I’ve written several times about the development of a client-server Interactive Fiction platform. Parts of this system are called FyreVM, Zifmia, and other parts are just plain old web application development. FyreVM was created years ago and is a very stable implementation of the Glulx virtual machine. Zifmia is a state-machine wrapper that allows FyreVM games to run on a web server with all of the commands coming through AJAX calls and output returned as JSON. I wanted to provide a more detailed view of the new Textfyre system’s construction.

Technology
I spent a good portion of my spare time last summer working through the technical issues of a client-server implementation of FyreVM/Glulx. I’d had a very rough prototype, but last summer I sanded down the rough edges and came away with something solid. There were still major issues to resolve, including the design and persistence, but eventually I was able to send commands into the server-side engine and receive story data and display it on a web page. The next step was to turn it all into something “enterprise” ready. Something that initially could handle hundreds of users, but also be able to scale.

The first thing I worked on is making a reasonably clean “library” of JavaScript and jQuery code that was layered and maintainable. I then took all of that code and implemented an ASP.NET MVC 3 website. This allowed me to implement Clean URL’s, but also has a built-in capability for creating RESTful web services. It also allows me to continue using C#, since that’s how FyreVM and Zifmia were coded.

An additional benefit to using RESTful web services for all game play is that other types of clients can be developed later (iPad, Android, Windows 8 Metro).

Storage
One of the primary differences in this approach is that all of the game data is stored on the Textfyre servers. You might call it Cloud-IF since the player could conceivably play the same game from many computers and devices without any concern for saving, restoring, or managing files. The system stores the results of every turn and provides a user-interface that lets the player “jump” to any historical turn. The user interface even tracks branches, so the player can see where they jumped and where they changes paths.

This is done using Eloquera, an object-oriented database. It allows for very simple storage and retrieval of session data.

Design
Not to stress this too much, but designing a modern user interface for Interactive Fiction is very difficult. Juhana Leinonen set the standard with his Vorple demonstration a year ago at PAX East. Jon Ingold and his partner Joseph Humfrey are doing some amazing things at Inkle Studios (Note: Jon Ingold is the co-designer and writer of Textfyre’s The Shadow in the Cathedral). I’d like Textfyre’s offering to be capable of similar results.

Styling
With that in mind, I’ve left all of the styling capability of this system to external resources. I considered adding a bunch of CSS capability to an Inform 7 extension and asking the author to work under those constraints. After a few passes, this was simply tiresome and very much the wrong direction. I designed the IO of FyreVM to be design neutral for a reason. I believe firmly that content should not know about how it is formatted; outside of emphasizing text with boldface, italics, or similar in-line styles. Any placement or styling beyond that should be handled by the content type. Since FyreVM allows the author to channel output to different content types, this is easily handled in the “interpreter”. In this case, the browser is our interpreter. We simply take content types and associate them to browser placement and styling.

Templating
The next assumption I made was that whatever template I designed was only going to be the default or standard template. There are a set of guidelines for authors or anyone interest to develop their own template. It may be daunting for an author and certainly a non-programmer to develop a template using HTML5, but it’s certainly not impossible or even improbable. I think the results of Vorple and Inkle Studios is confirmation that the IF world has the talent.

The standard template is very similar to a standard desktop interpreter with a few changes. Images can be identified by the game by filename and embedded in-game play, a map can be identified, and a few other visual elements allow interaction with the game, including displaying the player’s current inventory.

It would not be difficult to modify the standard template to move things around. Swapping in a new CSS file could change the entire design, similar to the way CSS Zen Garden works.

Web Services
I mentioned that game play is implemented using RESTful web services. Each service is called with a Clean URL and returns JSON (JavaScript Object Notation). HEre is a list of all of the possible web service calls (all executed through HttpWebRequest, always from a jQuery command):
Register player – /Register/{username}/{password}/{nickName}/{emailAddress}
Player login – /Login/{username}/{password}
Is Authorized – /IsAuthorized/{authKey}
Validate Player – /ValidatePlayer/{validationId}
Session Start – /SessionStart/{authKey}/{gameKey}
Session Get – /SessionGet/{authKey}/{sessionKey}
Session History – /SessionHistory/{authKey}/{sessionKey}/{branchid}/{turn}
Session Command – /SessionCommand/{authKey}/{sessionKey}/{branchId}/{turn}/{command}
User Session List – /UserSessionList/{authKey}
List all installed games – /Games

