What FTickableGameObject is

FTickableGameObject is a plain C++ class from Tickable.h that you inherit from alongside UObject. Its constructor adds this to a pending queue (Tickable.cpp:133-145), and the object only moves into the real array at the next tick pass (Tickable.cpp:67-95). The destructor removes it from that array (Tickable.cpp:147-152), and the engine walks the array once per frame (Tickable.cpp:167-208). This is a separate track running alongside the FTickFunction machinery that actors and components use. It is not part of it.

The upside is that the object does not have to be in a world, does not have to be spawned, and has no transform. The price is that it also gets none of what the other track gives actors: no tick groups, no AddTickPrerequisiteActor, no TickInterval. The entire class declaration (Tickable.h:134-210) does not contain a single one of them. You either give up all three or build them by hand.

For an object tied to a world, the call sits in UWorld::Tick (LevelTick.cpp:1792), after TG_PostPhysics (LevelTick.cpp:1749) but before TG_PostUpdateWork (LevelTick.cpp:1848). An actor ticking in TG_PostUpdateWork sees the state this tick has already produced. An object with no world lands somewhere else: it ticks only after the loop over all worlds. The engine says so outright in the comment on the method (Tickable.h:183), and the call itself sits in GameEngine.cpp:1947.

When to reach for this, and when not to

Does this have to be an actor? If the object needs a transform, collision, replication, placement in a level, or tick groups, the answer is “actor” and the rest of this post does not apply. None of those can be bolted onto FTickableGameObject.

Is the logic per-frame or event-driven? If it comes down to “in three seconds” or “every half second” and nothing in between, that is FTimerManager, not a tick. Polling state sixty times a second to respond once is a cost with no return.

Should the object live exactly as long as the world? If so, the right answer is almost always UTickableWorldSubsystem: a ready, tested lifecycle, without a single line of what I describe below. Your own base class earns its place when you need multiple instances (a subsystem is one instance per class per owner by definition), or when a designer is meant to create subclasses in Blueprint, which a subsystem cannot do.

Decision one: when you register

The default answer: in the constructor. Inheritance is enough. The base constructor runs on its own, the object lands in the registry, no extra code.

And that is exactly what you must not do. The constructor documentation says so outright:

If this is something like a UObject that could be created on a different thread (like for async loading), construct with a Never tick type and enable tick later.

— Tickable.h:147 (UE 5.7)

The base constructor in full:

// UE 5.7 — Tickable.cpp:133-145
FTickableGameObject::FTickableGameObject(ETickableTickType StartingTickType)
{
    if (StartingTickType != ETickableTickType::Never)
    {
        // It is only safe to create tickable game objects on the game thread, as otherwise there is a race condition between object initialize and the game thread tick
        // If you hit this ensure, change the constructor to use FTickableGameObject(ETickableTickType::Never) and call SetTickableTickType after initialization
        ensure(IsInGameThread());

        // Queue for creation, this can get called very early in startup
        FTickableStatics& Statics = GetStatics();
        Statics.QueueTickableObjectForAdd(this, StartingTickType);
    }
}

The base constructor runs before the body of the derived class constructor, before the archetype and Blueprint-class defaults are applied over the native ones, and before the owner has a chance to configure anything. Defaults are not applied until FObjectInitializer::PostConstructInit (UObjectGlobals.cpp:4239), the copy itself in UObjectGlobals.cpp:4350, and PostInitProperties runs later still (UObjectGlobals.cpp:4427) — all three after the C++ constructor chain. The next tick pass will call GetTickableTickType(), and then Tick(), on a half-configured object. On top of that, the CDO registers along with the instances, because the FTickableGameObject constructor does not check IsTemplate() or anything of the sort (Tickable.cpp:133-145).

The correct answer is to construct with an explicit “do not tick” and enable ticking later:

UTickableObject::UTickableObject()
    : FTickableGameObject(ETickableTickType::Never)
{
    // Deliberately empty. Registering for tick here is exactly what Tickable.h forbids.
}

Decision two: when you unregister

