Imagine you’re building a simple game. Your character moves across the screen, enemies spawn, and the score updates. So you write code that waits for user input and then updates the game.
But something feels off: the character only moves when you press a key. Enemies stop between inputs. Everything “pauses” the moment the player does. The game feels broken.
That’s because traditional programs are often event-driven. They wait for something to happen, respond, and then wait again. Games can’t afford that. Enemies must keep moving even when the player is idle. Physics has to run continuously. Animations should stay smooth.
The Game Loop Pattern fixes this by running a continuous loop that, on every frame, processes input, updates the game state, and renders the result whether or not the player does anything.
The Game Loop Pattern continuously cycles through three phases: processing input, updating the game world, and rendering the current state to the screen.
The key insight is that real-time applications must progress even without external events. Unlike web servers that respond to requests, games must actively drive their own simulation forward.
This pattern was first formalized in game development but has spread to simulations, real-time visualizations, animation frameworks, and any system that needs continuous, time-based updates.
But why not just use event handlers and timers?
Consider building a simple game with traditional event-driven programming:
This approach has several problems:
The game only advances when something happens. If the player stops pressing keys, everything pauses. Enemies stop moving. Projectiles hang mid-air.
Timer-based updates fire at intervals, but the actual execution time varies. Heavy processing can cause timers to back up or skip entirely.
The time between renders depends on event frequency. Fast input means fast updates. Slow input means choppy visuals. The experience varies wildly.
Game logic gets scattered across different event handlers. Coordinating updates between player movement, enemy AI, physics, and rendering becomes a nightmare.
Different platforms handle events and timers differently. A game that runs smoothly on one machine stutters on another.
The pattern centralizes all updates into a single, continuously running loop:
Read all pending input from keyboard, mouse, network, or other sources. Store it for processing but don't act on it yet.
Input handling is non-blocking. The loop checks what input is available right now, stores it, and moves on. It never waits for the user to do something.
This decouples game progress from user action. The world keeps moving even when the player is idle.
Apply the input. Run AI. Simulate physics. Update positions, health, scores. This is where the game world advances by one "tick."
This is the "simulation" step. Every game entity advances by one time step:
The update phase should be deterministic. Given the same state and input, it produces the same result. This enables features like replays and network synchronization.
Draw the current state of the world to the screen. This happens after the world is fully updated, ensuring a consistent frame.
The loop then repeats. Fast machines run more iterations per second. Slow machines run fewer. But the structure remains the same.
Transform the game state into pixels on screen. This phase is read-only. It does not modify game state, only visualizes it.
Separating render from update means you can skip frames if the machine is too slow. The game simulation stays accurate even if the visuals drop frames.
The Game Loop Pattern is not just for games. Any system that needs continuous, real-time updates can benefit:
Scientific simulations, traffic modeling, and weather prediction all run continuous update loops. They advance simulated time regardless of wall-clock time.
CSS animations, motion design tools, and video editors use game loops to preview animations in real-time.
Stock tickers, server monitoring dashboards, and live analytics tools continuously fetch data, process it, and render updates.
Digital audio workstations and synthesizers run tight loops to generate audio samples in real-time. Missing a deadline means audible glitches.
Autonomous vehicles, drones, and industrial robots run control loops that read sensors, compute actions, and send commands to actuators.