Removing The 'Tech' From 'Design Document'
Who are You?
If you're a programmer who has written at least one software title, and you have never written a technical document, this is your ticket to creating games faster. Yes, I said faster. And after all, aren't good game programmers all about speed?
This Isn't For My Benefit
Let's get some things straight, I've never worked on a blockbuster game title, so we're equal in experience there... well, maybe not. But I have worked commercially on a game before, and I know the pressures caused by having to meet deadlines (I'm positive I know why they call them deadlines now), getting paid, and adding features that were never mentioned six months ago.
I didn't write a technical document.
If I had, I know I would have completed the game in half the time. Oh, and like all good little programmers I created a design document with my employer (designer/creator). I even mentioned that we could use DirectDraw, but that was the extent of the technical design. (As a side note, take a look at how many game design articles are available online, including here at GameDev.net. Why aren't there any technical design articles?)
If you've never thought about using a technical document before, and if I haven't lost you yet, it's time to explain the title of this article. As you probably already know, design documents are essential to any game. You need to know what the game is about, what it will eventually be, and the design document exists for that purpose. On the other hand, do you really need to plan out how to implement the graphics library in advance? You already know Mario is going to have a red hat. You can figure out how that red really isn't Luigi's hat when you get there, right?
In fact, many game programmers do exactly that every day. Heck, you should see some of the MMORPG design documents that are out there. They are huge! But if you go to the creators and ask them for a technical document, they might look at you like you're speaking another language. Or (*cringe*) they might say that the technical document is included in the design document. Funny, there are only a few MMORPG's in working order. I wonder what happened to that 300 page design document Zeophytie posted last year…
'Tech' From 'Design Document', Huh?
Up until this point, I really haven't discussed why you need to have a technical document. (If you don't know what a technical document is, or even if you do, don't worry, I'll explain that in a moment.) I think I've made it clear that you can make a game without one, but that's bad practice if this article is trying to encourage you to write one, eh? What did happen to Zeophytie's MMORPG anyways?
I'll tell you what happened.
Zeophytie, being a veteran C/C++/ASM/VB/DirectX/OpenGL/MFC/Winsock programmer, knew how to write every functional piece of code he would need. And buttons to bottles, he did just that. Unfortunately, when he got done at 3am (all projects end at 3am, don't ask why ;-) he had a sudden realization: "How is any of this going to work together?" Even worse, he had just received the source files from his 4 other programming buddies 2 days before, and he realized that after reading them over, the text all looked like it was written in another language altogether.
I'm not sure I need to finish this story, because, well, there isn't much to tell. Zeophytie asked all the other programmers to modify their code (meaning a rewrite) while Zeophytie tried to make his own code work together. Needless to say, the team fell apart, and people went their separate ways. End of story.
360 Degrees The Other Way
I didn't write all of the preceding because I like to ramble. (Ignore any proof that may exist in the GameDev forms; it's an imposter poster, I assure you.) I wrote it because, even if you read this entire article, it's not going to make a difference unless you use the things you learn. So what's the solution?
YOU CAN DO IT
Open up a text editor. Heck open up your compiler if that makes you happy. Now look at the blankness. That's not a technical document.
This little exercise wasn't a good laugh at your expense. Rather, sometimes it's good to clarify what something isn't before trying to explain what something is.
Here's the definition of a technical document from GameDev.net's Game Dictionary:
"A specification for all of the programming algorithms, data, and the interfaces between the data and the algorithms."
Okay, while that's a great definition, it teaches you nothing. Here's what you NEED to know:
A Technical Document IS:
A Technical Document IS NOT:
Now that we've cleared up what a technical document is, and what it's not, I think it's time we had an example, eh?
Pong? No. 3D Shooter? No. Tic Tac Toe? You must be kidding…
Unfortunately I'm not. Although in the less fanatical sense a a technical document for program as small as a tic tac toe game may be overkill, it's an easy example to work with. More importantly, I'm going to give you a major heads up.
Technical documents not only don't need to look like each other, they probably shouldn't.
Considering the vast variety in games and the technology they use, I'm not going to have you memorize some arcane template for a technical document. Although you might benefit from from something like that, this isn't university, you're going to take what you learn here and apply it to the real world.
Okay, the following example doesn't try to fill in all the details (yes, even for a tic tac toe game), but it gives an idea of how you can take apart the concept and use it for your own work.
The "Note"s aren't part of the document, they just comment about the document.
TIC TAC TOE
Note: Simple eh? Your projects will require more then a point form outline, but that doesn't mean you can't KISS. (KISS - Keep It Simple Stupid.)
Overview Of Design:
The game will be written using a C++/WIN32 solution. It's will consist of a few small classes which define the entire game. The windows code will be in straight structured style, while the game module will be forged object orientated style. We considered using DirectX, but not all systems have the capacity or drivers, so the standard windows gdi drawing functions are the choice.
Project Break Down:
The project has a total of four files. Two header files, and two source files. One set will contain all game related code, and the other will contain all window specific code ( although the drawing and sound code will be encapsulated to some degree in the game code.)
(Same format as above…)
Note: Usually, each function would have a description of everything it does, but I'm assured as an experienced programmer you can do that yourself ;-()
In the future, the game might need the addition of an AI component. The class's ability to handle it's own input will allow us the addition of an AI component quite easily with out changing much of the existing code. (Note: Not there was much to begin with, but don't be too cynical =)
Conclusion… Is It Really Over Mommy?
Stop looking for more, there isn't any! Really though, if you thought this article was about forcing you into some narrow-minded view of how you should plan your games out, that wasn't my intent. I'm just (like any good Samaritan *wink, wink*) passing on some experience. My goal was to somewhat stimulate your thoughts in how you plan the technical aspects of your game projects. It doesn't really matter how you deal with technical planning...
AS LONG AS YOU DEAL WITH IT! (AND PROPERLY ;-)
Anywise, I've given enough trade secrets for one day.
Michael Sikora, at firstname.lastname@example.org.
©2001 Michael Sikora.