Game Data
When the player enters a command, it’s sent to the Session Command web service. This service executes the command and gathers all of the data. This data has always been called “Channels”, but you could also call it labelling. When the author is emitting text in a game, there are different kinds of text. FyreVM automatically determines most of the types and labels them accordingly. So the room title and description get labelled “Main”. The room title also is labelled “Location”, the score is labelled “Score”, time “Time”, turn “Turn”, and so on. The list of standard labels includes:

Prompt

This is the text that precedes the prompt. In a standard IF game, this has always been “>”, but in our system, it can be any normal text.

Main

This is the main text of the game, which includes any ‘before’ text, the location title and description, any object lists, and ‘after’ text.

Time

This is the time of day within the game. It’s not always implemented or used, so the standard template looks at the Settings text to see if it should be displayed or not.

Location

This is the location name.

Chapter

If a game implements chapter titles, this is that text.

Credits

This is the list of credits for the game.

Hints

This is the current list of hints for the game. This data has to coordinate with the browser properly, so modifications to the standard template are required.

Score

This contains the current score, if one is offered. The Settings text will identify if a score is displayed or not.

Title

This is the game title.

Prologue

This is the text displayed in the ‘When play begins’ rule of the game.

Turn

This is the current turn number.

Tips

This is a tip for the player.

Version

This is version of the game.

Verb

This contains the verb in the last command.

Tutorial

This contains tutorial text.

Maps

This contains a map image filename or some other text to show a map to the user. The standard template uses images (that change throughout the game).

Dead

This is the text emitted when the game has ended.

Settings

This text contains information on whether other types of text should be displayed or not.

Authors can dynamically label alternative content, which can in turn be displayed in the browser based on author preferences.

All of this data is returned in JSON and looks like this (this is an excerpt from a running version of Cloak of Darkness):

"Channels": [
{"Name": "PLOG", "Content": "Hurrying through the rain-swept November night, you\u0027re glad to see the bright lights of the Opera House. It\u0027s surprising that there aren\u0027t more people about but, hey, what do you expect in a cheap demo game...?"},
{"Name": "CRED", "Content": "Cloak of Darkness by David Cornelson\nGame Engine (FyreVM) by Jesse McGrew\nZifmia by David Cornelson\nInform 7 Programming by Emily Short and Graham Nelson, with Channel IO updates by David Cornelson.\nSpecial thanks to Graham Nelson and Emily Short for all of their hard work on Inform 7."},
{ "Name": "SCOR", "Content": "0"},
{ "Name": "TUTR", "Content": "You might try going WEST from the Foyer of the Opera House"},
{ "Name": "TIME", "Content": "540"},
{ "Name": "LOCN", "Content": "Foyer of the Opera House"},
{ "Name": "PRPT", "Content": "What do you want to do next?"},
{ "Name": "MAPS", "Content": "cloakmap-dark.png"},
{ "Name": "MAIN", "Content": "You are standing in a spacious hall, splendidly decorated in red and gold, with glittering chandeliers overhead. The entrance from the street is to the north, and there are doorways south and west."},
{ "Name": "TURN", "Content": "1"},
{ "Name": "TITL", "Content": "Cloak of Darkness"}
]

There’s a framework in place to convert the JSON data into a known JavaScript class, so “PLOG” becomes game.Prologue and “LOCN” becomes game.Location. This can then be displayed by updating the web page through a jQuery command, like this:

Summary
The new Textfyre website is nearly completed and in coordination with several eReader publications, is due out soon. It’s taken a long time to work through all of the technical details, but I think the results will be very attractive to Interactive Fiction game players as well as authors, teachers, and educational content providers.

Overheard on ifMUD last week was an observation-only comment about Zifmia being vaporware. I was amused by the comment, since I have made great progress on the entire project in the last few months. I just haven’t been talking about it all that much. Since there has been no demonstration of Zifmia and no public discussion, the vaporware comment was accurate.

However, that is all about to change. I have a working system and although I’m slightly side-tracked with a potential investor meeting on the 16th, a beta of Zifmia is coming this month. The beta will be a replacement of the entire Textfyre.com website into a game portal for Interactive Fiction developed with Inform 7, FyreVM and Zifmia extensions, images, js, css, and html.

A version of Cloak of Darkness will be present in the beta along with a demo version of Shadow in the Cathedral. A full version of Shadow will be added when the payment system is ready. Other features will be added over time, including the ability to upload your own games and web provisioning. I intend the beta of the new Textfyre website to be an extended period of time, to let the kinks iron out.

One of the first tasks will be to adapt extensions for the “standard” Zifmia design, which will be very simple. You can see a functional sample of the latest standard design at http://textfyre.com/design/zifmia-design-2.html. The opening page is a templated “prologue” and following a press of any key, the main template is displayed. Currently there is a column of main text, some spot art, fly out text windows on the left and right, a command line text box, along with map and hint buttons.

Templates are based on straight HTML5/CSS3 using jQuery and various jQuery plugins. I’ve tested this design with IE9, FF 5, and Chrome. It does not work on mobile devices as I see that as a separate template entirely. I plan to investigate jQuery Mobile to help with that work.

I plan to move forward with this design and implement an Inform 7 extension to implement the various pieces. It shouldn’t be too hard to create simple Inform 7 markup that translates to html with known classes.

Since getting the service layer running for Zifmia, I’m now focused on the client side look and feel and getting a first iteration completed by PAX for the IF Demo Fair. To that end, I’ve come up with a first draft of the wireframe layout.

As you can see, this is very different from previous Interactive Fiction UI designs. There are tabs on the right for different types of content. Popup menus that can auto-enter commands relative to a word in the text, a history of commands and recommended commands, a movement panel with all of the common directional verbs for auto-entering, a list of users (the lamp represents who is in charge of entering commands, everyone else is a watcher), an achievement panel, and a description panel (which will show the results of examine, search, and similar commands without using a turn – everything in-scope is known for every turn).

I’ve tried to keep the focus on words and reading as opposed to images, but this the first foray into developing a Zifmia web client and I wanted to try to stay somewhat generic. Future, game-specific user interfaces could have clickable maps, and other features. Eventually, Zifmia will allow a UI package to be uploaded that contains javascript, css, html, and images and tie the package to a game. Then when someone starts that game, the game UI package is used to display the game.

There is still one piece missing and I’m still pondering the implementation. The user can review previous turns. This data is stored on the server. So if the user has played 100 turns, how do we show this and how can we make it easy to select a previous turn or allow paging? This is a purely UI question. Technically, retrieving any turn is a simple AJAX call.

Since we’re using jQuery to design pages, we should be able to offer jQuery themes too.

I will also be adding oAuth to protect the service and offer pay games, web chat, and more.

I’ve been slowly working on the new vision for the Textfyre.Com website. It’s very much a work in progress and in the very early stages of development. If you’re concerned about design aspects, be patient. There will be artwork and prettiness added later. The site is going to be a portal for games and that functionality is at the core of the changes. There will be a lot of AJAX and Web 2.0 features and a new AJAX based FyreVM implementation called Zifmia (open source). Here’s the plan so far:

Game Portal Features
Zifmia will provide the ability to offer Interactive Fiction in the same way that a website offers web pages. Using AJAX, we’ll send commands to a server dedicated to Zifmia games (based on a modified stateless FyreVM engine). The web page will receive the response from the Zifmia server in JSON format, which will be stored locally using jStorage, unpacked, and written to the web page as required. There will be no scroll bar text window. Each response will be displayed in full in the main text area in the center of the portal. Each “turn” or response will be saved as history to local storage. There will be user interface features that allow the user to easily page through the history of their game play. This will happen by pulling the appropriate JSON data out of local storage and displaying it on the web page. If the user closes their browser, they can always come back to the same state they left the website in, carrying on with their game.

Game Search Features
At the bottom of the page there is a rectangle with the word “menu” as a placeholder. This area will be a place to scroll horizontally through game titles. The game titles will be represented by their cover art. When clicked, a light box will display the information about the game, which allows the user to start the game immediately. If the user is in the middle of a game, its state will be stored and we will start the new game automatically. What’s really cool is that we will keep track of all of the “games in progress” somewhere on the web page. Jumping to any game in progress will be a single click.

Membership
Similar to the previous website, we will have people register and login for certain types of content, mostly paid content, but there are other (legitimate) reasons for asking people to register. Anyone that’s registered and logged in will have access to paid content, beta versions, insider news, and more.

Cross Device Delivery
The biggest change to Textfyre is that it will focus on delivering games (ours and others) to many mobile devices in addition to the traditional desktop and laptop devices. The portal will prominently identify all of the current devices and available content.

Content
Another big change in Textfyre.Com is that we will begin to widen the type of content we promote and sell. This will include more mature themes and may include games with profanity, violence, and mild sexual themes (nothing explicit!).

Partnerships
Textfyre.Com will partner with other publishers and content creators to provide a wide variety of content.

Advertisement
Textfyre.Com will begin to carry skyscraper advertisements that will be located on the sides of the portal.

So somewhere way back a couple of years ago, Jesse McGrew helped build FyreVM with a new IO layer we called Channel IO. This has turned out to be extremely useful, especially when building different kinds of user interfaces.

