Unity3D getting Visual Scripting in 2019.2

If you would look at the source code for windows you gonna feel lost too.

Nice diagrams!

 

As somebody who has spent far too long dealing with other people's spaghetti code, I feel like I could far more easily parse some of those graphs than nightmare code with poorly named functions and variables.

 

While I love analyzing and making fun of bizarrely written code from time to time, the reality is this isn't a problem with the tools as much as it's a problem with the developer. Blueprint is a great example for showing this too as it has the features necessary to make elegant graphs. If the user chooses to use them.

Keep in mind that everything you said applies to code too. I have seen some truly nightmarish code written both by people who had just started learning and by people who had been in the industry for years. Making quality code and graphs is just as much a skill as programming. You don't magically possess it just by choosing a different tool.

 

You could have thrown in some modern wiring diagrams, techniques have improved since then.

 

Sa @Ryiah already duly noted, i hate when someone posts spaghetti FSMs and says "visual scripting is bad". I can post some horrible written code and say "coding sucks", but it doesn't, it's programmers fault, like blueprints from hell are also a display of bad programming practice and laziness, nothing else.

We'll see how it goes with blocks in Unity VS, looks clean and simple, but then again, my spline FSM's also look clean and simple, not like those hellish blueprints.

 

Good point. I will do that, if I wont forget and I will be back on PC.

 

A good tool would not ALLOW the user to make such horrendous spaghetti mistakes. These graphs may look pretty but does a user really need to be able to position boxes "anywhere" and have nice little curvy lines going between them? I think not. It looks at least like Unity's system might be a little bit more 'procedural' looking with lists of actions instead of a horrible mess of tangled wires. I mean who wants to spend development time 'arranging boxes' to try to make the program more readable anyway.

 

So what's Visual Studio's excuse?

 

You can make mess with any tool. Is up to user, how to clean up and present things.

 

I mean who wants to spend development time formatting and refactoring terrible code, to try to make the program more readable anyway.


So as you can see, you can literally say the same thing about written code, I for one have been handed some seriously messy crap in the past that I would always have taken a visual version over any day.

 

One thing I would love added to shader graph is an untangle button. The same thing could be useful in a visual scripting system. It would go a long way to reducing spaghetti.

The more I work with shader graph, the more I am warming to visual programming systems in general.

 

Yes, because computers aren't intelligent enough to understand why a skilled professional has made the decisions they've made when arranging their graphs. I'm perfectly fine with having the option of enabling it (or perhaps having it enabled and requiring people to disable it), but forcing features on people with no alternative is generally a bad move.

 

You really are clutching at straws here. Not creating spaghetti code is a matter of design. Not creating spaghetti-looking diagrams with most tools requires both the design effort of not creating spaghetti code and extra design effort in visually laying it out.

 

I literally have to put effort into my code. I also put effort into laying it out so that it is immediately organised and readable even if somebody is unfamiliar with the codebase. Plenty of people are working with these tools and they are doing fine.

 

There are very well accepted code styles and IDEs enforce them by default. You have to expend effort to *not* follow a visually acceptable code style. On top of that you can expend extra effort to nicely line things up, et cetera.

Personally, when doing diagrams (state machines, flow charts etc.), I would much rather use dot files than any form of visual tool and my personal preference for visual graphs would be automatic layout with an optional override.

PS: My previous career was in electronics, I'm no stranger to making readable schematics and manial circuit layout. It is simply less error-prone and more testable to use a textual description of interconnections.

 

And you assume these are just things everyone knows starting out? Absolutely not. It comes from experience producing the code itself and adapting to it as you learn. You are making some strange claim that this can't be done visually.

 

Unfortunately, Unity is still giving preferential design treatment to artists and non programmers. This can often severely limit the potential of a tool because non programmers simply don't know better for a lot of techniques. I hope Unity can see the value of this tool as being part of all projects, especially DOTS based.

Honestly it would be super disappointing to see some kind of silly blueprint spaghetti that's languished in the microwave for 30 mins after being zapped for 2.

 

If they have actually been taught programming or learnt from a book, they will have been exposed to some reasonable coding style.

I am under no illusions that people can't make an utter mess out of code but it is *significantly* harder to do that once you know what you are doing, especially when using an IDE, which is something Unity comes with by default.

The effort of laying things out on what is basically a two-dimensional schematic manually is not made easier with experience.

Where I am inclined to start to gravitate towards agreement with you is that if things are made so modular, with interfaces so clean cut that dependencies are minimised etc. things will become easy to look at in both code and a graph. That involves quite a lot software engineering knowledge, so who is the target audience at that point?

