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.
Microsoft
Project - "the only game in town"?
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.
