In UE5, default to an Actor Component for “master controller”-style logic and I/O orchestration, and only use an Actor when you need the thing to exist as a placeable/spawnable world entity with its own transform, collision, replication relevance, etc.
This “master controller” is primarily behavior + state that you want to attach to something else.
Typical reasons:
- You want to add the functionality to multiple different Actors (PlayerController, Pawn, GameState, a manager Actor, etc.).
- You want the logic to be modular/testable (swap it out, disable it, reuse it).
- You don’t want to care about transforms, collision, or being “in the level.”
- Your “I/O” is really event routing: input events, device events, network messages, gameplay events, etc.
In practice, this often looks like:
- A UActorComponent (or UGameInstanceSubsystem / UWorldSubsystem—more on that below) that:
- registers listeners (Enhanced Input, delegates, messaging),
- normalizes events into a common format,
- dispatches them to interested systems.
Your controller is actually a thing in the world.
Typical reasons:
- It must be placed in a level (or spawned) and has level lifetime.
- It needs a transform (e.g., an in-world console, router box, proximity-based controller).
- You want to leverage Actor-level features directly: replication, ticking, networking relevancy, ownership, etc.
- Designers need to configure it in a scene with visual debugging.
A common hybrid is: a thin Manager Actor that exists in the level, with the real logic implemented in one or more Actor Components attached to it.
If by “master controller” you mean global orchestration (not tied to a particular Actor), UE5 often wants you to use Subsystems instead:
- Lives across level loads.
- Great for device connections, external I/O, account/session state.
- Lives for the world, resets when you change worlds/maps.
- Great for input mapping, player-specific routing, UI-layer I/O.
Subsystems are purpose-built “managers,” and avoid the “where do I spawn my manager actor?” problem.
- Subsystem owns the orchestration (global routing, device state, message hub).
- Actor Components adapt that to specific actors (player pawn, interactables, UI drivers).
- Actors only when you need a physical in-world endpoint or designer-placed config.
Answer “yes” → pick the row’s option.
- Needs to be placed/spawned in the level? → Actor
- Needs transform/collision/in-world presence? → Actor
- Needs to persist across map loads? → GameInstanceSubsystem (not Actor/Component)
- Should be reusable across many actor types? → Actor Component
- Is it player-specific input routing? → LocalPlayerSubsystem (or component on PlayerController/Pawn)
- Is it global event bus / I/O hub? → Subsystem (+ components as adapters)
For “I/O and master controller-like functionality” in most UE5 projects:
- Core = Subsystem
- Integration points = Actor Components
- Actor only if it must exist as a world object
If you tell me what you mean by “I/O” (hardware/serial? network sockets? just gameplay input + interactions?) and whether it must persist across map loads, I’ll suggest the cleanest UE5 class layout (including what owns what and what replicates).