The Pyglet Game Library

Over the holidays, I sat down and wrote a casual turn-based strategy game. Aside from the obvious fun aspect, one major motivation was to gain experience with the pyglet game library, which I wanted to evaluate as a potentially general, light-weight GUI library for Python. Overall, my impression of pyglet was very positive: relatively light-weight and compact, very fast, well-documented, works as advertised.

Pyglet can feel quite spare: it provides only a core set of features, and does not offer a particularly rich set of convenience functions. One should be prepared for the need to augment the existing library functionality with some project-specific helpers and customizations. But because the core library itself is so small and transparent, this seems fairly easy (and, arguably, a better trade-off than having to learn the big, bulky, and possibly buggy feature set of some big and bloated other library).

Pyglet’s architecture is interesting, because it is entirely event driven. There is no game loop; instead, game elements register event handler for the events they are interested in. The framework dispatches event (mouse, keyboard, and timer events), and the game propagates by responding to received events. Anyone familiar with DOM programming will feel right at home.

Actually, almost at home. One major difference between pyglet and DOM programming is that in the latter case, event handlers are registered with the page elements that respond to the events, and the runtime propagates the events to all handlers (capture and bubble). In pyglet, event handlers instead must be registered with the elements that generate the events: the framework does not provide for centralized event delegation to receivers. This requires a somewhat different mindset, and possibly some additional support infrastructure on the part of the programmer. It also seems to open up the potential for possible race conditions among the events in the event queue. (If I had to do it over, I would organize the event handling in the Takeover game differently.)

Overall, I am certainly positively inclined to keep using Pyglet for future Python projects involving a UI component.