Game State Machines for Scenes and Menus

The Problem With Boolean Flags

Every game moves through modes. It starts on a title screen, transitions into gameplay, pauses when the player presses escape, shows a game over screen when they lose, and returns to the title. The naive way to track this is with boolean flags: isPlaying, isPaused, isGameOver, isMenu. The update loop then checks these flags to decide what to do, and the input handler checks them to decide how to respond.

This works for about five minutes. The flags are supposed to be mutually exclusive, but nothing enforces that, so bugs creep in where two are true at once or none are, and the game ends up in an impossible state. The conditionals multiply as you add modes, and the logic for which transitions are legal gets smeared across the codebase wherever flags are flipped. You end up unable to answer basic questions like which states can lead to the game over screen, because the answer is scattered across a dozen flag assignments. The boolean approach has no concept of a single current state and no concept of allowed transitions, which are exactly the two things game flow needs.

What a State Machine Provides

A finite state machine replaces the flags with a single variable holding the current state, plus an explicit definition of the states and the transitions between them. At any moment the game is in exactly one state, which makes impossible combinations impossible by construction. Each state owns its own behavior: the playing state has its own update and render and input handling, the paused state has different ones, and the machine simply runs whichever state is current.

Transitions become explicit and controlled. Rather than flipping flags anywhere, code requests a transition to a new state, and the machine performs it, running any exit logic for the old state and entry logic for the new one. This gives you natural hooks for the work that should happen at a boundary: when entering the paused state, show the overlay and stop the timers, and when exiting it, hide the overlay and resume. The set of legal transitions lives in one place, so the structure of the game's flow is documented by the machine itself rather than inferred from scattered code.

Entry and exit actions are one of the most useful parts of the pattern. A great deal of game logic is really about boundaries between states: start the music when gameplay begins, save progress when a level ends, reset the score when a new game starts. Hanging this logic on state entry and exit, rather than sprinkling it through update code guarded by flag checks, makes it reliable and easy to find. The state machine turns the question of when something should happen into the cleaner question of which transition it belongs to.

State Machines for Game Flow

At the highest level, a state machine governs the overall flow between the big screens of the game. The states are things like Title, Playing, Paused, LevelComplete, and GameOver, and the transitions describe how the player moves between them. This top-level machine is closely related to scene management, and the two are often combined, with each major state corresponding to a scene that bundles its entities, update logic, and rendering. The state machine decides which scene is active, and the scene supplies the content for that state.

A common refinement is to let states stack rather than strictly replace each other, which is essential for overlays like a pause menu. When the player pauses, you push a Paused state on top of the Playing state instead of replacing it, so the gameplay state is preserved underneath, frozen but intact, ready to resume exactly where it left off when the pause state is popped. This stack-based variant blends the state machine with scene management to handle the layered modes that real games need.

State Machines for Entity Behavior

The same pattern works at the smallest scale, governing the behavior of individual entities. An enemy might cycle through Patrol, Chase, Attack, and Flee states, transitioning based on the player's distance and its own health. A door might be Closed, Opening, Open, or Closing. A character might be Idle, Running, Jumping, or Falling, with the state driving which animation plays. In each case the entity is always in one behavioral state, and the transitions encode the rules of how it behaves.

Entity behavior state machines are a foundational technique for game AI, where they are usually called finite state machines or FSMs. The same explicit-states-and-transitions structure that tames game flow also tames enemy behavior, which is why the pattern shows up at every level of a game. For deeper AI behavior, state machines are sometimes extended or replaced by behavior trees, which scale better to complex decision-making, but the humble state machine remains the right tool for the many cases where an entity has a handful of clear modes. Our coverage of game AI explores how these behavioral state machines and behavior trees drive NPCs in detail.

Keeping State Machines Manageable

State machines have their own failure mode: the explosion of transitions. A machine with many states can in principle have a transition between every pair, and if you try to handle them all, the machine becomes as tangled as the flags it replaced. The discipline is to keep the number of states small and the transitions meaningful, splitting a sprawling machine into smaller machines when one grows unwieldy. A character's movement state and its combat state, for example, are often cleaner as two separate small machines than one large combined one.

Events pair well with state machines as the trigger for transitions. Rather than polling conditions every frame to decide whether to change state, a state machine can transition in response to events like playerDied or levelCompleted, which keeps the transition logic clean and tied to meaningful moments. Combined with thoughtful state granularity, this keeps the machine readable as the game grows. The state machine is one of the highest-value patterns in game architecture precisely because it pays off early, the moment a game has more than one screen, and keeps paying off as both game flow and entity behavior grow more elaborate.

Hierarchical and Pushdown State Machines

The basic flat state machine, where the game is in exactly one of a list of states, covers most needs, but two extensions handle situations it struggles with. The first is the hierarchical state machine, which lets states contain sub-states. A character might be in a broad Airborne state that itself contains Jumping, Falling, and DoubleJumping sub-states. The advantage is shared behavior: logic common to all airborne states, like applying gravity, lives in the parent state, while the specifics live in the sub-states. This avoids duplicating the same transitions and behavior across several flat states, which is exactly the kind of repetition that makes a large flat machine unwieldy.

The second extension is the pushdown state machine, which replaces the single current state with a stack of states. Entering a new state pushes it onto the stack, and leaving it pops back to whatever was beneath. This is precisely the model behind a pause menu that returns you to exactly where you were, and it generalizes to any case where you need to remember and return to a previous state. An enemy that breaks off from chasing the player to investigate a noise can push an Investigate state, then pop back to Chase exactly where it left off, without having to record and restore the chase state manually.

These variants are not always necessary, and reaching for them on a simple machine is over-engineering. A flat state machine with a handful of states needs neither hierarchy nor a stack. But when you notice the same transitions repeated across many states, a hierarchical machine often cleans that up, and when you find yourself manually remembering which state to return to, a pushdown machine expresses that intent directly. They are tools to reach for when a flat machine starts to strain, the same way a quadtree is a tool to reach for when a grid strains, applied at the moment the simpler structure stops being enough.