Unity Visual Scripting receive any major updates AND NOW SPEED VERY SLOW
It won’t. It’s in “maintenance mode”, which in Unity speak means it’s as good as abandoned. No one is working on it at the moment, and they have no plans to either. Generative AI is less compatible with visual scripting tools than pure code and everyone’s going all in on AI now. I’m even hearing Unreal folks want to deprioritize Blueprints due to this.
It hasn’t received any updates worthy of the term “major” since 2022 - for over three years.
Panthen already put it right. Everything and everyone is moving towards text-based scripting, and rightfully so. Godot removed their VisualScript due to its overwhelming adoption rate of 0.5%.
Both together have a major flaw: it’s just basic imperative programming without any high-level conveniences. So whenever you have to write something like “add one plus one” you actually have to drag in 2-3 nodes. Just 10 lines of script turn into 20+ nodes which you can’t even fit onto the screen anymore.
Blueprints has done it right by supplying more high-level functionality out of the box but even that doesn’t scale too well.
You’ll find more rationale on my LunyScript website where I argue that instead of making the same code visual, we ought to be able to write more expressive code at a higher level in a way everyone can relate to.
Thanks, bro. That’s a real shame
Thanks, bro. I actually do know C#, but I just think developing with visual scripting is more fun.
This. That said I expect someone to come along with a tool that will overcome these limitations. A large part of it is the use of a file format that isn’t compatible with AI models. A more traditional scripting language that can be easily converted back and forth would be a good start. For that matter I wouldn’t be surprised to eventually see a system that works similar to ComfyUI and when you “compile” it generates the code by passing the prompts to generative AI.
I might. 
Exactly: text is transformative.
LunyScript would be easy for an AI to pick up and generate code even without training since it follows a simple mental model and clear semantics. I found it very helpful to prospect the API by having AI extrapolate “imaginary” features from a small existing code sample to see how it would look like. Usually we do the opposite, designing the user-facing API from inside out, hence why many APIs (and languages like Verse - totally not poetic) seem like technical mumbojumbo.
But once you have this textual description of code it would be little use to convert it to a visual format for future manual editing. You just stick with the textual code, and any graph visualizations really only need to be images for review.
I already done so in the past generating plantuml diagrams from block-based code. It was shockingly sufficient to just VIEW the results you wrote as code if this view updates in near realtime.
And it’s unsurprisingly far more effective and efficient to write code as text because it’s code’s natural representation.
… and then a day later someone came along and supplied a Claude Skill for Visual Scripting. 
That’s a fun one, but still doesn’t change the fact that Visual Scripting package is a technological dead-end.
Anything of real use will probably come in combination with the new Graph Toolkit framework (programmatic graph/node creation API is coming in 6.4 or 6.5 for it).
Technological dead-end?
Have you seen the inner code of how uVS is made?
To determine it has no future as update? That its easier to discard it?
Im curious
First of all, there was a dedicated UVS team that got either laid off or transferred to Graph Toolkit team years ago. There’s no longer anyone actively working on UVS features at this moment in time and per last available information from the product manager there is no plan to do so in the future either.
UVS is officially in “maintenance” mode which in Unity-speak means the tool is as good as abandoned and will only get some minor compatibility fixes or blocking bug fixes for as long as it’s not deprecated.
Secondly, UVS is technologically stuck in 2018 when it was still developed by a solo developer. After Unity purchased the tool from the said solo developer, they didn’t make any fundamental improvements to its base technologies. It’s still based on IMGUI, which is a legacy technology - all new Unity editor tools are built with UI Toolkit including their new Graph Toolkit framework. Before UVS team was disbanded, a migration to Graph Toolkit (or rather it’s previous incarnation - Graph Tools Foundation) was in the plans, but never happened.
Additionally, UVS uses FullSerializer for all its serialization needs. Fullserializer was last updated in 2016, it’s essentially dead technology and the reason people are getting their variables wiped from time to time or graphs wiped of nodes when trying to Undo and similar serialization bugs that were never addressed.
And finally, the reflection based runtime is incredibly slow in performance and not really fit for production in studio environment for a lot of games. We were at the cusp of testing a new high performance runtime developed by the now disbanded UVS team, but it never landed. Layoffs started to happen around that time and UVS team went from biweekly/monthly check-ins in the now shut down Discord server to complete silence. This was like 3-4 years ago.
I wouldn’t be surprised to see Visual Scripting package deprecated in Unity 7. Migrating all its core technologies to modern standards is so much work that it would take many years to complete even if they restarted the process now.
I recall back then they were even hopeful to marry Visual Scripting with a DOTS / Entities backend.
This FullSerializer? That also seems pretty much abandoned 10 years ago - though in all fairness probably doesn’t need big updates between versions.
I see the API also includes dependencies to SQLite3. Apparently as a performance optimization (fuzzy search, type/reference caching).
I wasn’t aware it’s still IMGUI based. It must be a nightmare to work on the UI side of it.
Wow, never get fooled by the looks of something. It could still be technical nightmare underneath.
They also had their own Monobehaviour based visual scripting announced, which was some months later dropped for DOTS/Entities version at the height of ECS hype, but that too sinked together with a full ECS runtime when they opted to go for a hybrid system.
Then they purchased Bolt/Bolt 2 in 2020 with the initial idea of integrating Bolt 2 as the new Visual Scripting standard in Unity, but it was still in alpha state at the time of acquisition. It did have a lot of things current UVS does not posses - strong typing, proper refactoring tooling, graph search and near native performance in builds thanks to C# generated code from graphs. Unity released one or two betas of Bolt 2 but then decided to abandon it too for whatever reasons. I guess it was too opinionated in visual scripting centric workflows and a lot more complex than Bolt 1.
So they cancelled Bolt 2 and implemented Bolt 1, which had stopped development in 2018. They migrated namespaces from Ludiq (the original developer) to Unity, implemented a very rudimentary Input System package support and later added sticky notes for graphs. Some minor performance optimizations for the editor too but that’s about it. UVS is still effectively Bolt 1 from 2018 technologically and functionally.
Yeap, that FullSerializer. It was the standard at the time. FlowCanvas/NodeCanvas also use FullSerializer with the major difference being that the dev of those tools forked FullSerializer and fixed its bugs himself. It’s something that the Bolt dev didn’t bother with since he was switching to Odin Serializer for Bolt 2 and also something Unity didn’t bother with since it’s not their technology. So it’s still 100% working 95% of the time.
I haven’t looked myself but I presume IMGUI is tighly coupled with a lot of other systems so a migration to Graph Toolkit would involve a lot more than simply swapping graph rendering. Bolt 1 was the first commercial asset from a kid in Montreal. He’s very talented, but some of those decisions from a decade or more ago just aren’t really compatible with modern Unity. And Unity completely dropped the ball with providing a competent Visual Scripting solution in Unity.
Oh? In my mind Visual Scripting was always BOLT all along. I didn’t remember Unity was set out to do their own. I do recall Bolt v2 being rather new and then never appearing in the store as Unity took over its development. The developer did join Unity, correct? Ludiq as publisher is entirely gone from the store.
Unity at the time was too hopeful to push their DOTS solution even to designers. And then they did the most sensible thing without losing face: polish up the original Bolt.
Godot repeate a similar mistake. 0.5% adoption, wow.
Both fall far short of Blueprints due to lack of high-level nodes. The whole idea of “visual” scripting when it requires users to replicate actual code 1:1 is just so absurd. You only need to consider the screen real estate and the amount of clicking, dragging, scrolling to realize that it’s an experience that’s far more time-consuming than actual scripting.
Even Blueprints has a sharp cliff beyond which it becomes terribly inefficient, and that’s not even considering its binary-only nature where teams require discipline: one developer per graph.
I still can’t shake that Twitch stream I was watching for an hour in absolute disbelief how someone created the foundation for an Inventory item tooltip formatting blueprint - you know the Diablo item stats kind. This blueprint wasn’t even functional, just making all the connections and spending a painful amount of time layouting upwards of 200 nodes! 
Why do developers put up with that? Without even realizing that this is borderline insane?
FWIW that graph did look beautiful, like the sort of technical drawing you’d have in a futuristic spaceship console. But that would have taken half an hour to have it fully functional if it had been actual code.
Nah, he stayed independent and never joined but was at Unity offices to walk them through Bolt 2 architecture for a couple of months. Shortly before the acquisition he released Peek, a fullscreen authoring editor tool but that too was soon deprecated. Then he went to make a niche indie game with Unity acquisition and asset money funding his small studio.
He also released some interesting FOSS packages like GameObject Entity System - inspired by ECS but less restrictive and for the current Unity runtime, but that has since long been taken private.
I think he’s at some more established game studio now and doesn’t release anything publicly anymore so that’s the end of it.
Yeah, I think this is part of the reason why Visual Scripting is getting deprioritized - no one in studios needs a poorly performing reflection based general use tool that’s slower to use than traditional coding. High level nodes were on their roadmap for many years but didn’t land like all their other efforts.
Graph-Toolkit approach with custom per project scripting backends studios can tailor to their projects is a better approach at this point in time. That’s where all their visual scripting related resources are currently invested in too.
I was a Visual Scripting only developer as well ages ago. I think it’s related to how some people process information primarily visually. I couldn’t pick up coding in text form at all - it didn’t make any sense no matter how many times I tried.
Then Bolt 1 came around, and it just all clicked. The visual debugging especially was enlightening. C# scripts are black boxes unless you spam Debug.Log everywhere and then map those logs to some understanding of how the script is structured in your mind.
Visual scripting shows how code flows in real time all visualized. You see incorrectly configured nodes turn red, you see when Update, Custom Event, Awake/Start flows execute with animated node edges and node outlines, etc. It abstracts away the more esoteric concepts of programming like namespaces, inheritance, classes and just lets you get to creating logic flows from the get go. It’s an incredible learning tool and the marketing tricks you into thinking it’s not actually coding, which helps with learning it even more.
When people pick up these tools even in advanced use cases, many still don’t think they’ve learned how to code. And in some cases this is partly true, Blueprints doesn’t map 1:1 with C++ for example. But any Unity Visual Scripting users already are doing coding even if they don’t realize it. I think there’s a strong attachment to visual first workflows and the idea of “not coding” because they couldn’t pick it up in text form. But the distance between a UVS veteran and a C# coder in Unity is pretty narrow. I could pretty easily transfer to traditional code once I hit the limits of Visual Scripting package.
Feels also like the call for real blueprint-style coding is being pinched out from the bottom and from the top.
From the lower end, editor tooling (broadly, not speaking of any specific system) is getting better and better for defining the basics of something visually, such as UI or variables or whatever “data thing” you need to define. More and more you can just make stuff with some light middleware.
And then from the top, chatbot-driven tools are able to hold a new engineer’s hands hopefully long enough that they can get past the frustrations of learning an API and start to do meaningful things in code.
As the years of observing chatbot usage pile up, it is clear to me that they are just a software toool, an incredibly flexible and complex tool, one that can get you to the moon or simply explode and take out your entire project and you along with it. The difference in outcomes comes solely from the human user who is guiding the agents, and their diligence and effort. Working at a large AAA studio, some of the crazy multi-day chatbot projects I see my fellow engineers pull off are incredible, allowing them to test, prove and implement project-wide improvements that in the past would have been tedious and laborious to even contemplate, let alone execute successfully. But their success / failure almost always hinges on the choices made by the human, NOT the chatbot.
I’m just not sure where a visual scripting solution fits between these two extremes: generic middleware making more-useful objects and chatbots able to tell you how to write code and actually use those objects in meaningful ways.
We live in interesting times!
You also forgot the other thing that makes it a dead-end. Versioning.
If it’s stored in binary. You’red f’ed.
If it’s stored in text. Well, you’re not totally f’ed but you are still completely f’ed. Diffing that kind of thing during a merge conflict is just about the least productive thing you can spend your day doing.
It’s JSON for Unity VS graphs so you’re not totally effed, but merges are still a major pain.
The exact and only reason I was fascinated by visual scripting but never seriously invested in.
Technically a visual diff tool would solve that!
Would also be very helpful for scenes and prefabs which suffer thebsame fundamental problem that their storage format is way different from how you normally configure those things.
But that would reguire a tight integration with versioning in the engine and the development of such tools…
Don’t see much future in visual scripting for main Unity either.
Except.. well.. some people at Unity Technologies or maybe a hired 3rd party company has developed a whole new visual scripting language called “Logic”.
It’s for their industry-aimed, web based version of the editor called “Unity Studio”.
See #7 here for the language: Introduction to Unity Studio - Unity Learn
That whole thing is separate from the main editor though.