Verse Wiki — the Verse handbook for Blueprint authors
Technique · EXTRA

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:

door.verse
# 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:

treasure_chest.verse
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) ↗