The Game Loop & Time

01The loop and the kinds of time

A game is a loop: read input, advance the simulation, draw a frame, repeat. The whole subject of this tutorial is the middle step, advancing the simulation, and specifically how much time each advance represents. Get that wrong and everything downstream (physics, animation, networking) inherits the error.

A pause menu has to stop the world while its own buttons keep animating; bullet time has to slow the world while the HUD runs at full speed. That takes more than one clock, so it helps to separate the kinds of time an engine juggles^[1]. Real time is the wall clock. Simulation time is how far the game world has advanced, which can run slower than real time (a hitch), faster (fast-forward), or stop (pause) without the program freezing. Local time is per-system, like the playhead of one animation clip. This tutorial is about keeping simulation time correct and stable as real time does whatever the hardware makes it do.

02The naive loop

The first loop everyone writes runs at the right speed on the machine it was written on. It advances the world by a fixed amount of work per iteration, with no notion of elapsed time:

while (running) {
    pollInput();
    update();        // advances by a fixed step of WORK, not time
    render();
}

while running {
    poll_input();
    update();        // advances by a fixed step of WORK, not time
    render();
}

The simulation speed equals the loop's iteration rate, which is set by the hardware and the current load^[2]. A faster CPU runs the game faster; a slower one runs it in slow motion. It's why some early PC games became unplayably fast on later hardware.

03Variable timestep

The obvious fix for a player who jogs on one machine and sprints on another: measure how long the last frame took and scale every movement by that delta time, the real time since the previous frame, usually called dt and measured in seconds.

auto previous = Clock::now();
while (running) {
    auto now = Clock::now();
    double dt = std::chrono::duration<double>(now - previous).count();
    previous = now;
    update(dt);     // position += velocity * dt
    render();
}

let mut previous = Instant::now();
while running {
    let now = Instant::now();
    let dt = (now - previous).as_secs_f64();
    previous = now;
    update(dt);     // position += velocity * dt
    render();
}

Wall-clock speed is now consistent across frame rates, and for a lot of gameplay code this is fine. For the simulation core it brings three new failures:

• Non-determinism. Same inputs, different results. Different machines produce different dt sequences. A numerical integrator's error depends on the step size, so anything accelerating (gravity, drag, springs) lands somewhere different for a different sequence of steps, and floating-point rounding adds its own drift on top: a machine taking ten times as many steps accumulates more of it^[2].
• Large-step instability. A frame spike hands update a huge dt, and an explicit integrator (code that advances position and velocity by one finite step using only the current state) can overshoot and blow up. This is integrator-dependent: explicit Euler is fragile, while semi-implicit Euler (update velocity first, then move with the new velocity) and higher-order schemes are more forgiving^[4].
• Tunneling. A big step jumps a fast object clear past a thin wall between two discrete collision checks. A player running at 10 m/s moves 0.17 m per step at 60 Hz, less than a 0.2 m wall; a 0.25 s hitch moves them 2.5 m in one step, straight through it. That is a sampling problem, distinct from integrator instability.

04Semi-fixed: clamp the step

The spring blew up because one step was too big, so the first partial fix is to never integrate more than a maximum dt at once. If a frame took longer, take several capped steps^[3].

while (frameTime > 0.0) {
    double step = std::min(frameTime, dt);  // never exceed dt
    integrate(state, step);
    frameTime -= step;
}

while frame_time > 0.0 {
    let step = frame_time.min(dt);          // never exceed dt
    integrate(&mut state, step);
    frame_time -= step;
}

This bounds the step size, which removes large-step instability and reduces tunneling (a fast enough object still crosses a thin wall within one dt). It is still not deterministic: the last step each frame is a partial dt, so step sizes still vary frame to frame.

That trailing remainder is exactly what the accumulator pattern fixes, by deferring it instead of stepping it.

05Fixed timestep and the accumulator

To get the same simulation on every machine, every step has to be the same size, even though frames aren't. The canonical loop does it: accumulate real frame time, then consume it in whole dt chunks, carrying the leftover forward to the next frame^[3]. Every simulation step is now exactly the same size, which makes it stable and reproducible.

using Clock = std::chrono::steady_clock;     // monotonic; never wall-clock for dt
const double dt = 1.0 / 60.0;                  // fixed simulation step (seconds)
double accumulator = 0.0;
auto currentTime = Clock::now();

while (running) {
    auto newTime = Clock::now();
    double frameTime = std::chrono::duration<double>(newTime - currentTime).count();
    if (frameTime > 0.25) frameTime = 0.25;  // spiral-of-death clamp (Fiedler's example)
    currentTime = newTime;

    accumulator += frameTime;
    while (accumulator >= dt) {           // >=, not >: a full step is available
        previousState = currentState;     // keep the prior state for interpolation
        integrate(currentState, dt);       // every step is exactly dt
        accumulator -= dt;                // carry the remainder (< dt) to next frame
    }

    double alpha = accumulator / dt;       // 0..1: how far past the last step we are
    render(lerp(previousState, currentState, alpha));
}

