So I read somewhere that VS could be used to create custom nodes then used in conjunction with regular scripts to speed up prototyping in some areas using the custom nodes. I tried VS in 2021 out for around 5-10 hours, I absolutely hated it personally. Most of my frustration came from naming conventions that slowed me down tremendously even with doing extremely simple actions that I could’ve coded in seconds. I’m almost positive its a me problem, and not the VS. Its a slightly different way of thinking than I am used to.
I know UnrealEngine is created in a way that blueprints accentuate the developer’s c++ and its actively promoted to use both together in a supportive way.
-Is Unity’s the same way?
-Is it on track to being that way? A
-Am I missing out if I completely skip it and stick with pure c#?
-Are there any benefits at this moment to really learning Unity’s VS for developing games? Or is it too buggy or big of a hassle?
Not yet, UVS is still Bolt 1 at its core. And Bolt 1 was marketed towards complete Unity/coding beginners and never really played nice with C#.
The main method of interfacing with C# was via reflection using the Unit Options Wizard, which is now located in Project Settings/Visual Scripting. Bolt/Unity VS can access any public method, field/property, or struct via reflection and automatically generate nodes for them.
This, however, has its limitations as there’s no support for C# events or callbacks, and it can’t deal with generics at all. And if a method signature changes, all instances of that reflected node break in graphs with no tools for refactoring or even finding the broken graphs as clicking warnings/errors in console do nothing. On top of that, adding a new type requires you to regenerate the whole node library, which is costly time wise. This does not scale even for small, solo productions.
UVS also adds a lot of overhead for domain reload, enter play mode time, severe loading time and build size increase on AOT platforms like WebGL and mobile, etc.
So, no, UVS as it is currently, is not made to play nice with C#. The API wasn’t even documented until Unity acquired the asset; it was considered unstable.
It’s on track, but it’ll take a few years to sort all the above issues out. They have a new runtime currently in pre-alpha that replaces the reflection runtime with a per node C# gen for much better performance on target platforms.
This new runtime has a completely new, undocumented API. So if you’re writing any custom nodes based on current API, all of that will need a rewrite once the new runtime releases proper sometime in 2022 (hopefully).
They’re also planning to replace all the UI frontend so any custom drawers written now will also need to be rewritten. A replacement of the now defunct FullSerializer tech with the native Unity serializer is also in the plans.
Basically, all that makes up UVS now is in the process of being completely replaced with something better. So eventually it’ll play nice with C#, it just doesn’t right now.
The asset was acquired in May last year. They spent the rest of 2020 integrating the asset as a core package of the engine. And after a year of development in 2021, nothing much has changed. The new runtime will be a major step forward, but it’s nowhere near production ready.
I don’t expect much to change in 2022 besides perhaps the new runtime becoming semi-stable and they might drop some of their promised high level nodes based on the new runtime.
You aren’t missing a thing. Stick to pure C# if you want to keep your sanity and maybe explore other options like Flow/Node Canvas, which are proven in production and have a very clean API and proper refactoring tools. They also add new types in like a second, support generics, C# events/callbacks. They basically do all that UVS should do right now.
The only benefit is for complete Unity beginners, as Bolt/UVS is great at reducing the initial complexity of approaching coding. And maybe for prototyping since you can iterate on the code in Play mode and immedietly see any changes made and test them without the having to ever exit Play mode and recompile.
For actual productions, current UVS is a poorly tooled trap - hard to debug, hard to refactor, hard to maintain, can’t diff, can’t code check, adds tons of overhead both in builds and and the editor, doesn’t support sandboxing so you can’t expose only your custom nodes to designers. And everything about the tool is in the process of major, fundamental change so while Unity always are focusing on backwards compatibility, it’s not really a guarantee, especially for custom nodes since the API is changing.
It’ll be great once the new runtime gets stable and it’s API documented, the UI is replaced and unified across all Unity graph based tools, the outdated/buggy serializer is swapped out, etc. But at the current pace that’s years away.
For what it’s worth, I’m currently teaching a 2nd year University class in Unity to a group of students who already know C#. Nonetheless, I still think it’s easier to introduce the concepts of Unity through Visual Scripting. Aspects of design and good practice as well as thinking differently about how code is written and executed means that they have to refactor their other programming paradigms.
UVS is a syntax-free route in to this world but this only lasts for a few weeks until I bring them into the world of C# and Monobehaviour. I’m a big fan of democratising programming and so have advocated Scratch and Snap! to younger students. I just wish that UVS was more mature.
Still, there is an awful lot you can do with UVS. I’ve done it myself and seen others do it. It’s terrific but flawed.
Thank you both for your responses. I personally think because I already know c# I definitely view unity’s VS as subpar in many respects in comparison to straight code.
The main advantage of the Visual Scripting environment, is zero compile times. So even if working on some code aspect, you can prototype it in UVS, then write it back to code. Those tiny changes in code that incur reloading, they are not fun. UVS takes this away.
So from a teaching perspective on node/object-oriented programming, this also makes it more fun. At least for a basic understanding of how code works.
Main missing part for me, is that in C# I use a lot of arrays, but due to limitations in the reflected concept of UVS, this is not easily available in the same way, and is also slower (you use array for pure performance, reflecting them defeats the object!) But I hope to get around this at some point (always messing around with things, but currently focused on the new interpreter in 1.8)
Also, while the new interpreter is not documented, it’s is 10x more logical and easy to understand. It’s been easy making new nodes for me. But the current state of 1.8pre is that it has a lot to fix, including not currently IL2CPP buildable, it is more a pre-prerelease. But, for what does work, it is functional.
In a way, because the Interpreter fixes the extra lag on reflected nodes coming from code (rather than UVS built nodes), this means very much that simply using your code in the environment will work as it should, rather than being something to avoid.