So Thatcher, Charles, and Ryan are back from the Indie Game Jam. Check out the results, the games are reasonable counterexamples to the idea that totally physics-based gameplay is always boring. (As of this writing the games have yet to be posted, but they'll be up soon.)

I love the idea of the Jam; I wonder if you couldn't take the idea a bit further. For instance, the average game takes, let's estimate, 10 people about 1.5 years to develop. Call it 30,000 hours of effort, just to toss a number at it. The jam winds up generating games in about 50-60 hours of work, which gives us a speed up factor of about 500; call it two orders of magnitude. (I'm ignoring the fact that the jams always start out with a technology base, but I'm guessing that the estimate is still pretty close.) What if you could knock off another two orders? At that point, you'd be sketching a game in about 30-60 minutes, which might move it into the realm of performance art. Lord knows people have done more boring things on stage in that genre.

Probably to get the time requirements down, it would have to be almost all level design for an already complete game. So invert it: have the audience design the level, and the programmer/artist/m.c. is there just to mediate the experience. Buy a bunch of digitizing whiteboards (or conversion kits), and cover the walls of a small room. Put some wine and food in the middle, give the audience the pens, and let them design a 2d platformer level. Have a couple of PCs or consoles in the room to test the level out, and email everyone a copy of their work at the end of the night.

Or, if you wanted to follow the theme of this year's Jam, just take two whiteboards, split the room into teams, and have them draw rigid body machines to "attack" the other side. The team that manages to fling, slide, or drop the most mass into the other teams region wins. You'd have to run this one as an iterative session so the teams could develop defenses against the other team's onslaught. The mediator's job would then be to enforce some rules to ensure a fair competition. Ideally the final level would resemble a sort of emergent Rube Goldberg kinetic sculpture.

It'll never happen, but it's a fun party to imagine...

/games | permalink (2004/03/24 12:50)

Might as well put all of this stuff up. Surely my hosting provider's backup procedure is better than mine...

While I was in Portland a few months ago, I picked up a copy of Graham Stephen's String Searching Algorithms at Powell's. Fun little book, although given its size and scope, somewhat overpriced. Out of that: C# project number two. Eventually, this might wind up as part of a diff tool I've been thinking about for a while, but for now, it just does generalized string distance computation using Ukkonen's algorithm, and Boyer-Moore-Horspool searching. It's extremely general and inefficient, since the idea was that the symbols that would be compared would be entire lines rather than entire characters.

The next project I put up should be a little more substantial.

/projects | permalink (2004/03/09 23:08)

So I've been playing around with C# lately; this was the first project I did a few months ago. Now I've started paying attention to onepartcode again, I'm going to throw it up, since it's mildly amusing. Tabview is a little utility written by Casey Muratori that we use at work for viewing memory debug dumps. The idea is that leading tabs are interpreted as tree depth, so you can collapse large sections of your text file for ease of interpretation.

No program description is complete without a screenshot, so here are some highly fictitious memory stats displayed in TVEx. Note that we've included 200% more interface than Tabview, and our .NET technology guarantees that you'll receive more value for the dollar than you can get from Tabview. Download Tabview Extreme 1.0 now!

/projects | permalink (2004/03/08 15:18)

Under the heading of "stuff that didn't work", I'm stuffing my attempt at spline-based audio compression. The thought was to take advantage of large scale structure in audio data to losslessly compress it by fitting a spline to the data, and encoding the residual signal using standard techniques found in codecs like FLAC. Initial results were well short of encouraging, so onto the junk heap it goes. On the bright side, I did get some halfway decent spline fitting code out of it.

Here's what I completed before setting it aside. The code's a bit of a mess, since it was stopped mid-stream, but the spline code should be separable with a bit of effort. I was testing out a way of enabling/disabling exception handling in the library using #defines, but this turned out to be more trouble than it was worth. If I come back to it, that's definitely coming out, maintaining two error pathways is just a pain in the ass, with no real benefit.

/projects | permalink (2004/03/08 15:14)