They want to remove Blueprint in UE6

If removing visual scripting is a shock, just wait until people no longer have a rigid actor framework to guide them.

Unreal’s rigid architecture also works as a guardrail:

“This lives in the Character.”
“These rules belong in the GameMode.”
“This persists in the GameInstance.”
“This is visual, put it in a Widget.”

It is not always elegant, but it helps prevent the project from turning into a GlobalEverythingSystemSubsystemManager that controls the AI, menus, weather, sounds, and possibly the coffee machine.

5 Likes

lmao, I have been using “GlobalEverythingSubsystemManager”-style for years now, because I prefer it over the “its inside actor” way of doing things, in addition to function libraries.

just that I have multiple of those managers for the different things of the game. (with some exceptions)

Its just too convenient “to know where something is” in terms of logic and variables :melting_face:

So, at least for me, no big deal. (just getting adapted to how it will work in UE6 then)

My 50 cents

  • For years, I’ve argued that visual programming systems like Scratch/Stencyl were superior to Blueprints for developing complex software and, in many cases, even superior to conventional text-based programming, mainly because of better code reuse and lower cognitive load. Today, about 17 years later, I have a much clearer understanding of the strengths and weaknesses of both approaches.

  • Most developers associate Scratch-style blocks with “programming for beginners,” which was indeed the primary goal of the Scratch project.

  • However, the real advantage is not the basic blocks (if, else, etc.), but the high-level abstractions (such as Stencyl’s Behaviors), which encapsulate reusable logic while exposing only the relevant configuration. They also serve as a way to create new editor panels and extend the functionality of the game engine itself.

  • Blueprints are fundamentally a graph editor, whereas systems like Scratch and Stencyl represent something closer to a visual AST (Abstract Syntax Tree). This means blocks have a single, predictable structure similar to text-based code, while graphs allow countless different visual representations of the same algorithm.

  • The freedom of a graph editor is excellent for experimentation and prototyping, but as projects grow it tends to produce visual spaghetti, poor code reuse, higher cognitive load, and increased maintenance complexity.

  • Block-based systems are less flexible to modify. Consider the block system used by the Construct game engine: those long chains of nested blocks become painful to edit once they grow.

  • The real advantage of block-based systems only appears once the developer already knows what needs to be built. At that stage, very little changes besides configuration, and blocks naturally encourage abstraction, modularity, code reuse, and long-term maintainability.

  • Stencyl went beyond Scratch by making reuse part of the development workflow itself. Behaviors acted as reusable modules with configurable interfaces and could even be shared through an integrated marketplace—more like an asset store than a GitHub repository.

  • In traditional engines, code reuse depends largely on the developer’s discipline. In Stencyl, reuse was built into the normal development workflow.

  • Choosing between a graph editor and a block-based editor depends on the stage of the project:

    • Graph editor: best for testing, exploration, and prototyping, when the final architecture is still unknown.

    • Block/AST editor: best once the workflow has stabilized and needs to be organized, reused, and maintained.

  • AI agent orchestration is a good example. During prototyping, it’s much easier to connect and disconnect agents, memories, and tools in a graph. Once the workflow stabilizes, however, it makes much more sense to encapsulate it as a configurable component rather than continuing to edit dozens of node connections.

  • In block-based systems, once too many if/else branches start appearing, the same thing happens as with text-based code: it’s time to rethink the application’s architecture, split modules, and refactor.

  • During the prototyping phase, when developers don’t yet know exactly what they’ll need, graph editors are far superior. They’re like having a table covered with papers that you can freely move around, connecting and disconnecting ideas as you explore different solutions.

  • The big question is: if block-based systems really offer all these advantages, why are they still mostly associated with beginners? And why didn’t Stencyl become more successful?

  • In Stencyl’s case, one reason was probably the decision to use Haxe instead of C++. Another was its lack of focus on consoles. Haxe’s biggest strength at the time was Flash game development, since it generated Flash ActionScript. Then the iPhone effectively killed Flash, forcing both technologies to pivot toward mobile.

  • Stencyl appeared around the same period as many modern indie game tools. Later, Godot’s popularity grew significantly after Unity’s controversial Runtime Fee announcement. Although Unity eventually reversed course, many developers never returned.

  • Unreal’s announced direction for the next generation—combining Verse, AI, and MCP—may increase interest in more structured and reusable visual representations instead of relying exclusively on the current Blueprint system.

  • We’ll see whether Unreal actually revives this approach or whether it ends up becoming another example of a technology that, despite being superior in many respects, never becomes mainstream.

  • The central idea connecting all these points is simple: every representation should be used where it provides the greatest advantage. Graphs are excellent for discovering solutions and experimenting with architectures. Hierarchical block systems are better for consolidating abstractions, reusing components, and reducing complexity as projects mature.

  • My conclusion is that the best approach is to use each tool only where it performs best. Graph editors provide the best usability during experimentation and prototyping, while becoming an increasingly poor strategy once the system grows beyond that stage.

