Architecting Around GameState & Manager Systems

A common instinct is to make GameState the owner of your manager systems — an AI Manager, an Activity Manager — on the reasoning that they "dictate the game state."

Usually this is the wrong call. It:

• turns GameState into a god object;
• couples unrelated systems to each other;
• drags everything into the replication path;
• and loses those managers on every level travel, since GameState is re-created per map.

The modern idiomatic home for manager-style systems is Subsystems (Chapter 14): automatic lifecycle, singleton-per-scope access, no manual spawning or wiring.

The layered model most games converge on

The managers read from and write to GameState. They are not owned by it.

If a manager's state is itself shared, replicated data, then an ActorComponent on GameState is clean — because both GameState and its components replicate, the component gets networking for free.

Epic does exactly this in Lyra. ALyraGameState hosts a ULyraExperienceManagerComponent managing which "experience" (mode config) is loaded, because the loaded experience is shared state every client needs. Lyra's GameState also carries a global AbilitySystemComponent for game-wide effects and cues. Meanwhile Lyra uses subsystems heavily for service infrastructure that isn't shared match state.

AI Manager vs. Activity Manager

• AI Manager. AI runs server-side in Unreal — AIControllers are server actors (Chapter 16) — so this is near-pure server-authoritative logic that clients never run. Make it a UWorldSubsystem gated behind an authority check, or have GameMode drive it. If clients need to see something, like "12 enemies remaining", publish just that value to GameState. Don't put the manager there.
• Activity Manager (a mission, objective or dynamic-event director). This splits across two layers. The director logic deciding which activity runs is server-side, in a subsystem or driven by GameMode. The currently active activity is shared state clients care about, so that lives in GameState. It maps almost exactly onto Lyra's Experience pattern.

The concrete server → client flow

1. GameMode starts the match and tells the ActivityManager subsystem to begin.
2. ActivityManager (server) picks an activity, asks the AIManager to spawn the encounter, and writes CurrentActivity and EnemiesRemaining onto the GameState, which replicates.
3. AIManager (server) handles AI budget, pooling, spawning and coordination — none of which touches GameState.
4. Every client reads GameState->CurrentActivity to drive its HUD. No client runs manager logic; they just read the board.
5. On completion, ActivityManager updates GameState and the completion replicates out automatically.

GameState never does anything in that flow. It's the shared board, and the managers are what write to it.