The content is essentially the same. Instead of typing the keywords you click on hyperlinks that are highlighted in the text and shown in a separate list next to the story. A clickable, dynamic map of locations is displayed on the opposite side. There’s background music, but sound support is still a bit shaky in some browsers. Internet Explorer 7 or earlier will not work.

It uses the yet-unpublished version 1.2 of Vorple and demonstrates the use of the button interface in the map and in the keyword list, and tooltips that are displayed as brief instructions and as labels for the map. Under the hood it uses disposable links and other similar features. It’s also using the IF Recorder plugin, probably the first time for an Undum story.

• Play online
• Source code

Here are the major new features:

• Works with Undum. Now someone might wonder why anyone would want to record hypertext fiction stories, but even if there’s less need to check what kind of input readers give, other reasons still apply: you might want to get statistical data on which choices the readers make, or see if the readers give up at some certain point in the story, or even find out if some of the choices just don’t work as they should.
• Web interpreter template for Inform 7. There’s a ready-made Inform 7 template to use with the “Release along with an interpreter” option. This makes it easier to start using the recorder although you still have to set up the database and the server scripts.

The project’s new headquarters are at Github along with the instructions and downloads.

Monty Hall Paradox

An implementation of the Monty Hall paradox, this example lets the player guess which door holds the best prize in a game show. The correct door is randomized and the story text changes according to the player’s choices. The player is asked to give their name before the story begins and the name is later used in the story text.

• Play online
• Download
• JavaScript source code

Combat

A simple randomized combat system. The player character and NPCs are given attributes and combat is resolved by throwing dice. The player has health potions that restore hit points.

• Play online
• Download
• JavaScript source code

• Play the game here
• Annotated source code: zipped package or the JavaScript file and the HTML page (“View source” in your browser)

The plugin saves more than just plain text: it preserves text formatting and saves status lines as well, so the transcripts look (almost) the same as the actual game. (See this example of Bronze with status lines, colors and text formatting. Note that Parchment uses small caps in place of bold text.) The saved transcripts can be viewed with or without the status lines. In addition when the game waits for a single keypress, non-alphabet characters like enter, space and arrow keys are marked in the transcript.

There’s a live demo with a transcript viewer available. Games played in the demo installation can be seen in the viewer.

The plugin and accompanying tools can be downloaded from Google Code where you’ll also find installation instructions. Only Z-machine is supported at the moment, Glulx support will be added later.

Looking at the data from before and after the update, here’s what happened to the total amount of invalid commands:

In addition to new synonyms the update includes a new class of error message. The earlier version responded with “That is not a keyword the story recognizes” to all invalid input. The update shows the same message when the player gives only one word as input, but if the player had given more than one word the error message is ”Please type a single keyword to advance the story” followed by a list of available keywords.

This was inspired by the different ways people had given invalid input: some gave traditional IF commands, some typed more than one keyword at the same time. In addition to the new error message giving more accurate instructions on how to interact with the story, it also explicitly lists the input it accepts, leaving no room for confusion. I looked at how this affected “ragequitting” after giving invalid multiword input during the first turn:

(The sample set is so small that the results fit well within error margins, but they are still nice numbers to look at.)

In addition to reducing the total number of invalid input, the amount of error messages per game dropped as well. In the previous version about half of the players didn’t encounter any error messages while playing, but more than a quarter bumped into them more than once, 10 percent more than three times. In the latest release the no errors group jumped up to two thirds and those who saw more than one error message dropped to less than 10 percent.

It was expected that by making the parser more error tolerant and helpful the percentage of people who played the story to completion would go up, as well as time spent with the game, measured here with the average number of turns per game (not counting those who quit without typing a single command).

As the graphs show, the percentage of people who quit after one turn or right after the intro doesn’t show any significant change. There are people who don’t find this kind of medium their thing and there’s not much that can be done to make them keep playing. in the other end of the scale are the hardcore IF fans who play anything they can get their hands on. Most players fall somewhere in between and to keep them engaged requires both a good story and smooth gameplay.

Betatesting can do a lot, but analysis of real life transcripts can reveal surprising things that have a significant effect on how players enjoy the game. Who would’ve thought that invalid one-word and multiword input should have different error messages? What would a similar stack of transcripts from games with full parsers reveal?

The good news is that I’ve almost finished with making the transcript recording functionality an actual Parchment plugin. It’ll be released soon, first with Z-machine support and later with Glulx support, and even later with statistical tools to make all kinds of graphs like the ones presented here.

My entry to the fair is Vorple, an interface layer to be integrated with existing web interpreters and an accompanying UI library. It would work together with Parchment, Quixe, Undum, or some other web interpreter or system that would provide the engine running the actual game.

Vorple has two main features: giving games access to JavaScript and Vorple’s library, and providing ready-made functions and features that could be easily added to games. For example, an Inform 7 author could do something like this:

To players it would be just like any other web interpreter, but for authors Vorple would provide means to break free from the virtual machine into what is admittedly another sandbox, but one with a lot more possibilities. Authors who want total control could insert JavaScript commands that control the user interface or add whatever JavaScript/HTML elements they wish. People who don’t want to mess around with JavaScript could use the ready-made elements and functions like shown above.

The players would benefit of an independent UI layer even if the game author wouldn’t use any of Vorple’s features. You could use independent JavaScript widgets like notepad or (auto)mapping that would work with every game.

An interesting side effect would be that if Vorple were made to work together with Parchment and Quixe it could act as a general-purpose interpreter like Gargoyle or Zoom, making the difference between Z-machine and Glulx even more invisible to the player.

The features demonstrated at PAX will be:

• Keeping the transcript clean: hiding error messages and UI hints the next turn, showing meta information (about, credits) in popups
• Changing the content of previous turns. In the demo you can change temperature and speed units between metric and imperial. Doing so will change the previously displayed units as well.
• Bubble popup hints, as seen in the screenshot
• Linking to Twitter
• Sending commands to the parser from the user interface, either as normal commands, silently, or as partial commands (for example clicking on the word “examine” fills the input line with that word and lets the player to add the noun)
• Images in different layouts and popups
• Playing videos (local videos for now because internet access at the demo event might be difficult to come by, but YouTube videos would work just as well)
• Accessing and displaying the system time (although it’s not that amazing anymore now that Glulx supports this)
• An interactive version of the How to play IF card!
• + more

This is just a taste of what the library will include. The best part of course is that because the user interface and the game could communicate between each other the author would be free to come up with all sorts of interesting new interfaces and game mechanics outside the standard set of features. For example I had an idea of a time travel game where travelling into the past would actually change the content of previous turns that happened in the future—this would be impossible in any of the current interpreters, but perfectly doable with Vorple.

As said Vorple will be presented at the demo fair at PAX East in Boston this Saturday starting at 8 pm. If you’re around come take a look; you won’t need a PAX badge. The demo will be posted online later, but I’m travelling during March so it might take a couple of weeks.

Vorple won’t be out for some while as it’s currently just a bunch of stuff thrown together to demonstrate the basic concept. In the meanwhile you can follow @VorpleIF on Twitter for release announcements and updates on the progress.