Concurrency: spawn / race / sync — Command Your Clone Army

1. spawn: Send Out a Clone — the Main Line Doesn't Wait

Let's place this lesson properly first: Blueprints have no real concurrency primitives. When you make things happen "at the same time" in Blueprints, you split the logic across several Event Dispatchers, several timers, several Custom Events, each running on its own, and then reconcile their progress through variables — doable, but assembled entirely by hand. Verse builds this into the language: five concurrency expressions, keywords just like Branch. The first is spawn — send a clone off to do the job while the main line keeps walking, without so much as a glance back.

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

firework_device := class(creative_device):

    LaunchFirework()<suspends>:void =
        Sleep(2.0)
        Print("Fireworks away!")

    OnBegin<override>()<suspends>:void =
        Print("Lighting the fuse...")
        spawn{ LaunchFirework() }
        Print("Main line isn't waiting for fireworks - moving on to set up the venue")

Read this graph first: firework_device is a Blueprint device with creative_device as its parent class. Inside, LaunchFirework is a custom function (its name carries the little clock icon — because it holds nodes that wait), and its body is "Delay 2 seconds → Print String 'Fireworks away!'". OnBegin (think Event BeginPlay) does three things: Print String 'Lighting the fuse'; use spawn to fork off a new wire that runs LaunchFirework without the main line waiting for it; then immediately Print String 'Main line isn't waiting for fireworks'.

Read the output order — one detail deserves a tap on the chalkboard: the new wire that spawn forks off first runs in one go until it hits its first "wait a moment" node (here, the Delay that is Sleep(2.0)), and only then hands execution back to the main line. So the log reads "Lighting the fuse" → "Main line isn't waiting for fireworks", and only two seconds later does "Fireworks away!" show up.

spawn comes with two iron rules. First, the braces may hold exactly one call to a function "with the little clock" — want to do three things at once? Pack all three into one <suspends> function first (that marker declares "there are waiting nodes in here"), then spawn that function. Second, it is the only one of the five concurrency expressions that can live on a "wire that can't wait": regular functions and bound-event responses alike. Next lesson you'll see its highlight moment — starting a stretch of waiting logic inside the response you bind to a device event (Subscribe) is all spawn.

One more thing to lock in now: a clone sent out by spawn is a horse let off the reins — even when the function that launched it ends, the clone isn't cancelled; it keeps running until its own work is done. Also, the spawn action actually pushes out an output: a receipt called a task, which you can later hand to Await() (wait for it to finish and collect the result) — the extra page has the full breakdown.

2. race: First Across the Line Wins — Losers Get Cancelled

race is an elimination match: every wire listed under race is a contestant, and they all start at once; the instant the first one crosses the finish line, the match is over — every other contestant is cancelled. race also carries an output pin, and what it emits is the champion's result:

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

turtle_rabbit_device := class(creative_device):

    Turtle()<suspends>:string =
        Sleep(3.0)
        "Turtle"

    Rabbit()<suspends>:string =
        Sleep(1.0)
        "Rabbit"

    OnBegin<override>()<suspends>:void =
        Winner := race:
            Turtle()
            Rabbit()
        Print("The champion is {Winner}!")

Reading the graph: Turtle and Rabbit are two custom functions; each Delays for a while (3 s / 1 s) and then sends a string ("Turtle" / "Rabbit") to its own output pin. In OnBegin a race is laid down with those two wires hanging off it; when the race finishes, the winning wire's output is hooked into a fresh variable Winner (:= means "create a new variable and hook this value up to it"), then Print String announces the champion.

The rabbit sleeps 1 second, the turtle 3, so the race is decided at the 1-second mark: Winner gets "Rabbit". At that moment the turtle is still stuck on the Delay that is Sleep(3.0) — and that kind of "wait a moment" node is exactly where the cancellation happens: a loser isn't ripped out from the middle of a node; it waits until it reaches its next Sleep / Await (a waiting node) and only then exits quietly. This rule — cancellation only happens at waiting nodes — matters a lot, and the extra page "Cancellation and defer" runs an experiment so you can watch it with your own eyes.

Two house rules: race needs at least two wires under it, and it can only live on a "wire that can wait" (inside a function body marked <suspends>, or inside another concurrency block). Also, because race pushes a value out, the types the arms send must line up — one arm sending a string while another sends an integer turns Compile red on the spot. Want several nodes in one arm? Pack them into one wire with block: — that's exactly how the timeout recipe in section 4 is written.

3. sync: Everyone Arrives First; branch and rush: One Line Each

sync is race's mirror image: all the wires listed under it start together, and sync only lets you pass once every one of them has finished. Perfect for "nothing moves to the next scene until all of these are done" moments:

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

banquet_device := class(creative_device):

    CookMainDish()<suspends>:void =
        Sleep(3.0)
        Print("Main course is served")

    BakeDessert()<suspends>:void =
        Sleep(2.0)
        Print("Dessert is out of the oven")

    OnBegin<override>()<suspends>:void =
        sync:
            CookMainDish()
            BakeDessert()
        Print("Everyone's here - let the banquet begin!")

Reading the graph: CookMainDish and BakeDessert are two custom functions that Delay 3 s / 2 s and then each Print String one line. In OnBegin a sync is laid down with those two wires attached; only after both have run to the end does the Print String after the sync — "Everyone's here - let the banquet begin!" — get to execute.

The main course takes 3 seconds and the dessert 2 — but they're made in parallel, so "let the banquet begin" prints at the 3-second mark, not at 3 + 2 = 5. That is the whole point of concurrency: total time is set by the slowest member, not the sum of everyone. Like race, sync needs at least two wires under it and can only live on a "wire that can wait"; it too carries an output — a tuple bundling each wire's result, in the same top-to-bottom order you laid them out.

