🗺️ Lesson 3.1: The Gameplay Framework Map

Unreal ships a set of gameplay classes that fit together in a specific way — Actor, Pawn, Character, Controller, GameMode, and more. Learn the map now and every later lesson has a home. Fight the map, and you'll reinvent what the engine already gives you.

🎯 Learning Objectives

By the end of this lesson, you will be able to:

Name the core gameplay framework classes and state each one's job
Distinguish a Pawn (the body) from a Controller (the brain)
Explain what GameMode, GameState, and PlayerState hold and where they live
Trace how these classes connect during play
Choose the right base class for a new gameplay object

Estimated Time: 45 minutes

Engine Version: Unreal Engine 5.8

In This Lesson

Actor: The Root of It All

An AActor is anything that can be placed in or spawned into a level. If it exists in the world, it's an actor: a wall, a light, a pickup, a character, a trigger volume. Actors have a transform (location, rotation, scale) and can hold components (Module 3.3) that give them concrete abilities — a mesh, a collision shape, a light.

📖 Actor = container + transform

An actor by itself is nearly empty. Its capabilities come from the components attached to it. A "cube in the world" is an actor with a static mesh component; a "character" is an actor with a mesh, a collision capsule, and a movement component. Think of the actor as the thing, and components as its organs.

Nearly every gameplay class you'll write descends from AActor. The framework classes below are specialized actors (or their non-actor helpers) with roles the engine already understands.

Pawn & Controller

This is the distinction newcomers most often miss, and it's the key to the whole framework: the body and the brain are separate objects.

Class	Role	Analogy
`APawn`	A body that can be possessed and controlled — has a physical presence in the world	The car
`AController`	The brain that possesses and drives a Pawn	The driver
`APlayerController`	A Controller driven by a human (reads input)	A human driver
`AAIController`	A Controller driven by AI (behavior trees, logic)	An autopilot

graph LR PC["APlayerController
(human brain)"] -->|possesses| P1["APawn / ACharacter
(body)"] AI["AAIController
(AI brain)"] -->|possesses| P2["APawn
(body)"]

Figure 1: Controllers possess Pawns. The same Pawn body can be driven by a player or by AI just by swapping which Controller possesses it.

✅ Why separate them?

Because it's powerful. A player can possess different bodies (walk out of a character and into a turret or vehicle). An enemy body can be handed from AI control to player control. Input handling and persistent player data live on the Controller, so they survive even when the Pawn dies and respawns. This separation is a feature, not overhead.

Character

ACharacter is a specialized Pawn built for humanoid, walking movement. It comes pre-assembled with three components you'd otherwise wire up yourself:

A Capsule Component for collision (the pill shape around a humanoid)
A Skeletal Mesh Component for the animated character model
A Character Movement Component — walking, jumping, falling, swimming, networked and battle-tested

graph TD A["AActor"] --> P["APawn"] P --> C["ACharacter"] C --> Cap["+ Capsule (collision)"] C --> Mesh["+ Skeletal Mesh"] C --> Move["+ Character Movement Component"]

Figure 2: ACharacter is a Pawn with a standard humanoid loadout already attached. Use it when your Pawn walks like a person; use a bare Pawn for vehicles, flying, or custom movement.

💡 Choosing your base: humanoid on foot → ACharacter. A vehicle, spaceship, floating turret, or anything with non-standard movement → APawn (add your own movement). Something in the world that isn't controlled at all → plain AActor.

GameMode, GameState, PlayerState

Beyond individual bodies and brains, three classes hold the rules and state of the match itself:

Class	Holds	Lives where
`AGameModeBase`	The rules: which classes to use, spawn logic, win/lose conditions	Server only (authority)
`AGameStateBase`	The shared match state: score, time left, list of players	Exists on server & all clients (replicated)
`APlayerState`	Per-player state that outlives the Pawn: name, score, team	One per player, replicated

⚠️ GameMode is server-authoritative

The GameMode exists only on the server/host — clients never have one. That's deliberate: rules and spawn decisions are authoritative and must not be client-editable. When you need something clients can see (the score), it belongs on GameState, not GameMode. This distinction becomes critical in Module 10 (networking); we plant it now so the classes make sense.

📖 PlayerState outlives the Pawn

When a player's character dies and respawns, the Pawn is destroyed and recreated — but their score and name must persist. That's why they live on APlayerState (tied to the player) rather than on the Pawn (tied to a body). Same reasoning as Pawn/Controller separation: durable data lives on the durable object.

The Whole Map

Here's how the pieces connect during a live game:

graph TD GM["AGameModeBase
rules (server only)"] --> GS["AGameStateBase
shared match state"] GM --> Spawn["spawns & possesses"] Spawn --> PC["APlayerController
(brain)"] PC -->|possesses| Char["ACharacter
(body)"] PC --> PS["APlayerState
per-player data"] Char --> Comp["Components:
mesh, capsule, movement"] GS --> World["Level / World
holds all Actors"]

Figure 3: The gameplay framework in motion. The GameMode sets the rules and spawns players; a PlayerController possesses a Character; the PlayerState carries durable per-player data; GameState holds what everyone shares.

✅ The payoff

Unreal gives you all of this for free. When you make a project, a default GameMode, PlayerController, and Pawn already exist. Your job is to subclass the ones you need to customize — set your Character class on your GameMode, add score to your PlayerState — not to rebuild the framework. We do exactly that across Modules 3, 4, and 10.

Hands-on Exercise & Quiz

🏋️ Exercise: Place things on the map

Objective: Assign each requirement to the correct framework class.

The player's on-foot humanoid body
The logic that reads the gamepad and tells the body to move
The current team score, visible to every player
The rule "respawn a dead player after 5 seconds at a spawn point"
A player's kill count that must survive their character dying

✅ Answers

1. ACharacter (a Pawn specialized for walking).
2. APlayerController (the human brain; reads input).
3. AGameStateBase (shared, replicated match state).
4. AGameModeBase (server-only rules & spawning).
5. APlayerState (per-player data that outlives the Pawn).

🎯 Quick Quiz

Question 1: What is the relationship between a Controller and a Pawn?

Question 2: Which class exists only on the server?

Question 3: You're building a flying spaceship the player controls. Best base class?

Summary

🎉 Key Takeaways

AActor is anything in the world — a container with a transform whose abilities come from components.
Pawn (body) and Controller (brain) are separate: a Controller possesses a Pawn; APlayerController is human-driven, AAIController is AI-driven.
ACharacter is a Pawn pre-loaded with capsule, skeletal mesh, and movement — use it for humanoids, a bare Pawn otherwise.
GameMode (server-only rules), GameState (shared replicated state), and PlayerState (durable per-player data) hold the match itself.
Durable data lives on durable objects — that's why score is on PlayerState, not the Pawn.

📚 Additional Resources

🚀 What's Next?

Enough map-reading — time to build. Next we write real Actors in C++: creating them, adding components, and hooking into the lifecycle functions (constructor, BeginPlay, Tick, EndPlay) you met briefly in Module 1.

🎉 Lesson complete!

You hold the map. Let's start constructing what goes on it.