I am very sure, that we can have both, since a “visual verse file editor” doesnt even need to touch the engine functionality - see the proof of concept above.
If people do nonsense with the editor, then thats up to them, just as would be if they had to write it manually.
Everyone here seems to be missing the point of verse. Epic Games isn‘t pushing Verse because it‘s easier, or better, they push it because of this:
Metaverse First: Verse is designed for a future where code runs in a single global simulation—the metaverse. This influences every aspect of the language, from its strong compatibility guarantees to its effect system that tracks side effects and ensures safe concurrent execution.
That‘s all that really matters to Epic Games. “Run your game in their Roblox clone aka Fortnite or ■■■■ off.” They want to be in control of the metaverse, and they are okay to waste the time of every Unreal Dev to reach their goal.
Instead of properly keeping their Engine and Game separated, they try to push developers to also release into the „metaverse“ aka fortnite. With verse/ue6 it will be super easy. Mind you Fortnite will probably has seen its best days by then and no one will give two ■■■■■ about it. But hey at least developers had to sacrifice a cumulative million of hours retraining and adapting because of the senseless whims of the top executives at Epic Games to then be able to develop for a dead ecosystem no one cares about.
Hopefully they (or one of us, via Fab plugin) could come up with some sort of hybrid approach where a visual verse graph tool really only needs a VM in editor to link references, provide context, and such, then spits out code that only uses the standard Verse modules in runtime. And it would be up to devs to make sure their refs/vars in the output code are clean, or just set them manually as one would with an external tool.
Summarized discussion overall so far.
Thank me later!
That’s nowhere near a proof of concept. Not even remotely. It’s closer to an idea of what a visual node based system would “look like”. It can’t hook into to C++ core classes to provide nodes for function use. It can’t even grab custom class functions or read other verse classes for event calls.
That’s what I was noting a few pages ago. 3rd Party Plugin. That’s somebodies potential gold mine.
That would be ideal. But generally, it’s quite confusing
“An electrician doesn’t make their own pliers and electrical wire”
“A carpenter doesn’t make their own hand saw and wood”
A programmer frequently builds their own tools and resources
And that’s exactly where all this confusion comes from
Creating a sprite → “I’m developing a game”
Modeling a character → “I’m developing a game”
Programming an inventory → “I’m developing a game”
Even though actual game development only truly begins once you have all the pieces and all that’s left is to connect them
A sequence that, in practice, rarely ever happens
Because programmers build the tracks while the train is already running
In programming, ideally, you should build the libraries first
Inventory.add
Inventory.remove
etc.
After building that, you simply use the bug-tested resource
But in practice, they build the functions first—often incredibly well-named
AddWeapon-with_three_shotsToInventory
AddWeapon-with_two_shotsToInventory
Only later do they realize they need to separate responsibilities
And refactor the spaghetti
A more organized game studio can reuse the same pieces to build multiple games
The chaotic ones frequently recreate the exact same pieces over and over again
For instance, every time they need to make a character move, they rewrite:
C++
(...)
const FVector ForwardDirection = FRotationMatrix(YawRotation).GetUnitAxis(EAxis::X);
const FVector RightDirection = FRotationMatrix(YawRotation).GetUnitAxis(EAxis::Y);
AddMovementInput(ForwardDirection, MovementVector.Y);
AddMovementInput(RightDirection, MovementVector.X);
(...)
C#
(...)
if (controller.isGrounded && velocity.y < 0){
velocity.y = -2f;
}
(...)
Other times, a level designer pieces things together and builds new components for a game designer to use
Or vice versa
This makes it even harder to distinguish:
And the Independent Developer is usually a one-man band
They don’t realize they are filling 33 different roles that require 99 different skills 
From what I’ve been reading.
The demand / petitions are about continued official support.
Nobody wants 3rd party (maybe having to pay) for Blueprints that are currently free and working.
I get that and understand. Yet any level of of “good” visual scripting is going to need to hit the engine.
ECS/DOD. Is a lot different from Actor/OOP.
I do wonder, why should a beginner, or an artist, or hobbyist, that so far had not to deal with code and knows pretty much nothing about it, deal with Verse, and not go straight to whatever C Unreal Engine is using? Because honestly, for me, both Verse and C look similar (incomprehensible). So if i absolutely have to learn code, why should i pick Verse over C?
So if i absolutely have to learn code, why should i pick Verse over C?
You shouldn’t. You learn C++ C# or generally understand how a computer works. You cannot know everything for sure. Like there is many things shared by other devs in this thread that I learned,
However Verse’s entry point and learning curve seems to be much much lower than C++ even maybe lower than C# so that is a nice thing and that can be a distinction to write upper level gameplay systems that are much more robust. So maybe that can be a reason to prefer.
Accessibility wise, no objections there are many drawbacks already mentioned in various ways in the thread.
“Blueprint” as it is right now, its already dead. (People need to understand and accept that part, I think.)
But still, not having “sketch” or similar to edit .verse files is weird, especially since UE3,4,5 were using kismet/BP a lot and it wasnt just “some random stuff” bolted on.
“Actors” being gone, meh, couldnt care less - they get a replacement after all.
From what I have seen of it, its a nothingburger.
I definitely wouldn’t be afraid of that. They don’t make an engine just for big companies (CD Projekt Red etc) or even an engine just for themselves, but it’s publicly available. And there’s quite a difference - public engine vs inhouse. Now they’re moving more towards inhouse, although they’re looking at common mistakes like documentation and such… but the rest they’ll let the public know.
Honestly? UE 3 with only keyboard movement in the scene was terrible and UDK and public feedback got them back on track. So I would just take this as a lack of communication with the outside world, but if they share technologies, it won’t be missed.
That’s your opinion, not the general truth. You’re talking about some spaghetti blueprints here, etc, and I have to admit that while they may exist on the store and in inexperienced teams, they are really rare in professional production.
The technical side and accessibility are two very different things. I don’t understand how you can take one as a supporting argument for the other. There will be a verse. But people are protesting about accessibility and visual scripting. Which is also possible even with Verse, by the way… it just didn’t “seem” right to the Epic people… (see previous comments) - thats the problem (aproach - not some technical side of Verse.).
It’s the way it worked in just about every team project I’ve worked on since the early 2000’s.
Brainstorm the general idea. Look at some designs. Scope the project. Do minor idea based prototypes. Define the framework scope. Delegate the scoped framework. Build.
Here’s the idea. Ok, let’s do some protos on some of the heavy stuff we know we’ll be fighting against for performance. Test them out. Refactor based on the prototype results. Now that we know how to attack x issues we can do a robust scope.
Walk every core feature. Drill down these systems and how they’ll hook/integrate with secondary/child systems.
You don’t have multiple devs working on the same system. That’s how code gets broke and bloated. You delegate fully scoped and drilled write ups. There’s no confusion about how it’s suppose to work or what gets exposed.
All the transition from Blueprints to Verse does is shift to a more “LLM friendly” system (getting an LLM to do anything graphically with precision, consistency, or specificity is like getting a dog to Meow )
Blueprints for cooked projects could be resolved down to Byte code, and even “translated” into an intermediate (the system takes that VM generated Object-file, and then does a noodle by noodle translation into something that can exist outside the VM) it would slow down the “compile” step, and you lose the “graceful” exception handling, and real-time in editor Debugging.
If I lost “graceful” exception handling (the majority of real exceptions that are encountered are usually attempting to refence NULL, index out of bounds, infinite loops, or GC running away with a pointer), and the real-time in Editor debugging. If I gained performance of not needing to be in a VM, or the ability to use multi-threading ability that would be fine (debugging multi-threading is already race-condition-roulette and leads some programmers to drinking). heck they could even have 2 types of Blueprints:
In both of these situations Blueprints can still be “first class citizens” at least as much as they are now, and with Type1 even closer to C++
Epic’s Choice to delete Blueprints in favor of the LLM friendly Structured English. It is also more LLM friendly because it won’t be poisoned into hallucinations with out of date information, or information from completely different API/runtime (if it was in C# there is a non-trivial chance you would get an a code chunk for Unity-2013 or even XNA)
even if every node/box was a separate line of code (things like Delay becoming a delegate + a variable + callback function in the header, and then a “single” line of code in the cpp not withstanding because those and things like them balloon code length a lot)
looking up a Verse Timeline looks like torture, and the entire reason why Timeline objects were created for Blueprints early on.
The idea that Verse is more LLM-friendly is merely our speculation on this forum.
LLM handles better languages that it was trained with a lot of data.
And not necessarily with a new language that is simply more simpler.
That is the last thing on the list of priorities. Verse was not created with that in mind.
Other more significant advantages:
Software Transactional Memory (STM): Verse allows thousands of players to interact on the same map simultaneously without crashing the server (avoiding the notorious deadlocks found in C++).
Seamless Hot-Reloading: Updating game code in real-time while players are on the server, without needing to take the world offline.
Absolute Security: Enabling anyone in the world to submit a script to the Epic Store without the risk of that script stealing data from another player’s computer.
etc
The long-term goal is to be able to create everything using Verse,
and to use C/C++ less and less — only for low-level bit-twiddling.
About the new Visual Verse
In a survey of UEFN creators, Epic asked which version of Verse they prefer:
Regardless of what they choose, the current Blueprints will no longer exist in the future.
They can use something similar, but with a different name and different implementation logic.
This is the best system I’ve found for organizing code.
Including, this is my editor’s code, inside the editor itself.
I started the project inspired by Smalltalk and Stencyl.
But in practice, mindmap that turned out to provide the best usability for me.
And it brought back the “Joy of Coding”.
Simple solution: boycott UE6, trash talk it, don’t download it, fork your own UE4 and UE5 branches and use them forever. 
