Not to pick on Visual Scripting... But here's my 'two cents'...

Unity Engine
, ,
1

I understand from a performance perspective, Visual Scripting still has some kinks to work out…

Instead, this thread is about how much Visual Scripting can actually provide more value than writing C# code.

I am open to being convinced otherwise, but until that point, I am seriously considering reverting back to just writing code again…

So far, it really just seems like Visual Scripting is for ‘not’ having to learn to code… I was initially sold on the idea that Visual Scripting could help deal with Dependency visualization and re-factoring…

I’ve discovered, however, that each re-compile of a custom node not only requires re-compilation out of the code editor, but I also have to Regenerate the nodes each time I add ore remove nodes. This Regeneration often hangs up, a much longer process than just changing some code per usual…

As for Dependency visualization, I haven’t figured out if this actually helps or not. With proper diligence, coding strategies can be used to deal with dependencies in a more tidy manner… Either way, the compiling issue above is enough to make re-factoring a severe pain in the ‘A’.

There are a few strengths with VSG here and there, but so far it kind of just seems like a crutch for not having to learn to code and/or get good at developing effective coding systems. I am disappointed, I really went into it hoping to find more leverage out of it.

I am curious to hear your thoughts, feelings, and suggestions!

1 Like
2

To each his/her own. Not learning to code is big part of it. Some of us have no intention of ever learning to code. It’s not a crutch, it’s not being interested in learning to write lines of text. Simply don’t care to do it. If I need a programmer at some point, I can hire one. I don’t need to learn Spanish to go to a Mexican restaurant.

Different personalities have different needs/wants and value to one person may not be a value to others.

I don’t run in to the problem of recompiling because I use zero scripts beyond SyncVars and those don’t require recompiling to show up in VS.

There’s a lot of misunderstanding about VS everywhere it seems. Even at Unity. It’s not for everyone. Same as C# isn’t for everyone. It’s really a personality based thing. Do you want structure or do you want chaos. That’s really the choice you are making.

I made this script and it took me about 2 hours. It uses FishNet and SQLite to allow players/NPCs to change any tile in the world based on rules for their object and then propagate the changes to every player on the network.

Could I do this in C#? Sure, if I wanted to learn C#. Do I want to? Nope.

8380548--1105029--upload_2022-8-22_6-12-30.png
8380548--1105029--upload_2022-8-22_6-12-30.png1918×842 201 KB

The newer version (if it’s still being worked on) is supposed to address a lot of the issues and performance. But, we will see how that plays out in 2029 when it’s finally released. :smile:

2 Likes
3

I’ve always been interested in a visual version of coding. I’ve always observed with code, that everything is literally a text editor and no different from 1980s apart from all the magic around intelli-sense, colour-coding (a visual concept). Somehow I imagined it might be possible one day to make coding both visual and textual.

When Unity acquired Bolt, I was full of enthusiasm, it gave me some inspiration. I was pretty new to the node concept, although didn’t take me long to discover how slow it is, if you wanted to use it for anything more complex than simple. I like messing with algorithms, which are best done in code anyway. But it is nice to jig up algorithms, which is more fun in a visual way than using comments in code and recompiling.

What I did find though, is it helped me discover code in ways that visual studio and intellisense cannot, because, being a reflected environment makes it very malleable in changing things up and seeing what works. Also shows things which might be hidden from the coder, since it reflects everything. Change things up in code, and you have a 10 second wait to see what your change does. Zero of this in the UVS concept. Very useful for that.

As for users who don’t want to code, I think that they end up having to discover things as a coder does, and then try and get the nodes (a slow process of adding each one imo). No groups you can save and reload, eg. a URP group. Also lack of content for them to use. This could easily be a pack of simple custom addons to make a game, but doesn’t really exist. Bolt Addons Community added some functionality that was missing. But still not enough content for users to get stuck in I don’t think.

Also the main convenience of code is portability, cut and paste. One of my first projects was making this possible although like most things didn’t get to finishing. But was hoping to be able to share using compressed text (those jsons are massive), or a simple image (64 x 64 x rgba can store alot of info). So, that would have been nice because in visual script world, sharing is almost impossible, easily that is. I can’t post a graph on this page and you open it up. Did make it easy enough to cut and paste from project to project, Bolt to UVS. I got carried away on a tangent of encoding though (down to about 5% compression on massive graphs).

Was looking forward to high performance interpreter, it was incredibly good, and clean programming, very inspiring. But my guess is there were some issues down the line with it (maybe). High performance always brings issues with it. And when you have DOTS, burst, etc also in production, sure things can get a bit messy. As well as NET6 changing everything again. I think current focus is DOTS at Unity.

I only really built to IL2CPP, but that seems to be where the issues lie with UVS, where as in code, after some headaches you can get it to work. Probably fixable, but not without Unity on the case, which I’m not sure is happening atm.

Still ghost the forum, and discord, waiting for inspiration, because I want to get back into it. I loved how customizable it was really. Why not have some complex nodes that do all the programmer stuff, or connect the UnityEngine framework for people to use (not just have 10 words in a line of code you have to manually create in nodes).

Auto-node creation from code would be nice, and possible. Refactoring people always wanted, also possible. I had many thoughts on everything I wanted to create, but never got around to finishing. But hope to get into it again. Still waiting for inspiration.

1 Like
4

No, not to each their own… The purpose of my post was for identifying a better way of doing things… Not just doing whatever you feel like.

If you two hour graph can be done in five minutes in a script, for instance… That is a huge difference.

5

As a follow-up to my post. I will admit that Visual Scripting is growing on me just a bit…

The main reason for this is the fact that, for some reason, I don’t re-factor well when I write C# code. For some reason however, I find it much easier to re-factor within Visual Scripting. I don’t manage to talk myself out of it for whatever reason.

Second, the Blackboard variables are very convenient. It is like having a global variable pool without needing a system to pass them around. This, combined with the above reasoning, make Visual Scripting feel a lot smoother once you figure out how to wield the Nodes.

Third, a lot of type rigidity is worked out of the Visual Scripting process with how port conversions work. There is intelligent filtering on what goes in and out of Nodes, which can filter an object down to the type requested. Also, being able to de-couple and re-couple connections using the Node connectors is simply cleaner than building functions that get passed into and have to be re-factored due to changes in the type names…

Fourth, the Visual Scripting Graph actually has a solid State management setup using State Machines and Script States. One of the harder parts of managing an Event System is keeping in mind everything using the event callbacks… This is just visualized using the State layer of the Graph, and is excellent for defining high-level behavior-flow without having to define any logic.

Overall, I may have jumped the gun on dissing Visual Scripting… As long as it runs efficiently, and the UX isn’t a pain to use, Visual Scripting actually has a lot to offer…

6

Personally, if unity did not have Visual Scripting, I’d be looking elsewhere for one that did.

The Node based system reminds me a lot of a modular synthesizer and leads to more experimental moments in the same way. But just like for synths, you need to know what an LFO or an ADSR Envelope does before you can apply musical rules to make it sound appealing to our ears and style sensibly.

Not to mention how it’s much harder to screw up. You don’t have to declare using.whatever or even stick to standard code format. And don’t forget, you can edit the graph during runtime! so it’s almost like hooking an oscilloscope up. You can change values and see the result in real time.

But personally, I’m past the point that I need to make random demos to test ideas. Because of Visual Scripting.
It allowed me to fail faster and learn because of how it works when you use it. Feels more like a game and less like I’m typing out a report.

Once you understand the nodes by using them you can easily read code too. That’s kinda cool.
I don’t want to say code is outdated, but it would suck trying to type in a VR environment compared to how cool the nodes would be ^.^

7

The better way is for people to learn how to use the tool correctly. Unity does a poor job explaining to people how to use the tool and in their documentation they tell you there are very few uses for the most important and performant node, the while loop. ¯_(ツ)_/¯ Handicapping people from the start by pushing people toward updates that cripple the game over time leading to bad performance and a general feeling that VS isn’t any good.

I don’t care about the time difference to make something. If I can’t remember the syntax for the code immediately after writing it. It’s totally irrelevant if the script took less time because I can’t fix/modify it without relearning what I just did.

To each their own because people have different uses/needs cases. I can remember a database of leasehold for an oil and gas company that has 380K rows and tell you what’s right and wrong, but I can’t remember simple things like how to write a SQL update query without looking it up every time. Different use case for VS than a programmer.

8

to clarify, you want to see more examples of how the while node works?

9

No, the language needs to be changed to recommend using the while loops for just about every process that doesn’t involve physics. The example below is how I have every graph set up. Simply add in the time you want for the speed and add/or a time delta time if you want to mirror update speed. When a client is done building, the flow stops and there’s no performance impact. Running what only needs to be run allows you do run far more processes without running in to performance problems.

The warning about the infinite loop is good. The only way to create an infinite loop in this graph is by accidentally disconnecting the body from the wait for seconds. Once you do it a few times, you will learn not to do it. heh.

8471054--1125680--upload_2022-9-27_19-41-49.png

I’m making a MMO game using only VS, Fish Networking, and A* Project. Without the while loop, it wouldn’t be possible to run hundreds of test clients with a reasonable FPS under 16ms. Each update on each player has a compounding effect even if they aren’t doing anything. Cooldowns also cause problems. So, it’s best to work around those.

10

understood.
efficiency with the while compared to update.

that is not really a visual scripting issue more of a general programming issue but interesting

11

No. I very much disagree with that analysis. You can have structure in visual scripts and chaos in C#. This is in my opinion one of the most common mistakes people (especially those who prefer writing code) make about visual scripting. They assume it’s only capable of chaos but you can write elegant visual scripts if you chose to do so.

1 Like
12

