Interactive Fiction and Graph Databases

I’ve been puttering on my own .NET-based IF platform for years. I rarely talk about it because it’s never gotten past the idea-stage. I originally started experimenting with Visual Basic .NET because I thought the verbosity was a good thing for IF authors. I recently switched everything over to C# with the idea of building a fluent interface to all of the internal structures.

One of the many challenges of any IF platform is how data structures are implemented so that querying the “world model” is simple and fast. Graham gives some examples of the complexity of parser-based interactive fiction in his recent London IF Meetup presentation, specifically around assumed relationships between objects. (There’s no easy way to embed an exact reference, so you’ll just have to read through the part about natural language in IF).

Another thing I’ve been doing for about ten years is entrepreneurship. Most of you know I attempted to create a commercial/educational IF publishing firm, Textfyre. In recent years I was working on a contextual social network  (Wizely) premised on offering globally shared wisdom. I have recently abandoned this startup because machine learning + Search has come close enough to contextual to make my ideas quaint and likely to fail.

However, one of the aspects of trying to build a real business is that you force yourself to learn a lot of new things. One of the things I picked up building Wizely was graph databases. I had been using Neo4j as my tool of choice, but the graph database world has matured and there are several prominent players and interfaces. I still think Neo4j’s Cypher language is the most readable and accessible, but fluent interfaces seem to becoming the standard.

Anyway, graph databases are really interesting when solving relational data problems, especially natural language problems. When you’re building a story in Inform 7, you may find yourself “selecting” things that relate based on “criteria”. One of the core features of Inform 7 is the ability to define very complex relationships and build rules from their current and future state.

A graph database (or data store) would help do the same thing. A graph is made up of vertices and edges, but also known as nodes and relationships.

Player -> IS IN -> Kitchen
Player -> IS CARRYING -> Elvish Sword
Elvish Sword -> IS CARRIED BY -> Player

As you can see, the elements of a graph align directly with how we perceive the world model of a parser-based interactive fictions story.

So extrapolate this to pushing all of the data (or beginning state) of a story into a graph data store, then add the standard graph querying capabilities of either Gremlin or Cypher, you could build an IF platform that focused on the state of a graph.

Cypher example relating to IF:

MATCH (person:Person {"name": "George"})-[:IS IN]-(location:Location)->[:CONTAINS]<-(object:Object) RETURN object;

Which would return all of the objects in the location of the PC/NPC named George.

Cypher, Gremlin, and other graph query interfaces are very sophisticated and allow a great deal of querying power and I think this is a very interesting foundation for an IF platform.

In my current efforts, currently named “refly”, I’m building a serializable in-memory graph data store in C# and plan to implement a gremlin and/or Cypher interface. Once that’s complete, I’m going to build a working implementation of a story built in C# fluent interfaces to this in-memory data store. Then I plan to use Blazor to have it run completely in a standard browser that supports Web Assembly.



A good friend of mine, Jeff Panici, is going to post videos for a year, detailing how to build an old MS-DOS based video game in assembly language.

Check it out!

Mikayla’s Phone

So this “work” was conceived, written, and designed by my sixteen year old daughter Angeline. I implemented the user interface.

Angie had a ton of poetry and notes from middle school, a lot of which is pretty typical teenage angst. Some of it is more than that. A little over a year ago, I recognized that the anxiety was more than the usual teenage stuff and offered to introduce her to a therapist. She agreed and has been going regularly since. She’ll tell you it has immensely improved her life and as her father I can say it has immensely improved her disposition. She will always have anxiety (and depression) issues, but she’s building coping mechanisms, understanding triggers, and learning that she’s a pretty amazing person regardless.

She came to me in spring and said she wanted to learn how to make a video game. I asked what kind and she told me about her writing and the basic idea of a lost phone of a seemingly dead teenage girl. I told her she needed to outline everything first. She did that. I showed her Twine and explained how to put everything into a tree of choices. She did that. I did try to adapt Twine to a mobile phone look and feel, but I felt I’d need to learn way too much about Twine. So I just used basic html and jquery.

As we were putting this together, we looked at ways to put it in front of people. We thought about submitting it to SubQ, but I suggested the IFComp and after thinking about it, she agreed it was the best way to go.

We completed the game (it has quite a few rough edges) with 6 minutes to spare.

When I hit the Upload button, you could see the relief in her eyes, almost as if a weight of the past had been lifted. She really had a bad time in middle school. She could finally (mostly) let it go.

We were not expecting anything from the voters, but the reviews we’ve read are accurate and appreciated. We both laughed out loud at “wads of morose poetry” in one review. She read it and said, “He’s not wrong.”

There’s no doubt we could have cleaned up the interactivity quite a bit, possibly added some humor, and made it more of a game. But that was not the goal. It was meant to relay what it’s like, from a real person’s perspective, to be in middle school, to be a young girl, and suffer from anxiety and probably have some spectrum social issues.

Maybe someone will “play” it and realize they’re not alone and that seeking and investing in therapy is a real solution with tangible benefits.

FyreVM and IFPress Status

It’s been about six months since I’ve worked on FyreVM-Web and the infrastructure for After the most recent developments with Vorple and the clear interest from the community for its progress, I paused to re-evaluate where I spend my time. I think at this point I plan to spend more time on writing than on tool development. This means the status of my tools is going to remain dormant until some nebulous future date.

As everyone knows, platform development is hard and the IF community is somewhat mercurial about shared interests. I tried to enlist a couple of people in helping on the UI side of things where FyreVM is concerned and they flatly replied (paraphrased), “Why should I spend time on this when Vorple is more mature.” OR “I don’t have any extra time for this.”

So at the moment, FyreVM-Web is going to the dust-bin…until I find some future fuel for it or if it gains interest from other capable front-end developers and designers.

On to writing, IF and other things. Cheers.

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