Get the latest Education e-news
 
  • Book Extract - Creating Games: Mechanics, Content, and Technology

    [06.04.09]
    - Morgan McGuire and Odest Chadwicke Jenkins
  •  [Here, GameCareerGuide presents an extract from Creating Games: Mechanics, Content, and Technology -- Chapter 5: The Design Document. This comprehensive and easy-to-understand guide should get you on the road towards creating your first design documents with relative ease.]

    Terms Explained: Choke Point - Design Document - Issue Tracking - Player Composite - Bugs - Plot Graph - Staffing Plan - Storyboard - Tags - Technology Plan

    The design document describes the development team's shared vision for all aspects of the game and the development process. It is considered a working document because it is continually revised, based on feedback and experience. The team begins writing the design document before the game, but the document is not finished until the game itself is finished!

    The format of the design document is essential to its use as a reference document. Each chapter addresses a specific aspect of development, such as the user interface. The order and style of the chapters varies across companies, but any game-development project should contain most of the sections discussed in this book. When the developer works with a publisher, the developer proposes the game with an early version of the design document and later uses the design document to present the game's evolving specifications to the publisher. Some sections of the document resemble a business plan in order to meet these needs.

    Design documents are often hundreds of pages and are maintained by the lead designer and producer, although other members of the team contribute a lot of the content. In the board game industry, design documents tend to be short and informal because board games are simpler than video games, and the development process is shorter and involves fewer people. A tightly-focused design document of about 20 pages is good for an indie game or classroom final project. As with any working document, controversy may arise about whether to write a long document (to create a full specification) or to write a short document (which is easier to keep up to date). We recommend keeping the design document on the short side and augmenting it with regular face-to-face communication between team members.

    New document technology like webpages and wikis can make design documents up to date and more visible to the whole team. Online documents also have the advantage of hyperlinks between sections of the document and external concept art or supporting documents.

    This chapter describes the basic content of the design document. Although all of the following features are presented in this chapter, later chapters discuss individual features in more detail.

    1. Title page
    2. Executive summary
    3. Overview
    4. Related games
    5. Player composites
    6. World
    7. Characters
    8. Progression graph
    9. Art direction
    10. User interface storyboards
    11. Tags and dialogue
    12. Technology plan
    13. Software architecture
    14. Controls
    15. Level design
    16. Mechanics analysis
    17. Schedule
    18. Budget
    19. Change log

    5.1 Title Page

    The title is on one page. It is graphically simple, like the frontispiece for a book. Yet it contains vital information. The title page should contain:

    1. a picture (screenshot or box art);
    2. the title of the game, and optionally, the tagline;
    3. the name of the developer;
    4. the date and revision number of the design document.

    Larger companies or those working with publishers require legal statements on this page as well. For example, copyright information, "confidential/do not distribute" instructions, and the main office contact phone number and address.

    5.2 Executive Summary

    This one-page section describes the entire game in three sentences: [1]

    1. a sentence about the basic setting;
    2. a sentence that describes what makes the game interesting;
    3. a sentence that will convince a publisher to approve or fund the game.

    A game might be interesting and engaging because it contains a new technology, has an interesting story, contains a new mechanic, or can be marketed at a low price. There are many reasons a publisher might want to approve a game. These tend to focus on either novelty, e.g., "never before have RPG and puzzle games been combined" or "the first real-time Scrabble game," or (ironically) the complete absence of novelty, e.g., "this is a James Bond game, and all James Bond games sell 1M units." Often the text for the executive summary can be entirely drawn from other sections of the design document.

    5.3 Overview

    The overview consists of two or three pages that compactly describe the major qualities of the game. It follows the overview worksheet format from the previous chapter. It must pitch the core concept, review related games, and present the reader with a mental image of the game as a whole. It is essentially a distilled version of the entire design document.

    The overview is the first part of the design document that is written. Once accepted by an internal team, the proposal/overview then evolves into a proposal from the team to the company. The ideas from the overview are finally expanded into a full design document.

    5.4 Related Games

    This section reviews related games and serves as background research for both marketing and design purposes. Experience with previous work is important. You should extend the successes of previous games while avoiding their pitfalls. Rarely do truly original ideas emerge; usually someone has already come up with your great idea. So research previous work and then leverage it.

    The related games section should devote about one page to each related game. The specific games chosen should be a superset of those described in the overview section.

    Discuss existing games that resemble yours in any way (e.g., setting, mechanics, business model). Why do you feel that you can repeat the success of a previous game or avoid its failure?

    Some previous work may be your competition. You need to address this head-on. Judge your own potential and account for competition in your design. Why will your game succeed if it is competing with an already established game?


    Figure 5.1: Library of related work games at Iron Lore Entertainment.

    A wise designer draws heavily from previous games. Most games companies have large libraries of games available for close study and reverse engineering during production (see Figure 5.1). Build such a library and plan on spending many hours perusing everything from menus to data files in other games.

    ---

    [1] An academic would call this the abstract for the document.

Comments

comments powered by Disqus