Post-pyweek and suggestion for PW4

eltriuqS on 2006/09/10 08:40 of Kiwi

Just some things i wanted to write down:

Models
In the end, we have no models in the game (only coded glut functions), due to technical
difficulties (our modeler is down). Too bad we wasted so much time on writing and debugging
model-loading code. I guess next time we will prepare ourselves in advance to having no models
at all.

Bugs:
* Transparency problem in in-game left-bottom menu
* Time is reset when returning from paused mode
It looked like it would take too much time to fix them (They are a result of a design problem,
or the lack of it to be precise) so we postponed the fixing and so they got here.
However they don't *really* bother the game (If you don't pause).

Submission
We finished the game (at the current state) some 20 minutes before the deadline, but the server was too
loaded so i don't really know if the game will end up on the entry list.. :/
A suggestion: Everybody must upload their MD5 of the files until the deadline, and after they
will have a week to upload the files themselves, and so the server will handle just fine, and noone will waste
so much precious time before the deadline on uploading

Any comment about that idea?

(log in to comment)

Comments

richard on 2006/09/10 09:30:

I responded to your email regarding the submission but did't receive anything back from you. Please contact me to sort out your final submission.

pdallago on 2006/09/10 15:06:

We also had some troubles uploading our game, but mostly because it's quite big and we forgot to use the upload script.

I think the MD5 is a good idea, though algorithms for MD5 collision already exist. It would probably strain the server much less, and make it easier for everyone. You'd still have to upload the game pretty soon, so that other people can play it and rate it.

eltriuqS on 2006/09/10 19:23:

everybody have quite big games..

as far as i know, you can *create* two documents with the same MD5,
but you must know their content in advanced. anyway, after you submitted
a certain MD5, you cannot (easily) create another file that matches.

The rules can be: submit the md5 until the deadline, and the zip file until 24 hours after.
the file get checked automatically by the system against the MD5.

uri on 2006/09/10 20:51:

Well, I don't think anybody is really gonna find an MD5 collision just to get a few extra hours...
After all the idea behind the whole competition is fun, and if somebody really wants to break the rules, he can find easier ways...

Anyway, if any of you are still concerned about the weakness of MD5, then we can use a combination of MD5 & SHA (both can be easily calculated using the relevant python modules), so each competitor submits both the MD5 and the SHA1 hashes before the deadline, and the uploaded file will be checked against both. This should provide a reliable mechanism for enforcing the deadline while letting people upload the actual submission later.

richard on 2006/09/11 06:49:

The MD5 suggestion has come from a few directions and I hope to implement it for next time (assuming I can find the time to ;)

I agree with uri's comments regarding people bothering to try to h4xx0r their way through the MD5 scheme. I just can't see anyone doing it :)

Phil on 2006/09/11 12:24:

I would like to add my voice to the cacophany. MD5s are easy, painless, and don't cause an explosion of epic proportions ten minutes before the contest is over. I know you're a busy man, richard, so if there's anything I (we) can do to help ...

donal.h on 2006/09/11 12:38:

^^ There's the community spirit!

PyWeek is so much fun that I'm willing to help with whatever to keep it running smoothly. (Of course, waiting until judging is over would be good.)

Though after reading my code, you might not want me to touch anything... :)

alecu on 2006/09/11 15:21:

Richard: I believe the MD5 suggestion does not imply any extra code. Anyone with problems uploading can just post a standard journal entry like this stating the problem and the MD5 hash, and then upload later. It just needs to be stated somewhere on the rules.

Of course, if you want to get fancy...

eltriuqS on 2006/09/12 23:18:

Anyone will have upload problems: if some people will upload as usual - all the other will have slower pyweek.org.
also, an automated system for checking the MD5s is a must, because no one will want to compare 25 MD5's manually, and manage the whole thing (even if it's only one person who will do it)
and yes, MD5 alone should do for the reasons above (there are better ways of cheating)

Jay on 2006/09/13 00:02:

I think it's all too much work for too little problem. I don't think people here will cheat. There's no point to it.

Adding MD5's before you upload is just one more thing that people will stumble on in the rush to be done. Instead of trouble uploading at the last minute people will have trouble creating their hashes. There's already enough worries and hassles and blocks to stumble on near the end and I don't think another one is needed.

Simply give a ten minute or so grace period after the deadline, depending on load, to upload things and it'll be fine. I trust Richard enough in his judgment to know when someone's having legit issues.

Phil on 2006/09/13 16:43:

A ten minute grace period would not have been enough this past contest.

Generating an MD5 is hardly rocket science, and I think that people who can neither get a zipfile uploaded nor generate an MD5 sum should perhaps be disqualified. You can only lower the bar so much.

donal.h on 2006/09/13 23:31:

Since we all have python installed (I hope or there are other much bigger issues at hand) and there is an upload script...

it could be modified to make a hash of the file, send that to the server, then wait in a queue of some sort to upload the actual file. (Ignore the asynchronous nature of http and the issue of dependancies for the time being.)

The "queue" could be faked so only x connections are allowed and then >x connections are told to come back in y amount of time to try again. This could alleviate the bandwidth crunch in the final hour. I once implemented in PHP something similar to manage downloads when I was hosting a rather large file that got linked to from a high volume site and it worked admirably.

It's very hard to get a weeks worth of fun for free these days, not to mention 20+ games to demo. I'd be really sad if the hassle of running this comp made Richard throw in the towel.

eltriuqS on 2006/09/16 13:56:

i thought about another way to implement this:
in addition to uploading file (and screenshots), there will be a possibility to post an md5 (a similar method to uploading). i volunteer to create and share a script that calculates an MD5 on a file :)
until the deadline, a user can upload regular files and MD5s at will, and after it, for one day, MD5 upload is blocked and file upload will be successful only if a corrent MD5 was posted (several MD5s can be uploaded - there are enough hashes for everyone)
this way regular upload as now will still be usabe, but when reaching the deadline, we would only post MD5s to save bandwidth for the server (and continue fixing bugs in the last 10 minutes)

RB[0] on 2006/09/18 20:01:

I would also be willing to help create code/docs/etc. for it, if Richard decides to try it. :)

I also like the idea that you can spend the end of the compo bug-fixing instead of trying to finish half an hour early to avoid getting in trouble uploading ;)

pdallago on 2006/09/20 23:16:

While I brought up the issue of MD5 collisions, I also believe it's extremely unlikely someone would cheat that way (though uri proposed a very practical solution). As I said before, I think this is a good idea.

However, I'm more concerned with the possibility of human mistake: what if a team uploads a checksum of the wrong file, or finds out later the file has been corrupted, or even accidentally deletes their file.

The simplest non human-assisted solution I can think to this problem is to store not only one, but say the last 10 md5 checksums sent. That way, if a team cannot upload a specific file, it can still try sending previous versions.