Unity Game Mode System

What the system is for

Game state in Unity is one of those topics that looks like it belongs in a small static class, until the project has menus, gameplay, pauses, end screens and modal flows that all care about which mode the game is in. At that point an enum and a couple of booleans stop being enough. Music, input, UI and gameplay systems all need to react to the same transitions, and they all need to agree on what those transitions mean.

The Game Mode system in Serenity provides that contract. It defines a small set of game modes, exposes typed transitions as signals, and uses a pause strategy and a readiness gate to keep transitions clean.

The Unity problem

Most Unity projects end up with a custom GameStateManager. It usually starts as an enum and a public event. Then it accumulates exceptions: gameplay should not start until input is ready, music should only change when the scene is loaded, pause should freeze time only in certain modes. The manager grows special cases, the rest of the project ends up coupled to it, and changes get scary.

Pause behavior is its own subproblem. Some games freeze time, others keep certain systems running, and some do both depending on the screen. Without a pause strategy interface, that logic ends up inside the manager and is hard to swap.

How Serenity approaches it

Serenity exposes the game mode contract through IGameModeService, with the GameMode enum on the Domain side and explicit signals for transitions: StartGameSignal, EnterMenuSignal, ResumeGameSignal, PauseToggledSignal, EndGameSessionSignal and GameModeChangedSignal. Some of those have matching action types such as StartGame, EnterMenu, ResumeGame and EndGameSessionAction.

Pause behavior is described by IPauseStrategy, with a built-in TimeScalePauseStrategy. Transitions that depend on other systems being ready can go through IGameplayReadinessGate, implemented by GameplayReadinessGate. The Unity-specific implementation is UnityGameModeService, configured through UnityGameModeSettingsDefinition and UnityGameModeSignalConfiguration.

How it fits into Serenity

Game Mode lives in the Serenity.GameMode namespace. Domain types include the GameMode enum and the pause strategy interface. The Application layer provides the service interface, the readiness gate and the transition signals and actions. The Infrastructure layer provides UnityGameModeService and TimeScalePauseStrategy. A UnityGameModeInstaller registers the system through the initialization pipeline.

Game Mode is a hub. The Menu System reacts to EnterMenuSignal. The Music Player can change tracks on StartGameSignal or PauseToggledSignal. Game Settings can persist values when a session ends. The Modal System can request restart or end-session confirmations through the corresponding modal signals. Input behavior changes depending on the current mode through the Input System routing.

Practical workflow

1. Configure a UnityGameModeSettingsDefinition with the modes and transitions your game needs.
2. Map signals to actions through UnityGameModeSignalConfiguration.
3. Pick a pause strategy, for example TimeScalePauseStrategy, or supply your own IPauseStrategy.
4. Let the game mode installer register the service in the initialization pipeline.
5. Dispatch StartGameSignal, EnterMenuSignal, PauseToggledSignal and similar signals from gameplay code.
6. Subscribe to GameModeChangedSignal in systems that need to react to the new mode.

What you get

• GameMode enum and IGameModeService contract
• Typed signals StartGameSignal, EnterMenuSignal, ResumeGameSignal, PauseToggledSignal, EndGameSessionSignal and GameModeChangedSignal
• Pause strategy interface IPauseStrategy with built-in TimeScalePauseStrategy
• Gameplay readiness gate IGameplayReadinessGate to delay transitions until systems are ready
• UnityGameModeService and UnityGameModeSettingsDefinition for Unity-specific configuration
• Signal configuration through UnityGameModeSignalConfiguration
• Installer that registers the service for the whole project
• Integration with menus, music, input and settings through signals

When to use this

• Projects with more than one screen state that gameplay systems must react to.
• Games that need pause behavior to be swappable per project or per build.
• Teams that want game state transitions to be typed signals instead of string events.
• Codebases that need a clean place to gate gameplay startup until input, settings and other systems are ready.

Related systems

• Unity Menu System Declarative menus, shared UI themes and predictable navigation, configured as assets instead of hand-wired GameObjects.
• Unity Music Player Background music driven by track definitions, configurable transitions and typed signals you can hook into game state.
• Unity Event Dispatcher Typed signals dispatched through a service, with auto-registration support and no static singletons.
• Unity Input System Integration A player input gateway that routes Unity Input System actions to menus, gameplay and UI navigation through clean services.