RB on 2006/09/17 17:37
(log in to comment)
(Sum of score) / (num of respondants)
For instance, natively windows PCs can't open tgz or .tar.gz files. The 100% legal and free way to do this with tar and gzip isn't exactly easy or obvious. And WinRAR / WinZIP both technically cost money. So should a person who 'can't' untar things give all .tar.gz and .tgz programs 1s?(0s)?
In another, more real and at hand case, I got a set of 1s last compo because someone couldn't get pyODE to work, which is a rather common library in my book. And there are a lot of people who won't install like pygext, etc. to play games.
I really just don't want to get into a situation where we're judged based on others' efforts to run our game.
And, as a side note, the disqualify option, as stated, are for when rules have been broken.
OK. I see your point now. Although, I interpret this as specifically 'It was built in Windows to run on Windows and doesn't run on Windows'. I think you mean the same thing here.
I think Tenjou's interpretation is correct. Platform refers to either Windows, Linux, GP2X, etc.
A game should be punished only if it doesn't run on its intended platform(s).
This allows people who develop for a specific platform to participate in the contest without being disqualified.
Of course, it's in the team best interest to try to make the game work on every available platform, so that more people can play it.
I think RB has a valid point. Python can certainly be used to write Windows applications, but one of the strengths of the language (and most of the libraries) is that it works on many platforms. Given that more people in the system capabilities poll voted for Linux than Windows as their primary system and only slightly fewer had Linux overall, to make a Windows-only game (or a Linux- or Mac-only game) is to exclude many or most of the participants, devaluing the collaborative nature of the competition.
One thing which surprised me about the Ludum Dare rules was that they require Windows deliverables - something which could make it quite hard for developers on other platforms to provide if the judges want a pre-packaged executable or something really easy. The PyWeek rules should encourage developers from all platforms but define such deployment criteria clearly (eg. .zip file, optional setup.py script, list of dependencies with URLs), with the scoring in favour of games which run on more than one platform.
bishop: If some people don't have the time to install and maintain Linux, money to buy Windows or a Mac, or maybe previous experience programming in those platforms, how are they supposed to deliver a game that runs everywhere?
While Python certainly helps, if you can't playtest the game in other platforms, you can't be sure it's going to work.
I don't think we should exclude a great game or even decrease its score if it doesn't run on a platform other than the target platform.
I think Richard said it right on the rules: "Consider using py2exe to generate a Windows executable (though also recognise that some people don't have Windows.)" From what I understand, he's encouraging people to deliver code that runs everywhere, but doesn't punish people that aren't able to do that.
The goal of this competition is encourage people to create new games. Many people are using Python for the first time. Let's not make it harder for them by adding lots of unnecessary requirements. Like I said before, teams that are interested in their game becoming popular will make sure it runs in as many machines as possible. Other teams will be satisfied with barely finishing their first game.
I don't expect people to test on every platform, but although it isn't unimaginable for something using "vanilla Pygame" not to work on major platforms, developers have to consider a more conservative selection of libraries if they want to reach a wider audience. The issue is whether the contest encourages people to reach such an audience or not, and how one can reasonably judge games that many (or potentially most) people cannot run.
I think the help page is useful in giving some portability criteria, although the rules page should arguably carry the same information: use zip/tgz (although some prefer just zip), include a README.txt file, copyright and licensing information, dependency information and instructions on how the game should be run. The thing about bundling dependencies is interesting, but there are huge issues involved if one wants to bundle binaries, which is the easiest thing for the end-user, after all.
Perhaps experiences from the pygame.draw challenge might be educational here.
bishop: you win the contest for most negatives in a single sentence:
it isn't unimaginable for something using "vanilla Pygame" not to work on major platforms
I had to read that 3 times before I could understand what you were trying to say :)