Unity Visual Scripting 2017?

Programming is more than just making objects properties and variables, your create an architecture with programming patterns. VS with mouse and drag, can be an "option" or good to visualized what you have programmed in advance. But sorry visual scripting will never replace programming 100%, there is just to many constrains atm. We can all dream and think scifi and try to live in the "matrix" / minority report, but reality is what most of us deal it.. We already use allot of visual tools like mecanim, and unity editor etc. VS can be good for does with disabilities or handicap, "curly braces mental block", that can't use a keyboard. But for a programmer, writing code on the keyboard is way faster than creating a spaghetti matrix with click and drag.

For does who think they are VS expert, show me how to import an external header, or import header, how to parse meta data and use it as your own generic. Show me how quick you can create an advanced encryption algorithm. Show me string manipulation, reading the memorystream,etc... Face it, programming is made to be typed, not to be clicked/dragged.. Its not even comparable, but it can be a very good extended option/tool..

 

Yeah I think people are confusing game logic with scripting, let alone programming. Many people easily understand game logic, and it's easy to think that given a visual interface to scripting you can simply rely on an understanding of your game mechanics to communicate with it, but it's not the case unfortunately, not even with Unity.

Anyway, one thing is for sure, Unity needs to make a blueprint system so that programmers can start making useful templates for artists who would otherwise not be able to get their show on the road.

 

There's various pros and cons so I won't get into those. What I will say is that there are many cases where you can have a middle ground or go full retard.

For instance, even on unity's blog - I've seen good developers use mecanim really, really badly. I'm talking about insane wires, hundreds of them. This is ignorant and bad. I used to do that then I learned that you can split it more 50-50 and you end up with a handful of wires and a little bit of control code and the whole thing is controllable and bug-free and tiny!

Also had it been all code, it would have bloated the code and made it messy. Had it been all nodes it would have been spaghetti vomit.

So there's a place for node based and code both, and people should be doing both. You can start with nodes and then learn to make your own. You can start with code and short cut a lot of stuff. You could do dialogue. you could allow people to work non destructively with your code. Options are endless and I cannot wait.

There are zero downsides to Unity having visual scripting and it is illogical madness to argue against it in any shape or form.

 

This is probably true, besides the question of limited resources, but it's fun to argue the point!

Anyway, I think it's more important for those who find code distasteful to be able to make something on their own, even if it's not particularly efficient or very big in scope, than it is to be right about this topic. So I support it.

 

i feel bad for all the people who wants to lean on visual language and all the hard work they have to do just for small simple things.

Not as long as it doesn't effects us keyboard users. I am for sure not going full retard any time soon.

 

You think implementing VS into Unity can affect keyboard users? How exactly?

 

Well if you been around with Unity for a long time, you see that more and more features changed from code based to interfaced basted, most of them are welcome ofc and are good features. Unity didnt always have mecainm. If the developers of Unity spend more time fixing visual codeing rather than other more important feartures, yes then it will effect us.. Look at unreal engine, they had there own script, that got replaced with visual coding.

 

But some people won't learn scripting, and don't want at very first sight, and other people prefer Visual Scripting.

I agree most people that complain never used Visual Scripting, and are only repeating coding is superior so what the way they are making a game mnually coding is lot better , it's non sense

UDK3 Kismet was already Visual Scripting , it was not code scripting, and Blueprints is only
the evolution of Kismet.


The only people that talk about visual scripting is those that don't know a lot , don't like it, and never used it.

 

You so sure about that? I tried this and others : AgentSheets, Alice, Bubble, LARP and some shader tool, i also use mecanim every day. My conclusion
on all of them is that complex structure has constrains, and performance is a issue. Also looking at the code this "tools" generates confirms this.. Like i said before, having this as option or to visualize what you have programmed can be handy, but not a full replacement, its just not realistic, at least not for my projects. Having both, visual as a tool is just great..


Also i want you answer on this:

 

