Verse, C++, and Blueprints
Blueprint Deprecation
One key announcement from the State of Unreal 2026 was that Blueprints will eventually be deprecated in Unreal Engine 6.X.
However, Blueprints will still be supported in early versions of Unreal Engine 6.
This means the last version featuring Blueprints and the AActor model will become a de facto Long-Term Support (LTS) version for Blueprint-only developers or Blueprint-heavy projects.
Thus, the last Blueprint-compatible LTS release will probably be around 2029-2030, based on Epic’s roadmap targeting Unreal Engine 6 Early Access for late 2027 (or early 2028) and the full 6.0 launch 12 to 18 months later.
In other words, the BP-compatible LTS version will remain relevant for several years, basically the entire 10th generation of consoles and relevant PC hardware.
The Blueprint Creation Context
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, but the distinction was clear.
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 professionals.
However, 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 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 architecture significantly rely on both Blueprints and C++, which are deeply intertwined.
Essentially, the question of using one or the other is irrelevant, because both should always be used.
The main idea is simple: Unreal C++ should be used for base classes and heavy operations, while Blueprints is useful for creating most derived classes and have variations.
Thus, the Unreal C++ base class has to expose in Blueprints most member variables, or properties in standard object-oriented, and member functions, or methods in OO.
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 adapt the base class).
Collectible Class Example
Let’s take an example from my game: collectibles.
Each playable character has to find a specific category of collectibles, such as books earned through side quests or by buying properties.
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 unique 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 classs, either AGoldaCollectible or AGoldaCollectibleBook.
Traffic Light Example
Another example I can share from my game is a Traffic Light.
Although I only needed to create a traffic light that works from a visual standpoint, without affecting NPC
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 GOLDANNIYATECH_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++.
To be continue…
