🧩 Lesson 1.4: Scaling Design Patterns — Command, State, Service Locator & Event Bus

Why Patterns, and Which Four

A design pattern isn't a library you install; it's a shape you recognize and reproduce. Its value is twofold: it's a proven structure for a recurring problem, and it's a shared name so a teammate instantly knows what you built. The risk is over-application — patterns add indirection, and indirection you don't need is just complexity. The skill is matching the pattern to a real pressure.

These four each answer a specific scaling pressure:

• Command — when you need to treat "an action" as data: queue it, log it, undo it, replay it.
• State — when an object's behavior depends on a mode and the if/switch soup is getting unmanageable.
• Service Locator — when many systems need shared services and you want one place to find them (with eyes open about the cost).
• Event Bus — when a change in one system must notify many others that shouldn't know about each other.

Command

The Command pattern turns a method call into an object. Instead of calling player.Jump() directly, you create a JumpCommand and execute it. That reification unlocks everything you can do with objects but not with raw calls: store them in a list, send them over a network, and — because a command can also know how to reverse itself — undo them.

public interface ICommand
{
    void Execute();
    void Undo();
}

public class MoveCommand : ICommand
{
    private readonly Transform _t;
    private readonly Vector3 _delta;
    public MoveCommand(Transform t, Vector3 delta) { _t = t; _delta = delta; }

    public void Execute() => _t.position += _delta;
    public void Undo()    => _t.position -= _delta;   // the inverse
}

An invoker keeps a history stack, giving you undo/redo almost for free — the core of any level editor or turn-based game:

public class CommandInvoker
{
    private readonly Stack<ICommand> _undo = new();
    private readonly Stack<ICommand> _redo = new();

    public void Execute(ICommand cmd)
    {
        cmd.Execute();
        _undo.Push(cmd);
        _redo.Clear();          // a new action invalidates the redo branch
    }

    public void Undo()
    {
        if (_undo.Count == 0) return;
        var cmd = _undo.Pop();
        cmd.Undo();
        _redo.Push(cmd);
    }

    public void Redo()
    {
        if (_redo.Count == 0) return;
        var cmd = _redo.Pop();
        cmd.Execute();
        _undo.Push(cmd);
    }
}

The same reification powers input buffering: in a fighting game you enqueue commands as inputs arrive and execute them when the character is ready, so a slightly-early button press still lands. Because commands are just data, you can also record a replay (a list of commands + timings) or send them across the wire — a preview of the RPC thinking in Module 6.

State (a Code-Level FSM)

You already know finite state machines from the Animator in Intermediate — states with entry/exit and transitions between them. The State pattern is that same idea in code, for game logic rather than animation: an enemy that is Patrolling, then Chasing, then Attacking; a game that is in Menu, Playing, or Paused. Rather than a growing tangle of booleans and ifs, each state becomes its own class behind an interface.

public interface IState
{
    void Enter();
    void Tick();     // called each frame while active
    void Exit();
}

public class StateMachine
{
    private IState _current;

    public void ChangeState(IState next)
    {
        _current?.Exit();     // clean up the old state
        _current = next;
        _current.Enter();     // set up the new one
    }

    public void Tick() => _current?.Tick();
}

Each state owns its own behavior and decides when to hand off:

public class PatrolState : IState
{
    private readonly Enemy _enemy;
    private readonly StateMachine _fsm;
    public PatrolState(Enemy e, StateMachine fsm) { _enemy = e; _fsm = fsm; }

    public void Enter() => _enemy.PlayAnim("Walk");
    public void Exit()  { }

    public void Tick()
    {
        _enemy.FollowWaypoints();
        if (_enemy.CanSeePlayer())
            _fsm.ChangeState(new ChaseState(_enemy, _fsm));   // transition
    }
}

The payoff is the same as the Animator's: adding an AttackState doesn't touch the others, each state's logic lives in one place, and the transitions are explicit calls you can read. It's the code cousin of the animation FSM — same mental model, applied to gameplay.

