Archive for June, 2010

So I’m looking at being a part of the launch of the new Windows Phone 7 and have a dilemma. Andrew is nearing completion of the iPhone/iPad/iPod, and Mac OSX framework for FyreVM games. I’m working on the Silverlight code for Windows Phone 7 games. I think it’s going to be a tie as to when we get the code done.

So then I have to decide how I want to market the new platforms and whether I simply fire off versions for every platform. Do I market just the mobile apps? Do I do just iPad? Do I do just Microsoft or just Apple?

These are the questions I’m pondering every day now.


So while I’m porting Shadow to Windows Phone 7, I started realizing where Microsoft is going with all of their platforms. They want to make it so that if you play a game, you can stop and restart on another device.

So the scenario is…start a game on your new Windows Phone 7 device on the train. At some point you decide to save and quit. When you get home, you fire up the Xbox and load up the same game and continue playing. But wait, your friend Joe calls and wants you to come over. So you head over to Joe’s and pull up the same game on his PC, right where you left off.

Since we’ve been talking about user interfaces lately, this brings up a completely different problem. What will the three different devices/platforms looks like and how will they work? It’s obvious that the WP7 device will have a minimalistic user interface and touch controls. The Xbox might have a keyboard, but it would also have to support users without one and just the standard controllers. The PC user would be running something closer to what we would consider a traditional user interface.

All of this can be done in Silverlight using the various SDK’s and common data file formats, which we already have with FyreVM and Quetzal save files.

I’ve always thought one of the flaws of the iPhone (and now iPad) model was that you couldn’t buy an app and play it on your computer. Why not? What’s preventing Apple from creating an SDK that shares the same code base, but allows the developer to choose different devices to target? Seems like a no-brainer to me. Unless you don’t care about your desktop business anymore and you’re solely focused on mobile devices. That would seem to be the direction Apple is headed.

It will be interesting to see how this dynamic impacts the market when WP7 is launched and the marketing of Microsoft platform neutral gaming comes into play.

In any case, Textfyre is likely to pursue this model. I think telling people they can play our games on their new Windows Phone 7 device, a PC, or an Xbox, is going to be a nice draw.

Emily Short started an interesting conversation about the parser and offered an interesting alternative. Nick Montfort commented about the subject and Emily’s blog post has a sizable number of responses. I highly recommend reading through everything.

I have a great deal of sympathy for anyone that points out the flaws in using the current parsing technology within the available IF platforms. There’s a long history of parser inadequacies starting from two-word commands all the way to guess the verb problems. The most glaring problem is that if you place a person in front of a computer with a blinking cursor and tell them they can type anything, you’ve already failed. The parser is a very limited translation mechanism to a very limited world model.

The IF community has always sort of closed its eyes and waved away the problem by convincing itself that with thorough verb implementations and coded hints within the text that this resolves the problem. There was a belief that we were smart enough to hoodwink users into believing the parser could understand anything they type. We also believed we could create an imaginary world that seemed real enough to make the parser more meaningful than it truly is.

Emily has thoroughly disabused us of that notion. We have to face the fact that although our parser implementations are limited, the user experience is not conducive to new people catching on quickly.

However. I don’t believe our problem is the parser.

The parser does it’s job perfectly well. Once the user is familiar with how it works and determines what subset of english is available in a particular game, they tend to do just fine. So the problem isn’t the parser. That’s just a symptom.

The problem is the user interface.

Why do we do things the way we do them? Because we started out with tools that almost exactly mimicked systems that were designed in about 1975. These original systems were setup before we even had video. That’s right, the original Adventure and Dungeon (Zork Mainframe) games were only available in their original state on an ARPANET paper terminal.

When Infocom ported Dungeon to microcomputers, the only alteration they made was to add a status line at the top of the screen. Other than that, the user interface is exactly the same as using a paper terminal. Later on they added a few other graphical features, but the basic user experience remained.

When Mike Roberts created TADS and Graham Nelson created Inform, we were still using dumb terminals connected to mini and mainframe computers. Up until 1996, I was working almost exclusively on video terminals connected to a DEC VAX.

In the fourteen years since, no IF platform has embraced modern programming constructs. The Gang of Four design patterns book was published in 1994. Do we implement any of those patterns in our platforms? Not really, no. Have we embraced the concept of loosely coupled architectures? No. Have we embraced the concept of component based or layered architectures? No. Have we embraced web technology? No offense to Parchment and all the other Java or JavaScript interpreters, but no, we have not.

In order to truly explore alternate user experiences, IF programming needs to move into the twenty-first century. Our platforms need to provide loosely coupled architectures that leverage modern technologies like AJAX, Web Services, Flash, Silverlight, HTML5. Our platforms need to separate what the actual game engine does from what the user sees and how they interact with the story.

Once we get to that point, then we can start realizing user experiences that support and extend our existing parser technology. And then, through friendlier user interfaces, we can gradually immerse new users into the wonderful world of Interactive Fiction.

Microsoft announced their new mobile platform in February and I’ve been actively working on prototypes using the new development tools, Expression Blend 4, Visual Studio 2010, and the Silverlight Windows Phone 7 SDK.

