While browsing Spolsky's site looking for references for my previous article I rediscovered this, which I think has been lurking in my subconscious for a long time. Here's a quote:
What I wondered was, what happens if you take top-notch C++ programmers who dream in pointers, and let them code in VB. What I discovered at Fog Creek was that they become super-efficient coding machines.
I think that was part of the reason I turned in my technical director badge to become a scripter: the idea that I could get a lot of stuff done. And, since then, I have gotten a lot of stuff done. (Although not as much as I hoped.)
The typical argument for having a script language in your game is, I think, that you can then take these second-tier programmers, the kind that do not understand pointers, and pay them dirt to make a game for you. You've widened the pool from which you can draw warm bodies.
This ends in tears. We've found that we end up firing a large fraction of these second-tier programmers because they're not productive enough. And I suspect that the ones who are productive enough have what it takes to become first-tier and just don't realize it.
I have better arguments for having a script language:
1) A script language makes people more efficient.
To make people more efficient, the script language should have these features, more or less in order of value:
- Turnaround needs to be quick. Compilation time should be seconds and ideally you could recompile a script while the game is still running, restart your mission, and see the results of your change immediately. Try doing that in C.
- A debugger. I'd rather work in C with a debugger than in Basic without one. Still, the debugger takes a while to get online. We had our script language for years before we finally managed to get the time and money to write a debugger for it. Now that we've got it we don't know how we lived without it.
- Garbage collection. We could make people remember to deallocate the entities they spawn...but why? Another quote from the article:
The only thing that improves your programming productivity is using managed code - that is, using a language in which memory management is automatic.
- Strike a compromise between robust and brittle. Allow stupid mistakes like forgetting to initialize variables - initialize variables for people. I've been tempted to punish people for forgetting to initialize variables, but that's just my anal retentive C background. C is the only high level language I can think of that punishes you for not initializing variables.
2) A script language is easy to get up and running quickly, allowing you to prototype gameplay early in a project. I'm assuming here the alternative is a visual tool that allows one to place enemies and triggers directly in a level; a tool even non-programmers can use. Tools like this can take years and cost millions of lives.
3) A script language lets you write clearer code, that more accurately expresses what's going on.
Clearer code? You ask. How?
What's more clear? (Sorry about the formatting. Too lazy to fix.)
On_process()
{
switch( my_thing )
{
case TALKING:
if( am_i_done_talking() )
my_thing = WALKING;
break;
case WALKING:
move_towards_destination();
break;
}
}
Or:process()
{
talk();
walk();
}(I think Mike McShaffry said something like this in Game Coding Complete but I can't find the reference.)
4) Precedence before reason. This is not a new idea. Games have had scripting languages for decades. The new idea is this:
Try hiring experienced C and C++ programmers to do your gameplay scripting, or at least mixing a few in with the pure scripters.
Side note: props to Chuck Tolman, who wrote our script language in the first place (later we named it CHUCK in his honor) and Bob Parkinson, who added a debugger and garbage collection and variable initialization and basically anything we've ever asked for.
Recent Comments