Remember when I said that I was only going to present techniques we used to ship games? I lied. We tried a new technique recently, and we haven't shipped a game with it yet, and it has caused some problems, but I'm not ready to give up on it yet, because it's about fundamentally improving your development processes; it's about asking "What's the right thing to do?" instead of, "Are we doing things right?"

We got the idea from reading The Goal by Eliyahu M. Goldratt. Like most management books, there's a very low ratio of actual information to word-count in this book. It's a novel about a poorly run machine shop, and the guys realized they had a bottleneck process, and dealt with it. The idea of optimizing bottleneck functions appealed to the coder in me, of course.

In the novel, in order to work around bottleneck processes, they did these things:

• they made sure to always keep the bottleneck process fed
• once the bottleneck process was always being fed, they made sure not to over-feed it
• they did what they could to expand the bottleneck, until some other process became the bottleneck

You can consider game development to be a lot like a machine shop. We have a bunch of assets: models, textures, components, features. These get built and passed on to the next stage, assembled, and finally tested. During your full production phase, you could apply Eliyahu's technique to your shop.

The first question is: how do you identify the bottleneck?

Well, there's the non-scientific way: ask which process everyone is complaining about. With Spider-Man 1, it was level scripting. "What's taking so long? What's taking so long?" This wasn't necessarily pejorative (although the scripters certainly felt it was). It may just be a fact of life that scripting missions and tweaking them until they're "fun" is a massive time-sink.

So once you've identified a bottleneck, what do you do?

Keep them fed: in our example, mission designers need levels and characters and tools and features to work with, but the models don't need to be textured, and the tools don't need to be perfect. They just need to be usable.

Expand the bottleneck: in our case, we did this in two ways. We hired more designers, and we improved their tools (yes, those same tools that I just said didn't need to be perfect) to make their jobs easier. I even acted as a temporary mission designer to increase the bandwidth and see if there were any other ways we could improve the process.

We quickly found it was impossible to keep the designers busy with work, and we found ourselves with a lot of missions built up from placeholder elements that were far from being in a shippable state. This matches what happened in The Goal: once they expanded a bottleneck by running the machine double-shifts, they discovered that it would sometimes run idle. They solved this by "red tagging" items that needed to be processed by the machine, and those became highest priority. Similarly, we started expediting any assets that the designers needed.

Still, designers were no longer the bottleneck, if they ever were, which some doubted. Which brings us to the more "scientific" method of identifying a bottleneck, which is to look at inventory. If there's a big pile of inventory waiting to be processed in front of some stage -- for example, if you've got a big pile of character concept art piled up in front of your character modeler -- you can assume that that guy is a bottleneck. Again, this isn't pejorative; it may just be a fact of life that making concept art goes quicker than modeling and weighting characters.

I've talked to other teams about their bottlenecks and one interesting response I got was testing. On one team, every system they code goes through their testing department; quickly their testing department became overloaded. My feeling is that a lot of us would be overloading our testing departments if we attempted to test our games with the same kind of rigor that those guys do.

The most frequent response I got, though, is that a factory-model of production doesn't really apply to the world of game development, where things come in stages, and traditional project management is more appropriate. If you're one of those shops that actually has the discipline to completely design your game on paper, and then build the elements specified in the design, and then combine the elements into levels and missions, then, yes, the factory-model of production could work. But a production model like that doesn't actually make much sense; it implies that artists and coders are idle while designers finish designing, and then level builders are idle while people are making props and features, and then everybody else is idle while the designers populate levels with stuff. It's better to build things piecemeal; break the game down into chunks, do concept and design for each chunk separately, and then run it through the factory. And if you're doing that, you can benefit from finding and expanding bottlenecks.