advanced

System Design

Decomposing gameplay systems in Unreal — components, state machines, data-driven design, save/load, network — the senior-interview skeleton.

ue-system-design

Practice: 17 questions →

Sections

Detailed explanation

System Design — splitting the monolith, no 1000-line Character

Middle interviews ask how to implement a feature. Senior interviews ask how to decompose it into subsystems, draw responsibility boundaries, and survive a year of refactoring. System Design in Unreal is not API trivia — it is the ability to see the decomposition axes: where state lives, who has network authority, what loads from data, how saves migrate, when to use a component vs an actor vs a subsystem.

Senior questions in this area reduce to a few repeating axes: state ownership (Pawn, PlayerState, GameState, Subsystem), authority (server vs client decision), data vs code (DataAsset/DataTable vs C++), persistence (what survives Pawn death, level transition, game restart), composition vs inheritance (component or base class). Every well-designed system is a concrete answer to these five questions.

Twelve sub-topics below — each one defends against a specific failure mode: god-actors, hard references, client-side authority, hardcoded numbers, naive serialization.

Why it matters

System Design at senior UE interviews is not "how to write a function" but how to split a large task into subsystems. Without this skill, engineers ship 3000-line ACharacter classes that hold inventory, weapons, stats, save logic and network code in one place — and the project dies before alpha.

System Design — splitting the monolith, no 1000-line Character

Twelve sub-topics below — each one defends against a specific failure mode: god-actors, hard references, client-side authority, hardcoded numbers, naive serialization.