As mentioned in a previous post, I’ve been working on a unit testing program and in that process decided to tackle the coupling issues in the FyreVM engine. There were two, the channel order and layout as well as the output filtering (turning text into markup for HTML or XAML).

Both of these things are now removed from the open source version of FyreVM. The latest extension for FyreVM for Inform 7 6F95 is checked into the sourceforge.net site as well as FyreVMOS itself.

The channel layout is now dynamic. If you add a channel in your code, FyreVM will automatically allocate space for its output and return it to your calling program. In .NET this comes through as a Dictionary<channel, data> where channel is a 4 byte mnemonic and data is the text for that channel.

I’m aware that the required math in each constant definition may seem a little daunting to non-programmers, but if you follow the pattern, you should be able to easily add your own channel definitions.

The Inform 7 code to direct output to a channel is defined as such:

To Select the Main Channel:
(- if (is_fyrevm) FyreCall(FY_CHANNEL, FYC_MAIN); -).

Note the constant FYC_MAIN is used here to select the main channel. All of the channels above are defined and some have additional code for easy channel access, like the chapter channel’s phrase:

To Set the Chapter to (T - text):
Select the Chapter Channel;
say T;
Select the Main Channel.

One of the aspects of FyreVM that always frustrated me was the hard-coded nature of the channel layout. The engine, up until now, had a hard-coded enumeration of named channels. There wasn’t really any reason for this, other than it makes consuming FyreVM easier to understand. This was a feature that was nice to have, but now that I’m working on three different sets of source, it’s becoming a royal pain. I also have a better understanding of ways in which FyreVM will be used and ported and removing the tightly-coupled nature of the channel layout from the engine seems like a natural course to pursue.

The current engine also had an output filtering system for the different types of clients we were developing. I removed this from the engine as well. A separate project will be created to offer basic output filtering mechanisms for Silverlight, WinForms (RichTextEdit controls), and HTML. This is a simple layer that takes the contents of each specified channel and replaces standardized markup or characters with the specified output. For instance, if you were doing HTML, you’d replace double carriage returns with a wrapping <p> tag for paragraph. A single carriage return would get a </br> tag. Character styling, including bold, italics, underline, double-strike, subscript, superscript, and fonts, if supported by your output system, can also be implemented through the filtering layer. If a particular game had a very specialized output, the layout engine may be built into a special client that understands the layout markup. So if the game marked up all nouns, the client may know what to do with these words outside of just marking them up. It’s possible they’re links to other data or links to commands to be returned to the game engine. Maybe the UI shows a tooltip for such marked up nouns. This would be considered a non-standard layout engine.

There are a set of channels required for every game and they include Main, Prompt, Location, Score, Time, and Death. Main has to be the first channel.

The engine will now automatically allocate buckets for channel data. Since it uses a hashtable and text named channels, this leaves room for any number of channels a person might want. It also removes any need for ordering the channels. — updated 2:24pm

I plan to have a standard set of channels for public consumption, but the expectation is that the author or publisher can modify the channel list for their own purposes. My assumption going forward is that each game will have its own list of channels. The standard is really just a jumping off point.

The output filtering will also require a set of standard extensions, which will be titled something like FyreVM for HTML or FyreVM for Silverlight or FyreVM for WinForms RichText. This will offer the author easy ways to markup their output so that the client can filter it appropriately.

The client will require a second class library that takes the channel layout and the filtering rules and returns the channel data in the expected form.

The channel layout and filtering rules will probably be XML as the default standard, but I may decide plain text is easier to read and edit.

The output filtering requires character by character reading/writing because of begin and end tags in many cases.

I know this is meaningless to nearly everyone, but eventually the benefits will become obvious.

Nearly all startups go through a period of change. Many go through several periods of change. Most don’t survive these changes. The startups that do manage to stick around tend to adapt to everything thrown at them. They don’t always do it well or immediately, but the ones that survive find some knack for finding the solution to a thousand room maze that few others manage.

Textfyre is on the verge of exiting the startup maze and moving on to being a funded company with strong partnerships and amazing employees. Some of the details remain behind closed doors. Agreements need to be signed, product needs to be prepared, and people need to be notified of the coming changes.

But we’re finally approaching the real launch of Textfyre as a national brand in the Edutainment publishing industry.

These are very exciting and challenging times for me as the founder. I’d like to say that all of the ducks are lined up, but we still need to locate and place a few more of those proverbial ducks. I’m working on a number of fronts, bringing things together, and with a little more work, big announcements will be made in December and January.

One of the processes the IF community is learning about right now and one that Textfyre has been going through since Secret Letter’s game file was completed was the process of provisioning. Turning content into product. Infocom was brilliant at provisioning their content. They made some of the most beautiful packages and “feelies” even by today’s standards. Actually, few games are packaged these days. They have a pretty box, but inside it’s just some cardboard and a CD or DVD jewel case. Infocom included specially made items and paperwork that gave the customer the feeling that they were truly on their own adventure.

It’s occurred to me that Infocom was popular in part because of their brilliant packaging. I wonder how well their games would have sold had they come in a simpler, less enticing box. And if their games had no feelies at all, would they have garnered the same passionate following? It’s an interesting point to speculate on and one that I take seriously. I think anyone that wants to reach a wider audience for an IF game should also take it seriously.