One of the great things about targeting Windows Phone 7 is that all of our existing code base compiles without change. The FyreVM class library ported without easily and now it’s just a matter of working through the new WP7 API’s to make it work seamlessly.

Of course the real work will be coming up with a user experience that works well. It may be that our work with the book “paging” model used in Jack Toresal and The Secret Letter Deluxe Edition will help us with something similar on WP7.

The way that paging works on WP7, by flicking the screen right or left or up or down is a key to making something interesting and intuitive. The user should be able to play our games with just a thumb.

The other aspect of targeting this platform is that we can also implement them using XNA for the XBox 360 platform and players could go back and forth between them playing the same game. It will be interesting to see this in action.

We’re already registered as an official developer and targeting to be one of the first products available at the launch later this year.

Stay tuned!

This is community focused blog entry and not generally related to Textfyre.

Since the community has begun to look at ways to broaden the reach of IF, much of the focus has been on web-based interpreters like Parchment and Quixe as well as in-game modifications to enable easier play for people new to IF. In the past there have been efforts to develop feelies to go along with games. These are important steps, but I believe there is a lot more that could be done to widen the potential audience of game players.

With that in mind, I believe we have an iceberg problem.

Below the surface there are a number of things that are named post-production, finishing, and packaging. These are fairly huge tasks and without them, a particular game is unlikely to reach more than the normal people in the IF community.

Once you’ve completed your game, tested it thoroughly, possibly even added some nice in-game hints and help, there is still more work to be done. Some of these things might or should include:

It’s my belief that hints need to be embedded in the game, but also available in the user interface in a seamlessly user-friendly fashion. They also need to be context sensitive which means going through your game thoroughly and writing down as many questions as possible. In order to test to see if your hints are working properly, you probably need to sit a novice IF player in front of your game and see how they do. Getting feedback is very important, so this is a step with several iterations.

Every game should implement several different kinds of help either as an add-on document or embedded in the game or user interface. There should be a general introduction to IF, to the particular game and its idiosyncracies. There should be help for the user interface and there should be context sensitive parser help. If people are typing wildly inappropriate commands, the user interface should step in and help out. There should probably also be context or status help, where at various points in the game, a note is displayed summarizing what the player has accomplished, where in the game they’ve traveled, and a map showing such travel.

Cataloguing Information
Every game should have an IFID number, a title, list of author(s), a list of non-authorial credits, a short game summary, a long game summary, a marketing tag line, cover art, a standard set of icons, list of search keywords, genre(s), and probably a list of other games that are similar.

Every game should come with an in-game or add-on document map that shows either the detailed room layout or a more artistic rendering of the game setting.

Every game should offer an online place for a user to turn for questions that are not answered within the game or the user interface. The forums should probably be moderated to keep it clean.

Every game should be packaged so that it can be installed on a Mac, PC, or Linux box with a single step process that places the game in a known location. Most computer users understand where their programs are supposed to go, which is on the Start menu or in an Applications folder and/or menu bar. There should be no mention of interpreter or game file or anything about where things are located or installed and how things work. Most users don’t care and aren’t interested. For mobile devices, each game should be packaged individually. The hobbyist community will always feel comfortable with something like Zoom or iFrotz, but I don’t believe a wider audience will until, well, there is a wider audience. Each game should come with a transcript for each possible ending (unless if there are infinite endings of course). If possible, there should be an e-mail address the user can use to report bugs or to contact the author(s).

Loading Times
Obviously with larger games there is an issue with loading times, especially using Parchment or Quixe. I don’t think there’s any problem with the loading time specifically, but something should be presented to the user besides a count of bytes being loaded. There should be a cartoon or progress bar and this is probably a good place to offer some introductory text to distract the user while the game is being loaded. Watching a byte count is likely to be a death sentence with a lot of users.

Each game should be announced on, registered as a game at IFDB, and reported to Baf’s Guide. We should probably come up with a system to report new games to various blogs, ezines, and other appropriate channels.

I’m not sure if this is required or an optional task, but I think a specific website/web page for each game might be a good idea. IFDB offers this on some level. possibly a bit too libraryish. I think something more game focused and author designed would be nice. The way Adam Cadre and Emily Short have presented their games is very nice.

Emily Short just wrote a nice summary of some of the issues surrounding IF user experience, although she missed mentioning Zifmia.

Zifmia is a plan to implement IF games in a web client/server architecture, leaving the UI of the game entirely in CSS/HTML/JavaScript. The game file, the save files, and the virtual machine would all reside on the host side of the equation.

Anyway, I see the accessibility from a different angle, having looked at this for a long time and in the last three plus years from a commercial perspective.

First of all, I’m really excited that everyone is taking this seriously. I remember not many years ago when I would bring up the interpreter/game-file issue and people would simply shut the conversation down. They would say, “This is the way we do it because we want to be cross-platform. This is the best model.” and I would end up on a channel on ifMUD arguing with myself. I think the casual gaming implementations have shown that any installation complexity is a barrier few are interested in crossing. We still have that barrier and need to knock it down.