I have to admit, I thought for a second you were talking about those wanting visual scripting. But anyway, it would be very easy for anyone to debunk our claims about it not being useful, by showing us some examples that they've made from it and going into the detail of how it works for them. I was kind of hoping to be shot down actually, since at first glance VS is very nifty.

 

Would be really cool if Unity could do something like this. The vs system would be comprised of smart inspectors, autocomplete search boxes and text code combine. It would be similar to gamemaker, but cooler, smarter. Example......

This is what's possible now with the current system.

 

Even just basic sorting and filtering algorithms would be a pain in the ass, as well as anything that would use a delegate as a parameter and where lambdas are useful. Also with my BP experience even basic member access was a pain the ass since you need a whole node to split a complex type down to its basic types. In languages like C# and c++ you can be pretty expressive with a single line of code, while in BP that would end up as a ton of nodes.

 

Lets play a little game, where we compare how you do something in code and how it is done in VS.
I will go first, in games its pretty common to want to sort things based on distance so make me a BP that can sort a bunch of GO's or actors based on distance to a point.

Code (CSharp):

1. private GameObject[] SortDistance(Vector3 point, GameObject[] gameObjects) {
2.     return gameObjects.OrderBy(x => (point - x.transform.position).sqrMagnitude).ToArray();
3. }

edit:
if the semicolen and braces are too much for you, here it is in python

Code (Boo):

1. def sort_distance(point, game_objects):
2.     return sorted(game_objects, key=lambda x: (point - x.transform.position).sqr_length())

 

I can't be bothered to actually do this, but I want to point out that there is a node in Blueprint made for equations:

https://docs.unrealengine.com/latest/INT/Engine/Blueprints/UserGuide/MathNode/

Regardless of whether you use it or not though once you've created the macro you can simply copy it into new projects.

 

This is literally the only post on the entire page that makes any goddamn sense.

 

Nope.
"x => ..." is a lambda function, so it is not about having a "math node".

 

Okay, but there is more to that entire function than just the lambda function.

 

I think it doesn't matter.

It is a great example of what can be done with text, so if there's an equivalently expressive "visual script" equivalent, I want to see it.

 

Are there any VS solutions with lambda functions? Maybe they should have. Maybe its a case of drawing a wire from the whole box rather than the output of a box. It could be interesting.

 

Just have to say, I've been scripting for a few years in Unity, and never had to use the lambda function. But who knows, someone might need it.

Anyway, I'm looking forward to seeing a node file that could do the same thing as this snippet.

 

You're missing out.

 

Fair enough, but lets keep this at the level of what hobby scripters in Unity are going to need on a fairly regular basis. Otherwise we're going to start trying to bit shift in VS or something and that's just going too far.

In my opinion, the biggest flaw of VS is the aggregate inefficiency of trying to display the same amount of information on the screen as code would do - for example, creating some system or mechanic that would take 50-75 lines of code, which you could easily take in all at once mentally with written code, is just going to take several screenfuls of nodes and be way more messy.

 

There was a thread I answered a while back where one of the easiest answers used a lambda. I believe it involved modifying every entry in a dictionary and a foreach wouldn't work because as soon as you tried to modify the dictionary the compiler threw an error about it because it would have invalidated the enumerator.

 

And i want this [DllImport("user32.dll", CharSet=CharSet.None, ExactSpelling=false, SetLastError=true)] NOD support right?

 

Still not probably what most people are going to need on a regular basis. If the point is that vs is a poor choice as a general use scripting tool, we have to stick to general-case uses, not edge cases.

 

Nottorus is on it again.

 

Here's my one (pseudo blueprint):

The green dots mean a reference to the function. The only issue you see is that the point is an external value not part of the lambda function itself so wasn't sure how to do that. And you would imagine you could collapse down any of these boxes to not show the nodes inside.

 

It tok me 5 nods to create a alghortim in React, not worth my time at all, but i have to admit is fascinating, just not useful

 

