Writing a Component: What a Blueprint Component Looks Like as Code

1. A Component Is Just a Class

First, compress last lesson into one sentence you can carry: an entity does nothing on its own; what it can do depends entirely on which components you put in it. A visible block is "entity + mesh_component". A block that glows is "entity + mesh_component + light_component". No inheritance tree, no "subclass of XxxActor" — only assembly.

Which turns the question into: where do abilities come from? The built-in ones (meshes, lights, collision, particles) are already written by Epic — you just pick them off a list. But when your list of desired behaviors has a gap — say "this platform rises every two seconds and then comes back down" — you have to write a component yourself.

The good news is that writing a component means writing a Verse class. The class syntax from Lesson 20 carries over unchanged; only three things are Scene Graph specific: what you inherit from, which specifier you attach, and which lifecycle functions you override. Here is a minimal skeleton that actually runs. Look at it whole first; we'll take it apart in the next section:

using { /Verse.org }
using { /Verse.org/Native }
using { /Verse.org/SceneGraph }
using { /Verse.org/Simulation }
using { /Verse.org/SpatialMath }

hello_component<public> := class<final_super>(component):

    @editable
    Greeting<public>:string = "hello"

    OnBeginSimulation<override>():void =
        (super:)OnBeginSimulation()
        Print("{Greeting}")

A dozen lines and a custom component exists. Map it onto what you already know: this is equivalent to creating a new Blueprint whose parent class is Actor Component, adding a String variable Greeting in the variables panel with Instance Editable ticked, and wiring a Print String onto its Event BeginPlay. The only difference: that side is three panels and some wires, this side is one text file.

2. Dissecting the Skeleton: Four Positions Worth Memorizing

▢ Part one: using. Same as Lesson 7 — using is "pull open a drawer". The Scene Graph API lives in /Verse.org/SceneGraph; time-related things like Sleep live in /Verse.org/Simulation; vector3 and transform live in /Verse.org/SpatialMath. When the editor generates a component file from its template these lines are written for you — all you need to know is which missing line makes which batch of names "unrecognized".

▢ Part two: the type declaration. This single line is the densest thing in the lesson:

hello_component<public> := class<final_super>(component):
#      ▲              ▲          ▲             ▲
#      name       who can use   Scene Graph's  inherits from the
#                    it         hard rule      component base class

• hello_component: the class name, snake_case. This exact name shows up in UEFN's Add Component dropdown.
• <public>: an access specifier making the class referable across the whole project (Lesson 22 covered this family).
• class<final_super>: <final_super> is a hard requirement of Scene Graph — the official docs describe it as a requirement that preserves the integrity of the entity/component system. Copy it verbatim in custom components; leaving it out will not compile.
• (component): inherits from the component base class. That's the "parent class: Actor Component" dropdown when you create a Blueprint.

▢ Part three: fields. Ordinary Verse fields, written exactly as in Lesson 8. The only new thing is the extra line above them: @editable. With it, the field appears in the Details panel; without it, it is purely internal data. Hold that thought — the next section expands on it.

▢ Part four: lifecycle callbacks. This is the only genuinely new idea in a custom component. A Blueprint Component gives you two or three entry points (Event BeginPlay / Event EndPlay). Verse slices it finer: a component passes through a series of stages from creation to destruction, and each stage has an overridable callback. The official docs list the stages as: Initialized → AddedToScene → BeginSimulation → EndSimulation → RemovingFromScene → Uninitializing. In the Verse API, these are the ones you'll override most:

Two ordering guarantees are worth burning in: OnBeginSimulation always runs before OnSimulate, and OnSimulate is cancelled before OnEndSimulation. So "prepare" in the former and "perform" in the latter is the officially recommended split.

One more rule that trips people up: overriding requires the <override> specifier, and the first line of the body should call the parent's implementation — written (super:)OnBeginSimulation(). That's the auto-generated Parent node you get when you override an event in Blueprint: you can leave it unwired, but most of the time wiring it is correct.

▢ Bonus: Entity. Every component carries a constant named Entity pointing at the entity that holds it. It's the always-available GetOwner from a Component graph. Moving your own object, finding another component on the same object — everything starts here.

3. @editable: Getting a Property into the Details Panel

Anyone who has shipped Blueprints knows this need cold: a "lift platform" component, and a designer who wants to tune how high it goes and how long it waits. You can't recompile every time a number changes. Blueprint's answer is to tick Instance Editable (the little eye) on the variable, which drops it into the Details panel so every instance placed in the level can hold a different value.

Verse's answer is one extra line above the field: @editable.

editable_demo<public> := class<final_super>(component):

    # Shows up in the Details panel; each instance can hold its own value
    @editable
    Height<public>:float = 200.0

    @editable
    Loops<public>:logic = true

    # No @editable: purely internal data, invisible in the panel
    InternalTag:string = "lift"

