PyWeek - Next Pyweek GuidelinesThis pyweek, I've had attempted to run several entries that don't work without a lot of legwork on my end to hunt down the correct 3rd party library, compile it, etc. I was guilty of the same thing in the past when I created a game that used Box2d and some very flaky python bindings. I got a lot of comments from judges that they were dissapointed because it was a pain to run.
I know pyweek is very relaxed in respect to restrictions on external libraries, python versions, etc, but maybe it is time to set some guidelines on what is acceptable to expect the judges to do to to play the entries.
For some people, it is difficult to get support for some libraries to work on their system. It may take a person 15-30-60 minutes to get an external library downloaded, compiled and finally installed, only to play a pyweek submission that lasts 10 minutes.
My suggestion is that we break down general parts of games (graphics, networking, physics, etc), and make a list of "acceptable 3rd party libraries", and encourage people to use those. It would be a starting point for the newcomers for python/pyweek and make judging less of a hassle if all the games had a common set of libraries.
I'll start a list, all of these are just off the top of my head and just here to serve as a catalyst to get a discussion going.
2.6 or 3.2 (both ok, i guess)
PyBox2d or PyMunk (just choose one. discuss)
P.S. could me make it a requirement to use os.path? Nothing is more annoying that correcting a bunch of "C:\Documents and Settings\coolman23\python\pyweek\game\art\logo.jpg" statements.
P.P.S why are people using python 3.2 for pyweek? The standard library has less to offer and the syntax in general isn't much different from python 2.6.
bitcraft on 2012/05/23 16:07
— edited on 2012/05/23 19:41
Comments: (log in to comment)