Game Loop Fundamentals

Written by Backbone Tutorials Team

Last updated: June 2026 · 8 min read

Every game, from Pong to a modern engine, runs the same heartbeat: a loop that repeats many times a second, and on each pass it reads input, advances the world a little, and draws the result. Get this loop right and everything else has a place to live. This article explains the game loop, how to drive it with requestAnimationFrame, and why delta time keeps a game running at the same speed on every machine.

The playable Breakout demo runs exactly this loop, so read here and watch it there.

What a game loop is

A game is not a single drawing but a sequence of them, shown fast enough to look like motion.

A loop, not a script

The game loop is a cycle that runs continuously while the game is open. On every pass, called a frame, it updates the position of everything and redraws the screen. Because it repeats roughly sixty times a second, the eye sees smooth movement rather than a series of stills. This is the single structure that separates a game from a static page.

Driving it with requestAnimationFrame

The browser provides a function built for exactly this purpose.

The right timer for animation

function loop() {
  update();
  draw();
  requestAnimationFrame(loop); // schedule the next frame
}
requestAnimationFrame(loop);

requestAnimationFrame asks the browser to run your loop just before the next repaint, in step with the display. It pauses in background tabs and avoids the wasted work a fixed setInterval would cause, which is why it is the correct choice over a timer.

Input, update, render

Each frame does three jobs in a deliberate order.

The three phases

First the loop reads the current input state, such as which keys are held. Then it updates the world: move the ball, apply physics, check collisions. Finally it renders the new state to the canvas. Keeping these phases separate, rather than drawing in the middle of updating, keeps the loop predictable and easy to reason about.

Delta time and frame rate

Not every device runs at the same speed, and a naive loop punishes the slow ones.

Moving by time, not by frame

var last = 0;
function loop(now) {
  var dt = (now - last) / 1000; // seconds since last frame
  last = now;
  ball.x += ball.speed * dt;    // speed in pixels per second
  draw();
  requestAnimationFrame(loop);
}
requestAnimationFrame(loop);

If you move objects by a fixed amount per frame, the game runs faster on a 120 Hz screen than a 60 Hz one. Multiplying movement by delta time, the seconds elapsed since the last frame, makes speed consistent everywhere.

Fixed versus variable steps

There are two ways to advance the simulation, and each has a place.

Choosing a stepping strategy

A variable step advances by whatever delta time occurred, which is simple and fine for many games. A fixed step advances the simulation in constant slices regardless of frame rate, which makes physics stable and repeatable, important for collisions and networked play. Many games use a fixed step for simulation and render whenever they can, a pattern worth adopting once a game grows beyond the basics.

Common pitfalls

A few loop mistakes cause most early frustration.

What usually goes wrong

The most common is ignoring delta time, so the game speed depends on the device. The second is doing heavy work every frame, such as creating objects in the loop, which causes stutter; allocate once and reuse. The third is using setInterval instead of requestAnimationFrame, which drifts out of step with the display and wastes battery. The phases that run inside this loop are detailed in game state management.

Read next: canvas 2D rendering, or the Game Development hub.