Contents

Asking Questions More Questions The Template

The Template:

The major reason most artists and programmers don't read the design document is that, if there are any practical design features contained within, they are usually buried in page after page of ongoing paragraphs. Simply stated, no one wants to weed through it to get to what they need to know. The template, in this form, serves the major function of being digestible in small relevant chunks.

Remember, this is a FEATURE-ORIENTED design document, which means that it is put together with certain goals in mind, and these goals are broken down into doable bits.

• 0 TABLE OF CONTENTS - This needs to contain EVERY major heading that you'll be dealing with. It should include sections like AI, collision, level design, front-end logic flow, controller input, and the like.
• 1 FEATURE HEADING - Describes and numerates the issue/feature in question. The numerical index, established in the TOC allows for easy finding and sorting once the project is underway.
  • 1.1 Contact and "See Also" Information - Straightforward: Point of contact for who designed the feature and what other documents it relates to outside of this one.
  • 1.2 Goals - A bullet list of associated goals including problems you may encounter implementing this feature and possible solutions to said problems.
  • 1.3 Implementation - How you're going to affect the feature. This is where you'd include formula, diagrams, or flowcharts that layout the design feature in question that all relative parties may need to know/follow to get the feature up and rolling.
  • 1.4 Impact - How this feature will impact the current status quo. You can't always crystal ball this, but in our case we're making changes to an existing engine/game, so some changes do affect the way we're currently implementing some features. An example of this would be having a new action for a wrestler to do, and needing a button-press to pull it off when we're already overloaded here. Another use for this heading is to help you identify extra resources you may need, and schedule relevant needs to bring the feature into line.
  • 1.5 to 1.8 Tasks & Questions for:
    • Designers
    • Programmers
    • Artists
      • 2D
      • Modelers
      • Motion
    • Sounds

There must be "Tasks & Questions" sections for each arm of the development team. This allows the Designer, Artist, Programmer or Sound Designer in question to skip straight to the task relevant to them without having to filter through all the other text. This also lets the design team ask any questions they may have at a time when they might not have access to the person that could immediately answer it.

You'll also want some way to tag features that have been dropped or held back for whatever reason. You don't necessarily want to delete those features, as they may make their way back into the current design or appear in the sequel if you're doing one.
In our particular case, we're working on the design for several titles at one time. Each heading is further expanded into 3 sub headings-one for each version-and color coded to make reading and separating them on-screen a little easier.

E-mail and the Hyperlink:

With the design doc online, we're able to send intranet e-mail to all concerned parties when a feature is designed, changed, or dropped. In addition to the email saying, "This feature has been designed, changed, or dropped," we can also add a hyperlink which, when clicked upon, will take the concerned party directly to the page(s) they should be reading.

The e-mail has a secondary consideration in that the Project Manager will know when and if the Email is being read. This helps in maintaining team accountability for what each person's job should be, and how they need to implement it when the time comes. This kind of organization lends itself to a HTML-type document as well. We're currently setting up just this kind of accessible, online document using MS Frontpage. You could also use Dreamweaver if you were so inclined. This allows anyone with a web browser to access the design doc and very easily navigate their way to whatever piece of info they need. Even better, you can do things like create art bible's, complete with linked thumbnails and actual photo reference on the network, making sure all or your resource is available and protected.

The next section (THINK) will go deeper into asking questions about what you're supposed to be doing as a designer. This also includes my list of "Nevers," garnered over the years both from friends in the industry and from simply doing things the hard way.

Tim Huntsman has been with Acclaim Studios, SLC for over 4 years and is the Lead Designer for Acclaim's next-gen wrestling title. He has worked on the ECW wrestling franchise as well as the genre-defining WWF Attitude for PSX and N64, projects that taught him more about professional wrestling than he ever thought he'd know. When not working on games and their design, he's playing guitar in experimental projects, writing various forms of fiction, painting in the Sumi-E style, and fencing (with swords, not wooden planks.)

Discuss this article in Gamasutra's discussion forums

________________________________________________________

[Back To] Asking questions