PyWeek Game Progamming Challenge Rules

revision date:2005/08/05

The PyWeek challenge:

  1. Must be challenging and fun,
  2. Entries must be developed during the challenge, and must incorporate some theme decided at the start of the challenge,
  3. Will hopefully increase the public body of python game tools, code and expertise,
  4. Will let a lot of people actually finish a game, and
  5. May inspire new projects (with ready made teams!)


1. Entry is individual or team-based

You may either enter as an individual or as a team with as many members as you like. Individuals and teams will be judged together (we figure the benefits of being in a team are outweighed by the disadvantages of being in a team).

All members of a team get to vote (though not for their own team), enter diary entries and upload files. People may join more than one team.

During the challenge, competitors are encouraged to hang out on IRC and post diary entries (diaries are supplied as part of the challenge).

By signing up to the challenge, you are agreeing to abide by the system conditions of use.

2. Entries are to be written "from scratch"

The intent of this rule is to provide a level playing-field for all entrants. This has a number of aspects:

  1. You can't have a personal "library" codebase that you use during the competition,
  2. If you do have a library you must release it within a reasonable amount of time before the challenge starts so that others may have the opportunity of using the library, and
  3. If you do release a new version of a library around the time of the challenge, we would ask that you make all efforts to not sabotage existing users of your library (see rule 9. Target Platform.) It's probably safer to wait until after the competition to release the new version, and use the old version for the competition.

