[2012-10-17] WTF, PyGame?
So I've been wanting to resurrect the Guns project for a while now, and after I came out of my multiple-year lethargy of not-really-being-a-programmer-for-a-while, I started looking into it again.
I retain my initial thoughts on language: I'm very much an interpreted language kind of person, since that comes with dynamic typing and good syntax (sometimes) and other fun and wonderful advantages to my way of thinking, and Guns is not the kind of game that would be easily bogged down by running as, say, interpreted bytecode.
I further retain the thought that Guns itself is not horrifically impossible for one person to do, like the other two games on my help wanted page, so it still makes for a potentially great learning experience. In fact, I'm thinking it's the kind of thing that a game developer would recommend as a starting project to an aspiring newcomer to get them used to the kinds of troubles they can run into when making games.
And so I started trying to remember what about developing Guns had been absolutely terrible that I could do something about, and the first thing that hit me was that PyGame wasn't all that great. Although, at this point, I'm not entirely sure how much of that memory is actually of PGU, the GUI library I grabbed for use in the game.
SFML?
With the above thought firmly in mind, I spent the last couple of hours looking for alternatives to PyGame. The first one I looked at was SFML, something I remembered my friend EzTarget mentioning back when we were dicking around with Guns together. What I found there is that the (official) python bindings to SFML are only available for the 1.6 version (the "current" version as of 2010-04-06), and that the next version (2.0) has a release candidate that took about two years to make and is still not all that great (81 open issues and 11 pull requests as of right now, mostly cross-platform issues with OSX).
Let me say that again in fewer words: the latest official SFML that I could actually use is over two years old, and has been pretty much stuck where it was then, while the new one has been in development for over two years and is still showing some serious cross-platform issues.
Despite all that, I might still go for it. SFML is being actively developed (as far as I can tell), and experimental python bindings for the 2.0 version do exist, and it's at least possible that by the time I get Guns somewhere good, the library will have caught up.
Something else, then?
But since I'm not actually sure I want to deal with those issues, I decided I'd look for other python things I might use instead. I thought myself fairly lucky to have found the PythonGames entry on the python.org wiki, which includes a "Libraries" section that I sort of grazed through. What I found, unfortunately, could be summarized as: "PyGame, useless (too much), abandoned, abandoned, useless (too little), can't tell if that's any good, useless...".
I've since found the Python Game Libraries article on the same wiki, which might possibly have something useful... but it's kind of disheartening to find the apparently wide array of choices basically reduce right down to "PyGame or learn one of the 3D libraries and how to use it to draw 2D stuff, and you might still need pygame for that".
What's wrong with PyGame, then?
Let me first be absolutely clear that I'm having a hard time remembering (I've had almost a year to forget about the difficulties), but I do have the memory of struggling to do things that should've been fairly simple. To some extent, that's likely just me having to learn Python, together with some leaky abstractions from the underlying libSDL, coupled with PyGame itself not really having all that many releases, and thus working to an older version thereof.
...In fact, now that I look at it, I notice the pygame download page dating the latest release as "August 6th 2009". So, basically, even if I were to use the current SFML, it'd be more recent than PyGame. Ouch!
I also remember that getting pygame to run through py2exe for a possible Windows release was remarkably like pulling teeth from a bear with no anesthetic. And I vaguely recall documentation that was painfully incomplete, or inexact, or something... but I can't make any hard claims or show evidence of this.
What the hell?
There seem to be a lot of resources for making games with python and pygame, and at first glance there seem to be a lot of alternative options and helper libraries and the like. When we dig deeper, however, we find that, like pygame itself, so many of them seem to have been abandoned years ago, and you're not going to be able to convince me that any of them was so perfectly bug-free that they wouldn't have needed bugfixes and patches that could've been released in the intervening time.
Ultimately, I'm not sure where to go from here. I'm aware I've only just scratched the surface of what probably is available, and I have only been going at this for a couple of hours (not counting the time to write this article), and I'm further aware that this is probably just one of those issues that crop up for all game developers that they have to deal with. I accept all this -- but I can't help but feel something is inherently wrong when the most famous python game library is three years old and probably features a "known bugs" list that's three miles long.
Happily, I do not live in a vacuum, so I can ask people I know (and people I don't know, if I want) for advice. So this topic may or may not be revisited in a later article. For now, I've confused myself enough.