The default answer: in the destructor. And again it is too late. A UObject destructor runs long after the object stopped being useful, and in the meantime the engine is free to tick it.

The right place is an explicit method called by the owner, plus a hard gate in BeginDestroy() as the last line of defense. The tick queries themselves are gates too, each in its own place:

ETickableTickType UTickableObject::GetTickableTickType() const
{
    // Never for the CDO and before Initialize: the object stays out of the tickable
    // array entirely instead of sitting in it and being polled every frame.
    return (IsTemplate() || !bInitialized) ? ETickableTickType::Never : ETickableTickType::Conditional;
}

bool UTickableObject::IsTickable() const
{
    return bInitialized && bTickEnabled && CachedWorld.IsValid() && IsValidChecked(this);
}

The split between these two methods is deliberate. IsTemplate() belongs in GetTickableTickType, not in IsTickable: that way the CDO never enters the array at all, instead of sitting in it and answering “no” every frame. IsTickable is left for the conditions that genuinely change over the object’s lifetime.

// UE 5.7 — Tickable.cpp:59-63, indentation reduced (branch for an object not yet in the array)
else
{
    // Add to the pending list (which could override previous request), this will apply it next frame
    NewTickableObjects.Add(InTickable, NewTickType);
}

Decision three: which world you belong to

The default answer: none. Left unoverridden, GetTickableGameObjectWorld() returns nullptr (Tickable.h:187-190), and the object ticks in the global pass that follows all the worlds — knowing nothing about pause, nothing about PIE, nothing about the moment its world stops existing.

Overriding that method is cheap and handles all three at once:

UWorld* UTickableObject::GetTickableGameObjectWorld() const
{
    return CachedWorld.Get();
}

I resolve the world once, in Initialize(), and hold it in a TWeakObjectPtr<UWorld>. Plain GetWorld() is enough: the default UObject::GetWorld() implementation walks the Outer chain (Obj.cpp:1145-1150), so an object created with a sensible Outer finds its world with no help at all.

Here is the trap I ran into. Once the world is gone, CachedWorld.Get() starts returning nullptr. You would expect that to be the end of the tick. The opposite is true. The gate in the engine reads GetTickableGameObjectWorld() == World (Tickable.cpp:189), and TickObjects is also called with World == nullptr, precisely for objects with no world (GameEngine.cpp:1947). The comparison nullptr == nullptr passes. The object does not stop ticking. It quietly migrates from its own world’s tick to the global engine pass and keeps going.

The whole condition in the engine loop:

// UE 5.7 — Tickable.cpp:186-189 (indentation reduced)
// If it is tickable and in this world
if (TickableObject->IsAllowedToTick()
    && ((TickableEntry.TickType == ETickableTickType::Always) || TickableObject->IsTickable())
    && (TickableObject->GetTickableGameObjectWorld() == World))

Closing this takes two things at once: the CachedWorld.IsValid() condition in IsTickable(), and a subscription to world cleanup, so that the object shuts itself down instead of just no longer being polled.

void UTickableObject::HandleWorldCleanup(UWorld* World, bool bSessionEnded, bool bCleanupResources)
{
    if (World == CachedWorld.Get())
    {
        Shutdown();
    }
}

The delegate is FWorldDelegates::OnWorldCleanup, hooked up in Initialize() and removed in Shutdown(). Unregistering from inside your own broadcast is safe: Unreal’s multicast delegates defer compacting the list until the call finishes (MulticastDelegateBase.h:380-390).

Decision four: who cleans up

The default answer: nobody. A UObject with no UPROPERTY reference is collected at the next GC, and that is the correct behavior. It just has to be handled deliberately, instead of discovered halfway through a session when the object is already gone.

The reflex is AddToRoot(). That is not lifetime management; it is turning GC off for this object, with a manual RemoveFromRoot() as the only way out. The object survives a map change and everything else.

A sensible contract is simpler and puts both obligations on the owner: the object lives in a UPROPERTY(TObjectPtr<>), and Shutdown() runs before that reference is dropped.

So BeginDestroy() does exactly as much as it has to and not an ounce more: it removes the delegate (a plain Remove, no dispatch into Blueprint), kills the tick, and reports that the owner never called Shutdown().

void UTickableObject::BeginDestroy()
{
    FWorldDelegates::OnWorldCleanup.Remove(WorldCleanupHandle);
    WorldCleanupHandle.Reset();

    SetTickableTickType(ETickableTickType::Never);
    bTickEnabled = false;

    ensureAlwaysMsgf(!bInitialized,
        TEXT("%s: destroyed while still initialized - the owner never called Shutdown()."), *GetName());

    Super::BeginDestroy();
}

ensureAlwaysMsgf, not ensureMsgf: a plain ensure fires once per callsite per process. The bEnsureHasExecuted flag is keyed by a hash of __FILE__ and __LINE__, and the Always variant skips that filter (AssertionMacros.h:440-448). The first leaked object would silence the diagnostic for every one after it.

Epic does the same in UTickableWorldSubsystem::BeginDestroy (WorldSubsystem.cpp:154-159): it does not call Deinitialize from there — and now the reason is clear. Two differences from the listing above are deliberate: Epic leaves a plain ensureMsgf there (WorldSubsystem.cpp:158) and calls Super::BeginDestroy() first (WorldSubsystem.cpp:156).

The whole class

The complete implementation ships in StillCooking_Tools as USCTickableObject — a free, MIT-licensed plugin distributed as C++ source (GitHub), module StillCookingCore, header Objects/SCTickableObject.h. It is the class from this post, developed further: on top of the four decisions above it adds an explicit tick intent that Initialize() applies, the bTickWhenPaused and bTickInEditor gates, and a protected engine-facing interface with IsTickable() marked final.

• Reference: USCTickableObject — functions, properties, events and the messages it logs.
• Lifecycle — the ownership contract and what happens when the owner forgets Shutdown().

Checklist

Five things to check in your own class:

1. The constructor calls FTickableGameObject(ETickableTickType::Never) and does nothing else tick-related.
2. GetTickableTickType() returns Never for IsTemplate() and for the pre-initialization state, so the CDO never enters the array.
3. GetTickableGameObjectWorld() returns a real world, and IsTickable() checks whether that world is still alive.
4. There is an explicit shutdown method called by the owner, plus a world-cleanup subscription for the case where the world goes first.
5. BeginDestroy() kills the tick and reports the problem, but does not run subclass teardown.

The cause is not a race condition. A dispatcher broadcast is a synchronous loop over an array: one thread, one frame, the same result every time. The call order of the bindings is deterministic, and relying on it is legitimate, provided you know where that order comes from and what changes it. It comes from the lifecycle phase in which each Bind Event to… node ran.

The test setup

UE 5.7, pure Blueprint, two separate Blueprints. BP_GameInstance_Test owns both dispatchers and CustomEvent_1, which is bound in Init:

The actor BP_DispatcherTest binds to the same OnDelegate_1 in BeginPlay, and its handler is what creates the binding on OnDelegate_2:

A key press in the Level Blueprint fires the broadcast. After calling OnDelegate_1, the graph logs [END TEST]. That marker marks the end of the synchronous execution triggered by the key press, and it makes the log comparisons further down readable:

One key press, and the Output Log shows:

LogBlueprintUserMessages: [1]
LogBlueprintUserMessages: [2]
LogBlueprintUserMessages: [END TEST]

[3] never appears. A breakpoint on CustomEvent_3 is never hit. There is no compile error, no red node, and no warning. From the engine’s point of view nothing went wrong: the dispatcher called everything that was registered at the moment of the call, and CustomEvent_3 was not registered then.

This is not a race condition

The symptom suggests a race condition: the binding and the broadcast are competing, and the broadcast wins. That explanation is false and sends the diagnosis in the wrong direction.

Nothing here is racing anything. When CustomEvent_1 broadcasts OnDelegate_2, CustomEvent_2 has not started running yet. Not because it was too slow, but because it comes later in program order. Run the same project a hundred times and it behaves identically a hundred times.

