disruption.ca

April 28th-30th was the eigth ld48 game programming competition. It’s the 4th that I have participated in. The only info online about my entry is my postmortem, which you can read if that sort of thing interests you. I’ll get around to creating a page for Bee Commander eventually, but for now I want to talk about some thoughts and observations that I have taken from this last ld48.

Following up on one of the topics from my previous post, I’ve started using iPython with very nice results. One of it’s many cool features is the ability to embed a shell into your code and launch it whenever you want. I mapped the ‘~’ key to launching a shell, and with almost no effort the development version of my game had a rough approximation of the Quake console. This goes a bit further though, because the iPython shell has full access to read and modify the entire game’s state, whereas the Quake console doesn’t know anything about the underlying engine. Also, iPython brings with it the ability to automatically launch the debugger whenever an exception occurs. Surprisingly this is less useful than I expected, as the default Python stack trace usually gives enough information to locate bugs, and the extra power of the debugger isn’t usually needed. I still haven’t really gotten into the full swing of the fabled interactive development style, where new functionality is dynamically loaded into running code and tested from the shell. But I am getting closer. I do seem to have cured myself of the need to scatter my code with diagnostic print statements every time I have a bug. iPython is a very powerful tool.

Which brings me to another topic. I initially started learning to program in Python for three reasons. It has a solid set of libraries for game development, it has solid cross platform support, and it is a high-level, powerful language. C and C++ are the standard for game programming, but I didn’t want to have to deal with the headaches of memory management plus the lack of dynamic language features. Despite more than a few frustrations with Python, I’m very happy with the choice. But I have to ask myself a question; if Python is so great for hobby game development, why are there so few good Python games? The PyGame site has lots of games on it, but very few that strike me as being really great. Every ld48 has lots of Python based entries, but they are seldom as good as the C++ games. Some neat stuff comes out of PyWeek, but I’m typically more impressed by the ld48 results.

Is it because there are better tools and libraries for C? Not from what I can tell. If there is a really useful library, there is typically a Python wrapper for it. Does Python’s comparatively slow speed hinder it? Maybe, but I don’t think so. Some of the most graphically intense ld48 games of the past might be difficult to implement in Python, but most of the best ld48 games could have easily been done in Python without having to worry about performance.

One idea that came up when Jay and I discussed this is that the talent pool for C++ game programmers is simply a lot deeper. I think this has some merit. Most professional game programmers work in C++, and when someone first approaches hobby game programming, C++ seems like the natural choice. So we have more people with more game programming experience using C++. Which would account for the best ld48 games typically being from C or C++ programmers. Adding weight to the experience matters argument is Phil. Phil is one of the more experienced Python using ld48 participants, and his mixed Python/C++ entry is the highest ranked game in the most recent ld48. As well, after working on 5 Python game projects and participating in 3 prior ld48s, I’ve gotten much better at it, and my Python game received an above average ranking. So perhaps experience is the key, and language doesn’t matter much.

If there are simply more C++ programmers with enough experience, it explains why they are typically over represented in the top of the ld48 results. I guess it makes sense, but I would have thought Python could provide more of an edge. Could Python’s edge come into play in a different manner? Ld48s often have many Python games that are ranked below average. Maybe Python makes it easier for beginners to get a game done in 48 hours, whereas you have to have a great deal of experience and skill to do the same in C++. I’ve been thinking about average rankings of C++ games vs. average rankings of Python games. It might be interesting to look at the percentage of Python users that submit a final entry, vs. the C++ users that do so.

One of the reasons that Python vs. C++ has been on my mind is because I played the ld48 #8 games so shortly after playing the PyWeek #2 games. I felt that the ld48 game were noticeably more interesting and of higher quality. Now part of this is just a numbers game, there were 66 entries in the ld48, vs. 37 in PyWeek. Plus the ld48 has the C++ programmers that I argue have so much experience, vs. Python only with PyWeek. But still, I thought that week long team efforts would produce much better results than 48 hour solo efforts could. now that I’ve thought about it, I think the extra time and the option of working in a team make it more difficult to produce something really good in a competition. It’s hard to maintain intense focus on a project for a whole week. The communication between team members creates overhead and distraction. Team entries might result in games designed by committee, which is bad when you are trying to make something great.

I read a comment in the ld48 irc channel about the distinction between good crappy graphics and crappy good graphics and I wonder if this is a factor in the ld48 producing better games than PyWeek. “I’ve got a week and a group of talented people to work with. We can create something big and complex, it will be great!” vs. “I’ve got 48 hours and I’m on my own. I’m going to make something quick and dirty and simple. It probably won’t be much, but it’s all I’ve got time for.” Perhaps it is possible to do a really good job on something limited and simple in 48 hours, but trying to make some thing big and complex is hard to do in a week. Aim as low as you can get away with and build up from there, instead of aiming at where you think you should end up.

DrPetter is a participant from the last couple of ld48s. In both competitions he made fairly simple, but very well done, platform games. The most striking thing is his art work. It looks like it was taken directly from the best Genesis or Super NES games, it’s very cool. Reading his worklog from the last ld48 I came across something I thought was interesting. He had implemented a zoom feature in his game that let him view the level from any distance, and adjust it in game. He initially created this to make debugging easier, and he was considering letting the player control the camera as part of the game play. He decided against including the feature though, because he felt that the zoom ability ruined the retro feel of the game. He has an interesting point. A Genesis wouldn’t have had the power to pull off the zoom, so you never saw that sort of thing in old games, it’s a modern feature made available be the power of 3d accelerated video cards. If he had included the feature, his game would have felt more modern, and players would probably more naturally compare it to modern games, which a 48 hour game can’t compete with. It would have crossed the good-crappy/crappy-good line. As the game stands though, it is very cool with an excellent 16-bit retro feel.

So, the moral of today’s story. I like Python for game programming, and I’m liking it more as I gain experience with it. Also, good-crappy is way better than crappy-good. If that makes any sense at all.