The Gameshelf

This past Thursday, I went to a talk by Michael Mateas: "The Authoring Challenge for Interactive Storytelling". Mateas runs the Expressive Intelligence Studio at UC Santa Cruz. The talk naturally centered around Facade, an interactive drama released in 2005 by Mateas and Andrew Stern.

2005 was a long time ago now, which saves me the effort of explaining what Facade is. (What? Click on the link.) (What? Okay, here: Facade is a short game in which two friends, Trip and Grace, invite you over for dinner. They then proceed to have a horrible nasty argument and drag you into it. The interface is a real-time, free-form, natural language text prompt; the characters respond in spoken text and animated movement. It's free, go download it.)

(Admission of guilt: I never got around to playing Facade before I went to the lecture. Fortunately Mateas started by showing a trailer (youtube link), so I wasn't lost. Yes, I've now played with the thing.)

The lecture was nifty. So nifty, in fact, that I will transcribe all the notes I took. (My notes, to be sure, were not anything like a complete transcript of the lecture. I'm putting my notes under quote bars, but please take them as my interpretation of what I heard. I'll intersperse my own commentary.)

What is interactive storytelling?

• not choose-your-own-adventure books
• not paper-and-pencil RPGs
• not hypertext
• not an "embedded linear story" in a game (the most common story model for videogames, where a fixed story plays out in cut scenes, unintegrated into the gameplay mechanics)

The text adventure (Zork) is close to what Mateas is imagining. (The usual notional model is Star Trek's holodeck -- thus Murray's Hamlet on the Holodeck and so on. But even as a fictional ideal, the holodeck has been problematic.)

Yay text adventures. (I am, as you will soon see, thinking about this talk from an IF-author's point of view.)

As a distant spectator to the academic world, I don't know what narratologists think is problematic about the holodeck idea. (I mean, aside from it nearly destroying the Enterprise every six weeks.) I guess it's clear that the Star Trek writers had no deep notion of what interactive drama would be -- they just stuck a subordinate static narrative into the static narrative of their TV show. Except for that Moriarty episode, which showed how interactive stories didn't work...

CYOAs and hypertext are easy to implement, but don't provide much sense of agency. This is even more true of linear embedded stories, obviously. D&D provides true interactivity, but you need a human game-master to run it. The holodeck, similarly, needs a 24th-century computer. So we are led to the idea of AI underpinning interactive story. AI (or at least AI techniques) seem necessary for:

• story generation
• story understanding (figuring out what the player is trying to do)
• drama management (selecting and ordering bits of story to create dramatic arc)
• autonomous characters

This is where a lot of discussion in the IF world runs aground. We say things like "To really improve text parsing, you'd need real AI." Then, since none of us are AI researchers and we're pretty much implementing everything in low-level, C-like languages, we give up and say "Okay, so what can we do really well without AI?" (At least, I do. And I think I've gotten excellent answers to that latter question, but it's still fair to see it as a dodge.)

Current research into interactive storytelling has been disappointing. A lot of people come up with theories of how it could work. Some people implement engines or mechanisms based on their theories. Some of those then go on to create story demos within an engine. Very few create a complete interactive story -- not just a demo, but a work that can stand on its own.

Mateas and Stern created Facade out of a belief that to move research forward in an artistic sphere, you need to create complete works.

In other words (my words), a demo for a new game model can demonstrate the engine, the programming techniques, etc. But it can't demonstrate the validity of the artistic approach. To do that, you need to do art. It can be a short work, but it has to be something you're aiming at players. You find out whether you're right by seeing how players react.

This has been common wisdom in the IF world for a decade. Right from the beginning of the amateur-IF era, the community developed a strong response to on-line theorizing: "That sounds great. Write a game and show us." (Mateas mentions this himself, later on.)

They were hoping that Facade would provoke works in response, but it hasn't. Nor have the techniques been adopted by the commercial game world. (Although some of the most recent crop of games, such as Fable 2 and Far Cry 2, are beginning to do things like it.) Nor, for that matter, have they been adopted by the indie/amateur game world.

At this point Mateas played the demo reel.

When the creators first started planning Facade, they wanted game-like interactions -- no explicit game goal, but many opportunities for the user to pick up on a play mechanic and try to do something with it.

(Mateas mentions that in the beginning, he sternly resisted calling Facade "a game". Nowadays, sure, it's a game. He didn't say whether this was a shift in his attitude or a broadening of the expectations of the gaming audience.)

Eventually they went with a model from pop psychology, transactional analysis: Eric Berne's Games People Play. The characters Trip and Grace are playing head games at each other, using you as leverage ("Courtroom", "See What You Made Me Do", "I've Got You Now, You Son of a Bitch"...)

(See here for game examples from the TA literature. Or see any Woody Allen movie from his "miserable couples snipe at each other" period; Mateas cited Husbands and Wives.)

This gives the player several ways to dive into the game:

• the affinity game: take Trip's side or Grace's side.
• the hot-button game: find topics that provoke the characters and see how they react.
• the therapy game: try to help the characters understand themselves. (This is the most subtle, but it has the strongest effect on which ending you reach.)
• the tension level toy: the tension level in the game always rises, but you can play with it by trying to calm it or fan the flames. (Not exactly a game.)

Note that the creators don't expect players to stay in character, or take any particular role. You don't have to be a therapist. They expect players to try prodding at the edges of the story world (e.g., by talking nonsense, bringing up outrageous topics, kissing the characters, etc.) They wanted Facade to provide satisfying responses for that sort of play, just as much as for in-character or realistic play.

Nor do you have to stick to one goal throughout a session. (Although Mateas does, in some articles, describe the game as an "affinity half" followed by a "therapy half". See this article, which also gives a more detailed form of the next part of the talk.)

Facade offers multiple, mixable story progressions.

The idea is that in a simple linear interactive story, you can either Do The Next Thing (in which case the plot advances), or you Do Something Else (which fails in some sense, and the plot doesn't advance). In Facade, there are several story elements going on at any one time. If you type something that doesn't make sense in one storyline, maybe it pushes a different one forward. These storyline threads are called "beats".

I got confused at this point, because I was assuming a "beat" to be the smallest particle of performance. That's how the term is used in theater: in a back-and-forth dialogue, each line is normally a beat. (Or one character can pause a beat before replying, or so on.)

Mateas uses "beat" to refer to an entire scene fragment, in which all three characters may interact. (For example, the PhoneCallFromParents beat: the phone rings, Trip and Grace argue about whether to answer it, the player may ask them to answer or ignore it.) I am going to cheat and swap around the next few lines to introduce the concepts more clearly:

Facade contains just 27 beats, of which half might activate in any one run-through. Each beat has a chain of narrative goals, plus variations and reactions that depend on what the player does. Each goal is made of "joint dialogue behaviors", and each JDB consists of up to five lines of dialogue. (The JDB is more or less the smallest particle of performance, although you can interrupt one in mid-line, so they're not absolutely atomic.)

Facade contains about 2500 JDBs. So each beat contains about a hundred JDBs, on average.

There are three kinds of story progression, each handled by a story manager:

• the beat sequencer: manages the library of beats (27 of them), and picks which one to activate when the previous beat ends (or is interrupted).
• the beat goal sequencer: manages the goals of the currently-active beat; runs through them, or chooses variations based on player input.
• global mix-ins: a set of hot topics that can interrupt the currently-active beat if the player brings them up. (E.g., sex, divorce, alcohol, the view out the window, etc.)

Just one beat is active at a time, but these managers hand control back and forth fluidly as the player interacts. This lets Facade provide multiple, mixable story progressions for the player to mess with.

(About two-thirds of the JDBs are in beats, one-third in globals mix-ins. Then there are a small handful of JDBs which run in the background, handling "fidgeting" personality behaviors like sipping a drink or playing with a magic 8-ball.)

Mateas then went on to the central point of his talk, which was that this is a hell of a lot of work. (2500 JDBs is, what, six or eight thousand lines of dialogue?)

Writing the text is more difficult than writing the text of a play, because there are lots and lots of ways for lines (or groups of lines, or groups of groups) to be strung together. You have to think about the meshing at every level.

Mateas and Stern tried to work with a traditional playwright, but he never got the hang of writing dialogue that fit in with Facade's machinery.

There are several other areas of Facade where the implementation requires design work. For example, parsing the player's input happens in two stages. The words are parsed into a topic or phrase (as in IF). But then, the phrase has to be interpreted as an action.

For example, saying "I like [Grace's] painting" could be construed as complimenting Grace, or (if Grace and Trip are arguing about the painting) as agreeing with Grace, or disagreeing with Trip, depending on exactly when you do it. There needs to be custom logic to decide which action you've taken, which is then further customized for the ArgueOverRedecorating beat. This is all design work.

Then there's art design -- even the very stylized artwork of Facade has lots of code to manage body language and facial expressions. And so on.

Facade took two people five years to create. Mateas estimates that creating another game with the same model and technology would take a year and a half. Is this too long? It's too long for a decent feedback cycle, either in academia or among indie game designers.

Implicit is the point that the commercial game industry, which takes at least a year and a half (usually more) to produce a high-profile game, is also too slow for a decent feedback cycle.

Mateas gave explicit props to the IF community, for our strong tradition of small, experimental games. (Just to talk about myself for a bit: Shade, Hunter in Darkness, and Delightful Wallpaper each took me a month to write. Each did interesting stuff. We don't get games responding to games every month -- the annual IFComp cycle slows things down -- but it's still a high rate of creativity, with lots of people involved.)

To do interactive storytelling, do you have to be an artist/programmer? ("Artist" in the general sense, including "writer". Mateas and Stern each worked on both the dialogue and the implementation of Facade.) Mateas says he once thought so, but has changed his mind: he is now interested in how a powerful authoring system can support an artist who is not a programmer (or a programmer who is not an artist!)

Open questions for inventing an authoring system:

• how much help will it provide?
• will it help artists, programmers, or both?
• is it trying to replace a weak facility, or help the user improve his facility?

Attempts in progress:

• Storytelling Alice (Caitlin Kelleher)
• Storytron (Chris Crawford)
• Thespian (Si, Marsella, Pynadath)
• Wide Ruled (Skorupski, Jayapalan, Marquez, Mateas)

Mateas is also planning a project, "Story Canvas", in which a user enters linear narratives; the system then remixes and spins them out into an interactive drama (with the collaboration of the user).

As a final note, Mateas said that his vision for AI in interactive drama was not to replace human creation; he sees AI as being an expressive medium, a field in which artists can work.

That was the body of the talk. I will summarize some of the questions and answers that followed.

Did _Facade_ have debugging tools? Yes, lots. It's essentially impossible to diagnose bugs from the player's-eye level. You have to turn on verbose logging to figure out what's going on.

If branching story threads are difficult for writers (who aren't programmers), what is difficult for programmers (who aren't writers)? Ambiguity, maybe -- attacking a problem which has no clear definition, where you have to invent the problem statement and the solution in parallel.

I loved this answer, because that's exactly what I think of as the fun part of being a programmer. Implementing an algorithm to achieve a specified goal is work. Figuring out what the goal should be is what the work is for. And it is design work, artistic work -- art.

What about interdisciplinary teams? (That is, having an artist and a programmer work together, instead of an artist-programmer.) It's possible but Mateas hasn't done any work in that direction. It seems like it must be difficult -- all the work that an artist-programmer would do, plus the work of coordinating, communicating, and understanding each other's needs.

This would have been my question, but someone else asked it first. This is, of course, the approach that Dave Cornelson is trying with Textfyre.

Is _Facade_ sociology? (That is, is it extending our knowledge of how people interact?) Um... no.

Why the "kitchen drama" genre? Because it turns lots of game conventions on their head. No fantastic setting, no expansive landscape to explore, no physical danger. Mostly conversational interaction as opposed to physical interaction. Also: it's such a familiar genre that it's easy to tell if the work succeeds or fails.

Could menus be substituted for _Facade_'s natural-language prompt? Not easily. Facade allows twenty-ish speech acts, many of which are parameterized ("agree with X", "insult Y", "inspect object Z"). A menu system which really let you choose any available interaction would be huge and unwieldy. However, Mateas has considered other interface changes: perhaps displaying the system's interpretation of what you entered, or giving you an "undo" button to rewind time.

As an IF weenie, obviously, I see the free prompt as Facade's big strength. You can bring up any topic at any point, and the range of topics feels infinite. It isn't really infinite, but the point of having a clear genre demarcation is to let you speculate about what topics will get interesting responses, and be usually right. (So sex, divorce, the couple's courtship, Grace's art, Trip's drinking, the things in the apartment, etc, etc.)

Whew. Okay, long blog post. I hope you enjoy it. Again, I apologize for anything Michael said that I have miscontrued, misquoted, or just plain made up. It's accidental, honest.