I am not trying to be argumentative for the sake of it, it's just my experience so far has been that none of these systems have been clearer than code when they attempt to be general programming systems, mixing data flow and execution into a single diagram.

Graphs are beautiful for state machines, behaviour trees, data flow diagrams, where the domain is more constrained.

 

This is DOTS/ECS based though so one has to consider that kind of code is typically extremely small as well, so looking at the problem like classic visual scripting is a terrible idea.

 

That is a pretty good point, by virtue of being a much more limited domain.

 

True. But keep in mind, there may and will be cases, where large chunk of code will have to be in a single node/system. For example set of switches. While in general these are easy to lay down nicely and tidy, no one is stopped from making it a mess. Again, experience and evolution of code/graph design, should allow to produce clean visualisation easily.

 

VS, in my opinion, a waste of efforts, it's very easy to abuse and it becomes unmanageable by making thing unnecessarily convoluted for simple things.

It's good for a flow-like system such as particles and materials but not for logic. Even Epic recommended not to use for writting logics and there are good reasons. But why is Unity start a new project that they can't come up with a good solution and that does not even fit the bill?

Even if Unity comes up with a good UI (although I strongly doubt it) it will make version control, and diffing really difficult thus to maintenance cost will skyrocket as things get complicated.
UE probably has the best VS system but it still suffers from it. Look what happened to UE Market Place. More than 90% are made using Blueprint and it's a total mess.

I think they better spend their time working on improving the Editor core workflow that they have ignored for such a long time to help everyone instead, and make the Editor performance to scale up for a large project.

For example, if they can spend half of the time they will spend on the new VS, they can make really nice character animation system. Character animation really needs an overhaul yet I haven't heard anything about it and the goal is more tangeble that ECS VS. Yeah, I got really excited about Kinematica, but I hear nada since the announcement. Is that guy still with Unity? The turnover rate at Unity is so high and I always have to worry about things getting finished.

Anyway, I hate to see they ignore the core, yet look for something new, like building a tower on the sand. AI, ML, AR, Automotives, blah blah blah...

 

They are workig on improving the core too, its not like they have only one guy working on it. And as for the marketplace / asset store. I see it could have its own category.
And in my opnion state machines are great, don't know if you ever used them visually? it makes building interactions very simple.

 

We get it, enjoy your code. This thread is for people interested in Visual Scripting because visual scripting doesn't *subtract* from your coding. Let people invested in it enjoy it.

PS. you also missed the whole tiny-program-ecs-thing that this visual scripting has no others have. So prepare to have your mind changed in future. I'm sure coding for so many years should've by rights made me fixated on code only, but somehow that's not happened and I'm really into the potential Unity can achieve here that competitors failed on.

Unity can only achieve this potential by embracing how ECS is structured, because while it might seem a little alien at first, all those tiny programs working together make for pretty crazy small and useful VS graphs.

 

chrisk, don't focus on the past and embrace change! I posted this in another thread but I will post it again here!

You are forgetting that the paradigm is completely shifting.

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

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

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/

 

You don't stop abuse by taking the tools away from people misusing them. They'll just pick up a different set of tools and resume their behaviour. You stop abuse by teaching people how to properly use them (and despite what many people against visual scripting want to believe there are ways to properly use them) and the reasons why it's to their advantage.

If you don't believe me go check out Getting Started. There are many examples of bad code practices in that section.

https://forum.unity.com/forums/getting-started.82/

This is normal for a beginner and to be honest the vast majority of the examples being shown for bad visual scripting have been written by those beginners. In the hand of a skilled visual scripting user who is attempting to properly use the tools it won't look anything like those examples.

 

It shouldn't be so much up to the user to 'clean things up' or avoid spaghetti. At least when I wrote sourcecode it's fairly well structured and I can "read" it and follow it and the flow is obvious. Imagine taking every line in your program and drawing little strings of spaghetti between each one and then spreading them out on the page in random locations.

 

You wouldn't make a node for each line of code. That's ridiculous. That's like putting everything in Update() and not using any functions whatsoever. Nodes can easily be entire functions (or even groups of functions) that are written in code or using other nodes. This is just inventing a problem.

 

Yet that's precisely the case with C#. Like @Murgilod said you're not forced to write functions. You can stuff everything in the Update() method. You could even ignore Awake() and Start(), have a boolean that is set the first time Update() is run and have your init code there too. It's completely up to the developer to write clean code.

Better yet (or worse depending on how you want to view this) C#'s behaviour when it comes to formatting is similar to the languages it is based off of. If you wanted to do it you could write your script as a single line of code and C# wouldn't care in the slightest. Who needs newlines after all?

