The Game Loop and Delta Time

Learn what a game loop is: a repeating update-then-render cycle scaled by delta time.

What you will learn

Explain what a game loop is and why games need one
Describe the update/render split
Explain what delta time is and why games use it instead of a fixed step per frame
Trace through several iterations of a simple loop by hand

The idea

A game is not a program that runs once and stops - it is a program that runs the same cycle over and over, many times per second: check what happened, update the world a little, draw the new picture. That repeating cycle is called the game loop.

Why does this matter?

Without a loop, nothing in a game would move. A web page reacts to events (a click, a submit) and then goes quiet. A game must keep moving even if the player does nothing - enemies walk, timers tick, the ball falls. Only a loop that keeps running can do that.

A real-world analogy

Think of a flipbook animation. Each page is a tiny bit different from the last. Flip pages fast enough (say, 60 per second) and it looks like smooth motion. The game loop is the hand flipping pages: on every 'page' (frame) it nudges the world forward (update) then draws it (render).

See it in code

A minimal game loop shape (conceptual, no browser APIs)

function update(state, deltaTime) {
  // move things, check timers, apply rules
  state.playerX += state.playerSpeed * deltaTime;
  return state;
}

function render(state) {
  // draw the current state (pretend - this just describes it)
  console.log(`Player is at x=${state.playerX}`);
}

function gameLoop(state, deltaTime) {
  const nextState = update(state, deltaTime);
  render(nextState);
  return nextState;
}

Line by line

function update(state, deltaTime) {
update() is where the world changes: positions move, health drops, timers count down. It takes the current state and how much time passed.
state.playerX += state.playerSpeed * deltaTime;
Movement is speed multiplied by time passed, not a fixed number every frame - this is the heart of delta time.
function render(state) {
render() only looks at the current state and draws it. It never changes game rules - drawing and simulating are kept separate.
function gameLoop(state, deltaTime) {
The loop itself just calls update then render, in that order, forever (in a real game, driven by the browser's animation frame callback).

What do you think happens?

Why do games separate 'update' (change the world) from 'render' (draw the world) into two distinct steps?

Have a guess before you read on. Guessing wrong is part of learning it.

Try it yourself

Trace this by hand: state.playerX starts at 0, playerSpeed is 50. Call update three times with deltaTime 0.1 each time. What is playerX after each call? (Answer: 5, 10, 15.)

Worth knowing

Common mistake: moving things by a fixed amount per frame (e.g. 'always add 5') instead of speed * deltaTime. That makes the game run at wildly different speeds on a fast computer (many frames per second) versus a slow one. Delta time keeps motion consistent regardless of frame rate.

The proper words for it

game loop: The repeating update-then-render cycle that keeps a game running over time.
update: The step where game rules and simulation run: movement, collisions, scoring.
render: The step where the current state is drawn to the screen, with no rule-changing logic.
delta time (dt): The amount of time, in seconds, that passed since the last update - used to scale movement so it is frame-rate independent.

Where you'll meet this

Every real-time game engine - Unity, Godot, a browser canvas game - is built around this exact update/render/delta-time pattern. Even non-game software like animation tools and simulations borrow it.

Lesson recap

A game loop repeatedly updates the world, then renders it, many times per second
update() changes game rules and state; render() only draws the current state
Delta time is how much real time passed since the last update, used to scale movement
Using speed * deltaTime keeps games running at the same real-world speed regardless of frame rate