FyreVM Shared Source

One of the reasons I started Textfyre was that I had and have a firm belief that paid programming was a considerable missing component of the development and improvement of Interactive Fiction as an artform and medium. The “IF community”, depending on your definition of such a thing, generally focuses on the academic and hobbyist participatory aspects of the medium. We’ve had a few people sell games within the community and they’ve shared some of their processes and thoughts, but no one has recycled any profits into the community at large.

Although I don’t have any profits (let’s not talk about the increasing debt I’ve incurred) to speak of, I do have a sincere interest in sharing the fruits of our internal workings as much as possible without crossing swords with my attorney.

So with that in mind, we’ve put together a “shared source” version of our Glulx VM implementation named FyreVM which can be reviewed and downloaded from the FyreVM website. By shared source we mean that there is a non-commercial aspect to the source code and we also want to restrict branched versions of the VM itself. Any code you write that uses the FyreVM is of course all yours. We’re going to put up samples and those will all be public domain. We will entertain friendly requests for a limited (individual) royalty-free commercial license.

FyreVM is the culmination of a lot of thought on my part and a frustrated review of the Glk specification. I’m not saying Glk is bad or wrong. I just think its limited in its usability by the average developer. There has been a sizable effort by several people to make Glulx and Glk as friendly as possible and yet we still aren’t seeing any increase in games developed with higher quality user interfaces.

So I’m sharing FyreVM because of how we implemented I/O, which is differently from how Glk implements I/O. FyreVM uses channels to convey all information between the virtual machine (game engine) and the user interface. We’ve completely abstracted away any detailed knowledge of pointers and memory and low level programming hacks to access the I/O interface. The developer has to simply retrieve the text that comes out of each channel on each “turn” in a game and do with it as they may.

To aid in this process, we’ve also created a very friendly set of Inform 7 extensions to give developers the tools they need to create channel based games.

Of course we’re still working on sample games to show off the potential of FyreVM and Channel I/O and we will report updates on the website. We invite anyone and everyone to help create samples for the website.

Textfyre is dedicated to being involved in the interactive fiction community and will continue to share our tools and processes as time, money, and lawyers permit.