loonygames
a blue's news publication

<< Back to Normal View

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

 

Vol. 2, Issue 1
November 11, 1999
Behind the Curtain:

In the Beginning...

by Matt "Thraka" Gilbert

Well, 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 didn’t win. That’s 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, let’s 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, we’ll 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 can’t 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 yesterday’s game on tomorrow’s 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 console’s 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 doesn’t 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.

 

<<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??