A game designer’s job is to work out the interactions and systems within a game. Depending on their skills a game designer has a wide variety of methods for solidifying ideas. Whether it be paper or digital prototypes, sketches, flow charts, and wire frames etc. once an idea is fleshed out and given form the game designer must then communicate their ideas to their team members and stake holders. The game design process varies from game to game, because the games themselves vary so much from one to another. Because of this there is no complete check list of required documents for every game. There are however a few that should be generated no matter what the project. I’ll list them below with a short explanation, who the audience is and why you should consider making one for each.
Game Brief
Description
A Game Brief is usually a one pager that gives an overview of the game. It shouldn't get to deep into the nitty gritty of the mechanics but rather give an overview of the over arching vision. Make it short and sweet, think of this document like the “back of the box” for your game and it should hit all of the same high points. What is the core concept? What genre does it fit into and perhaps who is the games target audience. What separates the game from others in the space? What are the game’s defining features?
Why make one?
Game Briefs are a great way to get something that is kicking around in your head out into paper. Writing your ideas down is a great way to solidify and crystalize the various thoughts that surround your game. You’ll be surprise how much your assumptions change once you commit to writing your ideas down on paper in an organized way.
Who is your audience?
Most often the Game Brief’s audience is your team members and it will be used as a discussion piece, so everyone on the team is on the same page as to your concept. It’s a great starting point for further idea development. It’s also possible you’ll write the brief with out knowing when you’ll actually make the game. If this is case, it might be beneficial for you to not just keep it locked away in your hard drive. Show it to people you trust and talk about the idea. You’ll find that given enough attention ideas grow and start taking on a life of their own. Click here to view a game brief template.
Game Design Doc
Description
This document is always a doozy. It is the central document that you write when you are acting as a game’s designer. The game design document will detail every aspect of your game, from player controls to scoring system, to level structure. because of it’s potential to become extremely massive and bloated, often parts or sections of the document will be broken off and written in a supporting document. For example, if a game requires an in depth tutorial I’ll write a separate document for the tutorial. When it comes to the part in the GDD where mention of the tutorial is required, I’ll refer to the other document. It’s also crucial that writing is kept succinct, GDDs often grow to over 50 or more pages depending on the scope of the game, in order to keep the document useful and manageable it’s important to say more with less. Also to this point, it’s important to keep the document well organized with major and minor section headings along with a table of contents. This keeps things easy to access for team members consuming the doc and easier for you to make changes as the game grows and evolves. Though, the more I work with google docs, the easier I find it to keep organized. I can make links between documents and can have multiple kinds of documents (spread sheets, slide show presentations, and writing documents) all in the same ecosystem. This is possible with traditional desktop tools as well, but I find it easier to manage and keep organized while using the docs service.
Finally, it’s important to note that the Game Design Document isn’t finished until the product is shipped (if you are making a social or web game that is more of a service then a shippable product then the GDD isn’t finished until the project runs it’s course!). A GDD is a living document, this is due to the interactive nature of games. The designer has to make certain assumptions about how things work. These assumptions are tested as elements of the game are built. Often you will discover that something you thought would work well doesn’t and must be tweaked, changed, or dropped completely. It’s imperative to keep the GDD up to date in the process otherwise the project can really become disorganized and come off the rails.
Here is a good template written by a game designer / developer named Mark Baldwin. Looking through this might be a good place to get started if you have to write a GDD of your own. I wouldn't fill this out to the letter, rahter, I'd read throguh it to get the gist of what's covered and to what level of detail.
(cut and paste this into your browser bar)
http://www-personal.engin.umd.umich.edu/~bmaxim/cis488/BaldwinGameDesignDocumentTemplate.doc
Why make one?
Game creation is very often a collaborative process and communication and clarity is of paramount importance. The game design document is meant to be a central reference for the decisions made about how things are supposed to work in the game. Because of the level of detail necessary to communicate that, it is often impossible to sit down and start writing the GDD straight off the bat. It’s okay to prove some of your assumptions with prototypes before writing anything but ultimately, those findings should be captured in the GDD. When you do sit down to write the document you’ll find that you are forced to really figure your game systems out to the final conclusion. It’s easy to spot ambiguities when an idea is in print.
Who is your audience?
In a word, everyone! Everyone will at least skim the GDD and most will treat it as a bible. Although you won’t necessarily mention details about the art style (often times there is an art bible or style guide for that) the GDD should mention art related aspects that are key to communicating game state and events to the player, for instance feedback, HUD configuration, and screen layouts. Programmers, or the developer team lead, will likely refer to the design document very regularly. The GDD holds the rules for the game and the programmers are the ones implementing them. Another reason to make sure you leave no ambiguities in your writing, make sure to keep honest with yourself on this point! Stake holders will often require a GDD. They will want to sign off on the document. Finally producers will be careful readers of the document. They will use it to make sure the game is within the scope of the budget and to make sure everything the stake holder wanted is represented in the document. The producer will also prioritize tasks and base schedules around the GDD’s contents. The producer may even have a hand in crafting the document.
Click here to find a template of a GDD. As that document’s summary will tell you, there is no single template because, as mentioned, every game is different. It might be most useful to peruse the template, see what’s included and then start writing your own document from scratch. Rather then trying to fill in each heading and sub heading supplied in the template.
Wire Frames
Description
Wire frames are usually abstract representations of the game’s screens. They are a great way to visually communicate functionality and features and act as a guide for artists and programmers alike. You should generate a wireframe for each unique screen of your game, everything form the start screen, each menu screen, the HUD, even modal windows should be outlined in wireframes.
Why make them?
Typically the wireframes are done in very rough form early, as a means to visually communicate the features of the game, this early form may leave out a lot of screens and contain a low resolution of information. These wireframes can be printed out and used to test the screen flow of your game. This can be a great early part of your test plan.
Who is your audience?
Wireframes are seen by a lot of people involved in production. They are seen by stake holders to sign off approval, they are seen by artists and designers so they know what assets to create and how the assets will sit together on each screen and they are seen by programmers so they understand what features need to be implemented and how to organize the software’s state. As the game development progresses, the designer should anticipate when higher resolution wireframes must be made. Wireframes will change over time. As the game takes shape, assumptions you made early on will be refined, the scope of the game may change, or things may have been left out. Wireframes must be kept up to date to avoid confusion among team members.
Flow diagrams
Description
A flow diagram can be handy whenever you have a series of branching events or program states. For instance, you are creating an adventure game, such as Myst or the Secret of Monkey Island, and need to plot out the character dialogue, but different characters tell you different things depending on the mission the play has completed or the items the player is currently carrying. This is only one specific example, flow diagrams can also be used to describe how a user might navigate a series of menus in your game, for instance to complete a micro-transaction, or even how a particular dungeon should unfold.
Why make them?
As the game develops certain aspects will be easier to diagram then they will be to write about. A flow diagram is very useful for communicating the steps of a particularly complex interaction. They are also useful for communicating a large amount of branching information in an easily digestible way.
Who is your audience?
Often, when it comes to flow diagrams, the designer is their own audience. these documents might also be shared with writers, and programmers depending on the flow charts content.
