Unity3D getting Visual Scripting in 2019.2

This is some very good news. I am looking forward to 2019.2 and 2019.3

 

Good, finally.

 

Visual behavior trees are nice for AI etc. For everything else a real language is always better

 

Not quite everything. Visual tends to be much easier to manage for the high level stuff. Event sequencing. Quest logic. Trigger logic.

There is a whole host of high level things that will go better in a visual language.

Edit: Although looking at the picture it appears to just duplicate C# in visual form. Which is mostly a waste of time. If visual scripting is to be valuable, it should embrace a different paradigm that takes advantage of its strengths.

 

True, but at the same time, the second point mentions high level nodes, so I wouldn't be surprised if a bunch of common things don't come with specific nodes rather than being just pure C#.

 

Yeah, that's what excites me about visual scripting. I write out all of the methods to do stuff in C#. Then I combine those methods to do stuff in a specific order or pattern via visual scripting.

 

Looks interesting. I've never been a fan of the horizontal node layout most VS's use. Regular code is vertical, and I assume you will be able to group things into a node that can be inserted into a stack to keep it clean.

Hopefully they can include an FSM and BT into it.

I'm interested to see how they support custom classes via reflection. Vizio from years ago had an interesting Wizard Node that could convert to any type, and expose any variable from a checklist. FlowCanvas has lots of extract nodes of certain types instead, and also register a custom class first, but maybe there was another way which I'm forgetting. Hopefully the Get Property node in the screenshot just works automagically with any type, but what if you wanted 5 different properties? Hopefully not a Get Property node for each one.

 

I'm willing to bet that if there isn't a node for this to begin with, there'll soon be a community one.

 

I wish they would just buy flow and node canvas since it already has FSM and BT's. Plus a ton of other unity conveniences like automatically getting components / converting to types etc.

I just don't see Unity coming anywhere close feature wise right out of the gate. It will be just like the shader graph. Amplify seems to be way ahead of Unity.

 

I'm wholeheartedly against visual scripting. It's usually slow like hell and lazy, and when the Asset Store "publishers" start to use VS to "write" their code, you can bet that the real value of their product will fall into oblivion. (please make it mandatory to label their "assets" if they use VS for "coding")

I have no problem to visualize stuff with lines and boxes since I learned coding when flow-charts were a thing. BT-s and FSMs are okay IF they compiled into proper code. But usually they are also slow like hell.

Also I have fundamental problems with VS: the next generation of coders will play with this and will be too lazy to learn to code properly. Although it's good for the current professional developers (higher pay-rate), but it's bad for the industry and bad for the innovation.

 

I don't think this is right wording.
At least I consider general Visual Scripting a good thing.
But only for small things, or fast prototyping.

However, I definitely second that.

I wouldn't be surprised, if there will be flood of VS based assets. But did it happen with Shader Graph? I haven't checked.
I think major problem with any visual editor, is tendency to break apart, with future software iterations.
While it is easy to fix something in the script itself, in case of when something changes in core of visual editor, whole graph can become mess. Often very hard, if not impossible to fix, followed with possible file corruption.
Anyway, I wouldn't really for long term on the visual graphs.

Small anecdote of mine.
I was making some basics shader other day in Shader Graph. Was done. But I wasn't happy with its performance.
Maybe I haven't approached it in right way at the time.
However, after giving up on Shader Graph then (I think I spent 2 days or so), I decided to learn shader scripting and write it. Again, initial result wasn't promising as I would thought. Yet, with an assist of the forum, I have been advised to change just few lines. Performance bust was massive. And took far less than 2 days.

 

The problem is: visual scripting isn't faster. So you're not prototyping faster. Maybe the fact that your designer and artist also can put some chaotic string-knot together, overall faster, but when you're going to production phase, you will have to scrap basically everything. (Usually from the code prototype you can savage some parts)

Not yet, but considering it's a fairly new tool, I bet they're on their way.

And shaders have an arguably small set of commands/code-paths. Just imagine when it applied to general programming...
Although I'm curious about ECS+VS combo, but as I said, I'm skeptical about it.

 

Thats interesting point. But I doubt it.
I think it is just graphical overlay, on top of classic OOP.

The thing is, for example artists may not necessary be programming / shader literate. But without knowing about coding, they can make up something in Shader Graph for example. Therefore, for them will be faster. Or at least more encouraging / approachable.

