Your First Verse Class: From Blueprint Class to .verse File

1. The Same Move, Two Ways to Make It

Start by recalling the workflow you already know. You want a door that opens by itself, so: right-click in the Content Browser → Blueprint Class → pick a parent in the dialog (Actor, say) → name it BP_MyDoor. A new asset appears in the Content Browser; double-click it and you see three places: the Event Graph in the middle, the Variables section of the My Blueprint panel on the left (the variables panel), and the Details panel that lights up on the right whenever you select a node or a variable.

Doing the same thing in Verse looks like this: create a plain text file called my_door.verse, write one line inside it — my_door := class(creative_device): — then indent and write the variables and the events underneath.

Put the two side by side and the mapping is strict:

• “create a new class” → write one line in the file: name := class(parent):;
• “pick a parent” → the name inside the parentheses;
• “add a variable in the variables panel” → a field, indented one level under the class;
• “drag a chain of nodes off Event BeginPlay in the graph” → a function called OnBegin inside the class, plus the lines indented one level under it.

Exactly one thing does not map one-to-one, and it is worth memorizing on its own: in Blueprint, “asset” and “class” are the same object — one .uasset file is one class, and two classes means two assets. In Verse the file is just a container: a .verse file may hold one class, or five classes plus three functions and an enum. The file name does not even have to match the class name (the official style is to keep them the same so things are easy to find). “One file, one class” is a habit in Verse, not a rule.

One more difference to file away now: a Blueprint asset is binary — only the Unreal editor can open it — while .verse is plain text, openable in Notepad and diffable line by line in Git. That has real consequences for collaboration, and it gets its own extra page at the end of this lesson.

2. Part by Part: A Minimal Verse Class

The nine lines below are a complete Verse class that compiles and runs. Every step you take in Blueprint, it takes too:

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

my_door := class(creative_device):

    DoorName:string = "North Gate"
    var OpenCount:int = 0

    OnBegin<override>()<suspends>:void =
        Print("{DoorName} is in place")

1. using { /Fortnite.com/Devices } — which asset libraries this class may reach into

The job of those using lines is to announce “the code below needs things from these libraries”. /Fortnite.com/Devices is where creative_device lives; /UnrealEngine.com/Temporary/Diagnostics is where Print lives. Without the using, the compiler will not recognize the names you use below.

Blueprint has no move that looks exactly the same; the closest thing is the question “which asset libraries can this Blueprint reach into” — you enable a plugin in project settings, or a module’s assets are visible in the Content Browser, and only then do its nodes turn up in the right-click search box. The difference is that Blueprint spreads every available node in the engine out in front of you, while Verse asks you to name them one by one at the top of the file. That explicitness buys readability: one glance at the file header tells you what this class depends on. The full rules for using — modules, paths, name collisions — are the next lesson’s subject.

2. my_door := class(creative_device): — create a Blueprint Class and pick its parent

This line is the equivalent of the asset you get after clicking through “Blueprint Class → pick Actor → name it BP_MyDoor”. It breaks into three pieces:

• my_door — the class name, i.e. what you typed into the naming box. Verse class names use lower_snake_case (all lowercase + underscores), the rule laid down by the official Verse Code Style Guide; the Blueprint habit is PascalCase with a prefix, like BP_MyDoor. The two naming conventions do not line up, so don’t force one onto the other;
• := — read it as “is defined as”. The name goes on the left; what that name actually is goes on the right. Note it is not the same as a bare =: in Verse = compares things, and defining something new always takes :=;
• class(creative_device) — “I am a class, and my parent is creative_device”. The name in the parentheses is the parent you picked in the new-Blueprint dialog. Want a different parent? In Blueprint you go to Class Settings → Parent Class dropdown; in Verse you change that one word.

The trailing colon plus a 4-space indent on the next line is the old rule from last lesson: indentation is ownership. Every line indented deeper belongs to this class.

3. Fields inside the class — the variables panel

DoorName and OpenCount, indented one level, are the class’s fields — they are the Variables section of the My Blueprint panel. Translated word for word, DoorName:string = "North Gate" says: add a variable, name it DoorName, set Variable Type to String, set Default Value to “North Gate”.

The difference sits in the word var. A Blueprint variable can take a Set node from birth; Verse is the other way around — it is immutable by default, and if you want a value changed at runtime you must write var in front of the declaration. So DoorName is an engraved name tag, and var OpenCount is a slot whose contents change while the game runs. The full story of constants, variables and set is Lesson 8; here you are just learning the faces.

4. OnBegin<override>()<suspends>:void = — Event BeginPlay

This is the line where newcomers consider quitting: six parts crammed together. But the whole line says exactly one thing — “I am overriding the parent’s Event BeginPlay”. One part at a time:

