Game State Management
A game is more than its action: there is a title screen, the play itself, a pause, and a game over. Each of these is a state, and a game spends its life moving between them. Managing those states cleanly, rather than with a tangle of boolean flags, is what keeps a game understandable as it grows. This article covers game states, a simple state machine, and how the score and lives within a state are tracked.
The Breakout demo uses these phases, and the idea connects to the state management example.
What you'll learn
What game state is
State is simply everything the game needs to remember at a given moment.
Two kinds of state
There are two layers worth separating. The high level state is which screen the game is on, the menu, the action, the game over screen. The low level state is the detail within play: the score, the lives, the positions of objects. Confusing the two, or mixing them into one pile of variables, is the source of most messy game code.
Screens and scenes
Each screen behaves so differently that it deserves to be treated as its own mode.
One game, several modes
On the menu, the loop draws a title and waits for a start; in play, it runs the full simulation; on game over, it shows a result and waits for a restart. Treating each as a named scene, with its own update and draw behaviour, keeps each one simple instead of wrapping every line in conditions.
A simple state machine
A single variable naming the current state is enough to start.
One variable, clear rules
var state = "menu"; // "menu" | "playing" | "gameover"
function update() {
if (state === "menu") { if (startPressed) state = "playing"; }
else if (state === "playing") { runGame(); if (lives <= 0) state = "gameover"; }
else if (state === "gameover") { if (startPressed) reset(state = "playing"); }
}The loop reads the state to decide what to do, and transitions are explicit changes to that variable. This is a state machine in its simplest form, and the same pattern underlies the structured separation larger apps use.
State within play
Inside the playing state lives the data the action needs.
Score, lives, and the world
Score, lives, the level, and every object position are the low level state the simulation reads and writes each frame. Keeping this as a clear set of variables, or one game object, means the renderer can draw the current state and the loop can advance it without ambiguity, the same single source of truth idea as the state management example.
Clean transitions
Moving between states is where bugs love to hide.
Reset on entry
When the game enters a state, it should set up cleanly: starting play resets the score, lives, and object positions so a new game does not inherit the last one. Doing this reset at the moment of transition, rather than scattering it around, keeps states independent and replayable. The phases a hit or a loss triggers tie back to collision detection.
Common pitfalls
State management has a few recurring traps.
What usually goes wrong
The most common is a sprawl of boolean flags, isPaused, isGameOver, isMenu, that can contradict each other; one state variable cannot. The second is forgetting to reset on transition, so a new game keeps the old score or a half dead player. The third is running game logic on the menu or game over screen because the loop did not check the state first. The loop that reads this state is in game loop fundamentals.
Frequently Asked Questions
What is game state?
Game state is everything the game needs to remember at a moment. It has two layers: the high level screen the game is on, such as menu or playing, and the low level detail within play, such as score, lives, and object positions.
What is a game state machine?
It is a single variable naming the current state, with explicit rules for moving between states. The loop reads the variable to decide what to do, and transitions are clear changes to it, which avoids contradictory boolean flags.
How should I handle menus and game over screens?
Treat each as its own named scene with its own update and draw behaviour, selected by the state variable. The loop checks the state first, so game logic only runs during play and not on the menu or game over screen.
Why does my new game keep the old score?
You are not resetting on transition. When the game enters the playing state, reset the score, lives, and positions at that moment, so a new game starts clean instead of inheriting the previous one.
Read next: multiplayer game netcode, or the Game Development hub.