Game loop, update method and components

A game loop runs for as long as the game does: on every pass it reads input, advances the simulation and draws a frame. The Update Method gives every object in the world one update call per step of that loop, so each object simulates its own behaviour. Components split those objects into small parts, such as a position, a sprite or an AI, that can be combined freely instead of inherited from a deep class tree. Two smaller patterns keep the loop cheap and correct: a dirty flag recomputes derived data only after its inputs change, and a double buffer lets every update read the last state while it writes the next. The game loop’s most important decision is the timestep: advancing the simulation in fixed steps, whatever the frame rate, makes it repeatable and testable. The same patterns run simulations, dashboards and user interfaces.

Fixed steps make the simulation repeatable

Frames do not take the same time. A phone that renders 60 frames a second in a menu may render 20 in a busy scene, and a background tab may pause for a second. If each update moves the world by the last frame’s duration, the simulation itself changes with the frame rate. The fix is to decouple the two: the frame’s real time goes into an accumulator, and the simulation consumes it in steps of one fixed size.

Engines build this in. Godot’s documentation describes _process(), called every frame at whatever rate the device manages, and _physics_process(), called at a fixed rate, 60 times per second by default, independent of the frame rate. This program shows why, with a ball that falls for one second at 60 and at 20 frames per second:

"""A ball falls for one second under gravity, simulated at two frame rates. With a variable timestep, each frame
moves the simulation by that frame's duration, so the result depends on the frame rate. With a fixed timestep, the
frame time goes into an accumulator and the simulation advances in steps of exactly 10 ms, so both frame rates give
the same answer. Frame times are whole milliseconds to keep the arithmetic exact."""

G = 9.81  # metres per second squared
SMOOTH = [16, 17, 17] * 20  # 60 frames in 1,000 ms
SLOW = [50] * 20  # 20 frames in 1,000 ms


def variable_timestep(frame_times_ms):
    y = v = 0.0
    for frame_ms in frame_times_ms:
        dt = frame_ms / 1000
        v += G * dt
        y += v * dt
    return y


def fixed_timestep(frame_times_ms, step_ms=10):
    y = v = 0.0
    accumulator = steps = 0
    for frame_ms in frame_times_ms:
        accumulator += frame_ms
        while accumulator >= step_ms:  # as many 10 ms steps as the frame's time allows
            v += G * step_ms / 1000
            y += v * step_ms / 1000
            accumulator -= step_ms
            steps += 1
    return y, steps


print(f"variable timestep: fell {variable_timestep(SMOOTH):.3f} m at 60 fps, {variable_timestep(SLOW):.3f} m at 20 fps")
(a, n), (b, m) = fixed_timestep(SMOOTH), fixed_timestep(SLOW)
print(f"fixed 10 ms steps: fell {a:.3f} m at 60 fps, {b:.3f} m at 20 fps ({n} and {m} steps); same: {a == b}")
print(f"exact answer: {G / 2:.3f} m")

variable timestep: fell 4.987 m at 60 fps, 5.150 m at 20 fps
fixed 10 ms steps: fell 4.954 m at 60 fps, 4.954 m at 20 fps (100 and 100 steps); same: True
exact answer: 4.905 m

With a variable timestep the ball fell 4.987 m at 60 frames per second and 5.150 m at 20: the same second of game time gave two different worlds, so a slow phone plays a different game. With fixed 10 ms steps, both frame rates ran 100 steps and the ball fell exactly the same 4.954 m. Neither matches the exact 4.905 m, which is the numerical error of the step size, but the fixed version is wrong in the same way on every machine, which is what tests, replays and multiplayer games need. With the update method on top of that loop, each entity updates once per fixed step, and with components, which parts an entity has decides which updates it gets.

The spiral of death, and capping the catch-up Pro: opens with a Pro, Premium or Ultimate pass