FyreVM

FyreVM Shared Source

Last Updated: May 25th, 2008.

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?

You may not sell your programs or the FyreVM without permission from Textfyre. If you make a game that uses FyreVM, we may issue a free, but limited license to sell your game.

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 this Channel I/O layer thing?

I had always been a little frustrated with the Glk specification. It's a good generalist I/O layer, but because it offers direct control over the implementation of the output, it creates the problem that the presentation of your game is limited by the implementation of the Glk specification. So if someone spent thousands of hours developing a fancy DirectX version of Glk, you could then use all those fancy capabilities. If someone created a really basic implementation of Glk, then you're stuck with those features (or lack thereof). Whatever is there is all you are able to use.

So then I thought, what if we abstracted the actual presentation (text, images, buttons, sound) away from the I/O layer and simply communicated text and meta-data between the Glulx Virtual Machine and the interpreter or user interface. What would that look like? Then I came up with the idea of having different kinds of text and different kinds of meta-data. These eventually became thought of as "channels", and thus Channel I/O was born. At least that was the conceptual birth.

It took another six months before Jesse McGrew signed on as a programmer for Textfyre and took the concept and made it a reality.

How does Channel I/O work?

It's pretty simple actually. Think of any text that is output for 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.

But this just scratches the surface because if you can think of any logical interaction between the game state and the user interface, you can create a channel to help manage it. We came up with a few for our games, but there's nothing that says you can't create more or use ours differently.

Textfyre Channels Inform 7 Usage
Main The main channel is meant to handle the regular text window output. By default, all standard output is sent to the main channel. If you switch channels "manually", all 'say' statements will write to the newly selected channel. Make sure you switch back to the main channel when you've completed your other channel output.

To manually change the channel:

select the main channel.
Location The location channel contains the current location name. By default, the name of the current location is output to the location channel.

To manually change the channel:

select the location channel.
Score The score channel contains, if any is provided, the current score of the game. By default, the score value in the game will be output to the score channel.

To manually change the channel:

select the score channel.
Time The time channel contains the current number of turns or the current time. By default, the number of turns or the current time will be output to the time channel.

To manually change the channel:

select the time channel.
Map The map channel sends information in structured form (possibly XML) to the user interface that can then be used to either dynamically display a map or map information or manage a user interface driven map. The map channel is used to pass mapping data to the user interface. There is no 'default' implementation, but there is a sample implementation included in the source code.

To manually change the channel:

select the map channel.

You can turn the channel's output on and off with:

turn on map output.
turn off map output.
Hint The hint channel sends information, also in structured form, to the user interface that can be displayed as menus, as a control, or however you wish. The hint channel is used to pass hint data to the user interface. There is a sample implementation included in the source code.

To manually change the channel:

select the hint channel.

You can turn the channel's output on and off with:

turn on hint output.
turn off hint output.
Help The help channel sends information to the user interface to be used whenever the user needs general assistance. This may end up being deprecated for doing general help within the user interface, but it's possible one could implement context sensitive help that is not actual hint information. The help channel is used to pass help topics to the user interface.

To manually change the channel.

select the help channel.

You can turn the channel's output on and off with:

turn on help output.
turn off help output.
Progress The progress channel, something used for Textfyre games, is meant to send milestone data to the user interface. So if the user has accomplished something important, we could send information to the user interface that is displayed in a window or flashed in a popup or something similar. The progress channel is used to send progress information to the user interface.

To manually change the channel:

select the progress channel.

You can turn the channel's output on and off with:

turn on progress output.
turn off progress output.

Standard implementation example:

mark the player's progress as "Completed Maze";
Theme The theme channel, again a Textfyre thing, is for telling the user interface what state it should be in. If there are any colors, graphics, or controls that change based on a state-change in the game, we can signify this with the theme channel. The theme channel is used to send theme information to the user interface.

To manually change the channel:

select the theme channel.

You can turn the channel's output on and off with:

turn on theme channel.
turn off theme channel.

Standard implementation example:

change the theme to "psychedelic";
Prompt The prompt channel defaults to the common ">" caret, but can be altered to be anything. The prompt channel is used to set or change the prompt text in the user interface.

To manually change the channel:

select the prompt channel.

Standard implementation example:

change the prompt to "[time] >";
Conversation The conversation channel is used to send structured data regarding conversations with non playing characters. This can be implemented in a menu or a control or again, however you see fit. The conversation channel is used to pass NPC conversation information to the user interface. There is a sample implementation included in the source code.

To manually change the channel:

select the conversation channel.

You can turn the channel's output on and off with:

turn on conversation output.
turn off conversation output.
Sound The sound channel allows you to tell the user interface to change the musical score. The sound channel is used to send sound or music information to the user interface.

To manually change the channel:

select the sound channel.

You can turn the channel's output on and off with:

turn on sound channel.
turn off sound channel.

Standard implementation example:

change the sound to "psychedelic";

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).

How do I get the code?

There are two ways. You can use a Subversion client like TortoiseSVN on Windows to export or checkout (it's read-only though) the source code from svn://textfyre.com:8989/FyreSharedSource. The login is public and the password is guest. The second way is to download the latest code from the two links below:

What's in the code?

Can I use FyreVM on OS X?

By using the Mono framework you are able to compile the VM and SimpleFyre application, but they don't work very well. The OS X implementation of Mono uses a newer GUI library called CocoaSharp. My understanding is that this is incomplete, but being actively worked on. There is a mailing list for uses of Mono on OS X and specifically CocoaSharp. A volunteer has played around with this and I have screenshots, but I'd like to hold off until there's a reasonably stable Mono environment before we claim success.

Can I use FyreVM on Linux?

Yes. Using the Mono framework you can compile everything. A sample program and screenshots are below.

What's missing?

We still have to supply an example implementation of the conversation channel and we have yet to develop the SimpleFyre user interface to use all of the channels and show how this is done. We also need to document all of this stuff so it's easy to use.

How about some screenshots?

SimpleFyreGtk
Screenshot #1 - SimpleFyre on Linux using Gtk

SimpleFyre
Screenshot #2 - SimpleFyre on Windows