Unity is really missing a native Visual Scripting Tool

uNode looks interesting. Curious if further versions can produce a whole node graph by importing your own c# script..

 

Bolt plugin is awesome, fuzzy finder is very well done, appart from visual scripting code, it has FSM to create high level AI and leverage your "if then else" coding.

 

You shouldn't use visual programming tools unless you are doing behavior trees for AI or similar. Why? It gets really hard to maintain in a large project

 

I agree, but as most are doing, for a large project you can mix visual scripting and coding.
For example all AI detection system would be a custom node you will code containing many parameters exposed to tweak it, and you use it in your AI flowgraph to branch to different nodes depending on results.
This way it will leverage a lot all the "If then else" coding and you'll be able to debug visually what is going on.

 

Yeah, AI is a special case and I did wrote that We use Node canvas for our AI, 99% of the work is done in C# and we use node canvas to control the flow, ie the behavior tree

edit: I responded in general to the thread, not a reply to you btw, sorry for the confusion

 

No worry.

Full Viusal Scitpting way is also very usefull for the category of users that don't know coding.
There is lot of non coders using Playmaker, and i seen some great games demos made by 3D artists that learned Blueprints and liked it a lot.

 

I would say yoy can't make a large scale project in pure visual scripting. We do refactoring etc everyday in our very complex domain, thanks to stuff like that it's still maintainable even though the core domain is as complex as it is

 

You say that as if it's not already true with large text codebase, anyway, the idea, most hotly debated in the latter part, is a better paradigm of visual coding not the current one, and the conclusion was we already have some of that implemented but for some reason it doesn't exist either, which is a weird argument to leverage against visual anything.

 

Yeah, visual scripting can become confusing sometimes.
For example some vector and transform process between two objects needed many nodes and links, while it was only three lines of code. I found it was better to code a new custom node code to replace all that nodes to keep flowgraph simple and high level logic instead.

 

A game with easy game mechanics doesn't suffer as much as a game with a complex game mechanic. I would like to see someone make our game with visual scripting for example.. Not saying it cant be done.. But it would probably be a nightmare to maintain. Offcourse text based code bases can be hard to maintain too, but atleast with good devs its possible.

 

Yepp, but with nice tools as Coroutines and other highlevel stuff in C# lots of "workflow"-related stuff can reside in C# and be more maintainable actually. Behavior trees for AI though, here visual scripting shines

 

Yes, visual scripting is awful for low-level operations. It's much better when you have a programmer creating building blocks for the visual script, based on requests from the non-programmers. Basically anything that involves lots of variables shouldn't be directly manipulated with it - make a dedicated node with the logic behind it and expose as few variables as necessary so the artists can wrap their heads around it.

Behaviour, dialogues (with player-choice for branches) and monologues (with random variations for branches), perhaps even magic item logic are excellent uses of visual programming, while individual mathematical operations are pretty much the worst, most annoying thing to do. Depending on how the script backend works, this might also introduce some slowdowns. It might cause an extra context switch more than necessary, or add seemingly useless temporary variables.

For certain things this won't matter, but if you're exactly doing the visual equivalent of the programming I think you're doing it wrong. To use the LEGO comparison, writing node logic with transforms and other individual method calls all over the place is like building everything out of of 1x1 flat bricks on a large baseplate.

 

Dialogs and UIs are perfect example of when coroutine workflows are perfect. Example from our game

Code (CSharp):

1.         private IEnumerator SwitchTeam()
2.         {
3.             var result = ShowConfirm(AvatarController.Player.IsDead() ? "Switch team?" : "You are not dead, you will lose a life. Continue?");
4.             yield return result;
5.  
6.             if (result.Result == ConfirmResult.OK)
7.                 BaseGameMode.SendCommand(new SwitchTeamCommand());
8.         }

 

Yep, there is some helpers in visual scripting tools like making macros or sub flowgraph.
Still i also think it's better to keep your complex low level stuff as code or make it as new nodes for example.
It's always a matter of project complexity, a little arcade game coding is really different from a complex project with advanced features.

Yep, FSM and BT and some other high level tools are used in most AAA games.They can be understood and used by non coders and for debugging it's so usefull.

While Visual Scripting code is still usefull and also used in many AAA engines to allow level designers and non coders to create some level gameplay or functionnality.
Horizon game engine got visual scripting for that purpose.
https://www.guerrilla-games.com/read/creating-a-tools-pipeline-for-horizon-zero-dawn

Or FFXV with many high level tools, otherwise teams would be coding millions more of lines of code lol
http://www.jp.square-enix.com/tech/library/pdf/2015cedec_FFXV_AI_English_part2.pdf

It's a matter of keep things balanced, avoiding too much coding for high level logic and avoiding too much visual scripting nodes for low level components.
But someone could prefer to do it all in visual scripting lol

Visual Scripting will do very well for some games, they are few UE4 great games demos made with full Visual scripting because they are not coders. And there is lot of games using Playmaker.

 

Your example is very specific to use co routine for a dialog task, is this multiplayer ?

What about a tool for your dialogs ?
At 0:30 you can see a menu with lot of low level function components instead of coding.

 

I ment a dialog as a UI dialog But all mini workflows can be done usign coroutines.
Yeah, its multiplayer