June 27, 2003
What We Write About When We Write About Behavior
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?
July 1st, 2003 at 10:43 am
Descriptive text fragments are far more useful then code. Converting the highest level (and commonly used) descriptors to XML Schema tags may help bridge the gap and support some future-proofing.
July 3rd, 2003 at 3:40 pm
A few days ago, Mark Bernstein wrote some comments about this post on his blog.
I’ll respond in a few days — I just got back from a 4-day business trip, and today’s my fourth wedding anniversary, and tomorrow’s the Fourth of July, so a response will be forthcoming next week… :-)
July 19th, 2003 at 7:34 pm
I believe that writing non-linear fragments is not natural, and that, almost automatically, any author returns to paper and pencil (or typewriter, or word processor). You mention a few exceptions (maps, graphs), where the non-linearity is spatialized, which is rather intuitive. Otherwise, non-linearity seems to be abstract, and an intermediary level of description, a non formal textual description, is necessary.
The content of the structures vary considerably from one system to the other. With IDtension, we are not describing behavior, but “goal structures”, which are more abstract than behaviors. But in both cases, the author describes before, in an almost linear manner, what could happen in various situations.
Related to this question, I even wonder whether there is only two levels of authoring (textual specs + coding) or additional intermediate levels…
December 10th, 2004 at 7:48 pm
Actually architects work in different ways, some from vistas, some from plans, some from freehand ‘spaces’ or planning areas, some from elevations.
>Lately I’ve been wondering how authors of non-linear interactive experiences develop their designs..
I wonder too, because the ideas just come to me, (like writing comedy) and that is not particularly rigorous! There must be some methods that minimise pesky emergence.
For prototyping, I have found only by creating 3D interactive environments can people understand interaction, storyboards are the next best option.
I used to use pseudo code, but I would also like to use icons/symbols-a combination make it quicker to read.
A hybrid graphic symbol/text pseudo story code would suit my design style because that is how I sketch ideas (text and images).
Research indicates that users accuracy in drawing sketch maps after the VE experience, relate to their engagement. It would be great to see these sketch maps incorporated into the next game/story environment for the next players.
This thread may be moving towards partially answering a project-related question of mine: imposter behavior detection by bots/agents.
Also, I am looking at creating a VE/game where real people attempt to simulate local agent behavior in order not to be spotted /pointed out /socially demoted by the bots. Suitable behavior means reacting to certain social role holders and events in appropriate ways at the right time and place. The agents, on the other hand either instruct the imposters(the players) or try to detect them. I still haven’t found a sophisticated game that uses this (although you see this a lot in Hollywoods films, like robots or aliens pretending to be good guys-hmm, a cultural face off!).
I would appreciate being referred to any ‘imposter detection’ games and AI systems that attempt this detection. Perhaps current schemas like the one in Facade are extensible this way.