loonygames
a blue's news publication

<< Back to Normal View

URL: http://www.loonygames.com/content/2.3/btc/

 

Vol. 2, Issue 3
November 25, 1999
Behind the Curtain:

We don’t need no steenkin’ technical design!

by Matt "Thraka" Gilbert

Hello 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.

 

<<Back to Normal View

loonygames - the best damn gaming magazine online

Credits: Print CGI is © 2000 Square Eight. Used with permission. Article is © 2000 its original author. All other content is © 2000 loonyboi productions. Unauthorized reproduction is prohibited. You got that??