As one might expect of both the author and the venue, Prospero is a typographically attractive piece of work, rendered in white text with red progression links. Links that merely expand the existing text appear in bold white, instead. The distinction between stretchtext links and movement links might be old in literary hypertext terms — I’m not certain — but it’s not consistent in the Twine and Undum world. I find it very useful to know whether the link I’m clicking is going to tell me a little more information or whether it’s going to move the whole story forward.
Prospero is also a beautifully textured piece at the level of prose. Dias has a gift for the specific detail — seen in Mere Anarchy in the variety of magical tools available to the protagonist, or here in Prospero in the scenery and the protagonist’s possessions.
The original Poe story goes like this: there’s a plague in the land, but the prince Prospero has a lot of money, so he walls himself up with his favorite courtiers and various resources, and they try to keep the plague at bay. (In contrast with the religious community in Vespers, he seems untroubled by the implications of shutting out the rest of the world.) During an elaborate party Prospero throws, a creepy masked figure attends, who turns out to be the embodiment of the plague. Despite their decadence and indifference to the world outside, the whole party dies. It is possibly a story about the inevitability of death, or possibly about the comeuppance of the wealthy classes.
Dias’ version keeps a great deal of that structure, but moves the action to something closer to the modern day, with cars and modern architecture and electric lighting. He casts the player as the Red Death, with the ability to choose the final outcome. This feels like a surprising choice, given that Poe’s version is so much about inevitability. And I think it would have been fatal to the concept of the original story to give Prospero any choice about whether he lived or died. As the Red Death, we can move among different parts of Prospero’s party, meet different party-goers, and decide whether to spare them all, or one or two favored exceptions, or no one.
Two of Dias’ previous projects, Mere Anarchy and Terminator Chaser, deal with resistance against wealth and power. Prospero raises some of the same issues, particularly the idea of the rich who imagine that they can remove themselves from the rules that apply to everyone else. In contrast with Mere Anarchy, it is comparatively merciful; it allows you to grant forgiveness, if you’re so moved. But I found that I didn’t entirely want to. Perhaps my own favorite ending was to spare one woman who seemed not to belong to the wealthy decadence around her: this suggested a universe with some moral discrimination.
If you like Prospero, you might also enjoy Peter Nepstad’s adaptation of stories by Lord Dunsany, or Caleb Wilson’s anachronistic gothic Six Gray Rats Crawl Up the Pillow.
Setup: easy, assuming a certain amount of tech savvy; otherwise probably rather daunting. Raconteur requires you to install various packages yourself. This is very straightforward as such installations go, and some users will probably already have some of the elements. (Raconteur depends on Node.js, which I already had on my machine.) Still, this might be daunting to authors who are used to website-based tools or self-contained IDEs. The instructions for Raconteur assume that the user will, for instance, know how to invoke sudo when appropriate. You will also need a text editor to edit the text file that defines your game.
Documentation: depends what you’re looking for. Raconteur has clear, searchable documentation designed primarily as a reference for each of the programming functions of the system. It makes the most sense if you already know a little bit about programming terminology and the capacity of Undum. (At several points it sends the reader off to refer to the Undum documentation instead.) If you’re approaching it from the perspective of “how do I achieve behavior X?”, it may or may not be easy to find what you want. EDITED TO ADD: Dias also has some tutorials on his blog, however, as he notes below.
Rapid feedback: good. Once you’ve followed Raconteur’s instructions to download and install the necessary scaffolding, you can type GULP SERVER at the command line. This will open up a browser window that shows you the current behavior of your game, and that automatically updates every time you save changes to the text file defining that game. This gives the writer a nice fast cycle for viewing the result of changes and for noticing when something has gone wrong.
Visualization: not offered. Raconteur doesn’t provide any way of visualizing the structure of the story you’ve built. Contrast Twine’s node-based presentation or inklewriter’s narrative maps (or, in parser-land, the various indices in the Inform 7 IDE). I think this wouldn’t be too hard to provide at the same level as the rest of the Raconteur toolkit — you could have a script that parsed the “choice” lines of your game script and then spat out a .dot file that the user could then view in Graphviz. This would then also auto-update itself when the user updated the content of the story file.
Presentation control: solid. There are HTML and CSS files associated with your project and you can go mess with them if you want to, but they start out looking pretty decent even without changes. There’s more freedom to change up the look than with inklewriter, StoryNexus, ChoiceScript, or Seltani; much less fuss than with Inform. I know you can make advanced tweaks with Twine, but the Raconteur/Undum model feels closest to other kinds of web development.
Automated play: not available. Some systems (Inform, ChoiceScript, Versu) let the author create one or more test scripts to verify the behavior of the game file, and/or offer the ability to auto-play the game many many times with random inputs, in order to make sure that there aren’t any dead ends or crashes. Raconteur/Undum does not provide this capability, so everything has to be tested by hand. This is not a huge deal if you are writing a small project (and Prospero is reasonably small). It becomes more of an issue the larger your work becomes and the more you rely on Undum’s procedural features (about which more in a minute).
Prose variations: okay, could still be a little smoother. Raconteur provides facilities to do replacement of text, cycling, and stretchtext/expansion (where new words are placed within an existing paragraph). It allows cycling text in a way that stores the data for later (look for “leaveMotivation” in the Prospero code for an example), or in a lighter-weight way that doesn’t preserve any state.
What it doesn’t do is make all that really easy to type casually as part of your normal sentence-composition flow — you still need to type some fairly code-like things into your text, and then go add additional information elsewhere in the script. In my experience getting to the level where the author can type sentence variants naturally in-line makes a huge difference to how much those features are used.
Still, my experience with this was more positive than my experience trying to implement similar effects in Twine (namely: “search a bunch of different web resources for a macro to handle X or Y, then discover it’s not working quite the way you hoped but that the macro formatting makes it exceptionally hard to modify yourself”).
The very baseline task of adding a new link to a new piece of text is also more effort than in Twine.
World model: no more than Undum provides (very little). By “world model”, I mean support for maps, locations, inventory, character traits, and so on. Parser IF systems tend to provide a lot of world model support; choice-based systems typically provide little or none. Undum has a concept of qualities that can be displayed to the player in the corner of the screen. Raconteur lets you check and manipulate these qualities, which is enough to let you implement a simple inventory system or RPG-style skills. However, it makes no default assumptions about the kind of world model you want to use, nor does it (to the best of my knowledge, anyway) provide the equivalent of ChoiceScript’s fairmath for manipulating stats within a set range. You could do all this yourself if you wanted, but Raconteur doesn’t offer any special help with it.
Narrative model: no more than Undum provides (but that’s more than you might have expected). By “narrative model” I mean some kind of abstract model or organizing principle about what story elements are allowed to happen when, going beyond hand-authored branching at all points. Inform has scenes. StoryNexus and Varytale have storylets with prerequisites about when those storylets are allowed to appear. inklewriter, Twine, and ChoiceScript don’t really attempt to roll in anything like this.
Undum offers a feature somewhere between StoryNexus’ full quality-based-narrative approach and the handrolled choices of other systems. If you like, you can specify that a passage of text in Undum (called a Situation) may be followed by any choice with the appropriate tag. It also allows the author to write rules about whether a given situation should be selectable, visible but not selectable, or not visible.
This means, for instance, that you could have a number of different situations all tagged “#escape” and representing different ways of getting away from the boss monster. You could then control which of those escape options are actually offered to the player, for instance by adding a “canView” requirement that only allows the player to see the Escape by Motorbike option if they previously added the motorbike to their inventory. When you also consider that scenarios can carry multiple tags, this begins to feel a bit more powerful than the standard business of making the author write every possible transition and gate by hand.
But, of course, this is also precisely the kind of context in which some automated testing would be really helpful.