Wednesday 20 January 2010

Python Game Lab

The Concept

I started a new project on Google Code called pygamelab. Often, when you have some spare time and want to try out an idea it takes you most of the time to figure out which libraries to use, how to use them, debug them and develop your idea. Sometimes, your enthusiasm for the idea has evaporated by the time you finally have the tools to attack it.

It would be nice to have a starting point that was:
  • Python: quick and fun to write.
  • Portable: Works on Windows, Mac and Linux.
  • Has lots of features to play with.
  • Has plenty of examples.
  • Has some useful tools.
  • Well documented libraries.

One popular solution is pygame, but unfortunately Mac support isn't great. You need to install the python.org version of Python in order to install the version supplied off the site; I don't want to do this. I don't want the clutter and confusion. And if you do compile it natively, only other users that have done that can play your games.

The Libraries

So I looked around and found pyglet. This is a portable, Python OpenGL wrapper. It uses ctypes to access the necessary binary libraries for each platform. Pyglet also includes avbin, which gives access to multimedia functionality, like video streaming. Brilliant!

Additionally, there is Cocos2d, a layer on top of Pyglet, which supplies things like game flow, sprite management and tiling. Then for physics, I've chosen pymunk. This uses Chipmunk, the C library, which I've used before. Again, this uses ctypes, but this time to a supplied binary. It works on Windows, Linux and I've supplied a Mac binary (that works with the system Python). There will be more libraries to come as new features get added. I'm currently experimenting with GUI libraries kytten and simplui.

An important point to note is that the libraries are included in the repository. This means a user does not have to install extra Python packages and the versions will be compatible. It also means that I can fix bugs (which has happened) and modify the libraries. For example, they can be patched from the library repo with the latest features. For the package to be portable this means that care should be taken about any binaries that are included. Only two libraries contain binaries at present:
  • pyglet, with avbin. This looks to have good cross platform support, and uses ffmpeg, which again is well supported, portable and stable.
  • pymunk, which uses Chipmunk. This also looks to have good cross platform support (and 32/64bit support).
Hosting and Version Control

My previous projects have been on SourceForge. This is great site, but it is becoming a little slow and cluttered now. I thought I'd try Google Code, and so far it has been very good. Very fast, nice set of features and not complicated. Just the right level of functionality for managing a small project.

For version control I decided on Mercurial. I'm relatively new to DVCS, but I've really started to like the idea of having a repository that you can clone and experiment with, and also that you don't have to be network attached to commit work. It makes working and experimentation a lot more flexible. It's nice to be able to clone a repo and experiment, commit to that depot, but then throw that work away if you want to. In non-DVCSs you'd have to obliterate the information somehow, and this sometimes has dire consequences.

The other nice feature of Google Code projects is that users can clone a Mercurial repos for their own use. So if you want to collaborate with people, you don't have to give them access to the main repo. They can go away and experiment and do whatever you want, and you can choose whether you want to pull and merge. This is one of the ideas behind pygamelab, that you can clone a useful starting point and do your experiment quickly.

The Future

It's relatively early days, but I'm pretty happy with how it's going so far. I'm planning to supply a few simple default games from different genres that supply lots of different features. These will act as starting points and as sample code. And developing them in the first place is fun besides.

So the idea is:
  • You clone pygamelab.
  • Mess around.
  • If you cloned the repo in the pygamelab project you push back any cool changes.
  • Everyone else can see your work and potentially pull it.
  • Any good features make it back permanently into the main repo.
Assets

Some of the default assets are from the Lost Garden site. There are some interesting articles on there and I get itching to try them out, but there is always that hurdle of getting started. So hopefully soon I'll be knocking out games or other apps. Just doing the research and getting things going has opened up a whole load of ideas.

No comments: