FyreVM Shared Source
Last Updated: August 31, 2010.
What is it?
FyreVM is Textfyre's implementation of a Glulx Virtual Machine written in C# 2.0.
What can I do with it?
You can create your own game user interface (what the IF community calls an interpreter) without the need to understand or build a Glulx Virtual Machine. Your interpreter does not have to adhere to any standard and can either be a general implementation that plays many games or a specific interpreter for a game you've authored. Your interpreter doesn't even have to play games. It can be used to evaluate a game's contents, to test a game via scripts, or anything else you can dream up.
What can't I do with it?
Nothing, although if you use the source code, it has an MIT License. This just means you have to keep the license with the source and there is no warranty.
What about Glk?
FyreVM does not use Glk as its primary I/O layer. This is by design and not a specific limitation. You could alter the Shared Source FyreVM source code to accommodate a Glk I/O layer. Our implementation uses a Channel I/O layer.
Why did you implement Channel I/O?
The Glk specification is tightly coupled to the creation of the game. Any windowing or sound or graphical control has to be done through the Glk API. The Glk API isn't all that fun to work with and it's limited by its own specification.
In the business application development world, it's very common to separate the usage and storage of data from its display and reporting. Interactive Fiction could also benefit from this pattern. We decided that the content and context were all that we needed. What happens to the data and metadata once it reaches the user interface is meaningless to the game itself. Once we determined that, we created Channel I/O, which is just a fancy name for a bunch of name/value pairs being passed to the UI.
The content data is either written directly to text controls or transformed and written depending on the control. (FyreVM can translate tags embedded in text if setup to do so).
The metadata in channels can be used to alter the user interface. So you may have a map channel that contains the name of an image "front of house" which your program will use to display the file frontofhouse.jpg. The translation and handling of metadata channels is entirely up to the developer (you). You could have a sound channel that tells the UI what sound file to play and for how long.
You're not limited to the channels we've setup either. You can add more channels that do things specific to your game
How does Channel I/O work?
It's pretty simple. Think of any standard text that is output from a game as the "main" channel. Now think of the status line information as the "location" channel, the "score" channel, and the "time" channel. Those are all channels made up of already common information within any given interactive fiction game. Then think of any other text in your game that you could identify as something specific, like the game title, the credits, or the prologue.
We've implemented all of those plus a few more channels. You can use whichever ones you want as well as add your own.
All of this text is then used by the interpreter or user interface. Since we've developed this in .NET, you can use Visual Studio .NET Express or Mono to create your own interpreter. Your interpreter can be created to play one game or you can develop it to be a general interpreter and play many games. That's entirely up to you.
Why C# and Microsoft's .NET Framework?
Because it's easy. You can download the free Express version of Visual Studio .NET 2008 to work with FyreVM. You can also use Mono and SharpDevelop on Linux and potentially on OS X (although the OS X implementation lags behind the Linux one).