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!

newStory
{
    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;
                                           1347571796,text,prompt;
                                           1280262990,text,locationName;
                                           1396920146,number,score;
                                           1414090053,text,time;
                                           1145389380,text,deathContent;
                                           1162757191,text,endGameContent;
                                           1414877774,number,turn;
                                           1229866575,json,storyInfo;
                                           1397641044,text,scoreNotify;
                                           1129138004,text,contentTypes;
                                           1229343044,text,ifid;
                                           1515864385,text,bannerContent;
                                           1515864386,text,prologueContent;",
             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
game...?

",
             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:

Foo.counter();

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.

FyreVM-Web Cloak of Darkness with JavaScript UI

This culminates over a year of work, transitioning FyreVM to a web format using TypeScript (glulx-typescript), creating the EngineWrapper state machine, creating the page manager FyreVMWeb, the content transformation system, and then updating the I7 extensions to use formal objects for channel definitions.

You can see the live result at Cloak of Darkness.

Channels can now be added very easily:

my-channel is a channel with content name "myChannelContent" and content type "text".

You write to that channel using say:

say "[on my-channel]This text will show up in my new channel.[end]";

This text will show up in fyrevm.myChannelContent in the script of the web page.

The title is misleading since the the VM and the page manager are written in TypeScript, but the html page itself is scripted in simple JavaScript.

The example implementation uses Cloak of Darkness, which only seems appropriate.

Everything you need is included in my fyrevm-web repository, although the projects\Cloak of Darkness folder is entirely self-contained. That’s all you need to run the example.

To do so you’ll need to install TypeScript.

Once you have those installed, open a command line prompt at:

(your local file system)\fyrevm-web\projects\Cloak of Darkness\javascript

run:

> TSC

You’ll also need to run the app from a server. This is easy enough if you have Node/NPM installed, otherwise you can use Apache or IIS or ???:

> npm install -g local-web-server
> ws

Then open a browser and use the url: http://localhost:8000.

This will display the story. Note that everything in this web page is directly placed in HTML. This is the template:

The Story!

 

To make this “ready for prime time”, there’s still a lot of work. Most authors would want more pre-built components and a more fully developed standard template. I have a list. Feel free to send me suggestions.

On Second Thought – React

As a consultant, I learn a lot about bleeding-edge technology, including the latest web frameworks like Angular 1/2React, and others. My original thought was to use Angular 2/TypeScript for the basis for FyreVM-Web, but I’ve changed my mind.

Angular 2 is great, but it really is meant for “enterprise” development, not one-page story games. On the other hand, React is perfect for one-page story games. It’s just a layout engine without all the controller, service, and dependency injection technology that would be overkill for most IF authors.

React is still a level-up from plain HTML development, but most templates would probably be implemented by someone that knows HTML/CSS anyway. I think this is a reasonable compromise. The one feature I absolutely want, that Angular 1/2 and React offer, is data-bound templates. This just allows FyreVM-Web to set data to a JavaScript object that’s connected to the HTML template. React is perfect for that type of work.

FyreVM-Web App Dev Begins

It’s been a little over a year since I commissioned a Typescript version of FyreVM. The plan was to develop an app development model for IF stories that’s more “web” and less “IF”. Progress has been made and I’m going to talk about that here…

There are several moving parts to the technology under fyrevm-web. First there’s glulx-typescript, which is the basic Glulx virtual machine, coded in Typescript. Then there’s a layer on top of that called EngineWrapper, also written in Typescript. This first layer puts a sort of controller/state-machine on top of the interactions of glulx-typescript. It allows you to just load a story, send commands, and receive data. There’s now a third piece (second layer) on top of that called FyreVM.Manager, also written in Typescript. This second layer is what is implemented in an HTML page and handles the integration between HTML and data coming from FyreVM.

One of my visions was to simplify the data side of FyreVM, to make the story bits more accessible to web developers. FyreVM.Manager does this with a combination of a new I7 extension for FyreVM called FyreVM Content Management. It’s a simple idea. There’s a channel CMGT that is reported when play begins. It contains a semi-colon delimited list of descriptions of all of the data. So the main data, MAIN in FyreVM, is defined as “MAIN,text,mainContent;” The Manager will note that, take the data coming out keyed to MAIN and add it to the DOM as document.fyrevm.mainContent. The extension has all of the FyreVM required data defined and any extensions adding new data should add the bits to append their descriptors to CMGT.

In the WebStorm debugger, you can see how this comes through below. Note document = #document and then fyrevm and then all of the properties of fyrevm. This is all of the data for the sample story I’m executing. It even has the story information broken out into a sub-object.

fyrevm-web-content

The inline JavaScript code in the HTML page is fairly simple for a standard template. The template has to identify where the user is typing in commands and implement the line or key input switch (if the engine requests a key, then the template should send the key to the VM immediately, otherwise we wait for an Enter or whatever the UI requires for “execute command”. The template will have DIV tags for all of the content types it wants to display. The page will directly bind fyrevm values to the template or set the element directly.

There will be special cases where content is in JSON form and requires “logic”. I’m working on a sound extension that would qualify. The page has to take the sound “logic” from the story and implement that in the browser. It’s a marriage, similar to transposing the channel data into usable content types. But the story controls the sound, which is what we want.

Next steps are to implement Cloak of Darkness using plain JavaScript, Angular2, and React. The Angular2 implementation will come first and along with it the ability to auto-release as you edit in I7, push this to the app folder, and restart the story to see how it looks. It’s kind of cool to implement a new channel and see it just “appear” in document.fyrevm.