Visual Scripting in 2019.2

Is visual scripting still cumming in 2019.2 as a preview? On the roadmap it is still listed under research.

 

https://forum.unity.com/threads/uni...cripting-in-2019-2.577084/page-2#post-4146832

 

Yeah, it's dead for regular MonoBehaviour workflow now. ECS only. You can make your thoughts known at the link, but I doubt they'll change their mind.

 

At this point I just don't care any more, if they think that further development is needed that is cool, but as someone like me who can't write code to save his life and is desperately waiting for visual scripting system, I will not be waiting on unity team any more. I don't like the idea that to make unity useful for someone that is not coder, you have to spend money on asset store to boiler plate 3rd party solutions to core unity engine and hope to get functionality that you need.

 

You need to write code to make a games. Visual scripting is just a nice addition, so you don’t have to write a script for every sneeze, but everyone thinks it is a panacea, and misused it.

 

I can't write shader code, but with visual shader editor I can make interesting materials. Materials that do exactly what I need them to. I look at visuals scripting the same way, I don't need this system to move mountains for me, I am not working on a next anthem game.

 

This is a reasonable point.
And if that is really what someone would use a VS solution for, then they'll most likely be fine.

Shaders are already pretty complicated (complicated enough that no visual shader editor fully supports everything you could write by hand).
However general programming is even more complicated than shaders.

Anyway, most people will probably be fine (those who know how much they can expect from visual scripting).
But some will be in for a pretty rude awakening in a few months or years down the line... (just an observation I've made many times)

 

You can learn how to code faster, than you will sit and wait for years what is not clear. Believe me. I'm an artist.

 

I have been thinking why graph feels like the right interface for shader design, but not always for scripting. Scripting is usually waterfall-y, where it flows from top to bottom. If you consider a line of code as a node in a graph with 2 connectors to previous and next line then code editor is the best "visual" tool for scripting. (Even though you may not think letters are "visual")

Graph are at its best when you need to dissect and combine often which is the case in creative shader design. In the code at best I had such pattern where 2+`public` methods joins into a common `internal` method. But they rarely split apart again unlike shaders. Graph applied to scripting is underutilizing good characteristic of graphs.

Also in coding I rarely try to "mix and match and see what comes up" which is what visual tools are good at. Many times while I am making a post process graph in 3D software I found something good by accident thanks to visual graph.

 

You've made some good points, I agree with pretty much all of them.

I think I can offer an additional viewpoint on this that might be helpful since the personal project I'm working on also has a heavy focus on modding/customization. I thought about all of this visual scripting stuff a lot.

In my experience a node-based visual scripting will never work well!

Now before the visual-scripting-fans reading this grab their pitchforks, please let me clarify some things: I'm actually on your side, I too want to make it easier for non-programmers to somehow "implement code". The only thing I actually disagree with is the node-based in "node based visual scripting".

Now the fundamental reason for why node-based approaches fail for anything larger than simple examples is essentially that we're mixing data-flow and execution-flow.

The point @5argon made touches on that but I think I can clarify it even more.

So for Shaders the node-approach works fine for the most part. That is because what you are actually encoding in either the shader-code or some visual shader graph is almost exclusively a "data flow".
Shaders (for the most part) describe what buffers, vertices, numbers, ... to take, and how exactly to combine them.
They essentially describe a single big calculation.
You can write stuff like loops in hlsl as well, but the fact that almost no visual-shader-tool has built-in support for that already foreshadows the conclusion I'm about to make...


Now "scripts" that people commonly create in C# there are a few big differences.
First of all what is encoded by a script is much more complicated. Code, Classes, and Objects can interact with each other much more freely.

But the biggest part here is that most functions are not just simple calculations, but they also have "control flow".
"Control flow" is everything that changes what code gets executed depending on some data.
The best example is a simple "if() ... else ..."
And that's where the big issue is: node-based visual scripting tools all (have to) try to somehow encode data-flow and control-flow at the same time.

It's certainly possible as we can see from implementations like Bolt (unity), Blueprints (unreal), and many more...

But they all share this huge issue that functions will extremely quickly turn into a huge mess.
Take a look at any real-world script made using playmaker, bolt, or blueprints. 90% of them are gigantic spaghetti-code monstrosity.
All because they have to represent two things at the same time: control-flow and data-flow.

Initially having "easy to understand" nodes on a canvas looks really attractive, but as soon as you have two ifs and a loop in there it already becomes really confusing.
You *can* mitigate those issues with for example some strict rules about layout, limiting how many control-flow-elements can be used at most inside a single function, etc... but in the end there's no winning. Visual nodes are just not a good tool for this and will always naturally tend towards producing a mess.


Now I think that there are most likely ways to make a good, (reasonably) easy to understand, visual script editor.
But so far nobody has made one that comes close to what you can do with a good IDE (like Visual Studio).

 

You make some good points but you are forgetting that the paradigm has completely shifted.

Would your points and arguments still be valid in a ECS node based system?

Instead of functions we would be dealing with Data Oriented Designs and Entities, Components, and Systems! The logic and data flow for that is a totally new animal!

 

I think ECS is even further away from attributes of a graph. MonoBehaviour works more like a graph when we expose fields and interconnect them in the editor so they know each other (rigidly). I can imagine the new visual scripting tool leaning nicely to that workflow.

On the other hand any ECS System is allowed to take a slice (an archetype) of anything from one big central database, and one of the core design of ECS is that each System is working in isolation on their own but indirectly communicating through data they modified and execution order. If system ordering is this-then-that I think a graph might be useful but ECS system should not hard specify order, but better in terms of specifying run condition. ("Any time after X system runs", or even better with good programming that make it works on any state of the current data.)

They are not really connected directly. I am not sure what that would look like in graph representation. Maybe tons of lines spawning from one central node showing which system is using what? The current Entity Debugger may give you a hint why graph may not be the best for ECS. I think it is quite nice the way it is (lists data and not from-to relationship)

 

I could be totally wrong but Unity may already be giving us hints at how a visual node based ECS/Hybrid ECS system may work if you look at how the logic in the new Visual Effects Graph works which runs on the GPU...

Take a look at these links and also the Visual Effects Graph presentation from Unite LA 2018.

https://docs.unity3d.com/Packages/com.unity.visualeffectgraph@5.3/manual/Systems-Contexts-and-Blocks.html

https://blogs.unity3d.com/2018/11/27/creating-explosive-visuals-with-the-visual-effect-graph/

 

oh well. Installing 2019.2 alpha/beta was a waste of time.

 

What did you expect from this? They will distribute visual scripting via package manager when time is come.

 

I know. I'm just being a lame-ass.