You are allowed to use existing libraries that have been available for at least one month before the challenge (and are well documented). The libraries must not implement any game logic. The entire PyGame library is OK to use, as are PIL, PyOpenGL, PyODE, PyOGRE, etc. Links:
Pygame is a set of Python modules designed for writing games. It is written on top of the excellent SDL library. This allows you to create fully featured games and multimedia programs in the python language.
The PyGame section of the Python Code Repository has scripts, functions, and snippets to aid you in your programming endeavors.
PyOpenGL includes support for OpenGL v1.1, GLU, GLUT v3.7, GLE 3, WGL 4, and Togl (Tk OpenGL widget) 1.6. It also includes support for dozens of extensions (where supported in the underlying implementation). OpenGL is an environment for developing high-performance 2D and 3D applications.
Adds image processing capabilities to your Python interpreter. This library supports many file formats, and provides powerful image processing and graphics capabilities.
PyODE is a set of open-source Python bindings for The Open Dynamics Engine, an open-source physics engine.
PyOgre is a python binding for Ogre. Meaning you can use all Ogre functionality using python instead of C++. Ogre is an OO 3D rendering engine built on top of OpenGL and DirectX.
Slut is a programming framework for generative, synthetic, interactive, network-enabled graphics. It is a layer above PyGame, PyOpenGL and Twisted.
pgu includes several scripts and libraries. The scripts are a tile editor and a level editor. The libraries include a state engine, a full featured gui, document layout, html rendering, text rendering, sprite and tile engine, and a timer.
OcempGUI is an abbreviation for Ocean Empire GUI. and denotes a toolkit, which contains a set of various user interface elements based on and for pygame.
LGT is a collection of modules to assist with game development in the Python programming language, using the pygame libary.
A collection of widgets that provide a pygame Sprite interface
Mirra is a 2D openGL python framework.
Soya 3D is a very high level 3D engine for Python.
PyOpenAL is a binding of OpenAL ( for Python. OpenAL is a cross-platform 3D audio API appropriate for use with gaming applications and many other types of audio applications
Tofu is a practical high-level network game engine, written in Python and based on Twisted.
A small collection (64 packages) of pointers to Python software for working in three dimensions.
PyMedia allows you to parse, demutiplex, multiplex, decode and encode wav, mp3, ogg, avi, divx, dvd, cdda etc files manipulations.
A collection of code for games using python. Mostly code for use with games made with pygame, and/or pyopengl. Although some of it can be used outside.
Pygame Extended (or pygext) contains additions to pygame.draw (e.g. rectangles with round corners), an opengl accelerated 2D vector graphics library and a full blown, event-based sprite/scene engine.
Panda3D is a 3D engine: a library of subroutines for 3D rendering and game development. The library is C++ with a set of Python bindings. Game development with Panda3D usually consists of writing a Python program that controls the the Panda3D library.
The Python Computer Graphics Kit is a generic 3D package that can be useful in any domain where you have to deal with 3D data of any kind, be it for visualization, creating photorealistic images, Virtual Reality or even games.
"tdlib [is] a package of Python modules for doing the sort of things I think I will need to do to write a game". Downloads at
SPyRE is a lightweight OpenGL graphics engine, written entirely in Python. It includes a variety of cameras, several interfaces for user interaction, lighting controls and fog.

There's also some books that specifically cover game programming in Python:
"Game Programming with Python is about building games using Python. It deals with general concepts of game development and specifics that apply when using Python for game development. Some of the general topics include simulations, game architectures, graphics, networking, and user interfaces."
"The author set out to write a book like the one he used to teach himself programming at age 12. ... This book has been successfully used by homeschooling families and public school teachers." The library and example code supplied with the book is also available for download.
note:more links welcome

You are not allowed to use any exising personal codebases. This includes using those codebases as a point of reference. Hint: release the code well before the comp as part of a tutorial. Then you may refer to it -- and so may the other competitors.

This is a Python programming challenge, but that doesn't preclude the use of supporting languages (eg. C or C++ libraries, Javascript in HTML web pages, and so on).

3. The time limit is 1 week

The challenge starts 00:00 UTC Sunday and finishes 7 days later at 00:00UTC Sunday.

Work done on entries before this time would be considered cheating.

Entries will only be accepted after this time if there has been an error in packaging or transmission. If your game crashes then it's on your head. You should allow time for testing well before the deadline.

4. Themes are selected by the competitors

The theme of the challenge will be determined by a two-step vote in the week leading up to the challenge.

  1. A week out, all competitors select their favourite themes from the themes list. Everyone gets 10 votes which they use to select 10 themes. Votes are tallied. Ties are decided by random choice.
  2. The five winners from that round go into a final vote 24 hours before the challenge. All participants get to place a preference against each of the five final themes. The vote preferences are tallied, according to instant-runoff rules. The winner of that vote is announced at the point that the challenge begins.

All votes will be recorded for later examination.

5. Entries are judged by peers

Judging of final submissions will be done by your peers, the other souls brave enough to grind away for 7 days and compete with you (and finish). Judging is performed by the individual competitors, so every member of a team entry gets to vote. Competitors are not allowed to vote for any submissions they are involved with (so people signed up to multiple teams can vote for none of those teams).

Judging will be done in three categories rated 1-5:

Gold, silver and bronze awards will be given for each category.

Finally, competitors may vote that a submission be disqualified for one of three reasons:

A submission that gets more than 50% disqualification votes is not eligible for any prizes, though they'll still appear in the rankings ("do'h, if only I'd followed the rules!")

6. Existing artwork, music and sound effects may be used

As with the use of existing codebases, the intention is that all entrants start with a level playing field in artwork too. This means you shouldn't develop artwork beforehand that you intend to use during the challenge unless you also make that artwork freely available to all other entrants.

There should be absolutely no breach of licensing. You can't just cut-n-paste in artwork from The Simpsons (TM). A list of good, free art resources:

Stock Photos
Clip Art
Pixel Art
Sound Effects
note:more links welcome

7. Your Final Submission

You may upload your final at any time during the challenge. You may even upload multiple final submissions - but only the last one will actually be used for judging.

Your entry should include all code and data required for running, and instructions about how to run the entry. Consider using py2exe to generate a Windows executable (though also recognise that some people don't have Windows.)

Your entry must include all source code. You retain ownership of all source code and artwork you produce. The Free Software Foundation has a handy page of free software licenses which may help you figure out how to license your entry.

8. Allowed Documentation

Any online documentation may be used. This encompasses anything that might be viewed in a web browser and found by Google by any of the challenge entrants. Mailing lists and bulletin boards count.

If online documentation includes code snippets, that's ok, just don't cut-n-paste the code directly into your game.

If the online documentation is only code (ie. it's a web CVS viewer, or similar) then it's not OK.

Any existing code you've written should be considered out-of-bounds for the duration of the challenge.

9. Target platform

All entries must run in Python on the latest available libraries (ie. the latest release of PyGame, PyOpenGL, etc).

This doesn't mean you have to develop on those latest versions, just that any code you produce must work on those versions.

If you are the maintainer of a library, we would ask that you make all efforts to not sabotage existing users of your library. It's probably safer to wait until after the challenge to release the new version, and use the old version for the challenge.

The PyWeek Game Programming Challenge Rules Committee <>