Posts Tagged ‘html5’

After moving the two 2009 published stories (Jack Toresal and The Secret Letter, The Shadow in the Cathedral) to, there have been 200+ views, many press downloads, and a handful of sales. Sales are really not the point of course. I’m just trying to see if Textfyre can re-establish itself as an IF publisher, even a modest one. I’ve been working on updates to those two stories and to the existing tooling.

Empath’s Gift is in early beta-testing now is well on its way to being published this year, possibly even as early as spring.

A colleague has forked Quixe, Andrew Plotkin’s Glulx in JavaScript interpreter, and is nearing completion. This will allow FyreVM games to run in a browser and provide interesting tooling capabilities. I’ve talked about this a lot over the years and it’s been my belief that glk (even the proposed glk 2.0 for web) approach is at-best a stop gap measure.

Real web capabilities should allow an author to rely on the entire web programming paradigm and not just a subset of those capabilities. FyreVM allows for this (but doesn’t provide it) since authoring a game would only requires you to define context, not the look and feel. The look and feel, or user experience, is something that can be done by non-authors who are experts with HTML5. Tools can be developed (like Vorple) to give authors highly flexible control over the look and feel of their published stories.

My goal is take the resulting FyreVM compatible Quixe implementation and create a widget-based web interpreter. The author would load their game file and the system would automatically determine what widgets were required. The author would then drag-drop these widgets on a blank slate and save the results. Players would see the resulting “interpreter” as a custom user experience. The author could allow the player to move the widgets around for their own purposes or they could “lock” the widgets to maintain a distinct experience.

The plan is to have the first implementation of this vision by summer.

I’m personally working on a new story called Reflections, which will either be released sometime summer/fall and possibly in the 2015 IF Competition.

I’ve also discussed the Shadow sequel with Jon and Ian. Sadly, they are far too busy to work on it and so I had planned to open it up to someone else. I can’t offer the highly speculative contract that I once offered early Textfyre authors, so it would be a project of passion for the most part. I would pay a nominal (up front) fee to an experienced Inform 7 author for the work.

I have tried to contact Mike Gentry, but he seems to have left the IF world completely and does not respond to inquiries. This makes me very sad since Mike is still one of the best writers the IF world has ever known. It still irks me that Secret Letter has almost no reviews from prominent IF writers and players. I think it really bothered Mike too. I think the consensus was that it was cliche’d fantasy and this prompted many people to disregard it. Even so, probably the most disappointing aspect of having started and tried to make Textfyre work.

That’s my update. Stay tuned.

I’ve been winding down some things relating to Textfyre and have talked with a few people about when exactly I should officially close it. There are some legal and accounting hurdles to overcome and those will take time. I separated my consulting practice from it so that’s no longer a concern.

So it looks like Textfyre will “survive” for another year. I’m not exactly sure what it will do, if anything, but I’m working on IF projects that may or may not fall under the Textfyre banner at some point. But most of my IF endeavors are open source and freely available.

These include:

  • Completing the game Reflections. This is not going to be open source, but it will be free. It’s likely going to be a non-competition release in a non-standard web-based user interface.
  • A friend of mine is adapting Quixe so that it can run FyreVM games. Once this is completed, I’m going to finish up a toolkit for building custom web applications for parser based IF. This is similar to Vorple by Juhana Leinonen, but because the IO model is significantly different, the tooling will be different.
  • These new tools will be similar to Ionic/Angular in that you can use a command line to quickly create an IF app from a template. I plan to have several templates ready on first release and these templates should be relatively easy to modify if you know HTML and possibly a little JavaScript.
  • A web application version of the Inform 7 IDE. I’ve only mucked around with this so far, but it’s something I want to spend time on in the next year or two.
  • A web-based IF hub for educational content. I’ve actually already built several versions of this for Textfyre, but will build a new one in the next couple of years and release it for public sharing of educational content. I think this is a really important platform to build and share.

Textfyre plans:

  • I’m still trying to figure out how to get Empath’s Gift completed. I need an I7 programmer to own it. Paul and Chris are happy to help with additional writing and testing. I’m willing to pay a reasonable fee to see this happen.
  • I have a unique touch-based UI for Shadow about 70% completed testing. This is on me to finish and release, whether it’s a success or not. At this point, I’ll probably release it for free just to get feedback on the UI concepts and share ideas with the community.

Feel free to share your thoughts about Textfyre’s future.

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.

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).

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.

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.

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.

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:


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 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 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.

Feel free to test it out and leave comments.