One of the early contenders in visual scripting for Unity used to generate C# files.
For some reason, it died a few months after release.
a Visual scripting system doesnāt even need a VM to index or reference the base; to do real time intermitent compiles on the underlying file maybe, but that is only a fraction of what is implied:
Visual Studio is able to index all of Unreal, and your C++ classes and kind of keep up with real time header changes just on hint files (almost like UML parsing but the files doesnāt need to be human readable at all times) on includes, not a VM. The entirety of Reflection is those hint files but specially written for the engine, and even those have had a very shaky re-acquisition situation when the header gets regenerated, and manual C++ thunks are a special issue.
Unreal uses reflection and a VM for runtime resolution, and the only part of Blueprints currently that āneedsā to be a VM is runtime debugging for i3 injections, realtime compilation for the error handling (to have the editor catch exceptions gracefully), and āreal timeā code injection without patching DLLs.
Nothing about a graphical editor has anything explicitly to do with ECS (I just hope it doesnāt become mandatory entrenched on the tags system of Runtime Resolved Strings, when table of int32 Enums would be far less failure prone, and typing sensitive).
-similar to collision channels, but allow for an entire int32 for the space of the enum, give every class an index into the enum (very few programs will ever come close to the ~5 billion, you might not need to re-order the Enum every time there is a delete because the space will probably be used again).
ECS is about stronger enforcement of separation of responsibility, but it can easily fall down to base containers becoming one of 2 flavors of Uber-Classes:
-they know about everything, but have no real access to anything but the pointers (like a interface that knows about every type that could be a component)
-have the implementation of everything that thing could ever have, and then toggles which is used based on flags
The other fall down of ECS is when you have containers of containers, of containers, and the system gets confused on how to walk the tree on a specific request. When an ECS gets to the Uber-Classes level; interface derivation is less overhead, and when it becomes tree traversal it is just painful to get the wrong one.
ECS can make hint file generation harder because you no longer have rigid hierarchy chains to fall back on, and walk when things are āsimilarā.
For a full list similar to currently in Blueprint right-Click->uncheck "context" would need a hint file for every class, but not impossible, and this is probably what they are trying to avoid because to have a fully context aware filtering with an ECS the system would either need a semi-rigid include list, or to grab every hint file, and try to parse all of them.
Full OOP has its drawbacks with over-reliance of inheritance chains, Virtual Function tables, and potentially Chains of casting. Then the dreaded Spaghetti code of 3 line functions.
in the practical sense yes, If Epic doesnāt implement a Visual scripting system for Verse then any implementation would need to be 3rd party by definition because a ā3rd party will need to make itā, and if there is not rigid throughline for it to be implemented within the engine then it will need to be created externally, and would need to hook into the engine externally. Similar to how currently they rely on VS-code for writing verse currently (I am sure Jet Brains is hard at work already with UE6 announcements); that would mean the Verse scripting is already outside the engine, and facilitated by a 3rd party tool.
- maybe someone could make a Plugin for VS-code, or VS itself for this visual Scripting system that just does what VS already does with hint files.
then we have replacing a Visual Scripting Language with Structured English where:
- that could be a core reason why they chose to use Unreal in the first place (I have seen Blueprints as a visual scripting language as a large selling point of the engine because boxes and noodles can be easier to start with).
- more then 90% of the tutorial content for UE4 and 5 is for blueprints because of accessibility, and a majority of this forum is about Blueprints (even in the event of the answer being āyou need to use C++ā)
2 Likes
I suppose the most absurd thing is that Epic is designing Unreal Engine 6 for the 1% of the industry.
We will have to adapt, of course, but it would be a shame to lose what made Blueprints special. They are not just another visual scripting tool: they are deeply integrated into Unreal and work like a second native language of the engine.
Epic has never really managed to turn Blueprints into a proper text-based language.
Now it feels like we are going back to 2002, just before Kismet was announced.
A bit ironic really: Blueprints are one of the coolest things Unreal has, and we may end up going back to writing everything in text and pretending that is progress.
Just when with LLM you could turn any old spaghetti into a C++ box without having a clue
5 Likes
Here are some of the problems with Blueprint. When it was made, it was meant to be easy, but making it so easy comes with some limits, and it can be slow. Blueprint canāt convert to native C++, as it allows things C++ doesnāt allow.
This makes Blueprint more like C#, that compiles to bytecode, which is slower than machine code. I hope the new Virtual Verse real-time writes the code when we build a project.
Here is a possible way around it when it gets removed: use the latest version that supports Blueprint, build your stuff, have a project that converts it, and copy the code to your main project.
Redigit often took the time to answer questions from the community.
And once, he was asked about something he regretted. And he answered this about C#/C++.
The point was that with C++ he could create a much better optimized game. And your possibilities would have been much less limited
Thatās what I remember him writing.
About XNA become obsolete, that was another problem he also complained about.
To find the message, you would have to look for Twitter posts from about five years agoāon an account he deleted.
So, if you want to confirm, itās better to ask him directly.
Ideally, those with more expertise encapsulate complex logic so that those with less expertise can simply utilize it.
In practice, encapsulation and abstraction mean:
Creating libraries, frameworks, engines, new Blueprint nodes, or any other visual system.
This prevents juniors and LLMs from making the most serious errors.
It allows them to focus more on āconfigurationā even when this configuration uses a scripting language.
Complex problems involving physics engine, threads engine, memory management engine, etc., are issues for āengine developers,ā not necessarily for game developers or game programmers.
When a developer says they are creating their own engine - they are truly creating an engineānot a game.
Personally I am OK with blueprint removal, it integrates horribly with AI coding agents
Verse is already built on a VM?
Not that Iām aware of.
Search VerseVM on ue6 source
1 Like
1 Like
Itās a temp thing. By 6.2 or 6.3 we should see this change. Epic said they want to eventually get Verse itself multithreaded. Thatās not happening on a vm.
Thatās very clearly years away from now given the structure of commits to this branch and dedication of resources to stabilize systems that will be ādeprecatedā
Yup, part of the process if you want to be able to migrate a BP project up to 6 and use conversion tools to port to verse.
I noted that. Srās design and develop the core architecture and functionality. Jrās typically handle the low hanging fruit utilizing the core functionality that Srās code.
In practice Srās would be handling libraries, custom engine tools etc. But also writing Obj Pools, Projectile physics/sub-step sweeps systems, Interaction systems, weapon systems, multiplayer split proxy frameworks.
Jrās and scripters would be using these tools and custom functionality to use in gameplay. Like writing the code that adds a weapon to the character. Attaching, calling inventory functions etc. The weapon and inventory are done by the Srās.
Iām putting panic mode on pause until they open the beta and we can see how well the conversion system works. As it is, I was already considering moving some of my heavy BP actor classes like characters over to c++ in 5 (partially for optimization, and partly because I want to ditch CMC for Mover and would kinda need to make new pawn-based classes anyway since CMC is a native component of character). If 6 can turn my spaghetti to Verse, Iām hopping on the boat. Even if thereās no stable visual verse plugin around launch, one could always continue working with noodles in 5, and port to 6 when BPs are mostly feature complete. If 6 can translate my noodles to Verse right out the box, it would save me the trouble of recreating a bunch of stuff in c++.
2 Likes
Definitely donāt panic.
What we know is 6.0ea will still have BP and some level of Verse and ECS. This is the Onboarding version. Verse is currently, 6.0 main build, on the BP VM. This means thereās a level of translation and dependency.
6.1 will start pushing toward more ECS and Verse, still some level of translation.
6.2 - 6.3 is where weāll see the complete drop of BP/Actors and other heavy dependencies.
By 6.5 I fully expect BP/Actors to be completely gone from the build. Like when PhysX was dropped in 5.2ā¦ 100% out and no longer supported in any capacity, plugin or otherwise.
By this time I actually expect CMC to probably be officially replaced by Mover too.
ue6-main is +11,440 commits ahead of UE 5.8, and moves around 900 commits a week.
They are doing some serious work over there.
I went and experimented with the āverse BPā postead above, and even without knowing which keys to use, and what to do, I am like 10x faster than manually writing things, AND I didnt even need to look at a tutorial because I could easily derive it from BP-Knowledge within seconds.
We dont need a foolproof system, I would argue.
You could always do stupid things in BP, like infinite loops etc.
āPeople doing dumb thingsā really shouldnt be the baseline that should be the limiting factor when making something like this.
==============
I really like that little Tool there, but it āfeels clunkyā - but thats probably because its in Browser.
=============
You really dont need to fight us here for weeks on end - if you dont want it, fine, but your constant arguing against everyone here isā¦ lets say, not really productive for the matter - but I assume that this is the intention?
You (to me) look like you dont want others to have their cake, even though none of us wants to take away your cake.
1 Like
Iām simply injecting some reality for those that do not know how any of these tools work. Iād love for there to be a visual verse tool. As long as it does not have an impact on engine performance.