June 27, 2003
Lately I’ve been wondering how authors of non-linear interactive experiences develop their designs. Specifically, before coding, what are the ways people describe, represent, write down, their designs? Creating a written description of a system gets particularly tricky when the system’s behavior is more complex than what a state machine or graph can represent.
I imagine that maps are a common approach to design an experience, if the experience is based upon navigating an environment, e.g., a spatial narrative, as is the case for many adventure games, interactive fictions, first-person shooters. In the design phase, like an architect, an author could draw a map of the world / level, imagine the ways the player will traverse it, decide where to place content (puzzles, obstacles, treasure, weapons, traps, monsters, etc.), how the content gets triggered, etc. The map may be the central design document.
Actually I’m wondering more about interactive experiences that don’t rely primarily on spatial navigation to structure the experience. For example, systems where autonomous behavior of agents / objects etc. is primary, and the environment is secondary or minimal?
Perhaps some people design and author directly in the language / tool that the work will ultimately operate in. For example, one could start a design from scratch directly in Inform, Director, C++, what have you, and continue adding content and code until it builds up organically over time. In such cases, code will be the final representation of the behavior of the system anyway, so perhaps it is efficient to design directly in that language.
But, I’ve found, designing within the language can be cumbersome, and time consuming. Some planning before coding tends to work best for me.
I’ve often heard of game developers prototyping gameplay in simpler prototype languages, in order to understand the essence of their gameplay. Prototyping makes it easy to iterate over a design – not requiring the creation a lot of art up front, allowing authors to easily tweak and tune, etc. Once the prototype feels good, they take the plunge to invest the time and money into developing the real game itself.
For me, I don’t start at the keyboard. When designing an interactive experience (or a sub-part of an experience, or a sub-sub-sub-part), I always start on paper. I write down a bunch of descriptive snippets of how I want the system to behave. I try to make these descriptions as specific and unambiguous as possible, in essence giving me very clear instructions of how I should code the behavior. I then type up these notes into a descriptive spec, that I use as a reference as I code. I often tweak the spec during coding, when I realize this or that idea needs to be changed.
For example, here is an excerpt of a design document developed for Facade. It describes the behaviors for the Trip character and his plastic “advice ball” toy (i.e., a magic eightball). Additional design documents for these behaviors (not included here) include a list of dialog fragments used by the behavior. We’ve written dozens of these kinds of design docs for Facade.
I’m not sure how to represent this kind of behavior, other than descriptively, like the document shows. This kind of non-trivially complex behavior can’t be captured in a graph or state machine. For such systems, I wonder if the code (plus comments in the code) will have to suffice as the only document that describes the system’s behavior in great detail?