The game loop
The game loop is the heartbeat of every game — a tight cycle of reading input, updating state, and drawing the result.
- Explain what a game loop is and why games need one
- Describe the three phases of a game loop — process input, update state, render
- Understand frame rate and delta time conceptually
A spreadsheet updates when you press Enter. A web page updates when you click a link. Games are different: they must update constantly, whether the player does anything or not. Enemies keep moving. Timers keep counting. Physics keeps simulating. The mechanism that makes this happen is the game loop.
The game loop is the central while True: that runs for the entire lifetime of
the program. Every frame — typically 30 to 60 times per second — the loop
executes three phases in order, then starts again.
Phase 1: Process input
The first thing each frame does is ask: "what did the player do since last frame?"
Pygame gives you two ways to answer this. The event queue collects discrete
moments — a key was pressed, the mouse was clicked, the window was resized. You
drain the queue with pygame.event.get() and handle each event. The second
approach is polling: pygame.key.get_pressed() returns the state of every key
right now, which is better for held keys like movement arrows.
Processing input does not move anything. It reads actions and stores them, or directly updates state variables. The "update" step is where state changes take effect.
Phase 2: Update state
The second phase applies the rules of the game. Given the input you just read and the current state, what is the new state?
This is where you move the player, move enemies, check whether two objects are touching, increment a timer, decrement health, or trigger a win condition. Every variable that describes the current game situation gets updated here, once per frame.
A well-structured game keeps the update logic completely separate from the drawing logic. Update changes the numbers; draw reads them and paints pixels. Never mix the two.
Phase 3: Render
The third phase draws the current state to the screen. You are not "animating" — you are painting a still image of the state as it exists right now. Because this happens 30–60 times per second, the result looks like motion.
The standard render pattern is:
- Fill the background (erase the previous frame).
- Draw everything — background, enemies, player, UI — in back-to-front order.
- Call
pygame.display.flip()to push the frame to the screen.
Drawing order matters because pygame has no concept of depth. Whatever you draw last appears on top.
Frame rate and delta time
Frame rate is how many times the loop completes per second, measured in frames
per second (FPS). At 60 FPS, each frame has about 16 milliseconds to complete all
three phases. pygame.time.Clock and its tick(60) method enforce this limit —
if the loop runs faster than 60 FPS, tick(60) pauses it; if it runs slower, it
lets it catch up.
Delta time is the time elapsed since the last frame, usually in seconds or milliseconds. If you move an object 5 pixels per frame and the frame rate drops, the object moves slower — which is wrong. If instead you move it 300 pixels per second multiplied by delta time, it moves the same real-world distance regardless of frame rate. Delta time makes your game frame-rate-independent.
For beginner projects at a fixed 60 FPS, you can skip delta time and move in pixels-per-frame. Just know the concept exists for when frame rate varies.
The three-phase structure — input, update, render — is not a pygame convention. It is universal. Unity, Godot, Unreal, and every custom engine follow the same pattern. Learning it here means you understand every game engine you will ever use.
Where to go next
Next: moving things — implementing the full game loop and using it to animate a rectangle across the screen.