The distinction has practical consequences. A race condition is something you look for in timing and try to fix with a delay added just in case. A delay does work here, but not for the reason that hypothesis suggests: it doesn’t give another thread time to catch up, it moves the OnDelegate_2 broadcast past the end of the entire OnDelegate_1 handler list. It is worth knowing which of the two you are buying.

Proving the order is deterministic

The setup above shows where the invisible order comes from, but it mixes two variables at once. One Blueprint is enough to isolate it: all three custom events on BP_GameInstance_Test, both bindings to OnDelegate_1 on a single exec wire in Init, no actor and no BeginPlay.

LogBlueprintUserMessages: [1]
LogBlueprintUserMessages: [2]
LogBlueprintUserMessages: [END TEST]

Now the only change in the entire project: the exec wire between the two Bind Event to OnDelegate_1 nodes is swapped. The nodes, the events, their contents, and the Level Blueprint stay untouched.

LogBlueprintUserMessages: [2]
LogBlueprintUserMessages: [1]
LogBlueprintUserMessages: [3]
LogBlueprintUserMessages: [END TEST]

CustomEvent_2 ran first, bound CustomEvent_3 to OnDelegate_2, and only then did CustomEvent_1 broadcast that dispatcher. Reordering two nodes on an exec wire changed the result predictably and repeatably. The result follows directly from the order of execution: in one arrangement, registration happens after the broadcast; in the other, it happens before it.

Where the order comes from

A Blueprint dispatcher is an FMulticastScriptDelegate, and its broadcast lives in ScriptDelegates.h:917 (5.7):

if( InvocationList.Num() > 0 )
{
    // Create a copy of the invocation list, just in case the list is modified by one of the callbacks during the broadcast
    typedef TArray< UnicastDelegateType, TInlineAllocator< 4 > > FInlineInvocationList;
    FInlineInvocationList InvocationListCopy = FInlineInvocationList(InvocationList);

    // Invoke each bound function
    for( typename FInlineInvocationList::TConstIterator FunctionIt( InvocationListCopy ); FunctionIt; ++FunctionIt )
    {
        if( FunctionIt->IsBound() )
        {
            FunctionIt->template ProcessDelegate<UObjectTemplate>(Parameters);
        }
    }
}

TConstIterator runs front to back, and new bindings are appended to the end of the array. Hence the rule: in a Blueprint dispatcher, first bound is first called.

That leaves the question of why CustomEvent_1 runs first. Not the graph: neither of the two Blueprints contains a node that sets the call order. The lifecycle decides. UGameInstance::Init (Private/GameInstance.cpp:129) runs before the map is loaded, and therefore before BeginPlay on any actor in the world. The world startup timeline is laid out separately in Subsystem and manager actor lifecycles.

Same name, opposite order

The C++ equivalent iterates the other way, with a comment that says why (MulticastDelegateBase.h:292-293):

// call bound functions in reverse order, so we ignore any instances that may be added by callees
for (int32 InvocationListIndex = LocalInvocationList.Num() - 1; InvocationListIndex >= 0; --InvocationListIndex)

So one name, “multicast delegate,” covers two implementations with opposite iteration order. The order a graph relies on is a property of the specific implementation, not of the concept.

Same symptom, different cause

The comment above the copy, “just in case the list is modified by one of the callbacks during the broadcast,” describes a different case with an identical symptom. The copy means that a binding added to a dispatcher that is currently broadcasting will not be called in that broadcast. If CustomEvent_2 bound CustomEvent_3 to OnDelegate_1, the same dispatcher that is calling it right now, CustomEvent_3 would stay silent as well. The cause would be the frozen copy taken before the first handler, not the registration order.

What the order does not guarantee

Moving a binding earlier in the lifecycle fixes the symptom, and it is a legitimate move. It is worth knowing what it assumes.

Epic does not promise this order. The multicast class documentation says so directly (DelegateSignatureImpl.inl:1024-1025):

