Gameplay Framework: Actors, Pawns & Controllers

AActor is the base class for any object that can be placed in or spawned into an Unreal level. If it exists in the world, it is (or derives from) an Actor.

Actor Lifecycle

Actors go through a predictable sequence of events from creation to destruction:

Components

Actors are built from components. An Actor itself has no visual representation, collision, or movement — those come from the components attached to it:

• USceneComponent — provides a transform (position, rotation, scale)
• UStaticMeshComponent — renders a mesh
• UCapsuleComponent — provides collision
• UCharacterMovementComponent — handles movement physics

This component-based design means you compose behavior by attaching components, rather than inheriting it from deep class hierarchies.

APawn is an Actor that can be possessed by a Controller. This is the critical distinction: any Actor can exist in the world, but only a Pawn can be driven by a Controller.

A Pawn's job is to:

• Receive input and movement requests from its Controller
• Own the physical representation in the world (mesh, collision)
• Expose functions that a Controller can call (MoveForward, Jump, etc.)

ACharacter

ACharacter is the most commonly used Pawn subclass. It adds:

• A UCapsuleComponent for collision
• A USkeletalMeshComponent for an animated character mesh
• A UCharacterMovementComponent with walk, run, jump, fall, and swim built in

For most player characters and humanoid enemies, derive from ACharacter. Use APawn directly for vehicles, turrets, or anything without humanoid movement.

A AController is a non-physical actor that possesses a Pawn and drives its behavior. The Controller is the "brain"; the Pawn is the "body."

There are two Controller types:

Because the Controller is separate from the Pawn, you can swap the "brain" without changing the "body." The same ACharacter subclass can be possessed by a APlayerController in single-player, by a APlayerController replicated from a client in multiplayer, or by an AAIController when the player is dead and the game needs to take over.

The relationship between Controllers and Pawns is formalized through possession. When a Controller possesses a Pawn, it gains authority over its input and movement. When it unpossesses, the Pawn stops receiving input.

// Possessing a pawn from a Controller
AController* MyController = ...;
APawn* MyPawn = ...;
MyController->Possess(MyPawn);

// Unpossessing — Pawn still exists but receives no input
MyController->UnPossess();

Why this separation matters

Keeping behavior in the Controller and physicality in the Pawn enables powerful patterns:

• Spectator mode — PlayerController unpossesses player Pawn, possesses a spectator Pawn instead
• Vehicle entry — PlayerController repossesses a vehicle Pawn, then repossesses the character on exit
• AI takeover — same Pawn, swap from PlayerController to AIController during a cutscene
• Multiplayer — each client has their own PlayerController, all possessing different Pawn instances

The full hierarchy at a glance

UObject
└── AActor
    ├── AInfo
    │   ├── AGameMode        ← Rules of the game
    │   ├── AGameState       ← Shared game state
    │   └── APlayerState     ← Per-player state (score, name)
    ├── AController
    │   ├── APlayerController
    │   └── AAIController
    └── APawn
        └── ACharacter       ← Humanoid pawn with movement built in