Implementing a state pattern for a game loop in Unity with C#

Unity games often begin with a straightforward loop: read input, update objects, run physics, and render a frame. That approach works for a prototype, yet it becomes difficult to maintain when the project adds menus, loading screens, paused play, cutscenes, multiplayer synchronisation, or several game modes.

A state pattern gives each mode a clear responsibility and defines how the game moves between modes. In Unity, this is implemented with C#, rather than plain C, using classes, interfaces, coroutines, and the engine’s lifecycle methods. The result is a game loop that is easier to test, extend, and reason about as production grows.

Why game loops benefit from states

A game loop is a repeated process, but the work performed during each frame depends on the current mode. During a title screen, the game may animate a background and listen for menu input. During active play, it must process movement, collisions, enemies, scoring, and camera updates. During a pause, most gameplay should stop while the pause menu remains responsive.

Without an explicit state model, developers often add fields such as isPaused, isLoading, isPlaying, and isGameOver. These values can contradict one another. A loading screen might accidentally accept gameplay input, or an enemy may continue moving while the user expects the game to be paused. A single state makes those rules visible.

The pattern also gives each mode a lifecycle. A state can perform setup when entered, update once per frame, and release resources when left. This is useful for a Unity project being developed across teams in Sydney, Melbourne, or Brisbane, where a designer should be able to understand a state’s behaviour without tracing a long Update() method.

Choosing state boundaries in Unity

A useful state is a meaningful mode from the player’s perspective and the programmer’s perspective. Common examples include BootState, MainMenuState, LoadingState, PlayingState, PausedState, GameOverState, and ResultsState. These boundaries are usually more valuable than creating a state for every small action, such as jumping or opening a weapon wheel.

The state should own decisions that belong to its mode. PlayingState can enable player input, advance simulation, and check for win or loss conditions. PausedState can stop simulation updates while leaving UI navigation active. A state should not need to know every detail of the systems it controls; instead, it can coordinate services such as an input handler, scene loader, audio controller, and session manager.

Unity scenes and states solve different problems. A scene describes content loaded into the engine, while a state describes the game’s current behaviour. One state may span several scenes, and one scene may support multiple states. Keeping these ideas separate prevents a scene transition from becoming the only way to represent a gameplay change.

Building the state contract in C#

The first step is a small interface or abstract base class. An interface keeps the contract precise and makes individual states easy to replace in tests.

public interface IGameState
{
    void Enter();
    void Tick(float deltaTime);
    void Exit();
}

A central controller owns the active state and performs transitions. The controller should exit the previous state before entering the new one. Passing deltaTime from Unity’s Update() method keeps timing explicit and avoids making every state depend directly on Time.deltaTime.

public sealed class GameStateMachine : MonoBehaviour
{
    private IGameState currentState;

    public void ChangeState(IGameState nextState)
    {
        if (nextState == null)
            throw new ArgumentNullException(nameof(nextState));

        currentState?.Exit();
        currentState = nextState;
        currentState.Enter();
    }

    private void Update()
    {
        currentState?.Tick(Time.deltaTime);
    }
}

A production implementation may use dependency injection or a factory to construct states with their required services. For a smaller project, the controller can create them directly. The important point is that state logic remains separate from the machine that schedules it.

A PlayingState might receive references to the player, input service, level rules, and UI. Its Tick method can check whether the user has requested a pause, whether the level has been completed, or whether the player has lost. It then requests a transition through the state machine rather than modifying unrelated flags.

Connecting transitions to Unity’s lifecycle

Unity has several timing systems, so a state pattern should define where each type of work occurs. Frame-based input and presentation commonly belong in Update(). Physics commands should be handled in FixedUpdate() or passed to a physics-focused service. UI animation may use Update() or an unscaled clock, especially when the game is paused.

Setting Time.timeScale to zero is a familiar pause technique, but it does not pause every system. Code using Time.unscaledDeltaTime continues to run, and audio, networking, analytics, or custom timers may follow their own clocks. A dedicated PausedState makes these decisions explicit instead of assuming that one Unity property handles the entire application.

Scene loading deserves a similar boundary. A LoadingState can start an asynchronous operation, display progress, and transition only when the target scene and required services are ready. It can also prevent duplicate requests caused by repeated button clicks. On a project targeting Australian players, testing should include realistic connections to Sydney cloud regions and slower mobile networks outside the major capital cities.

State transitions should be deterministic. If several systems request changes in the same frame, the machine can queue a transition or reject later requests after one has been accepted. Logging the source state, destination state, and reason is particularly valuable when diagnosing a build on a remote QA device or at an event such as PAX Aus in Melbourne.

Managing input, events, and asynchronous work

Input belongs at the boundary between the player and the current state. A state can ask an input service whether pause was requested, rather than reading keyboard, controller, and touchscreen APIs directly. This makes the same game logic usable across PC, console, and mobile builds.

Events are helpful when a system needs to report something without knowing which state is listening. For example, a level service can publish LevelCompleted, while the active state decides whether to show results immediately or wait for a network confirmation. Events should be unsubscribed in Exit() to avoid callbacks arriving after the state has been replaced.

Coroutines can support transitions, but their lifetime must be controlled. A coroutine started by PlayingState may continue after the game has entered GameOverState unless it is stopped or tied to a service with a clear owner. An alternative is to let the state hold an operation handle and cancel it during Exit().

Networked games need an additional distinction between local presentation states and authoritative session states. A client may display a reconnecting overlay while the server still considers the match active. Keeping those state machines separate avoids turning a temporary connection problem into an incorrect gameplay result.

Testing and extending the state machine

State logic is easier to unit test when it depends on abstractions instead of MonoBehaviour objects. A fake clock, fake input service, and fake scene loader can verify that PlayingState pauses when requested, enters results after a win, and ignores gameplay commands after exit. These tests run quickly without loading a Unity scene.

Integration tests should verify Unity-specific behaviour: scene activation, animator changes, input action maps, audio snapshots, and time-scale handling. Test transitions at frame boundaries as well as during asynchronous loading. A useful diagnostic overlay can show the active state, previous state, and time spent in the current state during development builds.

For an Australian commercial release, platform and market testing should reflect actual distribution conditions. A game sold through Steam, console stores, or mobile channels may encounter different suspend-and-resume behaviour, account flows, and certification requirements. Local studios frequently work with distributed teams, so readable transition logs and clear ownership reduce the cost of reproducing a bug between a Melbourne office and an external contractor in Perth.

Practices that keep the implementation reliable

• Keep states focused on one game mode rather than one individual action.
• Make Enter, Tick, and Exit safe to call with predictable ordering.
• Pass services into states instead of relying on scattered singletons.
• Separate gameplay time, real-world time, and network time.
• Cancel coroutines, subscriptions, and asynchronous operations during exit.
• Log every important transition with its reason and originating system.
• Test invalid transitions, rapid input, scene reloads, and application pause events.

A state pattern is most effective when it remains a modest coordination layer. It should not replace every subsystem or become a single global object containing all game rules. Player movement, combat, audio, UI, saving, and networking can retain their own responsibilities while the state machine decides which systems are active and how the overall loop changes mode.

For a Unity game written in C#, this structure creates a dependable path from prototype to production. New modes can be added without expanding a huge conditional block, and existing modes can be tested in isolation. Whether the target is an indie release from a Sydney studio or a larger cross-platform title, explicit states make the game loop clearer for programmers, designers, testers, and technical artists.