How Games Work
Here's what you're about to build:
You've been building Coin Quest all course long — a hero, a coin pouch, a
backpack, a shop gate, an add_coins function. Time to put them together into
something you can actually play.
A game is a flipbook
Draw a stick figure on a page. On the next page, draw it slightly lower. Flip between them fast and the figure falls.
That's a game. A picture, then a slightly different picture, over and over. Each picture is called a frame. Coin Quest draws 20 frames every second.
Two questions, twenty times a second
To make each frame the computer asks you two questions:
- What changed? The hero moved a bit. A rock got closer. That's
update. - What does it look like now? That's
draw.
You write those two answers as functions, and the computer asks them forever:
update -> draw -> update -> draw -> update -> draw -> ...
You do not write the loop. That's the surprising part. You just answer the two questions, and the game engine does the asking.
The state
Between frames, the game has to remember things: where the hero is, how many coins you've got, whether you're still alive. All of that lives in one dictionary called the state — exactly like the hero dictionary you built in the Dictionaries chapter.
update gets the state, changes it, and hands it back. draw gets the state
and turns it into a picture.
The picture
The picture is a grid of coloured squares — the same __grid__ you painted
pixel art with. The track is 40 squares wide and 14 squares tall.
You get these for free in every Coin Quest exercise:
| Name | What it is |
|---|---|
blank_grid() | a fresh empty track, sky above, dirt below |
WIDTH | 40 — how many squares across |
HEIGHT | 14 — how many squares down |
GROUND | 12 — the row the hero stands on |
Keys
update also gets a second thing: keys, telling you what's held down right
now.
Check yourself
state = {"y": 0}
state["y"] = state["y"] + 3Ready? Let's draw a hero.