Post-mortem on PyWeek
2006-04-02 15:21:49
This morning marked the end of the PyWeek 2 contest, in which contestants develop a complete game in Python in a week. Inspired by NaNoWriMo, the event capitalises on the extraordinary work people can produce under the combined influence of a *very* short deadline and a community of like-pressured people. This year there were approximately 100 entries, of which about 35 were completed. The first thing you notice about these things is the amount of time and work people put into them. Despite having full-time jobs, university studies and families, these people can find an awful lot of time that you might not have thought existed. In my case, I was at uni basically full-time, in addition to writing two essays and coordinating a subject's assignment marking. Each day I was able to put in about 4 or 5 hours, and from Friday afternoon until Sunday morning I stopped only to eat and for a five hour sleep. I didn't keep track, but I suspect I put in about 60 hours this week. The game I wrote was inspired by *Lemmings* and *The Incredible Machine*. The idea is to construct a series of obstacles for the steam and water droplets to interact with in order to acheive the goals (watering the plants). The appealing parts for me about a game like this are: * It's dynamic: even though I'm designing the levels with a set solution in mind, there are potentially many other solutions that are just as valid. * There are no pre-conceived notions of what it should be. Unlike a platform shooter, first-person shooter, or driving game, etc, I am free to implement whatever user interface I feel like without confusing people. There are no high expectations about the behaviour of AI or graphics. * It appeals to people's creativity and problem-solving skills, rather than needing finely-honed trigger skills. It's the kind of game my Mum could pick up in a few minutes and then easily better me at it (this is yet to be tested..). The risky aspects are: * The environment in which gameplay takes place must be absolutely rock-solid. Unlike a traditional game, where the story is carefully directed by the designed, in a physics-based game such as this it is up to the model to provide consistent and reliable feedback in response to stimuli. * The puzzle aspects have to be carefully balanced so as to provide an interesting mix of puzzles which are difficult to solve yet easy to learn, and consistently entertaining. For the first few days I was very skeptical I could pull off the physics model. Despite being 2D and particle-based (rather than rigid-body), there's still a fair amount of maths involved, and is completely new to me. After just a couple of days though the code stabilised to the point where I could create devastating test cases that it handled gracefully. I put this down to luck, more than anything else, in that for the most part the parameters and behaviours I selected initially worked well together and survived with very little modification into the final game. The latter half of the week then found me doubtful of my ability to turn a physics engine into a game. As with my previous PyWeek entry, this came together in just the last few hours of development. I maintain that gameplay is extremely easy to code, but requires a complete engine underneath it before even being attempted. Lastly, I decided to draw all the graphics myself, with the exception of some freely downloadable photographed textures of wood and metal. Obviously this constrains my style somewhat, in that I cannot draw. I seem to have found a cartoon-like style using Inkscape that works for me. The last killer stretch of 24 hours programming without more than a 20 minute break is something I've done twice before: for my previous PyWeek entry and for my Interactive3D project. In all three cases the amount of work I get done is staggering. Not because of the hours involved, but because it comes down to working through a checklist in the final countdown to submission, making it impossible to fail. Sure, I feel like crap now (I've still had only an hour's sleep since then), but there's no other way to do a project like this, even if the same time was spread out over a week. So, the parts of the game I'm really happy about: * Very, very stable. It doesn't crash, and the physics is predictable and solid. * The graphics, while simple and a bit childish, are (in my opinion) suitable and clean. * The game is a *game*, with levels, a free-play mode, level editor and title screen. These are simple aspects to code but are things that can only be done at the very last minute, because they effectively freeze development. * I was able to come up with 10 quite challenging levels (the first 5 are introductory). This was actually harded than I expected, but makes sense in retrospect, as designing a level for a puzzle game is in many ways like designing a whole game, albeit with some constraints. Next time I'd like to try something in 3D. This would definitely require a big support library which I'd have to develop prior to the contest.comment