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

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!

 

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.



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.

 

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.

 

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.

 

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

 

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

 

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.

 

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

 

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.



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.

 

understood.
efficiency with the while compared to update.

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

 

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.

 

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.





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




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.




Hopefully the new Unity version of the UX is better.

 

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.

 

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.

 

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.

 

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.

 

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.

 

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

 

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.

 

That's not true by today's standards of programming. In fact, some consider comments to be a code smell. Readable code is achieved by naming and structuring things correctly which typically doesn't involve comments since the code explains itself. There are exceptions to the rule but not many.

 

With code that does various complex functions, and may access memory of something defined by some numbers (but what), comments really help. The problem with code is making tidy comments, it's not easy. I personally think you can never have too many comments depending who the audience is. But, given that the coding process is the main part, it's about spending a little time after to organise with some comments which I know is rarely done in the programming community. Algorithms that's another thing though, although a pseudo comment might help.

For example, while trying to understand code for RenderMeshIndirect I commented until I understood. Some ? where I am asking myself to fully understand. I'd love to mess with some voxels, so my idea this could simply be an offset, a cube region/half, and then numbers for each position, changed to a position in memory (if say using a 8x8x8 to fit into 256 as half a cube). But it does help to write comments to develop into things.

Code (CSharp):

1. void InitialiseBuffers()
2. {
3.         // -- Setup Instance Positions --
4.  
5.         // Init array of float3 - positions changed to Matrix4x4 in shader
6.         positionsV3 = new NativeArray<float3>(instances, Allocator.Temp);
7.      
8.         // Test case, random square based on the range size
9.         for (int i = 0; i < instances; i++)
10.         {
11.             float2 pos = new float2(UnityEngine.Random.Range(0, terrainWidth), UnityEngine.Random.Range(0, terrainWidth));
12.             positionsV3[i] = (float3)transform.position + new float3(pos.x, noise.cnoise(pos/10f), pos.y);
13.         }
14.  
15.         // -- Setup PositionsBuffer --
16.  
17.         // Init buffer with the size of positions, each item being 3 * float (convert to matrix on shader less memory)
18.         GB_positionsBuffer = new GraphicsBuffer(GraphicsBuffer.Target.Structured, positionsV3.Length, 3 * sizeof(float));
19.         // Send positions to the PositionsBuffer
20.         GB_positionsBuffer.SetData(positionsV3);
21.        
22.         // Clean up memory
23.         positionsV3.Dispose();
24.        
25.         // -- Setup CommandBuffer --
26.         // -- Initial settings required to access the GPU buffer
27.  
28.         // Initialise CommandBuffer
29.         GB_commandBuffer = new GraphicsBuffer(GraphicsBuffer.Target.IndirectArguments, commandCount, GraphicsBuffer.IndirectDrawIndexedArgs.size);
30.         // Initialise CommandData (indirect arguments/settings that go into CommandBuffer)
31.         GB_commandData = new GraphicsBuffer.IndirectDrawIndexedArgs[commandCount];
32.         // Indexes of submesh 0
33.         GB_commandData[0].indexCountPerInstance = mesh.GetIndexCount(0);
34.         // Initial vertex index in mesh?
35.         GB_commandData[0].baseVertexIndex = 0;
36.         // Difference to above?
37. GB_commandData[0].startIndex = 0;
38.         // This doesn't actually work, would be useful to set an offset. Can only be done in shader currently
39.         //GB_commandData[0].startInstance = (uint)startInstance;
40.         // Set number of instances to show from 0..x
41.         GB_commandData[0].instanceCount = (uint)drawInstances;
42.         // Send CommandData to Command Buffer
43.         GB_commandBuffer.SetData(GB_commandData);
44.      
45.         // -- Setup Render Parameters -- The specific parameters for rendering, including access to shader buffer
46.         // -- Full list https://docs.unity3d.com/2021.2/Documentation/ScriptReference/RenderParams.html
47.  
48.         // Init with a material
49.         renderParams = new RenderParams(material);
50.         // Set receive shadows
51.         renderParams.receiveShadows = true;
52.         // Set shadow casting mode
53.         renderParams.shadowCastingMode = UnityEngine.Rendering.ShadowCastingMode.Off;
54.         // Set bounds of object - bounds are what are seen by the camera when culling. Bounds(centre, corner of 3D bounds). Defaults to object size if unset
55.         //renderParams.worldBounds = new Bounds(startBounds.position, endBounds.position);
56.         // MaterialPropertyBlock so you can access the custom StructuredBuffer in the shader
57.         renderParams.matProps = new MaterialPropertyBlock();
58.         // Send PositionsBuffer to the GPU ShaderBuffer
59.         renderParams.matProps.SetBuffer("_PerInstanceData", GB_positionsBuffer);
60.     }
61.  
62. void Update()
63. {
64.             // Draw the instances
65.             Graphics.RenderMeshIndirect(in renderParams, mesh, GB_commandBuffer);
66. }
67.  

 

Anyway, the one thing missing from all Visual Script ideas that exist, is the ease of access cutting and pasting and sharing, which was actually my first project/hole I noticed with VS.

Code, what do you do, a bit of online cut and paste etc, VS thats a no, files yes but thats inconvenient compared to cut and paste. Maybe I'll go back to that project at some point. Did require some heavy compression on JSON.

 