A large part of the chaos comes from the node sizes. Good example is the get vectors. The nodes should be tiny little pass through nodes. No pictures, no words. Just an X, Y, Z, etc. So much space is used up by these massive nodes that it becomes a real mess when looking at larger graphs.

8476145--1126622--upload_2022-9-29_6-39-21.png

It can be well organized for sure. The state machines are pretty good about keeping things looking nice.

8476145--1126631--upload_2022-9-29_6-50-15.png

This script is stuck outside of the state machines for networking reasons. So, it’s as elegant as it’s going to get for now. But, it’s still easily readable from a logic standpoint. I like the this layout of the nodes, just not the size.
8476145--1126634--upload_2022-9-29_7-0-2.png

Hopefully the new Unity version of the UX is better.

13

I’m wondering why you need to put the graph out of a state graph? At least, to see if it is a bug or a feature missing.

For the size of the nodes, with GraphToolFoundation, we will get the same thing as shader graph like node collapsing.
8476751--1126742--upload_2022-9-29_10-17-56.png8476751--1126745--upload_2022-9-29_10-18-17.png

You can also use the subgraphs, to shrink size of graphs, but it may become harder to work with those nodes with the variables handling and also the exposed ports mechanic that won’t help much in those graphs readability.

2 Likes
14

Readability of graphs will really tank if icons are taken away completely. It might be fine for Shader Graph since the use case is very specific, but for a general purpose tool that covers literally all aspects of Unity, icons are key to graph readability. Fingers crossed that’s not the case whenever GTF update for UVS drops.

Not sure if manually collapsing stuff is that useful but I’m looking forward to extra functionality.

2 Likes
15

I look forward to the new UX and whatever performance increases are eventually coming. Going to be fantastic. I can do everything I want to do right now with pretty good performance, but having the Unity updated version is going to rock.

The graph being outside of a state machine isn’t a bug or lack of functionality. It’s a logic issue mostly. With all the RPC calls and database queries it made it 10x more difficult to have it in the state machine. It links back to multiple graphs for various conditions using sync vars that run other functions. It’s a big web and it’s going to be confusing either way. So, the single graph was the simplest way to get it done.

I have a few subgraphs for repeated functions. If it’s something I will use everywhere, I create a script file as the subgraph so when I modify the script they all change. I don’t think I have any one-off subgraphs in the project. I don’t like the idea of grouping things just to group them. heh.

16

Ideally, users would be able to apply a custom color to nodes as a global setting in preferences. Add the node to a list and set a color while the others default to a default color. For myself, there are some nodes that are very important to know they are there. Input nodes, while loops, custom events, debugs, etc. 90% of the others could stay a single color as they are just helpers that don’t really matter to the general structure of the flow. In almost every case, I am looking for something specific and have to cut through all the other noise of the nodes to get there.

17

While it sounds like a nice feature to have, I’d prefer a universal standard that’s readable by default. If every company, indie team and youtube tutorial creator have their own color scheme for the same concepts, it becomes a bit of a mess.

And colorable node groups and notes will be included in the next version of UVS. You can color node groups in current UVS versions as well. And events are already green. I concur that being able to manually color things is a good thing, but perhaps not the default nodes themselves which should be standardized. And custom nodes should be colorable, of course, they already are.

18

I have made multiple attempts at learning to program over the years. There’s some point in my brain where it just cant process how the words all come together. Combine this with having a passion for game design and mechanics and naturally I have had my eyes on a lot of this kind of stuff (visual scripting). From Kodu to other in-game editors, I usually am so much more limited in what can be achieved than in Unity (I’ve also worked in Unreal Blueprints). I see the value of this as completely unquestionable. I’ve seen plenty of people say “Just learn to code!” as if visual scripting isn’t here to stay or can serve no purpose. In the end, regardless of what becomes of anything I do, I’m having a blast and learning a lot along the way. The fulfillment I can achieve is exhilarating to say the least, so I’m thankful for the node system and visual scripting.

4 Likes
19

That would be great!

I would suggest things like trying to align edges via the button but that’s kind of clumsy for quick setup.
All of the nodes are not the same shape, size or has the i/o in the same location. hard to align all.
Snap to grid makes it even more messy. it aligns the node edges but the wires are all bent.

The collapse would make each node the same size so easy to organize. and it’s a feature that would be familiar.

I know what you mean about the Get XYZ…
Here’s the 3 ways I normally do it to keep it looking better…

8478485--1127048--Capture.PNG
8478485--1127048--Capture.PNG413×682 23.9 KB

8478485--1127051--Capture1.PNG 8478485--1127054--Capture2.PNG

20

Readable code uses comments, readable graphs uses comments. Ideally zooming out turns into a pseudo code form of processes rather having to subgraph to comment, although i get that. But less is more, less levels. Groups do look nice though, easy and straightforward. Less is also more size wise, hope the new framework will be super flexible for customising/drawing your own nodes.