Multicast delegates offer no guarantees for the calling order of bound functions. As bindings get added and removed over time, the calling order may change.

Removal from the list does not preserve order. RemoveInternal goes through RemoveAtSwap (ScriptDelegates.h:1069), so the last entry jumps into the freed index. The header warns about this on every removal method (ScriptDelegates.h:731, 771, 1045, 1056):

* Removes a function from this multi-cast delegate's invocation list (performance is O(N)).  Note that the
* order of the delegates may not be preserved!

The practical takeaway: the order is stable as long as nothing unbinds from the dispatcher. Unbinding from this dispatcher anywhere in the project can reorder its remaining listeners.

What to do about it

One pattern forces a decision: a dispatcher handler that broadcasts another dispatcher while it runs. It opens a window in which some listeners have not registered yet. Five ways out, each with its own condition. The first three change the graph and have results shown below. The last two are a project convention rather than a change in the nodes.

Defer the broadcast by one tick

Instead of broadcasting OnDelegate_2 straight from CustomEvent_1, route it through Set Timer for Next Tick by Event and a separate BroadcastDelegate2 event. The OnDelegate_1 broadcast then runs through every handler, each one gets to bind, and OnDelegate_2 starts with a complete list.

LogBlueprintUserMessages: [1]
LogBlueprintUserMessages: [2]
LogBlueprintUserMessages: [END TEST]
LogBlueprintUserMessages: [3]

[3] landing after the [END TEST] marker shows exactly what this solution does: the broadcast moved out of the synchronous execution triggered by the key press and into the next frame.

This applies when no OnDelegate_2 listener binds later than the next frame. An actor spawned two frames later, or a widget created on demand, still misses out. It widens the window; it does not remove the dependency.

Move the binding to a dispatcher that is guaranteed to fire later

CustomEvent_3 goes on OnDelegate_3, which is known to fire later. Here the same key press broadcasts it, right after OnDelegate_1.

LogBlueprintUserMessages: [1]
LogBlueprintUserMessages: [2]
LogBlueprintUserMessages: [3]
LogBlueprintUserMessages: [END TEST]

Cheap and effective, but it still depends on ordering: the order of separate broadcasts rather than the order of handlers within one broadcast. The condition is that nobody moves that call.

Turn the event into state

A dispatcher carries information only at the moment of the call. Whoever arrives late never gets it. A bDelegate2Broadcast bool on the sender side changes that rule: CustomEvent_1 sets it before the broadcast, and CustomEvent_2, once its binding is in place, checks it with a Branch and calls CustomEvent_3 directly if needed.

LogBlueprintUserMessages: [1]
LogBlueprintUserMessages: [2]
LogBlueprintUserMessages: [3]
LogBlueprintUserMessages: [END TEST]

[3] appears synchronously here, still within the same key press. The late listener does not wait for another broadcast. It reads the state and catches up immediately. This is the only option that survives a listener created after everything else, at the cost of maintaining extra state.

Declare the order instead of relying on it silently

If the order is meant to be a contract, write it down: a comment on both Bind Event to… nodes stating which one comes first and what depends on it, an event name that identifies the phase, and an explicit condition that nothing unbinds from this dispatcher. This option documents the existing ordering dependency without changing the graph.

Separate the phases: bindings in one, broadcasts in the next

If every Bind Event to… runs in a phase earlier than any call, the order within the list stops meaning anything. Here the dependency disappears instead of moving further out. The condition is that the phase boundary is clearly defined in the project and nobody binds after it.

When this matters

As long as every binding to a given dispatcher lives in one Blueprint, the problem barely exists. The order is visible at a glance, and nobody changes it by accident.

The risk shows up once listeners of the same dispatcher spread across different lifecycle phases: GameInstance, a subsystem, GameMode, an actor placed in the level, a spawned actor, a widget created on demand. Call order stops being a property of the graph and becomes a property of the whole project: it is set by the phases in which all the Bind Event to… nodes attached to that dispatcher run. Move one of them to a different phase and the rest shift position in the list.

