Archive for March, 2011

I’m still working on the web client for Zifmia and it’s going slow, mostly because I keep changing the AJAX interface to get everything so it’s compact and very simple. There’s a regression test working now at http://zifmia.textfyre.com/regressiontest.html. The tests include registering a user, logging in, listing games, starting a game session, sending a command to that session, getting a session, getting a previous turn in a session, and then listing all sessions for a logged-in user.

There’s a jquery-min.js file in there as well…I think I have 1.3, but should upgrade to 1.4.

* * * *

I took the plunge this past week and purchased an iPad 2 and a Mac-Mini. Paid extra for the iPad and got a deal on the mini, both off of craigslist, so it more or less evened out.

I installed xcode 4 and with a lot of help from the gang on ifMUD, started getting an iPad client for Zifmia going. I have a lot of hoops to jump through, not to mention learning Objective C, but it doesn’t seem that hard right now. Just different crazy syntax issues.

My idea for the iPad client is similar to the web client, but it won’t be called “Zifmia”, it will be the Textfyre app. I plan to make the client free, but zifmia will allow games to be installed as pay per use games. The nice thing is that this will allow games to be installed in Zifmia that require payment or be free. I haven not figured out how this will work and am aware of the more draconian principals around Apple’s pay for content model, but this seems like a reasonable direction.

Anyone that builds their own client is still free to do so. I may have to split the server into two installations, one for Zifmia and one for Textfyre, but for now I’ll leave it in a merged “beta” state.

As for the iPad client itself, I envision being able to type in commands as usual, but being able to swipe backwards for previous output (one turn per page), have expandable live mapping, note taking, comments at a given location for a given game-state (I’ll have to figure out how to manage this so we don’t show spoilers), common commands used by other users, and local play with a built-in FyreVM engine that resyncs to the server when it can.

I’m less interested in smartphones now. The tablet is the way to go and I’ll have to look at doing the same work on the Galaxy Tab or other Android tablets.

The IF crew has descended upon PAX East/Boston en masse. We had 25 people for dinner last night and it was a who’s who of Interactive Fiction including Andrew Plotkin, Emily Short, and more.

If you’ve been hiding in your grue-infested cellar and don’t know about it, the Boston IF group is hosting a suite at the Westin at PAX. Look for the flyers and stop by. We’re also having speed-if, panels, and an IF Demo Fair on Saturday in the Alcott room in the Westin. No PAX badge needed for either the suite or the Alcott room.

The big meet and greet IF people is tonight in the suite. Come on out!

As I work through the minor technical issues of Zifmia, both client and server, some questions have arisen that seem important to how one might develop new games….specifically for the web world.

First of all, we intend to remove scrolling output from the web client paradigm and replace it with paging. Every time you interact with the game engine, we’re going to store the response. Within the UI, you will then be allowed to “page” backwards (and then forwards) through the entire history of your play. Unlike a scrolling UI, the UI stays the same, only the content changes. One of the interesting changes this has on your perception is that the most important aspect of the screen is the current setting (or location). Well, that was important in scrolling too, but my experience is that the setting change and non-change turn over turn is much more impactful. If you’re interacting in the same setting for a number of turns, the static UI feels much more that you have not moved than in a scrolling UI.

I’ve also been toying with the idea of polling for responses of non-movement and non-setting changing commands. So for every in-scope object, we’ll do an examine and search, store those responses in a data structure, then pass them to the client every turn. This means that the user can interact with all of the scenery without using a single turn. This adds to the perception in the static UI that the world is stable, grounded, and more realistic.

If we continue down this path, I envision having background art for each region in a game, further solidifying the realistic look and feel of the setting.

I’m sure there are more interesting observations coming as we experiement with Zifmia and client/server IF, but these are some of my initial thoughts.