Verse’s Three Design Principles: It’s Just Code / Just One Language / Metaverse First
The Verse rules that make Blueprint authors frown — immutable by default, changes require set, indentation is syntax — nearly all trace back to one of three sentences. This page explains those three design principles, so that every odd rule you meet later shifts your reaction from “what on earth” to “why did they choose this.”
1. It’s Just Code: No Second Source of Truth Hidden in a Panel
In a mature Blueprint project, the truth about one feature is usually spread across three places: the wires in the event graph, a few checkboxes on the Details panel, and possibly a data table. Before changing a behavior, you first have to remember which places to go look. Veterans are immune to this by now, but the spread is not free — the bill comes due for whoever inherits the project.
Verse takes a hard line: if it can be expressed in code, it does not go in a panel. A property you want to expose to level designers is written by attaching an @editable to the field (covered in Lesson 22). It is first and foremost a line of code, and only incidentally a fillable box on the Details panel — the panel is a projection of the code, and the truth stays in the file.
The benefits are plain, and every one of them is worth money: a feature can be explained by one file; a change is a few lines of diff rather than two screenshots to compare; a whole piece of logic can be pasted to a colleague, into a code review, or to an AI assistant. It comes with a real cost, too — Verse has no Blueprint-style visualization of the execution wire lighting up at runtime, so you lean on Print and the output log instead. Epic made that trade with eyes open: a little immediacy, exchanged for “the code is the whole truth.”
2. Just One Language: One Language All the Way Down
The typical Unreal project has an unspoken dividing line: Blueprints for gameplay, C++ for the performance-sensitive or low-level parts, and a binding layer stitching the two together. So everybody maintains two mental models and two debugging workflows, and has to keep track of which side a given function lives on. That line is exactly what blocks many Blueprint authors: going one level deeper means learning an entirely different language first.
Verse aims to remove the seam: one language that has the writing feel of a scripting language and still holds up at the systems level. A single Print("hi") just runs — that is the scripting side. Strong typing, a compiler that stops whole classes of errors up front, and side effects spelled out in the signature — that is the systems side.
This explains why the first impression of Verse feels slightly contradictory: the syntax looks far leaner than C++, yet the rules are stricter than most scripting languages — data is immutable by default, changes require an explicit set, and whether a function can suspend, can fail, or can mutate world state is declared in the signature with effect specifiers (Lesson 22). It is not making life hard for you; it is explaining the same thing to humans and to the compiler at once.
What that means for you in practice: the ceiling and the floor are in the same language. There is no more “once I get good at C++ I’ll go touch the low-level stuff” — going deeper uses more of the same syntax, not a different one.
3. Metaverse First: Assume Ten Thousand Graphs Are Running at Once
This is the least intuitive of the three, and the one that explains Verse’s personality best. Picture a world that never shuts down: logic written by thousands of authors who have never met runs simultaneously, players come and go at will, and content updates at any time. In that setting, “a piece of logic failed halfway through” is not a rare incident; it is a daily occurrence.
So Verse wrote the answer into the language itself, mainly in two pieces:
- ◇ Transactionality: a piece of logic either takes effect as a whole or rolls back as a whole, as if it never happened — never leaving a half-finished state like “gold deducted, item not granted.”
- △ Structured concurrency: running several lines at once does not mean spawning your own threads and remembering to clean them up. The language has
spawn/race/syncbuilt in (Lesson 24), with defined ownership and lifetimes.
There is a third layer: no sneaking changes into state. Data is immutable by default, changes require an explicit set, and module-level mutable state has to be accounted for per player (Lesson 8’s extra covered weak_map). When you are the only author, these rules feel like nagging. When your code is one of ten thousand people’s, they are the only thing that lets anybody sleep.
In Blueprint terms: Blueprints assume “this graph is mine and the world answers to me”; Verse assumes “this graph is one of ten thousand running right now.” Two assumptions that different are bound to produce languages that look different.
4. Using the Three Principles to Explain the Odd Rules Ahead
This table is worth flipping back to as you go. Whenever a rule feels uncomfortable, first ask which principle it comes from.
| A rule you will meet later | Which principle | Why |
|---|---|---|
Data is immutable by default; mutability requires var |
Metaverse First | “Anyone can change anything” is where trouble starts in a shared persistent world |
Changes require set; a lone = is a comparison |
Metaverse First + It’s Just Code | Every state change must leave an explicit trace in the code, never happen quietly through a wire |
| No braces and no semicolons; indentation is the code block | It’s Just Code | Layout and structure become one thing — reading the code is reading the structure |
Device properties use @editable rather than a panel checkbox |
It’s Just Code | The panel is only a projection; the truth stays in the file |
| Functions declare what they do with effect specifiers | Just One Language | One language serving both gameplay and systems level has to state its contracts plainly |
| Failure is not an exception but “this path does not go through” | Metaverse First | Failure has to be rollback-able before you dare run thousands of logic pieces in one world |
spawn / race / sync are built into the language |
Metaverse First | In a persistent online world concurrency is the normal case, not an advanced topic |
As a side note, these three principles also explain why Epic is building Scene Graph on Verse from the ground up in UE6. A world model of “entities with components attached” inherently demands clear boundaries between components, no sneaky cross-mutation of state, and disciplined concurrency — which is exactly Metaverse First expressed at the framework level. The language and the framework grew together; nobody picked a framework first and then shopped for a language.
5. Quick Check
“Immutable by default, changes require an explicit set” most directly serves which design principle?
Sources & Further Reading
This page draws on Epic’s public materials and public talks by the language designers: