Post-mortem on PyWeek
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
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
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
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
* The graphics, while simple and a bit childish, are (in my opinion) suitable
* 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.
I *should* be spending lots of time on my PyWeek entry
, but somehow I keep
ending up doing university homework instead. A complete misalignment of
I did buy the latest Whitlams album the other day. I don't think I've ever
loved a CD so quickly before! Especially the second one (Apple's Eye), which is
admittedly very straight-forward love song material, but is really, really nice.
The trouble with not being a super-user
I was considering writing some web pages to help with some assignment marking
that's coming up. Since other tutors would also use the pages, it makes sense to
host them on the university server, and has the added advantage of having access
The first trouble came while trying to use Python as the CGI handler. This
involved much more trial-and-error than anticipated. For future reference, the
following is needed in *.htaccess*:
AddType application/x-httpd-cgi .py
and the .py files must be executable by Apache, apparently.
Problem number two concerns getting Oracle to work with Python. There are two
libraries around for doing this (neither were installed on the university
server). The Zope interface
would not compile without pthread support in Python
(why was this left out of the university installation?). This in-development one
did compile after some hackery with the makefile and LD_LIBRARY_PATH. It even
passed some of its test cases (support for CLOBs is not yet complete).
The third problem relates to the shiftiness of having a 32-bit Python installed
on a 64-bit machine (it's a Sparc running Solaris 10). Naturally the default
library path points to the 64-bit Oracle libraries, which is what I had to fix
above with LD_LIBRARY_PATH. I could see no way to specify this path to the
Python CGI script though, which meant the Oracle module could not be imported as
the wrong shared library was being loaded. The only workaround I came up with is
to check the library path in the CGI script and exec() the script again with an
updated environment block if it's incorrect. This is quite horrible, and after
proving that it worked I abandonded Python for this project.
PHP is really the only scripting language left after Python that's installed on
the university computers. I'm not a fan of PHP, and spent way too much time
debugging issues with its dodgy variable referencing (read: aliasing).
The final nail in the coffin was not PHP, but Unix permissions. At some point
the script is going to have to either connect to Oracle and write some stuff, or
write some flat files (I don't really mind which). If a database is used, the
username and password for the connection need to be stored in plaintext in the
PHP file (or in a file readable by the web server). Since I can't set
permissions for these files to be readable by the web server *only*, the username
and password are in plain sight for any student to see. Yes, that's the students
whose assignments I would be marking, and are undoubtedly smart enough to log
into the database and change all their marks.
I can't think of any way around this, short of getting a super-user to set up
some permissions for me (they tend not to do that for students around here).
starts at 11am tomorrow, got to think of some ideas for a game that I can
put together in about a day.
It's no secret I'm a fan of Aimee Mann
; I own and love every one of her albums.
Her second-most recent album, Lost in Space, was the first of hers to feature a
single motif through every song (her most recent, The Forgotten Arm, takes that
one step further by making each song tell a single part of an entire story). All
her songs share common sentiments and ideas of course, but with Lost in Space
Aimee focuses specifically on themes of alienation and addiction.
The title of the album, as well as having the obvious interpretation of
isolation and helplessness, shares Google results with the 1960's TV show of the
same name, perhaps in reference to the longing we have of simpler times no
longer possible. In the chorus of the first track, Humpty Dumpty, the
protagonist tells us that that future -- the "tomorrow that never was"
 -- is gone:
>*So better take the keys*
>*And drive forever*
>*Staying won't put these*
>*Futures back together*
The Moth is the second-last track on the album, and it doesn't belong. Where
Aimee's other songs tell stories or monologues, this one exposes the theme in its
>*The moth don't care if the flame is real*
>*Cause moth and flame got a sweetheart deal*
>*And nothing fuels a good flirtation*
>*Like need and anger and desperation*
If you haven't heard Aimee's music, this may sound very cliche, and it would be,
for any other artist. Off the top of my head I can't think of any of Aimee's
other songs that spell out the theme with no attempt at disguise. The music
supports this: the melody is simple and reminiscent of Dylan, while the chords
are a simple minor blues progression. The acoustic guitar is in the foreground,
and synthesised sounds (otherwise a trademark of this album) are kept well
I've started thinking that despite this song's complete departure from Aimee's
style, it is in many ways her manifesto. Perhaps this is why every live
recording I have of Aimee begins with this song: she is laying out the
groundwork, or foundation, of what is to follow; providing an emotional basis
from which to expand upon.
 William Gibson, *The Gernsback Continuum*; from *Burning Chrome*.
Agents, their mothers and the babysitters
I finally have come up with a topic I am interested in for the major research
project for Intelligent Agents
, a subject I am taking. Ask any agent-affiliated
researcher what agents are and they will begin by telling you how different they
are to objects (in the "oriented" sense). Ask the same person what's
wrong with objects, and they will say that agents can be built with objects. Ask
them why agents aren't popular yet, and they will point out that objects weren't
popular for a long time either.
This love/hate relationship with objects is carrying the researchers and their
publications into making agents the next best thing. In one big embrace they are
creating a new and distinct methodology while not allowing themselves to be seen
as foolish in rejecting the status quo. What's more, this new methodology
requires new algorithms, new data storage techniques, new communications
protocols, new software engineering principles, even new ways to gather
requirements! It's a grant-funded researcher's goldmine, and with so little
commonality between approaches or terminology, there's practically no risk of
stepping on someone else's toes or duplicating someone else's work (as evidenced
by this list of no less than 28 agent-oriented software engineering methodologies
At the heart of the matter is a lack of understand of what a software agent even
is. Sure, there are papers that invent taxonomies and doll out attributes such
as *situated*, *proactive*, *robust* and so on; but the same paper can talk about
and timetabling software as if they are solving the same
problems. Similarly, there is some great theory about the
belief-desire-intention model of action and reasoning based on modal logic and
possible-worlds decision trees; but the agent frameworks that are actually
implemented (and claim to be based on these models) are really just collections
of sub-procedures with certain triggers (or in other words, a giant
"switch" statement). It's arguable whether any software implemented in
this fashion is remotely robust, flexible or proactive.