This is not a trivial process. Some of the things involved in provisioning include:

Artwork. Every game should have at least one high end signature piece of artwork that represents the game. The community started doing this a few years ago with cover art. I think this was brilliant and the beginning of the community’s interest in provisioning their games.

Documentation. Each game should come with its own introduction, help, and any additional paperwork that helps the customer immerse themselves in the world within the game. I think this is key to booting the relationship between the customer and the game. It probably gives the customer a stronger attachment to the game, which will help them overcome any initial difficulties. Where IF is concerned, any way to reduce start-up confusion is highly desired.

Map. Each game should just give away the general setting secrets by presenting the entire game’s map in color, preferably drawn by a talented artist.

But these are things that go in a box or in a PDF. What about getting the game working?

Installation. The customer should be able to very easily install the game. The game should install exactly the same way that any other application installs on a given OS. The installation process should include details about the end user license agreement as well as any information about open source software being used. The user should be offered the opportunity to “run” the game immediately as well as display the introduction documentation immediately. There are free tools to create installations for Mac and Windows and Linux. I highly recommend looking for these tools and making your game a standard install for all platforms.

And there are things that should be within the application itself:

General help.

Full set of hints.

All of this is hard work. Just when you’ve finished updating your game with that last beta testing report, you feel this sense of accomplishment and you should. But you’re not done. You then need to determine how you want people to perceive your new work and go through the process of provisioning it accordingly.

If you’re not an artist, there are plenty of starving artists available through Craigslist.org. I paid $500 for the cover art for The Shadow in the Cathedral and I think it was well worth the money. You can also find great photos and artwork at istockphoto.com. I’ve used their site to grab various little pieces of spot art like gears and clocks for Shadow’s documentation. Again, it was well worth it. Of course in a perfect world I’d have an art director managing the graphical provisioning process, but if you have to be your own art director, you can still do an excellent job.

Provisioning is a critical aspect of making your game look exciting and giving the game player the feeling that they’re getting something really cool. Whether you’re giving your game away for free or selling it, provisioning should be on your to do list.

So I had set aside a lot of IF work in the past month for work and health reasons. I found myself with a very bad case of whiplash after several wild rollercoaster rides at Six Flags which uncovered high blood pressure, which led to me to get a stress test, a physical, and to see a foot doctor. The neck pain and dizziness are gone, the new orthopedic shoe inserts are wonderful, and the blood work all came back normal. I feel better. Relieved.

I had left Zifmia in a nearly working state, outside of details like security and the client aspects. The server was very close to being completed. So I’ve spent the last three days working through the issues and it’s now running perfectly. Here’s what I did.

I’ve developed FyreVM in a new WCF web service. For newcomers, WCF is a framework from Microsoft that allows you to easily build web services. The service has a single interface, GetResponse:

The main parts we’re interested in today are GameKey, UserKey, and Command. The GameKey is a reference to a server-side game file. The UserKey is a user’s identity. The Command is whatever the user has typed into the game window.

WCF has a built in test client that helps us test:

In the first frame, we’ve opened up our test client. We click on the GetResponse interface, which displays our available zCommand interface. Then we add in our start up arguments and invoke. You can see the results in the third image. Each channel has a value or is blank. Then we add a command and invoke a second time. This shows the channels again with different data. In the final image there is a couple of files that represent the state of the game. The main file is the save data and the numbered XML files are the channel data saved for each turn. We can re-use this data to display previous turns in the browser (or any application that consumes the Zifmia service).

It all works and is very fast.

Next up, the client with fancy jQuery controls to display our channel data.

The life of an entrepreneur is hard. Don’t let anyone tell you differently. For all of the Mark Zuckerberg’s in the world, there are thousands of guys like me. We have a vision, a passion, a singular belief that we can create something special. We will scrounge up dollars to keep our servers running, scramble to networking events that just might lead us to an important contact, and endure ridicule and debasement for our “fantasy”. Our families don’t get it at all. Our friends are supportive, to a point. Our advisors are helpful, but excruciatingly and irritatingly calm and collected. We ourselves either lose weight or gain weight, eat badly, sleep horribly (if at all), and do poorly at our regular jobs because we’re simply not inspired by the grey cube walls of doom.

And yet we persevere. We find inspiration in little things. We continue to poke and prod our network. To find new ways to develop our business plan. To bring new advisors into the mix. To improve our product plans. To find new customers. We think about our business and work on some aspect of it every single day. Some days for hours and hours. Some days for only a few minutes.

We believe with every fiber of our being that our plan is solid and it can succeed. We believe that we’re doing something worthwhile and good. Something that will create jobs that people will love. Something that will create products that people will love. Something that will make the world a better place.

I’ve been working on Textfyre for over four years. We have two published products. A third product incredibly close to being published. A new business plan. New markets (Kindle, iPad). New authors. New Advisors. We still have people investing their time in Textfyre and believing that it can succeed. We have great tools and great plans for new games.

We’re not Facebook and we’re not an overnight sensation. But we’re still working at making a great company, even if it takes years and not hours to get there. We’re still working.