Skip to main content

Concurrent Storytelling

This post outlines one way of understanding what my thesis is about: a tool for concurrent storytelling. For this post, I'll speak mainly in terms of narrative structure & system design rather than PL & logic. My goal is that an audience more oriented in interactive fiction than in programming languages can follow along. Please feel free to send me feedback about the accessibility of this writing from that perspective!

Previously, I've described my thesis programming language as a tool for designing game mechanics. But the term "game mechanics" is fairly broad, and in my proposal, I gave examples ranging from 2d puzzle games to parser interactive fiction. While I'm still excited about designing a core language that can express that entire range of mechanics, I've also narrowed my focus somewhat to examples that are especially illuminating to design this way.

In my INT 7 paper presented in June, I wrote about what I identified as the first solid successful experiment: narrative generation through a social simulation mechanic. In other words: describe general rules for character interaction; throw a bunch of characters into the pot; stir, and observe the (highly nondeterministic) sequence of actions that arises. Tweak the action rules until this process is likely to create something recognizably "story-like."

What I just referred to as a "sequence of actions" is actually better understood as a DAG of actions: a directed edge between actions A1 and A2 only exists if A2 depends on some resource(s) created by A1. "Resources" in the narrative setup include things like the presence/availability of characters required for a scene, but also pieces of state like "Romeo has a crush on Juliet" or "Tybalt carries a weapon."

Such a DAG is represented in CLF's notion of trace terms, and can be visualized with my coauthor's tool:

(This example interprets the story as a general directed graph (potentially with cycles), not a DAG, because it collapses the specific action instantiations into a single node. But the relevant structure of causal dependencies between actions can still be seen.)

What was interesting about this work to me was the way the concurrent structure of the trace term directly corresponded to the concurrent structure of the story. Even as a non interactive artifact, there is still an underlying intensional model of independent action among characters. This structure would be interesting to observe even for completely deterministic stories (i.e. those where characters always do the same thing and don't make choices). There is something like a choreography of character action that makes independent actions give rise to the global story.

To make this observation more concrete, consider the experimental theater piece Tamara. The play is set in the mansion of the Italian poet & historical figure Gabriele D'Annunzio, and the cast incorporates other artists and aristocrats as well as the servants of the household. The show is also performed in a mansion-shaped space, containing many and varied rooms. At the start of the show, audience members are instructed to pick a cast member to follow, and the cast disperses to different areas of the mansion to perform independent, concurrent scenes. When a character exits a room, each audience member may either follow them to the next scene they enter, or, if the room has any remaining characters, may stay and watch them perform the rest of the scene.

I have not managed to get my hands on a copy of the script (if anyone has any pointers for how to find or buy it, please let me know!), but if I were to reconstruct it myself, I would draw something looking very much like a CLF trace: each node is a scene; edges in are character entrances; edges out are character departures. (To be more precise, the scene node would need to be duplicated for every non-simultaneous entrance or departure.) The mechanics of actually synchronizing such an object so that the timing of scenes fits together is a separate issue, but one that could be analyzed atop the DAG abstraction.

So the next research question I have is: can one take the CLF trace corresponding to the Tamara script (or other "concurrent story") and have a computer "perform" it in a way that would give the player a (structurally) similar experience to an attendee of a live performance? In other words, permit the same interactions/choices afforded to the participants in Tamara?

My hypothesis is that the straightforward/na├»ve compilation of a CLF trace into Twine -- where the program DAG is literally interpreted as a passage graph -- would give such a reading. If the tuple of resources emitted by a rule application correspond to choices out of a passage, and those resources correspond to characters, then each potential choice will correspond to "following" (or remaining with) a character.

I'm hoping to test this hypothesis soon by writing such a compiler as part of #PROCJAM 2014!

Meanwhile, I have submitted a kind of related "concurrent storytelling" experiment (in collaboration with Vincent Zeng) to the 2014 IFComp.


Popular posts from this blog

Using Twine for Games Research (Part II)

This preliminary discussion introduced my thoughts on using Twine as a tool for creating prototypes for games research. I'll start with documenting my first case study: a hack-and-slash RPG-like setting where the player character has a record of attributes ("stats") that evolve through actions that turn certain resources (money, health, items) into others. I've selected this hack-and-slash example because it falls outside the canonical "branching story" domain thought to be Twine's primary use case, but it is not too much trickier to implement. It relies crucially on the management of state in ways that simple branching stories would not, but it does so in a fairly straightforward way.

If all goes well, this post may also serve as a tutorial on the "basics" of Twine (links + variables + expressions). In particular, I'll be using Twine 2/Harlowe, and I haven't seen many tutorials for this new version published yet.

To me, the main "…

Using Twine for Games Research (Part III)

Where we last left off, I described Twine's basic capabilities and illustrated how to use them in Twine 2 by way of a tiny hack-and-slash RPG mechanic. You can play the result, and you should also be able to download that HTML file and use Twine 2's "import file" mechanism to load the editable source code/passage layout.

Notice that, in terms of game design, it's not much more sophisticated than a slot machine: the only interesting decision we've incorporated is for the player to determine when to stop pushing her luck with repeated adventures and go home with the current spoils.

What makes this type of RPG strategy more interesting to me is the sorts of decisions that can have longer-term effects, the ones where you spend an accumulation of resources on one of several things that might have a substantial payoff down the road. In a more character-based setting, this could be something like increasing skill levels or adding personality traits.

Often, the game-…

Why I don't like the term "AI"

Content note: I replicate some ableist language in this post for the sake of calling it out as ableist.

In games research, some people take pains to distinguish artificial intelligence from computational intelligence (Wikipedia summary), with the primary issue being that AI cares more about replicating human behavior, while CI is "human-behavior-inspired" approaches to solving concrete problems. I don't strongly identify with one of these sub-areas more than the other; the extent to which I hold an opinion is mainly that I find the distinction a bit silly, given that the practical effects seem mainly to be that there are two conferences (CIG and AIIDE) that attract the same people, and a journal (TCIAIG - Transactions on Computational Intelligence and Artificial Intelligence in Games) that seems to resolve the problem by replacing instances of "AI" with "CI/AI."

I have a vague, un-citeable memory of hearing another argument from people who dislike the…