Poor entry packaging and disqualification

richard on 2007/03/17 23:58 of Fluffy Menace

Something that disappoints me about a lot of entries to PyWeek is that they don't spend the small effort required to have someone else test their game or write a nice README listing how to get the game going: dependencies, which file to run, the controls, etc.

A recurring issue we have in the challenge is that a lot of entries aren't runnable on some people's computers, for various reasons (can be as simple as documentation). We have the additional problem that non-game-hacker types come along and download a selection of games only to find they don't work (and then promptly give up thinking what a terrible platform we must be working with).

The rules currently state that entries should include "instructions about how to run the entry" and I'm considering changing this to must. I think it's that important that if you can't get a game to run* then that game should be a disqualification vote.

The challenge is a week long. I have trouble believing that people couldn't find some time to have friend(s) (including us other challengers) try out the game during that week.

*: note that I don't care whether the game is "complete" ... just that it should be possible for a 3rd party to get the game working.

(log in to comment)

Comments

philhassey on 2007/03/18 04:12:

I *strongly* recommend that if your entry depends on anything other than python+pygame+pyopengl make a binary of your game for either win32 or macosx. (Both is better!)

I tend to prefer to play games, not have an execise in system administration and troubleshooting. (In pyweek #3, I judged only 1/2 entries because of inability to get 'em working.)

And, even if your game uses just python+pygame+pyopengl, I'd still rec. building binaries - more people will try your entries who aren't "python users". This will gain more public interest in the contest results, since anyone could play the games without spending an hour installing python and other junk.

Just so you know, if you "know" py2exe and py2app, you should put aside about two hours for each. If you don't know them, put aside about six hours for each.

I don't know if this is in the rules, but I think it would be nice if people didn't have to have their binaries submitted by the deadline - just source, but had the option of submitting binaries for people to download afterwards - since sometimes they can be a bit of trouble to put together.

eugman on 2007/03/18 04:17:

Now I fall under the binaries wouldn't be required but what should I do about not having mac and therefore py2app?

TenjouUtena on 2007/03/18 11:59:

Also, if you make something that requires the libraries you're planning on using NOW, you can discover the got-yas in py2exe and py2app now.

philhassey on 2007/03/18 15:16:

eugman - well, not everyone can make binaries for everything. I'm just saying - if at all possible, please do! (And, optionally, allow those binaries to be submitted after the compo ends, so packaging doesn't cut into dev-time.)

saluk on 2007/03/18 18:34:

I really like the idea of source by deadline (working, running source, if proper libs are installed) and packaged later. Obviously packaging is difficult, because not everyone has access to all 3 major platforms, and there is no way to cross-build.

It would be neat if we could have a few people for each platform to handle builds for that platform for other developers who don't have access. If packaging doesn't cut into the week, I'd be happy building windows or linux builds for people. But I don't know anyone with a mac, and the mac's at University are too locked down to install all of the stuff I would need. So I have no way to build for OSX.

I really think as a community we need something like pybuildbot, but for packaging python applications. You would add your source to an svn account, and it would build an executable for the defined platform, maybe letting you select a few options and with some standard way to organize things. Then when you commit new updates, it builds again. You can have testers log on and download the binaries to test them and add tickets to trac on things that go wrong. Obviously it would be a huge project, but it sure is a nice dream.

pekuja on 2007/03/19 03:00:

I think entries should be required to provide installation instructions for any libraries the entry uses. This means at least a link to the library's website and the version number required (I recommend always using the latest versions, so that people don't have to downgrade if there are changes to the API in a later version or whatever).
I'm not saying this needs to be done for every platform, because everybody doesn't have access to all three major platforms, let alone all of their different versions. I am saying that you need to provide instructions for at least one platform (the one that they're using), because if you provide no instructions at all, or just a binary version, it's going to be hard if not impossible for people to get your game to work on their platform of choice.

korg on 2007/03/19 08:01:

.....and please please please please make it _OBVIOUS_ what python file to run.

The number of entries which are just a directory of py files and you have to see if its game.py or main.py or run.py or foo.py

richard on 2007/03/19 23:35:

OK, so how about we set up a nice game skellington that people can download and use as the starting framework for their game. This would include: 
rename_me/     (instructions will tell people to rename this to something sensible)
  README.txt  (including sections for description, controls, requirements, license, ...)
  run_game.py
  lib/        (contains all game code)
  lib/main.py (contains function "main" invoked by run_game.py)
  lib/data.py (contains helper function to load data files from the data directory)
  data/       (contains all game data)
Is there anything else that would be good to include? Are there any comments from those who have recently used py2exe and/or py2app and/or any Linux packagers that would affect the layout above? Should the above include a setup.py (or whatever is used by py2exe/py2app for building)?

richard on 2007/03/19 23:36:

(ps. I would probably REQUIRE that people use the skellington just to make sure that people who NEED to use it do so. Obviously people who are knowledgeable enough could alter the layout if/where necessary)

richard on 2007/03/19 23:39:

Oh, there would be an additional "create_package.py" in the top-level that builds a ZIP file for uploading to the server. It would ask the invoker for a version label and create a useful ZIP file for uploading. I'd also bundle the uploader script.

simonwittber on 2007/03/20 02:51:

that sounds very helpful. a setup.py file with relevant stuff for py2exe and py2app would be good too.

lib/data.py could be a lazy weakref'd proxy which loads files when they are first referenced, and unloads them when the last reference disappears... just an idea :-)

richard on 2007/03/20 03:15:

I'm not sure I'd want to get too fancy with the data.py implementation. Enhancements are left up to the reader :)

richard on 2007/03/20 04:32:

I've added a skellington to the rules / help page. I'll include a pointer to it in the first mailout due on Sunday for the theme voting.

Suggestions welcome - especially from someone with py2exe / py2app / etc experience.

RB[0] on 2007/03/20 13:44:

Just a question, but do we have to use the skellington?

I think overall its a good idea, but i would dislike it if it were a must.

richard on 2007/03/20 20:53:

"(ps. I would probably REQUIRE that people use the skellington just to make sure that people who NEED to use it do so. Obviously people who are knowledgeable enough could alter the layout if/where necessary)"

RB[0] on 2007/03/20 21:11:

Thats ok.

I would prefer it though if my data folder was on the same level as my actual game, ie you lib folder, and maybe rename the lib folder to resources or something.

Anyhow...

richard on 2007/03/20 23:15:

Mixing data and code is generally a bad idea, hence the lib / data split.

OTOH you can do whatever you like, just know that if you don't use the skellington and you leave out some critical part, or whatever, then you'll get no pity :)

RB[0] on 2007/03/21 00:06:

hehe, I meant make data a child of lib(or whatever), instead of a sibling.

I'll probably still use the skellington, then move the data folder inside lib.
I'm just glad I wont be penalized for doing that ;)

Hectigo on 2007/03/21 22:29:

Seems good to me. I'd make the data a child of lib too, and I don't know if the data.py would be of any use, but otherwise the skellington seems okay. Perhaps it would be good to keep the things required pretty much to the minimum - just force the run_game.py, README.txt or HTML and a separate folder for the actual code and data, and I think that would be enough. The packaging automation tools seem nice, and an included py2exe setup.py would be a great addition too.

alex on 2007/03/21 22:37:

run_game.py should not assume working dir: 
import os.path
libdir = os.path.join(os.path.dirname(__file__), 'lib')
sys.path.insert(0, libdir)

richard on 2007/03/22 02:44:

Moving the data dir seems like an easy-enough thing to do if you really wish to (though again I recommend not mixing data and code, even if the data dir is a subdir of the code dir).

The intention of the data and lib dirs, and the data.py module, is to encourage good game layout for beginners.

Thanks for the patch, Alex. Have updated the dowload to version 1.1

alex on 2007/03/29 01:08:

First time using py2exe today, and discovered it doesn't provide __file__, so please retract my previous patch :-)

(Incidentally, I haven't seen a good workaround for this: sys.argv[0] can be tricked by a shortcut... any way to discover the .exe location on a py2exe'd app?)

richard on 2007/03/29 02:29:

Please, anyone? Also do py2app and cx_freeze have the same problem?

emptyskull on 2007/03/29 09:01:

For py2exe programs, you should be able to assume that the current directory is the directory with the EXE file in it. Either py2exe or the Windows shell changes to this directory before the Python payload runs. How about maybe (not tested): 
import os
try:
   basedir = os.path.dirname(__file__)
except:
   basedir = os.getcwd()
libdir = os.path.abspath(os.path.join(basedir, 'lib'))
sys.path.insert(0, libdir)

alex on 2007/03/29 09:29:

Working directory is not necessarily the executable directory, even on Windows.

This is actually only a problem for finding the data directory: setuptools requires us to give the import path for packages anyway, so there is no need for sys.path hackery on a py2exe'd app.

py2app doesn't exhibit this problem (because the files really do exist on the filesystem, unlike the py2exe'd archive contents).

richard on 2007/03/31 22:03:

I've revised Skellington (to 1.6) to:
  1. Handle absence of __file__ in run_game.py
  2. Add filepath() to data.py to just get the path to the data file.
Skellington 1.6