Actor/Component vs entity/component: Same Name, Different Thing
Both sides have a word called "component", and they mean quite different things. The Blueprint world is an inheritance tree: an Actor grows capability by deriving subclasses, and components are its accessories. The Scene Graph world is composition: the entity is nearly an empty shell, and components are everything. This page pins down that difference — and sets up Chapter 8.
1. Getting the Status Straight First
To avoid any misreading halfway through, here are the facts:
Scene Graph is the new gameplay framework Epic built for UE6, constructed from the ground up on Verse, where entities hold components — and it is already usable in UEFN today. At the same time, Actors and Blueprints are fully supported in UE6 Early Access (targeting late 2027) and the early releases after it; deprecation waits until Scene Graph is mature enough, with no date set. Epic has committed to shipping conversion tools before any deprecation, but they have not been released.
So this page is not "learn the new one, throw out the old one". It addresses a more practical problem: while both systems coexist and share the word "component", don't treat them as the same thing.
2. The Inheritance Model: How an Actor Grows Capability
Think back to your own projects. A door: BP_Door. A door that locks: right-click BP_Door → Create Child Blueprint Class → BP_LockedDoor. A door that locks and plays a VFX when it opens: derive one more layer. Capability is inherited downward: a subclass automatically has everything the parent has, plus a bit of its own.
The upside is obvious: BP_LockedDoor definitely "is a door", so anywhere that accepts a door will accept it. The trouble is just as obvious — sooner or later the requirement arrives: "I want a door that glows, and also a chest that glows." Where does the glow logic go? Into BP_Door, and the chest can't use it; into both, and you'll fix one and forget the other; up into a shared parent, and that parent slowly bloats into a monster that does everything. An inheritance tree only has one trunk, and requirements grow sideways.
Actor Components exist precisely to relieve that pressure: make "glow" a component and attach one to the door and one to the chest. But note — in the Blueprint world, that's one of two available routes. The Actor itself is still a derivable class, logic can live on the Actor or on the Component, and both styles coexist indefinitely. Which is why every team relitigates "should this go on the Actor or in a Component?" over and over.
3. The Composition Model: The entity Is a Shell, the component Is the Content
Scene Graph settles that argument by cutting one route away: only components remain.
An entity is a node in the level with almost no behavior of its own — it has an identity, a transform, and parent/child relationships, and that's it. It isn't there for you to derive from: you don't write "a door entity subclass". To make it a door, you attach components: one for the mesh, one for interaction, one for the open/closed state.
So the question "what is this thing?" shifts its answer from "which class does it derive from" to "which components does it have". A glowing door and a glowing chest? Each gets a glow component, done — no shared parent class, and no need for one.
A component is itself a Verse class, shaped much like the device class you'll write in Lesson 6: it has @editable fields (which show up on the Details panel) and lifecycle entry points. The snippet below shows only the shape, to give you a feel — Scene Graph's exact interfaces are still evolving, so treat the official docs and Chapter 8 as authoritative:
using { /Verse.org/Simulation }
# A component is a Verse class, attached to some entity
spinner_component := class(component):
@editable
DegreesPerSecond:float = 90.0
OnBegin<override>()<suspends>:void =
loop:
# rotate a little each frame (transform APIs in Chapter 8)
Sleep(0.0)
Attach that component to a door and the door spins; to a chest and the chest spins; to a lamp and the lamp spins. It never needs to know what it's attached to — which is exactly where composition earns its keep.
4. One Word, Five Differences
Side by side:
| Question | Blueprints: Actor + Actor Component | Scene Graph: entity + component |
|---|---|---|
| What is the host? | A derivable Actor subclass that already carries plenty of capability | An entity with almost no behavior — identity, transform, hierarchy |
| Where does logic live? | On the Actor or in a Component; both routes coexist | Components only |
| How do you add capability? | Derive a subclass, or attach a component | Attach a component |
| What answers "what is it"? | The inheritance chain: it's a BP_LockedDoor, therefore it's a door |
The component list: it has an interaction component and an open/close component, therefore it behaves like a door |
| What is it written in? | C++ or Blueprint node graphs | Verse — the framework itself was built from the ground up on Verse |
Look at row four. It's the easiest to overlook and the most consequential: in the inheritance model "what it is" is an identity the compiler guarantees; in the composition model "what it is" is an observation, dependent on which components are currently attached — and components can be added and removed. Neither is better; they're two ways of answering, and they lead to entirely different thinking while you write.
5. What This Means for You
One: check the vocabulary and the date before you trust an article. A UEFN Verse tutorial that's all creative_device with no entities or components is describing what runs today — fine, but it doesn't cover Scene Graph. Conversely, an article full of entity/component is describing where UE6 is headed. Both are true today; just don't mistake either for the whole picture.
Two: you can practice "decomposing into components" right now. No need to wait for UE6. Open any Actor Blueprint of yours that's stuffed with logic and, on paper, break it into three to five independent chunks — this one handles movement, this one health, this one triggering VFX. Projects that decompose cleanly will migrate as mere manual labor; the ones that don't are where the real trouble sits, up in the inheritance tree.
Three: don't rush to rebuild an existing project. Actors and Blueprints are fully supported in UE6 Early Access and the early releases after it, and Epic has committed to conversion tools that have not shipped yet. Until that tooling lands, hand-refactoring ahead of time buys far less than it risks. What you should be investing in now is understanding, not rework.
Composition over inheritance, and Scene Graph's complete worldview, are the subject of Chapter 8. That's where we'll actually write a component.
6. Quick Check
In Scene Graph, what decides "what this thing is"?
Sources
Compiled from Epic's official documentation: Blueprints Visual Scripting (official docs) ↗ · Verse Language Quick Reference (official docs) ↗
Statements about UE6, Scene Graph and the Blueprint deprecation timeline follow Epic's public remarks at State of Unreal 2026 and the official roadmap: UE6 Early Access targets late 2027, Actors and Blueprints are fully supported in EA and the early releases after it, and conversion tools are committed but not yet released.