Deprecated: Optional parameter $input declared before required parameter $form_state is implicitly treated as a required parameter in /home/dh_gapiai/asifproductions.com/sites/all/modules/references/node_reference/node_reference.module on line 633
Custom Design & Documentation | As If Productions

Custom Design & Documentation

I've written a lot of automated webserver applications, standalone desktop applications and client-server systems for Windows and UNIX/Linux, and all of them needed documentation. I've also written rulebooks, user manuals and in-house documentation for games (both tabletop and electronic), as well as other complex projects. No matter what type of complex project you're talking about, good, precise documentation is a vital link in every step of the process.

"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

When it comes to software projects, I believe 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 "bottom-up." All of my digital system designs include full Object Specifications and Mechanics (i.e., definitions, tables and algorithms) allowing programmers to "grab the ball and run with it." If you plan to use in-house programmers or proprietary technology, the documentation will use your own 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 global network includes some of the hottest independent programmers around, 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.


Media Production

Of course, your project isn't all documentation and code. This is art,after all! Practically every interactive project requires some amount of original artwork and sound. Even a "demo" can be fairly involved in this regard: the capabilities of the system need to be demonstrated in clear and sensible ways, and audio/visual cues are invaluable for these purposes.

But these days you don't have to spend an arm and leg to obtain quality art and sound. New media assets can be created quickly and inexpensively using our extensive source libraries and state of the art digital equipment, or existing assets can be sampled, processed and fine-tuned to fit the project's needs. No matter what your multimedia requirements are, AIP's talented network of affiliated artists, actors, musicians and audio engineers can pull it together for you; on time and within your budget.

Contact Tod for a Consultation
Department: