Visual Scripting has gained a lot of attention the last years, by various indie designers that don’t want to learn coding its considered to be kind of a holy grail to enabled them to do things they would otherwise never have been able to do.
The likely widest known usage in the game development is Unreals Kismet which is powerfull and well integrated and especially makes cinematics creation very easy. But its also Kismet that shows the limits compared to going with UnrealScript, there are just things it can not do or things that look that clumsy that you really don’t want to do it there. So lets talk about the pro and con in detail.
The raw potential
The main benefit of visual scripting is a simple yet important one: Its not text! All the limited functionality they normally provide are easy approachable, making it possible for people without knowledge in one or more coding languages to create interactive functionality. But it requires that simple yet powerfull nodes for the specific tasks in question are available.
Through Nested nodes (sub graphs) its additional possible to raise the readability of a graph and make parts of it easy reusable.
The problems
The largest problem that anyone will unavoidably hit within hours at maximum is the ubiquity of the information. A functionality written in code taking 5 lines of code can easily lead to a graph spanning dozens of nodes and more to be represented in visual code. As an example of this problem of readability and „just beeing“ please see the following simple graph (done with uScript Retail Beta3) that does nothing but bounce a game object by a given Vector3 over time and back again. The screenshot shows just the small part of it handling the position forward backward handling
Enumerating collections is another thing in visual scripting that basically is a pure nightmare. Even if there were any visual scripting technology that would be able to represent this process in a LINQ alike form, it would still be very hard to grasp for designers.
As mentioned under the raw potential, one of the benefits of graphs is also a drawback and thats nested nodes (subgraphs), which if used right offer an easy way to reusability and making a graph more readable. But unhappily when not used right they can make it near impossible to maintain a graph at all. Especially if the designer uses nested nodes within nested nodes and even deeper hierarchies it becomes impossible to handle them any longer.
The options in Unity
PlayMaker
Not a visual scripting technology per se as it does not allow to create free form code, its an editor to design Finite State Machines, and important and very easy to grasp concept as we use it all day long without knowing about it.
Out of my view the best solution for pure designers with no coding knowledge because it is not only easy to approach and backed by piles of tutorials etc, but first and formost its not „just code“ that the developer will create but a clean and solid interaction broken down into states. Other solutions as well as pure code in the hands of non coders often lead to messy code and spaghetti code, while PlayMaker does not allow that, it requires that the designer thinks about the interaction and how it „plays out“ to create corresponding states and transitions.
The result will be code that he can maintain much easier and which is much more readable as only the states end on the ‚graph‘, which will enable him to get more done and especially done in a working form.
A usefull feature to make this even easier is the capability to visually debug the FSM, so you see in which state it is and where it transitions etc.
uScript
uScript is the youngest of the 3 solutions, approaching its release version (Retail Beta 3 at the time of writing). It follows the design principles that are applied in other technologies too, especially Kismet from the Unreal Engine / UDK.
It has well done and polished visual appearance that not only helps being productive but especially being able to grasp the meaning of a graph with a glimpse or two.
One unique feature it advertises to have is that the graphs actually generate C# code, which makes it platform independent. But to be fair, out of my view that generated code has relatively little meaning cause its impossible to work with it beyond „looking at it“ and being granted to work on any platform as its not designed and written for usage in a pure code form. Also when the corresponding graph is resaved, it will be overwritten!
Its major drawback compared to the competition at the time is the lack of visual debugging, which brings back one of the main problem for designers on normal coding to uScript too and thats that you need to know what you do and where an error comes from to fix it basing on educated guessing.
Antares Universe
Like uScript its a full visual scripting solution, which unlike uScript does not base on the Kismet style of working but a more „programmer style“ approach without the temporal variables for transfer or the coroutine yielding directly on the connectors (the + buttons along the lines)
It clearly loses on the front of visual appeal and easy graspability due to the graphics and the layout of nodes and connectors, but it compensates for that through two major benefits over uScript, which are the visual debugging (like PlayMaker) and the possibility to create GUIs in realtime within the editor basically.
Also it offers many very high level and high usage nodes out of the box (LoD node for example) and at least from a subjective point of view a clearly higher execution performance than uScript.
Conclussion
Its neither a holy grail nor the apocalypse. It surely has its good points and when used correctly, for example to expose high level logic in a designer friendly form to allow them to create that code on their own while the programmers focus on the low level and core systems, then it surely can turn into a diamond for a project.
But on the other hand if a designers with no programming knowledge has the hope to create whole games purely on it, I personally consider this completely unrealistic and a major source of frustration for the designer more sooner than later, because there will be limits which he will just not be able to solve without a programmer.
None the less visual scripting can enable a talented designer to create a simple game or a prototype to grasp the interest of others or an investor, so its not per se bad or deal breaking at all
