EDIT–This post is totaly re-written
Hey,
So, I am working on a new visual scripting NodeCanvas extension for some time now, and would like to share what I’ve been doing with you all :).
The initial idea started off inspired by the node editor in XSI (ICE), but soon enough I kind of realized that this would rather not be very usefull as-is in a game development situation, which of course we are all after I presume.
The reason I started with something similar to XSI’s node editor for a visual scripting extension, was the freedom of data manipulation that is possible, compared to other purely game oriented designs existing for Unity right now. Without going to technical, the main difference is that it doesn’t have the usual “In - Out” state like nodes, but instead all data are piped down to an Update call, very similar (visualy) to how you would create a shader in a visual editor.
Softimage ICE Node Editor
Long story short is that in a game dev environment, the above system:
- It may be costly for games.
- It’s hard to read when it comes to flow control, like loops, conditionals etc which a game obviously is full of.
- Require more work to figure it out that it’s worth, where instead you could go in and code the same thing. That is considering that a visual scripting tool is really there to bridge the gab between coder and designer, rather than replace either of the two!
With that said, I love the ICE system and use it personaly, but I think something similar would not fit for visual scripting game logic.
So, the next closest thing to XSI ICE node editor actually for game development, was clearly Unreal 4 Blueprint, Bitsquid Engine flowgraph and at a lesser degree CryEngine’s flowgraph, which combine a visualy forward execution state-like behaviour together with backward data fetching.
Blueprint, like ICE, also provides some very low level control, but there are some pros and cons by having this control or not.
Putting this to test, I came up with this. (Of course color coding things is now mostly missing)
In this first case, we can directly pass data around and there is no need to store it somewhere temporary, although we could if need be. Furthermore there is both great flow and data manipulation control. The downside is that a real graph might easily become a spageti, where in pure code it could be just a 2 liner.
In this 2nd approach, there is hardly any low level control and we can’t directly pass data around, but instead need temporary storing, which also needs to take place “within” the flow design by executing rather than getting (eg ‘Get Property’). The obvious good thing is that its much cleaner and probably more focused by not exposing all funtion arguments and return value as ports
Then again, at first glance it seems that the initial purpose of data manipulation is defeated without exposed ports.
In a way, we could combine the 2 designs above to get some good points from both worlds, by using ‘compounds’. Or in other words, a handfull of nodes compounded into one with specific exposed ports.
(This image is a proof of concept in photoshop)
And then use and reuse the compound node to make the higher level graph cleaner and focused.
This seems like a good aproach, but on the other hand, this compound node could be made into a simple function in code and then use an Execute Function node like the rest. So this is a point where I am skeptical about.
In the end it comes down to how low or high level control to exist. In both cases I hope this to become a very versatile tool in the overal steps of blueprint 
So, this is what I am working on and my thoughts on the matter shared with you.
What do you think? Do you have any ideas that want to share? Would you prefer one aproach over another? Would such a tool be useful to you?
Implementation wise, this is already working more or less except the compounds, UI color coding and some other thingies I will post in time. If you have any question feel free to ask
Cheers!
