Skip to content

Get Game Time / Unpaused Time / Real Time / World Delta Seconds

At a glance

Lives in: Blueprint API / Utilities / Time - Returns: Real values; the current native Blueprint functions return double - Reads: one selected world's accumulated game, unpaused, or real-time counter, or its current frame delta - Can fail by: resolving no world and returning a default 0.0 while the context path may log a warning - Official docs: Get Game Time in Seconds, Get Unpaused Time Seconds, Get Real Time Seconds, and Get World Delta Seconds

The one-minute version

  • Get Game Time in Seconds is the normal gameplay clock. It stops while the world is paused and advances through global time dilation.
  • Get Unpaused Time Seconds keeps advancing while paused, but it is still dilated. "Unpaused" does not mean "real time."
  • Get Real Time Seconds keeps advancing while paused and ignores time dilation and the world's normal time clamping. It is still a per-world, startup-relative counter - not the date, UTC time, or a saved timestamp.
  • Get World Delta Seconds is not an accumulated clock. It is the selected world's dilated frame step. Multiply a per-second rate by it for smooth frame-rate-independent updates.
  • All four use a hidden World Context Object. Every PIE client/server world has its own values; normal level streaming stays inside one world, while travel can replace the clock's world.
  • For multiplayer deadlines, let the server decide and use GameState's Get Server World Time Seconds on every machine. Do not subtract one client's local Game Time from another client's timestamp.

The four measurements side by side

Node Reads from the selected UWorld Stops during game pause? Affected by global time dilation? Beginner use
Get Game Time in Seconds TimeSeconds Yes Yes Pause-aware cooldowns, elapsed gameplay time, state durations.
Get Unpaused Time Seconds UnpausedTimeSeconds No Yes A world-relative duration that must continue through pause but should still follow slow/fast game time.
Get Real Time Seconds RealTimeSeconds No No World-session diagnostics or local UI behavior that must ignore pause and slomo.
Get World Delta Seconds DeltaTimeSeconds for the frame Not an accumulated clock Yes Per-frame integration: speed, interpolation, smoothing, and countdown changes.

The accumulated counters are double values in current UE5 source. The underlying world delta is stored as a float, then returned by the Blueprint helper as a double. That wider output does not invent sub-frame information; it reports the world frame sample Unreal has.

What each node actually reads

These are small static helpers. Each resolves a UWorld from the hidden context and reads one value already maintained by that world.

pseudocode of the engine behavior - not engine source

function GetGameTimeInSeconds(Context):
    World = resolve world from Context
    return World exists ? World.TimeSeconds : 0

function GetUnpausedTimeSeconds(Context):
    World = resolve world from Context
    return World exists ? World.UnpausedTimeSeconds : 0

function GetRealTimeSeconds(Context):
    World = resolve world from Context
    return World exists ? World.RealTimeSeconds : 0

function GetWorldDeltaSeconds(Context):
    World = resolve world from Context
    return World exists ? World.DeltaTimeSeconds : 0

They do not start a stopwatch when called. Reading Game Time at 120.0 means the selected world has accumulated roughly 120 seconds under that clock's pause/dilation rules. Store a first reading if you need a start point.

Game Time: the ordinary gameplay clock

Use Get Game Time in Seconds when pause and global slow motion should affect the rule:

BeginCooldown:
    CooldownEnd = Get Game Time in Seconds + CooldownDuration

CanFire:
    Get Game Time in Seconds >= CooldownEnd