For now the memorization strategy is blunt: learn this whole line verbatim. Its official meaning is “override this function to add custom logic when the game experience begins”. Incidentally, OnBegin has a twin — OnEnd<override>():void = — which runs when the experience ends and carries no <suspends>.

Snap the four pieces together: using is this class’s list of asset libraries, class(parent) is creating the asset and picking its parent, the fields are the variables panel, and the OnBegin block is the event graph. Everything you spend a few minutes clicking through in the Blueprint editor is nine lines of text here.

3. How to Actually Run It: Today That Means UEFN

The class is written — how do you make it move? Two things must be kept apart here: how a class is written is a rule of the Verse language, while how it is mounted, compiled and placed into a world is a rule of the runtime environment. The first is stable; the second will change.

Today, the only place that genuinely runs Verse is UEFN (Unreal Editor for Fortnite) — Verse has been running in UEFN production since March 2023. So the four steps below are the operating manual for today’s runtime, not the lesson’s subject matter:

1. In UEFN’s Verse Explorer panel, right-click your project name → Add new Verse file to project, and choose the Verse Device template. It generates a .verse file containing exactly the skeleton from the last section;
2. Write the class into it, go back to UEFN and press Ctrl+Shift+B (Build Verse Code in the Verse menu). Note that it compiles every .verse file in the project at once — unlike Blueprint, where each asset compiles on its own;
3. Once the build succeeds, my_door shows up in the Content Browser. Drag it into the level exactly as you would a Blueprint asset — only instances actually placed in the level execute, and dragging in two gives you two copies of the logic running independently;
4. Click Launch Session, and whatever Print writes appears in the Output Log panel and on the game screen.

Why must you write class(creative_device) before it can be dragged into a level? Because in today’s UEFN, creative_device is the parent class of “things that can be placed in a level” — and that requirement comes from Fortnite as a runtime, not from the Verse language. Verse is perfectly happy to let you write an ordinary class that inherits nothing; it just cannot be dragged into a Fortnite level.

This is exactly the layer that changes tomorrow. In UE6, Epic merges UE5 and UEFN into a single engine and brings Scene Graph — a gameplay framework built on Verse from the ground up, replacing the Actor inheritance tree with entity + component. Under that framework, the class you write is attached to an entity as a component rather than inheriting creative_device and being dragged in (Lessons 26–27 cover this in detail). UE6 Early Access targets the end of 2027; Actor and Blueprint are fully supported in UE6 Early Access and the early releases, and deprecation waits until Scene Graph is mature enough — with no date announced.

But notice what changes: the mounting mechanism — what the parent is called and how the thing enters the world. name := class(parent):, fields as variables, <override> as “override a parent event” — the way a class is written does not change by a single character. What you drill in UEFN today is what you use directly in UE6 tomorrow.

4. Line by Line: The Moment the Class Wakes Up

Snap this lesson’s parts together and watch it wake up one line at a time. The my_door below has two extra lines: three seconds after the opening it bumps OpenCount by one and reports again. Hit “Run Next Step” — every note tells you which Blueprint move that step is.

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

my_door := class(creative_device):

    DoorName:string = "North Gate"
    var OpenCount:int = 0

    OnBegin<override>()<suspends>:void =
        Print("{DoorName} is in place")
        Sleep(3.0)
        set OpenCount += 1
        Print("{DoorName} open count: {OpenCount}")

Compare lines 7 and 8. Both are “add a variable in the variables panel”, but Verse forces one extra decision out of you: is this value ever going to change? Only then do you write var. Anyone opening your class can see at a glance which values are fixed and which are live.

Blueprint Cross-Reference

Break “build a class” into six moves and line the two sides up. The differences column is the point.

Nearly all of these differences grow from the same root: Blueprint stores classes as binary assets and keeps them correct through editor UI; Verse stores classes as plain text and keeps them correct through the compiler. You cannot pick a nonexistent parent class in Blueprint because the dropdown only lists real ones; in Verse you can absolutely mistype a parent name, so the compiler has to catch it at build time. By the same logic, the <override> badge is unnecessary in Blueprint — the Override menu is itself the proof. Text loses the protection of UI, so it buys it back with explicit declarations.

The second root is compilation granularity. Blueprint assets compile separately, and one broken Blueprint does not bother the others; Verse compiles the whole project in one pass, which exposes cross-file errors immediately at the cost of letting a typo in any one file halt everything. That is why “reading compiler errors” is a required course in Verse rather than an elective — see this lesson’s first extra page.

5. Level Challenge ★

One fill-in-the-blanks plus three multiple-choice questions. Correct answers earn stars; wrong answers retry freely, no punishment.

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

# Create a class whose parent is creative_device
my_gate := ____(____):

    # Override the parent's Event BeginPlay
    OnBegin<____>()<suspends>:void =
        Print("My first Verse class is online!")

Further Reading