Unreal Engine 5.8 tutorial

Part 1 — The mental model (this is the most important part)

Unreal as an OOP framework with a game loop: Actors and Components, UObject reflection and garbage collection, the gameplay framework (GameMode, Controller, Pawn, Character), and lifecycle hooks.

If you internalize this section, everything else is detail. Skim it and you’ll be confused for weeks.

1.1 Unreal is an OOP framework with a game loop

At its core Unreal runs a loop, many times per second:

while (running) {
    handleInput();
    for (Actor a : world) a.Tick(deltaSeconds);   // your per-frame logic
    stepPhysics(deltaSeconds);
    render();
}

deltaSeconds is the time since the last frame. Anything frame-rate dependent must multiply by it (position += speed * deltaSeconds), exactly like any game loop or animation framework you’ve used.

1.2 Actors and Components (composition over inheritance)

  • An AActor is anything that can be placed in or spawned into a level. A rock, a light, a character, a trigger volume, a spawn manager — all Actors. (The A prefix is an Unreal naming convention; U = UObject, F = plain struct, I = interface, T = template.)
  • An Actor by itself is almost empty. It gets behavior and presence from UActorComponents attached to it. This is composition: a Character Actor = a Capsule Collision component + a Skeletal Mesh component + a Movement component + a Camera, etc.
  • One component is the Root Component; it defines the Actor’s transform (location/rotation/scale). Other scene components attach in a tree beneath it.

If you’ve used Unity, Actor ≈ GameObject, Component ≈ MonoBehaviour/Component — same idea, different names. If you’ve used ECS, note Unreal is not a pure ECS; it’s classic OOP composition (though the new Mass framework adds ECS-style crowds — more in Part 7).

1.3 UObject, reflection, and garbage collection

UObject is the base of almost everything that isn’t a plain C++ struct. Why it matters to you:

  • Reflection. Unreal has its own reflection system driven by macros (UCLASS, UPROPERTY, UFUNCTION). Marking a member UPROPERTY() registers it with the reflection system — making it serializable and, crucially, tracked by the garbage collector — and lets you opt into editor visibility (EditAnywhere / VisibleAnywhere), Blueprint access (BlueprintReadWrite), and network replication (Replicated) with the appropriate specifiers. A bare UPROPERTY() does none of those on its own.
  • Garbage collection. UObjects are GC’d. A raw UObject* member that is not a UPROPERTY can be deleted out from under you. Rule: store UObject references in UPROPERTY()-marked members, and in modern code use TObjectPtr<T> instead of raw T* for member pointers.
  • This is why you don’t new/delete UObjects manually — you NewObject<>() / SpawnActor<>() and let the engine manage lifetime.

1.4 The gameplay framework (the part everyone gets lost in)

Unreal ships an opinionated set of classes that define “a game.” Learn what each is responsible for and you’ll stop fighting the engine:

ClassAnalogyResponsibilityLifetime / scope
GameInstanceApp singletonPersists across level loads. Good for global state, save manager, online session.One, whole game session
GameModeRules engine (server-only)The rules: win/lose conditions, scoring, which Pawn/Controller/HUD classes to spawn. Exists only on the server in multiplayer.One per level, server-side
GameStateReplicated scoreboardShared state every client should see (match time, team scores).One per level, replicated
PlayerControllerInput + the player’s “will”Translates input into intent. Possesses a Pawn. Owns the HUD/UI. Survives Pawn death.One per player
PlayerStatePer-player dataName, score, ping — data about a player that persists across respawns and replicates.One per player
PawnA controllable bodyA physical agent in the world that a Controller can possess.Spawned/destroyed freely
CharacterPawn + humanoid movementA Pawn subclass with a capsule, skeletal mesh, and CharacterMovementComponent (walk/run/jump/crouch/swim).Spawned/destroyed freely
AIControllerA bot’s “will”Like PlayerController but driven by AI (Behavior Trees) instead of a human.Per AI agent

The key separation: Controller = the mind, Pawn = the body. A PlayerController possesses a Character. When the Character dies, the Controller lives on and can possess a new one. Input flows: hardware → PlayerController → possessed Pawn.

You’ll set the GameMode’s default classes (Default Pawn Class, Player Controller Class, etc.) in the GameMode asset or in Project Settings → Maps & Modes.

1.5 The lifecycle hooks (your constructors and update methods)

Every Actor exposes events you override. The order:

  1. Constructor (C++) / Construction Script (Blueprint) — runs in the editor and at spawn. Set up components. Don’t do gameplay here (the world may not be ready).
  2. BeginPlay() — called once when play starts or the Actor is spawned. Your “on ready / on mount.” Do initialization that needs the world here.
  3. Tick(DeltaTime) — every frame. Your update loop. Disable it if you don’t need it — per-frame ticks on thousands of Actors is a top performance sin.
  4. EndPlay() / Destroyed() — teardown.

Components have the same hooks. Prefer event-driven logic (overlap events, timers, delegates) over Tick wherever possible.

1.6 How Actors talk to each other

  • Direct reference — you hold a pointer/variable to another Actor and call its functions. Simple, but creates coupling.
  • CastingCast<AMyCharacter>(SomeActor) returns the typed pointer or nullptr. Like a safe downcast / as in C#.
  • Interfaces (UINTERFACE) — decouple: “anything that implements IDamageable can TakeDamage,” without knowing the concrete class.
  • Event Dispatchers / Delegates — Unreal’s observer pattern. An Actor broadcasts an event; any number of listeners bind to it. This is your pub/sub. Use it to avoid spaghetti references.
  • Tags & Gameplay Tags — lightweight labels for “find all actors tagged ‘Enemy’” and hierarchical state tags.
Exercise 1

Don’t build anything yet. Open your Wisp project (it’s Third-Person-based, so it already has everything below). In the Outliner, find the spawned character at runtime (use the “World Outliner” during PIE). Identify: which class is the GameMode? Which is the PlayerController? Which Pawn/Character is possessed? Open the BP_ThirdPersonCharacter Blueprint and find its components (Capsule, Mesh, CameraBoom/SpringArm, Camera, CharacterMovement). You’re just learning to see the framework.