From Actor to entity: The Scene Graph Worldview

1. The Language Is Done — Now the Framework

Take stock of the loot: variables and types, if and failure contexts, for and loop, array and map, functions and classes, suspends and concurrency, events and subscriptions. All 25 lessons taught the Verse language itself. A language is neutral: it doesn't care whether you use it to write a door, an enemy, or a scoreboard.

But a language has to land on some framework before it becomes a game. The framework you've used for twenty years is called Actor: everything in the world is an Actor, Actors are organized by inheritance, and behavior lives in Blueprint classes. The new framework UE6 brings to the table is Scene Graph — Epic describes it as a unified structure that connects all the objects in the world, and it is built from scratch on Verse. Not a Verse skin over Actors; a new foundation.

So let's be upfront about the stakes. Actors and Blueprints are fully supported in UE6 Early Access (targeted for the end of 2027) and in the early releases — the Blueprint assets you have open right now are not going to vanish one morning when a version number ticks. Deprecation waits until Scene Graph is sufficiently mature, and no date has been given; Epic has committed to shipping conversion tools before anything is retired, but they are not released yet. So this chapter isn't an evacuation drill. It's a tour of the new floor plan.

And you can tour it today: Scene Graph is already available in UEFN, where the official docs label it Beta — the wording is roughly "learn to use this feature, but be careful shipping with it". Which means you really can drag an entity into a level, add components to it, and write your own Verse component. Just don't expect every corner to be polished yet.

2. The Inheritance Tree: The Pit Every Blueprint Author Knows

First, a refresher on your current worldview. You have a BP_Door that opens and closes. Today the designer walks over: the lobby door needs to glow. You have three options:

1. Change the parent. Stuff the glow logic into BP_Door — and now all 47 doors in the project have sprouted a glow toggle they will never use.
2. Make a subclass. New BP_GlowingDoor extending BP_Door, glow added. Looks clean. Until next week, when the designer wants a glowing treasure chest — and chests descend from BP_Chest, so the glow logic gets written a second time, or copy-pasted.
3. Add an Actor Component. Build a BPC_Glow and attach it to whatever needs to glow. This one is right — it is the seed of the whole Scene Graph idea — except that in the Actor world it's a workaround, not the default posture.

Walk two more steps and the pit takes shape. The designer keeps going: a glowing door, a glowing chest, a glowing door that also slides along a rail, a moving platform that doesn't glow, a breakable glowing door… An inheritance tree is a tree, and requirements are a net. Paving a net with a tree has exactly two endings:

Ending one: the God class. To avoid repeating yourself you build BP_InteractableBase and pour glow, movement, breakability and pickup into it, gated by a fistful of booleans. Three months later it has 2,000 nodes and 31 variables and nobody dares touch it. Change one line and 47 doors, 12 chests and 8 platforms all enter the test matrix.

Ending two: the diamond. You want something that is "both a movable thing and an interactable thing" — and those two capability lines each have their own parent class. Blueprints don't do multiple inheritance, so you pick one side as the parent and patch the other in with an Actor Component or a copy-paste. Either choice feels wrong. That's the classic "diamond problem".

Neither pit is unique to Blueprints. They are the inevitable result of organizing by "what it is". As soon as you have more than one axis of classification (can it move × can it be used × can it take damage), a single inheritance line stops being enough.

3. Composition: An Empty Container Plus a Stack of Ability Cards

Scene Graph swaps the organizing principle: don't classify — assemble.

Per the official docs, an entity is "a container for components or other entities", and "an empty entity will have no visible effects or functionality". Read that twice. An entity is not "the new name for Actor" — an empty Actor still ships with Tick, with BeginPlay, with a long inherited membership roll. An entity out of the box does nothing at all. It's a pure mounting point.

So where does capability come from? Components. The official definition: components "provide data and behavior to an entity", and "the combination of components added to an entity define what that entity is doing in the scene". Components have editable properties, which can be physical (a static mesh, a particle system) or logical (a gameplay tag, or custom Verse code of your own).

Which makes the answer to "I want a thing that opens and glows" almost anticlimactic: add two components. A glowing chest? Put the same glow component on the chest's entity. A moving platform? Add a movement component. Whatever abilities you want, add those cards — no parent class to pick, no inheritance tree to rearrange, and no 47 doors dragged into your test matrix.

Two rules to bank right now, because you will hit both repeatedly:

