Guidelines for Effective Game design documents
Guidelines for Effective Game design documents
Creating your design docs as a mixture of text, systems and UX diagrams, equations, etc., helps anyone who reads it understand your game. You should use pictures, diagrams, flow models, etc., wherever possible. If there’s something you can adequately represent with a picture or diagram rather than a block of text, do so!
Any design documentation is only as good as it is current. Game designs are often referred to as “living” documents, in that they change as the game development progresses. As such, plan from the beginning to update your design as development proceeds. You will find new ideas, uncover new problems, and change the overall design as you make the game.
While your design docs need to be complete enough to guide the implementation of the game, do not treat them as a “design bible” that is written once and never changed. Doing so is the fastest way to make your design documentation obsolete and irrelevant, and leave the team without a usable plan for how to create the game.
Encourage team members to create and link in subsidiary documents, and to comment on existing design docs “off to the side” rather than changing the text itself on their own. This can mean different things depending on the technology you’re using. If it’s possible to have people comment on the same page as the design (as in Google Docs and similar programs) this can work well and allow for conversations about the design within the doc. Otherwise you may need to have a “shadow doc” that parallels the main documents but contains only the comments and discussion about the design docs they accompany. The design docs themselves contain only the current state of the design, not any conversations or commentary.
As part of maintaining the design docs, either include these in your version control system to keep a log of changes and dates, or insert a log at the top of each section to show its history.
As much as possible, keep your individual design docs as brief as possible. This is especially true for technical documents, where the reader (a programmer or similar) just wants to know how a features should be implemented. A diagram or sketch will go a long way to making a design concept understandable, so use these whenever possible.
Use links to other documents liberally. Reference the design vision from a technical design doc that supports it, and vice versa, rather than including information not relevant to the particular document's purpose. For example, define a single interaction standard (e.g. for how mouse buttons are used or how confirmation windows look) and then reference that via links from parts of the design that use them. This prevents repeating the same information in various places and having it drift in meaning over time due to appearing in multiple places.
You want to document the entire design as clearly as possible. That said, creating too much design documentation can be as detrimental to your game as creating too little. If you know the details of a part of the game, document it using text, diagrams, mockups, etc. If you’re not sure, document what you’re trying to create, your best ideas for how to do it, and what paths you’ve discarded – and then create prototypes (paper or electronic) to test out the ideas. Don’t waste time documenting a lot of different options, much less arguing about them: find the area of uncertainty and prototype it. Then once the path you want to take is clear, document that and why you chose it.
Treat your design document like a blueprint for a building. Be precise in describing the design details. Avoid being vague, and state aspects of the design in present tense (the game behaves this way, not “the game will behave”). Avoid waffling words like “the game might…” This documentation is where you stake out the game in no uncertain terms. Except when describing high-level aspects of the design, do not use qualitative phrases like “this enemy moves fast” or “this results in a big explosion” or “this turret turns left and right.”
How fast? How big? How far? Whenever a quantity is called for (number of skills or levels, amount of damage, etc.), supply a number, a defined range, or a reference to an equation or other determining factor. If a decision on a specific number has not yet been made, say so, and call it out as an issue to be resolved. Being precise in your writing forces you to eliminate the fuzziness that can accompany a design that is all in your head. It is far easier to discuss and find the holes in a proposal than an idea.
At the same time, don't try to turn the design doc, even a technical design doc, into an implementation doc. Don't try to specify how something should be implemented; focus instead on the desired behavior (in precise terms) and let those who are focused on implementing the game work out exactly how to do it.
On a multi-person team, each designer (and sometimes producers and others) may be assigned particular parts of the documentation to maintain and keep current. It is typically a good idea to assign the more general parts of the documentation to the more senior members of the design team, and the more detailed pages to the more junior members. That is, a junior designer is more likely to be assigned a particular feature or system and the Lead Designer or equivalent the responsibility of maintaining the game concept and vision.
When discussing particular aspects of the design, be sure to make clear which parts of a feature are high priority (needed for the MVP for example), which ones are "nice to have," and which ones are shown for keeping the design complete, but may not be implemented until some undefined time in the future.
There is no one best method for organizing a game’s design docs. What’s presented here will work well for your game, but adapt this template as necessary. Remember, the point is to give anyone who reads it the information they need in the most effective way: don’t make them hunt for the particular information they want, nor be left wondering about some aspect of the game that concerns them. This is true whether that person is you next month, or a potential employer looking through your docs in your portfolio.
Current best practices are to create and organize your design document in the form of a web page or online wiki (like this template). This allows fast access and easy editing. Designs stuck in a single big Word doc tend to be forgotten in the heat of production.
It’s useful to present your design docs so that the broadest, most general information is immediately apparent, and then progressively reveal more detailed information as needed. This is the model used here. The “main page” covered here gives the reader an immediate understanding of the game’s purpose and current status. On this page links leads the interested reader to additional levels of detail. These are then separate sections that describe each part of the design in progressively more detail, with links between sections as appropriate.
There are many good example design docs online showing the level of detail needed. This site, gamedocs.org, has an extensive list of example game design docs and templates like this one. Another good example by Chris Bateman can be found here. This shows the organization and level of detail needed in a production design doc.
Next: The Main Page - Tip of the Iceberg