P.S. I believe that understanding these differences requires hands-on experience with both approaches. Personal taste, assumptions, and preferences are usually not enough to determine which solution is best suited for a particular kind of problem.

4 Likes

scratch-style is what they had in the engine at some point for Verse, at least from what I got to see. )which, at least for me, would be completely fine as replacement for BP)

The point isn’t if Blueprints were the best tool ever made.

You can’t realistically be arguing that spaghetti blueprints are worse to maintain than obfuscated C++. I’m sure you all know that really bad code can be orders of magnitude worse than what you can ever do with BPs. (and much, much more costly to fix) I don’t know how that translates to Verse but usually the larger the capabilities the worse (more diverse) problems you can have.

I can’t really see the link between the architecture change (multi-threading) and BP deprecation. If anything, I see a missed opportunity to show each thread as a branch of a graph and linking variables between branches to visualize race conditions.

I also see no one arguing against node-based programing for shaders in favor of HLSL… It is a valid point to make against node based programming. (assuming you can make one)

For me, the best thing about BPs is the short “compile” time and the robust error handling. In my experience, every increase in compile time reduces the number of iterations and tests being made exponentially. Creative people get bored and they move their “good enough” goal closer.

The thing that worries me the most is that all this is done for no good reason. I can’t really stress enough how little I care about using AI and making games compatible with Fortnite. I’m really scared to see what will be the inherited limitations from Fortnite… (along or besides the new architecture)

1 Like

With AI in Rider, it writes C++ functions for me that I do not even look at, and I just use Blueprints to hook them together. This new way of working feels like a step backwards in terms of creation speed and bug reduction.

I had found my groove, and now they want to go back to archaic systems, haha.

1 Like

These are true, but true for any engine, even with the current structure. People would still make a GameManagerActor in the level to do everything. We see this in many places.

That is also what makes a Technical Game Designer a good designer: making cases, deep thinking, decision making, edge case conditions, fail conditions, success scenarios etc. That is actually an important aspect, to give your engineers good design and assist them, since even with one-shot designs, we know game feeling is something that cannot be felt unless it is played. So changes happen, and designers first hand have to foresee possibilities. Secondly, engineers and all devs have to expect/foresee them too.

With ECS, even for games with one playable dude, we will possibly see many GameManagerObjects :slight_smile: That maybe is actually something nice, so Design, Technical Design, and Engineering will matter more, and this will require more experts to be hired. That is good and bad. In the end, this will be a production problem, as mentioned before.

Iteration time, devs / studios understanding what they want, rapid prototyping and experimentation, planning, source management become definitely more important. I am not sure if this is good or bad. As a person who has seen these cycles of development in AAA from both sides, I lean more towards having non-programmers access logic, data, and even change / experiment with things, rather than requiring an engineer for everything.

So this worries me in that aspect, besides everything actually.

