The difference only shows up once the hierarchy has more than one level, which happens as soon as someone creates a Blueprint child of a subsystem written in C++.

I covered the lifecycle contract and where each collection starts in a separate post: Subsystem and manager actor lifecycles. Here, I’m focusing on one specific part: the loop that picks the classes.

A subclass does not replace its parent

The collection gathers derived classes in a single call and runs every one of them through the same procedure (Engine/Private/Subsystems/SubsystemCollection.cpp:209):

TArray<UClass*> SubsystemClasses;
GetDerivedClasses(BaseType, SubsystemClasses, true);

for (UClass* SubsystemClass : SubsystemClasses)
{
    AddAndInitializeSubsystem(SubsystemClass);
}

There is no selection of the most-derived class here, no collapsing of the hierarchy, no rule that the child wins over the parent. The question is asked separately of each entry’s own CDO (SubsystemCollection.cpp:331):

const USubsystem* CDO = SubsystemClass->GetDefaultObject<USubsystem>();
if (CDO->ShouldCreateSubsystem(Outer))
{
    USubsystem* Subsystem = NewObject<USubsystem>(Outer, SubsystemClass);
    SubsystemMap.Add(SubsystemClass, Subsystem);
    // ...
}

The consequence is straightforward and easy to miss: a Blueprint child of a C++ class joins the parent as a second, independent instance. The base implementation returns true (Subsystem.h:61), so if nobody has overridden the method, two instances live in the collection. One of the C++ class, one of the Blueprint class. Both have run Initialize, both carry their own state, and neither knows about the other.

Two filters run before that question is asked. The first rejects abstract classes (:318), the second rejects non-authoritative ones (:324):

// Do not create instances of classes that aren't authoritative.
if (SubsystemClass->GetAuthoritativeClass() != SubsystemClass)
{
    return nullptr;
}

The second one says something about intent. GetAuthoritativeClass filters out the intermediate classes produced when Blueprints are recompiled, which means Epic hardened this path for Blueprint classes. A Blueprint subsystem is a scenario the engine anticipates.

The switch: false in C++, true in Blueprint

The question is asked separately of every CDO, and Blueprint defaults live on the CDO of their class. The same flag can therefore hold a different value at each level of the hierarchy, which turns it into a switch between implementation layers:

UCLASS(Blueprintable)
class MYGAME_API UMySubsystem : public UGameInstanceSubsystem
{
    GENERATED_BODY()

protected:
    /** Read from the CDO only - set to true in the Blueprint child that implements this. */
    UPROPERTY(EditDefaultsOnly, Category = "Config")
    bool bShouldCreateSubsystem = false;

    virtual bool ShouldCreateSubsystem(UObject* Outer) const override
    {
        return Super::ShouldCreateSubsystem(Outer) && bShouldCreateSubsystem;
    }
};

With false on the C++ side and true in the Blueprint class defaults, exactly one instance ends up in the collection. The C++ class becomes a skeleton: it defines the interface, the BlueprintImplementableEvent declarations, and everything Blueprint cannot declare on its own, while the implementation lives one level below.

This works because ShouldCreateSubsystem runs on the CDO before an instance exists, which means it runs on the object that holds the default values stored in the Blueprint asset. That is also why the flag is marked EditDefaultsOnly. The value is read from the defaults and nowhere else, so per-instance editing changes nothing.

GetSubsystem<T>() finds the child anyway

Instances live in a TMap<UClass*, USubsystem*> keyed by the concrete class. The natural conclusion is that querying for the base class will not find an instance of a derived one, and that conclusion is wrong. GetSubsystemInternal has a fallback (SubsystemCollection.cpp:66):

USubsystem* SystemPtr = SubsystemMap.FindRef(SubsystemClass);

if (SystemPtr)
{
    return SystemPtr;
}
else
{
    const FSubsystemArray& SystemPtrs = FindAndPopulateSubsystemArrayInternal(SubsystemClass);
    if (SystemPtrs.Subsystems.Num() > 0)
    {
        return SystemPtrs.Subsystems[0];
    }
}

A miss in the map triggers an IsChildOf sweep and returns the first hit. So GetSubsystem<UMySubsystem>() with the base class as the parameter returns the Blueprint child instance, even though nothing is stored under the base class key.

Without that fallback the switch would make no sense. Every piece of C++ that queries the subsystem by its own base class would stop seeing it the moment the implementation moved into Blueprint.

Listing every instance at once takes a separate accessor. In 5.7 it is called GetSubsystemArrayCopy and returns by value, both on the collection itself (Public/Subsystems/SubsystemCollection.h:139) and on the UGameInstance wrapper (Classes/Engine/GameInstance.h:463).