And that line of code tok your whole screen...

 

Yup. Turns out all you have to do is reflect the entire API.

 

You do realize that a game usually ends up in 100000 lines of code, how will your nod screen look like? Reflection is horrible to performance in a game environment, but you probably dont care about that.

 

That's why its important to have each node which might be built of several subnodes, to be collapsable into a single node. And not group too many nodes together. Just like you would put your code into different subroutines.

Then when everything's collapsed it would just look like a list of functions.

 

http://mattwarren.org/2016/12/14/Why-is-Reflection-slow/

 

IMO, if you know loops, know functions, won't be much of an effort to wrap your head around concept of lambda function.

Well, thanks for the example. Even though readability is clearly inferior, at least it can be done.
Pretty sure UE4 blueprints do not allow this

 

You can't do that and expect to be able to understand exactly what's going on, especially when you're fragmenting stuff that belongs in the same function in normal OOP-style programming anyway. I'm a fan of modular code, but not of slicing things up any which way, just because it doesn't fit on the screen.

 

Yeah, reflection is slow when you're building nodes based on an API but you only have to do it once.

 

But its just the same in code.

You could write distance = sqrt((x1-x2)*(x1-x2)+(y1-y2)*(y1-y2))

or you could split it up to make it more readable with:
dx=x1-x2
dy=y1-y2
distance = sqrt(dx*dx+dy*dy)

Just the same!

 

Nope, it generates pure C# codes as I said before, so it has no impact on the perfomance, as far as I can see.

If you have 1000000 lines of code in a single file I think you have bigger problems than a VS vs coding dilema.

Anyway, like yoonitee said, you need to split your code/graphs into separated parts.

Your problem Ironmax, is that you don't wanna hear. You are repeating stuff that was already discussed here before.

Also, it's not about the space that the graph takes of the screen, is about being readable by non-coders.

Ah, but here we have that subjective thing again, some people might find this easier to read than this:

Code (csharp):

1. private GameObject[] SortDistance(Vector3 point, GameObject[] gameObjects)
2. return gameObjects.OrderBy(x => (point - x.transform.position).sqrMagnitude).ToArray();}

 

I googled it just before, and understood within about 5 seconds what it was - which is what I usually do when there's something I don't know. But that doesn't mean the fact that it's left out of a vs tool really will have too much of an impact on the average developer.

What I would like to see are fairly standard game code snippets side by side.

 

Where did i say i had 1000000 lines of code in a single file? I didn't, nobody does that, my question is how
will this look like in a game 100% based on NOD system. Yes you can minimize and maximize, still its takes more
space on your screen than a line of code.

I have hear every thing (at least read since its visual text ), i think you dont read what i am saying, i do in face like the concept of NOD system and do use it regulaery, my point is just that cant see how it will replace normal code environment.

Yes that is a very good point, and like i said it can have many different usefull application. Just not main stream development. I am not saying that VS should be banned or not implemented.. you might want to read my posts again

 

No, that's not the same. What would be the same is taking a fairly cohesive function and splitting it into half a dozen parts, putting them in different scripts, adding public functions and calling them with arguments. Making it difficult to conceptualise what's going on.

It absolutely does. Whatever does not appear on screen has to be stored and remembered in your head, which has a huge impact on how much information you can work with at any given time. It can easily become corrupted and mixed up, and the longer it takes to switch, the less you carry over.

 

True. That is how Unreal Blueprints works because whenever you expand a node it opens it in a new window. Which is silly. It should just expand it in the same window or zoom into it or something. That's why Unity should not just copy Unreal blueprints.

However what should happen is that you should be able to put a box round any collection of nodes and collapse it and put a name on it. In an ideal world.

For example you should be able to expand or collapse all nodes at once by one level.

 

