Vol.
2, Issue 3
November 25, 1999
Behind
the Curtain:
We don’t need no steenkin’ technical design!
by
Matt "Thraka"
Gilbert
ello
again, and welcome. Thanksgiving is almost upon us, so forgive
my brevity; I have a ton of work to get done if I want to enjoy
my holidays.
Before
you can build anything, you have to have some idea of what you’re
building. There is an aphorism that goes around programming circles
that goes something like this: “If builders built buildings
like programmers build software, the first woodpecker to come
along would destroy our entire civilization.” (No, I don’t
know who said it. I’m not sure anyone does. Nobody I asked
knew, either, but we’ve all heard it.)
Hyperbole,
sure, but not entirely unwarranted. There are plenty of people
who have the idea that you can just sit down and begin programming
‘the game’, and somehow, it will all come together.
In fact, not all that long ago, this used to be pretty much how
the industry thought things should work, too. And there was a
time when it did, frankly. When you only have 16k of ROM to work
with, you can afford to skip the organization, after all. If the
art format changed, you had the artist redo all eight frames of
animation for the one character you could display, and it was
no big deal.
But that
was then, and honestly, it didn’t work very well. Once more
than two people were involved, it just became a mess. Add to that
the volume of resources required by a modern game, which is rapidly
moving toward terabytes. It’s not hard to understand
that ‘redo the art’ is a phrase likely to inspire the
art and production staff to see that your life comes to a painful
end after the project ships.
So, imperative
number one is to communicate the capabilities of your system to
the art and design staff. Of course, how you arrive at this information
is the tough part. You consider what you believe the hardware
is capable of, and factor in the fact that it might be capable
of Feature A if it is not combined with Feature B. You have to
think about the fact that while ordinarily feature A will coexist
just fine with feature B, inevitably, someone will want to push
both features to their limits at the same time. Someone
else will also want a thousand Feature C’s in the same scene.
Finally, you have to factor in how much time you actually have
to implement the feature set. Feature A might be really cool,
but take a long time to implement; is it cool enough to put in
Feature A, and cut Feature B and C to make it happen? Does the
design team really want Feature A, or would they rather have the
other stuff? What features absolutely must be available
to the design team, and which can they live without?
Now that
you have this feature list, and have communicated some tentative
specs to the design staff, you come to imperative two: figure
out how to do it within the limited resources of the system, and
write down Da Plan.
Da Plan
consist of a breakdown of all the small tasks you feel it will
take to complete a given feature, and the amount of time you expect
each task to take. Here is where I inevitably screw up, and adding
up the task times shows that I think I can do the entire game
engine in one month. I can’t help it. Somehow, I always think
I am superman, and that nothing will go wrong, and that I have
a clear understanding of every fine point that will go into the
game.
Needless
to say, I am always wrong. So I go back and try to find
the spots where I have underestimated the time it will take to
do the job. It’s a multi-pass process, and the worst part
of it is that, inevitably, you get the feeling that you’re
artificially stretching out the tasks, like the old Scotty principle,
where Scotty confesses to multiplying his time estimates by a
factor of four to maintain his reputation as a miracle worker.
Don’t fall into this trap. The truth is that you are far
more likely to underestimate the time a task will take. Leave
yourself room to make mistakes, because they will happen. When
in doubt, be conservative and leave yourself some breathing room.
For every task that you overestimate, you are likely to have underestimated
another. Any slack you manage to pull out of the schedule during
the actual implementation, you will find a way to utilize. If
somehow you manage to pull it all off ahead of schedule, there
are still additional features, changes, etc., that someone will
want: I promise, you will never find yourself sitting idle, wondering
what to do.
Then you
wrap it up and tie a bow on it. You put it all down in a professional
looking package, and present it to the publisher’s technical
people, usually in a face to face meeting. You will be expected
to have answers for a variety of questions that they may have,
so it behooves you to prepare ahead of time with a list of things
that might be asked of you. The more questions you anticipate,
the better you will look, and the more confidence you will generate
with the publisher. And, especially in the early stages of a project,
when it is still cost effective for a publisher to pull the plug
on a project, it is imperative that you not look like you don’t
know what the hell you are doing.
Assuming
you did your job right, the publisher will green light the Technical
Design, and production will begin in earnest.
Next Time:
The Game Design
-
Matt 'Thraka' Gilbert is a console programmer, currently working
at StormFront Studios. These are his own ravings, and have nothing
whatsoever to do with his employer.