Three rules. First, @editable is an attribute — it starts with @ and sits on the line above the field. Don't confuse it with <public> or <final_super>, which are specifiers written inside angle brackets; those are two different systems. Second, an editable field must have a default value, and that value is what the panel shows initially. Third, changing a value on one instance in the level only affects that instance — the official wording is that the change applies to that instance alone, other instances are untouched, and no recompile is needed. That is exactly Instance Editable semantics.

While we're here, let's map the other Blueprint habit: variables also have Expose on Spawn, which adds a wireable input pin to the Spawn Actor node. Verse has no switch by that name — either you fill the value in the Details panel, or you assign the field directly when you construct the instance in code (my_component{ Height := 300.0 }). The latter is what "pass parameters at spawn time" looks like as code.

Which types may be marked @editable, plus range-limited variants like @editable_slider and @editable_number and the syntax for panel categories and tooltips — all of that is collected in this lesson's technique extra.

4. Bolting the Component onto an Entity

The class is written. How do you make it actually do something? The answer is almost insultingly familiar: click Add Component in the Details panel and pick it from the list.

The official flow goes like this: select an entity in the scene, in its Details panel click Add Component > New Verse Component, choose Scene Graph Component from the Verse code templates, type a component name (say my_verse_component), and click Create. UEFN generates the .verse file for you — the skeleton above — and attaches the component to the current entity at the same time. After that you edit the code in VS Code, compile, and the behavior updates.

Once a component compiles, it lives permanently in the Add Component list: any entity in the scene can pick it, no differently from picking mesh_component or light_component. Your abilities and Epic's abilities are equal citizens in that panel.

There is also a code path: entity exposes AddComponents(), letting you attach component instances at runtime. That corresponds to Blueprint's Add Component by Class node — "grow an ability after the game is already running". In day-to-day work, though, the overwhelming majority of components are attached in the editor; code assembly is reserved for genuinely dynamic cases.

One last rule that's easy to miss: an entity may hold only one component of a given class (or its subclasses). Want two meshes on one object? You can't — the correct move is to add a child entity and put the second mesh there. This is a visible break from the Blueprint habit of hanging five Static Mesh Components off one Actor, and it will stop you short the first time you hit it.

5. A Complete Example: A Platform That Rises and Falls

Bolting the first four sections together gives a component you could actually ship: a platform that rises to a given height, waits, comes back down, and repeats. It needs two @editable parameters (how high, how long) and two lifecycle callbacks. Click "Run next step" and watch the component go from attached to performing.

using { /Verse.org }
using { /Verse.org/Native }
using { /Verse.org/SceneGraph }
using { /Verse.org/Simulation }
using { /Verse.org/SpatialMath }

lift_platform_component<public> := class<final_super>(component):

    @editable
    Height<public>:float = 200.0

    @editable
    WaitTime<public>:float = 2.0

    OnBeginSimulation<override>():void =
        (super:)OnBeginSimulation()
        Print("Lift platform ready")

    OnSimulate<override>()<suspends>:void =
        loop:
            Entity.SetLocalTransform(transform{Translation := vector3{Up := Height}})
            Sleep(WaitTime)
            Entity.SetLocalTransform(transform{Translation := vector3{Up := 0.0}})
            Sleep(WaitTime)

Read it back: there is not a single line of boilerplate for "register with the engine" or "subscribe to Tick". You overrode two functions; Scene Graph handles the rest — it knows when to call you, exactly the way Blueprint knows when to fire your Event BeginPlay.

Attach this component to an entity that has a mesh_component and you have a moving platform. Attach the same component to ten different entities and fill in a different Height on each one's Details panel and you have ten platforms at ten heights — one piece of code, ten behaviors. That's what "composition over inheritance" looks like on a Tuesday.

A practical heads-up: the official docs note that component logic runs in both edit mode and play mode, meaning any behavior you add starts running the moment you launch your session. That's a different split from Blueprint's Construction Script versus BeginPlay, so the first time you see a platform moving on its own inside the editor, don't file a bug.

Blueprint Cross-Reference

Every action in this lesson has a counterpart you already perform daily. The differences column is the point.

Why do these differences exist? The root is the fork from Lesson 26: a Blueprint Actor is an inheritance tree with components bolted on; a Scene Graph entity has no tree at all — it is a basket, and all meaning comes from the components inside it. Since everything is composition, the engine has to be extremely explicit about "when is a component available" — hence six lifecycle stages; and it has to treat "component not found" as a normal outcome — hence GetComponent being failable.

Another layer of difference comes from the medium. A visual editor inherently communicates "which parameters are tunable"; in a text file, that has to be stated explicitly by something like @editable. You'll notice that most of Verse's "extra words" buy the same thing: legibility in plain text.

And to repeat this site's factual discipline: Actors and Blueprints are fully supported in UE6 Early Access (targeting late 2027) and the releases after it; deprecation waits until Scene Graph is mature enough, and the timing is undecided. You are learning components not because Blueprint disappears tomorrow, but because this is the same craft written another way — and that way is the new framework's native language.

Challenge Gauntlet

Component written; three checks to pass. Zero penalty for wrong answers, retry as often as you like.

Further Reading