One of the projects I’m working on this year is an interactive fiction engine built in a wiki interface. The game engine uses a markup similar to wikitext, with a helpful UI to simplify building world elements. The player interface is a webified version of a z code type of game, supporting MUD features for authors who want it.

The game editor

A SVG mock-up for “thwarter”

1. The main location editor. A location is a wiki page with a bunch of state attached to it. In the mockup example, you’re looking at “The Meadow,” in its “Chapter 1″ state. The text is like wikitext, allowing you to tag other areas, objects, and so on as you write. The approach differs from zcode, allowing you to write the story parts first (and worry about connecting the programming parts later).
2. The object editor pulls meta data from the wiki page (and things you add directly), allowing you to edit their properties. All concepts in the games are objects like this, including NPCs, things, paths, and game event triggers.
3. The object editor tabs show each kind of world element.
4. The location timeline for each location shows the story states. State can be used for description of an area over time or other story variants like branches, portals, and so on. Each area can have an unlimited number of these states, allowing the author to write all of the story for one area in a single interface. World objects can have a timeline too (not shown here).

The art of prototype

I use Inkscape to mock-up user interfaces. It’s a good starting place as it’s quick, vector-based, and it uses text (SVG plays nice with Subversion). I sketch the interfaces directly in Inkscape now, skipping paper prototypes for everything but the earliest concept sketches. I sometimes take the vector drawings to completion too, polishing them, and dissecting them later with the Gimp for HTML templates.

Notice that the editor mockup has no icons or colours. It’s a habit I’ve developed over the years, limiting my thinking in terms of highlights instead of worrying about the details. I get bogged down with details early on, so I have to force myself to sideline the distractions until later. I limit mock-ups to 10-20 minutes too, to avoid getting sucked in to trying to perfect ideas early. The time for polish comes later, after I can prove the utility in the approach.

Prototyping

I am also careful while building the prototype not to get too lost in the details. The purpose is to test the viability of the interface and the initial approach. So far, I’ve discovered that I need to be able to parse the wikitext in both client and server, as well as parsing the NL text from the game interface on the server. I’m considering externalizing the parsing rules (via regex or similar) so it can be shared between Javascript and PHP, so I can provide a rich UI and storage. This complexity is a good discovery to make in the prototyping stage, as it gives me lots of time to consider alternative–and hopefully simpler–approaches.

Another test of the prototype is to see if CodeIgniter is a good fit. I’ve been pleasantly surprised so far, and have found it an extremely comfortable framework. I’m also looking at hosting needs (AWS, Slicehost, Dreamhost), considering how DNS and DB partitioning will work, and what sorts of load might be put on the system. Some of this thinking is early, so I have to try not to get stuck in it.

Level up

Next up, I’m going to start to prototype the game play interface and expand the schema. The game implies a great deal of state, something that I want to be careful to contain simply. I’m siding on partitioning the games in their own databases (or tables), especially for the live game states. A live game will have large multipliers of the number of locations, their states, by the number players and their time in the game so far. At a small scale it won’t matter, but thousands of players multiplied by hundreds of locations (and dozens of states each, dozens of variables per state) becomes a large persistent data problem.¹

1. And there I am again shearing the Yak ↩

An interview with Richard Hipp (author of the SQLite library) at The Guardian. I’ve used SQLite for several projects now, and am very impressed.

A sliding tab view script (uses Prototype), a speedy web based (js) drawing tool, and a nice striped table script.

A Ruby on Rails diagram generator. Now you can see your ROR projects in full unidirected beauty. Graphs are produced in SVG and PNG using Graphviz.

[stars: 5] Getting Real, the dead-tree version. A damned inspiring read, well worth the price of admission. The book is targeted to web development projects, but makes sense for many types of businesses. The mantra cuts to the core of the hacker/maker ethic: Enjoy what you do, do it simply, and do it fucking well.

An interesting Google talk on How Open Source Projects Survive Poisonous People.

Modalbox is a Javascript library for doing wizards and similar dialogs in a browser.

How do I manage several different projects under Subversion?. This confused me at first as cvs doesn’t allow checkouts from the repository root. Also check out the answer to How can I do an in-place ‘import’?

I’m not the only one who has asked, “is there a Windows terminal emulator that doesn’t suck?“. I’ll try a few of these recommendations. If anything works for me, I’ll write about it. So far, poderosa seems perfectly reasonable (and console looks good too).

A rant about the newest version of Adobe Acrobat, including hundreds of comments from angry Acrobat users. Acrobat 7 weighs in at 20.3Mb for Windows (43Mb for Linux), just to read PDFs. To contrast, one of the leading Linux PDF readers, Evince, is more than 100 times smaller at 190K for the entire package. Similar, leaner Windows readers are available too: the Foxit Reader, the Brava reader, and Ghostscript for Win32.