PyGame Implementation

PyGame Implementation Specification

What this document is about

We want to enable game development in a way that allows a variety of levels of use.

Beginners who want to experiment with game development techniques in a simple environment. This document does not consider this case.
Slightly more advanced beginners and students who are starting to experiment with Python but might need a lot of handholding. This document is not primarily concerned with this case but may discuss it.
Advanced students and game developers who want to code in Python and can handle an API and the API documentation. The rest of this document discusses this case.
Hardcore professional game developers wanting to build games that push the limits of the OLPC and want to code in C or C++. This is discussed elsewhere: SDL Implementation

Choice of API: PyGame

The overwhelming leader for Python game development is PyGame. PyGame is built upon SDL, which is a cross-platform library supporting a variety of game-related interfaces, including graphics, sound, video, and input devices. SDL has been implemented on a very wide variety of hardware.

PyGame works on most major computer systems and has been in use for some time. Some commercial games have shipped with PyGame, and a whole lot of tutorials and sample code, as well as open source games, have been written using PyGame.

In a world where we would like end users to be building their own games and developing for the OLPC environment, PyGame will give those users a leg up with all of the available material for game development. See Content and OLPC on open source software.

If you're thinking of developing games in Python for the OLPC, please start by prototyping them in PyGame. At the moment, there is no guarantee that the code will run unmodified, but the port should be simple.

API details

(undergoing editing and not yet finished)

PyGame standard modules that will or should be included

Cursors -- manages the hardware cursor. We may not need/want to support the load_xbm module; instead we may want to add support for a standard image file format supported by the tools on the XO.
Display -- required support for setting up a display, but the number of modes is limited and the fullscreen option should be ignored. Existing PyGame code that tries to set up displays intelligently should still work if it was coded correctly, but all roads should probably lead to the same display setup result.
Draw -- line and shape drawing. Antialiased color lines may need special attention because of the characteristics of the display.
Event -- event handling. In the long run, we want to integrate this into Sugar so that the events play nice with Sugar / GTK.
Font -- we want some font handling to support the platform fonts, but I don't know the platform story on this. We'll make it easy to use the platform's fonts from within this API.
Image -- we'll support loading and processing images from whatever file formats are supported by standard platform libraries. We especially want to make sure it's easy to use the file formats created by the tools on the platform.
Key -- we'll support the keyboard, including the game keys.
Mixer -- this is the sound mixer, supporting sound loading and playback for certain standard formats. Again, we should make sure we can play formats that can be created on the device, and remove support for formats that are too big or obscure.
Mouse -- obviously, we'll support the trackpad. Can the graphics tablet be supported by the same API?

PyGame standard modules that will not or may not be included

Cdrom -- manages CD drives; we don't have a CD so no need or value for this API.
Joystick -- There's no joystick-like device on the system, but do we want to have support available for external USB joysticks? Could we?
Movie -- I don't think this is intended to be supported by the system, but even if it is we may want to leave it as a separate module.

Additional items that are not in PyGame but need support

PyGame Implementation

Contents