I’ve just submitted my final thesis packet, and have a few weeks to breathe before heading to San Francisco in July for the last part of my MFA program. So, obviously, I’ve been thinking about the new GearHead game. Most of the parts are going to be taken from Dungeon Monkey Eternal, plus some improvements since I know Python far better now than when I started three years ago.
Choosing a Graphics Package
The first big decision will be to choose a graphics package. DME uses PyGame, which I like. It’s based on SDL 1.2, the same graphics library as just about every other game I’ve ever made. It’s fast enough to draw a not-highly-optimized fullscreen isometric map at over 30 fps on my laptop, which IMO is fast enough for a game of this type. However, it does have limitations. It doesn’t play well with multi-monitor setups and certain operating systems. It doesn’t come with many bells and whistles; things like text formatting and widgets need to be built from scratch. So, I’m considering my options.
One option is Pyglet, which is based on OpenGL. Because of this it should be faster than PyGame; instead of the Python interpreter redrawing the screen manually, the instructions get sent to the graphics card which then handles the heavy lifting. It also comes with html text formatting and a text input widget built in. On the down side, it is an event-driven system, which means that I’d have to learn how that works and modify the game logic accordingly. You know, I’ve been using basically the same input-handling loop structure since the 90s and I’ve become quite fond of it.
Another option is Kivy, a full featured widget system. This one has several big advantages- first, I could use a whole toolkit of UI elements and even create my own. Second, it has utilities to compile distribution packages for Windows, Android, and other systems. On the minus side, it is also event-driven and based on OpenGL. After looking through the docs I couldn’t see an easy way to add an isometric map display; other open source projects working on this problem did not look promising.
I think, for now, that I’m going to stick with PyGame, but I will try to rework the main game loop so that if I need to change it to an event-based system later on I’ll be able to.