Icarus Studios News

Writing a Great Game Design Document

Why Do You Even Need a Game Design Document?

Over the course of his or her career, a game designer will write thousands of pages of content. This content will be rewritten, resubmitted, used as alternatives to coasters or toilet paper, handed back with requests for even more revisions, and “lather, rinse, repeat” until a final draft is accepted. Some of these documents will include pitch ideas, request for information, concept documents, proposals, treatments, beat outlines of episodic content, industry white papers, sample scripts, mission write-ups, statements of work, templates for data entry, informal blog posts, and—here’s the big one—game design documents.

Game design documents written for external use are a bit like the standard manual booklet that comes with your subscription to an MMO, but in this case, it’s written for non-gaming executives who are considering licensing their properties to you or financing your game. These executives—otherwise known as producers—are sort of like your company’s Boss of Bosses. (At least, for that particular project. Your company’s owner is always the Owner of Owners.)

Now, all those other documents I mentioned? Those can be relatively vague and light, until you get a sense of what kind of experiences you’re supposed to craft. The game design document is not the time to be ambiguous. Like a pre-nuptial agreement, it’s all about hammering out the details before a formal commitment. Which isn’t to say it can’t be modified several times before you and your client tie the knot. But this is the document that goes back and forth for a bit until everyone irons out all the details.

At the very least, all game design documents should cover the bare-bones basics with the most important, nitty-gritty specifics. This includes the proposed title of the game, a table of contents, an executive summary (translation: list of goals and thesis statement), a description of game-play and art style, a brief overview of how awesome your toolsets are, and a quick bit of background about your company. These sections are pretty much mandatory. More than likely, all your preliminary research and internal documents have already covered this much by now, so you’ll probably have a template from which to work.

But wait, there’s more:

Good game design documents also include (usually under the description of game-play section) a few examples of main missions and side-quests. These can be written in various ways: first-person present tense I-novel format; omniscient third-person past-tense formal point-of-view; or a mixture of italicized thoughts and traditional prose, supplemented with pictures, graphs, and bullet-pointed boxes. Your leader will give you a sense of what approach is best.

For instance, if I’m designing a serious game with instructional tutorials and scored testing events for a major university, I’ll go with a more academic and formal-sounding document. I’ll probably also provide quantifiable statistics about how well students retain what they’ve learned thanks to participating in simulated training systems. But if I’m pitching the latest zombie-clowns vs. cloned-pirates shoot-’em-up FPS game to a major studio in Hollywood, I’ll use the auteur method, writing a sample of one user’s experience as he or she pretends to captain a ship and swash some zombie’s buckle. I also will be sure to subtly mention marketing, branding, and expansion possibilities for the franchise while I’m at it.

Later on, when contracts are signed, this game design document is used as a basis for a far more technical, internal document—a property bible, of sorts—which Art, Animation, Production, and any collaborative partners your clients wish to incorporate into the creation will need to read to understand what is expected of them and their departments. An internal game design document’s purpose is not to convince investors or IP holders of your capability as a gaming company. Rather, its purpose is to inspire creations and aid in scheduling production. Internal game design documents are very specific and will be subject to many revisions during the course of scripting, coding, and implementation. In most cases, it’s best to use an online wiki so that artists and programmers have constant and complete access to this giant tome ever-evolving information.

(Continued in Part 2)

-Kara Stambach, Virtual Worlds Team