Vol.
2, Issue 1
November 11, 1999
Behind
the Curtain:
In the Beginning...
by
Matt "Thraka"
Gilbert
ell,
well, well, welcome back! Enjoy your vacation? You can bet, I
did. Yes, if you have been paying attention, you can also predict
where I went. No, I didnt win. Thats not what Vegas
is about, man.
Hot
Wheels is on the shelves, for PlayStation and Nintendo 64.
The team has gone its separate ways, and I, with a new team and
a new console, begin the process again, determined to make fewer
mistakes, and a better product than last time.
One thing
that you get used to in this biz, is looking back on the last
project and saying to yourself, Well, I really botched that
one, so how can I avoid it this time? It is so common, in
fact, that many companies, Stormfront
included, have an official post mortem meeting, where the team
discusses what they felt were the biggest problems, and how they
might have been prevented.
Logically,
you would expect me the talk about post mortems, right? Well,
it will have to wait, because, in fitting with launching Volume
2 of loonygames, I want to talk about launching a project. And
thinking of where you screwed up the last time is probably the
best thing you can do to get off on the right foot for a new one.
So this time, lets talk about, in general terms, what the
beginning is like, and we will go into specifics about the stages
in the coming weeks.
In
the beginning...
I have
this irrational belief that somehow, if you plan well enough,
you can avoid all the pitfalls that inevitably plague development
of a project. It sounds good, on paper; hey, well just line
everything up, and then it will fall into place. Of course, the
reality is that it never works quite that way. People change their
minds. Things you thought would work turn out to be not so easy
in practice as in theory. You cant plan for everything.
But one thing is certain: you can make it a lot better than if
you go into it by the seat of your pants.
Aside
from actually swinging a deal with a publisher, the biggest issue
that has to be addressed at the beginning is the technology and
the hardware you will be working with. They go hand in hand, really.
You can have the best technology in the world, but your hardware
will limit just how much of it you can implement. Likewise, you
can have the most incredible raw pixel pushing hardware, but if
your technology is not up to the task of driving it, you end up
with yesterdays game on tomorrows machine. Ideally,
you will have enough time to really explore the limits of the
hardware, and modify or create the technology to fully exploit
the consoles capabilities. Most likely, you will also have
a list from the designers of features that they feel are imperative.
What you wind up with, when all is said and done, is what I refer
to as a virtual machine, a combination of hardware and technology
that can perform a specific set of functions.
As an
example, for a modern game, we would want a virtual machine that
could display a 3D world, render dynamic objects within it, process
animation, display 2D overlays, play sounds, display full motion
video, and a variety of other things. You will also know the precise
format of the data that you have to feed to the virtual machine:
perhaps it accepts raw PCM data for sound effects, or MPEGs for
FMV, or BMPs for graphics. More often than not, due to hardware
peculiarities, you will in fact have established your own formats
that you feel are optimal for the platform. On occasion, for things
like sound or fmv, you will be using software provided by the
hardware manufacturer, and the format will be dictated for you.
Once this
information is available, it will be formally detailed in what
is known as a Technical Design Document, or TDD. Depending on
the shop, and the time available, the TDD may be complete before
the Game Design Document, or GDD, begins. In most cases, though,
time is short, and the GDD and TDD are created in tandem. The
technical staff gives preliminary specs on their virtual machine
to the game design staff, and both teams begin work on their specific
documents.
Some houses
may have people dedicated specifically to design, but in most
places, the design team consists of a mix of producers, artists,
and programmers, along with representatives of the publisher.
This ensures that the design of the game doesnt become more
ambitious than the technical limitations can support, and that
it does not propose an unreasonable amount of artwork. In addition,
it makes sure that the people creating the code and art are cognizant
of the big picture, which will smooth the ride later down the
road.
Usually,
the creation of a TDD and GDD are specific milestones. Once they
are ready, they are usually presented formally to the publisher
in a meeting, where senior producers and technical people representing
the publisher will consider the documents, pose questions they
have, and ask for any changes or clarifications that they would
like. Once the documents are approved, actual production will
begin.
Next time:
The Technical Design: Just What the Hell Can We Do Here?
-
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.