It's a couple of days late, but I finished my warmup entry for the theme "E = MC^2".

It took around 3 days to write and draw, and another half-day (today) to make the sound effects. It uses the experimental pyglet 1.0alpha2, just released yesterday (there are very few API changes since the previous release).

So, if you're feeling twitchy, grab pyglet from the link above and then download conserve-1.zip. Requires a reasonable graphics card and OpenAL.

System capabilities poll is closed, here's what I can see since this time last year:

• 20% more Intel dual-core CPUs. Multithread away!
• 9% more Linux, which is now the majority primary platform (55%). Watch the case in the filenames, people.
• 9% increase on 2+GHz CPUs and 6% increase on 1+ GB RAM, so don't be afraid of those brute-force algorithms. Though there is a 5% drop in 3+ GHz CPUs (possibly due to the increase in multi-cores).
• 12% drop in Windows and DirectX users, suggesting that we're seeing a conversion of Windows users, not necessarily attracting more hippie Linux users.
• 5% drop in PowerPC and Mac OS X usage. Have these people moved to Linux? Given up on gaming? Why didn't they just buy an Intel mac?

To reach the biggest target, you should write for OpenGL (89% supported; I'm guessing most of the other 11% have it but don't realise it) and Linux (85% primary and "also-haves" combined). However, write for the lowest common denominator: only 52% of respondants claim to have any hardware shader support.

Ok, it's going to be a board game. Here's a sketched mockup of the game:

This will be a good challenge for me, because I can do some new stuff like AI and possibly networked gameplay, and spend less time on graphics.

Ok, it's still clearly a board game :-)

Some things I've done:

• Implement side-effect-free game state -- needed for AI to be added later. The code is quite unreadable. Anyone have any experience with lisp or haskell bindings for Python?
• Draw the board (procedurally) and pieces in wireframe. This obviously won't be the final look, but you gotta love the moire-woodgrain effect :-)
• Drag/drop the board pieces and twist the rings around, which updates the game state. Yay!

Committing myself to a set of rules is the next step, and writing the minimax.

Worked on the game all day today (eek! don't tell my supervisor!) and got heaps done.

Spent quite a while toying with different rules, including some lengthy debates with random people in the computer lab, and a bunch of first year game design students (whose helpful comments ranged from "It should have bunnies!" to "Make it pink!").

I've settled on a very simple blocking-style game. The "twist" factor makes it hard to plan a strategy, but after a few plays through it becomes more obvious. It's not the most original or challenging game in the world, but I'll stick with it modulo minor variations because it's working.

The minimax was a nightmare to write -- sure, it's a simple algorithm to understand, and it's only 10 or so lines of code -- but it's nigh impossible to debug. There's all kinds of tricksy corner cases they don't tell you about in AI class :-)

The evaluation function is still simplistic (it only looks at the winning condition, so it sucks at the beginning/middle of the game). I'll tackle this later.

The moves, both by player and AI are all animated now so it's clearer what's going on. You can set up the game to play with any combination of humans and AI bots.

I found two more subtle bugs in the alpha-beta pruning. This is a function that is seriously less than 10 lines of code, and was more or less translated from pseudocode in wikipedia. The bugs caused it to improperly prune search paths early, so rather than crashing or showing a blank screen or any of the usual things you get when you make a mistake, it just played a little stupider. I only found the bugs by inspection while optimising the code -- I couldn't tell just from playtesting.

Before finding these bugs I was able to play a close match, but usually win, against the computer with a depth search of 5. Unfortunately the computer took over a minute for each move on my fastest desktop (hence the optimising).

I implemented two standard chess optimisations: iterative-deepening depth first search, and a transposition table. The ID-DFS improves alpha-beta performance (despite appearing on the surface to do more work), and also means I can set a time limit on the search and have it return the best result found so far. The transposition table is a cache, with some tricky code to get it to behave well with the alpha-beta pruning (again, several subtle bugs resulting in less-than-perfect play -- luckily by now I could spot when the computer made a bad move it should have known about).

With both optimisations implemented the depth=5 search takes a maximum of 14 seconds, and typically much faster later on in the game (as the winning path becomes more obvious and the translation table fills up). Because of the bug fixes that came with optimising, the computer beats me consistently even at depth=3 (which is searched in under a second).

I've run a couple of computer vs computer games at various different depths. One apparent design flaw in the game is that the inital player gets a large winning advantage -- a depth=3 player can beat a depth=4 player easily if they move first, and only narrowly loses against depth=5. I might try some slight juggling of the initial position to remedy this; otherwise I could make games happen in two rounds, at either side of the court.

Next stop: pretty graphics.

Erm, now there are lollies on a playing board.

That's a day or so of polishing and optimising, and making it work on mac. A few more animations and textures to do, then sound. Don't think there's time for network play.

Hey all, thanks for the great comments. I really liked a lot of the games, and was happy to see the ones at the top at the top :-)

As you're probably aware, my entry Lazy Susan is more or less a test program for pyglet, which is currently in Alpha. There were only a couple of comments indicating there was trouble running pyglet, which is encouraging as I can start moving closer to a Beta release.

If you were one of the few who had an issue, could you please send me an email at Alex.Holkner@gmail.com with a complete traceback and your OS version (this should be less time-consuming that submitting a complete bug report to the tracker).

In response to some of the comments complaining about a lack of sound in Lazy Susan: let me clarify that this is just because I ran out of time and didn't consider it a priority for a board game. :-). pyglet itself has support for WAV, MP3, WMA, OGG/Vorbis, etc. on all platforms, and can mix to surround sound. I'll make sure my entry in next year's PyWeek is a noisy one ;-)