How-To

Unreal Engine Gameplay Framework: The Blueprint Structure Behind Every Playable Game

Before building gameplay in Unreal Engine, it helps to understand the framework that quietly appears when you press Play. Game Mode, Player Controller, Character, Game State, Player State, and Game Instance each have a specific job.

Before pressing Play, the level appears empty. In this example, the Outliner shows only the level itself: L_TestLevel (Editor). There are no placed gameplay actors in the scene. This is important because it shows the starting point clearly: the level does not already contain a visible player, controller, game mode, game state, or pawn.

At this stage, the editor is only showing the design-time version of the level. Nothing has been spawned for gameplay yet.

**Figure 1. Empty level before pressing Play.** The Outliner contains only the level itself. No gameplay actors have been spawned yet.

When Play is pressed, Unreal Engine creates the runtime version of the level. The Outliner now changes from L_TestLevel (Editor) to L_TestLevel (Play In Editor), and several new actors appear automatically.

In this example, Unreal created 11 actors, including DefaultPawn0, GameModeBase0, GameStateBase0, PlayerController0, PlayerState0, HUD0, PlayerCameraManager0, and other supporting runtime actors. These were not manually placed in the empty level. They were created by Unreal as part of the gameplay startup process.

This is the first practical clue that the Gameplay Framework is not just theory. When the game starts, Unreal needs a rule system, a player connection, a controllable pawn, player information, game state information, camera management, and other runtime systems. The Gameplay Framework provides that structure.

**Figure 2. Runtime actors created after pressing Play.** When the level starts playing, Unreal automatically spawns gameplay framework actors and supporting runtime actors in the Outliner.

When you press Play in Unreal Engine, the level does not simply “start.” Unreal creates and connects a set of gameplay objects that define how the game runs, who controls what, what rules apply, and what information needs to persist.

This system is called the Gameplay Framework.

At first, the Gameplay Framework can feel abstract because many of its classes are invisible during normal level editing. You can see meshes, lights, cameras, and actors in the viewport. But objects such as the Game Mode, Game State, Player Controller, Player State, and Game Instance mostly work behind the scenes.

Placing objects into a level and writing logic directly inside those objects may work for small experiments, but it quickly becomes messy. A better approach is to understand what each gameplay class is responsible for and place your logic where it naturally belongs.

The big idea is this:

Unreal’s Gameplay Framework separates responsibility by lifetime, authority, and purpose.

Different parts of the framework exist for different durations, run in different places, and handle different types of logic.

In this article, I provide a simple overview of the Gameplay Framework before we build a step-by-step Blueprint setup in a future article.

What Happens When You Press Play?

When you play a level, Unreal creates a playable world. In that world, the engine needs answers to several basic questions:

What rules does this level use?
What pawn or character should the player control?
What object receives player input?
Where is shared game information stored?
Where is individual player information stored?
What information should survive level changes?

The Gameplay Framework answers these questions through a set of core classes.

The most important classes for a beginner-friendly Blueprint setup are:

Gameplay Class	Simple Description
Game Mode	Defines the rules of the game or level.
Player Controller	Connects the human player to the controlled pawn or character.
Character / Pawn	The object the player controls in the world.
Game State	Stores game-wide information that players may need to know.
Player State	Stores information about an individual player.
Game Instance	Stores information that persists across level changes.

The Simple Mental Model

A useful way to understand the Gameplay Framework is to imagine a game as a small organization.

The Game Mode is the rulebook.

The Game State is the public scoreboard.

The Player Controller is the player’s input desk.

The Character is the body in the world.

The Player State is the player’s profile.

The Game Instance is the long-term manager that survives between levels.

Each one has a different job. Problems usually happen when we put logic in the wrong place.

For example, if we place all logic inside the Character Blueprint, the Character becomes responsible for movement, input, score, rules, level flow, player data, and persistence. That may seem convenient at first, but it creates a tangled Blueprint that becomes hard to maintain.

A cleaner design spreads responsibilities across the framework.

Game Mode: The Rules of the Game

The Game Mode defines what kind of game is being played.

It decides which default classes should be used, such as:

Default Pawn or Character
Player Controller
Game State
Player State
HUD class, if used
Spectator class, if used

For a single-player Blueprint demo, the Game Mode is often where you define the basic rules of the level. For example:

Which Character the player should spawn as
Which Player Controller should be used
What happens when the level starts
Whether the game is in progress, won, lost, or waiting to begin

A practical lesson is this:

Put rules in the Game Mode, not in the Character.

The Character should not decide the entire structure of the game. The Character should mainly represent the playable body in the world.

Player Controller: The Player’s Connection to the Game

The Player Controller represents the human player’s connection to the game world.

It is not the same thing as the Character.

This is one of the most important distinctions in Unreal Engine.

