Vorple and FyreVMWeb

So now that Vorple for Glulx is in beta and looking great, I asked Juhana whether it made sense for the two of us to work together to make Vorple work with fyreVMWeb. Iniatially we both thought this would be a great idea.

However it would seem that Vorple adheres to the existing glk-oriented display paradigms and that’s exactly what FyreVMWeb breaks (intentionally).

Most, if not all of the concepts in Vorple are transferable, but the implementation is likely to be wildly different underneath the covers. The one area that may have overlap is some of the I7 extenstions, but even then it would be file by file decision. More often than not, one platform would be hampered by the others requirements or capabilities.

Vorple extends to Glulx a real web development experience that is very exciting. It may make FyreVMWeb less of a target to many who just want an out of the box development experience. Even so, I still need to find a way to bring the same Vorple UI experiences to FyreVMWeb. I’m just not sure how that will happen.

For the most part, a rough beta of FyreVMWeb is functional. It is not ready for real use quite yet, but getting closer by the day. The sample is running showing the standard beta template..

FyreVM Status Line (I7 Extension)

This extension allows the author to decide which parts of the status line will be displayed. The extension doesn’t say anything about the design or location of the status line, but only which parts should be shown or hidden. The design will be handled by a component in the UI template.

This is going to be common pattern for components in fyrevm-web, as it clearly defines the content, but has no opinion about the design.

In this case, Story Addendum is a new feature of the status line and will require further definition. For now it’s just a placeholder, but my intention was to allow the author to control any parenthetical addendums, such as:

Kitchen (floating in mid-air)

The following is the current documentation from the extension, now on the fyrevm-web github repository:


FyreVM Status Line defines which parts of the standard status line are displayed.

These parts include:
- location name
- location addendum
- story time
- story score
- story turn

The author can show/hide any of these with the following statements:

show the location name.

hide the location name.

show the location addendum.

hide the location addendum.

show the story time.

hide the story time.

show the story score.

hide the story score.

show the story turn.

hide the story turn.

The statusline-channel will emit the details in JSON format to be handled by the UI template.

{ "showLocationName": true, "showLocationAddendum": false, "showStoryTime": true, "showStoryScore": false, "showStoryTurn": false }

This data will be contained in fyrevm.statusLineContent in the browser.

A fyrevm-web Standard Template Emerges



After a holiday hiatus, the standard template is coming along. It’s not pretty, but the basic functionality is getting closer to my vision.

One of the tasks we completed was reorganizing the github repo so it was strictly fyrevm-web, the I7 extensions, and the eventual I7 build templates. The eventual development of ifpress will be within its own repository.

In this iteration we’re storing arrays of the main content and the commands. In the next iteration we’ll have the full complement of content displayed in the template including hints, help, and multi-session (branching) capabilities.

Then we’ll introduce multi-story housing, external saves, and mobile templates.

And then finally we’ll add a paging template to show that the same data can be used in multiple contexts.

We could still use a professional web designer to help us make this look pretty. If anyone is interested, drop me a note.

FyreVM-Web Builds

As we progress on the development of a “standard template” for fyrevm-web, you can follow the results here.

This is a simple build and deploy process via a Jenkins server. Every time we check in code to the fyrevm-web GitHub repository, Jenkins will pull the latest code, build it, and deploy it.

It’s fairly new at this point (the code and some of the basic react + semantic-ui elements), but we’re about to make huge progress.

Stay tuned!

FyreVM Installed Stories

I just finished the first draft of code that will allow users to install a fyrevm story into their browser. One of the issues that comes up is that local storage has a hard limit of 5mb. I’m looking into using IndexedDB, another browser storage mechanism, but I’m not sure if it’s reliably standard.

I hacked a copy of the loaded story from the Chrome debugger below (in JSON format). The storyFile object is an ArrayBuffer containing the ulx file and the quetzal object is the save game state for turn ‘0’.

As the user continues to play, more turn objects would be appended to ‘turnData’.

The ‘key’ is the IFID from the story itself.

Content types are one of text, json, number, or css. More can be added, but the FyreVMWeb/FyreVMMem typescript files would need to be updated to handle that content…or you’d make any new content text/json and handle any further transformation in your own code.