If the game pauses halfway through, the deadline does not get closer during the pause because both readings use the stopped clock. At global time dilation 0.5, four real seconds advance this clock by about two gameplay seconds (subject to the world's frame/time clamping).

This clock is usually the right default for gameplay state. It agrees with normal world simulation better than an operating-system timestamp does.

Unpaused Time: pause-proof, but still dilated

Use Get Unpaused Time Seconds only when both parts of its contract are intentional:

  1. the measurement must continue while the game is paused; and
  2. global slow motion or fast motion should still change how fast it advances.

For example, a pause-menu animation normally belongs to the user interface's own animation/tick behavior, not necessarily this clock. But a world-relative debug counter that must span pause while still matching the world's dilated cadence can use Unpaused Time.

The name is a common trap:

Unpaused Time != undilated time

If pause must not stop it and slomo must not affect it, choose Real Time.

Real Time: undilated world-session time

Get Real Time Seconds counts from when this world was brought up for play. It does not stop for game pause and does not use global time dilation or the world's normal game-time clamp.

Useful examples include:

  • measuring how long a local loading/debug step took within this world;
  • a local menu timeout that must continue during game pause; or
  • comparing real-versus-game duration to diagnose dilation.

It is not wall-clock calendar time. A return value such as 86400 does not mean midnight, a Unix timestamp, or a date. It means this world-relative real counter has accumulated that many seconds.

For a calendar value, use UTC Now / a Date Time value (or a trusted backend for security-sensitive deadlines). For process-level elapsed profiling that is deliberately not tied to a world, Get Platform Time Seconds is the closer lookalike.

World Delta Seconds: one frame step, not a timestamp

At 60 frames per second with ordinary dilation, World Delta is roughly 0.0167. At 30 frames per second it is roughly 0.0333. The correct per-second update is:

change this frame = rate per second * Get World Delta Seconds

For a value smoothing toward a target:

Event Tick (Delta Seconds)
-> FInterp To(Current, Target, Delta Seconds, Interp Speed)

The Event Tick Delta Seconds output already supplies the relevant frame step. Do not call Get World Delta Seconds again in the same Tick graph just to obtain the same kind of value.

World Delta is affected by global time dilation. A hitch normally produces a larger frame step than a smooth frame (within any engine/project clamping or smoothing in effect). That is precisely why movement must consume the actual delta instead of assuming 1 / 60.

Pause needs a separate mental model: World Delta is a frame sample, not a counter that can "stop." Normal Actor graphs usually do not execute while the game is paused unless configured for paused ticking/input. If a graph does run while paused, do not infer a real-time duration policy from World Delta; choose Game, Unpaused, or Real Time explicitly for that policy.

Store a timestamp or create a Timer?

Both are valid, but they own different behavior.

Store a timestamp when state is queried

Use a start or deadline when other systems need to ask "how much remains?":

StartPoison:
    PoisonEndTime = Get Game Time in Seconds + Duration

GetRemainingPoisonTime:
    Max(0, PoisonEndTime - Get Game Time in Seconds)

This is a good fit for cooldown UI, saveable state (with a deliberately chosen clock policy), and replicated deadlines. Store both values from the same clock family. Subtracting Real Time from a Game Time deadline has no useful meaning.

Prefer Now - Start or Deadline - Now over accumulating a separate variable with Value += DeltaSeconds when you only need elapsed time. A stored accumulator can miss updates when its owning graph does not tick and can drift from the clock whose semantics you intended.

Use a Timer when execution must happen later

Use Set Timer by Event when an event must fire once or repeatedly:

Set Timer by Event
    Time = 0.5
    Looping = false
-> callback: RefillOneAmmo

Timers are checked by the world's timer manager on game frames. They give you a handle to clear, pause, or replace; they are not background threads and they do not synchronize across network worlds.

Many systems use both: a server-owned deadline for truth and a Timer as a convenient wake-up. The deadline remains the answer if a hitch makes the timer callback arrive after its ideal instant.

Startup, hitches, streaming, and travel

World startup

Game, Unpaused, and Real Time are relative to one world being brought up for play. 0.0 is therefore a legitimate early value. It is also the default from a missing-world failure, so the number alone cannot diagnose context.

Hitches and exact comparisons

Do not wait for a clock to equal a deadline exactly:

bad:  CurrentTime == EndTime
good: CurrentTime >= EndTime

Frames sample time in steps. A hitch can take the value from just below the deadline to above it without ever producing exact equality. Delta-driven countdowns should clamp at zero rather than wait for exactly zero.

Level streaming

Streamed levels join the same UWorld, so they read the same world clocks. Streaming a sublevel in or out does not reset Game Time.

Open Level and travel

Normal map travel can replace the world. Do not assume these per-world values form one continuous process clock across travel, even when the Game Instance survives. Recreate world-relative baselines after travel or store a different kind of time when continuity is the actual requirement.

Precision and long-running sessions

Current accumulated world clocks and Blueprint helper returns use double, which gives far more long-session precision than the older habit of storing timestamps in a Float. Keep timestamp/deadline variables as Double/Real; an explicit conversion to Float throws that advantage away.

Still follow three rules:

  • compare ranges (>=, <=, tolerance), not exact floating-point equality;
  • subtract nearby timestamps before converting/formatting when possible; and
  • do not accumulate frame delta for days when the engine already owns the clock you want.

World Delta starts from a float frame sample, so it describes frame-scale work, not archival precision. For save files that must expire at a real date, use a Date Time/UTC or trusted service value instead of any world counter.

Multiplayer: choose one authoritative clock

The server and every client own separate UWorld instances. They can start at different moments, pause differently, and receive network data later. This is invalid:

Server stores its Get Game Time in Seconds as FireEnd
Client compares FireEnd with client's Get Game Time in Seconds

Both values are called Game Time, but their zero points belong to unrelated worlds.

Use GameState's synchronized server clock:

Server accepts Fire request:
    ServerNow = GameState -> Get Server World Time Seconds
    FireEndServerTime = ServerNow + Cooldown
    replicate FireEndServerTime

Server validates next request:
    Get Server World Time Seconds >= FireEndServerTime

Client displays:
    Remaining = Max(0,
        FireEndServerTime - GameState.GetServerWorldTimeSeconds)

AGameStateBase replicates server time information and estimates the server world's TimeSeconds on clients. It gives every machine the same clock domain for presentation, while the server still owns the decision. Network delay and periodic synchronization mean the display is an estimate; they do not give a client authority to approve its own cooldown.

Do not use client Real Time or the computer's UTC clock for authoritative gameplay. Client clocks are not synchronized or trusted, and a player can change a local system clock.

When a getter fails

These pure nodes have no Failed execution pin. With no usable world context, the native helper returns 0.0; context resolution may also write a Blueprint warning depending on the call path.

Common causes:

  1. a Blueprint Function Library did not receive/forward a World Context Object;
  2. the caller is a Data Asset, class default object, or editor preview rather than a runtime world object;
  3. an old Actor/Widget reference survived into teardown or travel; or
  4. a valid context came from another PIE client, giving a believable but wrong clock instead of failure.

Because zero is valid at startup, diagnose the context, not just the number. The Blueprint World Context page has the full debugging ladder.

What these nodes do not do

They do not:

  • return a calendar date, UTC timestamp, or Unix epoch time;
  • create, pause, or clear a Timer;
  • make a callback happen when a deadline is reached;
  • survive travel as one guaranteed continuous world clock;
  • synchronize one client's local world time with another;
  • replicate a stored timestamp or cooldown;
  • grant authority to the machine reading the value; or
  • make a fixed frame-rate assumption safe.

Lookalikes - which one do I want?

Node / value Use when Watch out
Get Game Time in Seconds Elapsed gameplay should pause and follow global dilation. Per-world; not synchronized across clients.
Get Unpaused Time Seconds Time must span pause but still follow global dilation. "Unpaused" is still dilated.
Get Real Time Seconds A world-session measurement must ignore pause and dilation. Still per-world and not a calendar value.
Get World Delta Seconds A per-second rate must advance once for this world frame. Not a timestamp; current sample originates as a float.
Event Tick: Delta Seconds You are already in Tick. Prefer this pin to another getter in the same graph.
Set Timer by Event A callback must run later/repeatedly. World/frame driven; store the handle when it needs control.
Timeline A curve should update smoothly over time. Owns playback state; not a universal clock.
Get Server World Time Seconds Multiplayer clients need the server's synchronized Game Time domain. Read through GameState; server still validates truth.
Get Platform Time Seconds Process/platform elapsed measurement should not depend on a world. Not calendar time and not a replicated authority clock.
UTC Now You need a date/time on this computer. Local system clocks are untrusted for authoritative online rules.

Rule of thumb: Game for gameplay, Unpaused for dilated time through pause, Real for undilated world-session time, Delta for this frame, and Server World Time for shared multiplayer deadlines.

Going deeper