Operators, the Full Loadout: Bind Every Key at Once

1. Arithmetic Operators: Add, Subtract, Multiply, Divide — but Division Has Attitude

+ - * / hold no surprises — they work on both int (whole numbers) and float (decimals). But Verse has one iron rule: both sides must be the same type. Writing 3 + 1.5, mixing a whole number with a decimal, is a straight-up compile error — in Blueprint, when you drag a Float pin into an Integer pin, UE quietly inserts a conversion node to smooth things over; Verse refuses to cover for you — when a conversion is needed, you make it explicit yourself (check the official Verse API Reference for the exact conversion functions). Behind this pickiness is the same creed: types quietly morphing in the dark is exactly the hardest kind of bug to catch.

The one with real attitude is int (whole-number) division. Coins / 2 hides two surprises: first, dividing by 0 means the wire doesn't go through — so integer division has to hang off a Branch check, and when it doesn't go through, execution slips out the else pin (remember last lesson's dice roll?); second, dividing two whole numbers yields not a whole number but a rational, and to get a whole number back you finish the job with Floor (round down) or Ceil (round up).

using { /Fortnite.com/Devices }
using { /UnrealEngine.com/Temporary/Diagnostics }

wallet_device := class(creative_device):

    var Coins:int = 17
    var Speed:float = 3.5

    OnBegin<override>()<suspends>:void =
        set Coins += 3
        set Speed *= 2.0
        Print("Coins: {Coins}")
        # int division can fail (dividing by 0 fails), so it must live in a failure context;
        # the result is a rational — use Floor to get back to int
        if (Half := Floor(Coins / 2)):  # Verify against the Verse API Reference
            Print("Split into two piles of {Half} coins each")

Graph translation: OnBegin is Event BeginPlay — it fires automatically the moment the game starts. The first two lines are two Set nodes — += 3 adds 3 to Coins and *= 2.0 doubles Speed; then a Print String puts the coin count in the top-left corner of the screen. The last part is a Branch: it first floors Coins / 2 to get Half, and only if that step goes through (no division by zero) does execution enter via the success pin and Print how many coins per pile.

One more for the notebook: + isn't just for math. String concatenation (Blueprint's Append node) and array merging (Add on an Array) are its jobs too — set Names += array{"Bubbles"} is one Set node that enqueues Bubbles at the end of the array. One button, multiple combos.

2. Comparison Operators: the Referee Doesn't Say true/false, Just "Pass / No Pass"

The comparison family has six members: equals =, not-equals <>, and the ordering four < <= > >=. Let's nail the most mind-bending part first: they do not spit out a Boolean. As last lesson explained, a Verse Branch doesn't check True/False — it checks "does this wire go through?" — and comparison operators are the main workforce of that kind of check: if the comparison holds, the wire goes through and execution moves on; if it doesn't, the wire is dead and you turn down the else path. The referee holds up no scorecard — they either wave you through or block you.

From that follows a hard rule: comparisons may only sit where "not going through" is allowed (a Branch condition, a ForEach filter clause, inside not…). Write Score = 100 on its own line in a normal spot and it lights up red the moment you hit Compile — an expression that "might not go through" has nowhere left to put its "not going through". This is the number-one pitfall of this lesson; we'll bang the chalkboard about it again in the pitfalls section.

using { /Fortnite.com/Devices }
using { /UnrealEngine.com/Temporary/Diagnostics }

referee_device := class(creative_device):

    var Score:int = 72
    var PlayerName:string = "Bubbles"

    OnBegin<override>()<suspends>:void =
        if (Score >= 60):
            Print("Passed, the referee waves you through")
        else:
            Print("Below the line, run it back")

        # equality is a single =, inequality is <> (Verse has no == or !=)
        if (PlayerName = "Bubbles"):
            Print("Welcome back, Bubbles")
        if (Score <> 100):
            Print("Not a perfect score yet, keep practicing")

Graph translation: this whole snippet is Branch nodes. The first Branch asks "is Score ≥ 60" — if it goes through, the success pin Prints "Passed"; if not, the else pin Prints "Below the line". The next two Branches work the same way: one asks "does the name equal Bubbles" (equality takes just one =), the other asks "is the score not equal to 100" (the not-equals sign is a pair of angle brackets <>).

One more easily missed rule: = is only open to "comparable" types — whole numbers, decimals, logic (that's Boolean), strings, characters, enums (Enumeration assets), plus option / array / map / tuple whose contents are themselves comparable. Ordinary Blueprint instances are not directly comparable with = by default — force it and it goes red the moment you hit Compile; either compare one of its inner fields, or mark the class <unique> so it compares by identity, "is this the same instance?" (a bit like checking whether two object references in Blueprint point at the same Actor).

3. and / or / not, Plus ?: Combo Moves for Conditions

The logical operators are three English words: and, or, not — mapping straight onto Blueprint's AND, OR, NOT boolean nodes. Since comparisons give you "goes through / doesn't go through", these three combine the same currency: A and B only goes through if both wires do; A or B tries A first, and if A doesn't go through, it wipes away whatever changes trying A made, then tries B; not A goes through precisely when A doesn't. Last lesson's "commas in a Branch condition mean and" clicks into place here: if (A, B): and if (A and B): are the same thing.

not comes with a fun fact: whatever sits inside it is always rolled back — whether not as a whole goes through or not, every Set done inside gets undone, as if it never happened. So don't sneak variable changes in inside a not; they won't stick. Also, when A and B goes through, the whole expression actually carries a value (B's value), and A or B carries the value of whichever side went through first — but in practice you almost always use only their "goes through / doesn't go through" to decide where the Branch goes; don't evaluate them like math formulas.

Last up is the query operator, postfix ?: after a logic (Boolean) it asks "are you true?", after an option (that kind of box that might hold something or might be empty) it asks "got anything in there?" — if it's true / there's cargo, it goes through (and hands over the cargo); otherwise it doesn't. It's another one of those "might not go through" expressions, so it likewise has to sit in a Branch-style check position.

using { /Fortnite.com/Devices }
using { /UnrealEngine.com/Temporary/Diagnostics }

combo_gate_device := class(creative_device):

    var HasKey:logic = false
    var Score:int = 80
    var MaybeBonus:?int = option{50}

    OnBegin<override>()<suspends>:void =
        # ? asks a logic: "are you true?"
        if (HasKey?):
            Print("Key acquired")
        else:
            Print("No key yet")

        # combo move: comparison + and + not
        if (Score > 60 and not HasKey?):
            Print("Score is there, just missing a key")

        # ? asks an option: "got anything in there?" If yes, unwrap into Bonus
        if (Bonus := MaybeBonus?):
            Print("Easter egg unboxed: {Bonus} points")

Graph translation: three Branches. The first uses HasKey? as its condition — asking whether this Boolean is true; if yes, Print "Key acquired", otherwise take the else path. The second wires "Score > 60" and "not HasKey?" together with and — only when both hold does it Print. The third is box-opening: MaybeBonus? takes the value out of the box and names it Bonus; only if that works (box not empty) does execution step in and Print the bonus points.

4. The Three = Brothers: := Defines, set Assigns, = Compares

In many text-based languages a single = can both assign and compare — one slip of the finger and you have a classic bug (Blueprint never had this headache: Set variable and the Equal comparison are two different nodes to begin with). Verse simply splits the three jobs across three spellings, and none of them can impersonate another:

Key takeaways: := only does "first introductions" — hit the same name with := again and it's a duplicate definition, going red the moment you press Compile; changing an existing variable answers only to set (the Set node); an = sitting in a normal check position is always treated as a comparison. Also keep the Branch's two faces apart: if (X := Items[0]): is a value binding (grab element 0 of the array — if that works, name it X; if not, take the else path), while if (X = 100): is a comparison (asking whether X equals 100) — one colon apart, completely different meanings. The combo machine below brings all three brothers together; hit "Run next step" and see with your own eyes what every = is doing.

using { /Fortnite.com/Devices }
using { /UnrealEngine.com/Temporary/Diagnostics }

equals_family_device := class(creative_device):

    var Combo:int = 0

    OnBegin<override>()<suspends>:void =
        Reward := 100
        set Combo = 3
        set Combo += 2
        if (Combo = 5):
            Print("{Combo}-hit combo, claim your {Reward} coins")

5. Precedence Cheat Sheet and Common Pitfalls

When several buttons get pressed in a row, which fires first? Just like in math class, Verse operators have precedence. Here's the table from highest to lowest (within a tier, they associate left to right):

Two corollaries you can use right away: not A and B parses as (not A) and B — not only grabs the single thing right after it; and comparisons rank above and / or, so X > 0 and Y > 0 works on intuition, no parentheses needed. For the exact ordering of adjacent tiers (say, ? versus not), defer to the full precedence table in the official Verse Language Quick Reference — and when in doubt, add parentheses. Parentheses are never wrong.

Next up is this lesson's minesweeping manual — every entry is a real compile-error crime scene:

• Using a comparison where "not going through" isn't allowed: write Score = 100 on its own line and it gets blocked the moment you hit Compile — a comparison is an expression that "might not go through", and it may only live where that's allowed: Branch conditions, ForEach filters, inside not. Want to change the value? Write set Score = 100 (one Set node).
• Copying equality syntax from other text languages: some languages spell equality == and inequality != — Verse recognizes neither. Here equality is a single =, and inequality is a pair of angle brackets <>.
• Evaluating and / or like a math formula: Result := A or B hands you "the value of whichever side went through first", not true / false. Combine conditions all you like — but let them stay inside a Branch and decide where execution goes.
• Mutating inside not: whatever sits inside not always gets rolled back — a set (Set node) in there leaves no trace whatsoever.
• Treating whole-number division as plain division: X / Y might not go through (dividing by 0 doesn't), and the result is still a rational, not a whole number — finish with Floor / Ceil, and the whole expression has to hang off a Branch-style check.
• Mixing whole numbers and decimals: 3 + 1.5 goes red the moment you hit Compile — Verse doesn't slip in a conversion node the way Blueprint does; both sides must match.
• Comparing ordinary Blueprint instances with =: instances aren't comparable by default — compare one of their fields, or mark the class <unique> to compare by "same instance" identity.
• Hunting for shorthands like increment and ternary: other languages have ++ (add one) and condition ? A : B (pick one of two) — Verse has neither. Add one with set X += 1; pick one of two with if (C) then A else B (like Blueprint's Select node). Want to "overload operators" for your own types? Not open for business either — the extra page has the full set of workarounds.

Recognition without reps doesn't stick. The energy gate below has had three operators carved out: the magic word for changing a variable (Set), the single-equals equality comparison, and that "angle-bracket not-equals". Fill them back in and hit "Check answers".

using { /Fortnite.com/Devices }
using { /UnrealEngine.com/Temporary/Diagnostics }

energy_gate_device := class(creative_device):

    var Energy:int = 10

    OnBegin<override>()<suspends>:void =
        ____ Energy += 5
        # the equality comparison takes exactly one equals sign
        if (Energy ____ 15):
            Print("Energy is exactly 15")
        # the not-equals sign is a pair of angle brackets
        if (Energy ____ 0):
            Print("Energy is not 0")

Blueprint Cross-Reference

Nearly every operator in this lesson is a node you have wired countless times. The differences column is the point — especially the = row, which is where this lesson most often runs off the road.

The biggest difference fits in one sentence: Blueprint’s Equal node hands you a Boolean you can store and pass around; Verse’s = hands you the pass-or-fail outcome itself. That’s why in Blueprint you can wire an Equal output into a variable and keep it for later, while in Verse a lone line reading Score = 100 is an error — it has no value to give you, only a verdict on whether the wire goes through, and something like a Branch has to catch it on the spot.

The other difference hides in the division of labor between symbols. Blueprint keeps definition, assignment, and comparison physically apart by giving each its own node, so you couldn’t mix them if you tried; Verse is plain text and has to keep them apart with three spellings: :=, set …=, and =. Early on this is your most frequent compile error — but once it sticks, you’ll find it far more direct to read than hunting through a node graph for where that Set node was wired.

Level Challenge ★

Button map complete — into the training arena for three live rounds. Zero penalty for wrong answers; retry as many times as you like.

Further Reading