Deikto user interface in Erasmatron storytelling engine

Just came across this discussion of the Deikto component of Chris Crawford's Erasmatron storytelling engine:

Erasmatron 4 is being built around Deikto, a radical new approach to user interface. The concept harkens back to the concepts I originally built into the game "Trust & Betrayal" 15 years ago, but now I am taking it much further. The user builds commands by building sentences on the screen using popup menus.

Not sure if it is really that radical, but I thought it might be of interest to the LtU readership.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Tiles in Squeak

Reminds me very much at first blush of Squeak's eToy tiles, in which you program by dragging and dropping tiles which refer to objects, actions, properties of an object (which can be extended by creating your own instance variables), etc. Really cool.

The use of Squeak as a basis for a storywriting tool has been bandied about but as of yet there's not much produced in this regard. Should be possible.

Shall I consider Erasmatron a

Shall I consider Erasmatron any different than an adventure game's point'n'click interface? because that type of interface has been around for long time: click the item, then click one of the verbs available, then click another object or person to perform the action.

And this kind of interface is already present, now that I think of it: you select the item that you want to process with the mouse, then press a button that does something to the selection, or bring up a context menu with options.

I personally wouldn't like my context menus to be more than two levels deep. Otherwise it gets difficult and slow.


Well, Erasmatron is an interactive storytelling engine. It's fair to say that it goes quite far beyond traditional adventure games. Read the papers and articles for more info about the system as a whole and the approach to interactive narrative (also look at things like Façade and the Oz project for other approaches; there are quite a few). Deikto is just an interface for specifying some of the behaviours of characters within a story, as I understand it. In that sense it is similar enough to other programming tasks to be of interest to LtU.

[Edit: it's probably also worth pointing out that Deikto is an authoring interface, rather than an experiencing interface as in adventure games.]

A storytelling DSL

it's probably also worth pointing out that Deikto is an authoring interface, rather than an experiencing interface as in adventure games.

Well, not long after writing that, I noticed that I had this exactly the wrong way round; Deikto is the user interface for someone experiencing the interactive story. Authors use other tools like the Scrypt Editor to specify the behaviour of verbs. There are some thoughts on language design (scroll down to the title "Scripting Languages"), which include:

  • Logomorphic languages, not alphabetic languages: this seems to mean that a language editor should only allow you to manipulate complete pieces of abstract syntax, rather than typing in individual characters.
  • Hard data typing: limiting data types to just eight primitives (Actors, Props, Stages, Numbers, Booleans, Verbs, Events — I only count 7). This seems to imply that there is no way of building your own types in the language. Oh, and these types are colour-coded to make "the concept of data typing more digestible to the artist"!
  • Poison for error handling: any script that errors at runtime is marked as poisoned and then is ignored for the rest of the story.
  • No flow control: explicit loops are replaced by higher-order functions, such as a PickBest which picks an item from some type that satisfies some predicates.

There are lots of little snippets around in the writing about how the language was designed. Lots of these seem like new names for fairly well-known ideas, but it is interesting to see the design of a language for storytelling. Most interesting perhaps is that a lot of the ideas for making the language easier for artists seem to coincide with ideas that have been applied to general purpose programming (e.g. use of higher-order functions instead of explicit loops, more structured editors, etc).

not really related, but not w

not really related, but not worth a separate thread - i'm currently experimenting with svg in xul as a user interface for graphical programming.

svg is an xml based language for constructing diagrams. the dom tree can be manipulated using javascript, giving animation.

xul is an xml based language for constructing user interfaces used in firefox.

since xul can include svg you can, in theory, use xul for providing "standard" components like menus and svg for providing a canvas on which more complex graphs (in my case) can be constructed. the event model, javascript environment, dom model are all shared, so the result should be pretty seamless.

in practice, it's not quite that easy, because svg support in xul/mozilla is incomplete. so the two dom trees are largely separate (events from the svg don't propagate up into the parent xul tree - this is because xul doesn't have zoom/pan support, so the svg is in an iframe, which isolates the content dom).

but it is working - currently i can add/delete items in the canvas using mouseclicks.

and xul also integrates with xpcom which is a minimal c++ subset (no exceptions, for example). so the execution of the final "program" can be executed by c++ code.

i don't think anyone here is much into grpahical programming, but if you want to use this approach give me an email - what i've got done already would save you some time.

you need the latest (like, nightly builds of deer park) firefox browser (the application appears as an extra item on the "tools" menu which launches a separate window).


I didn't look at this recently but the use of SVG as a programming model looked rather cool when I did.