A picture is worth a thousand words, but yes. user cannot copy paste the graph and use it without understanding it like you can with typed code. I would call that a bonus when learning because it forces you to actually "show your work" and do it. You can just take the graph and share that though via file share the same as a text file.

Would be sweet to copy text code and convert that automatically to nodes.
or some kind of "workshop" for nodes that the community could contribute

 

Well I'm a big dreamer, and was full of enthusiasm when I first got into VS (still am but always off on some tangent of discovery currently delegate* lol). One idea I had was a kind of separate window linking to some server with foldable/searchable categories of stuff, where users can upload their graphs into some category with a screenshot. And then if you are looking for some particular way of doing something you can just copy it straight into your graph (with a copy/paste function yet to exist except in my own project). In a way you could have a user system for everything in Unity, eg. Shadergraph user library. All with cut and paste straight in, no file to download/import. That's what I do like about graphs, working outside the main assembly reload.

For myself, I find the challenge I have whenever I start a new project is maybe I had useful Editor addons here and there - I then have to remember what they were, where they are, just to build the editor setup I try to remember I had. So one project I might work on is a global SSD/hard drive cache to send files to, or to update if there's a newer version (or I modded my own tool to be better). And then within Unity, I will always be linked to this central cache of stuff that I can favourite etc. Maybe this is beyond my skills at this point. I know people use GitHub, but not sure it's the same thing. Package manager/assets, not what I mean either as these are a bulk of files. I kind of mean a 2nd Project window of all my global stuff, or even simply showing every project/assets I have created just listed there so I can grab items, move them to an accessible place (global Project folder), so I know always where it is.

I'll keep dreaming unless I one day create it myself!

 

@ericb_unity Will the nodes be super customisable for making your own nodes? I liked working on my own nodes

 

Oo neat.
I like how the wire sockets are inset into the panel and not floating around on the outside. looks like an audio jack ^.^ Sometimes, those connections glitch out with the current nodes. I hope this also fixes that too!

Feel like folks could easily overlook the little dropdown arrow at first, but once discovered it would be like finding out that you've had an 'alternate fire' the entire time. Recommend .GIF animations in the documentation that show the usage of everything.

I want to click on that cogwheel and see what's in that ^.^

but as for customization: for a while I was hooked on just making subgraphs. Like i'd sit down and try to make the cleanest looking subgraph to so some function that I would reuse a lot. Like this little move node that I threw together as an example.

You can see how easy it would be to return to this project later on and instantly tell what it does. I was hooked on it like a video game itself. and WAY more fun then I've ever had lookin at functions with typed script. This needs to be a thing still.



I was NOT a fan of how you had to enter in the variables and data i/o from the blackboard on the side however. Most of the time i'd forget to hit enter and apply the Key name.. but also.. why not just enter it on the actual node? Just pointing this out as a thing that did not feel intuitive. I STILL forget sometimes that you set the 'Select On' over in the blackboard/ graph inspector lol




I also want to make it 100% clear that the EXPOSE node is awesome. and really helped me see what types of data is expected or sent or could be obtained. Normally you'd have to review documentation about somthin' to figure it out.. but here it's like you can see it AND tap into them. I learned a lot just connecting a Debug Log node to the outputs. one of those little things that compounds on other things to make it fun.

 

Glad to hear. Also, thank you for being available for communication, this is very much appreciated.

I'm not sure if this is covered already but I'd like to dynamically change node's outputs based on its input for both data values and flow control. For a simple example, say I have some data type that defines dialogue choice options which can range from say 1 to 15 different options. So for however many options the input contains, the node would dynamically display an output for each of those dialogue options.

Instead of manually adding new outputs in Graph Inspector like you do for Sequence, Switch, etc nodes, the node itself would automatically configure the outputs based on rules user defines in the custom node. i.e. no input, no output ports or only the default passthrough output port. And output ports dynamically appear based on input.

 

Comments can be helpful but the ones in your example are worthless. A comment shouldn't repeat what the line is already telling you. Instead a comment should tell you why you needed that line if it isn't immediately obvious. If a line isn't obvious and I have to open the docs any comments it had have just failed and should be removed.

I've never worked with the system that your code is interacting with but the only lines that don't immediately have meaning to me are lines 9 through 13. Every other line should have it's comment removed. After all do you really need to know that

renderParams.receiveShadows = true;

means that you're setting "receive shadows"?

 

Point taken however my comments are custom neon green so they overrule the code in english, rather than like you said reading both comments and code. I did literally comment every line i know so a bit overkill!

 

// Reply with comment here and move to the next sentence when period is typed.
I think everyone starts out typin' more comments than code lol [ERROR]

// Continue reply while establishing that it's alright to start off by typing lots of comments;
But it did help to translate from English to code until understanding more.

// Continue yet again and reenforce that it's got a use.
Sometimes it's like a doodle, trying to figure out what you need to do.

But you'll get to a point when it's not really necessary.
Unless working with others on a project, as a team, even more-so.
But if it helps you get to where you're going. hey.. that's what comments are for!

//

 

Well if I can override the GUI/widget I can add things like sliders and textures. One node I got side-tracked on was a kind of tween node, showing the movement type in a graph/texture (not simple 0 to 1 animation curves). As it's Visual Scripting the visual element can also be enhanced to be more visual.

 

Actually I was commenting every line for someone who doesn't understand code, so there is that. I rarely see enough comments in code to show what absolutely everything is doing (yes some things being obvious).