NIME Progress Report #2: Reading and discussion (still no sound)
This week was spent deep in research, both in the function and form of interactive fiction. I'm knee-deep in source code and documentation of Inform interpreters (and the Inform 6 compiler), of course, but I also took some time to familiarize myself with some interactive fiction theory—and to actually play some games (consider this a form of rehearsal). There's still no sound coming out of my ChucK patch, but I'm getting close.
My main bit of breakfast reading is The Z-Machine Standards Document, which defines how implementations of the Z-Machine should behave (this information was reverse engineered from vintage-era Infocom story files and interpreters, and then later used as the basis of Inform). The opcode table is especially elucidating. I think I have a better handle on what information is available to me as the story file is running in the virtual machine.
I've also been skimming the Inform 6 Designer's Manual, which is short on the kind of low-level technical details I need but contains no end of helpful information about what to expect from games designed for the Z-Machine (particularly those programmed in Inform)—and the practice of designing interactive fiction.
Nick Montfort's Twisty Little Passages has proven to be an invaluable source of theoretical insights, and has helped to fill in my knowledge of interactive fiction history. (Further notes on this forthcoming.)
At this point, I think the key to my instrument is going to be the Z-Machine's object tree. This is the component of the virtual machine most specific to the creation and interpretation of interactive fiction; its presence distinguishes the Z-Machine from its more generic brethren (e.g., the Java virtual machine).
Here's how it works: every Z-Machine game has a number of objects, each of which represents something tangible in the game—everything from items to locations to people to the player himself/herself. These objects are contained in a hierarchy which, by and large, corresponds to physical containment. For example, the child objects of a room are the items contained in that room; the child objects of the player are the items in the player's inventory; the child objects of a box are the items contained within it, etc. Player movement through the map is, in fact, usually represented in code as detaching the player object from one room object and attaching it to the next. These actions are all conveniently performed using Z-Machine opcodes, making them highly visible to my hacked version of Frobnitz.
This is a sufficiently generic method of getting my hands on the data that effectively makes up the "map" of the game; it's also probably enough information to automatically draw a graphical map of the as it's traversed. But the fact that it's generic is also a drawback: for example, because the player object is just one among many, its identity can't be determined simply by looking at the object tree. (Heuristics could be used, such as looking for the object identified with the word "you," but this would fail in some cases.) If I want to focus the operation of my instrument on player movement, I'll either need some way to interactively define this, or else limit the scope of the instrument's functionality only to games specifically written for it. I'd rather not succumb to the latter course of action—I really like the idea of performing Zork.