Harry Tormey

Last month I interviewed both Alex Holkner the main author of Pyglet and Rene Dudfield a contributor to Pygame, you can listen to a recording of the interview with Alex here.  The interviews deal with their respective work on Pygame and Pyglet, some of the challenges they faced developing these libraries, what they are currently working on,  plans for the future and their experiences competing in competitions like pyweek. This article concerns the first interview with Alex Holkner. Alex has contributed to numerous open source projects apart from Pyglet and is currently doing a PHD at RMIT Univeristy.

If you have ever considered making a game with python chances are while researching the options available you came across both the Pygame and Pyglet libraries. The two libraries have taken very different approaches to the challenge of making games with an interpreted language. With Pygame the focus is on abstracting away low level details like how graphics are rendered. Its main assumption is that such things can be completely detached from the game logic. Most of the functionality in Pygame is built on top of its bindings to the c library Simple Direct Media Layer (SDL). In contrast Pyglet is written almost entirely in python and is mainly an OpenGL based software library, which inherently means its focus is on how graphics get drawn to the screen.

The origins of Pyglet can be traced back to 2006 when Alex participated in a google summer of code project the goal of which was to produce a pure python port of pygame using c-types.  The project did not receive a good reaction from the community as the pure python rewrite did not have the performance of the c version and hence was abandoned.

Pyglet was originally just going to be a nice library which used OpenGL functions to render sprites and text. Alex had always meant to write this library to help with common features he found himself implementing every pyweek. Prior to starting development Alex thought about the project some more and based on his summer of code experience realized that a lot of the things that Pygame does with SDL does could be done in python without any c  library dependencies. So the original idea behind Pyglet was to gets rid of Pygames distribution problems by having a library which you could drop in a folder and just run without compiling anything, also the libraries focus on OpenGL rendering would compensate somewhat for the interpreted slowness of python. Apart from Avbin, which is an optional component used for audio and video, Pyglet is totally written in pure python. 

One of the big potential problems of developing games with Pyglet is it’s reliance on OpenGL to render graphics to the screen. Typically a developer using OpenGL needs to be much more aware of resource management and what options/states he has used at any given moment within an OpenGL context. In contrast SDL, which Pygame is based on, has two options for rendering either using OpenGL or SDL surfaces. Pyglets OpenGL focus is a double edged sword as usually it makes simple sprite based games such as puzzle games a lot tricker than they need to be. Conversely this fact also makes things like developing 3D games or impressive graphics a lot easier. Another problem Pyglet faces comes from its design decision to avoid c where ever possible. A consequence of using only an interpreted language like python and no c is that it makes some game related tasks such as writing a real time audio loop practically impossible with any kind of CPU left to spare.

During the course of the interview Alex highlighted both of these problems. A suggested solution was to revaluate one of the core design decision’s behind Pyglet and allow for critical parts of Pyglet to be rewritten in c and tied in to the existing python code base using c-types.  However such a rewrite would require a large investment of time and Alex is very busy completing his PHD. Also the current development version of Pyglet available from the subversion repository still requires a large amount of work to be stable and usable. This would probably have to happen first before any major rewrite could occur.

A subtle but significant diffrence between Pyglet and Pygame is the way that they link with c libraries. Their are two ways to hook a c library into python, one is to write a c extension to python, the other is to use a foreign function interface like  c-types.  Pygame is writen as a python extension, what this means is that for each version of python and each platform a seperate build of  Pygame must be made.  So for example you would need to do a seperate build for python 2.4, 2.5, 2.6 on Windows, OSX and OpenBSD. Pyglet on the other hand uses c-types to talk to c libraries like Avbin and thus does not need a seperate build for different platforms or python versions.

For me the big take away’s from this interview are that Alex would be open to rewriting parts of Pyglet in c using c-types and that competitions like pyweek have demonstably played an important role in motivating people to write cool new libraries for making games with python. In my view, relaxing Pyglet’s original design goal of being pure python is a good thing and if done correctly could lead to a host of valuable high performance libraries  which could be used by other projects apart from Pyglet. Such a rewrite is unlikely to occur anytime soon unless members of the wider Pyglet community step forward to assist Alex in this ambitious endevor.