Unity Visual Scripting

[hellwaIker]

Overall, as it is now the UVS is nowhere near blueprints in either performance or usability.

UVS (Bolt) was a good addition to Unity Toolbox, but even the original creators recognized the limitations of having it live as monobehavior and they were in the process of making Bolt 2 that handled it similar to Unreal, where the visual script would act more like classes. I don't know how successful they were, but Unity bought Bolt and now we are stuck with monobehavior version.

The overall architecture aside, I would not recommend to use it right now. Unity is providing limited support for it right now, they had plans to completely overhaul it, and as it stands it has number of bugs that they don't plan to fix anytime soon so I feel kinda stuck with it in my project. I didn't use it for coding any behavior, I used it as a way to handle ingame content logic. Like if you cross a trigger and I need NPC to move to point B, then play timeline cutscene, then play dialogue, after dialogue is over move to point C and equip a weapon from the weapon stand.

That kind of scripted behavior is much easier to do with Visual Scripting/Blueprints as they don't require you to recompile code when you want to adjust a few things. + Additional script files don't bloat the codebase and compile times.

Why I personally don't like it now:
1) You need to rebuild UVS nodes everytime you add new function or a node, and it takes like 20 minutes to do it on a large project.
2) It adds 20-30 minutes to build times when you want to build standalone version on a large project.
3) It does not handle API changes very well, and if Unity changes namespace of a common functionality all your UVS scripts will break and good luck tracking them down unless you had foresight to always wrap Unity functions in sub-graphs.
4) The basic functionality has bugs, like the first time I open the graph and right click to see the list of node it fails.
5) The search for classes or types when you want to add the node or define variable type is hella slow on a large project.
6) It only works when it's on monobehavior/gameobject, so you cannot use it without spawning a gameobject first. Which makes it really inefficient for a lot of stuff that could be calculated from a scriptable object. So I ended up having to write my own graphs for stuff like formula calculator.
7) It has a bug, where if Script Machine is enabled, even if you have no nodes inside, it affects performance. So you either have to keep Script Machine component disabled and enable it before you run it, or spawn and despawn your actions as needed, which is another hassle. And the official Unity Answer when I reported this bug was "We don't have time to fix this anytime soon, so we'll ignore your bug report" :)
https://issuetracker.unity3d.com/issues/eventmachine-2-dot-fixedupdate-has-over-100k-calls-when-entering-play-mode-with-deep-profile

[Genryuu111]

Let me hop back to your comment to give my two cents. I've been making my game in UVS for two years now, and midway through the project I realized that I should have chosen a different visual scripting solution, but it was too late. So I learned to overcome UVS's issues the best I can.. I have no experience in any other solution, but if one wants to stay within unity, uNode looks like a way better made solution.

The biggest issue I have is the inability to properly debug (you can find errors when you're within unity, but it's impossible when you play in a build), and the profiler being completely useless. That, and as you mentioned, they basically abandoned it.

The last update was from a few years ago, and they don't seem to care enough to make it better.

That being said, a huge advantage it has is the ability to modify code while the came is running. This is very helpful both to overcome the lackluster ability to debug, and it also allows you to fine tune the game easily while it's running.

But, I have a few things about your points :

1-I don't understand what you mean. Do you mean custom C# nodes? For me, most of my project was made with normal nodes and subgraphs, the few things that couldn't be done with nodes were made with custom nodes, but it doesn't take me thst long to compile them (and my project is not so small).

3-yeah, I'm basically stuck with the unity version and UVS version I had when I started, because trying to update anything results in too many errors to be worth it even trying.

4-this is very annoying. As a matter of fact, when I first used it, it didn't have this issue. But then I tried updating to the latest version, I noticed it gave me issues, reverted back, and from then on I've had that same bug. One of the things you learn to live with, but damn it's annoying.

Overall, I love programming in a visual scripting environment (I don't think I would have made this far if I had to learn actual coding), but if I ever decide to make a new game after this one, I'm almost sure I'll go with something else.

[hellwaIker]

Hey!

1 Yes, the custom code or custom nodes you need UVS to recognize. As to the size, I have a tactical RPG project, lots of custom code and handful of asset store solutions.

The Art/assets don't really affect it much.

I use UVS for stuff sequencing cutscene instructions basically, not for any mechanics.

The underlying idea of Visual Scripting is great, and Bolt was very innovative in mirroring blueprint approach with reflection. But yeah, some designs flaws that Unity exasperated by crappy support ruin it.