PyWeek - ADMIN: How to package your game

Owing to some historically terribly packaged games, I've created a "game skeleton" that all entries must download and use as the basis for packaging their game. Please find the "skellington" in the help page section on how to submit your entry.

My reasoning for requiring the use of the skellington is pretty simple: users downloading the games will have an entirely predictable method of invoking the games. No guesswork, no pain.

And I figure that's pretty darned important.

— richard on 2007/03/24 22:30 of Fluffy Menace

Comments: (log in to comment)

By eugman on 2007/03/25 00:19:

What if I end up having one python file and a readme file. Am I still required to make use of skellington?

By eugman on 2007/03/25 00:20:

What if I end up having one python file and a readme file. Am I still required to make use of skellington?

By eugman on 2007/03/25 00:20:

When I saved it took me to your profile or something so I ended up posting twice.

By RB[0] on 2007/03/25 00:22:

And can I have only a single folder with assets, instead of having 'data' and 'lib'?

I'll use the skellington if need be, but I would prefer to just develop the game, and have another file call the game?

If this would disqualify me, obviously I would not do it, but I feel that there are getting to be too many rules coming up :/ And that we should be allowed to make the game as we please, but perhaps dock "production" points if the packaging is terrible.

By richard on 2007/03/25 00:28:

I don't think people realise this: I actually get email from people downloading games from the PyWeek site and not being able to run them (usually because of simple packaging problems) and taking away the message that all of the games must be pretty crap. And perhaps that's a problem with all other Python-based games.

eugman: Yes. Your one python file will be called "main.py" in the "lib" directory.

RB[0]: I think you understand where I'm coming from.

Is this really so onerous?

By richard on 2007/03/25 01:31:

Based on feedback from last time, I have altered the ratings system so that you may mark a game as "Entry Did Not Work". Your rating of the game (fun, innovation, production) will not count towards its final ratings tally, though you may still have the option of disqualifying the entry if you need to.

By RB[0] on 2007/03/25 01:40:

Thats ok Richard, I'll just have to use/learn a different way of doing it, but that is rarely a bad thing :).

It may be I am making a mountain out of nothing ;)

By Tee on 2007/03/25 02:19:

richard: I don't mind the skellington. But I'm going to be honest, just to let you know, the first time I saw the proposal, it felt like "I can't trust you to make a decent package, so you're only allowed to structure your package like this". It's not hard to find people who like their own way of structuring things so much that they fight about it.

But since you run pyweek, you've seen every pyweek game, and you know much better how many games are badly structured, that means structuring really is a problem. In that case, I think it's a good idea. Better to follow a few standards rather than have a lot of unplayable/hard-to-run games.

It's a pity some people think all pyweek games are bad just because one can't be run.

By Tee on 2007/03/25 02:20:

Oh, and I forgot to ask, what does 'skellington' mean? :)

By richard on 2007/03/25 02:46:

It's a play on words, and a reference to Jack Skellington :)

By pekuja on 2007/03/25 03:51:

I'm all for this. It's not like it actually limits you in any way. The data directory/module might confuse some folks a bit though. You might want to include a variable that contains the path to the data dir. Currently there is a "dirname" variable in the module but that just contains the directory where data.py is. I suggest having that point directly to the data directory.

By richard on 2007/03/25 05:01:

Sounds like a good idea pekuja. Updated to 1.3.

By philhassey on 2007/03/25 06:01:

Hey - locate the "run_game.pyw" should say "run_game.py". You might also want to remove those junk .pyc files. Also - if you want, I can supply my hacked together version of setup.py that builds py2exe, py2app, and (if anyone cares to) cx_freeze binaries.

Great job on the skellington - I expect this will increase the odds of games being played by quite a bit this time :)

Phil

By philhassey on 2007/03/25 06:06:

Hmn - maybe I take back the .pyw bit. (Just looking through your other stuff...) That's kind of neat ...

By richard on 2007/03/25 07:03:

.pyc files: whoops, the create-upload script had the same bug as my create-skellington, and was including the .pyc files. /me forgot splitext() returns a tuple. Skellington 1.4 uploaded.

Please, email me the setup file Phil :)

By gizmo_thunder on 2007/03/25 14:53:

This is a great idea.. this will make judging a lot easier than what it used to be :)

By eugman on 2007/03/25 16:03:

So if everyone is using this standard does this mean we someone could make a menu to access all the games? That would be something really cool.

By Tee on 2007/03/25 16:45:

Yes, that would be convenient. After the deadline, someone could make a package with all games and a menu.

By gcewing on 2007/03/26 05:39:

Perhaps you could clarify which aspects of the skellington are actually requirements, and which are just provided for convenience if you want to use them.

For instance, presumably the name of the startup file is a requirement, but use of specific subdirectory names (lib, data, etc.) is not?

By richard on 2007/03/26 06:24:

I don't want to really get into it too much because I don't want newbies shooting themselves in the foot just because that want "data" to be spelled "Data" but then in their code call it "data" and boom it breaks on UNIX-alikes.

Or maybe I'm being too paranoid. I dunno, I've just seen so many games broken because of silly little packaging mistakes made by first-timers (and in some cases second- and third- ...)

I you wish to change the structure, do so. If it breaks, I will have no mercy when I come to rate your game :)

By philhassey on 2007/03/26 15:31:

I've got an idea for a hack that would help solve one of the other major packaging problems - case sensitivity:

- add into run_main.py something like:
import os
import glob
join1 = os.path.join
def join2(*p):
    #use glob to find the file in a case-insensitive manner
    #return the filename if it exists ...
    #or just return the filename
os.path.join = join2

That might be wrong to add into this though. But if you think it would help, I'd be glad to fill in those details in the middle.

By philhassey on 2007/03/26 15:45:

Hmn - a better way might be to check for a file with the same cased name existance, and if the file exists but doesn't have the same case, print out "warning file X has incorrect case" .. Then they'd be warned if this is happening, and could fix their code.

By RB[0] on 2007/03/26 17:42:

I dont think you are paranoid Richard :)

I know last time packaging wasn't one of our strong suits ;)
Perhaps you could just make a rule that you can only have one .py file in the main directory, one README.txt, and maybe a LICENSE.txt?

Just throwing out ideas, I hadn't realized that you had been getting complaints about the games not running.

My biggest concern was that when it is no longer a pyweek game, I would have to re-write a lot of it to get it to look like it were a professional game.
I wouldn't want the main start script for the program to be "run-program.py" or "play-game.py" or something, if it were outside of the compo :P
But now that I look at it that isnt really that bad ;)

One more thing, maybe you could ask people to name the folder of there game there team name?
So instead of "the whatever game" they would put "team_name"?
That would really help the judging, instead of trying to find out who's games are which :)

By richard on 2007/03/26 22:15:

Phil: hrm, maybe...

RB[0] I already had that rule last time and it had zero impact on the quality of packaging.

Good idea about the naming though, thanks!

By korg on 2007/03/27 00:02:

Yay for this. The number of games that Ive downloaded and you end up with a directory of .py files and no idea which one to run. :) If you are lucky, the archive still has the .pyc files so you can work out which one to run by working out which file doesnt have a .pyc. ;)

By RB[0] on 2007/03/27 01:21:

Ohh, hehe, I didnt know this...
I guess I'm one of those who didnt follow that rule ;)

I think Ill have another gander at the rules page, seeing how bad I'm getting :P