A subsystem derives from one of five base classes. Each subsystem type is associated with a different owner and inherits that owner’s lifetime: UEngineSubsystem, UEditorSubsystem, UGameInstanceSubsystem, UWorldSubsystem (plus UTickableWorldSubsystem), or ULocalPlayerSubsystem (Runtime/Engine/Public/Subsystems/Subsystem.h:12-20). Everything below comes from reading the UE 5.8 source.

Choosing the base class is how you declare the subsystem’s lifetime. Everything else happens automatically.

All five follow the same contract: ShouldCreateSubsystem(UObject* Outer) → Initialize → Deinitialize. The first call is the exception. It runs on the CDO before an instance even exists, as the header states explicitly: “Note: This function is called on the CDO prior to instances being created!” (Subsystem.h:49-56).

Under the hood, the collection gathers every non-abstract derived class through GetDerivedClasses(BaseType, …, true) and asks each CDO whether that subsystem should be created (Private/Subsystems/SubsystemCollection.cpp:256,373-391). It stores the resulting instances in a TMap<UClass*, USubsystem*> (Public/Subsystems/SubsystemCollection.h:116-143). One instance per class per Outer isn’t a convention; it follows from the container type. The key is a concrete class, not a hierarchy. If another non-abstract class derives from that base class — a Blueprint child, for instance — its CDO gets asked the same question separately, and the collection ends up holding two independent instances. How this affects which class provides the implementation is covered separately in ShouldCreateSubsystem and the subsystem class hierarchy.

Where each collection starts

The first two rows are the easiest to get wrong. UEditorSubsystem and UEngineSubsystem derive from UDynamicSubsystem, which automatically populates the collection when a module loads and empties it when that module unloads. Your subsystem won’t exist until its module is explicitly loaded, and the engine won’t report an error if it isn’t.

The world startup timeline

By the time this timeline begins, the Engine and GameInstance collections have already been initialized. UEngine::Init runs during process startup, and UGameInstance::Init runs before the map load that creates the gameplay world.

The relevant points in the timeline are all in Runtime/Engine/Private/World.cpp:

1. UWorld::InitWorld() calls InitializeSubsystems (:2447) and, near the end, PostInitializeSubsystems (:2610). World subsystems receive both Initialize and PostInitialize.
2. UWorld::InitializeActorsForPlay() runs (:5946). Only then does the engine start handling actors placed in the level.
3. UWorld::BeginPlay() calls OnWorldBeginPlay on every World subsystem and then calls AGameModeBase::StartPlay() (:6165-6179).

The third point gives us a guarantee that no actor can provide: a World subsystem has been initialized and has already run OnWorldBeginPlay before GameMode starts gameplay. An actor placed in the level receives its BeginPlay during InitializeActorsForPlay/StartPlay, which puts it after the subsystems. That last part is my interpretation of the call order, not a guarantee stated on any single line of engine code, but it follows directly from that order.

An actor spawned during play is a different case. Its BeginPlay fires immediately after it is spawned, so the startup-order question doesn’t apply.

A manager actor comes close to providing the same guarantee, but only when three conditions are met: it derives from AInfo (or explicitly sets bIsSpatiallyLoaded = false), lives in the persistent level, and has no dependency on a streamed sublevel. The AInfo constructor sets bIsSpatiallyLoaded = false and bReplicates = false (Private/Info.cpp:11-45), which is exactly the kind of role Epic designed this class for.

A plain AActor placed in a World Partition level is spatially streamed by default and can be unloaded during gameplay. A subsystem is structurally immune to this class of bug because it doesn’t belong to any ULevel.

Where the ordering guarantee stops

The guarantee from the previous section applies only to this ordering. Everything below falls outside it, and that is where the assumption that “the subsystem is always there” breaks down.

There is no declarative ordering between collections. FSubsystemCollectionBase::InitializeDependency enforces ordering within a single collection and nowhere else. The header states this plainly: “Dependencies only work within a collection” (Public/Subsystems/SubsystemCollection.h:31-45). A World subsystem that accesses a GameInstance subsystem from inside Initialize has no declarative safeguard. You must either enforce the order yourself or defer that access until OnWorldBeginPlay, when the world has already been assembled.

