Gameplay Framework

The base of every UE project: actors, components, lifecycle, tick, input, AI.

This is the layer of Unreal Engine that all game logic rests on.

Actors
Components
Controllers
GameMode
PlayerState

These classes determine how objects exist in the world, how they communicate, and which class is responsible for what.

This is not abstract “architecture”. These are actual C++ classes with a concrete lifecycle, initialization order, and set of rules.

Why it matters

Most of the bugs I see do not come from gaps in rendering or physics knowledge. They come from misusing the Gameplay Framework:

a component assumes its owner is fully initialized by the time BeginPlay runs,
the wrong tick order causes a one-frame delay,
logic lands in GameMode instead of GameState, because “it had to go somewhere.”

A solid understanding of this layer saves hours of debugging and makes the systems built on top of it — AI, input, replication — behave the way they should.

What lives here

I write about things I run into in practice. I do not rewrite the documentation. If something is here, it is usually because it bit me once or cost more time than it should have.

Gameplay Framework

Why it matters

What lives here

ShouldCreateSubsystem and the subsystem class hierarchy

A Blueprint subsystem does not get created in a packaged build

Movie files in Content/Movies stay outside the pak — the two fields that change it

A tickable UObject — how to build one, what to keep in mind

A dispatcher broadcast from inside a handler does not see later bindings

Subsystem and manager actor lifecycles — who, when, and in what order

Set Timer by Event with Time = 0.0 never fires

A Blueprint node tooltip stops at the first @param

Casting to an interface misses Blueprint implementations