Example:

  • Will join a studio as Game Designer: I will go change logic in C++ that makes an additional valid check to something with a raycast and submit it, then Engineer will go NUTS because why did you touch code :slight_smile:
  • Will join a studio as Technical Game Designer / Programmer / Engineer: I will waste all my time trying to figure out what DESIGNER wants with tons of meetings, vague high-level docs, partial specifications, bad UX and gameplay, and try to stay sane while writing my classes :slight_smile:

So it is not good. I know people can see this as emotional and exaggerated, but it is what is going to happen. I know it because I have seen it. Blueprints have their problems, and I am even okay with the tradeoffs to get rid of them in some ways, but production-wise it will take away the ability from many devs to work alone in their style, experiment, make up their minds, and go through iterative development: what can be carried to C++, what can stay as it is, what can stay as prototype BP.

This is something only Unreal can offer fully in the industry, not partially. Maybe I should switch to shaders and Technical Art, so I can be a free agent with “Do Whatever Mode On” in studios :slight_smile:

The point is, I can clearly see engineers being in favor of these changes, and I can clearly see the advantages too, even I want them. But production-wise, in the very very end, if this becomes real 5 years later, it may still be bad in some ways. The result can be fewer games, but better games. That is what I see with this, rather than just visual programming.

2 Likes

Objective opinion.
Don’t be lazy and read to the end, a lot will become clear. :wink:

In business history, this has happened many times: when a market leader becomes so confident that it starts ignoring its users’ interests in favor of its own global ambitions (in this case, the Fortnite ecosystem and the metaverse), it always leaves behind a gigantic empty niche.
If the Blueprint and Actor systems are replaced by Verse and an ECS architecture, this will split the market in two.

Mass devaluation of millions of assets: Today, the vast majority of existing 3D assets, code modules, and templates are built on Blueprints and the traditional Actor system. If UE6 eliminates these, those assets will overnight turn into “garbage” unless their authors rewrite them entirely for Verse. Many authors simply won’t do that.
We can expect rising prices and developer demotivation. Creating high-quality assets compatible with the new system (Verse) will be difficult and expensive from scratch. This will drive prices up, while the number of buyers (indie developers who are currently panicking) will decrease. As a result, the ecosystem that Epic built with the Fab platform will take a serious hit.

Who will leave Unreal?
Epic Games made a huge mistake by assuming that developers would forgive them anything. People chose Unreal Engine for two main reasons:

C++ control (for large studios).
Blueprints (for indies, artists, designers, and rapid prototyping).

If you remove the middle layer (Blueprints) and force people to learn an entirely new, specific language (Verse) — which for now is optimized only for Epic’s internal ecosystem — you lose the most loyal and massive part of your audience. Hobbyists, technical artists, and indie developers will start looking for alternatives en masse.

Unity tried to implement DOTS (their version of ECS) while keeping the old Mono logic in parallel. They introduced the new UI Toolkit while leaving the old IMGUI. The result was a “Frankenstein engine” where nothing worked stably. Add to that poor monetization policies, and the company nearly collapsed.
Epic will realize this too late, and it will be a bitter lesson — but remember my words.
Forcing users to switch to a new system (Verse/ECS) when the old one (BP) works perfectly causes panic. Indie developers are the backbone of the engine — alienating them is fatal.

Full deprecation of Blueprints and the Actor System: This is the biggest question mark. Blueprints are not just “visual scripting” — they are a visual asset, a composition tool where models, textures, sounds, and logic come together. The complete disappearance of Blueprint Actors means Epic intends to move to a pure ECS (Entity Component System) model (which we already see in UEFN). However, migrating complex projects to pure ECS with “automatic tools” (Migration Tools) is practically impossible because it requires a completely different paradigm of thinking.

Who will benefit from the moment?
As we all know well, a vacuum is never left empty. Just as years ago when Autodesk changed its policies, it opened the door for Blender, which has since captured a huge share of the market.
If Epic Games carries out this radical migration rigidly and forcefully, several scenarios will play out on the market:

