GDKB

Delta Time

Beginner20 Minutes readUpdated July 21, 20263 related concepts

Delta time is the amount of real-world time that elapsed since the previous frame, measured in seconds and handed to your code every game loop iteration. Multiplying movement, timers, or any other rate-based change by delta time makes that change happen at a consistent real-world speed no matter how fast or slow the frame rate currently is. Without it, gameplay would run at different speeds on different hardware — or even moment to moment on the same machine.

On this page

Delta Time

Summary

Delta time is the amount of real-world time that elapsed since the previous frame, measured in seconds and handed to your code every game loop iteration. Multiplying movement, timers, or any other rate-based change by delta time makes that change happen at a consistent real-world speed no matter how fast or slow the frame rate currently is. Without it, gameplay would run at different speeds on different hardware — or even moment to moment on the same machine.

Why This Matters

If a character moves a fixed distance every frame — position += 5 — that character crosses the screen twice as fast on a machine hitting 120 FPS as one hitting 60 FPS, because more frames simply means more additions per second. The character's actual on-screen speed becomes an accident of hardware performance rather than a deliberate design choice. Delta time fixes this by scaling every per-frame change to how much time actually passed, not how many frames happened to run — position += 5 * deltaTime covers the same real-world distance per second regardless of frame rate.

Mental Model

Delta time is a car's speedometer reading multiplied by the seconds since you last checked it, not a fixed distance per glance. Driving at 60 km/h covers the same real-world distance whether you check your position once a second or ten times a second — checking more often just means smaller distances counted more frequently, never a change in your actual speed. Multiplying a rate (km/h, or units per second) by elapsed time (delta time) is exactly this: it converts "how fast" into "how far this frame," correctly, regardless of how often you're checking.

Core Explanation

  • Delta time is measured, not configured. Each frame, the engine records how much wall-clock time elapsed since the previous frame's measurement and exposes it — Time.deltaTime in Unity, the DeltaTime parameter passed to Tick in Unreal — you read it, you don't set it.
  • Multiplying a per-second rate by delta time gives the correct per-frame amount. A moveSpeed of 5 (units per second) becomes 5 * deltaTime units to move this specific frame — over one real second, regardless of how many frames that second was split into, the total movement adds up to the same 5 units.
  • Delta time varies frame to frame — it is not a constant. A frame that took longer to compute (due to a spike in scene complexity) reports a larger delta time next frame, which is precisely what keeps frame-rate-dependent code correct even through frame rate fluctuations.
  • Very large delta time spikes (after a stall or breakpoint) need guarding against. A frame that took several seconds to process (e.g. the game was paused in a debugger) reports an equally large delta time, which can cause a single frame of movement or physics to jump drastically — engines often clamp delta time to a maximum reasonable value to prevent this.

Syntax / Theory

Engine-neutral (pseudocode)

text
previousTime = now()

while (gameIsRunning)
{
    currentTime = now()
    deltaTime = currentTime - previousTime
    previousTime = currentTime

    Update(deltaTime) // Every rate-based change scales by this.
}

C# (Unity)

csharp
public class Mover : MonoBehaviour
{
    public float moveSpeed = 5f; // Units per second.

    void Update()
    {
        transform.position += Vector3.forward * moveSpeed * Time.deltaTime;
    }
}

C++ (Unreal)

cpp
void AMover::Tick(float DeltaTime)
{
    Super::Tick(DeltaTime);
    FVector Movement = GetActorForwardVector() * MoveSpeed * DeltaTime;
    AddActorWorldOffset(Movement);
}

Both engines pass delta time into your per-frame logic the same way — Unity as a globally-readable property, Unreal as an explicit parameter to Tick — but the multiplication pattern (rate * deltaTime) is identical.

Practical Example

A fade-out effect needs to take exactly one real-world second regardless of frame rate.

csharp
public class FadeOut : MonoBehaviour
{
    public float durationSeconds = 1f;
    private float elapsed;

