Every cast, every direct reference, every deep child class quietly ties your Blueprints together, until touching one loads a hundred.

Here is what dependencies really cost, how to see them, and the handful of patterns that keep a project loose enough to grow.

BRIEFING

A dependency is one part of your game needing to know about another. A few are unavoidable. A tangle of them is what people mean when they say Blueprint "does not scale." In Unreal the stakes are higher than in most languages, because a dependency does not just couple your logic, it loads assets: one hard reference can drag a whole chain of content into memory. This piece explains the two kinds of dependency, where they sneak in (casting, direct references, deep inheritance, circular links), how to see them, and the small set of Blueprint patterns that cut the cords without a line of C++.

You have felt this even if you have never named it. You open one small Blueprint to change a single value, and the editor sits there churning, loading a pile of assets that have nothing to do with what you are editing. Or you tweak one actor and half the project wants to recompile. Or you try to reference one Blueprint from another and Unreal throws a circular dependency error you cannot seem to untangle. Every one of those is the same illness with a different symptom: too many dependencies.

Dependencies are also the real story behind the tired claim that "Blueprint does not scale." It is not the language. It is that a loosely-disciplined Blueprint project accumulates references between everything until the whole thing moves as one heavy, tangled block. The good news is that this is a solved problem. There is a small, learnable set of habits that keeps a project loose, and they are the difference between a codebase you can grow for years and one that seizes up at month six. Let us go through them properly.

What a dependency actually is (and why Unreal makes it worse)

A dependency is simply one thing needing to know about another: Blueprint A calls a function on Blueprint B, or casts to it, or holds a variable typed as it, or inherits from it. Some of that is normal and necessary. The problem is the amount and the direction, and it shows up as two distinct costs.

The first is logic coupling, the ordinary kind every programmer eventually meets. When A knows about B, A is now hostage to B: change B and you risk breaking or rebuilding A. Robert C. Martin built a whole principle around escaping this, the Dependency Inversion Principle, which says to depend on abstractions rather than on concrete things. Robert Nystrom spends a good part of Game Programming Patterns on the same theme, because a large chunk of good architecture is really just deciding what is allowed to know about what.

The second cost is the one that makes Unreal special, and it catches people who came from other engines. In Unreal, a hard reference means the thing you reference, and everything it references in turn, gets loaded into memory whenever your asset loads. So a web of hard references is also a web of forced loading. Touch one asset and you pull its entire dependency chain along with it. That is why a tiny Blueprint can trigger a huge load, why memory balloons on console and mobile, and why your "one small change" recompiles the world. In Unreal, coupling is not just messy. It is heavy.

Where dependencies sneak in

They rarely arrive on purpose. They accumulate one convenient node at a time. These are the usual entry points, roughly in order of how much damage they do.

Casting to a Blueprint (the big one)

This is the single most common source of accidental coupling in Blueprint projects, and it is worth understanding exactly. When you cast to a Blueprint class, you create a hard reference to it. The subtle, painful part is that this happens even if the cast fails at runtime: the mere presence of the cast node forces the target Blueprint, and its whole dependency tree, to load. Cast to BP_Enemy from your player, and your player now hard-references BP_Enemy and everything BP_Enemy touches.

There is a crucial exception that most people miss: casting to a native C++ class, such as AActor, APawn or APlayerController, does not create this hard reference. It is essentially free. So the rule is not "never cast," it is "do not cast to Blueprints when you can avoid it, and when you must cast, cast to the native parent class."

Direct references to specific actors and assets

A variable typed as BP_Door hard-references BP_Door. A widget that holds a direct pointer to your gameplay character welds your UI to your gameplay. Every time one system stores a concrete reference to another, you have tied a knot that both loading and refactoring will have to pay for.

Deep inheritance: parent and child Blueprints

Inheritance is the tightest coupling there is, because a child is permanently bound to every single decision in its parent chain. A child Blueprint depends on its parent, which depends on its parent, all the way up, and it inherits all of their dependencies too. Stack fifteen levels of child Blueprints, as tempting as it is, and a change near the top ripples through everything below, while each child quietly drags the entire ancestry's baggage into memory. Deep inheritance trees feel organised. They are actually one of the most rigid structures you can build.

Circular references

When A hard-references B and B hard-references A, you have a loop. Blueprint handles these badly: at best it forces both, and everything they touch, to load together as an inseparable clump; at worst you get compile errors you cannot untangle without breaking the loop. Circular dependencies are almost always a sign that two things that should talk through an intermediary are instead talking directly.

Learn to see your dependencies

You cannot fix what you cannot see, and Unreal gives you the tools to see coupling directly, so use them before you guess. Right-click almost any asset and open the Reference Viewer: it draws exactly what references this asset and what this asset references, which is a literal map of your coupling. The Size Map shows how much memory an asset pulls in once you count everything it hard-references. Together they turn a vague feeling of heaviness into a specific list of the worst offenders, the assets dragging the biggest trees, which is where any cleanup should start.

The toolkit for cutting the cords

Here is the actual craft, and all of it is available in 100% Blueprint. None of these is exotic; they are the standard vocabulary of a clean Unreal project.

