pyglet – First Impressions

David Shaw, 2:46 am 26th May 2009
Posted under: Blog Babble

My first foray into graphical Python games using pyglet is complete. For a first test, I have made a simulation of the sport of tennis, featuring state-of-the-art ball ricochet physics and ball position matching artificial intelligence.

Tennis game screenshot

Okay, nothing to set the world on fire. The code is basically a hacked together extension of existing pyglet examples. If you’re interested in checking the game or source out, here’s the zip file. You will also need Python and pyglet installed, which shouldn’t be too big an ask; the only reason to download this game is if you are interested in pyglet.

Most of my time in the last week was spent revising Python, remembering how to use version control and learning Eclipse as a Python IDE. After working through the standard Python tutorial I cobbled together a simple event passing system, much like the code that forms the backbone of all my games for the last few years. I then turned to pyglet, and found that pyglet v.1.1 uses its own event system making my attempt completely redundant. Oh well, no harm done.

pyglet has a few sample programs to show you the basics, but I haven’t found a proper formal tutorial yet. Hence my game code consists of ideas cribbed from the sample programs and tweaked a bit using the documentation. It was basically built by what I call either the “hammer” or alternatively the “square peg” method of development. This approach is where you don’t approach code design as the careful assembly of precision engineered pieces, and instead you just jump in and plug any holes in your functionality with whatever you can find, hammering, breaking off and crudely modifying bits until it fits. It’s extremely inelegant and leads to sloppy unmantainable code, but for any domain new to me with many unknowns it’s the only methodology that I find works. Once you get a better grasp of the domain you have to switch to something else though, as this approach tends to fail spectacularly when your programs get over a non-trivial size.

With my brief experience of pyglet so far, I’m quite impressed. With pyglet it has been extremely painless to get OpenGL, sound and control working in Python. It’s not as if my tennis game is particularly taxing, but I know from experience even the basics of initialising everything can be a hassle, even with source code. With Python and pylget it’s been a breeze. I think it even runs via the interpreter if you wanted to slowly trace through things, which is something I haven’t seen before with a windowed app.

My biggest stumbling block would be thinking through the Python and pyglet way of doing things. I’m used to having all my code within functions, but Python allows you to put active statements and function calls dispersed within a module’s code which run at import time. It’s something I still have to wrap my head around, as I don’t know how much of that is considered “Pythonic” or whether it is too easy to abuse. To test this out, I guess I need to slowly work my way up the beginner game developer chain of difficulty, ramping up the level of planning each time until I figure out a elegant methology that suits both me and Python.

Overall, I think pyglet will find a place for sure in the future amongst my tool chain. It seems perfect as a method for quickly mocking together tests. I’m not so sure about production code – I think I will still need my own custom made libraries if I were to go with a Python base. For one thing, pyglet is OpenGL only, and I’d almost certainly need a Direct3D library for Windows. The other is that I’m still fairly sure that a custom made framework is probably better for the sort of 2D games I like to make, especially with the sorts of tweaks I’d like add in the future. Eventually I always need to tinker with the low-level stuff, and a custom made interface for the sorts of games I’d like to make is bound to be eventually be more efficient than a general purpose layer like pyglet. But pyglet is extremely useful for making this kind of system; I’m hoping I’ll be able to make layer on top of pyglet that allows me to seamlessly move from one to the other.

For now, pyglet is perfect to get comfortable with Python as a game development platform and to see how powerful it can be. I’d like to see how much code I can leave in Python and still make an efficient game.



Leave a Reply