Thoughts on Scripting - To see, or not to see

Last time, I talked about some motivations for using script in games. For at least the next two posts, I'm going to talk about some of the possible representations for script that I have seen, and about some of the pros and cons with each.

At the highest level there are two options: visual or code script. Visual scripting language implies to me that there is a GUI interface where you are dragging around boxes and lines (or something to that effect). However, within visual representations there is a gamut of visual-ness. Visual can mean that all of the operators are predefined as visual primitives, or it can mean that relationships are declared visually but operations are implemented in script code. I have also seen a lot of these "visual" representations done entirely in code. There is power in the form of the abstraction even without a GUI.

Visual has definite benefits.

• It is extremely expressive, especially for small datasets. There is tremendous appeal in being able to inspect and understand a chunk of code at a glance, and that is what the visual paradigm offers. 
• Drag-and-drop interfaces are also appealing for fast manipulation of "chunky" data.
• Though it pains me, less technically savvy people can both grok and manipulate a visual representation easier. Manipulate can mean here either change relationships or twiddle parameter values.  

There are also some benefits which may or may not be realized for a particular implementation.

• A visual interface tends to break logic into smaller pieces, and may facilitate more reuse. 
• Visual representation also tend to provide more structure to begin with, which can mean less time spent developing the correct level of abstraction. 

It isn't just roses, though; visual scripting has its problems.

• While expressiveness for small datasets is good, large datasets can be a real mess. FSM are somewhat famous for the difficulty of representing large problems cleanly. 
• Hoisting functionality for visual languages can be painful. The underlying operations have to come from somewhere, and the process for exposing new operations to the visual interface can be time consuming. 
• The benefit that visual languages provide through additional structure can turn from blessing into curse. A rigid or ill-fitting structure can lead to gerrymandering as people try to solve problems. 
• Implementation cost for a visual scripting language can be quite high.
• Visual languages often have poor support for problem abstraction, and can fall back on the ease of duplication with variation. 

The last problem is particularly thorny. A lot of people make the assumption that since script is "simpler" than code the problems addressed in script are simpler. Hah. One of the major failings I have seen with script in general is that the script system is designed for simple problems, and under production conditions problems don't stay simple. Without support for mitigating complexity (e.g. generalization, black boxing, polymorphism, templetization) script can turn into a real mares-nest. Let me restate: Don't go to production with a scripting system that doesn't have tools for mitigating complexity. (You probably will anyway, but now I can say I told you so.)

Scripting code has fairly obvious advantages. 

• Flexible - it is just code, do whatever you want.
• Often there is better support for abstraction, complexity mitigation. 
• Good tool support (e.g. IDEs) for non-proprietary languages.
• Language robustness for non-proprietary languages.

The disadvantages for scripting in code, for me, stem out of its power:

• Flexibility can lead to more ad hoc mechanisms. Rather than using a standard tool for expressing a relationship everyone rolls their own. 
• Units of work can grow quite large. I have seen script tend toward "kitchen sink programming", where single functions or files do a huge amounts of work. 
• Relationships can be hard to discover. There are no nice little lines connecting the boxes. 

What have I missed? I am certain that this is a topic on which many hold opinions.

Next I'll get around to some variants for both code and visual scripting representations.