Deep Dive · EXTRA

Where .verse Files Live and How They Get Referenced

In the main lesson you wrote one class in one .verse file. But no project stays at one file — does the second class get a new file or go into the existing one? How do classes in two different files see each other? This page settles how Verse code is organized in a project, then puts plain-text .verse next to binary .uasset to see what that difference actually buys you.

1. Where Verse Code Lives: The Tree in Verse Explorer

UEFN has a dedicated panel called Verse Explorer, and what it shows is a tree of every .verse file in your project, rooted at the project name. That “right-click the project name → Add new Verse file to project” from the main lesson simply hangs a new file on this tree.

This tree consists of real folders and files on disk — it is not a view the editor invents. You can find them in your file manager and open them in Notepad, and the contents are exactly the characters you see in VS Code. That is quite unlike the Content Browser, where the path (/Game/...) is an engine-side virtual path and the assets are binary packages.

Worth noting: a .verse file is not an “asset”. It does not appear in the Content Browser and cannot be dragged into a level. What gets dragged into a level is the build output — your class only shows up in the Content Browser as a placeable entry after Build Verse Code runs. Source and output are two separate things, which is one of the most structural differences between Verse and Blueprint.

2. Files and Modules: The Folder Decides Visibility, Not the File

The question beginners most often ask wrong is “my class is in file A, how does file B use it?” — because the subject of that sentence is wrong. The unit of visibility in Verse is not the file, it is the module; and a module is a folder in Verse Explorer.

Creating a folder in Verse Explorer creates a module, and the module’s name is the folder’s name;
Several .verse files in the same folder belong to the same module — their definitions are naturally visible to each other, with no using required;
Only when you want something from a different folder do you write a using at the top of the file, pulling that module’s path in;
Your project’s own module path begins with the creator name and project name, in the shape /YourName@fortnite.com/YourProject/Folder — the same path system as the /Fortnite.com/Devices you saw in the main lesson, except those are libraries Epic supplies.

So “one file, one class” in Verse is purely an organizational habit, not a syntax requirement: five classes in one file and five files in the same folder have identical visibility. You split files so humans can find things, not to make the compiler happy.

Note: the module hierarchy rules were adjusted once in UEFN 23.20, so older tutorials may not line up. The full syntax of using and modules is the next lesson’s subject (Lesson 7); here we are only installing the one mental model: folder = module.

Side by side with how Blueprint references things

Blueprint	Verse	Difference
Any Blueprint can reference any other asset by asset path (`/Game/...`)	To use something from another module you must first write a `using` at the top of the file	Blueprint references are per asset and created on demand; Verse visibility is per module and must be declared explicitly
Content Browser folders are just tidiness and do not affect who can reference whom	Verse Explorer folders are module boundaries and directly determine visibility	Move an asset to another folder in Blueprint and references survive; move a file to another folder in Verse and it has changed modules
One asset is one class; “several classes in one file” does not exist	One file may hold any number of classes, functions and enums	Verse lets you keep a cluster of small related classes in a single file, which Blueprint cannot do

3. .verse vs .uasset: One Is Text, One Is Binary

Now for the thing this page actually wants you to remember. BP_MyDoor.uasset is a binary file: outside the Unreal editor, no tool can read it meaningfully. my_door.verse is plain text: openable in Notepad, copyable, searchable, comparable line by line.

That difference sounds technical, but what it really decides is how you and your teammates work together:

This	Blueprint asset (`.uasset`, binary)	Verse source (`.verse`, text)
What opens it	Only the Unreal editor	Any text editor
Seeing a change in version control	You know “this file changed”, not what changed	Line by line: what was added, removed, which word changed
Two people editing the same thing	No automatic merge; usually one version wins	Different regions merge automatically; conflicts can be resolved by hand
Typical collaboration strategy	Exclusive checkout: whoever is editing it, nobody else touches it	Everyone edits, then merges
Code review	Mostly screenshots and verbal description	Inline comments, line by line
Letting an AI read and write it	Essentially impossible	Read and edited directly (the subject of Lesson 30)

None of this says Blueprint got something wrong. Binary assets buy graphical editing and engine-level reference checking, and those are real capabilities. But if you have ever been ground down by Blueprint merge conflicts on a team, you will immediately see why Epic is building its next-generation gameplay framework on a text language.

One reality check: a UEFN project does not become an all-text project just because you write Verse. Levels, meshes, materials and audio are still binary assets — only the logic layer went textual. So a real project is a hybrid: code follows the text workflow, art follows the asset workflow. That is also why “logic in Verse, content in assets” is such a profitable split today.

In your project, door.verse and lock.verse sit in the same folder. lock.verse wants to use a class defined in door.verse. What does it take?

4. Sources

This page is distilled from Epic’s official documentation and developer forums: