Verbs: Functions, Events & Effects

In Part 3 you got comfortable with nouns — the things you name. Now they start doing things. This lesson is about verbs: the actions in your game. End the round. Eliminate a player. Open the door. Add a point.

There are three ideas here, and they build on each other:

1. A function is a named action you can run.
2. An event is the game shouting "this just happened!" — and you can subscribe to react: when X, do Y.
3. Effect specifiers are little labels on a verb that warn you what it's allowed to do — wait, fail, or change things.

A function is a named action

<!-- section-art:a-function-is-a-named-action -->

Function Lever

A function packages up some steps and gives them a name, so you can run them whenever you want by calling that name. You met the shape in Part 1; here it is again, read as a sentence:

EndRound() : void =
    Print("Round over!")

"EndRound is an action that takes nothing — () — and gives back nothing — void — and what it does is print a message." The () is where inputs go (none here). void is the output type, and void means "gives nothing back." The steps below, indented, are the body — exactly the block-belonging idea from Part 2.

To run it, you call it by writing its name with ():

EndRound()

Functions earn their keep when they take inputs and give back an output. Inputs are nouns, written Name : Type, just like Part 3:

AddScore(Player : agent, Points : int) : void =
    Print("Awarding points")

"AddScore is an action that takes a player and a number of points, and gives nothing back." Now you can run it for anyone: AddScore(SomePlayer, 10). One verb, reused everywhere — that's the whole point of naming an action. Our project rules push hard on this: break big jobs into small, focused functions that each do one thing.

An event is "this just happened"

Games don't just run top to bottom — they react. A player presses a button. A player gets eliminated. A timer ends. Each of those is an event: a moment the game announces so your code can respond.

You react by subscribing to the event with .Subscribe(...), handing it the function to run when the event fires. Read it as plain English: when this event happens, do this function. You saw this in Part 1:

StartButton.InteractedWithEvent.Subscribe(OnStartPressed)

"When StartButton's interacted-with event happens, run OnStartPressed." InteractedWithEvent is a real event that every button_device gives you. OnStartPressed is a function you wrote to handle it.

There's one small grammar wrinkle worth knowing now, because it bites everyone. Device events are subscribed directly, but character events need empty () first:

# Device event — no () before Subscribe
StartButton.InteractedWithEvent.Subscribe(OnStartPressed)

# Character event — () before Subscribe
FortChar.EliminatedEvent().Subscribe(OnEliminated)

That second line reads: "when this character's eliminated-event happens, run OnEliminated." The pattern is the same — when X, do Y — only the punctuation differs between device and character events. (Our project convention is to also keep the subscription around so you can cancel it later when you're done listening, but you can grow into that.)

A handler function usually receives information about what happened. An elimination handler is handed the agent involved:

OnEliminated(Result : elimination_result) : void =
    Print("A player was eliminated")

You don't memorize EliminatedEvent or elimination_result — you read the sentence, see they belong to a character, and look them up when you need them. That's the Part 1 promise paying off.

Effect specifiers: what a verb is allowed to do

<!-- section-art:effect-specifiers-what-a-verb-is-allowed-to-do -->

Verb Power Blocks

Here's the idea that makes Verse special, and once it clicks you'll see the language differently. A verb can carry effect specifiers — little labels in angle brackets < > that warn you, right in the verb's signature, what kind of power it has. It's like the rarity color on loot: before you even use it, the label tells you what you're dealing with.

You read them as part of the function's sentence. Here are the four that matter, in plain language:

<suspends> — "this verb can wait"

A <suspends> verb is allowed to pause and wait for time to pass or for something to happen, then carry on. Anything that involves waiting — a countdown, a delay, waiting for a round to end — needs this label.

CountdownThenStart()<suspends> : void =
    Sleep(3.0)
    Print("Go!")

"CountdownThenStart is an action that can wait; it sleeps for 3 seconds, then prints Go." Sleep is a real verb that pauses for a number of seconds — and because it waits, any function that calls it must itself be marked <suspends>. The label is contagious on purpose: it keeps the "this can pause" fact honest all the way up. Think of it like the storm timer — the code can sit and let real time pass before the next thing happens.

<decides> — "this verb can fail"

A <decides> verb might succeed or fail, and Verse forces you to deal with both outcomes — you can never accidentally use a result that wasn't actually there. This is the honest-failure idea from the option type in Part 3, now as a verb.

Because a <decides> verb can fail, you call it with square brackets [ ] instead of ( ), usually inside an if that runs only on success:

if (FortChar := SomeAgent.GetFortCharacter[]):
    Print("This player has a live character")

"If getting the Fortnite character for this agent succeeds, name the result FortChar and use it; otherwise skip." GetFortCharacter is a real <decides> verb — it can fail when the player has no character right now (they just left, or haven't spawned) — and the [ ] is your visual cue that this call might not work out. (This is exactly the project rule: <decides> calls use [ ], ordinary calls use ( ).) Looking something up that might not be there — a player who left, an empty chest — is the classic <decides> job.

<transacts> — "this verb changes things"

A <transacts> verb is allowed to change game state — to have side effects. Remember set from Part 3, the keyword that moves a variable? Any verb that does that kind of state-changing work is marked <transacts>:

AddScore(Player : agent)<transacts> : void =
    set CurrentScore += 1

"AddScore is an action that changes state; it bumps the score up by one." The label is a promise to everyone reading: this verb touches the game's state, it doesn't just compute a number. And like <suspends>, it travels upward — a function that calls a <transacts> function must be <transacts> too.

One honest caveat our project rules call out: despite the name, Verse does not actually roll changes back if something goes wrong partway. So the discipline is to check everything first, then make your changes — validate, then act — so you never leave the game half-changed.

computes — "this verb just figures something out"

A verb with no effect labels is the calmest kind: it only computes — takes inputs, works out an answer, gives it back, and changes nothing. Pure arithmetic, a bit of logic, a formula:

BonusPoints(Streak : int) : int =
    Streak * 100

"BonusPoints takes a streak and gives back a number; it just multiplies, nothing else." No <transacts> because it changes nothing; no <suspends> because it never waits; no <decides> because it can't fail. The absence of labels is itself information: this verb is safe and simple.

Reading the labels together

Put them side by side and the labels become a quick character sheet for any verb:

When you see a verb's signature, read the labels first. They tell you, before you read a single step of the body, whether this action waits, fails, or changes the world. That is an enormous amount of meaning packed into a few small words — and it's grammar you can read, not trivia you have to memorize.

Why this helps you direct an AI

Effect labels are where directing a helper gets powerful. You can say: "write a <suspends> function CountdownThenStart that sleeps 3 seconds then starts the round," or "make a <decides> function that looks up a player's score and fails if they have none." Those instructions are precise because the labels pin down exactly what the verb is allowed to do. A helper that gets the labels wrong writes code that won't compile — and now you know enough to catch it.

Quick recap

• A function is a named action: Name(inputs) : OutputType = then its steps. Call it with ().
• An event is "this just happened." React with .Subscribe(handler) — when X, do Y. Device events subscribe directly; character events need () first.
• Effect specifiers label what a verb may do: <suspends> can wait, <decides> can fail (call with [ ]), <transacts> changes state. No label = it just computes.
• Effect labels travel upward: call a <suspends>/<transacts> verb and your verb needs the same label.

Next: Part 5 — The Rules That Keep Verse Honest, which gathers the conventions behind everything you've learned into rules you can follow — and use to direct an AI correctly.

How a verb's effect label tells you what it's allowed to do — and how an event drives a function.

References

• Verse Language Reference (Epic)
• Functions in Verse (Epic)
• Specifiers and Attributes in Verse (Epic)
• Grounded in the Verse Cortex knowledge base and our project Verse conventions (.cursor/rules).