use std::time::Instant;                        // monotonic; analog of steady_clock
let dt: f64 = 1.0 / 60.0;                     // fixed simulation step (seconds)
let mut accumulator: f64 = 0.0;
let mut current_time = Instant::now();

while running {
    let new_time = Instant::now();
    let mut frame_time = (new_time - current_time).as_secs_f64();
    if frame_time > 0.25 { frame_time = 0.25; }   // spiral-of-death clamp
    current_time = new_time;

    accumulator += frame_time;
    while accumulator >= dt {                  // >=, not >: a full step is available
        previous_state = current_state.clone();   // keep the prior state for interpolation
        integrate(&mut current_state, dt);    // every step is exactly dt
        accumulator -= dt;                    // carry the remainder (< dt) forward
    }

    let alpha = accumulator / dt;             // 0..1
    render(lerp(&previous_state, &current_state, alpha as f32));
}

Three lines carry the whole design, so be precise about each:

• while (accumulator >= dt) runs zero, one, or several steps this frame, depending on how much real time built up.
• accumulator -= dt leaves a remainder below dt in the accumulator. It is carried, not discarded. Throwing it away makes the simulation run slow.
• alpha = accumulator / dt is the fraction of a step the renderer sits past the last completed state, the blend factor for interpolation in §7.

The widget runs the same bouncing object under three loops at once:

Wrong answers, and why: zeroing the accumulator loses time (slow sim); a final partial step is the semi-fixed variant that breaks determinism; and fixed timestep constrains the simulation, not the display or vsync.

06Decoupling sim from render

A player with a 144 Hz monitor should see 144 frames a second, and a player on a 30 fps laptop should still get the same simulation. The accumulator already decoupled the two rates, so neither one dictates the other. The inner loop runs the simulation zero, one, or several times per rendered frame; rendering happens once at the end, as often as the display allows. Unity says the same about its fixed step: FixedUpdate is called "zero, one, or multiple times per frame depending on the frame rate"^[6], and Godot splits a fixed-rate _physics_process from a variable-rate _process^[10].

07Interpolation, not extrapolation

With a 60 Hz simulation on a 144 Hz display, two or three rendered frames in a row can show the same tick, then the picture jumps. Rendered frames fall between simulation states, so the picture stutters. The fix is to keep the previous and current states and blend them with alpha, the leftover accumulator divided by dt^[3].

// alpha in [0,1): how far between previous and current we are.
State shown = previousState * (1.0 - alpha) + currentState * alpha;
render(shown);

// alpha in [0,1): how far between previous and current we are.
let shown = lerp(&previous_state, &current_state, alpha as f32);  // previous*(1-alpha) + current*alpha
render(shown);

Because this blends two states that were already computed, it never invents an unphysical position. The cost is latency: the image shows a moment between the last two ticks, so it trails the newest simulated state by up to one fixed step, and real time by more. Unity describes its rigidbody interpolation this way, using "the previous two physics updates" so the body appears "to move slightly behind where it should be"^[8]; Godot's docs put the rendered position "between 1 and 2 ticks into the past"^[11].

The widget runs one ball through all three ways of drawing it:

08The spiral of death

An explosion spawns two hundred rigid bodies, and one physics step now takes 20 ms to compute against a 16.7 ms step. One failure mode of the accumulator deserves its own name, the spiral of death. If a single simulation step costs more than dt of real time to compute, each frame adds more to the accumulator than the inner loop can drain, so next frame needs even more steps, which take even longer^[3]. The loop spirals until it locks up.

There are two guards, working from opposite ends, and engines use one or both:

• Clamp the incoming frame time (the frameTime > 0.25 line). Caps how much work can enter the accumulator per frame.
• Cap the steps per frame. Bail out of the inner loop after a maximum count; "the game will slow down then, but that's better than locking up completely"^[2]. When the cap trips, drop the leftover time as well, or the accumulator keeps the debt and grows every frame. Unity's Maximum Allowed Timestep caps the simulated time per frame in the same spirit^[7].

The widget models that loop, with a frame taking exactly as long as its steps:

09Determinism

A fighting game records only the players' inputs for its replays. Played back on the same build and machine, a replay matches. On a teammate's PC built with a different compiler, a hit that landed now misses. A fixed timestep is the usual foundation for a reproducible simulation, since every run takes the same-sized steps, but it is not enough on its own.