    void Update()
    {
        elapsed += Time.deltaTime;
        float progress = Mathf.Clamp01(elapsed / durationSeconds);
        canvasGroup.alpha = 1f - progress;
    }
}

Whether this runs at 30 FPS or 144 FPS, elapsed reaches 1.0 after roughly one real second either way — at 30 FPS it took about 30 larger steps to get there, at 144 FPS about 144 smaller ones, but the total elapsed time, and therefore the fade's duration, stays the same.

Common Mistakes

  • Forgetting to multiply by delta time entirely. position += speed; instead of position += speed * Time.deltaTime; ties movement speed directly to frame rate — one of the most common beginner bugs in game programming.
  • Multiplying by delta time twice, or in the wrong place. Scaling an already-scaled value by delta time again (e.g. inside both a helper method and its caller) produces motion that's far too slow and quadratically tied to frame rate instead of linearly.
  • Using delta time for something that should be frame-rate independent in a different way — physics integration. Naively multiplying acceleration by delta time every frame with a variable delta time can introduce subtle inaccuracy; this is part of why physics is often updated on a fixed timestep separate from the render loop (see Further Reading).
  • Not clamping delta time after a stall. A debugger breakpoint, a loading screen, or an alt-tab pause can produce one enormous delta time value on resume, causing a character to teleport or clip through a wall in that single frame.

Game Development Example

A cooldown-based ability system counts down using delta time so ability cooldowns feel identical regardless of the player's frame rate.

csharp
public class Ability : MonoBehaviour
{
    public float cooldownDuration = 3f;
    private float cooldownRemaining;

    void Update()
    {
        if (cooldownRemaining > 0)
            cooldownRemaining -= Time.deltaTime;
    }

    public bool TryUse()
    {
        if (cooldownRemaining > 0) return false;
        cooldownRemaining = cooldownDuration;
        Execute();
        return true;
    }
}

A player on a lower-end machine running at 30 FPS still gets exactly a 3-second cooldown, not a cooldown that's subtly longer or shorter because of how many frames it took to count down.

Best Practices

  • Multiply every per-second rate (speed, rotation, cooldown countdown, fade progress) by delta time — never assume a fixed number of frames per second.
  • Use a fixed, separate timestep for physics simulation rather than the same variable delta time as rendering, when precision and stability matter (most engines provide this as a built-in fixed-update path).
  • Clamp delta time to a sane maximum to protect against enormous spikes after a stall or breakpoint.
  • Be explicit about units (seconds vs. milliseconds) in variable and parameter names — a duration that's actually in milliseconds but multiplied against a seconds-based delta time silently produces wrong timing.

Exercises

  1. Write a Mover script that moves an object forward at a fixed units-per-second speed using delta time, then deliberately remove the * Time.deltaTime multiplication and describe the resulting behavior difference between two different simulated frame rates.
  2. Take the Ability cooldown example and add a cooldownRemaining01 property that returns the cooldown's progress as a 0–1 fraction for a UI radial fill — compute it using the existing delta-time-driven countdown.
  3. You're implementing a physics-heavy vehicle simulation and a simple UI fade animation in the same game. Decide whether both should use the same variable delta time, or whether one should use a fixed timestep instead, and justify the choice for each.
  4. Research why some engines expose both a regular delta time and an "unscaled" delta time (e.g. Time.deltaTime vs. Time.unscaledDeltaTime in Unity), and explain a situation (like a pause menu) where using the wrong one would cause a bug.
  • Game Loop — delta time is measured once per game loop iteration; it only exists because the loop repeats and needs a way to know how much time passed between repetitions.
  • Frame Rate — delta time and frame rate are two views of the same measurement, inversely related — knowing one lets you compute the other.
  • Operators — correctly applying delta time depends on understanding multiplication and the units involved, and is a common source of off-by-a-multiplication bugs for new programmers.

Further Reading

Related Concepts