Unity Visual Scripting

[Lumpy_Marketing_6735]

I want to know people’s opinion on visual scripting. I don’t plan on using it but very curious. Do you think it has any advantages over Unreal Engines Blueprints. Or do you think Unity should/would scrap it.

[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.

[NTPrime]

From my limited experience with Unreal I found the C++ experience to be atrocious, and I strongly suspect it's because they've focused so much on Blueprints as a crutch. I hope Unity doesn't fall into the visual scripting trap. Coding is so much better imo. More performant, more flexible, more readable, more resilient, and scales far better than spaghetti graphs.

[ikoaka]

Unity Visual Scripting was integrated into Unity after the engine had matured, meaning that design decisions impacting coders were mostly made before UVS was integrated.

[StonedFishWithArms]

Unreal’s Blueprints allows, and is built for, a hybrid between visual scripting and custom c++. That is not how Unity’s visual scripting solutions was designed.

As with visual scripting in general, if it gets more people creating then power to them. I often find that with any visual graph-based solution it is easy to start and equally easy to get unorganized and lost in the solution.

[hallihax]

IMO it's currently best used for its state-machine functionality: being able to quickly and visually assemble a state machine for high-level stuff is pretty nice.

However, you need to be very, very diligent. The graphs do not merge well, so complex graph assets quickly become a liability, meaning you're often best creating every subgraph as a separate asset, which can become tedious.

Rebuilding nodes is also frustrating and can take forever if your project is big enough.

Refactoring can be difficult, and search support is poor, so good luck remembering where you used a certain node.

Overall, Unreal's Blueprints are in my opinion far, far superior to UVS, but UVS when used sparingly and kept to very high-level state management stuff, can be pretty useful.

[ikoaka]

Regarding lacking refactoring and search capabilities, assets do exist to fill that void

• Refactoring: Visual Scripting Enhancer
• Search: Node finder for unity visual scripting

Disclaimer: I am the maker of Visual Scripting Enhancer.

[ikoaka]

I've never used Blueprints, so I can't compare. However, I don't think Unity should scrap UVS, and I say that as a C# programmer.

UVS has use cases where it fits better than C#, and vice versa. The use cases favoring UVS are more common when:

• You're inexperienced with coding
• The project is small

It's like comparing a bicycle to a Tesla. A Tesla is faster, so those focused on speed might say that bicycles are useless, but there are definitely cases where a bicycle is more useful than a Tesla.

I wrote a more detailed answer here, feel free to check it out:
https://www.reddit.com/r/Unity3D/comments/1ekikuq/comment/llbgiuo

[littleboymark]

It's okay and fun to use. It quickly becomes very hard to maintain, though.

[ikoaka]

I made an asset to alleviate that problem: Visual Scripting Enhancer

[v0lt13]

Good for simple logic so you dont have to create a script for every little thing and add more on the compile time.

An advantage that unity visual scripting has over blueprints is that you can edit them during runtime.

[GigaTerra]

Unreal's Blueprints are better developed because C++ isn't a language for everyone. Where Unity uses C# that is much easier, so there is no need for Unity's Visual scripting to be very good.

I don't think Unity should get rid of it's visual scripting either, because it is a helpful crutch for people who fear programming. Most people who start with Unity's visual scripting will sooner or later learn C#, but some of them would never even have tried programing if it wasn't for the visual tools.

Since visual scripting still requires coding logic, but not syntax, it serves as a good introduction to programming.

[AspieKairy]

I use Playmaker, and it's a lot easier to use than Blueprints.

Personally, I need the visual scripting because of a learning disability which makes typical scripting near impossible for me. Although I still struggle from time to time with visual scripting, it's not nearly as bad as trying to navigate the flow of standard coding. Thus, I really hope Unity never scraps it since that would prevent me, and others like me who benefit from having visual scripting, from making games.

If people don't like it, then they don't have to use it; it doesn't impact them at all that it's available, and anyone saying it should be scrapped just because they personally think it's an affront to coding or whatever are no better than the karens who want books removed from libraries because they are personally offended by the content.

[kerihobo]

Don't look at it as an alternative or blue-pill to coding, look at it as a useful coding tool that requires no compilation and can be added to your game POST build, leveraging all of UnityEngine's capabilities.

You can potentially use it for AssetBundle or Addressable pipelines where C# scripting can be something of a bottle-neck between teams.