Blueprints and C++ Deprecated!
A Gameplay Programming shift
One key announcement from the State of Unreal 2026 was that Blueprints will eventually be deprecated in Unreal Engine 6.X.
Initially, Blueprints were still supported in early versions of Unreal Engine 6, along with the AActor and inheritance-heavy model, mostly to provide an easier way to move from Unreal Engine 5 to 6.
However, plans have changed very recently in recent Unreal Fests, such as Tokyo Unreal Fest.
Apparently, Blueprints and Unreal C++ are completely deprecated in Unreal Engine 6, from the very first Early Access release for late 2027 (or early 2028) and the full 6.0 launch 12 to 18 months later.
Any information still require official confirmation from Epic Games, so I would still hold it as a “rumor” for now.
Why Blueprints might not be relevant anymore
Although I understand those who got used to it, to me, it makes perfect sense to remove Blueprints in the next generation of Unreal Engine.
Historically, back in the UDK/Unreal Engine 3 era, the engine had both UnrealScript for gameplay logic and Kismet for level-only visual scripting. Since I never used UDK or UE3, I can’t speak from experience on how practical it was, but most books I’ve read were quite enthusiastic about both languages.
When Unreal Engine 4 was released in March 2014, it replaced Kismet and UnrealScript with the Blueprint visual language for high-level scripting,
while also offering Unreal C++ for programming low-level systems and base classes.
Interestingly enough, the Level Blueprint that has existed since UE4 is actually the true legacy inherited from Kismet.
Beyond providing access to C++, Unreal Engine 4 also became a unified engine available for everyone, removing the separation between UDK for indie devs and UE3 for professional studios.
In this context, and at that time, the Blueprint language was justified because Unreal C++ was far more complicated and difficult to learn and use in UE 4.0 than it is today, with UE 5.8.
It’s still significantly lower-level and more complex than Unity C# (but more about that later 😉), but definitely not as fast as Blueprints.
But to understand more about Blueprints, and why they should be deprecated, let’s talk a bit about the engine’s architecture 😋.
Unreal Architecture: BP & C++
Unreal Engine is built around a hybrid architecture where Blueprints and C++ are deeply intertwined and designed to work together.
While Blueprint-only games do exist (far more than pure C++ projects 😅), they are relatively rare, as Unreal isn’t designed to be used without C++ for complex or long-term projects.
Essentially, C++ is used for programming low-level logic and core systems, while Blueprints are designed for high-level scripting, prototyping or visual stuff (animation, materials, etc.).
It’s not a choice or a preference here, it’s the whole engine philosophy.
From a gameplay programming standpoint, the idea is simple: Unreal C++ is for programming base classes and heavy functions, while Blueprints are for scripting derived classes and handling small variations.
Thus, the Unreal C++ base class can expose relevant member variables (properties to use the object-oriented lexicon) and member functions (methods) to derived Blueprint classes.
In other words, it’s pretty much like creating a basic template in C++ and tweaking it with many properties to create multiple variations, without even modifying the C++ code unless you need to change the base class itself.
A Monstrous example!
For example, a base Monster C++ class can define fairly generic properties and methods, while derived Blueprint classes represent specific in-game monsters such as a Goblin, Troll, or Orc.
Then, we can either modify some property values (health, strength or mana/magic) or override some functions, so each monster will attack in a different way.
But how far generic or specific that C++ class is might depend upon the game’s project.
For a game heavily relying on a combat with a large variety of different monsters, like a roguelike, a single C++ class might have many direct Blueprint subclasses for many different monsters.
However, an adventure game with fewer monsters might treat each one very differently, almost like a mini-boss, hence even requiring a single C++ class for each monster.
It’s all about balance, as there’s no one-size fits all solution.
From a technical standpoint, Unreal relies on core object-oriented principles:
Encapsulation: we can encapsulate some properties or methods that Blueprints don’t need to change with the private access modifier and without using Unreal reflection (only if it’s just for some math operations and not gameplay, of course).
Polymorphism: We can write inside the C++ base class a BlueprintImplementableEvent or a BlueprintNativeEvent function so each monster Blueprint will implement it differently.
Blueprint VM
Under the hood, Blueprints are much slower for the machine to execute,
as they run through a Virtual Machine, but much faster to write for us, developers (hence why it’s for prototyping 😎).
The reason is simple: while C++ compiles into native machine instructions for a specific CPU (x86, PS5, Xbox Series, etc.), Blueprints compile into intermediate bytecode.
At runtime, the Blueprint Virtual Machine executes this bytecode step by step, pretty much like the Python interpreter or the Java Virtual Machine.
Because of that, this VM operation (per node) is negligible for some small events (like updating once a variable or a Box Collision event),
but it starts to be noticeable for intensive math operations, ticks or recurring events.
There were some attempts to address that performance gap by Epic by converting all Blueprint bytecode directly into native C++ during Unreal 4, called Blueprint nativization,
but it was removed for Unreal 5.
Comparison to Unity
The Blueprint and C++ architecture in Unreal is very different from Unity, where developers rely on C# for everything (outside of a few things like shaders in HLSL, etc.).
First, there is no visual scripting “equivalent” in Unity.
The Unity Visual Scripting, formerly Bolt, is an alternative that replaces C# and comes with limitations, while Blueprints in Unreal were designed from the get-go.
Thus, beginners often mistakenly compare Unreal C++ to Unity C#.
In fact, from a gameplay programming perspective, C# is much closer to Blueprints, aside from the visual/textual difference.
Unreal C++ has no true equivalent in Unity outside of modifying the engine itself.
Collectible Class Example
Let’s take another example from my game: collectibles.
Each playable character has to find a specific category of collectibles, such as books or gamepads.
In order to implement this, I created a base AGoldaCollectible C++ class to handle all generic collectible logic.
Then, I added a derived C++ class for each playable character or collectible category, such as AGoldaCollectibleBook for the first character.
From there, every collectible book in the game is then a BP_CollectibleBook Blueprint instantiated in the world and derived from the C++ class I created.
I only have to model and texture the book asset in Blender, create a new Blueprint and tweak some exposed variables, without modifying Unreal C++ unless I want to add another method or property to the base classes, either AGoldaCollectible or AGoldaCollectibleBook.
Traffic Light Example
Another example I can share from my game is a traffic light. Since my game world is goofy and crazy, I only need a traffic light that works visually, as NPCs do not interact with it at all, not even drivers (I told you it’s a goofy world 🤡).
Thus, my AGoldaTrafficLight base C++ class logic is mostly about a visual sequence that changes, without messaging any other AActors.
Here’s my trafficLight.h (header file) where I expose stuff. I omitted the boilerplate preprocessors like #include "CoreMinimal.h", forward declarations and the enumerator.
UCLASS()
class GOLDANIATECH_1_API AGoldaTrafficLight : public AActor
{
GENERATED_BODY()
public:
AGoldaTrafficLight();
virtual void Tick(float DeltaTime) override;
protected:
virtual void OnConstruction(const FTransform& Transform) override;
virtual void BeginPlay() override;
virtual void EndPlay(const EEndPlayReason::Type EndPlayReason) override;
UPROPERTY(VisibleAnywhere, BlueprintReadOnly)
TObjectPtr<UStaticMeshComponent> TrafficLightMesh;
UPROPERTY(EditAnywhere, BlueprintReadWrite)
TObjectPtr<UMaterialInterface> MatAllOn;
... // Rest of my code
};
Then I make a Blueprint out of it. If I ever needed to modify properties, I can prototype new features easily.
For instance, I can use the Construction Script (the OnConstruction() method in C++) to update a new StaticMesh properties (Material and Mesh) before deciding to port the code back in C++.