Godot is already very popular among indies. It is completely free (open source) and lightweight. If they further refine their graphics renderer (their version of “Lumen/Nanite”), a massive wave of indie developers will move there.
New players (e.g., Unigine or entirely new projects): There are engines on the market (such as Unigine) with extremely strong C++ foundations and graphics, but they previously lacked popularity. Unreal’s crisis will be their opportunity.
Return to custom engines: Medium and large studios with strong C++ teams will get tired of chasing someone else’s whims (first Unity’s Runtime Fee, now Epic’s architectural upheaval) and will begin developing their own internal engines or fully forking older versions (UE 5.x) and bringing them under their own control.

My personal advice for those on C++:
While Blueprint-dependent people are panicking because their only tool is disappearing, for us the core (Engine core) remains the same. If Unreal Engine 6 really goes in the wrong direction, our coding, technical tools, and algorithmic knowledge can be easily ported to any other platform or engine that emerges as a leader during this crisis.
And for those who spent years learning Blueprints, support their families with income from assets, and have huge projects built on Blueprints:
I advise them to either find an alternative or learn Verse — though the latter is much less likely.
Because the difference between a C++ programmer and a visual programmer is not so much about “talent,” but about the architecture of thinking, cognitive load, and how the human brain processes information.

People who dedicate their lives to Blueprints are often brilliant architects and game designers. Their brains are wired to see the big picture, the “fun” factor of a game, and systemic connections.
But their brains are structured this way: they process information primarily with the right (visual-spatial) hemisphere. C++ and Verse, on the other hand, demand maximum load on the left (analytical-symbolic, linear) hemisphere.
This is exactly why many people don’t fail at learning code because of a lack of talent, but because of a cognitive barrier. It’s the same as forcing a painter who has worked with oils for years to describe their paintings using chemical formulas and coordinate grids.
The brain simply says: “This is not my language” and refuses to work.

In visual programming, the brain mainly uses three-dimensional, spatial, and associative thinking.
When a person works in Blueprint, their brain perceives the code as a geographical map.
Low “cognitive load”: Blocks hide complexity. The brain doesn’t need to think about memory addresses, strict type compatibility, or where to put semicolons. A block is a “black box” labeled with a function (e.g., Destroy Actor), and the brain jumps straight to the result.
Visual recognition (Recognition vs. Recall): It is much easier for the human brain to recognize a familiar shape/color block on the screen than to recall syntax from a blank page and type it from scratch.

How the C++ (textual) coder’s brain works:
A C++ developer’s brain operates in a completely different mode — it is an abstract-symbolic and multi-layered model.
Code as textual abstraction: A C++ coder has no spatial cues. Code is a linear flow of text. The brain must itself construct a virtual architecture from that text in the mind.

When a C++ coder writes MyActor->Destroy(), their brain subconsciously processes several layers: “Is this pointer valid? Where is it in memory (Stack or Heap)? Who owns this object? Will this cause a memory leak?”
Strict formal logic: Textual code will not forgive even the smallest mistake. The brain constantly works in “compiler mode” — it follows a huge number of rules, syntactic conventions, and low-level principles.

When a person accustomed to blocks opens Visual Studio or the Verse editor, their brain experiences sensory deprivation. There are no longer colors on the screen, no lines (wires), no space. There is only a black screen and white text. The brain loses orientation, anxiety begins, and it refuses to accept the information because its familiar “spatial map” has disappeared.
You might think Verse is simpler than C++, but for a block-based thinker it is often an even bigger nightmare. Verse is based on functional and data-driven programming.

For example, in Blueprint there are direct events (this happened → do this). In Verse there are concepts like failure contexts, decidability, and immutability (variables you cannot change). This is pure mathematical thinking, which completely contradicts the intuitive, “hands-on playful” approach that Blueprints offered.

and finally I will say that
Your main capital is not the Blueprint nodes themselves, but your experience and knowledge of making games. The engine and language are only a pencil in your hand. If they take away your pencil and give you a brush, it will be difficult at first, but you will continue painting — because you already know how to paint.

