Course contentsShow
← Unreal Engine Game Development
Lesson 111 of 8802. The Gameplay FrameworkFree lesson

Separating Gameplay Logic from Character Blueprints

Students will migrate critical gameplay calculations from the character class to the controller to ensure persistence across pawn changes.

In this lesson, you will learn why moving core gameplay logic out of your Character blueprint and into your PlayerController is essential for creating robust, persistent player experiences.

The Problem with Pawn-Centric Logic

As beginners, we often put everything inside the Character blueprint: health, score, inventory, and inventory management. This seems easy until you realize that in Unreal Engine, a Pawn (or Character) can be destroyed, respawned, or switched entirely.

If your "Current Score" or "Inventory List" is stored inside the Character, that data is wiped the moment the Character is destroyed or replaced. Your player effectively becomes a blank slate every time they respawn, which ruins the flow of your game.

The Solution: Persistent Controllers

The PlayerController is the "brain" that persists for the duration of the player's session. Even if you swap from a "Soldier" character to a "Vehicle" pawn, the PlayerController stays active and connected. By migrating your critical variables—like PlayerExperience, HealthStats, or InventoryData—into the PlayerController, you ensure those values stay constant regardless of which physical body the player is currently possessing.

Consider this logic migration pattern:

  • Inside Character: Handle visual-only things like playing footstep sounds, triggering animations, or managing the camera position.
  • Inside PlayerController: Handle state-based things like calculating damage, adding experience points, or checking if an item can be picked up.

Example Logic Flow: When a player picks up an item, don't tell the Character to "Add item to inventory." Instead, use an Interface or a direct cast to tell the PlayerController:

// Logic inside the PlayerController
void AMyPlayerController::AddInventoryItem(FItemData Item) 
{
    PersistentInventory.Add(Item);
    UpdateUI(); // Keeps the HUD updated across different pawns
}

By decoupling these systems, your code becomes modular. You can change your Character blueprint model or swap pawns entirely without needing to rewrite your underlying gameplay rules, because those rules now live safely inside the persistent PlayerController.

Key Takeaway: Always store data and gameplay rules in the PlayerController to ensure they survive the destruction or replacement of your Character pawn.