Poor Tools Make Us Shoddy Craftsmen

GDC, as is to be expected, was excellent. I'm still catching up, both on things missed while I was away and processing everything I took in at GDC (also why I wasn't able to post anything last week). I imagine the next several posts will be inspired by talks seen or conversations had. This being the first is more nuts & bolts, but I think it's a very important issue that's often overlooked.

On the first day of GDC, as part of the Indie Games Summit, Slick Entertainment gave a talk about the creation of their XBLA racer Scrap Metal. Scrap Metal is reminiscent of old R.C. racers like R.C. Pro-Am or Blizzard's (yes, that Blizzard) Rock N' Roll Racing. Slick Entertainment is actually just two guys here in Vancouver and they built the entire game, soup to nuts, themselves. The only outsourced content was the music and a small amount of 2D art. They're great guys and you should click on this link and try out the demo, at least.

The focus on their talk was exactly how the hell only two guys were able to build this game. One objective they mentioned as contributing to their success was building all their tools to support quick changes and iteration. A game like an R.C. racer lives or dies by how good it feels to control and to get that right, there are a lot of variables that need adjusting. Slick built their tools to expose all of these values and allow them to be tuned live as the game was running. Adjusting something like a vehicle's suspension can instantly be felt and tweaked until it's right. Similarly, pathfinding on the tracks for AI cars can be adjusted live as the AI drives that track.

Kees Rijnen (Slick's art half) made a very salient observation during the talk. He said that previously, without the ability to live tune values, he would subconsciously find excuses to avoid all the export unpleasantness necessary for a single small change. Upon hearing this, I realized that I have absolutely done the same thing in the past.

For most games, changing a value means: make the change to the data, compile the change, load up the game (including waiting for all the loading screens), restore the state (load a save game, debug checkpoints, etc.) and test the value again. A change that should take two seconds ends up taking five or ten minutes. And you have to remember how the original value felt to compare against the change. Despite best intentions, it's difficult to justify (and tolerate) more than a few spins of this cycle.

And that presumes you can make the change yourself. If a designer or artist has to get a programmer to change some value, there's only so many times you feel okay asking them to tweak and submit a change. Eventually it gets to the point where it seems close, but feeling bad about continuing to bug someone else outweighs getting it that last 10% of the way there. In an interview about the process of making God of War III, producer Steve Caterson discusses how important it was for them to build tools that empowered designers. It's the first question on this page, but I'd actually recommend reading the entire article. I usually don't expect much from conversations about huge blockbuster games like GoW, but this one was actually surprisingly good.

Slick said, "Polish = Iteration + Focus." By decoupling their data to minimize exporting, they said their polish actually became fun, not to mention efficient. I think many projects would benefit from finding a way to similarly decouple their tunable data. It's easy to get used to the status quo, but it's important to revisit old assumptions. It is fine to be wrong (another GDC theme I'll touch on later) and recognize data that appears to be relatively static is actually being adjusted frequently. Even if they don't realize it, the cost of adjusting this data is likely quite significant. The time taken finding a way to enable making faster changes will almost certainly be drowned out by the efficiency and polish gains that will be earned.

"A shoddy craftsman blames his tools" may be the idiom, but for physical craftsmanship, a hammer really is just a hammer. In game development, some of our tools feel like hammers that only work between 7:14 and 9:46 PM when the barometric pressure is below 101.4 kPa. And only when held at a 37-degree angle.

We can talk forever about the importance of iteration, but to actually reap the benefits of heavily iterative game production, the ability to iterate has to exist on both a macro and micro level. Having a high-level process that supports prototyping and testing matters little when actually executing on those prototypes isn't similarly efficient.

I had recognized this in an amorphous way previously, but Nick and Kees' talk really crystallized this for me. They have my thanks for that, and I remain profoundly impressed that just two guys accomplished what they did with Scrap Metal. That their tools so completely support iteration and polish is envious and something I (and others) hopefully can emulate on future projects. I can't help but wonder what other barriers to iteration remain unchallenged and what we can do to tear them down.