We started early this year, with a warm up game to try out Pyglet under Python 3 and to introduce my teammate Arnav, who I work with, to games programming.

This is a clone of an Android game called Archipelago in which islands exchange squadrons of aircraft to take over their neighbours. Our version looks like this:



Clone it from the Bitbucket repo if you'd like to play (requires Pyglet 1.2a and Python 3). Player is blue, AI is red. To play: click on one of your islands to select an origin island. Then click to select a destination to send a plane to - this costs half of the island's resources. Ctrl-Click selects multiple origin islands. You win if you eliminate the red team.

Day 1 kicked off with a brief brainstorming, as we hadn't come to any fixed conclusions about what game to make.

We've decided on a straightforward platformer set on a train:



Arnav has worked on physics (from retrogamelib) while I got stuck into the artwork. I have 29 frames of character animation, three train cars and the start of a steam locomotive.

I've also put together some OpenGL code to handle perspective on the tracks:



The sleepers look a bit flat, but it's harder to see that when they are whizzing past at speed.

The main thrust of my effort today was in adding more detailed objects to the scenegraph. The scenegraph mainly allows me to group sprites and animations together as compound objects, but I have scenegraph nodes to do depth effects and some that implement animation though custom draw() methods. So the scenegraph consists of animated 2.5D objects, like this locomotive with animated piston linkage:



I'm also going to write the character animation system as a scenegraph node, so I can keep logic and presentation separate. This has been a problem in some of my previous projects - classes that represent, say, a player character, and deal both with its control and presentation, are quick to get up and running, but soon become very complicated. Having a clear interface for the logic to control the presentation should help manage that complexity.

Two features dropped today.

The first and greater is a pure-python physics engine built on geometry code from retrogamelib and Super Effective's vector. So for once I don't have to worry about people not being able to compile PyBox2D or Pymunk - I just have to worry about it being chuffing slow. It doesn't have a broad phase yet, but it does have a rough and ready collision solver. So what you're seeing here is the dude standing on a box that he can also push around (hence they are both highlighted green).



The other thing I landed was a basic character animation system, which as promised keeps most of the animation state in the scenegraph, loaded from JSON. A trick for entering up animation data was to set up a quick optparse-based script which modifies a JSON document. So I can add a new animation to pc.json by running:

python anim_add.py -f pc.json -n running -f 0.3 -a 69,14 pc-walk{1..8}.png

It doesn't modify anything you don't specify on the commandline, so I can add more animations or tweak one property of an animation quite easily. Effectively I can get structured data into the game without writing an complicated editor, writing a complicated parser, editing ugly data files by hand or running the risk of making syntax errors.

Here's a random shot of our chappy pushing a crate out of the back of the train just because he can:

After a slow start redrawing the trains to add more headroom for jumping around etc, I added bullet physics -  and a law man to use them on:



The only really challenging feature left to tackle is AI; then we just have the simple matters of:

• Ladders
• Death, respawns, victory conditions etc
• Tons more art - backgrounds, scenery, train cars and more
• Levels
• Decoupling train cars
• Menu screen
• Sound

At last the game seems to be more or less fully playable. Not all the stuff in the original concept is implemented yet, but you can have a fight, and die (frequently). It's not that enjoyable yet, because the AI is very punishing.

I think something like reloading is needed too, so that you can spot your moment to attack. Possibly it also needs hand-to-hand combat so you have the option to charge in when you spot the moment. And some grenades would be a nice addition too.



Hopefully we'll have enough time to iron all these issues out.

Today I spent a very long time tracing and tuning the animation of a horse from Muybridge's originals. I think on balance it was worth it, as chasing up to the train before the level starts is pretty epic:



There were also a few minor tweaks, such as these gold bars and health crates:



All in all, I think we're in pretty good shape. We still have a lot to land in tomorrow's final push, but I'm always amazed at how much difference a Pyweek Saturday can make.

Saturday is always the highlight of Pyweek. You've spent 6 days laying a foundation and on the seventh day you write an awesome game. It's like the opposite of what God would do.

Many features went in today, including much more sophisticated AI written by Arnav, much more scenery, sound, music, intro screens...



The combat got much better, so hopefully people will find the game is fun to play. Also we added a side challenge - collect the gold. This is very useful actually, as it forces the player to explore the whole train: