This refreshing change from usual development practice along with it being a challenge as well as a good time with friends have made Game-in-a-Day events appealing enough for whole communities (edit: link removed, unfortunately dead by now) to have formed around them. Last October I decided to mail all my friends and host one myself.

After the usual scheduling woes Roman Pohrt, Torsten Gellert, Felix Stürmer and Anne Pohrt (part-time) brought their computers and participated. Julian Bischof couldn’t bring his equipment but created some music for us remotely.

As our group contained no real artists, it was clear from the start that our result would not look particularly pretty. On the other hand, everyone had some programming experience, albeit evenly distributed between C++, D, Python and Java. Consequently, we figured we would try to make up for it in gameplay and features. That also meant we could skip the obligatory asteroids clone and tackle something more complicated.

The collective search for a game idea finished quickly. We were going to improve on C-Dogs by supporting multiple players on one computer. We also planned to replace its line-of-sight effect with my (then recent) soft shadows implementation, hoping to overshadow our lack of art by composing our levels from dark hallways and by using lots of special effects.

Next was the choice of programming language and libraries. Since there was no common denominator, we selected Python and pyglet. It turned out to be a very good decision. Even though half of us had not used the language before, the essentials were easy to pick up and soon everyone was able to contribute: At the end of the first day I made our previously hardcoded weapons system more modular, then went to bed. When I pulled the changes next morning, there were four different guns (and an electro zapper) and someone had added code so they could be put down and picked up.

Our source management tool, mercurial, was employed less successfully. We had one or two cases where we accidentally automerged into the wrong direction and propagated those incorrect changes through our repositories. However, I maintain that these issues could have been avoided if we had been more familiar with mercurial and that a centralized version control system would have had even more trouble with the highly concurrent nature of our development.

This is when we got started. After about 16 hours of work (spread out over the weekend) we ended up with the current feature set:

• up to three players can play simultaneously
• they can move, shoot and bump into walls
• the levels are randomly generated
• there are three kinds of monsters, all with different behaviors</li>
• players have hitpoints and can die
• five different types of weapons lie scattered around the levels and can be picked up
• background music plays
• finding the blue goal portal teleports to the next level

From the start we structured our efforts pretty well. At least one person was always working on the next logical step or an absolutely necessary subsystem. We also implemented quick placeholders for things that were to come later. For instance, it took a lot more effort to get solid random level generation working than we expected, but due to a square placeholder level it did not delay the development of other components at all.

Nevertheless, there are some things that did not get implemented or fixed in time:

• the game is too slow
• collision detection breaks often
• level generation sometimes produces incorrect geometry
• line of sight and shadows are missing
• there is no menu

The slowness is definitely our major issue. We started profiling and sped up some parts of the code considerably, but it wouldn’t help. In the end, we even concluded that while Python had been an ideal choice from the perspective of getting everyone involved and productive quickly, it had also failed us due to its lack of speed.
In hindsight, I’m pretty sure we were wrong in our assumption that some Python code was to blame for the speed deficiency. If I comment out our level drawing, which is basically a set of OpenGL calls, my framerate increases dramatically. Thus this is probably some OpenGL usage or hardware acceleration issue. (edit: installing the new pyglet 1.1 makes the game run almost as fast as it did with the level drawing commented out; it was a library problem after all)

While the unreliable collision detection is merely an effect of the low framerate, the missing menu is excusable and the incorrect level generation is rare and only a graphical glitch, the lack of shadows and line of sight is painfully obvious. We just didn’t get around to implementing it. It seemed to not be essential for basic gameplay and hence was postponed time and again. Without it, however, our game is missing a key aspect; something that was supposed to make it unique and different.

Even with these defects, I’m amazed by what we have achieved in such a short time. Especially considering that we started from scratch with a programming language half the team was not familiar with. It was a pity we had to stop when the result was not yet what we had envisioned, but that’s the premise of these events: try to get as far as you can before the time is up, then stop and take a look at what you’ve done.

We certainly had a good time and I plan on doing this again next autumn.

Screenshots: