Modular Actors & Player Layer

CrimsonCommon folds three Epic sample plugins into one foundation so the suite depends on a single layer: ModularGameplayActors (the GFP-extensible framework classes), CommonGame (the UI policy + primary layout), and CommonUser (login/session). You get the base classes without inheriting those plugins' wider dependencies.

Modular framework classes

Each ACrimsonModular* class derives from its Epic equivalent and adds the Game Feature / Modular Gameplay registration hooks, so Game Features and plugins can attach components and abilities to them at runtime. They add no gameplay state of their own - game-specific state belongs in your subclasses or in feature components.

Class	Base	Role
`ACrimsonModularCharacter` / `ACrimsonModularPawn`	`ACharacter` / `APawn`	GFP-extensible player/AI bodies
`ACrimsonModularPlayerController` / `ACrimsonModularPlayerState`	`APlayerController` / `APlayerState`	GFP-extensible controller and per-player state
`ACrimsonModularGameMode[Base]` / `ACrimsonModularGameState[Base]`	`AGameMode[Base]` / `AGameState[Base]`	GFP-extensible match rules and shared state
`ACrimsonModularAIController`	`AAIController`	GFP-extensible AI controller

Player layer

Above the framework classes sits the player/session layer. UCrimsonCommonGameInstance tracks the primary player and exposes an OnPrimaryPlayerSet hook; UCrimsonCommonLocalPlayer broadcasts player-side delegates; ACrimsonCommonPlayerController bridges controller to local player. The online side - UCrimsonUserSubsystem (login, privileges, online context) and UCrimsonSessionSubsystem (host/join/matchmaking, beacons) - is a complete, self-contained port of Epic's CommonUser (both OSSv1 and OSSv2 paths), with every type renamed to the Crimson prefix.

UI policy belongs here too

UCrimsonGameUIManagerSubsystem + UCrimsonGameUIPolicy create and own each local player's UCrimsonPrimaryGameLayout, including the local-multiplayer interaction mode. That's the CommonGame replacement - see How-To: Show a Widget on a UI Layer.

Use only what you need

Nothing forces you to adopt the whole stack. The user/session subsystems are independent of the framework classes - a single-player project can use ACrimsonModularCharacter and ignore UCrimsonSessionSubsystem entirely.