Another month, another game. For May I’ve prepared an homage to the classic Missile Command. However instead of defending a city at the bottom of the screen you must instead defend a small blue planet in the center of the screen. I call it Blue Ball Defender.

Development was fairly straight forward. There’s a graphic for the planet. The missiles and explosions are just shapes drawn via Pygame. Some music and sound effects completed it. The only slightly tricky bit was a little bit of trigonometry. That was needed to aim the incoming missiles at the planet, to aim the outgoing missiles at the locations chosen by the player and to choose their spawn points as the outgoing missiles need to be initially positioned at the point on the planet’s surface closest to their target.

It’s pretty simple and it all came together rather quickly. So quickly in fact that I found myself wanting an additional challenge.

Rather than using a background image I decided to try my hand at generating a star field. I’m sure there are sophisticated ways to do this however I just randomly chose locations on screen and drew a white dot at each. Possibly for the first time in my programming career I wrote the code, saved it, ran the program and it worked perfectly without so much as a typo. This literally took twenty seconds although I then spent 5 minutes saying “that can’t be right, code doesn’t just work!”

So much for additional challenge. What else can I take on?

All of my previous Pygame games have redrawn the entire screen with every frame. It keeps things simple but can negatively affect performance. The alternative is “dirty rect drawing”, rect being short for rectangle. In dirty rectangle drawing you flag the sections of the screen that are dirty ie that require redrawing. This requires you to build up a list of rectangles covering the changed areas of the screen. You then supply that list of rectangles to pygame.display.update(). It then unions your rectangles together and selectively redraws portions of the screen.

Implementing this was actually fairly painless. I eagerly rushed to gather some statistics so I could see how much faster it was. The results were uninspiring. Dirty rectangle drawing caused my game loop to execute slightly faster but not dramatically. I suspect this is because either I’ve implemented it wrong or I’m simply not demanding enough for the difference to become apparent. At worst, regardless of the drawing method used, the main game loop is never being executed less than around 150 times per second on my laptop. That number can spike up to around 500 times per second during quiet moments.

The whole dirty rectangle business probably wasn’t worth bothering with for a game as simple as Blue Ball Defender. But at least I now have some idea of how it’s done for future projects.

That’s it really. This has been a really painless project.

Hopefully my next project will be a HTML 5 game. I’m just finishing up a Calculus course I’m doing on then I’ll get through Udacity’s HTML 5 game development course. With that under my belt I’ll make the switch from Python/Pygame to HTML 5.

You can get Blue Ball Defender from github at git://

Here is a Blue Ball Defender Window’s executable