One cycle, repeated
Every real-time game is built around a loop that never really finishes until you quit. Each trip around it does three jobs in order:
- Input: check what the player is doing, such as which buttons are down or where the stick is pointing.
- Update: move the world forward a small step based on that input and the game’s rules.
- Draw: produce a picture of the new state and show it.
One full trip is a frame. A game that runs at 60 frames per second repeats this cycle 60 times each second. Everything you see as smooth motion is really a quick series of still images, each one slightly different from the last.
What each step does
Input
The game collects the current state of the controller, keyboard, mouse or touch screen. It does not usually act on this immediately. It stores the information so the update step can use it. Games often distinguish between a button being held and a button having just been pressed this frame, since a jump should trigger once, not on every frame the button stays down.
Update
This is where most of the logic runs. The game moves the player, advances enemy behavior, applies physics, checks collision detection, starts or stops sounds, and updates timers and scores. Each object typically gets a small chance to change itself. The order can matter: if the player moves before the enemy decides what to do, the enemy reacts to the new position, whereas the opposite order has the enemy reacting one frame late.
Draw
Finally the game sends instructions to the graphics hardware to render the scene: background, characters, effects and the on-screen interface. The result is held until the next screen refresh. The draw step normally reads the game state but does not change it, which keeps the logic and the picture cleanly separated.
The time budget
The loop only works if it finishes quickly. At 60 frames per second, each frame has about 16.7 milliseconds (1000 divided by 60). At 30 frames per second the budget is about 33.3 milliseconds. If input, update and draw together take longer than the budget, the frame arrives late, and the player sees a hitch or a lower frame rate.
Suppose a hypothetical frame spends 2 milliseconds on input and setup, 6 on update and 7 on drawing, for 15 milliseconds in total. That fits inside 16.7 with a little room to spare. If a crowded scene pushes the draw step to 12 milliseconds, the total becomes 20, which is over budget, and the game can no longer hold 60 frames per second. Finding which step grew is exactly what performance profiling does.
Waiting for the display
Most games also wait for the screen’s refresh before showing a new frame, a setting often called vertical sync. If the game finishes early, it idles until the next refresh instead of drawing frames that will never be seen. If it finishes late, it either shows the previous image again or, without syncing, may show a torn image where two frames are mixed. Many games offer options for this among their graphics settings.
Fixed versus variable time steps
The update step needs to know how much time has passed, because a character moving at 5 meters per second should cover that distance in a second whether the game runs fast or slow.
Variable time step. The game measures how long the last frame took and scales all movement by that amount. A frame that took 20 milliseconds moves things 20 milliseconds’ worth. This is simple and adapts to slow machines, but results can vary slightly depending on frame length, and unusually long frames can cause large jumps that make objects pass through walls.
Fixed time step. The game always updates in equal slices, say 1/60 of a second, regardless of how long drawing takes. If a frame runs long, the game performs several updates to catch up. If it runs short, it may skip an update. Results are more consistent and easier to reproduce, which suits physics and online play, but the code is somewhat more involved.
Many games blend these: a fixed step for physics and gameplay rules, and a variable step for visuals. When drawing happens between two fixed updates, the game can smooth the picture by estimating where objects should appear between their last two positions.
Why frame rate and responsiveness differ
A high frame rate does not automatically feel responsive. Delay also depends on how long the input waits before it affects what you see. A game that reads input at the start of a frame, updates, then draws still has a chain of steps before the picture reaches the screen, and screens add their own delay. Streaming a game from a remote machine adds more, which is the focus of cloud streaming latency.
Menus, pauses and other loops
A pause does not stop the loop. It keeps reading input and drawing the menu, but the update step skips the game world. Many engines hide the loop and call your code at the right moments, but knowing it exists explains why slow code in one place slows everything.
Common loop problems
- Doing heavy work in the update step, such as loading a large file, which freezes the whole game for a moment.
- Tying movement to frames instead of time, so a game runs faster on powerful hardware.
- Letting one slow frame cascade in a fixed step design, where catching up takes longer and falls further behind. Developers usually cap the number of catch-up updates to prevent this.