A timestep (commonly represented as `dt` or `deltaTime`) is the amount of in-game time that elapses between two discrete updates of a piece of the game's internal state, or the duration that an update operation is meant to model. Timesteps arise in game loops, physics simulations, animation timelines, interpolation, and other systems modeling change over time.
Timesteps in games fall into two broad categories: variable and fixed.
Variable timesteps
Sometimes a game system needs to be evaluated at uneven intervals, for instance:
when using a lockstep game-loop like
read-input-->update-->render, differences in the player's hardware or the update and rendering workload within a scene can cause the loop to execute faster or slower, leading to an inconsistent framerate.when a group of low-priority behaviours or tasks are placed in queue and updated a few at a time as the system has time to spare, the duration between successive updates can vary.
If the same update logic is applied unchanged every time, then the speed of the simulation relative to realtime will appear inconsistent.
Instead, the game can measure the span of time elapsed since the last update (or predict the time until the next pass), and provide this as an argument to the update methods. The update methods then scale the amount of change they apply to match the amount of time they are simulating.
For example, to simulate an object with constant velocity moving with a variable timestep:
MoveWithConstantVelocity(float deltaTime) {
position += velocity * deltaTime;
}
Unfortunately, for all but the most simple types of change over time, it can be difficult to correctly scale them to handle different timesteps and still give the same behaviour over time. As the timestep grows longer, integration errors tend to creep in. Systems like physics and collision are notoriously sensitive to the timestep used, and are prone to jittering or tunneling artifacts when the timestep is not properly tuned.
Fixed timesteps
To address these issues, many games adopt a fixed-timestep, where a standard update duration is decided in advance, and remains constant throughout the game. This can improve consistency and simplify code by removing the need for elaborate time-scaling methods.
A simple way to achieve a fixed timestep would be by locking the framerate to a conservative frequency and updating once (or a set number of times) per frame - though this makes it difficult to scale performance to take advantage of faster hardware or compensate for temporary slowdowns without impacting gameplay.
A more flexible and robust approach for a fixed-timestep game-loop is to decouple the update from the rendering. A variable accumulates realtime elapsed, and at the beginning of each frame the game state is updated zero or more times at its constant timestep until it's caught up, then finally the frame is rendered (often using interpolation to avoid stuttering/juddering artifacts).
Check out this popular guide for information on implementing a fixed timestep in a game loop, and this answer for a more detailed explanation for why this is commonly recommended in games.
Hybrids
Many games and game engines will use both fixed and variable timesteps for different tasks. For instance, the unity game engine uses a fixed timestep for its physics and FixedUpdate() scripts, and a variable timestep for Update() scripts, animation, and user interface elements.