A dynamic subsystem whose module hasn’t loaded never appears. A UEditorSubsystem placed in a module with the wrong LoadingPhase simply never reaches the collection (Subsystem.h:72-83, EditorSubsystem.h:9-23). The symptom is misleading: GetEditorSubsystem<T>() returns null even though the class compiles, loads, and looks perfectly fine in the editor.

A class that hasn’t been loaded never even makes the list. This is the same mechanism as the point above, seen from the other side. Non-dynamic collections run their GetDerivedClasses scan once, when the collection is created, and they only see the classes that are in memory at that moment. A Blueprint child of a subsystem with no hard references to that child isn’t loaded yet in a packaged build, so its CDO is never asked — and at the default log level a refusal and an absence look identical: both are just a missing line. The editor never shows the problem, because the Content Browser keeps the class in memory. I covered the whole case in A Blueprint subsystem does not get created in a packaged build.

A conditional ShouldCreateSubsystem eliminates the non-null guarantee. Epic does this in its own code: UInputDeviceSubsystem returns false on a dedicated server, in a commandlet, and when Slate hasn’t been initialized (Private/GameFramework/InputDeviceSubsystem.cpp:240-252). The consequence is visible in the subsystem’s own accessor. UInputDeviceSubsystem::Get() returns nullptr (:194-197), so every call within the engine is wrapped in an if, three times in ForceFeedbackEffect.cpp alone (:122, :190, :214).

Overriding this hook gives up the very property that often makes a subsystem appealing in the first place. From that point on, every GetSubsystem<T>() requires a null check, and the call site has no way to know whether it is running on a path where the subsystem was created. Sometimes that tradeoff is intentional. The condition in this method doubles as a way of declaring which class in the hierarchy should be the subsystem, and the null check becomes the price of moving the implementation one level down, into a Blueprint.

DoesSupportWorldType includes editor worlds by default. A gameplay manager that doesn’t override this method gets an instance in every world opened in the editor, not just in PIE. This happens because UWorldSubsystem overrides ShouldCreateSubsystem through DoesSupportWorldType, whose default implementation allows game, PIE, and editor worlds (Public/Subsystems/WorldSubsystem.h:33-66, especially :64-66). If the subsystem also derives from UTickableWorldSubsystem, it ticks from Initialize to Deinitialize for as long as the map remains open in the editor (WorldSubsystem.h:72-106).

Confirming this in your own project

You can verify the entire timeline above in a single editor run. Log four points and include the world type on every line:

void UMyWorldSubsystem::Initialize(FSubsystemCollectionBase& Collection)
{
    Super::Initialize(Collection);
    UE_LOG(LogMyGame, Log, TEXT("[1] Subsystem::Initialize | World=%s Type=%d"),
        *GetWorld()->GetName(), (int32)GetWorld()->WorldType);
}

void UMyWorldSubsystem::OnWorldBeginPlay(UWorld& InWorld)
{
    Super::OnWorldBeginPlay(InWorld);
    UE_LOG(LogMyGame, Log, TEXT("[2] Subsystem::OnWorldBeginPlay"));
}

// AMyManagerActor::BeginPlay  → [3]
// AMyGameMode::StartPlay      → [4]

Seeing 1 → 2 → 3 → 4 in the log confirms the guarantee for one specific project and one specific streaming setup. If [3] appears before [2], the actor is being spawned rather than placed in the level. Its BeginPlay fires immediately after the spawn and has nothing to do with the world startup timeline.

The ordering guarantee is real, and the engine code enforces it, but it covers exactly one thing: a World subsystem exists before actors in that same world receive BeginPlay. It extends no further than that single axis. Everything above also covers startup only; the order in which a world and a session shut down is a separate question, and this note leaves it open.

The game code has to answer every other question for itself, and the engine won’t even signal that the question came up.