Manager In A Strange Land: Dependencies, Part One

So, I've been using Microsoft Project a lot lately. By "a lot", I mean eight hours a day for weeks. (You can insert a rant here about how it may be Microsoft's worst piece of software ever.) How valuable this exercise will be remains to be seen. But Project does seem to be the only game in town, and doing it has reminded me of a truth about project management: namely, that dependencies are bad.

By dependencies, I mean things like, "You can't start putting monsters in this level until the level is done being modeled," or: "You can't start modeling this level until the level-modeling tool has been finished,", or even: "You can't finish this level-modeling tool until you hire a tools programmer." Also, try certain other 'issues' like: "You can't animate this cutscene until you've recorded the voice-over," and: "You can't record the voice-over until the script has been approved," and, "You can't get the script approved if you haven't written it yet," and: "You can't write the script without a writer." Oh, and there's another kind of dependency that Project isn't so great at revealing: "Fred can't work on the spline reticulator until he's finished coding the matrix defibrillator."

These dependencies do a couple of things: firstly, people go idle while they're waiting for a different person's task that they're dependent on to finish. When people go idle, they're getting paid for doing nothing. Your bang for buck is decreasing. Often, you can find something else for them to work on in the meantime. Sometimes you can't. However, most of these dependencies are solvable. You can eliminate or minimize them. Here's how.

Placeholder Everything

One of the oldest tools in game development for eliminating a dependency is the placeholder asset. This is something film makers don't get to use: if a prop isn't ready for a scene, they can't film. Granted, if our prop isn't ready, we can't ship - that dependency will never be eliminated. But it's nice to know we can get useful work done in the meantime.

There's a right way and a wrong way to use placeholders. Let's take sounds, for example. You've just coded or scripted a feature where a badguy shoots a ray gun at the hero, and you need a sound before you playtest. There happens to be a sound similar to a raygun in your game already, when your hero runs into an electric fence, called "electric_fence_001.wav", so you just have your script use that sound file, and it's ready for playtest.

That's the wrong way. If you do it that way, when your sound engineer finally makes "ray_gun_001.wav", you have to go back into the script and change it. You've introduced a dependency between the sound engineer and you.

The right way is to copy the sound file, rename it (you get bonus points for asking the sound czar what the name should be - although this does introduce another small dependency, it's worth it so the sound guys can keep track of all the sound assets), and check it in. That's the sound file you use in your script. Then, the sound engineer can record the sound at their leisure, and it doesn't have to go back to you for the final pass.

Sounds aren't the only thing that can be placeholder. Here's a short list:

Beware Of Process

The more involved game development gets, the more we need rigorous processes to prevent screw-ups. We insert control gates and signing-off procedures to make sure Joe doesn't start building a level until we're happy with the original design, to make sure Fred doesn't use a placeholder sound with the wrong name, to make sure we don't put a character in the game that's going to be turned down later by the licensor, and so on. We make pipelines - flow charts describing the path an asset takes from being a twinkle in a designer's eye to an in-game element. The more steps these pipelines have, the more professional the documents describing them seem, but adding more steps creates more dependencies..

Of course, sometimes it's worth it to create those dependencies. Slowing down the project now to prevent chaos later is often a good thing. But more process isn't automatically better - it's a judgment call.

Coming next article: more kinds of dependencies, and what to do when you can't eliminate them. Stay tuned.