Three sources of divergence survive a fixed step. Floating-point results differ across compilers, optimization levels, architectures, and fast-math settings (compiler modes that let the optimizer reorder and fuse float math for speed), so the same code can produce slightly different numbers on different toolchains. Float addition is not associative, so changing the order operations are summed changes the result. And input timing or sampling can differ run to run. Nystrom puts the practical consequence plainly: with variable steps "the same bullet will end up in different places on their machines"^[2]; a fixed step removes that particular variable but not the float ones.

10Timing sources

A player changes the system clock while the game runs, and physics gets a negative dt; a frame limiter calls Sleep to wait out the rest of a frame and misses the next refresh. Both come from where the loop gets its time. Measure frame time with a monotonic clock, one that never goes backward, never a wall clock.

• Use std::chrono::steady_clock in C++ and std::time::Instant in Rust. Both are monotonic and meant for measuring intervals^[13][14]. A wall clock (system_clock) can jump backward when NTP steps it or a user changes the time, and hand you a negative dt. (Daylight saving doesn't move it: system_clock counts UTC, and DST only changes how local time is displayed.)
• sleep() is not precise. On Windows the default timer granularity is about 15.6 ms, so Sleep(1) can sleep roughly 15 ms^[15]. A common approach to precise frame pacing (delivering frames at even intervals) sleeps to near the target, then spin-waits the rest, checking the clock in a tight loop.
• With vsync on, the present call blocks once the swap chain is full, until a refresh frees an image, so presentation itself paces the loop. The accumulator absorbs that cadence, and absorbs the jitter, the frame-to-frame unevenness, when a frame is dropped or repeated under load.

11Case studies

If you ship on an existing engine, it already made these choices. Knowing which ones tells you what its physics settings do and why its docs warn about the things they warn about.

12Pitfalls

13What's next

Next is Platform & Window: the loop needs a window to run in and events to pump, and that page builds them, followed by Input. The integrator inside integrate() is the subject of the Physics tutorial, which uses the fixed step you just built for its substeps. And the determinism caveats trace back to IEEE-754 Floating Point. The full path is on the series hub.

1. Jason Gregory. Game Engine Architecture, "The Game Loop and Real-Time Simulation." gameenginebook.com. The kinds of time an engine tracks and the structure of the loop. (Chapter number varies by edition; cited by title.)
2. Robert Nystrom. "Game Loop," Game Programming Patterns. gameprogrammingpatterns.com. Frame-rate coupling, fixed-update/variable-render, the step-cap guard, float divergence, and an extrapolated render first described as "interpolated."
3. Glenn Fiedler. "Fix Your Timestep!" gafferongames.com. The canonical accumulator algorithm, the 0.25 s clamp, the alpha blend, state interpolation, the semi-fixed loop, and the spiral of death.
4. Glenn Fiedler. "Integration Basics." gafferongames.com. Explicit Euler vs semi-implicit Euler vs RK4; supports scoping large-step instability to the integrator.
5. Koen Witters. "deWiTTERS Game Loop." dewitters.com. Constant-logic-rate loop with frame-skip and a forward-prediction render the article calls "interpolation."
6. Unity. MonoBehaviour.FixedUpdate, Scripting API. docs.unity3d.com. FixedUpdate "may be called zero, one, or multiple times per frame depending on the frame rate and simulation needs."
7. Unity. Fixed updates / Time settings. docs.unity3d.com. Default fixedDeltaTime of 0.02 s and the Maximum Allowed Timestep guard.
8. Unity. Apply interpolation to a Rigidbody. docs.unity3d.com. Interpolation blends the previous two physics updates and renders slightly behind; extrapolation predicts ahead.
9. Epic Games. Physics Sub-Stepping in Unreal Engine. dev.epicgames.com. Variable tick with Max Substep Delta Time and Max Substeps bounding the physics step.
10. Godot. Idle and Physics Processing. docs.godotengine.org. Fixed-rate _physics_process (default 60 Hz) vs variable-rate _process.
11. Godot. Physics interpolation introduction. docs.godotengine.org. Blending current and previous transforms, which places the drawn object "between 1 and 2 ticks into the past."
12. Valve. Source Multiplayer Networking. developer.valvesoftware.com. "Discrete time steps called ticks," a 15 ms default step (66.67 ticks/sec) decoupled from frame rate.
13. cppreference. std::chrono::steady_clock. en.cppreference.com. A monotonic clock with constant tick spacing, "most suitable for measuring intervals."
14. Rust. std::time::Instant. doc.rust-lang.org. Monotonic now() and elapsed(); Duration::as_secs_f64 for seconds.
15. Bruce Dawson. "Windows Timer Resolution: The Great Rule Change." randomascii.wordpress.com. The default ~15.6 ms timer granularity and timeBeginPeriod.
16. winit. ApplicationHandler. rust-windowing.github.io. Render in response to WindowEvent::RedrawRequested, not about_to_wait; ControlFlow::Poll for games.