Verse Wiki — the Verse handbook for Blueprint authors
Technique · EXTRA

How Sleep Really Keeps Time: The 30-Tick Ceiling and Per-Frame Animation

Blueprint's Event Tick is the engine calling you once per frame; in Verse you write the per-frame loop yourself with Sleep. But write Sleep(0.01) and the engine bills you 1/30 of a second anyway. This page gathers the community's real-device measurements: how long Sleep actually sleeps on a live server, and why for smooth animation "Sleep(0.0) and call it a day" is the move — often without ever computing DeltaTime.

1. Measured Data: Sleep Doesn't Sleep What You Wrote

The Epic developer-forum thread “Important Notes On Sleep & UEFN Timing” did something plain and precious: it measured on real hardware. The author put Sleeps with different arguments in a loop (that's the Delay node from Blueprints) and counted how many times they actually executed per second. The verdict is blunt — Sleep(0.1) reliably yields 10 per second, while Sleep(0.01) and Sleep(0.0) both cap out at about 30 per second; the author ran the test on both the slowest and the fastest test devices, with identical results.

The reason is exactly Lesson 23's simulation frame: a Fortnite server runs about 30 simulation updates per second, Sleep can only wake on a frame boundary, and sub-frame precision simply does not exist. The number you write in the parentheses is more like a "minimum request": the engine guarantees at least that long, then wakes you on the next frame boundary. The reference table:

What you write Actual execution rate Notes
Sleep(1.0) About once per second Keeps time by the second, as expected
Sleep(0.1) About 10 times per second As expected — 10 ≤ 30 fits fine
Sleep(0.01) About 30 times per second (capped) Want 100? The engine gives you 30
Sleep(0.0) About 30 times per second (every frame) “Call me next frame” — in practice identical to 0.01

2. The Practical Takeaway: For Per-Frame Animation, Just Sleep(0.0)

To do smooth movement, fades, or per-frame animation in Verse, don't agonize over "how long should I sleep" — just write Sleep(0.0): run once per frame, at roughly 30 fps. The intent could not be clearer — "I want to work every frame" — instead of dressing up as some precise number of milliseconds. Better still, because the tick rate is governed by the engine and essentially constant, the thread author's experience is that you usually don't need to compute DeltaTime yourself (the actual time elapsed each frame): move a fixed step per frame, and the motion looks uniform to the eye.

Use Lesson 23's "loop + Sleep" template to write a per-frame counter and verify the 30-tick story with your own hands:

frame_counter_device.verse
using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }
using { /UnrealEngine.com/Temporary/Diagnostics }

frame_counter_device := class(creative_device):

    OnBegin<override>()<suspends>:void =
        var Frames:int = 0
        loop:
            set Frames += 1
            if (Frames >= 90):
                break
            # Yield once per frame: about 30 frames = 1 second
            Sleep(0.0)
        Print("Counted {Frames} frames — the wall clock moved about 3 seconds")

Translating the graph: this is Lesson 23's loop all over again — an exec line that wires back into itself. Each lap, a Set node first adds 1 to Frames, then a Branch checks whether Frames has reached 90 — if so, a Break jumps out; if not, the line walks through a Sleep(0.0) (a Delay of zero length, meaning "come back next frame"). After breaking out, a Print String reports how many frames were counted.

Drop it into a level and run it: from OnBegin (Event BeginPlay) to the print, about 3 seconds of real time pass — 90 frames ÷ 30 frames per second. Swap Sleep(0.0) for Sleep(0.01) and the result barely changes; swap in Sleep(0.1) and you'll wait about 9 seconds. Numbers don't lie: the pace is set by frames, not by the milliseconds you wrote.

One final splash of cold water: people in the thread also warn that 30 ticks isn't smooth enough for some fast animation — bullet trails and quick camera moves show visible stutter at 30 fps. That's a hard engine-level limit Verse cannot break through; when designing fast visual effects, either accept 30 fps or hand the presentation to a non-Verse, engine-side solution.

Three takeaways you can copy straight into a project: first, for any "trigger every X seconds" gameplay logic (spawning waves, healing, score settlement), Sleep is thoroughly reliable when X is 0.1 s or more — use it with confidence; second, for anything per-frame and presentational, standardize on Sleep(0.0) and calibrate your per-frame step against 30 fps; third, don't accumulate precise real-world durations by counting Sleeps — each wakeup may align to a frame boundary, the error compounds lap after lap, so leave tolerance in duration-sensitive gameplay.

You want a Verse-driven movement animation to be as smooth as possible. What goes in the loop?

Sources

This page draws on community measurements from the Epic developer forums: