21 May 2010

[Literature] Tolkien: An Event Based Storytelling System

In this short paper from 2009, Satish et al. introduce Tolkien, an event-based storytelling system. This paper has an obvious link to interactive storytelling and fiction, but there could also be interesting applications to non-static or random content-generation in MMOG as well.

The authors define a story as a time-ordered coherent sequence of events. They consider a database filled with events and event-related data (video, audio, images, texts). Storytelling is simply retrieving appropriate events from the database in a particular order, and filter/adapt them to a particular audience. The filtering allows to show personal events such as birthdays to friends and relatives, music-related events to music-lovers or professional events such as conference talks to coworkers. Interactive storytelling approaches are inefficient in filtering large collections of events and most do not adapt to their audience.

[In the rest of the article, it is quite hard to understand in details what happens because the authors change their notations and names regularly. For instance, they use "objects" without having defined what they are. The "preference triple" definition has only two components. And so forth...

Each node of a directed acyclic graph represents an event. Events contain a spatio-temporal description and a semantics Itype. Edges are relations that connect events. Since relations are heterogeneous, they need different labels (found in the vocabulary L).

The storytelling process consists of two phases. First, the author specifies which events can be included in the story. Then the selected events are processed into a story tailored to the preferences of each member of the audience. (see figure below)

Story scripting

The scripting language the author can use to write the story script is actually a pseudo-SQL language. Example:

FIND $events FROM aParticularFile
FOR e IN $events
   FIND $museumsAtNY WHERE (activity = 'museum' 
                            AND datetime = '24 December 2008')
TELL $museumsAtNY

Compiling based on audience's preferences

Each member of the audience has its own preferences. For each member of the audience, these preferences are computed into a preference list, which is a a set of (pref_name, score). The score is a float between -1 (dislike) and 1 (like). For event ei and person pj, event interestingness is computed from the attributes of ei and the preference list of pj. It reflects how much an event should be incorporated into a specific viewer's story.

Story interestingness defines how interesting a story will be for a particular viewer. It is updated each time an event is added to the story. The addition of an event to the story aims at keeping story interestingness as high as possible. It can happen that the author's script requires to add an event reducing the story interestingness.


Concretely, the viewer's preferences could be retrieved from a Google Calendar, Twitter or Facebook page (hence the WWW on the architecture diagram). The description of the rest of the architecture is given by the authors quite consicely:

The script contains a specification of the story as well as instructions on how to modify it depending of the audience. The script is first analyzed by a Script Processor to check for lexical errors. This provides the Compiler an error-free script with which it creates an operator tree. This operator tree would be stored in a cache. Once the preference list of the audience is known to the Run Time Processor, this tree is converted to a series of Index lookups and queries to the Eventbase. This database contains detailed event descriptions with the relevant media items. The results of these queries are then collected and sent to the Web-UI.
-- Arjun et al.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.