Features

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.

	Microsoft Project - "the only game in town"?

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:

• Characters. Eventually this level's going to have dragon-men instead of bungie-men, but bungie-men have already been modeled. Copy the bungie-men assets to make placeholder dragon-men assets, and use that. You won't be able to playtest until the dragon-men are modeled, animated, and given brains, but at least you can work.
  
  
• Props. There's a briefcase handoff. There's a bomb under the table. If you don't have an asset you can copy, you can probably get somebody to spend half an hour modeling you a box that says "Bomb" on the side.
  
  
• Levels. Although you need to have something to put your gameplay in, nobody said it had to be finished. A blocked-out level may be just fine for spawning bad guys in and testing your character's platforming gameplay.
  
  
• Textures. We like to stamp the word "PLACEHOLDER" on our placeholder textures, so angry executives don't ring us up and ask us why our game looks crappy. (Another, more obscure problem occurs when we replace the placeholder texture with the final one, and those same executives rave: "We liked the old one better!" For some reason, this is a more pernicious problem with textures than with other kinds of placeholder assets.)
  
  
• Voice-over. This is a tricky one. Animators like to animate their cut-scenes after the VO has been recorded, so they can make the animation match. When I talk about the animation 'matching', I'm not talking about lip syncing, which is automatic, but facial expressions and gestures. That's how they do it at the feature length animation houses, after all. But this does create a dependency, and on one of the games I worked on, it meant that scriptwriting -> script-approval -> voice recording -> animating was the critical path. - Another option (though this is just a suggestion, and we haven't actually tried it) would be to animate to placeholder voice, and then have those expensive actors come in and do ADR (that's Automated Dialog Replacement). Quality will suffer, sure - but if it's your critical path, it's a choice between this possible quality hit, or the quality hit from having your animators crank out 60 minutes of animation in the last month of your project.

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.

join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2003 CMP Media LLC

privacy policy | terms of service