The flagless variant: yielding to subclasses

The flag has one unpleasant property. When the Blueprint child is gone, whether it was deleted, moved, or simply never loaded in time, false on the C++ side means nothing is created. The subsystem disappears entirely, including the part that was written in C++ and had nothing to do with Blueprint.

The condition can be phrased differently: let the class step aside, provided there is someone to step aside for.

bool UMySubsystem::ShouldCreateSubsystem(UObject* Outer) const
{
    if (!Super::ShouldCreateSubsystem(Outer))
    {
        return false;
    }

    /// @Note: The collection instantiates every non-abstract subclass, so a Blueprint child
    ///        would live alongside this one. Yield so that only the most-derived class is created.
    TArray<UClass*> DerivedClasses;
    GetDerivedClasses(GetClass(), DerivedClasses, /*bRecursive*/ true);
    return DerivedClasses.Num() == 0;
}

In the normal case the outcome is the same, since a child exists and the parent steps aside. The failure looks different though: a missing child leaves a working C++ instance instead of an empty slot. There is also no flag to forget to set in a new Blueprint’s defaults.

I use this variant in a production subsystem, and I have tested it in PIE. With the Blueprint child present, exactly one instance is alive; with the child removed, the C++ instance is. I have not tested it in a packaged build, so that behavior remains an inference from the mechanism rather than an observed result.

There are two limits, and both follow directly from this implementation.

Two children mean two instances. Each of them sees zero descendants and each concludes that it is the most-derived one. This case cannot be resolved inside the method, which leaves a convention: exactly one Blueprint child per class.

A single permanently loaded C++ subclass disables the base class for good. A test class in an Editor module is enough. It is compiled, so it sits in memory from startup, so the parent yields to it in every editor session. In practice this means a test module must not derive from such a subsystem, and the test double has to be built on a plain UObject acting as a listener. This trap is worse than two Blueprint children, because nothing about it is visible in the assets. It lives in test code that nobody associates with runtime.

Common mistakes

The last of those cannot be reproduced in the editor. It only surfaces in a packaged build.

Verification

The number and classes of live instances, in one console command:

obj list class=MySubsystem

A query for the base class covers derived classes, so it shows the parent and the children at once, broken down by class. Two rows instead of one reveal the duplication described in the table above; a row for a _C class means the switch worked and the Blueprint implementation is the one running.

Each CDO decision is in the log once the category’s log level is raised:

-LogCmds="LogSubsystemCollection VeryVerbose"

LogSubsystemCollection: VeryVerbose: Subsystem does not exist, but CDO choose to not create (MySubsystem)

That line means the class was on the list and refused. Its absence, together with a missing instance, means something entirely different: the class was not on the list, so nobody asked it. Telling those two states apart is the only way to distinguish a working switch from a class that never loaded. At the default log level both of them look like silence, which is why the category’s log level has to be raised first.

The symptom: nothing to look for

No compile errors. No warnings. No lines in the log. GetSubsystem<T>() does not return nullptr either, because as long as the parent C++ class does not refuse to be created, an instance is created normally. What gets created is the parent. The Blueprint implementation that was supposed to replace it never runs, and the pointer looks perfectly valid.

There is a harsher variant, and it happens when the parent refuses on purpose. That is the case in the pattern where the C++ class returns false to make room for a Blueprint implementation. Then nothing is created at all: the parent refused, and nobody asked the child.

Two runs that settle it

The test project uses UE 5.7. It contains UMyTestSubsystem : UGameInstanceSubsystem, marked UCLASS(Blueprintable), which logs a single line in Initialize. It also contains a Blueprint child, BP_MyTestSubsystem, with a PrintString in its graph. The build is packaged in the Development configuration.

First run, with nothing in the project referencing the Blueprint class:

LogSubsystemCollection: Verbose: Initializing subsystem collection for BP_GameInstance_Test_C_2147482547 with type GameInstanceSubsystem
LogSubsystemCollection: VeryVerbose: Subsystem does not exist, but CDO choose to not create (MyTestSubsystem)

The parent made it onto the list and refused. The child is not on that list at all. There is no second choose to not create line, and no line from Initialize either, which the child inherits from C++ and would have run had it been created. Counting objects confirms this independently:

Obj List: class=MyTestSubsystem
Objects:

0 Objects (Total: 0.000M / Max: 0.000M / Res: 0.000M | ...)

Second run, after adding a single variable of type MyTestSubsystem Class Reference to the GameInstance class, with its default value pointing at the Blueprint child. The variable is never used anywhere. It exists for one reason: so that the asset holds a reference.

                    Class    Count
     BP_MyTestSubsystem_C        1