More coming next week!

    key: "69DE4C7B-CF54-42E4-A6D1-0DEE7197DB6A",
    storyFile: { },
    storyInfo: {
        debugMode: "",
        inform6Library: "6.33",
        inform7Build: "6M62",
        inform7Library: "6/12N",
        releaseNumber: "1",
        serialNumber: "161130",
        storyAuthor: "The IF Community",
        storyCreationYear: "2016",
        storyHeadline: "A basic IF demonstration using FyreVM",
        storyTitle: "Cloak of Darkness",
        strictMode: ""
    turnData: [
        {    bannerContent: "Cloak of Darkness
A basic IF demonstration using FyreVM by The IF Community
Copyright © 2016
Release 1 / Serial number 161130 / Inform 7 Build 6M62 (I6 lib/v6.33 lib 6/12N )
             command: "",
             contentTypes: "1296124238,text,mainContent;
             dateTime: "",
             locationName: "Foyer of the Opera House",
             mainContent: "

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.

             prologueContent: "Hurrying through the rainswept November night,
you're glad to see the bright lights of the Opera House. It's surprising that
there aren't more people about but, hey, what do you expect in a cheap demo

             prompt: ">",
            quetzal: { },
            score: 0,
            time: "540",
            turn: 1

FyreVM-Web Templates

The work on a standard reusable template has begun with a target of mid-December for functional completion. Depending on how it looks, I may let a designer friend play with it before releasing, but extensions and documentation will all be published as soon as it’s feature complete.

The standard template will come with several options that are driven by I7 code. Some behavior will be different than most interpreters and this includes:

  • Every turn is saved, along with turn data. This allows the story to be reloaded with history/scrollback/pages and allows the reader to jump to any historical turn and “branch” their play. If a player does page back to a previous turn and enter a different command, the previous line of story is saved as “branch 1” and stored separately from the “running branch”. The player can create as many branches as they wish. The player will be able to add/edit a description to each branch.
  • We’re using ReactJS for the templating system and all of the front-end code will be simple with clear separation of concerns. Each portion of the template will be a self-contained component controlled by the larger template.

Some of the template feature choices include:

  • Story Title Header (optional)
  • Status Bar (optional)
    • Location Name (on/off)
    • Turn (on/off)
    • Time (on/off)
    • Score (on/off)
  • Main Content (required, select one)
    • Scrolling
    • Paging
  • Command Line (required, select one)
    • Embedded
    • Static Footer
  • Menu (required)
    • Install New Story (required)
    • Save Story To File (required)
    • Start Story (required, must have installed stories or will be disabled)
    • General Help (required, provided but modifiable by author)
    • Story Help (optional, generated by I7 extension “FyreVM Story Help”)
    • Story Hints (optional, generalted by I7 extension “FyreVM Story Hints”)
    • About (optional, generated by I7 extension “FyreVM Story About”)

There are many features and options to add, such as turning off the command bar and making a choice-based selection list of links, allowing embedded directional links, embedding magic word links, embedding images, and creating more complex templates. I plan to publish a story with an alternate template and release it next year at some point, possibly for the 2017 IF Comp. Requests for features will be welcome, but I’d also encourage others to try their hand at creating their own components and templates. For anyone with basic HTML, CSS, and JavaScript knowledge, this will not be too difficult.

Ruminations on a burst of Inform 6 coding in Inform 7 times…

You may have seen my post of a very small story on intfiction.org. I spent part of my labor day weekend appeasing a festering lack of creativity by “cleaning up” some old code in Inform 6. I had a zip file of all of the story and I6 library files, along with the 1999 version of infrmw32.

I haven’t been doing a ton of Inform 7 coding lately, but enough in the last year or so that I’m mostly comfortable with its syntax and usage scenarios. In my work life I write mostly C#, so jumping back into Inform 6 was interesting. Most of the basic syntax is easily remembered, but boy those I6 idiosyncrasies are a boat load of fun. Not having static analysis of your code is really frustrating when you find things like:

Object Foo with name 'foo', counter true, has scenery;

And try to check:


That little mishap, which will compile and execute, but give you the wrong value, is awesome.

But the most glaring difference is in usability. I eventually got my testing down to quick reruns of code in WinFrotz, but having to plan through all of that, needing to manage code, debugging with print statements, it all makes Inform 7 a huge blessing. One of the reasons I even tackled this was that I had written reasonably decent code, broken into include files, with base classes. Without that, I may have not bothered.

Even so, I can honestly say that for small stories, I might actually use Inform 6 instead of Inform 7. For a Speed-IF type endeavors, it might just be (for me) more efficient use of my time.

Of course for any WIPS I have, it’s Inform 7 all the way. At least now I’ve been given a reminder of some of the benefits.

FyreVM Text Styles

My initial thoughts on this extension were to offer font control. Then I used it and realized this completely breaks my SoC intent. Text styling should be left to using em, b, i, and strong tags, along with link commands (hyperlinks that send commands to the VM).

So I removed the font and color constructs.

Then when testing link commands, I realized everyone would use them for compass directions and such, so I added the following:

go-north is a link-command with command "north".
go-northeast is a link-command with command "northeast".
go-east is a link-command with command "east".
go-southeast is a link-command with command "southeast".
go-south is a link-command with command "south".
go-southwest is a link-command with command "southwest".
go-west is a link-command with command "west".
go-northwest is a link-command with command "northwest".
go-up is a link-command with command "up".
go-down is a link-command with command "down".
go-in is a link-command with command "in".
go-out is a link-command with command "out".

do-inventory is a link-command with command "inventory".

Now that I have this wrapped up and have a “feel” for where development should go, I’m going to move back over to my ReactJS application development and a real-world example. This will include a responsive design, reusable components, save/restore, paging or scrolling options, images and videos, sounds, modal popups, menus, and more.

But I have to set this aside and work on other things for a bit. fyrevm-web work will probably be silent for a few months.

FyreVM-Web Extensions Update

FyreVM-Web requires at least one Inform 7 extension to host your story in a browser using glulx-typescript. There are several others and the list is growing, so I’m going to report progress on occasion. This is the list and their current state of development.

FyreVM Core
This is the foundational extension that allows a Glulx game to use FyreVM output constructs (channels) instead of the traditional glk mechanisms.

FyreVM Banner
This is a simple extension that prints the banner text in a banner channel.

FyreVM Prologue
This is a simple extension that provides a prologue channel for text to appear before anything else.

FyreVM Text Styles
This is a new extension that somewhat mimics and extends the built-in Glulx Text Effects extension. It adds styling, font, color, and command link capabilities, including built-in usage of Google, Adobe-Edge, Adobe-TypeKit ($$), Fonts.Com, and browser (built-in) font sources. The command link allows you to say “[link go-north]north[/link]” and this would translate to a hyperlink that calls a sendCommand(command) function in the browser. The rest is standard styling using span tags and generated classes. The author doesn’t see anything except the I7 constructs. I’m in the process of updating Cloak of Darkness to use this extension. To use a Google Font, you’d simply make your own style with google as its source. The communication to the browser will inject the link to that font and create a CSS class. The author usage is shown below:

my-style is a ui-style with color Black and font-family "Poirot+One" and font-source google and weight normal.

say "[ui my-style]This text will show up as black text, normal weight using the Poirot One font from Google Fonts.[/ui]";

FyreVM Embedded
This is a conceptual extension to support the author embedding images and video within text.

FyreVM Sound
This is a conceptual extension to support sounds.

FyreVM Menus
This is a conceptual extension to support web based menus.

FyreVM Modal Dialogues
This is a conceptual extension to support modal popups and dialogues.

IF Interpreters and Separation of Concerns

As a software architect in the business world, one of the prerequisites to any system is to adhere to certain rules. One of these rules is “separation of concerns” and it’s meant to ensure that different types of logic remain separate from each other.

One of the common implementations of this rule is the separation of user interface and data. In the Interactive Fiction world, this would mean breaking apart the standard interpreter into two things. One to handle the story execution and one to handle the user interface. Luckily we have the ability to adhere to this rule with browser technology.

One of my primary reasons for building FyreVM, even in its original C# implementation, was to support the implementation of SoC. This is just good system design from my perspective.

I was able to achieve this on the Windows side of things and even to some degree in a browser using Silverlight, but that was never going to be something to which the average author would gravitate.

So that’s when (and why) I procured glulx-typescript through a Elance/Upwork project.

And as mentioned, having just the VM wasn’t enough. It had to have a full implementation to show how SoC works with Interactive Fiction. The Cloak of Darkness story in my fyrevm-web GitHub repository does just that.

But it really only shows the very basic requirements of SoC. There are elements of the IF interpreter that are tightly bound to the platform we use to develop stories. These include:

  • text styling
  • window or panel creation and management
  • images/video
  • sound
  • menus
  • modal popups
  • text location
  • link creation and intent

In developing fyrevm-web further, it’s my plan to make extensions for all of these types of UI communication. So the author won’t manage windows, but she might target a component with a particular set of text or she might say a panel should open or close based on story progression. But the actual window management would be entirely in the browser. The same would hold true for these other aspects of an IF interpreter. The HTML/browser would care and feed UI elements and the story file would just manage story, thus we reach separation of concerns in IF.