August 2, 2008

Reading week 1: Game Development Documentation

Filed under: ECU MInT,GDT3102 Writing for Games — steve @ 3:37 pm

Game development Documentation – a reading and summary of chapter 15 “Game Development Documentation” from the book “Game Design: Theory and Practice” by Rouse, R. (2000).

Rouse (2000), in this chapter, discusses 8 development documents that the game designer may find useful and beneficial to the successful development, and possibly ongoing funding, of a game project. These documents are as follows :

  1. Concept Document or Pitch Document or Proposal (p. 293)
  2. Design Document (p. 294)
  3. Flowcharts (p. 295)
  4. Story Bible (p. 295)
  5. Script (p. 297)
  6. Art Bible (p. 300)
  7. Storyboards (p. 301)
  8. Technical Design Document (p. 301)

and finally, the documents that, according to Rouse, should not be included in the design document, the Schedules and Business/Marketing Documents (p. 302).

Concept Document or Pitch Document or Proposal

Rouse outlines that this is usually the first formal document that is written to get the “green light” for funding from the publisher/upper management to develop the game proposal. This is normally not a large document “customarily no longer than ten pages” (2000, p. 293).

The Concept Document would “usually include plenty of concept art” and be “written by committee, typically involving the game’s producer, lead designer, lead programmer, whatever marketing people may be on hand and the lead artists” (Rouse, 2000, p. 293).

The Concept Document should explore the full range of the game idea that is being proposed, including “how it might be positioned in the market place, budgets and development timelines, what technology will be used, what the art style of the game will be, mini-bios of the team who hope to work on the game, and some broad description of the gameplay” (Rouse, 2000, p. 293).

Though not normally useful in the game’s development, the Concept Document can be a useful launching pad for the development of other documents such as the Design Document and Art Bible (Rouse, 2000, p. 293).

Design Document

Rouse (2000, p. 294) is clear to point out that the Design Document may be referred to by another name, that of “the functional specification”. Its primary purpose is to “fully describe and detail the gameplay of the game” and describe the game mechanics as to: “what the player is able to do in the game world, how they do it, and how that leads to a compelling gameplay experience” (Rouse, p. 294). The Design Document will include “the main components of whatever story the game may tell and …. the different levels or worlds the player will encounter” (Rouse, p. 254). Also included will be “lists of the different characters, items, and objects the player will interact with” (Rouse, p. 254). Basically, the Design Document “should describe how the game will function, not how that functionality will be implemented” (Rouse, p. 295).

The Design Document, as a development tool, is used by the Development Team as a common point of reference and by Producers as an aid to developing a development schedule (Rouse, 2000).

Rouse points out (2000, p.295) that the following items should not be included in the Design Document:

  • Technical specifications such as
    • Platform
    • System requirements
    • Code structure
    • Artificial intelligence algorithms
  • Marketing of the game
  • Sales projections
  • Schedules
  • Budgets
  • Other project management information


These may be included in the Design Document and according to Rouse (2000, p.295) “are not actually all that useful in the game design process though they may be handy for communicating to the other members of the team or the publisher how the gameplay is supposed to progress”. Rouse does point out that flowcharts are useful in the game development to “track the player’s navigation in out-of-game menu options” and “to chart the areas the player progresses to and from in the game” (p. 295). He offers this final comment on the use of flowcharts in game development: “Primarily, I have found that flowcharts impress the publisher, while the development team seldom refers to them” (Rouse, p. 295)

Story Bible

“The story bible is a tool which can help in the creation of the game’s story” (Rouse, 2000, p. 297).

Rouse explains: “For games that tell stories, some amount of that story must be included in the design document … but the design document cannot include it all” (2000, p 295). Therefore, a Story Bible is perhaps the best place to document information on a game that “involves a complex story line with a variety of characters and locations or if the game takes place in a universe with a specific history” and “is a good place to document a game’s potentially extensive back-story” (Rouse, p 296).

Though the “format of the story bible is fairly open” (Rouse, 2000, p. 296) the following are mentioned as possible game elements to be included in the Story Bible (Rouse, pp. 295-296):

  • historical narratives
  • the game world’s history
  • narratives and histories of the major characters, including:
    • the character’s childhood
    • how they achieved their position in the game
    • what motivates the character
  • histories of:
    • major items
    • major locations
  • other information that will be important to the game’s creation

Rouse states that the “writing style of the story bible should be in more of a prose style” (2000, p.297). He mentions the following as useful considerations for the reader of the Story Bible (Rouse, p. 296):

  • that it reads and flows nicely
  • includes a break down each character, item or major event
  • uses appropriate:
    • title headings
    • diagrams
    • timelines
    • event flowcharts
    • character relationship trees

The Story Bible can be a useful tool for artists to find out more about the character they are modelling, voice actors to find out how they should interpret their character and for continuity between game title sequels, if any (Rouse, 2000).


In this section, Rouse describes the importance of a script: “If a game has a story, it is quite likely that at some point the player will be asked to listen to narration, hear characters talking, or read information about upcoming missions. This dialog and the accompanying descriptions of the situations during which the dialog occurs (stage directions) should be contained within the game’s script” (2000, pp. 297-298).

Rouse goes on to say that the script itself may be developed by a number of people including “a designer, an artist, the game’s producer, or someone whose only role on the project is to write the script” (2000, p, 298). Also, the script might take differing forms – a movie script for cut-scenes, dialog for in-game conversations , the inclusion of stage directions (Rouse, p. 298).

Rouse (2000, p. 298) states: “The non-linear nature of games demands that the script be organized and presented differently from a play, movie or television script”. He proposes the use of pseudo code “using IF-THEN-ELSE or SWITCH-type syntax to communicate when the player would hear different pieces of dialogue” (Rouse, p. 298) and provides some examples of how this might be employed in the design of an interactive script with the following disclaimer “There is no industry-standard syntax that dictates the form of an interactive script” (Rouse, p. 299).

In closing this section on the Script, Rouse (2000) makes the following observation: “The most important thing to remember when working on the script for your game is that people are usually playing your game not for the dialog, but for the gameplay” (p. 300).

Art Bible

On the use of an Art Bible, Rouse (2000) states that: “The art bible is often composed primarily of concept sketches and other resources that artists can refer to as they are working on creating various visual assets for the game” (p. 300). The Art Bible is compiled by the Lead Artist and “needs to correspond and be consistent with the story and characters described in the game’s other documents, including the design document, script, and story bible” (Rouse, p.300).

Furthermore, Rouse says: “The art bible is the place where the look and feel of the game is comprehensively established in detail” (2000, p. 300) and that “designers on a project should read over and be familiar with the art bible” (p. 300). Rouse also mentions that the Art Bible may contain technical guidelines artists will need to abide by for use of their art in the game engine as well as polygon count limitations and animation frame counts and durations.


Though storyboards are normally used for linear sequence such as cut-scenes, Rouse (2000) does point out that they can be also useful for pitching concepts to team members or financiers in the early stages of the game’s development before the game engine is available for use. He also points out that: “Storyboards may be included as part of the art bible or can stand alone as their own separate document” (Rouse, 2000, p. 301).

Technical Design Document

On the development of the Technical Design Document, Rouse (2000, p. 301) offers the following: “A technical design document is the sister specification to the design document. Whereas the design document focuses on how the game will function, the technical design document discusses how that functionality will be implemented”. He explains that this is “where the code’s structure is laid out and analysed” (Rouse, p. 301) and that the Technical Design Document may contain (Rouse, p. 301):

  • code structure
  • major classes
  • rendering architecture
  • AI systems
  • other implementation information
  • and any pseudo-code as appropriate

However, perhaps the most interesting thing Rouse tells the reader about the Technical Design Document is the following:

Though the technical design document may be a good idea, many projects manage to have perfectly successful development cycles without a technical design document ever being created. Indeed, none of the projects I have worked on has had one, nor do I know anyone who has actually worked on a project which did. (2000, p. 301)

Schedules and Business/Marketing Documents

Not discounting the worth of these documents for the appropriate project management and Business and Marketing needs, Rouse is clear that he includes these in his list of game documentation “in order to emphasize that schedules, budgets, and project management information does not belong in the design document” (2000, p. 302) [italics added].

Summing up…

Rouse rounds of the chapter with statement that there is “No Standard Documentation” (2000, p. 302) and finishes with “The Benefits of Documentation” (p. 303) where he states: “good documentation really can help make your game better … As a lead or senior designer, the creation and maintenance of the design documentation, story bible, and script are all your responsibility” (p. 303).



Rouse, R. (2000). Game Development Documentation. Game Design: Theory and Practice (pp. 291- 303). Plano, Texas: Wordware Publishing.

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Designed by TigerLeo - Powered by WordPress