Recently at work I’ve been tasked with designing and building a customer service chat system. The best way to do this is using AJAX Long Polling and the best way to do that is to use a Comet library based on the Bayeux Specification. All of this is some older networking patterns being reworked into existing and future HTML specifications and the underlying pattern is a publication subscription model.

All of my research on Comet got me thinking about Channel IO and that got me thinking about Zifmia and how best to serve many users a particular IF game or to even allow them to play the same game at the same time. It also got me thinking about how we implement output in Interactive Fiction.

Leaving the Zifmia impact for another post, I want to focus on IF output and this has been something I’ve been thinking about for awhile, even outside of the Comet stuff.

In an IF game we have different targeted locations of output. Channel IO handles this great. We can direct text to a main channel, a location channel, a score channel and in the UI place these pieces of text where we want them. Now I’m wondering if we can’t dig deeper into the IF engine and provide a completely different output paradigm. I believe Emily and a few others have actually done things like this in their code, but I think the pattern should be extended as a standard layer.

The idea is to output textual parts given some meta data. Let’s focus on what we consider main output. anything that shows up in the main window. However, we want this process to work for any channel.

The different kinds of parts include sentences and items with descriptions. The meta data might include things like “sentence beginning”, “sentence end”, sentence middle”, “can be preceded”, “can be followed”, “must be listed separately”, and “must be output with a pattern” (and the pattern is somehow included in the meta data).

From here we allow the author to identify pieces of output beyond using just a “say” or “print” command. Possibly:

say “From the crib you hear a wimpering toddler” as sentence-beginning, can-be-preceded.

The result is likely to be some type of markup that has to be processed within the VM.

The idea is that within the IF game, the author is less concerned about format and more concerned about content. The question is, can a post-output processor be smart enough to string everything together properly? Does this break down the talent of an author or does it enable them to do interesting things?

The reason I bring all of this up is that I continue to think of alternate user experiences, server based IF, as well as mobile device output.

The idea is obviously not well-formed, but bothered me enough that I needed to blog about it.

I have a great deal of sympathy for anyone that points out the flaws in using the current parsing technology within the available IF platforms. There’s a long history of parser inadequacies starting from two-word commands all the way to guess the verb problems. The most glaring problem is that if you place a person in front of a computer with a blinking cursor and tell them they can type anything, you’ve already failed. The parser is a very limited translation mechanism to a very limited world model.

The IF community has always sort of closed its eyes and waved away the problem by convincing itself that with thorough verb implementations and coded hints within the text that this resolves the problem. There was a belief that we were smart enough to hoodwink users into believing the parser could understand anything they type. We also believed we could create an imaginary world that seemed real enough to make the parser more meaningful than it truly is.

Emily has thoroughly disabused us of that notion. We have to face the fact that although our parser implementations are limited, the user experience is not conducive to new people catching on quickly.

However. I don’t believe our problem is the parser.

The parser does it’s job perfectly well. Once the user is familiar with how it works and determines what subset of english is available in a particular game, they tend to do just fine. So the problem isn’t the parser. That’s just a symptom.

The problem is the user interface.

Why do we do things the way we do them? Because we started out with tools that almost exactly mimicked systems that were designed in about 1975. These original systems were setup before we even had video. That’s right, the original Adventure and Dungeon (Zork Mainframe) games were only available in their original state on an ARPANET paper terminal.

When Infocom ported Dungeon to microcomputers, the only alteration they made was to add a status line at the top of the screen. Other than that, the user interface is exactly the same as using a paper terminal. Later on they added a few other graphical features, but the basic user experience remained.

When Mike Roberts created TADS and Graham Nelson created Inform, we were still using dumb terminals connected to mini and mainframe computers. Up until 1996, I was working almost exclusively on video terminals connected to a DEC VAX.

In the fourteen years since, no IF platform has embraced modern programming constructs. The Gang of Four design patterns book was published in 1994. Do we implement any of those patterns in our platforms? Not really, no. Have we embraced the concept of loosely coupled architectures? No. Have we embraced the concept of component based or layered architectures? No. Have we embraced web technology? No offense to Parchment and all the other Java or JavaScript interpreters, but no, we have not.

In order to truly explore alternate user experiences, IF programming needs to move into the twenty-first century. Our platforms need to provide loosely coupled architectures that leverage modern technologies like AJAX, Web Services, Flash, Silverlight, HTML5. Our platforms need to separate what the actual game engine does from what the user sees and how they interact with the story.

Once we get to that point, then we can start realizing user experiences that support and extend our existing parser technology. And then, through friendlier user interfaces, we can gradually immerse new users into the wonderful world of Interactive Fiction.