Phobocore – new game release

Here’s a new game I’ve been developing on-and-off for a few months now. I’ve become pretty busy at “The Day Job” recently, and due to commuting time I haven’t found time to add all the features I’d like. I thought rather than sit on this game for many more months, I’d just release it as is. It’s polished enough to play … but you’ll need a friend (if you live in Melbourne … I’m happy to drop round and play it with you :) ).

Phobocore is a two-player hotseat game, where the aim is to capture all the planets onscreen by shooting them. It’s sort of a cross between Asteroids and Risk/Galcon, with a respectful nod to open field overhead shooters like Robotron, Bezerk or Gauntlet.

Phobocore screenshot

Download Phobocore (v.09 for Windows & Linux) [10.3 mb]

The experience of creating this game has been quite enlightening so far. It really got me thinking about aspects of game design I hadn’t thought deeply about. I threw around lots of ideas relating to ‘resources’ and ‘defenses’, particularly thinking about how RTSs like Starcraft require balance in play style between defense building, offensive maneuvers and resource gathering. Good players must multitask and proiritize to get the upperhand on their opponents. Key questions like “Should captured/neutral/enemy planets be solid objects or unhindering ?” occupied more than one dinner time conversation, bearing out all the ways these would changed the game. I had great fun testing the effect of different game rules, and how these changed the dynamics of the gameplay (with huge thanks to my long-suffering girlfriend for playtesting. The next best thing to writing an AI player :) ). If you are keen to fiddle with these game rules yourself, you can throw various flags in the phobocore.py sourcecode to test how these variations change the play style required to win.

I also spent considerable time tweaking things like fire rates and the “planets-held to ammo recharge rate” ratio to try and make the game somewhat fun. It works pretty well for players that are equally matched, but much like Galcon, once one player gets an edge, it can be hard to recover and things are over pretty quickly.

Big features I’d love to add in the future: an AI compurer player for single player mode, and maybe network play. I need to work on the collision detection, improve the graphics, add background music, and add a help screen / tutorial screen and slap on a license (probably GPL for code and Creative Commons for audiovisual assests).

Have fun & feedback is, as always, welcome !

Continue reading…


Packaging a Python game for distribution on Windows — py2exe and cx_Freeze

I do my game development on Ubuntu Linux. In case you hadn’t noticed, unlike pretty much every Linux distro, Windows does not come with Python installed by default. For distributing games written in Python on Windows, it’s nice to create a compiled executable version (using py2exe or cx_Freeze, for example) that can unzipped or installed with two or three clicks, without requiring a separate Python installation. Gamers will typically give up if they have to go on a wild goose chase to install Python, Pygame and maybe something else just to get your lame game to run. (Hey, that gives me an idea for a great game – “Software Dependency Wild-goose Chase”. Actually, it would probably be un-fun. Scrap that idea.)

Continue reading…


Profiling Python functions with IPython’s timeit

If you aren’t careful (and even sometime when you are) realtime games written in Python sometimes hit speed problems and require some profiling to bring them to a playable speed. Typically, I would use the Python standard library’s “profile” module to find “hot” functions which are stealing all the CPU cycles. Today I discovered another way.

Over at scienceoss.com theres a nice post about profiling functions using “timeit” within IPython. Essentially, in IPython, you can run:

timeit my_slightly_sluggish_function(x, y)
timeit maybe_a_faster_function(x, y)

and get average execution time values over many replicates of each function call, like:

100000 loops, best of 3: 8.9 µs per loop
100000 loops, best of 3: 4.9 µs per loop

Interesting how programming for games and programming for scientific number crunching often have the same requirements and boil down to using similar techniques.


Interactive fiction in Python ?

I’ve just been researching Interactive Fiction (aka text adventure) systems written in Python. I’ve always wanted to make an interactive fiction, but never quite got around to it. I even started learning the Inform language a few years back, which can be compiled to run on the Infocom Z-machine interpreters (like Frotz, among many others). Of course, I’d rather write it in Python since there’s more chance I could add some custom features to the game.

As tempting as is it to reinvent the wheel and write my own IF interpretor in Python, I figured it was likely that others had already done this grunt work for me. After a bit of Googling, so far Python Universe Builder (PUB) looks like the best option. Hopefully this will save me from the grue.


New release of Shoodar (v 0.11)

Shoodar is a little game I’ve been writing, mostly to learn Rabbyt (although these things tend to grow beyond learning exercises ….. :P). Essentially it’s just a silly vertical shooter, but there is an Ikaruga-inpired twist. It’s in early stages of development, but I’ve put a playable version up in the Games section

No nice installers and stuff yet, but the README in the archive gives some instructions for getting it running under Debain flavours of Linux.