Scripting: It's Not Just For Scripters Anymore

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.

Comments

[Raph]

I'm a big fan of scripting myself, but have recently seen a lot of folks desirous of having programmers do the scripting and not having designers do it. But for me a big part of the reason why you want designers to be doing it is because the programmers are less likely to aim for the fun factor in the scripts they implement.

Now, I'm speaking primarily from an MMO background, and there's no doubt my mud experience influences this, but I'd be curious to hear your take on it.

[Pat Lipo]

My first visit to your blog and I run into this great commentary on the value of a competent scripting language, Jamie!

It's really unfortunate that all too often scripting is considered a job for second-tier programmers or interns. Certainly, as a lead it’s sometimes the safest place to assign an untested recruit, but it’s easy to forget that scripting can be the last line of defense, the final step in making a game shine. It’s ultimately a very important position, even though I’ve seen more than one talented programmer shun it for “real coding”.

However, I’d have to agree with Raph also, experienced programmers aren’t always the best choice for scripting by any means. Many programmers unfortunately are at a complete loss when it comes to making a game fun, just as some designers have a really hard time writing solid script code. In the end the best people to write scripts may those rarer birds who can write (reasonably) good code and still have a keen eye for gameplay. These can come from either the tech or design pool.

[Jamie Fristrom]

I have two counter arguments to Raph's point:
- programmers at a game company almost always took the job because they're into games. I might agree that sometimes we have weird ideas about what 'fun' is, but we're still all about 'fun'. (Actually, I'm all about shipping on time, and then about fun...which may be why the missions I worked on aren't the best in the game...)
- Chris Hecker's article in Game Developer way back when that suggested that game design is programming. It's setting up rules and systems and discovering corner cases and boundary conditions and so on.
But that's theory. Raph's experience is experience. So I'm going to have to agree: don't replace your pure designers with a team of coder-designers. Still, mixing them in is a viable option.

[Raph]

Well, perhaps I should caveat by saying that IMHO the best designers know how to code. And draw. And write. And worldbuild. And compose a screenshot. And play music. And...

So it's not so much an argument against coder-designers, as it is a question of whether the barriers to entry to becoming that sort of Renaissance-person are too high if the standard requires knowledge of Visual Studio.

The converse would also be true. Programmers who also happen to have design skill sets are not my worry. But I know plenty of game industry programmers who want to work on games and love games, but who aren't really designers. They are graphics people or AI people or whatever, and they want the game to be fun but don't necessarily know how to make that happen. And that was my concern really.

[Pat Lipo]

Apologies for butting in above there. This topic is near and dear, so I just got a bit over-enthusiastic. I do that. :-)

From your previous experiences, what fraction of a given programming staff would you say "gets" the intangible stuff of making a good game? Half? A quarter? A tenth? Obviously that all depends on your luck and company hiring practices, but then again that's why I'm curious.

[Pat Lipo]

I'll add the caveat that there's plenty of need for programmers that don't dig on the game-y stuff too. Some hardcore techies don't like doing "fun factor" because it can't be quantified...

[peterb]

Can you expand on your point number 3 a bit? I don't see anything intrinsic to those two code samples that says that the first one is representative of a compiled language and the second is representative of a scripting language. I think I'm missing your point there.

[Jamie Fristrom]

Point #3 wasn't a great example. My argument would be, no matter how you would implement something in C, you can design your scripting language to make it more elegant in script. CHUCK is designed so you don't have to write state machines to implement gameplay behavior - if you wrote the same code in-engine it would be polled once a frame, so you'd have to write state machines to describe the behavior, which is a pain. (Side note: Neverwinter Nights script doesn't do this, but it has different advantages over C.) A clever programmer will point out that you can use macros or multithreading or something-I've-never-of to let people write these non-state-machine scripts in C. But then you're being clever. "It's a fine line between clever and stupid." - Spinal Tap. Sorry. I consider most macro code I've looked at unreadable and ugly, and if often confuses the hell out of your debugger. Threads lead to heisenbugs. So that brings us back to script languages.

A couple more argments for scripting language:

Hinting at the lines between systems and instances, although you may have systems that are done completely in script.

Hinting at the lines between game engine and the actual iteration of the game you're going to ship; most of the script gets thrown away at the beginning of the next project.

Memory optimization: implementing a script language is usually easier than writing an overlay system for your C code.

Protection. This is part of point #1 - it's harder for a script programmer to dereference a garbage pointer, etc.

[Nathan McKenzie]

To back up what Jamie's saying (and because this is specifically the sort of stuff I work on, in part)...

It's REALLY convenient, when making game behavior, to be able to write code like this:

self.startAnim("Fury");
while(!self.animDone()){
waitFrame();
}
self.moveTo($enemy1_startPoint);
while(!self.atMoveDest()){
waitFrame();
}
... and so on.

It just seems to model what you're doing really, really well. Getting the same functionality out of true code would require multi-threading and all its side-effects.

[Factory]

"- Turnaround needs to be quick."
"- Garbage collection."
Strangely enough, modern languages (ie. ones made after the 70's will generally have these features, they are good for pretty much any language, not just stripting languages.

IMHO there should be no such thing as a scripting language, scripters should just work with a subset of the main language that is used to code the game, since most of that which makes a good scripting language also makes a good programming language in general, and vice-versa.
Where the needs of the the two domains diverge is that engine programmers need to be able to scale up to large codebases, with the requisite tools, and scripters need more DSL type functionality. I've yet to see any programming language that could span these two domains with a decent trade off though.

[shaver]

> Well, perhaps I should caveat by saying that IMHO the best designers know how to code.
> And draw. And write. And worldbuild. And compose a screenshot. And play music. And..."

Do you find the converse, as well? I suspect that better programmers also have interest or casual talent in other domains, but I'm biased, since I'm a programmer who has diverse interests in reading/activities/discussion. I'm curious to hear your thoughts, though.

[Martin Donlon]

My own opinion is that if programmers have to become scripters then something is wrong with your scripting environment. Either the scripting language itself is flawed or its interface with the rest of the engine is flawed.

[Badman]

Re: your scripting vs. code example from McShaffry's "Game Coding Complete", I think you were thinking of the example he gave in his process manager code, where you could code something like:

walk->then(openDoor)->then(drawSword)->then(goBerserk);

But while that's pretty clean and self-explanatory, it's still code, not script (I've no doubt such code could be script-controlled very easily, though).

PS: "Game Coding Complete" doesn't _quite_ live up to its title, but it's still the best single book on game programming I've ever read.