Story
CSSE 290 – Computer Game Design
Winter 2010–2011

This document assumes a foldback structure for your story. If you feel that you need to deviate significantly from these instructions for your game, discuss this document with your instructor.

The Story document describes your story, including any progression through levels, in complete detail. It forms part of the Game Script that gives all the details about your game.

What process should you use to design your story?

Consider using the following process for designing your story (but see below for the form of the Story document).

  1. Brainstorm the basic description of the story as part of your initial game brainstorming.
  2. Determine the story ending(s).
  3. Determine most of the inevitable events in the foldback.
  4. Give tentative answers to some of the Design Questions for Storytelling and Narrative.
  5. Determine the branching in some of the foldback stages, by answering for some of the nodes:
  6. Iterate and refine, continuing to answer the appropriate Design Questions for Storytelling and Narrative as they arise.

How should you organize your Story document?

Organize your Story document as follows, but note that you write the document per the process above (e.g. you answer design questions while you are in the process of writing the story, and the story is refined/modified as the game design progresses):

  • Section 1: Executive Summary

    A one or two-paragraph summary of the story.

    • You probably want to write this during the concept stage, but it is likely to change (maybe several times) during elaboration.
    • Try to keep this section up-to-date as the story evolves, so that the team maintains a consistent vision for the story.
    • Near the end of the design of the game (but before you try to sell the game design), polish this summary.

  • Section 2: Story structure

    A foldback diagram like the one pictured to the right, but with short phrases at each node.

    • Each node should refer the reader to a more complete description of that node (see Section 3 below).
    • The reference can be through a hyperlink, but also should use some labeling scheme.
      • For example, perhaps you label each node X.Y.Z where:
        • X is the level of the node when you count only the inevitable events
        • Y is the level within its inevitable-event subgroup
        • Z is the left-to-right position of the node within its level
        See the diagram for an example of this labeling scheme.

    If your game really doesn't have a story elaborate enough to support a foldback diagram, force the story to have a foldback diagram with at least two inevitable events plus the ending, along with at least some branching within an inevitable-event subgraph. Indicate to the reader (game programmer) the simpler story that you really want implemented, explaining that the more elaborate story was written so that you could meet the learning objectives regarding Story and Narrative.

  • Section 3: Detailed Description

    List the nodes in Section 2 (using the labeling scheme you choose). For each node, indicate:

    • What event(s) cause the story to go to this node from its parent node(s)?
    • What narrative is associated with this node?

    If your foldback diagram has a large number of nodes, you may select a subset to describe in this section (and leave the rest with only their short phrase on the diagram). Rule of thumb: you should have at least 12 nodes described here (i.e., 3 per person in a 4-person team).

  • Appendix A: Design Questions

    Answers to the Design Questions for your Storytelling and Narrative.

    • Start with the answers that you know, and add to this section as the storytelling and narrative is refined/modified.

Foldback Diagram with nodes labeled