Who are You?

If you are an aspiring game designer, artist, or programmer, this is your ticket to better game development. Think of it as "Introduction to game development 101" for anyone looking to break into the industry. You will learn about the differences between the mysterious "Design Document"[sup]1[/sup] and the even more mysterious "Technical Document" that together comprises the road map for developing a game. If you are coming from a design, art or sound background, you might question the value of being familiar with "the technical details." Like all media forms, games have their own set of medium restrictions which influence design decisions. If you want your design, artwork, or sound contribution to be the best it can be, it is important to understand how your contribution translates into a working game. If you are coming from a programming background, the technical documentation is ultimately a reflection of the game design. It is essential to know how to map from the Design Document to the Technical Document, and what belongs in each. This is true even if you are not directly involved in the design, since you will be responsible for implementing the most important part - interaction!

This article was originally published to GameDev.net back in 2002. It was revised by the original author in 2008 and published in the book Design and Content Creation: A GameDev.net Collection, which is one of 4 books collecting both popular GameDev.net articles and new original content in print format.

Why Do Upfront Design?

Let's get some things straight - these days professionally developed games have multi-million dollar budgets. In some cases, hundreds of people work on a single game project over the course of years. Clearly, these people require a plan so they can work towards a common goal. The goal is usually to create a fun game, although considering some of the massively-hyped duds that have come out over the years, you can't help but wonder exactly what the goal was (or maybe, where the plan was.) That being said, upfront design isn't just for large teams of professionals! Aspiring game developers[sup]2[/sup] also benefit from the process and end result of having useful design and tech documents for their new game. If you have never thought about "game design" before, and if I haven't lost you yet, it's time to explain the title of this article. As you may already know, design documents are essential to any game. They tell you, and the other people working on the game (if there are any) what the game is about, what it will eventually be, and all the little details that define the game's "design". On the other hand, do you really need to plan the implementation of the graphics library in advance? Or make considerations for what platforms[sup]3[/sup] your game will be released on? You already know your main character is going to have a red hat. You can figure out how that will appear on the screen later, when you get there, right? Sure. In fact, many game developers do exactly that every day. Heck, you should see some of the MMORPG design documents that are out there on the web. 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 good working order, and only a handful from amateur sources. Well-done design (including technical) can save your project from being relegated to the "might have been cool" project category. It will ensure that your game actually gets finished, and somewhat resembles the original vision[sup]4[/sup].

What's This Game Design All About?

Let's quickly go over what "game design" is, just to be sure we are on the same page. We'll get started with GameDev.net's Game Dictionary definition of a "Design Document":

"A document that the designer creates which contains everything that a game should include. Sometimes referred to as a "design bible", this document should list every piece of art, sound, music, character, all the back story and plot that will be in the game. Basically, if the game is going to have it, it should be thoroughly documented in the design document so that the entire development team understands exactly what needs to be done and has a common point of reference."

Effectively, it is a description of how the game will look when finished, from the user's point of view. It's the end result, or the final goal of developing the game. Other articles in this book already cover game design in greater detail, so let us focus on what does not go into the design document. A Design Document is not the place to:

• Keep software requirements.
• Keep project milestones.
• Depict software architecture (that includes UML diagrams, with the possible exception of Use Cases).
• Describe specific art file formats, sound file formats... or any other file formats!
• Describe system requirements, or performance metrics.
• Describe game development processes (artwork pipeline, coding standards, etc.).

To summarize, a Design Document is not the place to have detailed information on how the game will be implemented. That's what technical documentation is for. The reason? To keep the concepts separate. Also, while game design is subject to (often a great deal of) change during the development phase, the design document should keep pace. That means that, regardless of the state of the technical status of the project, you always know what the end result should be. Games often change target platforms, or need to be developed for new platforms. With radically different platforms, the game project's technical documentation might be completely different. In fact, these days, it's not surprising to see separate companies working on the same game for different platforms. For example, Lucas Art's upcoming game The Force Unleashed is being developed by multiple companies for several difference console systems. On the other hand, the design will remain the same for the most part, usually only changing to account for different control schemes, and possibly different levels of audio/visual fidelity. So you save time by keeping them separate and up-to-date.

'Tech' From 'Design Document', Huh?

Up until this point, I really haven't discussed why you need to have a technical document. Clearly you could start developing artwork, sounds, and music for your game with just a design document. Maybe start hacking out code for one (or more) of the platforms you intend to run the game on. Unfortunately this is a simple recipe for disaster. One of the problems with starting production on a game without a detailed technical overview of how the game will come into being is like driving to a city you know, but not knowing where you are starting from, and having no map to direct you to your final destination. Basically, the design document describes the "place" you want to be at some point in the future. It's what you expect to be able to see, hear and touch when you arrive. However, you need to know how to get to that place. You need to know where you are starting from. That's where the technical documentation comes into play. It describes how you will get there - all the tools you need, and all the directions. Everything you need for how to get your game done. 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 concise definition, it teaches you little, if anything. Also, it is a very-software centric view of game development. These days, most teams have more artists then programmers, and they can often have very technical roles in the project as well. With that in mind, here is a simple checklist for getting you started on your own technical documentation: A Technical Document is the place to:

