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++.
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:
Productivity decreases steadily while crunching to a point where there’s a net loss, usually after a few months of heavy overtime.
When scripts are technically challenging, they become much harder to implement when working long hours.
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?
