I’ve had a list of “tasks” since the beginning of this endeavor. Some of these tasks are simple, like “Incorporate” or “Get a Logo”. Others are more complicated, like “Business Plan” and “Hire People to Make Games”. And then there are a small number of issues that seem almost impossible. One in particular….
You see, I have a very clear vision of what I want Textfyre games to look like to the public. I want them to take on a near Myst-like quality. That’s probably unattainable, but it’s something to strive for. So in striving for that level of quality I decided to implement the first round of games using the latest Microsoft development technologies; Windows Presentation Foundation and XAML. These tools don’t really do anything that couldn’t be done before; they just allow it to be done far more quickly and efficiently. Instead of requiring deep knowledge of arcane graphics API’s, WPF allows the developer to implement glossy applications in declarative form. If you want a quick look at one application that spurred my interest in WPF, take a look at the New York Times Reader. It comes with a 30-day free trial and it’s simply phenomenal.
So with that in mind I decided to bypass (for now) a cross-platform delivery mechanism and focus on Windows as a platform. I’m not turning a blind eye to Apple or Linux users. We will absolutely address the needs of those users. But our first delivery solution will be Windows oriented and based on the .NET Framework 3.5, which is the latest version available. It’s bleeding edge to some, but having been tested publicly for a year now, seems pretty stable.
One of the big complex tasks was to develop the virtual machine for our games. Since we’re currently standardized on Inform 7 as a development platform, it was either Z-Code or Glulx and since Glulx was a bit more mature, I decided to push forward with Glulx. I also liked that Andrew Plotkin, the creator of the Glulx specification, made it so that the I/O layer was abstracted and he also made it so that the VM was extensible by adding extra “op codes” or internal operations. This means that Textfyre could develop its own I/O layer and do things that have really never been done before, which is to handle all of the output in the user interface. The Textfyre output channels are simply handing off the text to the user interface and we code the user interface to do the “right thing” with that output.
So the challenge was to find someone to do this work. I tried to tackle the problem, but it would take me years to understand all of the aspects of VM’s, memory management, and many other non-trivial tasks to make this possible. I started with Jesse McGrew and then got blind-sided by a fast-talking developer who said he’d do it on a promisary note. That didn’t work out so I eventually went crawling back to Jesse and after some begging and pleading, he agreed to extremely favorable terms for Textfyre. This was only a few weeks ago.
Jesse more or less finished the VM in less than two weeks (with a few more hours of finishing touches to add). I can’t possibly explain to the uninitiated how incredibly unlikely this is. As Jesse put it, he was “in the perfect storm for this thing”. He knew C# and .NET, Inform 6, Inform 7, Glulx, Glk, and he understood virtual machines.
So starting tomorrow I am going to marry our game in beta (Secret Letter) to the user interface I’ve been working on in WPF and to the Textfyre VM, and have a very real beta version ready within a few days.
This is something to be truly truly thankful for. It is now almost assured that our first game will be published in Q108 and it may be as early as January. We still have a lot of “finishing” to do, but the end of the tunnel is very much in sight.
Hats off to Jesse McGrew!