Fixed vs Variable Timestep

The Core Difference

The timestep is the amount of simulated time the game advances in a single update. With a variable timestep, that amount is whatever real time elapsed since the last frame, so on a fast machine the game takes many small steps and on a slow machine it takes fewer large ones. With a fixed timestep, the game always advances by the same amount, for example one sixtieth of a second, no matter how often the screen actually refreshes. If real time has accumulated faster than the simulation, the loop simply runs several fixed steps in a row to catch up.

This distinction sounds academic until you realize that it decides whether your game behaves the same way everywhere. A variable timestep means the simulation's results depend on frame timing, which depends on the hardware, the browser, and whatever else the machine is doing. A fixed timestep makes the simulation independent of all of that. The same sequence of inputs produces the same result on a flagship phone and a five-year-old laptop, because both run the identical fixed steps in the identical order.

Why Variable Timesteps Cause Bugs

Variable timesteps fail in three characteristic ways, and each one is a real bug that has shipped in countless games.

The first is unstable physics. Physics integration accumulates small errors, and the size of those errors depends on the step size. Large, irregular steps make the errors larger and inconsistent, so a character's jump height, a projectile's arc, or a stack of boxes can behave differently at thirty frames per second than at sixty. Spring forces and constraints are especially fragile and can even explode into instability when fed an unexpectedly large step. Physics engines are tuned to expect a consistent step size, which only a fixed timestep guarantees.

The second is tunneling. When a single frame takes unusually long, perhaps because the garbage collector paused or the browser was busy, a variable timestep produces one enormous step. A fast-moving object advanced by that huge step can leap clear past a wall or a platform in a single update, and the collision check, which only looks at the object's position after the step, never sees the overlap. The object passes through solid geometry. A fixed timestep prevents this because it caps each simulation step at a small, known size, splitting a long frame into several safe small steps instead of one dangerous large one.

The third is non-determinism. Floating-point math combined with variable step sizes means two runs of the same inputs never quite match. This breaks any feature that depends on the simulation being reproducible, including replay recording, spectator modes, and the lockstep networking model where each client runs the same simulation and only shares inputs. These features require that the simulation be a pure, deterministic function of its inputs, which is only achievable with a fixed timestep.

The Accumulator Pattern

The standard way to implement a fixed timestep is the accumulator. Each frame, you add the real elapsed time to a running accumulator. Then, while the accumulator holds at least one fixed step's worth of time, you run a single fixed simulation step and subtract that step's duration from the accumulator. When the accumulator holds less than a full step, you stop and render. Whatever fraction of a step remains in the accumulator is carried over to the next frame, so no time is lost or invented.

This approach decouples the simulation rate from the render rate completely. On a 144 hertz display, the simulation still runs at its fixed sixty steps per second, but rendering happens 144 times per second. On a slow frame, the accumulator builds up and the loop runs two or three simulation steps to catch up before rendering. The simulation always experiences uniform time, while rendering adapts to whatever the display and hardware can deliver.

One detail prevents a failure mode called the spiral of death. If each simulation step takes longer than the fixed step it represents, the accumulator grows faster than the loop can drain it, the loop runs ever more steps trying to catch up, and the game freezes solid. The fix is a clamp: cap the number of simulation steps allowed per frame, or cap the maximum real time added to the accumulator each frame. When the machine simply cannot keep up, the game slows down gracefully instead of locking up entirely.

Interpolation for Smooth Rendering

A fixed timestep introduces one visual subtlety. Because the simulation advances in discrete slices that are not aligned with the moments the screen refreshes, rendering the raw simulation state can produce slight stutter, since the displayed positions jump by whole steps. The solution is interpolation. You keep each object's previous and current simulation positions, and when rendering, you blend between them according to how far the accumulator has progressed toward the next step. The result is buttery smooth motion on any refresh rate, even though the simulation itself ticks at a fixed rate.

Interpolation is what makes the fixed timestep practical rather than a tradeoff. Without it, a sixty hertz simulation shown on a 144 hertz monitor would look slightly choppy. With it, the same simulation renders perfectly smoothly because the renderer is showing the in-between positions the simulation never actually computed. This separation, a fixed-rate simulation feeding an interpolated variable-rate renderer, is the architecture that high-quality games converge on.

When a Variable Timestep Is Fine

None of this means a variable timestep is always wrong. For games without meaningful physics, where motion is simple and nothing depends on exact reproducibility, a variable timestep multiplied by delta time is perfectly adequate and simpler to write. A point-and-click adventure, a turn-based puzzle, a card game, or a calm exploration game with basic movement will never encounter the bugs that fixed timesteps prevent, because they have no fast objects, no constraint physics, and no determinism requirements.

The decision comes down to what the game does. If it has real-time physics, fast-moving objects, networked play, or any need for deterministic replay, use a fixed timestep with the accumulator and interpolation from the start, because retrofitting it later means reworking the entire simulation. If it has none of those, a clean delta-time loop is a reasonable and simpler choice. As with most architecture, the goal is to match the structure to what the game genuinely needs, neither cutting a corner that will hurt nor adding machinery that earns nothing.

Choosing Your Step Size

Once you commit to a fixed timestep, you have to pick how big each step is, and the choice involves a real tradeoff between accuracy and cost. A common default is sixty steps per second, matching the most common display refresh rate, which keeps the simulation smooth and the per-step time small enough that physics stays stable for most games. Many games use this rate and never need to think about it further.

Some situations call for a different rate. Games with fast collisions or precise physics sometimes run the simulation faster than sixty steps per second, perhaps 120, so that fast objects move a smaller distance per step and are less likely to tunnel or interpenetrate before collisions are resolved. The cost is that the simulation runs more often, consuming more of the frame budget, so a higher step rate trades CPU time for accuracy. Conversely, a game with simple, slow movement can run the simulation at a lower rate, such as thirty steps per second, freeing budget for rendering, as long as the lower rate does not make motion feel sluggish or coarse.

The key point is that the simulation rate is independent of the display rate, which is the whole benefit of separating them. You can run the simulation at exactly the rate the gameplay needs for stability and accuracy, while interpolation ensures rendering stays smooth at whatever rate the display refreshes. Pick the simulation rate based on what the physics and gameplay require, measure whether the per-step cost fits the frame budget across your target devices, and let interpolation handle the visual smoothness on top. That separation is what makes the fixed timestep both correct and flexible.