March 4, 2008
EP 7.1: Writing Software
My early experiences of digital media were as an audience member. I remember playing text-only games like Hunt the Wumpus on mainframe terminals at my mother’s university — as well as interactive fictions like Zork I on my father’s early portable computers (a Kaypro and an Osbourne). I remember playing graphical games like Combat on a first-generation Atari console that belonged to my cousins — as well as Star Trek: Strategic Operations Simulator on my friend Brion’s first-generation Atari home computer. Brion would later guide me in more arcane explorations of computer code, as we attempted to creatively alter the binary files of games we played, saving them back to the Atari’s tape deck. But I think it was earlier, when I was ten years old, that I first sat down to program at a “blank slate.”
This was at my elementary school, on pre-Macintosh computers from Apple. I used the built-in Apple version of the Basic programming language to create a very simple piece of media of my own: a low-resolution star and sky, independently cycling through colors, beeping as each new combination appeared. On the playground I daydreamed about how to create more complex media, along the lines of Infocom’s Zork I (Anderson, Blank, Daniels, and Lebling, 1980). But I couldn’t figure out how to scale up from the simple Basic commands I knew (e.g., “GOTO”) to a complex software system like Zork’s.
Decades later, I now see the piece of the puzzle that eluded me: the authors of Zork didn’t work in Basic, and it wasn’t necessary for me to do so. Though Basic was part of the built-in, read-only memory of the Apple II, by working in it I wasn’t functioning in the essential language of the computer. Instead, I was using an authoring system, created to make it easier to develop certain kinds of software. The authors of Zork were using a completely different system, designed to make their sort of software easier to create.
In fact, the authors of Infocom’s popular interactive fiction titles employed several layers of software I didn’t begin to imagine (Montfort, 2003, 126–127). Rather than use the versions of Basic (or some other language) specific to the various personal computers of the 1970s and 80s, their code was written to run on a “virtual machine” — versions of which they created for each major platform.1 Further, the essential elements for supporting gameplay (interpreting text typed by the audience, simulating a virtual space, managing manipulable objects, and so on) were abstracted into a kind of game engine. Each author (or set of collaborators) creating an Infocom fiction was mainly occupied creating the specific text and behaviors for the places, objects, and characters in that fiction — rather than starting from scratch, as I imagined.
To put it another way, the fact that I didn’t recognize Basic as a set of authoring tools was only the tip of the iceberg. More generally, I didn’t recognize that most digital media creation takes place within systems specially designed to support particular types of authoring tasks, and that these systems are in turn supported by layers of further systems. As this happens, elements that look like system processes on one level (e.g., a series of commands in a programming language) can come to look like data on another level (e.g., a compiler using its processes to translate those commands for another system). The power afforded by this fact allows for the crafting of special-purpose authoring environments — from game engines to interactive animation software — that can make some tasks much easier and others impossible.
Authoring stories
As story generation systems are thought of as media, rather than simulations of human intelligence, issues of authoring come to the fore. Creating a successful story generation system requires thinking in terms of the audience’s surface experience — and also in terms of the structures presented for authoring the elements of that experience. This chapter examines three influential story generation systems both as authored artifacts and as systems for authoring.
Like any digital media system, a story generation system has one simple requirement: along some dimension(s), the system should offer an advantage over other solutions. For example, Infocom sought to create interactive story experiences for broad audiences. Implementing a software system had the advantage of making this possible, given that it was impossible for Infocom authors to make personal visits to the homes and workplaces of thousands of simultaneous players. On a more serious note, implementing a virtual machine made it easier for Infocom titles to reach audiences playing on the wide variety of 1980s personal computing platforms, as compared with “porting” the games to each operating system.
Beyond this simple litmus test, the sorts of story systems considered in this chapter also have two further requirements. First, they must be expressive and controllable, so that their underlying models effectively shape the audience experience. Without this, much of the effort involved in developing their fictional models is arguably wasted. At the same time, these systems must also be authorable — not departing so far from the skills and expectations of traditional authors that developing material for them is unrealistically onerous and unable to draw on our vast body of experience in media authoring. Balancing these two requirements can be a challenge.
Looking at this chapter’s example systems also foregrounds another significant difference between the practices of AI and digital media. In AI, as in many areas of computer science, a system does not need to be completed in order to be influential. Computer science rewards the creation of innovative processes, and mostly considers data the province of other fields. This results in a significant incentive against actually completing the authoring work for story generation systems. Completing the data is time-consuming work with little direct reward, especially for systems that are not well-designed for authorability.
Unfortunately, unfinished systems provide substantially less valuable results, for both fields, because neither their processes for story generation nor their support for authoring are fully tested. Yet unfinished systems remain worth examining, because it is the only way to gain insight from the creative work performed in many computer science projects. This is visible in two of the systems discussed in this chapter: Universe and Brutus. This chapter’s final example, Terminal Time, takes the next step — both departing from an exclusive disciplinary identification with computer science and (perhaps as a consequence) creating a completed system.
Notes
1This was an early commercial instance of the same strategy used by the Java language’s virtual machine.
March 4th, 2008 at 6:18 pm
If you’re interested in more about the programming of Zork, here’s the 1979 IEEE Computer article by Lebling, Blanc, and Anderson. http://www.csd.uwo.ca/Infocom/Articles/ieee.html
March 10th, 2008 at 8:33 am
You know, this is a good question. When I learn something from secondary sources (like Nick’s book) should I also/instead go back and cite a primary source (like that IEEE article)? It’s helpful to readers, who may want to research further themselves, and probably more authoritative, but I hate to leave the debt I owe the secondary literature unacknowledged.
March 10th, 2008 at 11:45 am
You might quote a brief bit of interpretation or introduction from Nick’s phrasing, as a way of tipping the proverbial hat, or just list Montfort first in the parentheses and then add the primary source right afterwards. Or you could add another line of narrative: “When I read the IEEE article for myself, I realized…”
When I’m citing a secondary source in a subject area outside my field, of course I have to lean more heavily on the secondary source. But you did a service to the field by pointing out the soap opera plot mistaken by credible sources for an AI output. If you cite Nick and his source favorably, that’s a sign that you double-checked him and agree with his findings, and that’s also worth a mention.
March 11th, 2008 at 11:13 pm
Yes, I think the double citation makes sense. But that probably means I need to find a version of that IEEE article that I can feel confident is identical with the version I’m citing. I wonder if UCSD’s library has electronic access to an IEEE database going back that far…
Meanwhile, thanks for calling my Universe catch a service to the field!