The remaining two members get one line each. branch: is spawn's "act now, report later" cousin — it forks off a new waiting wire and the main line continues immediately; but that wire's life is leashed to the surrounding graph: the moment that stretch of graph ends, the wire is revoked (think of it as "spawn on a leash"). rush: is "race without eliminations" — the moment the first contestant finishes, rush moves on with that result, but the others are not cancelled; they keep running until the surrounding graph ends and only then get cleared out.

The "usable on a wire that can't wait?" column exposes the official design philosophy: structured concurrency. Wires forked by sync / race / rush / branch all have their lifespans managed by the stretch of graph they live in — when that graph wraps up, those wires pack up with it, and not one goes missing; only spawn's wires can "escape" that graph and live on independently. Hence the refreshingly blunt official advice: if one of the four structured siblings will do, don't use spawn; call on spawn only when you're stuck on a "wire that can't wait" (say, a bound-event response) with no other choice.

4. The Classic Recipe: race + Sleep = Timeout

Put race together with last lesson's Sleep and you get the most classic concurrency recipe in Verse — the timeout. The brief: the player must press a button within 10 seconds; press in time and the challenge succeeds, miss it and it's a timeout. Done any other way, you'd need a Timer, a switch variable, and manual state cleanup — no skipping any of the three; in Verse it's just a two-runner race: one wire waits for the button press, the other Delays 10 seconds — whoever finishes first wins, the loser is auto-cancelled, and you don't wire up a single cleanup node. Hit "Run next step" to watch this race get decided.

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

timeout_device := class(creative_device):

    @editable
    Button:button_device = button_device{}

    OnBegin<override>()<suspends>:void =
        Print("Press the button within 10 seconds - go!")
        race:
            block:
                Button.InteractedWithEvent.Await()
                Print("Pressed in time - challenge complete!")
            block:
                Sleep(10.0)
                Print("Time's up - the chance slipped away...")
        Print("race is over - the loser has left the stage")

Note that both arms open with block: — block's job is to bundle several nodes into a single wire. Here neither wire emits a value at the end (void), so the types trivially line up; if you want the race itself to tell you "success or timeout", have each wire send out a logic (a Boolean true/false) — the race's output is your answer.

Your turn. The "curtain-call console" below has two keywords carved out: one is the expression that can fork a new wire from a "wire that can't wait" (like a bound-event response), the other is the one that waits for everyone to finish. Fill them back in, then hit "Check answer".

Reading the graph: in the top half, Fireworks and Music are two custom functions each carrying a Delay. OnEncore is a response "bound to a button — runs on each press" — it's a wire that can't wait, so to launch another round of fireworks inside it, your only move is to fork a new wire (first blank). In the bottom half, OnBegin needs "fireworks and music both finished before the curtain call" — that takes the block that waits for everyone (second blank).

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

finale_device := class(creative_device):

    Fireworks()<suspends>:void =
        Sleep(2.0)
        Print("Fireworks burst together")

    Music()<suspends>:void =
        Sleep(3.0)
        Print("Music fades out")

    # This callback gets Subscribed to some button (details next lesson)
    OnEncore(Agent:agent):void =
        # A callback is not an async context - to fire another round, send out a clone
        ____{ Fireworks() }

    OnBegin<override>()<suspends>:void =
        # The curtain call only counts once fireworks and music are both done
        ____:
            Fireworks()
            Music()
        Print("Curtain call complete")

5. Common Pitfalls: the Concurrency Rookie Minefield

When a concurrency expression turns Compile red, the error tends to look ferocious, but the root causes are all tiny. Step on these mines in advance and you'll save yourself hours of debugging:

• Using race / sync / branch in a regular function (the kind that can't wait). Compile turns red: "not allowed by its context". A forum classic: copying the official sample verbatim and still getting the error — because your own function forgot the <suspends> marker (never declared "there are waiting nodes in here"). These three can only live on a wire that can wait.
• Stuffing a pile of nodes into spawn's braces. The spawn body takes one call to a function "with the little clock" — one extra is a violation. The fix: pack those nodes into a <suspends> function and spawn that.
• Using rush as if it were race. rush doesn't cancel the slower wires — they keep running until the surrounding graph ends. If you want eliminations, use race.
• Putting branch as the last step of a function. The function ends immediately, that stretch of graph exits, and the wire branch forked is revoked before it's out the door — the symptom is "nothing happened", which is thoroughly baffling.
• Assuming spawn's wires will wrap themselves up. They won't. The round is long over and the leftover wire is still poking at objects that have already been destroyed — instant runtime error. When you want "graph wraps up, wire packs up", use branch instead.
• race wires sending types that don't line up. race pushes a value out, so the types the wires send must be compatible — forget that and collect one type error.

Blueprint Cross-Reference

This lesson's table looks different from the others: the left column is mostly not "some node" but "a workaround you hand-wrote." Blueprints have no concurrency primitives — which is exactly what makes this chapter the most valuable trade in the whole book.

Where does the difference come from? In the Blueprint execution model, "a wire" is a line you drew — the engine has no object you can name, cancel, or wait on. Verse has the notion of a task at the language level, which is what makes "cancel the losers" and "wait for everyone" expressible as keywords instead of something you re-assemble by hand every time.

It cuts the other way too: a Blueprint Event Dispatcher is a one-to-many broadcast by nature, and adding listeners is just dragging more wires. To do the same in Verse you declare the event and subscribe to it yourself — which is precisely what the next lesson is about.

6. Level Challenges

Three quick challenges to certify your clone-commanding skills. Wrong answers cost nothing — retry as often as you like.

Further Reading