• One entity holds at most one component of a given type. The docs put it plainly: you can only add one of a given component class or subclass. Want two lights on one object? Make two child entities and hang one light on each.
• Entities come with a transform component by default (location, rotation, scale) — things have to be somewhere, after all. The docs do note that entities constructed in Verse don't get one automatically.

Here's a quick look at what a component actually looks like written down. The skeleton below follows Epic's Verse component template; the details (what <final_super> means, when each lifecycle function fires) are Lesson 27's job. For now, just take in the shape:

using { /Verse.org/SceneGraph }
using { /Verse.org/Simulation }
using { /UnrealEngine.com/Temporary/Diagnostics }

# An "ability card": works on any entity you attach it to
greeter_component := class<final_super>(component):

    @editable
    Message:string = "Chest in position"

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

Note that last sentence: this card doesn't know what it's attached to. That is the entire magic of composition — and its entire cost. The upside is the card fits anything. The downside is you can no longer tell at a glance what an object does; you have to read the Details panel card by card. How that ledger balances out is in the extras at the end.

4. Three Nouns: entity / component / prefab

The new framework doesn't ask you to learn many words. Three, essentially. One sentence each, then how they nest:

The relationship between the three is containment, not inheritance: a prefab holds a tree of entities, and each entity holds a list of components. The docs are direct about it — a prefab is a stable object that uses a hierarchy of entities and components to hold the base information all its instances share; edit the prefab in the Prefab Editor and save, and every instance adopts the change automatically. That last part feels a lot like editing a Blueprint parent and watching instances follow. You can also override an individual component on a single instance, and the overridden card gets flagged in the UI.

Two more landmarks so you don't get lost in the Outliner. There is one simulation entity at the very top of each project, and the whole scene is nested underneath it. And the prefabs you author are exposed as classes in your project's Assets.digest.verse, so Verse code can reference and spawn them. What the hierarchy actually looks like, and how the lifecycle runs, is in the extra entity / component / prefab: how the three fit together.

5. Rewriting "Is" Into "Has"

Memorizing three nouns is easy. Changing how you talk is not. The Blueprint author's default sentence is: "this thing is an interactable, it extends the interactable base class." The Scene Graph sentence is: "this thing has a mesh, has an interaction, has a loot drop."

Let's practice. Take the BP_TreasureChest your project definitely contains — it glows, the player presses E to open it, it drops three items, and the lid has an opening animation. Old sentence: it "is a subclass of an interactable Actor." New sentence: it has these capabilities:

Look at row four: the lid's animation goes on a child entity, not on the chest body. Why? Because the lid needs to rotate on its own, and a transform is one per entity. "Any part that needs to move independently gets its own entity" is the most-used instinct in this framework.

Two more. Think for ten seconds before reading the answer:

Exercise A: BP_HealingFountain — a fountain with a water VFX that heals you continuously while you stand in it, with a sound each tick.
Breaks into: a mesh (the basin) + a particle system component (the spray) + a sound component (the heal audio) + one custom Verse component (detect who is inside the radius, heal per second). Note that "healing" and "spray" got separated: swapping the art asset doesn't touch the healing logic, and tuning the numbers doesn't touch the VFX.

Exercise B: BP_MovingPlatform_Glowing — a glowing platform sliding back and forth along a rail.
Breaks into: mesh + light + movement component. Three cards, one job each. Now the designer wants "a glowing platform that doesn't move" — remove the movement card, done, no new class required. That's the final answer to the glowing-door problem this lesson opened with.

One self-check while you rewrite: if the name you just wrote for a component contains a noun like "door", "chest" or "enemy", you probably split it wrong. Ability cards should be named after verbs or adjectives (glows, can be used, drops loot). Nouns belong to entities and prefabs; verbs belong to components.

6. Blueprint Cross-Reference

Every concept in this lesson has a counterpart in Blueprints. The differences column is the point — plenty of these words look familiar while occupying an entirely different position.

Where do the differences come from? From swapping the organizing principle. The Actor system organizes the world by classification: everything belongs to a class, and classes share code through parentage. Scene Graph organizes it by assembly: everything is an empty shell, and capability is bolted on. The first answers "what is it", the second answers "what does it have" — every difference in the five sections above falls out of that single change of axis.

One practical difference worth stating plainly: the Actor system has twenty years of tutorials, plugins and muscle memory behind it, while Scene Graph is currently marked Beta in UEFN. This chapter teaches you to read the new floor plan. It is not telling you to move house tonight.

7. Level Challenge

New worldview assembled — three mini-challenges to sign off on it. Correct answers earn a star ★; wrong answers can be retried forever, zero penalty.

Further Reading