Events and Binding: From Event Dispatcher to Subscribe

1. Broadcast and Subscribe: You Already Know This Model

Think back to the last time you used an Event Dispatcher in Blueprints. A door gets opened. The door has no idea who cares — it just Calls its own OnOpened dispatcher and shouts "I'm open." Whoever cares does the Binding: the scoreboard binds, the audio manager binds, the achievement system binds. The door never hears about any of them.

That is the broadcast / subscribe model, and it is the single most important decoupling tool in Blueprints. Its value isn't "it can trigger other logic" — holding a reference and calling a function triggers logic too. Its value is direction: the publisher doesn't know the subscribers, so you can add or remove a listener any time without going back to touch the door.

Verse expresses the same model with three words:

• Broadcast (Blueprint's Call Dispatcher) → Signal();
• Subscribe (Blueprint's Bind Event to XXX) → Subscribe(Handler);
• Unsubscribe (Blueprint's Unbind Event) → call Cancel() on the ticket Subscribe handed back.

Verse also throws in something Blueprints don't have: Await() — instead of registering a handler, you park the current exec line right here until the event rings. There is no Blueprint node for this, because a Blueprint function graph cannot stop partway (Lesson 23). Verse has <suspends>, so "wait for an event" can sit on the exec line just like a Delay. We'll walk both routes below.

But before subscribing there's a more basic question to settle: how does your code get hold of that door in the first place?

2. Referencing Another Object: That Details-Panel Drag Is Called @editable

You could do the Blueprint version in your sleep: add a variable to the class, set its type to an Actor reference (or some concrete Actor class), tick the Instance Editable eye. Once the thing is in the level, open the Details panel, click the dropdown, and pick an Actor from the level. The code never knows which door it is — the door is configured in.

Verse works exactly the same way; the little eye is now one line of attribute: @editable.

using { /Fortnite.com/Devices }

# A remote control with slots
remote_device := class(creative_device):

    # Slot one: a button in the level. @editable goes on its own line, above the field
    @editable
    TriggerButton:button_device = button_device{}

    # Slot two: plain values can be exposed too - designers tweak numbers without touching code
    @editable
    Delay:float = 2.0

Line by line against Blueprints: the @editable line = ticking Instance Editable; TriggerButton:button_device = a "button-typed Actor reference variable"; = button_device{} = its default value. Delay:float = 2.0 is a Float in the variables panel defaulting to 2.0, which designers edit right in the Details panel.

Three rules to remember. First, @editable takes its own line, above the field. Second, a default value is mandatory — reference-typed fields use an empty archetype as placeholder (= button_device{}), and skipping it turns Compile red. A Blueprint object reference defaults to None; Verse refuses to have such an "empty" state at all, which is part of how it kills Accessed None at the root (see Lesson 18 on option). Third, more than object references can wear the attribute: int, float, logic, string and arrays of them all work; to put a whole class of your own on the panel, that class also needs the <concrete> marker (condition: every field has a default).

One thing is identical to Blueprints: changing a value on the panel needs no re-Compile. Nudging a cooldown from 2 s to 3 s is a drag, not a build. And that's exactly why "look the level object up by name in code" is a bad habit on both sides — levels change constantly, while a slot only needs a fresh drag.

3. Subscribing to an Event: Bind Event in Code Form

With a button in the slot, back to the opening question: how does the code find out the instant the button is pressed? In Blueprints you drop a Bind Event to On Interacted on the event graph and wire its red event pin to a Custom Event. In Verse it is one function call:

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

# Alarm: subscribing, unsubscribing, and plain waiting - all three moves at once
alarm_device := class(creative_device):

    @editable
    AlarmButton:button_device = button_device{}

    OnBegin<override>()<suspends>:void =
        # Subscribe: when the button is pressed, OnAlarm is called automatically
        Sub := AlarmButton.InteractedWithEvent.Subscribe(OnAlarm)
        # Subscribe hands back a cancelable; Sub.Cancel() unsubscribes

        # The other route: don't subscribe, just wait - Await is an async call
        FirstAgent := AlarmButton.InteractedWithEvent.Await()
        Print("Got the first press, OnBegin moves on")

    OnAlarm(Agent:agent):void =
        Print("Alarm! Someone pressed the button!")

Where does the subscription go? Same place as in Blueprints: wherever "runs once at the start" lives. In Blueprints that's Event BeginPlay; in Verse it's OnBegin. Elsewhere is legal but risky — see pitfall three below, the most common trap in this lesson.

The handler's signature has to match. In Blueprints a mismatched signature simply won't let you make the connection; in Verse a mismatch is a red Compile. InteractedWithEvent hands over "whoever pressed the button" as an agent (think the Instigator pin on a Blueprint event), so the handler must read OnAlarm(Agent:agent):void — one parameter short won't do, and typing it as player won't either. One more detail worth a tap on the chalkboard: inside Subscribe(OnAlarm) goes the function's name, with no parentheses and no arguments. You are handing the graph to the button for safekeeping so it can run later — not running it now. Wiring it up ≠ pulling the wire right now.

Unsubscribing. Subscribe hands back a cancelable (a cancel ticket); calling Cancel() on it is Blueprint's Unbind Event. Blueprints also give you Unbind All Events to clear the board in one node; Verse has no counterpart — you keep the tickets yourself, and when there are many, store them in var Subs:[]cancelable and Cancel() them one by one at cleanup. When you must unsubscribe and when you can let it ride gets a whole page in extra x1.

The handler cannot wait. The function you subscribe is the run-to-completion kind; its signature is fixed by the official API and carries no <suspends> — put a bare Sleep in there and it errors. This has the same flavor as Blueprint's rule that a Delay can't go inside a custom Function. The fix is to call in Lesson 24's clone technique: spawn{ SomeAsyncFunc() } forks a new wire and lets that wire do the sleeping and waiting. spawn happens to be the only concurrency expression allowed on a wire that can't wait; this is its home turf.

Assemble the parts and watch the whole chain: a slot + a counting variable + a subscription + a handler whose signature lines up = a doorbell that keeps books. Hit Run Next Step.

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

# Counting doorbell: every press goes in the ledger
doorbell_device := class(creative_device):

    @editable
    Bell:button_device = button_device{}

    var PressCount:int = 0

    OnBegin<override>()<suspends>:void =
        Bell.InteractedWithEvent.Subscribe(OnRing)
        Print("Doorbell ready. Come press it.")

    OnRing(Agent:agent):void =
        set PressCount += 1
        Print("Ding-dong! Press number {PressCount}")

Notice what happens after OnBegin finishes: the device is not "over." It guards the wire it bound, and whenever a player presses, OnRing wakes up; ten presses, ten ledger entries — the very same mental model as BeginPlay finishing in Blueprints while the events you Bound keep working.

4. Firing Your Own Event: Call Dispatcher in Code Form

Native devices ship with events. But how do two Verse classes you wrote yourself talk? This is Event Dispatcher's home ground in Blueprints: Add Event Dispatcher on the class, name it, configure its inputs, then Call it wherever you need.

Verse's counterpart is event(t). Declaring one has an iron rule: the "type = archetype" pair must be written in full, i.e. RaceStartEvent<public>:event(agent) = event(agent){}. Write only the left half and Compile complains it is an abstract thing you cannot use directly. The agent in the parentheses is the dispatcher's input parameter type (the Inputs you configure on the Event Dispatcher panel); with no parameters, write event() = event(){}. The <public> is there so other classes can reach it — the other end of the conversation usually lives elsewhere.

using { /Fortnite.com/Devices }
using { /Verse.org/Simulation }
using { /UnrealEngine.com/Temporary/Diagnostics }
# The Signal / Await of event(t) come from /Verse.org/Concurrency
# The Verse API Reference is the source of truth (using paths can differ across template versions)
using { /Verse.org/Concurrency }

# Starter side: one button press broadcasts the race start to every listener
starter_device := class(creative_device):

    @editable
    StartButton:button_device = button_device{}

    # The equivalent of Add Event Dispatcher; its input is one agent
    RaceStartEvent<public>:event(agent) = event(agent){}

    OnBegin<override>()<suspends>:void =
        StartButton.InteractedWithEvent.Subscribe(OnPressed)

    OnPressed(Agent:agent):void =
        # Signal is Call Dispatcher: shout, and take the Agent along
        RaceStartEvent.Signal(Agent)
        Print("The starting gun fires!")

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

# Listener side: wait for the starting gun, then open the barrier
gate_device := class(creative_device):

    # @editable can reference a Verse class you wrote yourself
    @editable
    Starter:starter_device = starter_device{}

    @editable
    Gate:barrier_device = barrier_device{}

    OnBegin<override>()<suspends>:void =
        # Await is an async call; OnBegin has suspends, so this is legal
        Racer := Starter.RaceStartEvent.Await()
        Gate.Disable()
        Print("Starting gun fired - barrier open!")

Read the whole chain against Blueprints: the player presses the starter button → the OnPressed graph runs (in Blueprints, that Custom Event lights up) → RaceStartEvent.Signal(Agent) is Call Dispatcher, taking the player along → over on the other side, the exec line parked on Await wakes up holding Agent → Gate.Disable() opens the way. Note that the slot on gate_device references your own starter_device: in the editor, drag the starter in and the two are paired — the same gesture as dragging an Actor reference in Blueprints.

One semantic point deserves care: when several exec lines Await the same event at once, the wake-up order — and whether one awaiter or all of them wake — is described inconsistently across doc versions. When you need the deterministic "one broadcast, every listener hears it" behavior, register several handlers with Subscribe instead of having several wires each Await the same event. That also matches your Blueprint instinct: every Bind on an Event Dispatcher gets notified.

Your turn. The walkie-talkie below is missing its two key moves: one shouts (Call Dispatcher), one waits. Fill in the code words:

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

# Walkie-talkie: press the button and the patrol gets the code word instantly
relay_device := class(creative_device):

    @editable
    GoButton:button_device = button_device{}

    GoEvent:event() = event(){}

    OnBegin<override>()<suspends>:void =
        GoButton.InteractedWithEvent.Subscribe(OnGo)
        WaitForGo()

    OnGo(Agent:agent):void =
        # Shout (the equivalent of Call Dispatcher)
        GoEvent.____()

    WaitForGo()<suspends>:void =
        # Park here until someone shouts
        GoEvent.____()
        Print("Code word received - move out!")

5. Why Events Beat Tick

One requirement — "open the door when the player presses the button" — two ways to write it. The polling version looks like this:

# ✗ Polling (sketch): the equivalent of stuffing logic into Event Tick,
#   asking "pressed yet?" every frame. ButtonIsPressed is a logic field you
#   maintain yourself; this is here only to contrast the shapes.
PollForPress()<suspends>:void =
    loop:
        if (ButtonIsPressed?):
            OpenDoor()
        Sleep(0.0)

# ✓ Event-driven: register once, let the engine do the rest
OnBegin<override>()<suspends>:void =
    Bell.InteractedWithEvent.Subscribe(OnRing)

The polling version runs about 30 times a second (Lesson 23's simulation-frame rhythm), and in a typical match all 30 of those do the same thing: confirm "not pressed." The event version might run twice the whole match — because the player really did press twice. The gap isn't a few percent, it's orders of magnitude. And it scales with the number of objects: twenty doors means twenty exec lines spinning every frame.

Latency and correctness are the bigger problem, though. Polling notices a state change one frame late at best, and it only ever sees "what the state is now," never "what just happened" — a player who presses and releases within one frame slips straight through polling, while an event catches every single one. This is why Unreal performance write-ups have repeated the same sentence for decades: don't use Tick if you can avoid it. The advice carries into Verse word for word; Tick just goes by another name here — "a Sleep(0.0) in a loop body."

The engineering advice for a Blueprint author, in three lines:

• Default to events. "Do something when X happens" — first look for an existing event to Subscribe to; if there isn't one, declare your own event(t) and have the upstream Signal it.
• Only continuous quantities earn a per-frame loop. Interpolation, smooth movement, progress bars — things that genuinely differ every frame — are worth a loop + Sleep(0.0). And exit the loop when the job is done instead of idling all match.
• "Wait for one thing to happen" is Await, not a loop. An Await arm plus a Sleep arm inside a race is Lesson 24's timeout recipe — far cleaner than checking "how many seconds left" every frame.

6. Common Pitfalls: On the Wiring Floor

This lesson's pitfalls share one trait: half of them live outside the code. Walk the checklist and save yourself hours.

• ▢ Code is perfect, panel is unwired. The number one trap: forgetting to drag an actual object into the @editable slot in the Details panel. Compile all green, then the moment you enter the game — an "accessing invalid object" runtime error. @editable only opens the slot; the wiring is a manual drag in the editor — the very same mistake as leaving a Blueprint Actor reference variable unassigned.
• ▢ An @editable field with no default value. Instant Compile red. Reference-typed fields must be placeholdered with an empty archetype like = button_device{}.
• ▢ The handler's signature doesn't match. Dropping the agent parameter, or typing it as player, both fail Compile. Signatures come from the official API — never guess. In Blueprints the wire simply wouldn't connect; in Verse this is that same refusal, spelled as an error.
• ▢ Dropping Sleep / Await straight into the handler. It is the run-to-completion kind and cannot hold nodes that wait. The right move: spawn a new wire from inside it and let that wire wait.
• ▢ Subscribing to the same event repeatedly. Subscribe again and again inside a loop or a repeatedly-executed spot and the handlers stack up — one press fires N times. Exactly what repeated Bind Event does in Blueprints. Either subscribe once, or Cancel() first and re-subscribe.
• ▢ Changed the code, panel didn't change. You forgot to push / rebuild the Verse code, so the editor cannot see the new @editable field. Also, renaming an @editable field can drop references already configured on the panel — re-drag them.
• ▢ Expecting native devices to "see" your custom event. An event(t) declared in Verse never appears in a native device's event dropdown — only other Verse code can Signal / Await / Subscribe it.

Blueprint Cross-Reference

Almost every concept in this lesson has a same-named thing in Blueprints. The differences column is the one that matters.

The differences come from two things. One: Blueprints let the act of connecting a wire guarantee signature matching — if it doesn't fit, it doesn't connect. Verse has no wires, so that guarantee moves to the compiler, and you meet more red text, earlier. Two: Verse has <suspends>, so an event gains a way of being consumed beyond "register a callback" — parking an exec line on it. Blueprint's Bind has no such form, because a Blueprint exec line cannot stop.

And one place where Blueprints are genuinely handier, credit where it's due: the Event Dispatcher panel lets you open up "who bound to me." Verse has no such view — to learn how many subscribers an event has, you search the code. That is one of the prices text code pays for compile-time safety.

Level Challenges

Wiring practice complete — three challenges to cash it in. Zero penalty for wrong answers; retry as often as you like.

Further Reading