The Character is the physical body in the world. The Player Controller is the thing that receives input and tells the Character what to do.

This separation matters because a player may control different pawns at different times. For example:

A walking character
A vehicle
A drone
A tactical camera
A temporary spectator view

The Player Controller can remain the player’s control object even when the controlled pawn changes.

For a clean Blueprint setup, the Player Controller is a good place for player-facing control logic, such as:

Input routing
Camera control logic
UI opening and closing
Mouse cursor settings
Possessing or unpossessing Pawns

Character and Pawn: The Body in the World

The Pawn is the base concept for something that can be controlled.

A Character is a specialized kind of Pawn designed for humanoid movement. It includes a capsule, skeletal mesh support, and a Character Movement Component.

The Character is the most visible part of the Gameplay Framework. It is the object the player sees moving around the level.

The Character is a good place for logic related to the body itself, such as:

Movement behavior
Jumping
Crouching
Health components, depending on the project
Interaction traces, if they belong to the body
Animation-related references
Collision behavior

But the Character should not become the dumping ground for all gameplay logic.

The Character should not be responsible for global rules. It should not manage long-term save data. It should not track every player’s score. It should not decide which class the game should spawn.

The Character’s main job is simple:

Be the controllable body inside the world.

Game State: Shared Information About the Current Game

The Game State stores information about the current game or level that other players and systems may need to know.

If the Game Mode is the rulebook, the Game State is the shared public status board.

Examples of Game State data include:

Match timer
Current objective
Team score
Round number
Whether the game is active, paused, won, or lost
List of connected players

The distinction between Game Mode and Game State is important.

The Game Mode controls the rules.

The Game State shares the current state of those rules.

In multiplayer, this matters even more because Game Mode exists only on the server, whereas Game State can replicate information to clients. Even in a single-player project, separation remains useful because it keeps your architecture clean.

A simple rule of thumb:

Put rule decisions in Game Mode. Put shared game status in Game State.

Player State: Information About One Player

The Player State stores information about an individual player.

This is different from the Character.

A Character can be destroyed and respawned. A player may switch Pawns. A player may die and come back. But the Player State can continue to represent that player’s current information.

Examples of Player State data include:

Player name
Score
Team
Player level
Death count
Player-specific status
Readiness state in a lobby

Do not store player identity in the Character if that information should survive respawning. The Character is the body. The Player State is the player’s game-related record.

A useful rule:

If the data belongs to the player but not necessarily to the current body, consider Player State.

Game Instance: Data That Survives Level Changes

The Game Instance has a different lifetime from the other gameplay classes.

It is created when the game starts and remains alive until the game shuts down. It is not tied to one specific level. That makes it useful for information that should persist between maps.

Good uses for Game Instance include:

Save game management
Selected character or profile
User settings
Session-level data
Data passed between levels
High-level managers and subsystems

The Game Instance should not be treated as a dumping ground for everything. It is long-lived, so careless use can turn it into a global junk drawer. But when used properly, it is the right place for data that must survive level transitions.

A simple rule:

If the data must survive opening another level, Game Instance may be the right place.

Split Responsibilities by Lifetime and Authority

The most useful way to understand the Gameplay Framework is to ask two questions:

How long should this data or logic live?
Who should have authority over it?

This gives us a practical structure.

Question	Likely Class
Does this define the rules of the current game?	Game Mode
Does everyone need to know the current game status?	Game State
Does this belong to one specific player?	Player State
Does this receive and manage player input?	Player Controller
Does this represent the controlled body in the world?	Character / Pawn
Does this need to survive level changes?	Game Instance

This is the heart of the framework.

Unreal is not just giving you a random collection of Blueprints. It is giving you a structure for separating responsibilities.

When you understand that structure, your Blueprints become easier to read, debug, and expand.

Why This Matters

The Gameplay Framework is not just a technical detail. It shapes how you think about game architecture.

A good Unreal project is not built by throwing logic wherever it happens to work. It is built by clearly assigning responsibility.

That does not mean every small project needs a complex architecture. But even a small project benefits from clean separation:

Rules belong in one place.
Input belongs in one place.
The player’s body has a clear role.
Shared game status has a clear role.
Player-specific data has a clear role.
Persistent data has a clear role.

This is how a simple prototype becomes a project you can grow.

Conclusion

The Unreal Engine Gameplay Framework gives you the foundation for organizing a playable game.

The most important classes are not difficult once you understand their purpose:

Game Mode defines the rules.
Player Controller connects the player to the game.
Character or Pawn represents the controlled body.
Game State stores shared game information.
Player State stores individual player information.
Game Instance stores data that persists across levels.

In a future article, we will turn this overview into a working Blueprint setup. We will create the framework classes, assign them correctly, build a simple test level, and verify what Unreal creates when the game starts.