This is some very good news. I am looking forward to 2019.2 and 2019.3
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.
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