Guys, this is just my objective opinion,
and doesn’t reflect anyone else’s opinion.
I’ve lived long enough in this world to know where to place my feet to avoid falling.
Thank you for reading to the end. :white_heart:

1 Like

(post deleted by author)

Well, whatever the last supported Blueprint-heavy version of UE is going to be, 6.2, 6.x, or whatever, looking at the comments and responses, that version seems like it would be popular for a while.

Expect to have custom branches even :slight_smile: Unless Epic surprises everyone with how intuitive the new changes are and how much more powerful Unreal becomes.

Products change, decisions are made alongside that, and some of these decisions raise new companies to the top while some make them collapse, like Kodak. Without giving names, that is for sure the same for gaming studios / companies too. Sustainability is always a problem, and I highly doubt this is only a sustainability / ecosystem decision.

I think it is a mix of many things.

  • Reducing duplicated engineering effort inside Epic to continue making Unreal the best. Merging product lines / ecosystems is the way to go, so it becomes one product with many features.

  • AI, well, love it or hate it, and I hate it but I use it, it lowers my tedious work. If you know what you are doing, it is generally good. It is still stupid for now, so use with caution. That is probably what Epic is doing too.

  • Technically, multithreading and ECS are very nice. It is a mindset change, but it is not bad. The bad part is losing the visual layer of development, but it is not entirely lost. Graphs in many things, like materials, will stay. Even if UMG does not have a graph, which we do not know, it can be Verse, it can be rewritten, or we can build one. Like quest plugins / systems, it is possible to make custom graphs that communicate with whatever system. In the end, from a designer perspective, it is still systems talking with systems. Nothing is really lost, it is still the same idea. The possibility is that this is not “out of the box” anymore, so expect job descriptions like “Need developer with Verse coding +10 years” soon :slight_smile:

  • As an industry, we are all in a hard spot: devs, studios, artists, musicians, and games themselves. Choosing an engine is not just technical. It is about scalability, what the game needs, community, resources, workforce, and so on. I would not lower my assumption of why people choose UE to two main reasons, to be honest. Unreal is a very intuitive engine, and I am pretty sure Epic will do whatever they can to keep it that way.

Edit :
PS : Also let’s remember how lucky we are to have Open Source, Free Use, Extremely Capable, Well Designed engine we have literally “One Click Away” from download :slight_smile: When I was in my twenties, I could only have dreamed about using a game engine in my country since that would require minimum 1 million dollar in my pocket :slight_smile:

1 Like

I actually have a question that is really bugging me. Not blueprints, not Actors, not ECS.

I am not satisfied with what Verse introduces? What is “New” and “Nice” About it?

Why Verse? Why Inventing a new language? I check it, I didn’t see a big benefit so far ( including, readability)

Why not C# or a Subset of C#?

Can someone enlighten me with some arguments?

Cause I am not satisfied what is said in the presentations. That didn’t fully even nearly legalized it for me. Cause those things can be done ofc in C++ or C# which is quite popular, many sources.

Is it like Microsoft issues? Is it technically making C# restricted harder that would be easier/secure for common users? Or is it OOP simulation oriented problems? cause imo C# a subset of it can do these.

Edit :
It has emojis out of box though

because verse is simple to learn.

If someone like me, who never wrote a line of code before can “kinda get it” within 20 minutes, then its simple.

Now I just need to remember how all the things are written, just like I had to remember all the BP Nodes that exist.

C# is also simple, also much more readable. You can do code in 20 minutes as non programmer in many languages probably much faster in C# than Verse, C++ has a much more higher learning curve compared to C#.

All I see some Effects and Transactions → Can Fail

TryBuyItem(Player:player, Item:inventory_item, Price:int)<transacts><decides>:void =
    Player.Gold >= Price  # This is Case
    Player.Inventory.CanAdd[Item]   # This is Case

    set Player.Gold -= Price   # Deduction and so on
    Player.Inventory.Add[Item]
    Player.QuestLog.MarkBought[Item]
    Player.Stats.IncrementItemsBought()

