July 16, 2003

AI and authorship

by Michael Mateas · , 12:14 pm

The post Responsive Narratives (and its comments) raises the question of whether there lies anything in between brute force authoring approaches and building a human-level AI. This question is important not just for interactive drama, but for Expressive AI (AI-based art and entertainment) in general. In a brute force authoring approach, the artist lovingly hand-crafts material (e.g. animation, text, images, etc.) for every possible context, for all possible interactions. In the AI-complete approach, the artist somehow describes their intention at a very high level (e.g. the high-level motivations of characters), and the system auto-magically grounds this high-level description with concrete representations for different contexts (e.g. generated animation, generated text, generated images) and for all possible interactions. There are good reasons to seek a middle ground besides the current technical impossibility of AI-complete approaches.

Hand-crafted material tends to be high quality because the artist can directly employ her skills in shaping the material. In AI-based art what you want is to somehow have the AI architecture help you generate material (manage combinatorics) while supporting fine-grained authorial control. This seeming contradiction can be resolved by approaches that provide multiple levels of abstraction, and allow the author to move up and down these levels of abstraction while creating material. In Façade, this plays out by having several different custom languages for authoring different parts of the experience, as well as different subsystems that are built using these languages. For example, each dramatic beat has a collection of character goals and behaviors that are active during the beat. Some of these goals are special “beat goals”, dramatically significant moments necessary to carry out the beat. During the beat, these beat goals are sequenced in such a way as to carry out the beat while responding to player interaction. Goals and behaviors are written in ABL, a custom behavior language for believable agents. The “specialness” of beat goals, their ability to dynamically resequence as player interaction occurs, is handled by additional code written in the ABL language. Even just within the ABL code in Façade, as authors we moved between several hierarchical levels, writing the code that gives beat goals their special properties (this code is infrequently changed), for each beat sometimes writing code that provides custom sequencing logic for beat goals within that beat, and for each beat writing the beat goals and behaviors themselves that carry out dramatically significant behaviors.

If one views AI-complete approaches as the holy grail, rather than seeking a middle ground, this leads to a different technical and artistic agenda, one focused on automating the author rather than providing a rich combinatoric authoring framework. For example, when building an architecture for dramatic beats, such an approach might try to capture some general logic of dramatic beats, seal this general logic into a black box that automatically manages activity within a beat, and force authors to use this black box. Of course authors would immediately want to do things that the “general logic” doesn’t handle. Viewing the problem as “automation” tends to lead to rigid black boxes. An author-centric approach leads to soft, permeable hierarchies and custom languages.

I agree with Andrew that high-agency interactive drama will inevitably be technology-heavy. There is no magic design bullet that, if you just conceive of interactive story the right way, allows you to build rich interactive dramas by writing a bunch of C code using standard techniques. When we started this project, I think Andrew thought that we could get maybe 50% of the way there through good interaction design and story design. He now feels that good design, on its own, won’t get you even that far. It’s interesting that for me, I never thought that good design, on its own, would get us anywhere. That’s partly because, in my approach to AI-based art and entertainment, the design thinking is actually done through an architecture – that is, the AI architecture and the design co-evolve. Without the architecture, the only design work you can do is some kind of wish list. But the detailed design requires this architectural co-evolution. Even the wish-list isn’t really understood until the architectural work begins. The tradeoffs between items on the wish-list aren’t apparent without an architecture. And the architecture suggests new design directions, new conceptual opportunities, that the artist doesn’t even conceive of except when thinking through code.

In this post, Andrew describes his design approach for writing beats in Façade, emphasizing that he starts with a piece of paper, far from the details of architecture and code. I similarly start with a description of what I want a beat to accomplish. But I claim that we wouldn’t be able to do this except that we’ve already reached a stable state in the co-evolution of design and architecture. When we write these high-level descriptions, we’re doing it with a deep understanding of beats, beat goals, natural language contexts, and other abstractions defined by our architecture. We wouldn’t know how to write these high-level descriptions without this architectural understanding.