Blueprint Interfaces: talk to a capability, not a class

A Blueprint Interface lets you say "send this message to anything that knows how to receive it," without knowing or caring what class it is. Instead of casting to BP_Door to call OpenDoor, you call an Interact message through an interface, and any actor that implements it responds. No cast, no hard reference, no knowledge of the concrete class. This is the primary decoupling tool in Blueprint, and it is the practical form of Martin's advice to depend on an abstraction instead of a concretion.

Event Dispatchers: broadcast, do not command

An Event Dispatcher is the Observer pattern in Blueprint form. The sender broadcasts "this happened" and does not know or care who is listening; interested actors subscribe. Your health component broadcasts OnHealthChanged, and the UI, the audio and the AI can all react without the health component holding a single reference to any of them. It is worth knowing one honest limit: a listener still needs a reference to the sender in order to bind to it in the first place, so dispatchers decouple the reaction, not always the initial wiring. When you need fully reference-less communication, route it through a hub instead.

A subsystem or manager as a hub

Rather than have every system hold references to every other, let them talk through a central point: a GameInstance Subsystem (or a Game Instance) that any Blueprint can reach without hard-referencing a specific actor. The player broadcasts to the subsystem; the subsystem tells whoever registered. This is the Mediator pattern, and it turns a dense mesh of connections into a clean hub and spokes. Subsystems are especially good because they are globally accessible by type, so reaching one does not couple you to any particular instance.

Gameplay Tags deserve their own mention here, because asking "does this actor have the tag State.Stunned?" is far looser than casting to a class and reading a boolean. Tags let you check capability and state without knowing the type at all, and they are one of the cleanest ways to decouple identity from class. They are a big enough topic that they get their own article, but they belong in any conversation about dependencies. And if any of this raises the old worry that clean architecture must mean dropping into C++, it does not: I made that case in full in the C++ myth piece, and every tool here is pure Blueprint.

Soft references for things you do not always need

For heavy assets you do not need loaded at all times, a mesh, a sound bank, a whole level, use a soft reference (TSoftObjectPtr or TSoftClassPtr in C++ terms, or a Soft Object or Soft Class variable in Blueprint). A soft reference stores a path, not the loaded asset, so nothing loads until you deliberately ask for it. This is how you break the "everything loads at boot" pattern for content that is only sometimes needed.

Composition over inheritance

Instead of a deep tower of child Blueprints, keep your hierarchies shallow and push reusable behaviour into Actor Components that you attach where needed. This is Nystrom's Component pattern, and it is the direct cure for the inheritance trap: a health component, an interaction component and an inventory component can be mixed onto any actor without any of them inheriting a mountain of unrelated code. A child should add a little, not inherit everything.

A practical way to untangle an existing project

You will rarely start clean. Far more often you inherit a project that has already knotted itself. The recipe is the same every time, and it is calm, not heroic.

1. Measure first. Open the Reference Viewer and the Size Map, and find the assets that pull in the biggest trees. Fix the worst offenders, not the ones you happen to be looking at.
2. Kill the casts to Blueprints. Replace each one with an interface call, or a cast to the native parent class where a cast is genuinely needed.
3. Replace direct commands with broadcasts. Where one actor reaches out to poke a specific other, switch to an Event Dispatcher, or route the message through a subsystem.
4. Break the loops. Wherever you find a circular reference, introduce an interface between the two, or move the shared logic into a component or subsystem that both can use without referencing each other.
5. Flatten the inheritance. Pull repeated behaviour out of deep child chains into Actor Components, and let the hierarchy get shallow.
6. Re-measure. Open the Size Map again and watch the tree shrink. That number dropping is the whole point.

Glossary

Dependency.  one part of a project needing to know about another (calling it, casting to it, referencing or inheriting from it).

Coupling.  how tightly two parts are tied together. Tight coupling means changing one forces you to change the other.

Hard reference.  a reference that forces the referenced asset, and everything it references, to load into memory whenever the referencing asset loads.

Soft reference.  a reference stored as a path (Soft Object / Soft Class), so the asset stays unloaded until you explicitly load it.

Circular dependency.  two things that hard-reference each other, forcing them to load together and often causing compile errors.

Blueprint Interface (BPI).  a shared set of messages an actor can implement, letting others talk to it by capability without casting to its class.

Event Dispatcher.  a Blueprint broadcast (the Observer pattern) that lets a sender announce an event without holding references to its listeners.

GameInstance Subsystem.  a globally accessible object, reachable by type, useful as a central hub so systems do not reference each other directly (the Mediator pattern).

Reference Viewer.  an Unreal tool that maps what an asset references and what references it. Your picture of coupling.

Size Map.  an Unreal tool showing the total memory an asset pulls in once every hard reference is counted.

Composition over inheritance.  building behaviour by attaching reusable Actor Components rather than stacking deep parent and child classes.

Is your Blueprint project starting to move like one heavy block?

Tangled dependencies are the quiet reason projects slow down, balloon in memory, and get scary to change.

I build and untangle Unreal architectures in clean 100% Blueprint: interfaces, events, subsystems and components, so your project stays fast to load and safe to grow.

If yours is knotting up, that is exactly what I fix.