constructor vs Archetype: Two Ways to Build Objects

1. Where Direct Archetype Fill Hits Its Limit

Archetype instantiation is "filling out a spec sheet": you write what goes into each field, item by item, inside the braces. It's simple, intuitive, and Compile even goes red to remind you when you miss a field — but it can only fill values, not compute the "derivation relationships" between them. Picture a boss generator: the designer wants to hand over a single parameter, "level", and have the name, health, and attack all derived from it. Written as an archetype, every place that uses it has to work out all three by hand: boss{Name := "Dragon Lv.5", Health := 500, Attack := 50} — the conversion formulas end up scattered across every call site, where fixing one spot misses three others. A textbook bug nursery.

What you need is to package the "one parameter → several fields" conversion logic into a named entry point. That's exactly where the constructor earns its keep.

2. <constructor>: The Function That Doesn't Look Like One

Constructor syntax has two counter-intuitive quirks — watch closely: first, it doesn't declare "what type comes out"; instead it uses := to point straight at the class it builds. Second, the body doesn't hold ordinary logic nodes either — it fills in initial values for the fields, one line each:

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

boss := class:
    Name:string
    var Health:int = 100
    var Attack:int = 10

# Constructor: <constructor> after the name, no return type, := points at the class name
MakeBoss<constructor>(Level:int) := boss:
    Name := "Dragon Lv.{Level}"
    Health := 100 * Level
    Attack := 10 * Level

spawn_device := class(creative_device):

    OnBegin<override>()<suspends>:void =
        # Archetype: great for simple direct fill
        Grunt := boss{Name := "Grunt"}
        # Constructor: one parameter derives three fields
        Dragon := MakeBoss(5)
        Print("{Dragon.Name} enters the arena with {Dragon.Health} HP")

Translating the drawing: the top half builds a boss blueprint with three variables, Name / Health / Attack. In the middle, MakeBoss<constructor>(Level:int) := boss is a dedicated entry point for building bosses: feed it one Level, and inside it works out the name, health, and attack from the level and fills them all in at once. The bottom half makes the contrast obvious: boss{Name := "Grunt"} is the old way (direct fill in the braces); MakeBoss(5) is the new entry — hand it a single 5 and all three stats are derived automatically.

From now on every place that needs one just writes MakeBoss(5), and the conversion formula lives in exactly one place; a level-10 boss is one argument away. And you're not limited to one — the official docs are explicit: a class may have multiple constructors. Giving each scenario its own named entry point is a very comfortable pattern: MakeEnemyGrunt(), MakeEnemyBoss(Level:int)… the name is its own documentation, and callers see at a glance what's being built. The official Constructor in Verse page also stresses: constructors and archetypes are two different things: a constructor bundles a "reusable initialization recipe" into one entry point, while an archetype is "fill the braces right where you stand" — they complement each other; it's not either-or.

3. Which One? And Why Building Objects in Verse Needs No "new" Keyword

The selection rule fits on a sticky note: direct values → archetype; derived logic → constructor. Unpacked — field values ready-made, each initialization site different, one-off use in place: archetype. Initialization involving conversion or validation, one recipe reused in several places, readable names wanted for different configurations: constructor. The two also coexist happily: direct fill for the simple spots, MakeXxx for the complex ones, no friction between them.

Finally, the question everyone arriving from code asks: why no new? Because in Verse, writing boss{Name := "Grunt"} already "equals" a finished instance — as naturally as writing 1 + 1 equals 2; there's no need to shout "I want to new an object" on top. Constructors are the same: they don't hand over the instance by shouting return — the whole function body is a smarter spec sheet that "describes" the instance into being. Get that, and you've got the whole philosophy of object creation in Verse: objects aren't "new-ed up" — they're described into existence.

One honest boundary note: how a subclass constructor chains to its parent's constructor gets little ink in the official docs, so this site won't expand on it for now — when experimenting, let the Verse API Reference and Compile's actual verdict be your source of truth.

4. Pop Quiz ◇

Sources & Further Reading

This article draws on the official Epic documentation:

▸ Official docs: Constructor in Verse ↗

▸ Official docs: Class in Verse ↗