1 Objects

LogTemp: UMyTestSubsystem initialized.
LogBlueprintUserMessages: [None] PostInitialize(): Test Subsystem (BP_MyTestSubsystem)

The instance exists, it is of the Blueprint class, and both the inherited C++ Initialize method and the Blueprint graph ran. The only difference between the two runs is an unused variable.

Where it disappears: the scan happens once

FSubsystemCollectionBase::Initialize builds the class list in a single call, at the moment the collection is created (Engine/Private/Subsystems/SubsystemCollection.cpp:209):

TArray<UClass*> SubsystemClasses;
GetDerivedClasses(BaseType, SubsystemClasses, true);

for (UClass* SubsystemClass : SubsystemClasses)
{
    AddAndInitializeSubsystem(SubsystemClass);
}

GetDerivedClasses sweeps the class hierarchy in memory. A class that nobody has loaded exists only as a file on disk: the asset registry knows about it, the type system does not. Since it never lands in SubsystemClasses, AddAndInitializeSubsystem never receives it, and ShouldCreateSubsystem has nothing to run on. A class missing from the scan produces no CDO decision entry. A class that is found but refuses creation produces the CDO choose to not create line at VeryVerbose verbosity.

That loop is in fact the else branch. The first branch handles a completely different case (SubsystemCollection.cpp:194):

if (BaseType->IsChildOf(UDynamicSubsystem::StaticClass()))
{
    for (const TPair<FName, TArray<TSubclassOf<UDynamicSubsystem>>>& SubsystemClasses : GlobalDynamicSystemModuleMap)
    // ...
}
else
{
    // GetDerivedClasses, once
}

UDynamicSubsystem gets incremental registration. FSubsystemModuleWatcher listens for module loads and calls AddAllInstances for classes that have just appeared (SubsystemCollection.cpp:524). UGameInstanceSubsystem does not belong to that branch. For it, the scan runs once and nothing repeats it, so a class loaded one second after the collection is initialized is too late for that collection.

Why the editor can hide this

In the editor, the Content Browser keeps the Blueprint class in memory. Opening the asset once is enough, and so is having it sit in a visible folder. By the time PIE starts, the class is already loaded, GetDerivedClasses sees it, and everything behaves exactly as designed.

In a real project the packaged build usually works too, but for a different reason: the reference exists by accident. A Get Subsystem node with the Blueprint class selected embeds a hard reference in the Blueprint that calls it, and that Blueprint ships with the level or with the GameInstance class. A reference from a Blueprint hides the problem if that Blueprint loads the subsystem class before the collection is initialized.

That is the whole trap. The mechanism breaks in exactly the place nobody tests it: when the subsystem is called from C++ and nowhere else.

The fix

Anything that loads the class before the collection is initialized. The cheapest option, and the one that does not disappear when somebody rewires a graph, is a variable of type <Subsystem> Class Reference on an object that loads early, with its default value set to the Blueprint class. The GameInstance class is the natural place for the variable, because the GameInstance itself is created before its subsystem collection.

The variable does not have to be used for anything. What matters is that the GameInstance asset holds a hard reference to the Blueprint class, so loading one pulls in the other.

Getting the class loaded in time is the only real fix. How badly the failure hurts when nothing loads it is a separate question, and the answer depends on how the C++ class steps aside for the Blueprint. Overriding ShouldCreateSubsystem with a condition that checks for subclasses, rather than with a flag set in the Blueprint defaults, turns “zero instances” into “a C++ instance without the Blueprint logic”: a reduced system rather than a missing one. I wrote up the mechanism itself, and its limits, in ShouldCreateSubsystem and the subsystem class hierarchy.

Checking this in your own project

Check two things separately: whether the instance exists, and whether the log contains a CDO decision for that class. A missing instance together with a missing CDO decision points to loading as the source of the problem. Neither observation is enough on its own.

When this matters

As long as a Blueprint reference gets the class loaded in time, the trap stays asleep. The reference appears on its own and nobody finds out it was ever needed. I reproduced it in two setups: one where the subsystem serves C++ code only, and one where a Blueprint child was added to override a few default values and nothing called it afterwards.

A third setup follows from the mechanism, but I did not reproduce it. Removing the last Get Subsystem call from Blueprints during a refactor can remove the only reference to the class. If that happens, this is the worst of the three cases, because nothing obviously connects the regression to the commit that triggered it. A node disappears from one Blueprint, the subsystem stops existing in the packaged game, and everything still works in the editor.

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.