Wumple.com

Damien Schubert has an interesting video game development post entitled "No Scripting for You!" on his blog Zen of Design:

"Ubiq’s law of scripting: Programmers always say, “No designer scripting!” This lasts until they see the production schedule."

I posted a comment about hybrid solutions which can frequently achieve many of the benefits of the individual solutions while minimizing the drawbacks.   Basically, I suggest using data driven systems run by engineer-developed code as much as possible, and when additional scripting/feature coding is needed either have a scripter supervised by an engineer (via tech design, consultation, and code review) implement it for simpler cases, or an engineer implement it for more complex cases.

This could allow the use of more efficient and less error prone data driven system in most cases, while allowing scripting (code reviewed by software engineers) when needed when a more expressive solution is required.

More detail after the jump.

I think we have two conflicting forces at work here:

1. Code, including scripting, can create more interesting and varied game features than a completely data driven system of a small amount of base code and lots of data for the system.  Code is naturally more expressive than data.  (On a more philosophical note, isn’t code just more expressive data?)
2. Scripting equals programming, and scripters frequently have less to no software engineering training, leading to more frequent performance, stability, expandability, and maintainability problems due to script code.

On a large MMO I’ve worked on with a very expressive scripting language, we’ve seen both forces occur: incredibly interesting and appealing game features creating by scripting, and also horrible script code that causes performance, stability, expandability, and maintainability problems.

In my experience, hybrid solutions to problems like these can frequently achieve many of the benefits while minimizing the drawbacks.  In this instance, I’d suggest:

1. Make as many systems as data driven as possible to reduce the chance of script code problems (since more of the game content will be easier-to-get-right data rather than harder-to-get-right code).  This also has efficiency benefits, in that data is usually easier and faster to create than script code and more people are capable of creating the data.  A software engineer should create the base code that drives the data-driven system, and the designers can create the data that drives the system.
2. Use scripting for features that don’t fit the above criteria.  Example: one-offs that need more logic than allowed by the data-driven system, and/or where creating a data-driven system would not be an efficient use of time because very little data would be created making use of the system.
3. Try to limit scripting by non-engineers to simple scripts in an effort to reduce the chances of problems.  More complex scripts and systems should be written by engineers. 
4. Have software engineers code review all scripting code written by non-engineers before check-in (including the scripter making code changes recommended by the engineers).  This will increase quality of the script code, and also increase the engineering skills of the scripters.
5. If a scripter does end up implementing a more complex system in script, at minimum the scripter should work with an engineer at the beginning feature’s work on a tech design, consult with the engineer during the implementation, and do a code review as discussed above.

This could allow the use of more efficient and less error prone data in most cases, while allowing scripting (code reviewed by software engineers) when needed.

This isn’t to say software engineers are immune from creating horrible code too, or that some scripters don’t have the programming talent to become good programmers after training in software engineering, algorithms and data structures, complexity theory, etc.  🙂 

I’ve also met a few programmer/designers in the industry with both skill sets, and they’ve created some awesome game features.  However, as the industry has matured and companies enforce the designer/engineer split, I’ve seen many of these designer/engineers forced to go one route (usually engineering because the pay and job security tends to be better).

I also look forward to a time when we have fast-enough high level languages with a common ABI and enough available common code (licensed and open source) so we don’t need to use separate scripting languages.  I think "scripts" could be written in the same high level language compiled to the same byte code, and we wouldn’t need to use scripting languages and create and maintain all the nasty glue code connecting different languages with different object models, libraries, memory management, etc. with the resulting maintainability and debugging problems we have now.