Lets say as example putting patter based color changing. Which takes few nodes.
Anything to code, require much more experience.

 

As long as a visual engine only is used as a state machine and the actual logic is implemented in code in fine with it.

 

Depends what you're doing. A modular transform rotator monobehaviour would be slower to write and add to an object in code.

 

It really depends on a lot of things, especially on who is writing.
How quickly you're able adapt from the mouse to the keyboard and back. How often you're moving your boxes on the screen. How the code generation works (do you need to "define" your variables or the generator will take them from the first usage?), and many more things.
But on average actually hitting the keyboard is always faster than moving back and forth between the keyboard and the mouse making precise movements.

 

https://ludiq.io/blog/bolt-2

Bolt 2 also generates C# and this way is very fast.

The argument of slow speed is out of date.

And as for connecting the nodes and setting being slower as typing on a keyboard.
Not for me, typing takes me way longer. because I don't know what I'm doing when writing code on the keyboard, and I have to look up every single line of code how to make it work.

 

Including how fast you can find the nodes in the menus. I remember with UE4's Blueprint it quickly started feeling like I would have to memorize the first three or four letters of every node just to be able to use it in a timely fashion.

 

It's hard to beat me in VS with resharper. Though it's a moot point, most time is not spent writing code but designing it etc

 

But you will have to wait for at least one compilation, or two if you create the script inside the Unity editor. VS assets seem to do it faster or at a later point. The main speed problem with VS (related to writing code, not performance) is when doing basic math, but that could be sped up with some kind of smart expression node, so it wouldn't need tons of basic blocks.

 

I would agree with that. Doing basics math in visual editor can be pain. But other stuff, like textures / animations etc. then editor become very convenient. Specially when you can see changes live.

 

No, I prefer Unity engineers solutions. This means that they can start with a clean slate, it will be free of legacy cruft with full control.

Don't have to use the Unity solution. Your favourite assets would receive no performance advantages from being native to Unity. Unity does all this stuff in C# these days.

 

Finally.

 

Indeed finally,
Just for the heavy "art" projects alike: Visual novels, animation shorts with limited game-play impute this will be huge step forward. Hopefully is not "just" another simple FSM/ flow chart spaghetti thing, but one you can actual type in more complex math etc --> like scirra´s Construct.

 

This is not a problem with Visual Scripting. If they don't want to learn how to code in C#\text they won't learn to code (Although they should learn the basics of data\logic from VS). Visual Scripting has a few good applications, for example:

Dialogue

Dialogue systems normally go:

• Build the API (Pass some dialogue info to the dialogue system)
• Some way of serialising\deserialising the dialogue info so designers can create it \ give it to a character
• Add ways of visualising the dialogue info
• Add ways of changing dialogue info based on events or story data

Essentially you get to a poor visual scripting\custom scripting system anyway. If you just expose some nice Dialogue API to the visual scripting system you get all of that for free.

I think visual scripting should be used how Warcraft 3 uses it, as a way to create really custom behaviour or events using the really specific game API that you have made rather than building your game in visual scripting.

 

This is great and i don't think it will make people "lazy" or affect the future generation of coders. Actually, it will help a lot of people to get into pure c# since learning curve is quite steep in programming.

 

Yeah, it reminds me a lot of Blox (and plyBlox). I can understand why non-programmers might find it very useful, but I just couldn't handle working with it. For me, trying to create a script with Blox was a similar experience to trying to type a paragraph on an old mobile phone (which only had the numeric keypad).

I do agree about visual scripting being useful for high-level features -- essentially, the things that game designers would typically be writing in whatever runtime scripting language the game engine uses. A spell system or world object interaction system would be coded by programmers, but specific spells and individual world interactions would benefit from being created using a visual scripting tool.

 

Well I'm glad they're going with something that looks a bit like Scratch. As I think that's a much better than the spaghetti of Unreal blueprints. They could make it even more compact by shifting some of the data links to the right hand side.

What would make this a killer feature would be if you could do your visual scripting with keyboard commands only. Then nobody could say it's slower than typing scripts because it *would* be typing scripts. It would have an intellisense for visual scripting. This would be quite easy to do by the looks of it just using arrow keys to navigate around the nodes.

Also you should be able to type in expressions like Mathf.sqrt(x*x+y*y) and it will either keep it like that or turn it into a collapsed equation-node (even typeset into a nice equation!). Because writing out math equations in visual language is not very intuitive or fast.

 