Just to take an real example, i do allot of SQL programing (mssql) i can code references and then execture the whole thing to the server, its always nice to show this visualized in the context editor with visual studio, or to work with entity framwork, yet the code is the main stream work. I welcome visual tools and i even think its the future, but its not even near to replace any thing.
Codes are commands to the computer even if its low level, or manged level.

Just because i love robots, doesn't mean i let it drive my car.

 

^^^ It is about space on the screen, actually. This was a one line snippet, pretty much and it resulted in screenful of data. A standard recommendation is to keep function size somewhere under 20 lines of code (meaning short within reasonable limit), and that means an equivalent can take up to 20 screens of data.

I don't see this as a good argument.

The reason why I asked is because someone was trying to claim that blueprints are the "way of the future" earlier, and because this is something I was interested in.

So, it can be done - good. Readability need to be improved and it needs to be made roughly 50 to hundred times more compact.

 

This, is the problem with visual scripting.

 

But this is their product, their resources, what if they dont even plan "fixing" features you have in mind??
You are simply user and they give you product which you prefer or not at the moment but you can always give suggestions.

Saying you dont like them working on some feature, cause propably, you dont need it and rather want them sending those ppls from working on visual scripting to working on stuff you prefer is waaay beyond giving suggetions it is simply silly.

And c'mon, i'm sure unity developers are good at multitasking as every other similiar company. They definitely work on fixing stuff.....or not.

 

But you don't need to keep every node in a single graph. It will not look bloated if that's what you're thinking.

What is main stream dev for you? Unity is mainly for indie games, remember their motto "Democratizing Game Development", people who use unity will be mostly making very simple indie games, unity's main stream is indie games.
Also, vs will not replace traditional code in Unity, is just another option.

In code you scroll down, in visual script you zoom out. And I don't think you need to remember stuff that is not on the screen, you code something, if it works you leave it there and work on something else, in code we don't always have everything visible on screen either.

It's not, is just an addition, there are people still using the legacy animation system and doing the blending through code instead of using animator/mecanim, no problem there, is just another tool for us to work with.

That' because you prefer code, ask someone who prefers visual scripting and he will say that he prefers the graph one. For him, it doesn't matter the space it takes on the screen, it matters if he will be able to understand what is going on. It is a matter of preference, we are not the only one using the engine.

Wasn't me, so you're kinda taking my argument out of context. I don't like to "predict" the future, I like to be surprised.

You guys are missing the point here, this just became a "Unity vs Unreal", "Maya vs 3ds max", etc etc, it's not like that, we will have the best of both worlds, also, again: you don't need to use it, and don't forget this: everything is subjective! What is easier for you doesn't mean it's easier for others, what is best for you, doesn't mean it's best for others, I know there are some technical details that does make something stand out for the other but that's okay.
Remember back in ~2004 when there were people being against commercial engines claiming that coding your own engine and using pure C++ + directx/opengl/etc was a better option and the "right" thing to do? And here we are, doing what we think what is best for us, using Unity engine.

Also, just to be clear, I don't use VS and I will not use VS when it becomes available, I just love the word "subjective", it's like... my new philosophy. Live and let it live, I stopped telling people how they should do stuff just because I think is right/best, show them the paths available and let them choose.

After VS be implemented time will tell if it was a good thing, like Animator, or a bad thing, like unity adding Flash as a platform.

 

Read previous posts , there is some game and demos examples, if you make some research you'll find lot more.

No one said code will be replaced, one major advantage is coders can work faster than connecting nodes.

Indeed, but Visual Scripting does not write code for you, it's like you are coding but in a visual way.

It's not a small company, they can have one guy only working in Visual Scripting tool and improving it.

+1
You can make some AAA games like the game Pamela, but it's not Unity main usage, because the majority users are indies. And Visual Scripting suits very well indies, and those that don't know coding.

 

Ofc its there product, but if all the customers scream " i want yellow bars", they will push the focus on. From my own company perspective i do the same, i don't think about it as my product, i think its more " my service", this is something you understand if you spend some years on running a company with customers.