Four Ways to Write Your Design Docs

By Tim Lang [05.05.09]

 When people find out I make games for a living, their first response is "coooool". The next question is almost always "So you program games, then?", to which I answer "no". Then comes the confusing explanation of what a game designer does. After being asked what a game designer does, my usual answer is, "I write documents that no one reads."

Yeah, it's a funny answer. And as any game designer will tell you, it frequently rings true. There's two big reasons for that -- besides that all the other game developers are lazy. Our documents are organized in a way that makes it difficult finding the pertinent information and designers tend to write way more than they need to.

The tools are the thing

Today, I'll take a look at the first reason: the tools. Like any good carpenter, good tools make the difference between a crappy product and something you'd actually feel good about selling. Most designers use a couple different tools for creating, editing and balancing game design documents.

These tools fall into a few categories:

Text editing is the primary tool. The text editor is what glues all the other design docs together. Microsoft Word is the most commonly used. It's on most systems, and is pretty easy to use. Text editing is what I'm going to be talking about, and showing you the alternatives to Microsoft Word, and the strengths and weaknesses of each method.


There are a few requirements for a text editing tool that game designers need. Otherwise, Notepad would do just fine. We need our editor to do a bunch of other crap though, so we've got to use something a little fancier.

So here's the list of requirements that I use to judge the appropriateness of any kind of text editor for designing games:

Ease of Access

This is how easy it is to get to the document and edit it. Some are only available in file folders (Word). Others are available and editable online (Wiki).

Importability of Excel

It doesn't have to be Excel specifically. As a designer, you're going to be creating a lot of tables of different times. Some will have auto calculated formulas. Others will have images and descriptions and specifications. How easy is it to get that data from a spreadsheet to a table in your primary design doc?

Importability of Images

Images are great. When used as a background, they help sell the design. When used in place of text (as often as you can!) they help teach the rest of your team exactly what you meant when you were designing your mechanic.

Ease of Editing

This is how easy it is to do your job. Do you have to learn a new language to program your text, or can you use a plain old WYSIWYG editor to input your data?

Source Protection

Possibly the most important requirement. How do you control access to editing, and old versions?

Gimme some of them tools!

So now I'm going to go into detail about four different methods of writing GDDs, including two that may seem unusual to you. I'm just going to talk about the different options and their strengths and weaknesses. If you were hoping for a decision on which one is the best, sorry! I won't be rating any of them. The good news is that if you read all the pros and cons, you'll probably be knowledgeable enough to make your own decision!


In a short time, Wiki is already taking the game design community by storm. Designers love it because it's web-based, it's searchable, and it keeps the document sizes small. What's not to love?

Well first off, you can't print your entire GDD very easily. There's basically two methods: Printing it out page by page, or use the built in include function ({{:pagename}} in media wiki). Including it is the way to go, but it still formats weird, and doesn't come out very well.

It also doesn't import tables very well (there are converters out there: and importing images is less than easy. (No drag and drop for you!) You also have to learn a new markup language to write all your wiki documents. Hope you like = and [, cause you'll be typing them a lot! I'm told there are WSYWIG editors out there, but I haven't seen any yet.



It's hard to say if the benefits outweigh the difficulties. We're currently using Wiki on Tech Deck Live. It's solved a lot of problems that plague many projects. On other games, programmers and artists would just come talk to the designers rather than read the design docs. We still get that here, but they usually come to talk to us with a wiki page in their hand.

Microsoft Word

Word is the thousand-pound gorilla of the game design document world. I'd estimate that 85-90% of all games in production right now still use Word. Why? Because it's on almost every machine. Because it's pretty easy to use. Because we all already know how to use it. It's a writing standard, and when standards get that much momentum, it's hard to change.

So why not use it? As we all know too well, GDDs can get massive. Common sizes for a full Game Design Document can reach into the hundreds of pages. Some can even go as high as a thousand pages. Loading that big of a document takes forever! Finding what you need in it is even worse, even with Word's search function.

Multiple people can't edit the same document at the same time. Like Wiki, you can include separate documents together into a single document, which makes things easier, but that single document is still gigantic! Word is the 1000-pound gorilla because that's how big the full GDD file is!



 Microsoft PowerPoint

I'm not sure if anyone is actually using PowerPoint to design games, which is a shame. I've been experimenting with it, and it's actually quite handy. Because it's designed for presentations, it's got most of the functions designers need built right into the program. It's got a fairly robust version of Excel built in for creating spreadsheets, charts, and graphs. It's totally easy to add images to it, and it's really easy to make the document look awesome. You can even embed videos and animations into it. How totally awesome is that?

There are some downsides though. To keep the thing from becoming unwieldy, you have to break out your designs into separate presentations. Storing all those and linking them together can be a pain.



Google Docs

Google docs is a relative newcomer in the field of design docs. Like PowerPoint, I don't know of any companies that actually use any of the Google Doc suite to write their design docs. It's definitely got some things going over Word however.

First, it's online, which means you can edit it from any computer with a network connection, and the files are stored remotely. This can be bad if the network connection goes down, but it's a lifesaver if your server closet burns down! It's also a suite of tools, including a presentation program, and a spreadsheet program. Both are functional, albeit a little harder to use than Excel or Power Point.

On the downside, the security of your files might be questionable, since the data has to travel through the internet to get to the actual location they're stored at. t's also not searchable outside the document (just like Word) so if you're looking for a specific line of text in a bunch of different files, Wiki's got all these others beat hands down.

It's WYSIWYG, but not quite as sophisticated as Word. I haven't used it for any kinds of lengthy or complicated documents, so I don't know how well it performs tasks like importing images or other formatting tasks that Word does with ease.



So that's about it!

That's the end of my overview of GDD tools. Hopefully I've given you some insight or alternatives to what you thought you HAD to use. All four of these have their strengths and weaknesses, but ultimately, if you're starting a project and are looking for design tools, you need to weigh these pros and cons and decide for yourself what works best for you and your team.

For those of you who are knee deep in your production already, what do you use? What do you like or hate about it?

Return to the web version of this article
Copyright © UBM TechWeb