• Write the requirements. Typically software requirements - but it's good place to write requirements for artwork, music and sound development too.
• Write which platforms the game will run on, and the specific details for each platform. Specifying clearly what (if anything) will be different on the platforms is important!
• Describe how art, sound, and other game assets will be managed and put into the game, as well as the process for converting from standard media formats to game-specific formats.
• List file types, data layout, etc. If you intended to have your own image, sound, map formats, etc. this is the place to document them.
• List projected system requirements (usually only applies to PC/Mac games).
• List all the technologies the game uses, and (ideally) how the game benefits from them. This includes software tools, licensed artwork, etc.
• Describe the system architecture (usually thought of as software architecture).
• Give considerations to future additions, and "what ifs". Doing this right will help you avoid boxing yourself into a corner with a rigid design/development process.
• Specify documentation conventions such as coding conventions, artwork format requirements, etc.

That's a good starting list, but by no means complete. What you actually need to cover will vary, but generally the larger and more complex the project, and/or the more people involved, the more important it is to describe as much as possible in detail. Now that we've cleared up both what a design document is and what a technical document is, I think it's time we had a look at an example of a technical design document.

MMORPG? No. 3D Shooter? No. Tic-Tac-Toe? You must be kidding...

Unfortunately I'm not. Unless you're a documentation fanatic, a technical document for a program as small as a tic-tac-toe game may be overkill, but it's an easy example to work with. And, hey, we'll try to spruce it up a bit as we go. More importantly, I'm going to give you a major heads up. Technical documents may or may not contain information that covers the same areas. That is to say that if one technical document describes a MMORPG, and another describes tic-tac-toe, they will not and should not try to cover the same areas. It is not a simple question of page numbers either. What they contain will be significantly different, and reflect the different challenges in each - or lack thereof. With that in mind, I am not going to suggest that you memorize some arcane template for a technical document. Although you might benefit from something like that, for the wrong game project, you could end up wasting all sorts of time considering things that just do not matter. Likewise, you could ignore important considerations - probably much more of a concern then over-compensating. So, when you ask yourself if you have considered and documented enough yet, keep this in mind: The goal is to develop technical documentation that lets you meet the goals of the design document - nothing more, nothing less. Okay, the following example doesn't try to fill in all the details (yes, even for a tic-tac-toe game), but it gives you an idea of how you can take apart the concept and use it for your own work. SUPER+AWESOME TIC-TAC-TOE Technical Document Table of Contents

1. Introduction 2. Requirements 3. Development Process Overview 4. Software Architecture Overview 5. ... 13. Future Considerations

1. Introduction This document describes the overall technical description of Super+Awesome Tic-Tac-Toe. Based on the game design document, the platform we are targeting (Windows PC), and the resources dedicated to the project, we will (etc...) 2. Requirements [Sample of high-level requirements]:

1. The program must be able to run on any Windows XP/Vista based system. 2. The program must not depend on any code libraries, other than those included with the OS itself. 3. It should be controlled exclusively by the mouse. No other input device should be required. That means we can't plan on having the player use a keyboard. 4. Each of the two players can interact with the game board on screen during their turn only, using the mouse.

(etc...) 3. Development Process Overview: The development process will be fluid, using an iterative agile software development method. Even with an agile approach, we will try to do as much upfront design and documentation as possible. We will use Test-Driven-Development during software development... (etc...) 4. Overview Of Software Architecture: The game will be written for the Windows platform, using C++, and making use of the default Win32 platform functionality. We considered using DirectX, but it is simply not necessary to meet the game's graphical/sound requirements based on the provided design, so we choose not to make use of it. Due to the simplicity of the project, the overall software architecture will effectively be a default implementation of the standard model-view-controller software architecture pattern. (etc...) 13. Future Considerations Some of the things that were brought up during design for consideration for the next version of Super+Awesome Tic-Tac-Toe were: 1. Supporting multi-player over the Internet. [nbsp][nbsp][nbsp][nbsp]We discussed the ways our current design could accommodate for this in a future version and decided that we could adapt the design to use a new Controller without changing the other parts of the system ... (etc...)

Conclusion

The ultimate goal here was to stimulate your thoughts on how game design and technical design fit into the overall game development process. If you are working on some of your first game projects, the important message to takeaway is that planning and documentation are important for all the reasons outlined here - platform requirements, design reuse, communication, and most importantly, working towards a common goal as a team. [sup]1[/sup]In most development studios a Game Design consists of many documents. The same applies for Technical Documentation. I'll keep referring to them as single document just to make things a little more readable [sup]2[/sup]I will just use "game developer" to refer to all the people involved in game development...like designers, artists, programmers, level designers, sound editors, script editors, producers, quality assurance people, etc [sup]3[/sup]Even amateur developers are releasing their games on multiple platforms these days, and it's practically a requirement for full-on commercial titles. [sup]4[/sup]A vision, which more often than not, starts life on the back of a cocktail napkin.