Hawkdev.games

Good to know : The Building Blocks of a Game in UE5

·

When building a game in Unreal Engine 5, understanding the Game Framework is not optional — it is foundational. The UE5 framework defines how your game initializes, how players interact with the world, how data persists, and how systems communicate with each other. From Game Mode and Controllers to Pawns, SaveGame systems, and the World itself, each component plays a specific role in turning a project into a fully functioning game. This post provides a clear overview of the essential framework elements you must understand and use when developing in UE5, forming the structural backbone of any complete game experience.

Game framework elements

  • Game Mode
  • Game Session (Multiplayer)
  • Game State
  • Controllers
  • Player State
  • Pawns
  • Game Instance
  • User Interface
  • Inputs
  • SaveGame
  • World

Game Mode

Blueprints derived from Game Modes can set the following defaults:

  • The game mode is set in the level world settings

Game Mode Base

  • Primary class that specifies which other classes to use in the gameplay framework and is commonly used to specify game rules for modes

Game Mode

  • Has some extra functionality to support multiplayer matches and legacy behavior

Game Session

  • A game session exists only on the server, while running an online game.

Game State

  • Contains data and logic relevant to all players in a game, such as team scores, objectives, and a list of all players and their associated player states

Controllers

  • Non-physical actors that can possess a pawn (or Pawn-derived class like Character) to control its actions
  • Controllers take control of a Pawn with the Possess function, and give up control of the Pawn with the Unpossess function

Player Controller

  • used by human players to control pawns

Ai Controller

  • implements artificial intelligence to dictate a pawn’s actions

Player State

  • Handles data and logic relevant to its associated player, such as health, ammo count, and inventory.
  • Is created for every player on a server (or in a standalone game)

Pawns

  • Can be possessed and controlled by players or AI
  • Is the physical representation of a player or AI entity
  • One-to-one relationship between Controllers and Pawns

Default Pawn

  • Contains a native Movement Component, a spherical Collision Component, and a Static Mesh Component

Spectator Pawn

  • Provides a simple framework ideal for spectating functionality

Character Pawn

  • Special type of pawn designed for a vertically-oriented player representation that can walk, run, jump, fly, and swim through the world.

Game Instance

  • Persists throughout the lifetime of the game
  • Traveling between maps and menus maintain the same instance of this class
  • Used to manage information and systems that need to exist throughout the lifetime of the game between levels and maps
  • Can also use the Game Instance class to organize different game instance subsystems
  • The game instance must be set in the project settings

User Interface

  • Game menus, heads-up displays (HUD), and other elements drawn over the game screen
  • Provide users with information and help players interact with the game

HUD

  • The HUD is usually non-interactive, meaning the player does not click on elements of the HUD, though this becomes a gray area in certain types of games where the HUD and user interfaces are hard to separate.
  • The HUD is the base object for displaying elements overlaid on the screen. Every human-controlled player in the game has their own instance of the AHUD class which draws to their individual Viewport. In the case of splitscreen multiplayer games, multiple Viewports share the same screen, but each HUD still draws to its own Viewport. The type, or class, of HUD to use is specified by the Game Mode being used.

User Widgets

  • Drawn on a canvas, serves as visual representations of menus or other interactive on screen systems

Camera

  • The PlayerCameraManager is the “eyeball” for a player and manages how it behaves. Each PlayerController typically has one of these as well. It is set in the Player Controller class defaults and is spawned at runtime.

Inputs

  • The Enhanced Input system has four main concepts, Input Actions, Input Mapping Contexts, Input Modifiers, and Input Triggers.

Input mapping context

  • Input Mapping Contexts are a collection of Input Actions that represents a certain context that the player can be in. They describe the rules for what triggers a given Input Action. Mapping Contexts can be dynamically added, removed, or prioritized for each user.

Input Action

  • Input Actions are the communication link between the Enhanced Input system and your project’s code. Input Actions are the conceptual equivalent to Action and Axis mapping names, except they are data assets. Each Input Action should represent something that the user can do, like “Crouch” or “Fire Weapon”.

Input Modifiers

  • input Modifiers are pre-processors that alter the raw input values that UE receives before sending them on to Input Triggers. The Enhanced Input Plugin has a variety of Input Modifiers to perform tasks like changing the order of axes, implementing “dead zones”, and converting axial input to world space.
  • You can make your own Input Modifiers in C++ or Blueprints by creating a subclass of the UInputModifier class and overriding the ModifyRaw_Implementation function.

Input Triggers

  • Input Triggers determine whether user input, after passing through an optional list of Input Modifiers, should activate the corresponding Input Action within its Input Mapping Context. Most Input Triggers analyze the input itself, checking for minimum actuation values and validating patterns like short taps, prolonged holds, or the typical “press” or “release” events. 

SaveGame

  • Unreal Engine (UE) features a saving and loading system that revolves around one or more custom SaveGame classes that you create to meet your game’s specific needs, including all of the information that you need to preserve across multiple play sessions. The system supports the ability to have multiple saved game files, and to save different SaveGame classes to those files. This is useful for separating globally unlocked features from playthrough-specific game data.
  • You add required variables to the SaveGame, information you need to save, player location, items, health etc.
  • On Save, you create a Save Game Object Based off SaveGame and set the variables needing to be saved, then save the Save Game Object to a Slot
  • On Load, You check if Save Game Object exist in Slot, then Load Game from slot, then from the return value, as SaveGame, you extract the saved values and set them in the Game instance or other relevant places

World

  • Contains the levels and the actors that the player ultimately explores and interact with

Level

  • The container to build the game world in, has a level blueprint, used for level specific logic

Actor

  • The elements used to build the game world, can be meshes, sounds, particles, landscapes, NPCs, and much more. They can be only for visual or audio rendering, or they can implement logic.

Minimal required elements

  • Game instance
  • Menu Level
  • Game Level
  • Actor
  • Game Mode
  • Game State
  • Player State
  • Player Controller
  • Player Character
  • HUD
  • Player Camera Manager
  • Menu UI
  • Pause UI
  • Input Mapping Context
  • Input Actions
  • Save Game

Game instance
Persists throughout the entire application lifecycle and stores data or systems that must survive level transitions.

Menu Level
Provides a controlled environment for menus and setup before gameplay begins, separating UI flow from active game logic.

Game Level
Contains the playable world, actors, and level-specific logic where the core gameplay experience occurs.

Actor
Serves as the fundamental building block of the world, representing any object that can exist, render, or execute logic in a level.

Game Mode
Defines the core rules of the game and determines which framework classes (Pawn, Controller, HUD, etc.) are used during gameplay.

Game State
Holds shared runtime data about the match or session that must be accessible to all players.

Player State
Stores individual player-specific data such as score, health, or inventory that persists while the player is connected.

Player Controller
Acts as the bridge between player input and the Pawn, translating user commands into in-game actions.

Player Character
Provides the physical, controllable representation of the player within the world, handling movement and interactions.

HUD
Displays essential non-interactive gameplay information directly on the player’s screen.

Player Camera Manager
Controls how the player views the world, managing camera position, transitions, and visual effects.

Menu UI
Allows the player to navigate menus, adjust settings, and initiate gameplay or load games through interactive interface elements.

Pause UI
Provides in-game interruption functionality, enabling the player to suspend gameplay, access options safely and perform game saves if not implemented in game.

Input Mapping Context
Defines which inputs are active in a given situation, allowing dynamic control schemes depending on game state.

Input Actions
Represent specific player intentions (such as Jump or Interact) that connect input hardware to gameplay logic.

Save Game
Stores persistent data to disk so player progress and important game information can be restored across sessions.