3 Ways to Avoid Scripting Nightmares in Your Game

Alex J. Champandard on August 7, 2007

Scripting support in a game (for AI, gameplay, or level scripting) always starts off as a good idea; everyone wants a data-driven engine that empowers the designers. Yet somehow it almost always turns out to be a big mess — sometimes worse than something implemented in plain C++.

Scripting Nightmares

The problem is that scripting is too complicated for a majority of people on the team, but yet somehow, almost everyone ends up joining in. And that’s where the problems start…

Looking at how other big studios avoid these nightmares can help you make better informed decisions.

1) Take More Time!

This is the most typical approach in the games industry: either delay your release, or get all your content creators to crunch… maybe even both! (From working at Rockstar, this approach is certainly familiar. :)

Obviously, there are many problems with this approach:

  1. Productivity decreases steadily while crunching to a point where there’s a net loss, usually after a few months of heavy overtime.

  2. When scripts are technically challenging, they become much harder to implement when working long hours.

  3. Finally, whole studios burn out after a game, and you end up with a high staff turnover, traditional for the games industry.

So there must be a better solution…

2) Hire Technical Minded People

This is the approach Electronic Arts uses by throwing money at the problem. Since scripting is not a trivial process, it makes sense to hire technical people with a degree in computer science.

Hiring programmers to do the scripting has a few advantages:

  • It’s a good way for junior programmers out of university to learn the trade by starting of with scripting.

  • It provides relatively cheap technically minded people to the task of making important or difficult scripts.

On the down side, it can be expensive, and it becomes as much of a challenge to manage the scripts as the engine itself (e.g. enforcing coding standards, revision control and versioning).

3) Build a Domain Specific Language

A smarter solution is to use a less flexible, but equally powerful language for scripting. Using a domain specific language, you expose to the designers only the functionality that’s required to add agreed features into the game. The advantage of this approach is that there’s less rope for scripters to hang themselves.

There are two ways of doing this:

  • Use a language built for extensibility and creating domain specific languages, such as Scheme or Forth. Sadly, not that many people are comfortable with these languages.

  • Alternatively, you can try to use Lua or Python instead by providing a clean and simple API. However, you’ll need additional tools to check and enforce usage of this API as a domain specific language.

In a sense, behavior trees and finite state machines are domain specific languages too. Although they tend to be geared towards AI rather than scripting in general, they can be easily edited visually using simple user interfaces.

What techniques do you use to prevent scripting nightmares?

Discussion 5 Comments

Andrew on August 7th, 2007

Hey, I thought that many companies simply have dedicated (or partially dedicated) AI programmers - who allow level designers and normal designers to adjust some behaviour but usually keep the scripting AI creation side to themselves. Since scripting has more benefits then just being "data driven" I think its missing a vital point; its easier to debug due to it being VM driven (error logs reporting line number failures, save states will save the running scripts, etc), will not crash the engine if it fails at some point, and can be edited (usually) without compilation so testing is faster, and modifications can be more easily made without having to rebuild the engine just to add a unit (more common in RTS and similar games with the concept of "units") I am interested to what you might think a "clean, simple API" is. Is Oblivions AI editor in their toolset one? (its cumbersome, undocumented, and very poor control-wise IMO). If you say AI should be a "domain specific language" (what is that by the way?), then what controls are designers allowed?

alexjc on August 8th, 2007

Great questions Andrew. [B]1.[/B] There is certainly a separation between AI scripts and level scripts, but when you start making heavily story-driven games, this distinction collapses. Many behaviors are one-off, and need to be scripted with the levels... and that tends not to be done by programmers. [B]2.[/B] For AI scripting, you're right, it's typically more of a programmer's job, but all the companies I've been in so far have involved the designers too. I guess it's a matter of choosing a team-structure and workflow, as I describe in the article. [B]3.[/B] The benefits of scripting beyond data-driven + fast turn around times are greatly exaggerated. It takes a lot of work to make a debugger that's better than Visual Studio. I've no idea how long it took Blizzard to make Lua that robust in WoW, but from experience I presume we're talking many man years. Also, you can make very reliable non-data driven scripts just using sensible C++ practices. [B]4.[/B] I'm not aware of Oblivion's SDK, but for AI, a DSL could be a simple FSM editor, or just a bunch of statements like this:

    (location 10 0 5)
    (location 30 5 20))
It's domain specific because it only exposes what the engine supports, in this case patrolling around points.

I hope that clarifies a few things!  Again, nice comment :-)


gware on August 8th, 2007

After few titles, I still see what Alex calls "scripting nightmare". It's not easier to debug because it is embed and the only output you get is on the only "hardcoded" in the scripts (which of course are not visible if the vm crashes or something prevents it from correctly updating), it can crash the whole engine due various reasons (from platform specific optimizations to object synchronisation), it can be a pain to optimize if you are short on anything ;) Anyway, I'm still a scripting fan ... For DSL, see : Ruby has been used for various DSL (I believe the most known is Rake , Ruby's building system). Check it out ;)

Andrew on August 8th, 2007

Okay, thanks a lot for the information guys, interesting stuff.

alexjc on September 21st, 2007

Matthias, You're absolutely right. Those extensible languages are perfect. But their reception in the games industry is very bad. Naughty Dog had an amazing lisp/scheme solution, but it got dropped when Sony bought them. Likewise, I tried to introduce Scheme in my last company but it didn't fly for similar reasons. It's a shame, most AI engines end up being "informally-specified bug-ridden slow implementation of half of Common Lisp" — as Philip Greenspun would put it. Alex P.S. Sorry for the long delay in the reply, but thanks for the comment!

If you'd like to add a comment or question on this page, simply log-in to the site. You can create an account from the sign-up page if necessary... It takes less than a minute!