This is perfectly valid code. You might make the statement that no one will do it, but then no one other than a beginner (or a very lazy developer - but then you wouldn't want their code either) will use a visual scripting language in the manner you say they will.

Code (csharp):

1. using System.Collections;using System.Collections.Generic;using UnityEngine;public class Foo:MonoBehaviour{void Start(){Debug.Log("Start");}void Update(){Debug.Log("Update");}}

 

Exactly, visual scripting (apart from shading) look more like a gimmick to draw in noobs.
I also hope they don't go with the Blueprint-style clone, with a simple double operand math expression represented with three nodes and three connections, that's unproductive kindergarten level s**t!

They should instead explore a hybrid system and builds on top from the programmer's side, with basically an in-editor IDE with intellisense and everything that takes code blocks and functions and turn em into visual blocks.
Use a referencing system to expose and query the scene objects, components and API then hook everything up with visual logic.

Best of both worlds with full interop and would work beautifully with ECS (some concepts could be ported over there to simplify it).
Visual scripting should be used to solve high-level design pattern and reiteration problems not to write simple script statements.

 

Hey calm down, I wasn't really going hard, just a friendly reminder to Unity that it can be useful to both camps and not to get blinded by only non technical people because sometimes non technical people will use a thousand box colliders for a staircase instead of a ramp or other thing they may not have been aware they needed.

 

I think many 'non-technical' people, thanks to Unity, easily got into programming, but I think even zero-technical folks would agree that A = B * C is far more intuitive and efficient that [block A] - - - [block Multiply] < [block B] [block C].
Just saying this could be more interesting if it can evaluate actual code, even if it's intended solely for pure artists.
For programmers they could also use visual scripting in interesting ways if it could integrate their code.
So this could be a win-win instead of tug of war.

 

Just to clarify, since I wasn't completely certain after reading your post a couple times, are you referring to the individual math nodes or the math expression node?

 

I'm not aware of that node, but in that doc page it illustrates the point why this node was implemented. 1 simple line versus 8 nodes / 8 links sub-graph.
It's all unnecessary.

 

Weird how UE4 has all these developers and games but apparently visual scripting is impossible to develop with.

 

Hope we get some updates at GDC

 

I guess what's really important is simply that you can 'express' some kind of 'idea' and or range of ideas, potentially complex ones, but at a very high level without having to think or do much, and then have the computer 'translate' that into whatever its own internal representation needs to be, to more intelligently understand what you are trying to do and laving the 'how' more up to automation.

When it's a visual tool where you literally have to "create a variable" through multiple mouse clicks, and then pull up menus to find an option to do a bit of "math" and then to do an "Addition" I mean.. really, that's ridiculously low-level and not something I want to be spending my time doing in a visual editor. Especially given I could've typed a + sign within a split second in code. If it's literally slower to do something than it is in direct writing of text code, what's the real benefit?

The editor needs to be much smarter about understanding what the person is trying to express and accomplish and remove a lot more of the fine-grained "implementation" stuff up to the computer. The bigger the gap is between the visionary and what you have to do to get the computer to match up to that vision, the more effort is required.

At some point we literally should become able to just talk to the thing and have it build entire environments in a split second. Google is already doing a lot to understand the semantics of things and the graph of terms and topics and understanding more about what it means and how it connects and so on. Why not a more AI-driven development environment where you just use normal english to tell it what you want and it makes it. Right now, all the tools available are still not up to par with the human experience of artistic expression.

At some point I can see "writing code" going away completely and the end of programming/development at the scripting level. I already am having to reconsider whether I want to write ANY code at all in my project versus using a higher level tool to do most of it for me. It's really making me consider whether, in future, there's even going to be any need to write code at all, visually or otherwise. As the tools get smarter and smarter there's going to be less and less need for "programmers".

 

You can write inform 7 game in almost plain english, you still have a lot of contriviance.

How it's done now:
0. rando have a vision -> make specs sheet -> Programmer read the non sense and interpret / translate it into efficient code -> back and forth to actually get what rando mean -> hit publish

What people think the future will be:
1. rando have a vision -> make specs sheet -> write dumb down unoptimized code -> hit publish NO PROGRAMMER NEEDED

What will probably happen:
2. rando have a vision -> make specs sheet -> write dumb down unoptimized code -> Hand it over to a programmer who will trash teh code to write efficient version -> hit publish

Dumb code will be the new spec and it will be better than currently deciphering the mind of someone who don't understand code, while some stuff will adopt point 1, being competitive will happen at point 2. IMHO that's better that point 0 in everyway, because now rando has SOME logic education and therefore can speak better to programmer without dealing with the specifics of programming.

 

Probably still will happen, weather code will be optimized, or not. It will just help to further flood the game market, with cheap / free (yet pay to actual play) rubbish. Except small % of "genuine" productions.

 

You mean it's already happening like yesterday ... in fact unicorn tech company where founded that way ... but shift to 2 because competition.

 

I expect to shift most of the things I prototype in real code to nodes where it makes sense, which is a lot more than I would've a year ago because frankly, if it is dots it'll perform really well in the end.

And why should we worry about tech? https://forum.unity.com/threads/id-like-this-gi-solution-in-unity-thanks-a-lot.656899 we should have Unity solve it all, and just give Unity money.

That really is why we pay Unity. Take the GI example? You would need to code it all with a lot of research but if Unity solve all these things we need, then nodes are all we need.

We become directors, not the full staff. Unity is the full staff. This is so powerful, so pure a vision that Unity must frankly have giant balls and I mean that figuratively. Really, it takes a lot of guts to go full dots.

But without Unity solving the harder tech cases, we cannot yet fully rely on nodes.

 

Incredible and finally .... Visual scripting IS the reason why i choose The concurrent. If Unity make
a big Visual Scripting system, i think i go back immediately to Unity.
I think 2019 is the year of Unity
Also, there is so many usefull visual scripting addons on the store, wouahh so nice
Keep up the good work !!!

 

hmm, im going to have to give this a try.. one of the things keeping me from using unity over unreal is the use of C#.. not because i think visual is easier, in many cases, it isnt, but because visual scripting is usually a built in language not specifically reliant on a third party company.. i like to see gaming engines, and gaming itself become more cross-platform in the editor, in the games, in everything, and not tying yourself to a microsoft product like C# or DX11/DX12 i think is a good direction.. be it a built in visual scripting system, or open source like lua (in cryengine and lumberyard)

i may wait till 2019.2 makes a full release rather than an alpha though

 

C# has been an ECMA standard for a **very** long time. For most of Unity's lifetime the implementation of the C# compiler had absolutely nothing to do with Microsoft at all, and neither did the runtime and implementation of the standard class libraries. Mono was entirely third party. On top of that, Unity has their own runtime nowadays (IL2CPP) and the current Microsoft C# compiler is open source (Apache license). Even .NET Core itself these days is MIT licensed.

 

According to Brackey's video on the GDC roadmap talk the VS has been move to 2020.1.

 

I don't understand why unity is bothering with visual scripting. Am I missing something?

People who want to visual script already have Playmaker, Bolt, flow Canvas or whatever. And people who want visual scripting but can't spend 50 bucks on one of these won't bring you any money. So, what's the plan here?

 

Because integrated solutions, especially ones ECS based, are far better than third party tools that may not have that feature support or even exist by the time VS is rolled out.

 

To have something that is build in is very important, especially when all the competition has it.

Programmers need to work together with designers, and this is one of the ways to do that. The other way it to write a bunch of editor tools that are basically taking over the things that visual scripting would do, spending more programmer time than needed.

now I'm talking about working in a team. When working alone its a requirement for me personally to have a visual way to debug my game.

http://www.gamasutra.com/blogs/Tomm...emy_AI_Design_in_Tom_Clancys_The_Division.php
Example of behaviour trees for ai

 

Those authors lack the impetus to rewrite those from the ground up in DOTS. The market isn't there plus it will take the same amount of time as it took them to get this far. It has to be a complete rewrite. Complete re-think.

It's hard as hell and none of the existing visual scripting authors will bother. And Unity's will be way, way, way faster performing without any doubt at all, even slightly. So count me in!

Plus as Unity is not serving the existing market, those VS solutions on asset store still have a viable income stream.

 

Yeah I would agree but that's theory.

In practice what happens are things like collaborate, a tool Unity made from scratch instead of providing a bridge toward existing and well established services like Github or Plastic SCM. As it turned out, that was a much bigger task than they expected, the team was understaffed and unable to solve bugs that pilled up so much that users had to use the previously mentioned third party services.

Meanwhile, features expected from Unity are late or left undone. I work on VR, they announced VR interaction in the editor years ago, still waiting for that even though that's something we needed right away. They announced HDRP last year, it's still not ready for VR. I'm concerned about how they handle their resources.

There is also a market saturation issue. I've been using Playmaker for 3 years. I also have Bolt and Flow Canvas and never used them because I'm still looking for an opportunity to do so. Even if their are some upsides to an integrated solution, I still won't use something that I don't need.