Contents  Introduction  Page 2  Page 3  Printable version  Discuss this article

'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

How?

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 place to write the requirements.
• A place to write an overview of how objects/functions/data interact.
• A place to specify coding conventions such as variable naming and commenting.
• A place to list all the technologies the game uses, and how the game benefits from them.
• A place to list all the classes/structures/variables, and what they are to contain.
• A place to list all the functions/routines and what they are to do.
• A place to list in what order modules will be written.
• A place to list file types, data layout, etc.
• A place to give considerations to future additions, and "what if"s.
• A place to list projected system requirements and dependencies.

A Technical Document IS NOT:

• A place to write the game's story.
• A place for source file comments, or worse, code. (Excluding example snippets/PDL)
• A place for describing how levels are played through.
• A place to develop characters.
• A place to plan marketing, or distributing.
• A place to think about how to get the game published, or attract investors.
• A place to discuss *mood*, *setting*, or any emotional quality.
• Most of all, a technical document is not a personal diary! You don't write about what your girlfriend said about those ugly blue shorts of yours! Gee-e-e-ezzz. (You'd think they'd get over taking you out in public by now…)

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?

Next : Tic Tac Toe