Deep Dive · EXTRA

entity / component / prefab: How the Three Fit Together

The main lesson introduced the three nouns one at a time. This page puts them side by side: what contains what, whose lifecycle starts first, and how the tree you see in the Outliner grows. Definitions quote Epic's docs where possible; the API member lists come from the official Verse API reference.

1. Three Definition Cards

Get the official definitions straight first — everything below follows from these three sentences:

Noun	Official definition (in substance)	Key property
`entity`	A container for components or other entities; an empty entity has no visible effects and no functionality	Nestable. Comes with a transform component by default (except entities constructed in Verse)
`component`	Provides data and behavior to an entity; the combination of components on an entity defines what it is doing in the scene	Not nestable (components don't hold components). One per type per entity
`prefab`	A stable object that uses a hierarchy of entities and components to hold the base information all its instances share	Instantiable many times; edit the prefab and every instance follows; an individual instance can override a component

Read those three and the containment relationship falls out, and it is strictly layered:

prefab ⊃ tree of entities ⊃ the component list on each entity.

Note that all of it is containment; not one link is inheritance. This is where Blueprint authors most often skid: seeing "edit the prefab and every instance follows" makes you reflexively file prefab under "parent class". It isn't. A parent and child class say "you are a kind of me"; a prefab and its instance say "you are a copy stamped from me". The feel is similar, the mechanism is not.

2. What That Tree in Your Level Looks Like

At the very top of each project sits one simulation entity, and the scene is nested underneath it. Parent entities govern the appearance and behavior of their children. Drawing the chest from the main lesson, it comes out roughly like this:

Outliner hierarchy sketch

simulation entity              ← project root, one per project
└─ Level                        entity
   └─ P_TreasureChest           entity (prefab root)
      │  · mesh_component        the chest body
      │  · light_component       a faint glow around it
      │  · interactable_component the player can press to use it
      │  · chest_loot_component   ← your own Verse component
      │
      └─ Lid                    entity (child: the lid)
         · mesh_component        the lid mesh
         · keyframed movement    the lid swings on its own

Three things to read out of that sketch:

The lines prefixed with · are components, not child nodes. They hang off that entity without occupying a slot in the hierarchy — only entities live in the hierarchy.
Why does the lid get its own level? Because the lid must rotate independently of the body, and a transform is one per entity. "Any part that needs to move independently gets its own entity" is the highest-frequency instinct in this framework. Same reasoning for two lights on one object: split into two child entities, since one entity holds only one component of a given type.
The whole P_TreasureChest block can be saved as a prefab. After that, every copy you drag into the level is an instance of it; edit it once in the Prefab Editor and all instances follow. Components you override on a single instance get flagged in the UI to show that instance has drifted from the template.

One more thing that matters if you write code: the prefabs you author are exposed as classes in your project's Assets.digest.verse, so Verse code can reference them, instance them and attach them to the scene. That's the seam between "level assets" and "code" in the new framework.

3. Lifecycle: Who Wakes First, Who Sleeps Last

A Blueprint author's mental model of lifecycle is about three words long: BeginPlay, Tick, EndPlay. Scene Graph stretches that chain a little. Per the official API reference, these are the lifecycle functions on the component class:

Function	When	Nearest Blueprint relative
`OnAddedToScene`	When the component is added to the scene	Roughly the construct/register stage, earlier than BeginPlay
`OnBeginSimulation`	When the component begins simulating	Closest to Event BeginPlay, but scoped to "this component"
`OnSimulate`	The component's asynchronous update logic	Like trading Tick for a long-running block marked `<suspends>`
`OnEndSimulation`	When the component ends simulation	Event EndPlay
`OnRemovingFromScene`	Just before the component is removed from the scene	A teardown hook even later than EndPlay

Your intuition about ordering is safe here: into the scene first, then simulating; end simulation first, then leave the scene. That (super:)OnBeginSimulation() line in the main lesson's stepper is this system's etiquette — when you override a lifecycle function, run the parent's version first. Epic's template and doc examples all write it that way.

component also carries two data members you'll use constantly: Entity (the entity this component belongs to, i.e. your window onto the world from inside a component) and TickEvents (pre-physics and post-physics per-frame callbacks). Plus a set of state and operation functions: IsInScene, IsSimulating, RemoveFromEntity, and the scene-event pair SendDown and OnReceive.

On the entity side, the functions group into four bundles by purpose:

Hierarchy: GetParent, GetEntities, AddEntities, RemoveFromParent
Components: GetComponent, GetComponents, AddComponents
Scene events: SendUp (up the hierarchy), SendDown (down the hierarchy)
Tags: AddTag, RemoveTag, ContainsTag, ContainsAnyTag and friends

Both classes live in the /Verse.org/SceneGraph module — which is why the first line of a custom component is using { /Verse.org/SceneGraph }. This page lists names and purposes only; for the exact signatures, failability (square brackets versus parentheses) and effect specifiers, defer to the official Verse API reference, and expect them to shift while the feature is in Beta. Actually calling these is Lesson 27's job.

4. The One-Line Comparison

Flatten all three against the Blueprint world and the cheapest way to remember it is:

A prefab is the asset you double-click; an entity is a row in the Outliner; a component is a card on the Details panel.

The reason the Actor era only had two levels (the asset, and the row in the Outliner) is that the "card" level got eaten by inheritance — capability hid in parent classes and never appeared on the panel. Scene Graph moves it back onto the panel. The cost is a longer panel. The benefit is that what an object does is written on its face.

5. Quick Quiz

A chest needs the body to stay put while the lid swings open on its own. How should the lid be arranged in Scene Graph?

Sources

Compiled from Epic's official documentation and Verse API reference: Getting Started in Scene Graph in Fortnite (official docs) ↗ · Prefabs and Prefab Instances in UEFN (official docs) ↗ · Verse API: the entity class (official docs) ↗ · Verse API: the component class (official docs) ↗

The hierarchy sketch is a teaching illustration drawn by this site from the definitions above, not official artwork; exact function signatures are a question for the official API reference. Scene Graph is currently marked Beta in UEFN, and details may change between releases.