State in games

The Fundamentals track defines state as "the data right now, which instructions change over time." In a game that definition becomes concrete fast. State is not an abstract idea — it is the list of variables that, taken together, fully describe the game at this instant.

If you could pause a game, read every variable in memory, and then recreate the game from those values alone, you would have an exact snapshot. That snapshot is game state. Nothing else matters. The screen, the sounds, the animations — all of those are generated from state at render time. They are not state themselves.

What lives in game state

A minimal game has at least these categories of state:

Position state. Where things are. A player at (x=120, y=300). An enemy at (x=400, y=150). Projectiles at various coordinates. Positions change in the update step and are read in the render step.

Status values. Health, lives remaining, ammunition, stamina. These are integers or floats. They change when rules fire — a collision costs one life, picking up a power-up restores health.

Score and timers. A running integer that increments when conditions are met. A countdown in milliseconds that decreases each frame by the elapsed time.

Flags. Booleans that track modal state: is the game paused? Is the player invincible for the next 2 seconds? Has the player reached the exit? Flags are the cheapest way to represent "something happened."

# A snapshot of game state for a simple game
player_x = 120
player_y = 300
player_health = 3
score = 0
is_invincible = False
invincible_timer = 0
running = True

These are just variables. That is the point. Game development is not magic — it is the disciplined management of variables over time.

The loop as a state machine

Each pass through the game loop is one tick of a state machine:

1. Input phase reads events and translates them into potential state changes — "the player pressed right" might set moving_right = True.
2. Update phase applies rules to the current state and produces the next state — player_x += speed if moving_right is true, then collision checks, then win/lose checks.
3. Render phase reads state and produces pixels — "draw the player sprite at (player_x, player_y)."

The render phase is a pure function of state. Given the same state, it always produces the same image. This is why many game engines can replay a match from a saved state log — they just feed the same inputs into the same state machine and get the same frames back out.

The screen is not state

This is worth saying explicitly because it trips up beginners. Moving a rectangle on screen does not store anything. When you call pygame.draw.rect, you are painting pixels into a buffer. The next frame, screen.fill() erases all of it. The position variables are what persist. The drawing is disposable.

A common mistake is trying to "read" information from the screen — checking what colour a pixel is to determine what something is. Never do this. If you need to know where the player is, read player_x and player_y. State is the source of truth.

Where to go next

Next: player input — reading keyboard events to let the player control the state directly, and understanding the difference between discrete key presses and continuous held keys.