Yes! Finally we'll get even more shovelware

 

We're at saturation on that I think. There are so many existing "no code required" packages you can get for free even that this will just benefit artists and people who are also less likely to have coded before dipping their toes into game design.

 

just watched the video, and actually sounds like the most interesting part of it is
that apparently you don't need to compile it, can keep working in the playmode!

 

While hot compiling sounds cool, in my experience its mostly a waste of time. Should initialization code run again? What should happen to the values of existing variables? What about variables pointing to this object? Its very easy for the program to end up in a undetermined state.

While its occasionally useful, most of the time its just too messy to be worth worrying about.

 

Hot-swap is useful when you're doing reactive systems. Like an event on a button click or something like that.
Obviously with initialization and maybe with tear-down hot-swapping an entire application is not a good idea. Although the Unity Editor is kind of doing that with the editor code.

 

I LOVE THE IT! VISUAL SCRIPTING! SO AWESOME!!!

Im surprised by the negativity of this post I think this is absolutely amazing

I'm a visual person and without visual programming I wouldn't be able to create games or I should say it would take me forever, for some reason I just can't remember the syntax when that big scary code editor is looking at me but visually I have the opportunity to create games and can find what I need when I need it for some reason its easier for me.

I'm so excited and can't wait to start using it!

P.S. I have no interest in learning how to code, I just want to make games

 

That's what they said at Unreal...

 

I don't know what is the story with Unreal, but I can not fully agree with first statement.
While for most cases perhaps it will be true, in the end many games will be shipped using visual scripting.
I am not to judge at this stands weather is good, or not having full game on VS, but definitely affects such game owners (including haters who own game). Definitely, if game will end up somehow bad, VS will be just extra spark to the haters fire If good, perhaps will end up without of much storm.

 

Visual scripting will be a nice addition. Sure, the initial release will probably be so awful the backlash would drive weaker developers to suicide, but then the next release will be so much better everything is forgotten

The extensibility is the best part of their plan. It wouldn't be the least bit useful without that out of the box, because the team members who need visual scripting will usually ask for something they'll have a hard time even cobbling together in that tool. That's where we programmers ride in and save the day by making nodes for them to use like LEGO

It will also be interesting to see how far UT take the use of it. Visual editor plugin design, GUI FX and animation setup, network lobby configuration? Just kidding about that last part - that implies they ever finish the network API!

 

From my experience, you can't avoid Blueprints because pure C++ is very hard to use -- need to use file paths, need to #include every component, no visual editor for the subobjects. However, I don't have much experience there, so any experienced devs can call me out.

 

Unlike UE4, Unity's had visual scripting very late. This gave Unity a lot of advantages as the baseline code and components that make up typical workflows are very well established, so there aren't any of the usual issues that could apply.

 

It's a bit of a trade-off. Traded having it for eventually getting something that's likely to be good and last longer

 

I suppose, one of advantages is the fact, Unity could learn from Unreal, to evaluate best product.

 

UE4's C++ is not "pure". It makes heavy use of macros to make life easier for developers. That said the statement I've heard isn't that you can't avoid them because C++ is difficult to work with (which is an opinion that many programmers will likely disagree with including myself), but because UE4 requires them to some degree to make use of the engine.

 

Yes, definitely. I worded it wrongly -- I wasn't meaning that C++ was hard to use because it's C++, I meant it was hard to use because of how the engine was designed. Almost every thread I've seen online recommends Blueprints, or at least says avoiding it will make life much harder.

Edit: Also, you need to buy a plugin to get autocomplete, apparently...

 

Look, I know we are behind the eight ball. But Unity has a wonderful team of developers working on it. I'm sure we will reach issue parity any day now.

 

I suppose this will end up with parity twice over, with +1 for Unity

 

UE4's c++ side is a mess because UE4 is Tim Sweeny's attempt at a game framework after he spent most of his life making first person shooters. He rebuilt the UE4 framework from the original unreal mostly by himself over a number of years then dumped it on his team to "polish and release".

It's over designed so you spend all your time trying to figure out when you should inherit from what class and what methods you need to override. I don't miss it at all.

 

As someone who was there from early alpha onward way before release, I hardly think that's the case. UE4 is an excellent engine.

We don't do the whole engine bashing thing on this forum.

 

From wikipedia.

 

Yes, but Wikipedia does not back up the statement that it's a mess