Skip to content

GameMode & friends, single-player edition

GameMode is not "the place for all game variables." It is the per-level rule and spawn manager that tells Unreal which framework classes this map uses.

The one-minute version

  • GameMode defines the current map's game rules and default framework classes. It is where a first project usually sets the default pawn, PlayerController, HUD, GameState, and PlayerState classes.
  • GameMode is chosen by project settings, per-map World Settings override, travel URL, or map-prefix rules. If the wrong GameMode is active, Unreal can spawn the wrong pawn, controller, or HUD even though your Blueprint looks fine.
  • GameMode is created for the loaded level. It is not the thing that survives Open Level; use Game Instance for across-map data.
  • The normal beginner spawn chain is: map loads, active GameMode is chosen, player controller exists or is created, GameMode picks/spawns a pawn, and the controller possesses it.
  • Put map/match rules and spawn decisions in GameMode. Put player input and UI ownership in PlayerController. Put body movement/health in the Pawn or Character. Put level-specific scripted events in level actors, not in GameMode by default.
  • In multiplayer, GameMode exists on the server, not on remote clients. This page keeps the single-player mental model, but that rule explains why GameMode is not client UI storage.

The framework pieces

Unreal's gameplay framework splits the "game" into objects with different lifetimes and jobs.

flowchart TD
    GI[Game Instance<br/>survives level travel] --> World[Loaded World / Map]
    World --> GM[GameMode<br/>rules + default classes]
    GM --> GS[GameState<br/>game-wide runtime state]
    GM --> PC[PlayerController<br/>human player's control path]
    GM --> HUD[HUD<br/>player screen overlay path]
    PC -- possesses --> Pawn[Pawn or Character<br/>body in the world]
    PC --> Camera[PlayerCameraManager / camera view]
    PC --> PS[PlayerState<br/>per-player state]

For a first single-player project, the most useful translation is:

Class Beginner job
GameMode Which rules and default classes this level uses; how players start or restart.
GameState Runtime state about the current game/session that should be visible as game state.
PlayerController The human player's input, UI ownership, camera/view decisions, and possession path.
Pawn / Character The physical body in the world: movement, collision, mesh, damage, abilities attached to the body.
HUD / widgets Screen presentation for a player. Modern projects often create UMG widgets from the controller/HUD path.
PlayerState Per-player scoreboard/identity-style state. It matters more once multiplayer enters the picture.
Game Instance Data and managers that survive loading a different map.

If you try to make one Blueprint own all of those jobs, it works for a week and then becomes impossible to debug. The framework split is Unreal's answer to "who should own this?"

What happens when a map starts

At startup altitude, map play looks like this:

pseudocode of the setup relationship - not engine source

Engine already has a GameInstance
Open or start a map
-> create the World for that map
-> choose the active GameMode class
-> create the GameMode actor
-> GameMode creates/uses its framework classes
-> player controller enters the game
-> GameMode chooses a PlayerStart
-> GameMode spawns the default pawn class
-> PlayerController possesses that pawn
-> player input and camera now have a body to drive/view

The exact engine path has more hooks than that, especially for networking and seamless travel. The beginner point is simpler: the GameMode is the map's starting rulebook and factory for the default player setup.

That is why changing Default Pawn Class in the active GameMode changes what body the player gets when the level starts. It is also why editing the wrong GameMode Blueprint changes nothing.

The override chain

When Unreal asks "which GameMode should this map use?", several settings can answer. The two that matter most in month one are:

Place Beginner meaning
Project Settings -> Maps & Modes -> Default GameMode The project's normal fallback GameMode.
World Settings -> GameMode Override This specific map's override. It wins over the project default for that map.

Epic's docs also document URL and map-prefix ways to choose GameMode. Those are real, but they are not where a beginner usually starts.

Use this debug checklist when "my GameMode isn't running":

  1. Open the map you are actually pressing Play in.
  2. Check World Settings -> GameMode Override for that map.
  3. Check Project Settings -> Maps & Modes -> Default GameMode.
  4. Expand the selected GameMode's defaults and confirm its Default Pawn Class, Player Controller Class, HUD Class, GameState Class, and PlayerState Class.
  5. Press Play and print Get Class Display Name from BeginPlay in the GameMode you think is active.

If your print never runs, the active map is not using that GameMode instance.

What belongs in GameMode?

Good first-project GameMode jobs:

  • default framework class selection;
  • spawn and respawn rules;
  • selecting a PlayerStart;
  • game start/end rules;
  • win/loss decisions for the current level or run;
  • rules such as "can this player restart?" or "which pawn class should this controller receive?"

Poor first-project GameMode jobs:

  • the player's current input graph;
  • per-frame character movement;
  • widget button logic;
  • health stored only because you could not find the character reference;
  • variables that must survive Open Level;
  • level-specific door/platform/cutscene scripts that belong to placed actors or the Level Blueprint.

The quick path is to put any "global-looking" variable in GameMode. The concrete cost is that map travel destroys and recreates GameMode, and multiplayer clients do not have the server's GameMode instance. Put the data where its lifetime and audience actually match.

Where should this variable go?

Data or behavior First place to consider Why
Default player body class GameMode It decides which pawn class to spawn for players.
Respawn location/rules GameMode It owns player start/restart decisions.
Current health Character or health component Health belongs to the body that can take damage and die.
Health bar widget reference PlayerController or HUD path UI is per local player and often survives pawn replacement.
Pause menu open/close input PlayerController and widget It is local player control/UI, not map rules.
Score for one player PlayerState later; simple single-player can start in controller/save data It is per player, not the pawn's body.
Current objective in this map GameState or objective manager actor It is runtime game/session state, not a default class setting.
Coins collected across maps Game Instance or SaveGame It must outlive the current level.
Door opened in this level Door actor, level actor, or save system if it must persist The door owns the level-specific state.

This table is a starting point, not a law. The rule is: match the object's lifetime and audience to the data. If the thing is destroyed at the wrong time or hidden from the machine that needs it, it is in the wrong owner.

Common traps

  1. The map overrides the project GameMode. Your project default is correct, but this level's World Settings points at another GameMode.
  2. You changed Default Pawn Class in the wrong place. The active GameMode is not the one you edited.
  3. A pawn placed in the level is auto-possessed. You may be controlling a placed pawn, not the pawn GameMode would have spawned.
  4. There is no PlayerStart or the PlayerStart is blocked. Spawn can move or fail in ways that look like the wrong pawn setup.
  5. You stored run data in GameMode, then used Open Level. The old GameMode belonged to the old world.
  6. You put UI state in GameMode. Player UI is a local-player concern; use PlayerController/HUD/widget ownership patterns.
  7. You used GameMode from client-side thinking. In multiplayer, remote clients do not have the authoritative GameMode instance.
  8. You used GameMode for level-specific actors. A door, pickup spawner, or puzzle actor usually owns its own state better than GameMode does.

Debug with the same tools as any Blueprint mystery: print the active class, watch the instance that is actually running, and avoid assuming that a class default changed the already-running world.

Lookalikes - which one do I want?

Thing Use when Not the same as
GameMode Current map/session rules, default classes, player spawn/restart. Persistent cross-map storage.
GameState Runtime game-wide state for the current session/map. Rules/default class selection.
PlayerController Human player's input, UI ownership, camera, possession path. The pawn body.
Pawn / Character Movement, collision, mesh, health/body-specific abilities. The player identity or rules object.
PlayerState Per-player score/identity/state that should conceptually belong to a player. A local-only widget controller.
HUD / Widget What the player sees on screen and interacts with. Match rules or persistent save data.
Game Instance Data/managers that survive changing maps. Current map's default pawn or PlayerStart rules.
Level Blueprint One-off scripting for this specific map. Reusable game rules across many maps.

Going deeper