The parser and interface aspect has also been something I’ve discussed, but only through Textfyre have I really tried to push the envelope. Even I’ll admit that before Textfyre, I was mostly a traditionalist, favoring a white fixed font on a blue screen. That quickly changed when I started thinking about how I was going to present IF to new players.

My initial thoughts were to implement a book interface. I developed the concept with an art director and Thomas Lynge implemented the complex code to allow for paging. This can be seen in the deluxe version of Secret Letter.

This looks great, but most people thought it was “over done” and possibly detracts from game play. With a mixed response, this implementation is likely to be abandoned until further testing is done.

I’ve since started focusing less on the look and more on the functional side of the user experience. This is why I started talking about simple buttons for common UI actions as well as implementing a “Try” button that might list commands that would work at the current moment in the game. iFrotz has also come up with a few neat tricks that I think are great. You can tap words and watch them slide down to the command prompt. I think more touchscreen and multi-gesture input concepts could be introduced into the user experience increasing usability and accessibility.

But I believe there is a flaw in Emily’s article as well as in my own implementations and ideas. In order to determine what works and what doesn’t work, I believe we need lab rats, guinea pigs, and hyperactive mice to try out our ideas on a relatively large scale, get feedback, improve our ideas, get more feedback, and at some point make a cut that we think can reach as many people as possible. In talking to partners via Textfyre, we probably need several hundred people of varying ages, experiences, genders, and backgrounds to truly determine what works and what doesn’t. And then you have to decide what subset you want to target. Where do we get hundreds of people to use as guinea pigs? When we find them, how do we track their usage? Who will organize/facilitate sessions? How do we implement the results? Who implements the results? Which platform do we choose first? Z-Code? Glulx? TADS 3? (Knowing that the results will be portable to other platforms).

Do you want anyone from 8 to 80 playing your game?

Do you want non-computer users playing your game?

Will your game be on a PC/Mac?
Mobile device?
Does it have a full keyboard?
iPad or multi-touch tablet?

Are you willing to develop content for a deep help/hint system in conjunction with the lab-rat determined user experience?

Are your users avid readers?

Have your users played video games?

These questions are just as important as where to put buttons, what font to use, and how you make games accessible.

* * * *

As much as I struggle with this problem, it’s my number one priority both for Textfyre and for the community at large.

I’ve been avoiding talking about the behind the scenes aspects of developing Textfyre because it hasn’t gone all that smoothly. It’s been a struggle almost from the beginning and I’m now going to share some of the things that have held us back.

I’ve been married for a little over 12 years now. My wife and I have five awesome kids. One of the things that developed over time in my relationship with Irene was that she decided she didn’t like the ups and downs of consulting. I’ve been independent on and off and also worked at several consulting firms during our marriage and either the hours or the stress of finding “the next client” always caused her enormous anxiety. I admit, the lifestyle is not for everyone.

Some people argue that when you have kids, you shouldn’t take any risks. Some people think that you live your life and your kids learn from that. These aren’t necessarily competing priorities if both parents share the same philosophy, but when you don’t, success is very difficult. Something has to give.

There are other, personal aspects to my marital difficulties, but the fundamental difference is choice in lifestyle. After twelve years of never really figuring out how to accommodate each other, my wife and I are divorcing. The discussion started well before Textfyre was created. Then the legal divorce process started in July of 2008. It’s mostly amicable and we’re sharing the kids jointly and will live close to each other.

In working through the divorce, the economy tanked. Up until March of last year, I was making a considerable amount of consulting income. Enough to take care of personal finances and significantly fund Textfyre and incur no debt outside of a mortgage and a couple of car payments. The economic downturn strangled the investor pool that drove my client, OneDegree.Com, out of business. After that, I couldn’t find work from April through mid-December. It was financially devastating to say the least. There were some very close calls keeping the servers up at times.

Through all of this turmoil, I have managed to keep Textfyre afloat, although certainly not at any pace or direction that I originally planned. A few people have switched gears to leave the work as a lower priority, which is understandable. Some people understand that in any start-up there are “hard times” and are willing to push through. Some people just have to get paid every week or every invoice to keep working. I can’t fault anyone for doing what’s in their own best interests. I very much appreciate everyone that has worked on Textfyre’s development whether they continue to do so or not.

Now the good news. We’re not going anywhere. We’ve struggled to make it this far and we’re very close to doing some amazing things. The iPhone, iPod, and native OS X versions of games are around the corner. The third game is nearing beta and a fourth series is now in the design phase.

I’ve made a personal commitment to help do outreach for the larger hobbyist community because through that process I actually learn how to do my job as owner of Textfyre better. I still learn new things about IF all the time, about how its perceived, about how to develop it, what works and what doesn’t. This is really a never-ending learning process.

As of June 15th I will be divorced and my personal financial situation will both improve and degrade at the same time. I won’t be able to take some of the risks I’ve taken in the past, but I will be able to support and direct Textfyre better than I have in the last two years.

By the way, If anyone’s thinking that Textfyre caused my divorce, that’s silly. Textfyre was a result of knowing that I was going to be divorced.

I don’t plan to share personal information often, if ever again. I just thought that those reading this blog should understand how divorce and the economy can impact a start-up business.