Just for the record...

richard:
I know in the past people have just not voted those, or they have voted all 0's.

Should I do one of these, or is there something else I should do.

(log in to comment)

Comments

I've just skipped voting on them. I've voted on all the ones I could get to run so far . There's only about 5 that wouldn't run on my machine.
Thats what I've done before too.
But some people were told by Richard to vote zero's last time around, and I was wondering if he still recommends the same thing?

For the current compo I've got the two games I cant play at all zero's, I was asking right now so that if I needed to change there is time...

Another idea I had would be to just disqualify it since it doesnt run on our machine? Then you could just categorize that as not working on the target platform?

Just throwing out some suggestions ;)
Well, as the team that used pyOGRE, I'd like to point out there's a different between doesn't work and not willing to make work. I don't know if you're talking about our entry at all. And as it's very incomplete, I dont' care what you give it, honestly... But I don't think it's fair to give out 0s when you just don't want to do the work to run it.
TenjouUtena: I spent about 2 hours trying to get PyOGRE working on my machine, filed a bug report about the build process and eventually gave up in frustration.
I'm also definitely not clear about what to do with games that don't work on my system. Right now I'm just not voting for them. (I'm not referring to the PyOGRE one, but ones that crash upon startup or immediately after, or don't have proper dependencies provided or documented.)
TU, I will work on playing your game, but its seems to me that all of the data is in the svn. Did I get something funny, or was it intentionally done that way?
Your game is one of only two I couldnt play, and its the only one I havent yet attempted to make work :)

But I dont think it should be the responsiblity of the judges to fix a game if it has bugs/errors. If the game is just needing the nescessary packages and those are difficult to install, that is the responsibility of the judges.

I was mostly referring to the games that have bugs/errors or just wont run on our platforms, not the games that just have to have hard-to-get packages installed to run ;)
I honestly don't care if you don't get the game to work. I would rather not be punished for it. :)
If your game doesn't work you're punishing me by depriving me of the wonderful experience! ;)

Annnyways... a good backup plan is to py2exe it and make sure it runs from there. That way you know you won't be missing libraries and the like.
TU, but if we cant for some reason play your game,
And we just dont rate it, it is the same as if we rated it average in everything.

But since we cant play your game we might be rewarding you and punishing other games we could play, but rated lower than average.

For me this is the biggest problem with just not rating games we cant play.

Since we couldnt play your game I dont think it is fair to leave it at an "average" rating since it was technically 'zero' in everything for those of us that couldnt play it.
>> And we just dont rate it, it is the same as if we rated it average in everything. No it's not. It's just like you voted exactly the same as the average vote for a given game. For instance, if I only get 4 votes, a 2, 2, 1, 1, that means I get a 1.5. At least, that's the way I understand the voting. The only way it's not fair is that people will less votes get less of the field to play with, so individual votes count for more.
... In fact, I just checked the math on my scores, and this is exactly how the voting works.

(Sum of score) / (num of respondants)

Sorry. I thought of that after I posted, but my comp just really puked on me :(
I think you're correct, if you dont vote you dont change anything, exactly as if you had voted the same way as everyone else.

None the less, if we cant play your game then we didnt see an 'average' amount of fun/innovation/production. So shouldnt we vote those at zero? Or maybe disqualify the entry?

I was just wondering what Richard thought we should do, since I have heard conflicting things, not start a debate ;)
BTW, when I said that you vote average in everything, I sorta meant that you vote the average of what everyone else voted.
It just came out really weird.

I really need a new mouse ;) whenever you click, it clicks twice, so often it'll delete something you dont want.

Sorry for the confusion.
Yeah, but this creates a slippery slope of 'How much effort to put in' that becomes very necessary to define.

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.

Like I said, I dont think games that dont run due to the peson not being able to get the required libs installed should be punished.
What I meant was if there is a bug or the game just doesnt work.

In the rules...
    Finally, competitors may vote that a submission be disqualified for one of three reasons:
    * Did not follow the theme of the challenge,
    * Did not work on the target platform, or
    * Entrant cheated.


So not running on a machine for reasons unrelated to the user would fall under the "Did not work on target platform" , IMHO
>> So not running on a machine for reasons unrelated to the user would fall under the "Did not work on target platform" , IMHO

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.

Mostly, but I would make the statement a little broader, since python is not a platform-specific language.
    "It was made in python, so it should run on python"
If it didnt run on python because you were doing something that is only feasible on certain platforms e.g.(you are using directpython-directx) then it would be in the "does not work on the target platform".
Because, since python isnt a platform specific language there are many different platforms contestents are using.

So...
What should someone on linux do if someone on windows chooses to make a game with directpython? They wont be able to play it so, IMO they should dq it for not working on there platform.
That is mostly what I meant and personally think.

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[0] 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.

pdallago: people who are using python for the first time are not likely to be the ones using highly specialized libs.
Likely they will just use pygame.

Py2exe isnt required because, while it is handy for people on windows to have it, it is no more nescessary to have an exe in order to run the games than it would be in linux or mac.

But I think we've gotten a lttle too complicated in this thread,
All I want to know is what to rate a game that wont run, due to errors, bugs, or not being finished.

Since there arent really any games that are using the scenario that is currently being discussed(only running on one platform), maybe we could wait untill the end of the compo to discuss them?
That way there is still time for us to change our "cant play votes" to what Richard wants.
..But, that is a good point pdallago :)
I hadnt thought of it that way.

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 :)

That may be the only contest I'm trying to win here: it's almost two weeks after PyWeek and I haven't touched my unfinished entry for at least a week. And I probably won't finish it before judging ends, either.