Why not just leave the current engine as is and make a different one for all the new stuff?
2 Likes
Because Unreal 6 is basically Unreal 4.37.
I have been porting a Blueprint-only project originally created around ten years ago. It is old enough that parts of its UI were made before UMG/Widgets even existed. Yet I have moved it from version to version all the way to UE5.8 with maybe four or five warnings per upgrade â sometimes none at all. And I expect it will port to Unreal 6 in much the same way.
Even Scene Graph and a traditional text-based scripting language feel less like a new engine and more like the final step in Unrealâs gradual Unityfication. So as long as the project keeps opening, compiling, and porting forward, we are still basically using Unreal 4.
and After working on medium-sized Unity projects for years at different companies, Scene Graph gives me nightmares. Not because scene graphs are inherently bad, but because they can turn a project into a maze of giant hierarchies, nested prefabs, hidden dependencies, and instance overrides that nobody dares to touch. You end up with empty objects used as pivots, offsets, folders, or mysterious script anchors; a small visual fix can be inherited from three prefab levels above; and deleting something called âRoot_OLDâ can somehow break a door on the other side of the game. At that point, maintaining the project becomes archaeology rather than development , and you develop a genuine fear of pressing Apply All on a prefab.
At least with an Unreal Actor, you feel like you are touching the ground: this is the thing, these are its components, and this is where its logic lives.
We can always fork UE5.8 and live like the Amish: Actors, Components, Blueprints, and the comforting certainty that deleting an empty object will not summon a production incident from 2019.
4 Likes
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
(post deleted by author)
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 