The Game Loop

Every game, from Pong to Elden Ring, is built around one loop that runs many times per second. Each pass through the loop produces one frame — one still picture. Show 60 of them a second and your brain sees motion, like a flipbook.

Input → Update → Render

1. Process input — what keys, buttons or touches are active right now?
2. Update — advance the simulation one step: move things, apply physics, check collisions, run AI.
3. Render — clear the screen and draw the whole world in its new state.

function gameLoop(now) {
  const input = readInput()      // 1. what is the player doing?
  update(input)                  // 2. change the world's state
  render()                       // 3. draw the world
  requestAnimationFrame(gameLoop) // ask the browser to call us again next frame
}
requestAnimationFrame(gameLoop)

requestAnimationFrame is the browser’s way of saying “call me right before the next screen refresh” — usually 60 times a second, or 120/144 on fast monitors. Game engines run their own version of this loop for you.

Redraw everything, every frame

Unlike a web page, where you change one DOM element and the browser repaints just that, a game typically clears the whole canvas and draws every object again each frame. It sounds wasteful, but GPUs are built for exactly this, and it keeps the code simple: the picture is always a pure function of the current state.

The frame budget

At 60 FPS you have 1000 / 60 ≈ 16.7 ms to do all input, update and rendering work. At 144 FPS it’s under 7 ms. That’s why games care so much about performance: anything slow (loading a file, a big allocation, a long loop) inside the frame causes a visible hitch.