Visual scripting vs writing code

Hello,

While i am a developer and i know how to write code, i am aware of many available visual scripting tools for Unity (uFrame, PlayMaker to name a few).

Unreal Engine 4 also includes the Blueprints system that looks like the common way to create the logic for game systems.

So, it seems that visual scripting tools have some place and can be a useful tool in the developer's arsenal.

Having said that, i keep hearing negative opinions of using visual scripting tools as part of the dev process (things like - "if you can code, stick to that", etc).

I have not used any of these tools yet, but i'd like to know from others' experience - what are they good for? can they be better than coding for specific tasks? and in general, what is your opinion or experiences with using visual scripting tools (uFrame, PlayMaker or any other that is good and that you've used).

p.s: I know this discussion is kind of "opinion based", let's try to keep it civilized and avoid any religious arguments (e.g: "visual scripting sucks!!! code rulez!!!!")

 

You can probably search this forum, I think this is one of those "beaten to death" topic.

I see this as follow, you split your behaviour in low level stuff, and in high level stuff. Low level, like path finding, AI behaviour, managers, animation handling, and the collection of gameplay specific MonoBehaviour should be in code.

For example, if you have to create trap that shot something, you should code it, and expose enough variable that a design can tweak it to its liking. Like a variable that define what the trap shot, its speed, rate of fire, damage, etc. In this case, it's simply too much of a pain to do in visual scripting properly.

As for high level stuff; cinematic, level wide gameplay, puzzle, or any stuff that is too specific to a single setup and not easily reusable, that's where visual scripting shines.

A level puzzle is often a one time deal that the designer will keep tweaking over and over. So in this case, the designer should directly and personally tweak it without any direct help - most of the time. Maybe part of the puzzle, like levers, will be coded as a MonoBehaviour, but the overall logic and inter-object communication would be best in visual scripting.

Keep in mind, Visual scripting is there to add something that would just be too specific and too messy to do in code, like the timing of a cinematic, or animation blending - which is why Mecanim is so useful! However, visual scripting greatly suffer from the chaos theory, in which it turns into a mass of spaghetti very easily, logarithmically proportional to the number of item in it.

 

Are you referring to the visual clutter that larger visual scripted systems may suffer from ? this is a usability issue that can be improved in probably many different ways (e.g: hierarchical nodes that can be expanded/collapsed, etc).

What other disadvantages does visual scripting suffer from?

I would imagine that visual scripting can greatly improve scenarios where you just have to "see" what's going on instead of coding it.

This can be, for example, a behaviour that fires events, with other classes/components registered to those events.

Visualizing this can help you spot any errors in the behaviour of your systems (that's a nice feature that Mecanim has).

 

You can add the tools you want to help handling it, it will simply never be enough to replace code. Writing, searching, handling, managing and debugging code will always be faster. Visual scripting is there for when a programmer doesn't or shouldn't need to be involved. The spaghettification is simply unavoidable in visual scripting, and reach maximum entropy faster the more people handle a graph and its complexity. I've seen node graph with thousand of nodes; it is never pretty to see, never easy to handle, and a nightmare to debug.

I'm on the fence as I have experience handling both code and visual scripting. I'm easily 4-5 times faster in write code... and I know people who are in turn 4-5 times faster then me in writing code. However, I know nobody who are much faster in visual scripting. The maximum speed you can reach in visual scripting is just capped much lower.

Another issue is that visual scripting has the intention of giving logic-driven scripting in the hands of people who are not programmer. By experience, it's really not always a good idea. Programmers have the experience of handling such logic.

Now, I'm not saying visual scripting doesn't have it's place. I would deeply hate trying to script a cinematic timing in code. It's just a matter of the right tool for the right job. You can build a house with a hammer... but I would prefer a pneumatic nail-gun.

 

I love visual scripting. A lot of AAA games use it to a degree. A few points:

1. Visual scripting only makes sense where a Finite State Machine makes sense. However, the vast majority of programming is not related to a Finite State Machine.
   
2. Generally we use visual scripting to know when something should happen, and in what order. However, the actual *making* something happen is done in regular code that is called by the FSM.
   
3. You still need a programmer to make visual scripting awesome.

I'm going to use Borderlands 2 as an example. This is 2K Game's best selling game of all time. Here's an example of a quest chain in one of their acts.
http://www.gearboxsoftware.com/community/articles/1059

You can see they obviously use visual scripting. The point I want to make is that a lot of those boxes run code made by a 2K programmer. Those boxes hide a ton of normal hand-typed code so the quest designer can focus on design. You can't just use visual scripting out of the box to make a AAA game.

PlayMaker is an excellent example. Yeah you can do some simple things with it, but if a programmer makes custom PlayMaker actions, that's where PlayMaker really shines.

Eg: I have a PlayMaker action that can add 1 of a specified item to the player's inventory. This action can be reused all over the place, but it was created by one of our programmers for our game. Our inventory system is NOT visually scripted. It would be really hard to create an inventory system with visual scripting, but being able to drag-and-drop in "Add 1 health potion" in our quest editor, which uses a visual scripting system, is super useful and time efficient.

 

Hi gang,

I've received a reimplementation of the Break-Out Unity tutorial built with the latest v2.0.18 release of iCanScript. this is worth seeing for those of you that are interested in the generated code quality.

http://www.icanscript.com/forum/icanscript-examples/34-break-out