While we’re waiting for the Liberated Pixel Cup contest results, I thought I’d take some time and post some personal thoughts about the contest in general, and what we might do better if we decide to run it again next year. First, a disclaimer: While several different organizations are taking part in LPC, the thoughts and opinions stated here are entirely my own, and do not necessarily reflect the opinions of the FSF, the Creative Commons, the Mozilla Foundation, or even OpenGameArt.org. I am one of the people involved in running the Liberated Pixel Cup, but this blog post is not an official statement. It’s just my own ramblings. 🙂
First things first. LPC was, in my opinion, an amazing success. Since we’re still in the judging process, I can’t give my opinions on specific entries, but I will say that we have some really amazing ones in my opinion, and if you haven’t already checked them out, I’d recommend that you do so. One of our contestants has put together a large page of game reviews, so that’s a good place to start if you’re curious.
The Liberated Pixel Cup has always, in my opinion, been about the advancement of free and open source software, so one of the decisions we made very early on in the planning process was that we would require all entries to work on a system that is libre from the ground up. That is, not only should the entries themselves be free software, they shouldn’t require that any part of the system running them be closed-source or otherwise proprietary. We caught a fair amount of flak for this decision, and I can’t say I was particularly surprised, since a lot of people really love proprietary frameworks and libraries such as XNA, Flash, and others. It’s understandably frustrating if your system of choice is specifically disallowed, but think of it this way: If someone have a Flash games competition (and there are plenty of these), people don’t take offense because they aren’t allowed to enter non-flash games. It’s not about the relative merits of various frameworks — LPC is just a contest for free and open source games. I’m pleased to say that I’ve spoken with at least one person who got their first experience developing games on a free platform, and has been very happy with it thus far. I’m hoping there are others who feel the same way. At any rate, while this decision didn’t go over well with some people, it’s not something that I would change in retrospect, and I can say with a fair amount of confidence that any future instance of LPC will have the same requirement.
We also got a number of complaints that the contest itself was too short. This is something that kind of surprised me, since most game coding contests (Ludum Dare, Bacon Game Jam, etc) are a weekend or a week long at most. It has been suggested on several occasions that we make the coding contest in particular last longer. This is an idea that I’m personally willing to entertain, but we’ll probably have to do some sort of informal survey to really get a feel for how long people in general feel the competition should be. Even though several people suggested it, it’s entirely possible that a majority of participants were satisfied with the length of the contest, so we’ll have to look at some real numbers before we make any decisions based on this. (One thing we’ll almost certainly do is provide a “break” of a week or two between the art and code phases of any later contests.)
All that aside, far and away the biggest problem we had with LPC was what to do about all of the different operating systems and environments people might develop their game in. There are two big things we had to take into consideration.
- People want to be free to choose the environment they’re developing their game on.
- People want to be confident that their game will compile and run.
- People want us to standardize on the system they personally like.
This is, of course, impossible, so we were left in the difficult position of having to give people advice for writing programs that will be easy to compile and run in multiple environment, but without pushing specific operating systems or frameworks. This caused a lot of consternation on the part of the code entrants (and also the judges — I’ll address that further down), but as far as I can tell, there isn’t a great solution. We either standardize on a certain system with certain libraries and exclude a large number of potential participants, or ask people to write their code carefully so that the judges will be able to compile it. I don’t personally regret doing it this way, and hopefully some of the specific things we learned this time around (about common problems, etc), we can pass on to people the next time we do LPC (* there are currently no official plans to run LPC again, but I’d like to see it happen, and we’ll talk about that once the results are announced).
When all was said and done, we ended up with about 50 code entries. First, a shout out to the HTML5 folks — your stuff just worked. Also, I have to come out and say that I’ve never been a big fan of Java; it’s always felt really clunky to me. LPC made me reevaluate my position on Java games. Given a set of entries that were built in different environments, it was an immense relief when I decompressed a game archive and found a bunch of .jar files, because I knew instantly that it would just work. So, Java folks, a shout out to you too.
The remainder of the entries were written in other languages, mostly C and C++. Some of them compiled very easily (these tended to be the ones based on established engines and frameworks, such as FLARE), others took a few tweaks, and there are a couple I still haven’t managed to compile at all. Which brings us to judging.
Judging has been slow. Since this is the first time we’ve done this, we had no idea the magnitude of the response we’d get. This is to some extent due to several perfectly legitimate desires that work in conflict:
- People want to be able to write their games in the environments they prefer (see above).
- People would like the judges to take time to fairly evaluate their submissions, rather than just giving them a zero the first time they run into trouble.
- People would like the contest results to be announced quickly.
In short: pick any two. As it stands, the judges (myself included) are doing our best to be fair and thorough, but the downside is that the entries require a lot of attention, and, given that we have jobs and families, we can’t put a full 40+ hours a week into judging, which means the results are slow. Not only that, personal lives have a way of changing at a moment’s notice, so it’s very difficult to even guess how long the judging process will take. While I’m hesitant to give any sort of estimate right now (due to the fact that mostly I’d be pulling a number out of you-know-where, plus my three previous estimates have come and gone), what I can say is that in future years, we’ll likely base our estimate of when the results will be announced on the amount of time that it takes us this year. Hopefully, if we can offer a set of suggestions to make later contest entries easier to compile (and perhaps as a result of the extra suggestions, be a bit harsher if we’re unable to do so), we can make the judging process more efficient.
Anyway, that’s about it — an inside view of my personal thoughts on the Liberated Pixel Cup. I’d be happy to answer any questions that I can, but before I do so, two things bear repeating:
- These are my thoughts alone, and they do not represent the official thoughts of LPC or any of the organizations involved.
- We’re working on judging, and while I’m happy to provide progress updates, I can’t give an estimate on when judging will be completed because I simply have no way of knowing. We will keep at it and get them done, but it could be two weeks from now, and it could be December.