Where Verse Came From: A Functional, Logic and Imperative Hybrid
Many of Verse’s rules are not designer whim; they are ancestry. This page pulls apart its three bloodlines — imperative gives you the familiar execution order, functional gives you immutable by default, logic gives you “goes through / does not” — then explains why transactional memory and structured concurrency are necessities for online worlds rather than showpieces.
1. Three Bloodlines, One Language
Programming languages are like cuisines: the flavor is largely decided by who taught the cook. What is rare about Verse is that it serves dishes from three traditions at once — and makes no attempt to hide it.
- ▢ Imperative: you already know this one. “Do this, then do that” — the white execution wire in Blueprints is imperative programming made visible. Verse keeps this side intact: the lines inside
OnBeginrun top to bottom, no mystery involved. This is the part you do not have to pack when you move. - ◇ Functional: treat computation as a juicer. Ingredients in, juice out, and the machine keeps nothing. This tradition’s creed is “mutate less, return more,” and Verse inherits from it both “data is immutable by default” and “changing a value requires an explicit
set.” You have actually seen a small enclave of it in Blueprints: those green Pure nodes with no execution pins that only take inputs and yield outputs. What Verse did was turn that enclave into the home field. - △ Logic: the one bloodline that needs a new intuition. It does not care about “how to compute it step by step”; it cares about “what conditions hold.” Verse’s most head-tilting designs all live here: a lone
=is a comparison that can fail, not an assignment;iftakes not true / false but “does this path go through”;forwalks the entire space of successes an expression yields. There is no Blueprint counterpart — this is the only new taste you have to acquire.
Hence Epic’s label for Verse: a functional logic language. The first two words describe its skeleton, and the imperative side survives so that gameplay authors can still express “order of operations” the natural way. You will find that the closer you stay to gameplay, the more familiar Verse looks; the deeper you go, the more its functional and logic personality shows.
2. The Verse Calculus: The Bare Machine Underneath
In 2023, Simon Peyton Jones, Tim Sweeney, Lennart Augustsson and co-authors published “The Verse Calculus: a core calculus for deterministic functional logic programming” at ICFP, the premier functional programming conference. It is rare enough for industry to write a formalization paper about its own scripting language; rarer still is the author list, with the language’s boss and a grandmaster of functional programming signing side by side. (Peyton Jones joined Epic as an Engineering Fellow in December 2021 to work on the design.)
What the paper does fits in one sentence: the Verse calculus is Verse stripped down to its skeleton — the minimal core. Peel away every convenience that merely makes code comfortable to write, and this bare machine is what remains; everything that happens in the language ultimately reduces to its handful of rules.
The core holds three things, each matching an “odd rule” from the main lessons:
- ◇ Variables are bound by unification. A variable is not “a box holding a value” but “an unknown waiting to be solved,” and running a program feels a bit like solving equations — making both sides hold. That is why a lone
=is a failable equality, while stuffing a value into a variable (the Set node in Blueprints) is written separately asset. - △ A computation can yield several values. A result is not necessarily single; it may be a “choice space” of candidates. And
for(the ForEach Loop from Blueprints) is at heart walking that string of successful values one by one. - ▢ The whole language is deterministic. The same program only ever runs to one and the same outcome, never varying with internal evaluation order. For an engine that wants to pack thousands of logic pieces into one world, that is not academic fastidiousness — it is whether anyone can sleep at night.
You do not have to read the paper to write Verse. But knowing the bare machine exists tells you these rules were not made up on the spot — behind them sits a group of people who have written compilers and proved theorems for decades, making trade-offs.
3. Transactional Memory: The World Steps Forward Whole, or Not at All
Epic has a compact way of describing Verse: it “transactionalizes C++”. “Transaction” is borrowed from databases: a piece of logic either takes effect as a whole or rolls back as a whole as if it never happened, with no half-changed state in between.
In Blueprint terms: imagine Verse first wiring and running the logic on an invisible “shadow graph.” Only if the whole thing goes through does the change actually land in the game world; get stuck one step in and it is as if the shadow graph was never wired, leaving the world untouched.
Why is this a necessity in a multiplayer online world? In single player, “gold deducted, item not granted” means the player restarts a match at worst. But in a world that never shuts down and is shared by many, a half-finished state is immediately seen by other people and treated as truth to compute from — they trade based on wrong inventory, and the trade triggers somebody else’s logic. Errors in an online world do not sit still; they spread. Transactionality cuts that chain at the language level: any piece of logic affects the world atomically — all of it, or none of it.
4. Structured Concurrency: Every Kite Gets Tied to a Post
The other headline feature is concurrency. You have already used asynchronous things in Blueprints: Delay, Timeline, all those Latent nodes with a little clock icon. What they have in common is that once you pull one out, it runs somewhere you cannot see — and cleaning it up, say stopping it when a player leaves mid-match, is basically down to you remembering.
Structured concurrency demands exactly that be remembered: every execution line spawned must have clear ownership and a defined ending, and when its parent task finishes it does not turn into an orphan still running. Verse builds this into the syntax — spawn (let it run on its own), race (several lines race, the first to finish wins), sync (several lines run together, continue when all arrive). Lesson 24 takes them apart one by one.
An analogy: starting a Delay in Blueprints is like letting a kite go — whether you keep hold of the string is up to you. Structured concurrency rules that every kite must be tied to a specific post; pull the post and the kite comes back. In a world where players leave whenever, matches end whenever, and content hot-updates whenever, unattended async tasks are where memory leaks and ghost logic come from — “the countdown belonging to a player who left five minutes ago just broadcast to the whole server” is not a bug you want to debug.
Tying the three sections together: the hybrid ancestry gives Verse its expressive power, transactionality gives it safety, and structured concurrency gives it order along the time axis. Only with all three in hand does “Scene Graph, built on Verse from the ground up” become a sentence Epic can say about UE6.
5. Quick Check
Saying Verse is “transactional” most accurately means what?
Sources & Further Reading
This page draws on the paper page, a public talk, and Epic’s official news: