Visual Scripting Languages

There’s an interesting entry on Christer’s blog about graphical shader systems. It reminded me of another issue that bothers me for some time now – visual scripting languages. They seem to be gaininig popularity recently and I am not really convinced it’s a way to go. Now, I am a programmer, so obviously, I’m biased, perhaps designers see it differently. As I understand it, main motivation for such systems is to let people, who are not familiar with programming (designers) to easily implement all their crazy ideas. As a bonus, it should be as hard as possible to break something. However, as noticed long time ago by Jamie Fristrom (you dont have to agree with him) - it’s heavily based on assumption that hard part of scripting is working with text (reading and writing). IMO the worst you can do is to provide full-blown scripting languages with all the typical “instructions” substituted with boxes. It doesnt solve the problem, just masks it. Designers may ‘code’ with arrows and boxes now, but it doesnt change the fact that for them it’s an artificial way to look at things. If someone cant program to save his life, he’ll be equally “dangerous” with text and visual language. On the other hand if someone feels relatively comfortable with programming, I dont believe he’ll prefer linking boxes instead of just coding. See example screenshot from Kismet (UE editor, it’s taken from Epic promo materials actually). It scares me and I’m a programmer (without Kismet experience, though, so I’m probably overreacting), if I were a designer told to fix it I’d be probably changing my pants now.

Another problem with such system is that’s hard to predict what exact functionality will be needed. In my experience, the number of exposed functions grows 2-3 times during project lifetime (ie, you may start with 50 functions exported and end with 100). At some point designers may try to persuade you to provide them with special “script box” where they could just link any external script - “so that we dont have to bother you every time we need new functionality”. Never agree. It defeats whole purpose and remove constraints that were placed (for a reason, too!). Basically, if you decide to go with visual language, it’s a hidden message: you dont believe your designers can code and they should be controlled. Of course there are other ways to achieve this using “typical” scripting language. You only export small subset of functions that can be used by designers. One clear advantage of VSLs is that it’s rather hard to make syntax errors there :)

Basically, as I see it there are two possible camps you can position yourself in:

• trust your designers can code (they’re probably called scripters then). Give them big possibilities and flexible scripting language. Potentially dangerous, but can lead to amazing results. One example that spring to mind immediately is Infinity Ward and Call of Duty 4. Download their SDK to see samples of mission scripts.

• admit your designers are “not that good” (let’s be nice) at programming. Main concern here is to make it easy for them to get basic stuff working and incredibly hard to break something. Safer, but more ambitious designers may struggle to realize all their ideas.

Choice is yours. Solution #1 is obviously harder and more dangerous, it will require hiring people dealing exclusively with scripting, but I strongly believe it may lead to better results ultimately (…in a perfect world).

[Edit] Another take on the subject by Angelo (I’m a little late to the party, it seems).

Old comments

ed 2008-08-06 21:15:56

Kismet is taken from the earlier system called Virtools. The idea behind is simple: make logic using blocks… but once your logic starts to be more complicated (if/switch/loops) it gets real pain in the ass for “script designers”.
But also I don’t agree that creating logic or shaders should be done only in text. Visual representation help even programmers to image how whole system works. It’s just a level of this representation that matters.

ed 2008-08-06 21:25:30

Ad. I would say that best solution whould between 1 and 2 :) Give designers abilitity to code blocks but also give them system based on blocks that can be easly visualized. It doesn’t have to be graph but simple list of features. Designer can script “new behaviour block” for example “I will dance at xx:xx hour for yy minutes”. This block will be added to “database” and another designer can look at it and say “Hey this is what I needed !” and will just do “Old guy->Add Behaviour->I_Can_Dance” and there you go. You have new behaviour in your character with 2 parameters exposed.

js 2008-08-07 08:27:46

I think Kismet is a great tool if you use it for what it is intended to be: simple scripting.
It really annoys me when I code something and I think it could have been done with a few clicks. It’s bit the same with interfaces, you could do everything by code, but it would be boring and uninteresting

admin 2008-08-07 08:43:23

If it’s a matter of “few clicks” - sure. Problems start when you really need more complicated logic (COD4 mission again).

js 2008-08-07 09:37:00

Then, if the problem need more complicated logic and his task is hazardeous
Isn’t it the designer’s responsibility to estimate if he’s using the right tool (visual scripting) for this job ?
He’s still free to switch back to programming

admin 2008-08-07 09:53:30

It may not always be the option, there are studios where all the logic is done in visual editor. Sadly, often it’s also not designer’s decision. Too many managers treat VSL as free “get-out-of-jail” card and solution for all problems. If company’s problem is that their designers just cant code, it wont be solved by substituting their tool.

Angelo Pesce 2008-08-08 00:03:30

I totally agree with you… I wrote a related post some time ago:
http://c0de517e.blogspot.com/2008/04/is-writing-text-best-way-to-code.html

js 2008-08-08 08:29:42

Blaming management is always an option!
I can spot a pattern for game programmers:
a) blame designers
b) blame management

admin 2008-08-08 09:13:59

..you forgot marketing guys :P

js 2008-08-08 10:31:10

I keep this one for the poor sales
a) piracy
b) PR + marketing

Jumpster 2010-06-11 01:14:26

Actually, visual scripting is very possible. Look at electronic schematics! While looking at a detailed schematic, an electrical engineer can tell exactly what is supposed to happen when the current flows.
Of course, schematics are really composed of a few basic symbols (and pin assignments) and the engineer must have some knowledge of the specific components being referenced (read: parameters).
Therefore, in my opinion, schematics represents a combination of both “text” and “graphics” to express the intended ideas.
If electronics can do it, so can we; it’s just that we haven’t evolved to that point yet - it will happen (we have UML, Object-Diagrams, Data-Diagrams, Flow-Charts etc. already), in due time - but what we have now is far too complicated to achieve that kind of functionality with current “visual tools”. We need to simplify things: Remember K.I.S.S.
Personally, I look forward to it - it will make life so much easier when it does happen…
Jumpster

Frank 2010-05-27 22:56:34

I couldn’t disagree more, I’m a 3d Modeler/ animator and have dabbled in game engines. What would take me all day in Unity programing maybe 2-3 minutes with Virtools. Although Kismet looks intimidating to me.