Why programmers should play Go. A good argument for stretching your thinker in weird and wonderful ways. I’ve played my share of Go over the years, and while I can’t claim to be good at it, I can say that it has changed how I think. The important thing to remember, though, is that the stretching isn’t just a result of learning the game, it’s also the result of thinking about the game, and reflecting on the patterns of play and tactics.

Some random Sunday fun: a live Pong game where you can enable/disable the lines of code driving it. Fun for at least a few minutes.

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 ↩

A simple logic implemented entirely in HTML … no Javascript, no Flash, etc. It’s a a good example of FSM,¹ and a great tangent hack.

1. Not to be confused with the Flying Spaghetti Monster, also a product of HTML and poorly contrived state machines ↩

Gamasutra demystifies Mario Galaxy’s physics model. A link to working source code is included, for those interested in one approach to implementing it.

Launchpad is a fun machine-building science Flash game, sponsored by the UK Science Museum. It has a clever UI, and includes a level editor.

Also see my flash games for kids page.

Ben Fry has a beautiful set of images and prints of Atari 2600 game code and data segments. The images show the code, the jump maps, and data blobs used by the games. The prints are based on his dismap project.

HOWTO write a great adventure game, in case you were wondering.

A few good reasons why every developer should play nethack. I’d like to add that every developer should take a look at the code, as it’s a great example of some of the cooler unixisms.

Here’s a short article about a machine learning project written in pygame. It’s an interesting approach with some intriguing possibilities (yes, I’m tempted).