C++

bool UInventoryComponent::TryBuyItem(const FItemData& Item, int32 Price)
{
    if (Gold < Price)
    {
        return false;
    }

    Gold -= Price;

    if (!CanAddItem(Item))
    {
        Gold += Price; 
        return false;
    }

    AddItem(Item);
    return true;
}

C#

public bool TryBuyItem(ItemData item, int price)
{
    if (Gold < price)
    {
        return false;
    }

    Gold -= price;

    if (!CanAddItem(item))
    {
        Gold += price; 
        return false;
    }

    AddItem(item);
    return true;
}

I don’t think this is just that “if” or “break” problem :slight_smile:

nah, C# looks absolutely intimidating and annoying to deal with in comparison. (at that point, I will just ignore C++, which apparently most people dont like anyway.)

readability is down the drain, and those {} are a complete pain in the rear to deal with, good that verse mostly doesnt use them.

I would not be able to do C# even remotely as quickly as I have done with verse, even with all the knowledge from blueprint.

Verse apparently does what it was designed to do very well, looking at this.

@Yaeko That is fair for you, but that is also personal preference, not a technical argument.

Since you can clearly write C++ and C# - you are not the target audience for Verse.

You are to me, and the others that relied on BP, what I am to a BP beginner - not comparable. (It is only natural that we disagree on the readability.)

What you consider “easy to read” is very hard to decipher for others, just like my BPs would make a Beginner run away crying :rofl:

If you are coming from C, C#, C++, Java… something like Php is going to look like rubbish. Now going from no coding experience to Ruby, it’s not that bad. Hell Python is intuitive enough if really want to learn.

Programming is programming once you wrap your head around the architecture, nuances and syntax. Just getting in it is the hard first step.

2 Likes

I will just be sticking to UE5 and blueprints!

There’s little to nothing that UE6 could possibly offer me to make gamedev “easier” as a solo dev. They already packed into the engine much more than I care to learn and I can do most of what I do just fine. I have over 10 years-worth of custom bp functions and subsystems I’ve made for myself. I will not throw that away to learn yet another scripting language unique to Unreal, that doesn’t seem to offer any benefit, not when the whole engine is there in C++.

I’m also doing solo dev so I need speed! When I can drag and drop my content browser mesh selection into an array in verse, wire two functions and have a procedural mesh spawner in 10 seconds, that’s when I will consider any text-based script.

I’m 100% sure that Epic does NOT realize how the vast majority - even in AAA studios - is relying on blueprints. Hell, maybe their engineers don’t realize it either.

It would seem the purists that never learned blueprints properly or just worship the church of code on reddit and other online barking stations instead of doing wholistic dev work, managed to convince Epic that blueprints are just an annoyance they need to maintain and only noobs and cheap indies use them, thus they make Epic no money. Well, they’re in for quite the surprise. Wherever I worked (smaller or bigger studios) we were absolutely relying on blueprints, especially for asset-oriented work.

Dropping blueprints is a major blunder. Just like they went with leftism and destroyed the goldmine that used to be “Inside Unreal” and the Tech Talks during the UE4 era, hiring fake-smiling cringe yellow-haired hosts that know nothing about the engine; just like they sunk money into that other cringe story they were obsessed with - the Metaverse - they are now making another huge mistake - maybe the biggest so far.

Blueprints was the ONLY reason I picked Unreal over Unity, back in 2014.

/rant.

5 Likes

If I understood correctly they want to make it open so other engine can use it and be able to create content for Epics ecosystem. It goes in hand with other ideas like adoption of standardized open tools, just that they will be the guardians that have control of the implementation.

Fab itself was a total blunder too. The old marketplace was miles better. When we were complaining about how bad it was, we just had no idea how bad it can become…

2 Likes