I’m still waiting for it to finally tell me who’s Json
2 Likes
I don’t know, but he does a lot of coding…
I think he also hangs out with those Argon 0s
2 Likes
I hope, you are right about custom visualizers. What i love about Blueprints, is that it visualizes the logic flow really well - just follow the white line.
Verse might be great, but what i saw so far… ok, i don´t mind script languages, but for me, it highly depends on… whats it called… the syntax? The structure? What i have seen from Verse didn´t look very appealing, or readable 
Something like LUA looks more readable and accessible than Verse. Verse looks like something designed by coders for coders.
they did, its called UEFN, and they decided that bring it into UE. Just wish they kept it seperated
1 Like
Instead of improving the engine, it feels like they are ruining it. Nobody wants to be forced into Fortnite development. Making content publishable on Fortnite should be completely optional for Unreal Engine developers.
Verse should also be optional, or kept strictly as a UEFN feature. Most Unreal developers rely on Blueprints because they work incredibly well and are highly loved. Why get rid of a system that everyone uses? C++ and Blueprints need to remain the core ways to develop in Unreal Engine. Verse should only be an extra option for those who actually want to publish to Fortnite.
Don’t fix what isn’t broken. Focus on what actually needs improvement instead of changing the tools we already love. 
EPICCC WAKE UPPPPPP YA’LL RUNNING ON A BURNING BRIDGE
Their turning the unreal engine into a slop engine
1 Like
To me the worst part is that they dont even plan to replace blueprint after removing it…
Also, players don’t like AI, and Epic’s response is, “Let’s go all-in on AI…”
Like, yeah, okay—the gaming industry is doing so well right now, let’s do the exact opposite of what our customers want.
Also, people who say Blueprint is hard to maintain or update just need to learn how to organize things.
3 Likes
I absolutely hate the idea of removing blueprints.
Spent 10 years learning the engine, and building a very strong framework for our future games mainly in blueprint, just to see that go up in smoke? sounds terrible.
I also don’t believe you can make serious/bigger games with vibe coding. Neither you or the AI would be able to know exactly how the game/code work.
Actors rely on OOP inheritance. This results in high memory overhead, CPU bottlenecks, scattered memory pointers, cache misses.
Because any actor can access and alter any other actors properties and data at anytime, the engine struggles to parallelize the workload… Forced sequential processing.
References and casting create deep asset chains which forces asset loading. For example, loading one actor can force the engine to load many more unnecessary actors that eat memory.
DOD & ECS are the future.
It seems you do not understand the overall issues with the Actor framework. It cannot be optimized. Force Sequential Processing.
You also don’t understand that you can publish standalone games in UE6.
AI isn’t forced. It’s actually disabled by default. You have to enable and configure it.
1 Like
Having too much faith in AI is a bad thing, it never gives you what you want
2 Likes
I can understand removing Actor (migrating after the fact will be nightmare Looking at what happened with Unity where there is effectively 2 different asset stores for before and after Dots (they also did it twice with their 2 different render pipelines)), I even remember my first attempt at making an RTS in UDK, I nearly ended up re-implementing Pawn and Character into my custom Actor (OOP things can get dumb when you don’t see the power of composition)
if Verse is so easy to learn (the people that gravitate toward structured English will not always be the same as those that gravitate toward boxes and noodles), and “optimized” (I have big doubts considering the forced limitations that had to be imposed just for UEFN to not have heart attacks)
-is there no practical way to migrate the Blueprint compiler from the soft JVM implementation, and do a 2 step compilation into Verse, and then into what ever the Verse compiled object code would be.
heck this could even be concurrent where if a node is connected to an entry point node in the blueprints it generates the verse on the fly, and then the “compilation step” is taking that generated Verse and put that into whatever its compiled version is.
-The hardest part is the reverse: taking a Structured English and translating it into boxes and noodles because spacing and alignment can become massive issues based on the flavor of OCD.
Blueprints was supposed to be an entry point where a level designer doesn’t need to learn the trials and tribulations of pointers in order to make a box move, and they don’t need to pull in a “programmer” to get their quest to function. By removing the visual programming of Blueprints and replacing it with another structured English is not a real replacement. The new sales pitch of UE6 is “we have 2 strongly typed Structured English programming languages, one is Verse, and the other is C++. We used to have a Visual programming language, but that was ‘TOO HARD’”,
1 Like
The visual tool would have to be almost a 3rd party plugin that ran alongside, but not in UE. Do your node thing and compile it. On the plugin side it stores an XML file. On the UE side it creates an Entity, Component, or System Depending on what you are doing.
Entities: An entity is an empty shell; it represents an “object” in your game world, but possesses no data or logic on its own.
Components: Pure data containers. They hold specific variables like health, position, or velocity, but have absolutely no functions or logic.
Systems: Pure logic and behavior. Systems scan for all Entities that have the specific Components they care about, and execute the math or operations on them (e.g., a “Movement System” updates the “Position Component” based on a “Velocity Component”)
UE6’s architecture will be completely different to that of UE5.
ECS focuses on data-oriented design. By storing raw component data in clean, continuous blocks of memory, the CPU cache can read it much faster, preventing performance drops in scenes with thousands of moving parts.
ECS architecture allows the engine to distribute calculations across multiple CPU cores simultaneously. This makes rendering, AI, and physics processing substantially faster
2 Likes
I dont think people care about what the new systems are, or what not, they simply want a visual interface for verse files.
One which we even have images of, because it exists(ed), but epic never finished it. (I dont have an image right now, but I have seen it - in its unfinished state.)
It doesnt matter “how” we edit the .verse files.
The issue for people is not the 2 clicks it takes to create a .verse, its the “how do I write in it” - ECS and all that stuff can work just fine, as long as whatever that “blueprint” would be, only edits the .verse file currently open - just like VSCode also does.
Everything else can stay, even the multithreading etc. because its just an alternative way of “writing” the code inside the already existing .verse files, not a different system like Blueprint.
Yeah, people would still needed to get used to a slightly different approach (that you cant just cast and do stuff anymore, but whatever, thats a compromise people have to swallow.)
We can literally have the best of both worlds, without compromises to either one (at worst, a few fancy things dont work in the visual editor, but thats probably too advanced for users who rely on this anyway) - why are we still arguing against each other here?
1 Like
If someone cannot design clean code with simple classes, interfaces, and well-defined responsibilities, they probably will not get much out of ECS either
For a game with one playable dude, a few weapons, and around twenty enemies, ECS usually does not offer a clear advantage.
Besides, every millisecond saved will quickly be claimed by ten more trees, wet footprints, and 37 varieties of slightly swaying grass.
ECS for the hordes, OOP for the important characters, and Blueprint spaghetti for when the build has to ship on Friday.
DOD & ECS are the future, VR is finally going mainstream and Linux is finally going to dominate the desktop — any year now.
I’ve seen attack prefabs burning beyond the Scene hierarchy…
I’ve seen C# rays glitter in the dark near the gates of Update()…
All those moments will be lost in time… like broken references after moving a prefab.
error CS1002: ; expected
1 Like
If they promise me that this is going to be a completely clean version of the engine — not just a patch like the transition from UE3 to UE4 — and if they get rid of all those absurd dependencies and rigid systems, then honestly, they can remove Blueprint and C++ for all I care. I doubt they’ll actually do it, but if they did, it would be the best thing that could happen to the engine. They can always build a proper graphical IDE later on 
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 
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/elsebranches 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