Naming Conventions: BP_MyDoor → my_door
UE uses prefixes to tell asset types apart: BP_, S_, E_, BPI_. Verse uses no prefixes at all — it splits the work by casing instead: type names in snake_case, members and functions in PascalCase. Here's a full renaming table, a hands-on exercise, and the details that trip people up.
1. Why UE Needs Prefixes and Verse Doesn't
UE's prefix system was forced into existence by the Content Browser. One folder holds blueprints, materials, textures, structures, enumerations and blueprint interfaces, and the filename is the only clue that tells them apart at a glance — hence BP_, M_, T_, S_, E_, BPI_. It solves the problem of "a pile of assets all mixed together".
Verse doesn't have that problem. A type isn't an asset; it's a line of declaration in a file, and that line already says everything:
# Class, struct, enum, interface — obvious at a glance, no prefix needed
my_door := class(creative_device):
Placeholder:int = 0
player_stats := struct:
Score:int = 0
door_state := enum:
Closed
Opening
Open
openable := interface:
Open():void
So Verse spends its naming budget on something else: using casing to separate "type" from "value". That's the more frequently needed piece of information — you judge "is this name a type or a variable?" hundreds of times a day, while "is this name an enum?" barely comes up twice.
2. Three Rules Are Enough
Rule one: type names are always snake_case — all lowercase, underscores between words. Classes, structs, enums and interfaces alike: my_door, player_stats, door_state, openable. The official API looks the same: creative_device, button_device, weak_map.
Rule two: everything else is PascalCase — fields, locals, constants, functions and methods, all capitalized with words run together: IsOpen, MaxHealth, OpenDoor(). This one barely changes anything: it's already how you name things in the Blueprint variables panel.
Rule three: the module path is the folder path — every folder in the project automatically becomes a module of the same name, and the path in using { /MyProject/Doors } maps to the directory structure. The .verse filename follows the main type it contains, also in snake_case: my_door.verse.
Put together, the effect is: see my_door and you know it's a type; see MyDoor and you know it's a value or a function. Half a file becomes readable without context — something a prefix system can't give you.
3. The Renaming Table
Run your current project through this:
| In UE / Blueprints | In Verse | Why |
|---|---|---|
BP_MyDoor (Actor Blueprint) |
my_door |
Drop the prefix, switch to snake_case |
BP_TreasureChest |
treasure_chest |
Same. Multi-word names get an underscore between every word |
S_PlayerStats (Structure) |
player_stats |
Structs are types too, same rule |
E_DoorState (Enumeration) |
door_state |
Enums, same again |
BPI_Openable (Blueprint Interface) |
openable |
Same. The convention is an adjective or a capability name, with no i prefix |
BP_HealthComponent (Actor Component) |
health_component |
A Scene Graph component class, same rule |
Variable IsOpen |
IsOpen |
No change. Fields and locals are PascalCase |
C++ variable bIsOpen |
IsOpen |
Drop the boolean b prefix — the type is already written as :logic |
Function OpenDoor |
OpenDoor() |
No change. Function names are PascalCase |
Constant MAX_HEALTH |
MaxHealth |
Verse has no all-caps constant convention. Constants look like any other member, because immutable is already the default |
Event Dispatcher OnDoorOpened |
Field DoorOpenedEvent + callback method OnDoorOpened() |
The official API convention is event fields ending in Event (e.g. InteractedWithEvent), with the subscribing callback starting with On |
Asset path /Game/Doors |
Module path /MyProject/Doors |
Folders automatically become modules of the same name |
File BP_MyDoor.uasset |
File my_door.verse |
The filename follows the main type, also snake_case |
4. Renaming Exercise
The device below was translated from a Blueprint asset called BP_TreasureChest, which had a Blueprint variable named IsLocked. Two blanks: one needs its style changed, one doesn't. Think before you type:
using { /Fortnite.com/Devices }
# Blueprint asset BP_TreasureChest — how is the type named?
____ := class(creative_device):
# Blueprint variable IsLocked — does the member name change style?
var ____:logic = true
Unlock():void =
set IsLocked = false
Now do it yourself: translate BP_SpikeTrap, E_TeamColor, S_LootEntry and BPI_Damageable into Verse type names. The answers are spike_trap, team_color, loot_entry and damageable — prefix gone, snake_case throughout, no exceptions.
5. Four Details That Trip People Up
One: don't compensate with suffixes. Having dropped BP_, plenty of people itch to write my_door_class or door_enum. Don't — the declaration line already says class or enum; repeating it is noise.
Two: booleans start with Is / Has / Can. IsOpen, HasKey, CanInteract — each reads as a question with a yes/no answer. The C++ b prefix isn't used in Verse.
Three: treat acronyms as ordinary words. PlayerId rather than PlayerID, HudText rather than HUDText. A run of capitals smears PascalCase's word boundaries, and the reader has to stop and re-parse. Consistency within your team is what matters; the official style guide is the final word.
Four: no spaces or non-Latin characters in names. Identifiers are letters, digits and underscores only. Other languages are fine in comments and string literals; type names and field names stay Latin.
One honest closing note: naming conventions aren't there to please the compiler — MyDoor := class(...) compiles perfectly well. They're there so the next person to open this code (very likely you, three months from now) saves ten minutes. That was true in the Blueprint era; with text code it's only more visible.
6. Quick Check
The Blueprint asset BP_TreasureChest, translated into a Verse type name, should be written how?
Sources
Compiled from Epic's official documentation: Verse Code Style Guide (official docs) ↗ · Verse Language Quick Reference (official docs) ↗