Software Development Documentation

Documentation is essential for interactive games and other complex projects.

"The goal of the reiterative development approach is to methodically evolve every object in the system - from abstract concept to actual code - as quickly and clearly as possible, without killing, mutating, or forgetting anything."
- AIP Founder/Director Tod Foley

When it comes to complex projects like interactive environments, design and documentation go hand in hand. Before your project can be built it must be designed, and if the concept isn't precisely captured and described in the documentation, the finished product will bear only a passing resemblance to your initial idea. Whether you call it "playing telephone" or "conceptual drift," it's a problem that must be addressed on all large creative efforts.

To avoid this problem, AIP has developed and tested documentation systems for every type of interactive media design. One key feature of these systems is that they approach the work in a reiterative fashion, adding layers of increasing detail and technical definition on top of a standard infrastructure as the work progresses.

All interactive projects pass through five phases on their way to release: Definition, Analysis, Design, Construction, and Testing. In the AIP method, each of these phases is represented by a particular "level" of documentation -- from Sketches and Outlines to Functional Specifications, through Flowcharts and Object Specifications, and up to Technical Specifications, Mechanical Scripts and Bug Reports, each of these documents lays down a coherent framework for the next phase of development.

Some sample documents (available upon request):

• Functional Specification (from "Ocean Voyager")
• Narrative Flowchart (from "Doomsday")
• Object Specification (from "A Rogue in Exile")
• Technical Specification (from "Doomsday")
• Mechanical Script (from "Ocean Voyager")

Code

It is our philosophy that the programming team is ultimately the most important audience for the project documentation. This shows in the AIP approach to design, which is programmer-targeted, object-oriented, and largely "bottom-up." As a result of this approach, all of our designs include full Object Specifications and Mechanics (i.e., definitions, tables and algorithms) allowing programmers to "grab the ball and run with it." If the client plans to use in-house programmers or proprietary technology, our documentation will use the house jargon. If off-the-shelf products will be used to build the project, the terminology of those products will be used in the docs.

If the requirements of the project exceed the experience or availability of your in-house programmers (or if you don't have any in-house programmers), AIP can help with that, too. Our network includes some great independent programmers, and our experience runs the gamut: from custom installs and web-based scripts to client-server apps and rendering engines.

Demos

They say "a picture is worth a thousand words," and we believe that's true. But here at AIP we also believe that an interactive demonstration is worth at least

1000 words * NC

(where N equals the number of interface elements displayed and C equals the number of choices available through any given interface element).

This is of course just a tongue-in-cheek way of saying: Sometimes the best way to explain something is to build a simple version of it. That's what demos and mockups are for, and here at AIP we pride ourselves on the rapid development of such programs. Whether you need a working demo of a networked application, or just a good "look-and-feel" interface mockup, we're here to help.