what the kiwi game does

Just a quick note on the comments. We don't have much of a game here. We basically aimed really high on this project, and just ran out of time. We didn't manage to check in much of a game, so of course we're not going to win this contest. However, I think we do have some interesting technology here.

Here's what's going on:

• 2d physics engine: pyODE is a 3d physics engine, so we had to trick it into handling our 2d room. We ended up building something like an ant farm: everything is happening inside a 640x480x32 unit space, with walls all around holding everything in place. When you press left or right, you're actually applying a force to the kiwi, and he stops because the atmosphere applies resistance. At one point he was able to kick around a soccer ball and it would bounce around realistically, but that didn't quite get integrated with the level editor.
• angled platforms: the world consists of arbitrary rectangles loaded from an SVG file. We hit a big snag here dealing with svg's transformation matrices. I was up a whole night reading about linear algebra trying to get it working, but never quite nailed it, so we had to fall back to non-rotated platforms. Unfortunately, even these disappeared from the room in the release version.
• metabolism: kiwi's can't fly. Since this kiwi can, thanks to his hyped up metabolism. The price is that he has to eat a tremendous amount of food for this power. Fat stores and glucose actually behave sensibly, and he can even eat food. We just didn't have time to get the speed right, or to get food into the level. I added a quick hack to force-feed him invisible food just to keep him from starving in the release version, which is why the glucose meter goes up on it's own. He still still starves if you fly too fast though. The original idea was to make him change shape as he got fatter and slimmer, and to incorporate weight changes into the gameplay, but we didn't get that far.
• console state machine: the menus, dialogs, high score system, and the game it self are all modelled using the State design pattern, with separate objects for each. So one console is always running, and it just swaps out these state objects as things happen. This turned out to be a really clean way to model a game.
• model-view-controller architecture: the model consists of geometry and bodies in the physics engine, whereas the view tracks these objects and moves the sprites around on screen accordingly. Eventnet and the event handlers in the individual state objects act as the controller.
• nice sound/music system: illium did all this single handedly so I'm not 100% sure how it all works, but using it was very easy, and the code is worth investigating
• inkscape scripting: inkscape is an open source svg drawing tool and part of our project was getting inkscape to break the levels down into foreground and background PNG fies, and extracting the geometry/object layer as a simplified svg. It looks like inkscape could be a great level editor once we get this working.

Much of the system is also written in a semi-literate style, with test cases and documentation interspersed throughout the code. That's part of what the trailblazer concept was about, though that part didn't quite go off the way I'd expected.

So anyway, we didn't finish and what we have doesn't look like much, but check under the hood and you might find that there's some interesting stuff going on. We're planning another week long sprint to happen in a few weeks. Meanwhile, I'm hoping to have time this week to at least get the levels loading so we can actually play!