💡 When to graduate to it. One or two modes? A simple enum and a switch is fine — don't over-engineer. Reach for the State pattern when the number of modes, per-mode data, and transition rules grow past what a single switch can hold clearly. That inflection point is where it earns its indirection.

Service Locator

The Service Locator is a central registry that hands out shared services on request. You met it in Lesson 1.2 as DI's compromised cousin; here's the pattern itself, stated plainly, plus when it's a legitimate choice.

public static class ServiceLocator
{
    private static readonly Dictionary<Type, object> _services = new();

    public static void Register<T>(T service) => _services[typeof(T)] = service;

    public static T Get<T>()
    {
        if (_services.TryGetValue(typeof(T), out var s)) return (T)s;
        throw new InvalidOperationException($"No service registered for {typeof(T).Name}");
    }
}

// Register once at startup (the composition root):
ServiceLocator.Register<IAudioService>(new AudioService());

// Fetch anywhere:
ServiceLocator.Get<IAudioService>().Play("footstep");

Its appeal is real: minimal wiring, easy to add to an existing codebase, and — crucially, unlike a raw singleton — consumers depend on IAudioService, so implementations remain swappable and fakeable.

Event Bus

The Event Bus (a.k.a. message bus) is the decoupling powerhouse. A publisher raises an event without knowing who — if anyone — listens; subscribers react without knowing who raised it. When the player dies, one Publish(new PlayerDied()) can update the UI, stop the music, trigger a respawn timer, and record analytics — none of those systems aware of each other or of the player.

public interface IEvent { }

public static class EventBus
{
    private static readonly Dictionary<Type, Delegate> _handlers = new();

    public static void Subscribe<T>(Action<T> handler) where T : IEvent
    {
        _handlers.TryGetValue(typeof(T), out var d);
        _handlers[typeof(T)] = (Action<T>)d + handler;   // combine delegates
    }

    public static void Unsubscribe<T>(Action<T> handler) where T : IEvent
    {
        if (_handlers.TryGetValue(typeof(T), out var d))
            _handlers[typeof(T)] = (Action<T>)d - handler;
    }

    public static void Publish<T>(T evt) where T : IEvent
    {
        if (_handlers.TryGetValue(typeof(T), out var d))
            ((Action<T>)d)?.Invoke(evt);                 // fan out to all subscribers
    }
}

// An event is just a data payload:
public struct PlayerDied : IEvent { public int Score; }

// Many unaware subscribers:
EventBus.Subscribe<PlayerDied>(e => ui.ShowGameOver(e.Score));
EventBus.Subscribe<PlayerDied>(e => audio.StopMusic());

// One publisher, ignorant of all of them:
EventBus.Publish(new PlayerDied { Score = 4200 });

One Publish fans out to every subscriber. Here's that fan-out drawn out — the shape that makes the bus worth its indirection:

Choosing Between Them

Patterns are tools, not trophies. A quick decision guide:

• Need to queue, log, undo, or replay actions? → Command.
• An object's behavior switches by mode and the branching is sprawling? → State.
• Many systems need a shared service and you accept hidden dependencies for less wiring? → Service Locator (but prefer DI for your own code).
• One change must notify many unrelated systems? → Event Bus.

They compose. The Module 1 mini-project (Lesson 1.5) wires services through a container (DI/locator hybrid), and a real game would layer a State machine for game flow and an Event Bus for cross-system notifications on top. The goal is never "use all the patterns" — it's to recognize the pressure and reach for the shape that relieves it.

Hands-on Challenge

Summary

🚀 What's Next?

You now have the full Module 1 toolkit: assemblies, dependency injection, async/await, and a vocabulary of patterns. Time to build something that uses them together. In Lesson 1.5: A Game Bootstrapper with a Service Container (Mini-Project), you'll assemble a real boot sequence — a container registering services behind interfaces, initialized in order with Awaitable, then loading the main scene.