It's All Geek to Me

The one thing that has always bugged me about sprites in PyGame is that they are so damn finite. Why should I be restricted to an upper bounded number of sprites in my game? Fortunately, I figured out a way of breaking the finite sprite limit, and render an infinite number of sprites to the screen - without any reduction in the frame rate!

Now before you try to convince me this is impossible with such arguments that as "an infinite number of sprites requires an infinite amount of memory", bare in mind that I consider the laws of mathematics to be more rules than actual laws. And rules were meant to be broken, as they say. Not convinced? Download and run this demo, and tell me when you run out of memory. Requires Python and PyGame.

If anyone wants the aforementioned rubber serpent, then let me know. I want to get rid of it before it starts leaving little rubber droppings behind the television. I'll even post it to you for free (UK only). On the condition that you have kids and you're not just a geek with an inner-child.

Now if you will excuse me, I have to get back to day-job, which is something that we adults have to do.

I recently posted a path finding demo that uses a breadth-first algorithm to route a sprite around a map. Kamilche has taken the basic idea and created a new demo with many improvements. Fugu has been replaced with an animated turtle that uses the A* algorithm to do the path finding. A* (pronounced "A star") generally performs better than breadth-first search because it directs the search towards the target, rather than have it expand evenly.

Kamilche is the author of Incarnation, an impressive RPG written in Python & PyGame. I highly recommend checking it out!

So you are writing a game in PyGame and you come up with the most beautiful particle effect. But when you implement it, you find that the particles seem to jitter between pixels, and it spoils the effect. This is because PyGame can only render sprites at integer coordinates, even if you give it float values. OpenGL or other 3D APIs don't suffer from this because they can apply filtering and effectively render images between pixels (or sub-pixel). But you can't do that with a 2D blitter.

Until now that is! :-) I've written a small module that pre-calculates sub-pixel sprites so that you can render a PyGame surface at fractional coordinates. It's nice and easy to use, and is almost a drop in replacement. Here's an example: continue reading…

I have written a demonstration of a simple path-finding algorithm (in Python), for use in grid-based computer games. It used a breadth-first search to route a sprite from one part of a map to another, avoiding obstacles in between. The code is a listing taken from my forthcoming book, Beginning Game Development with Python and Pygame

To run it, you will need PyGame, and of course Python. The code is completely public domain, use it for whatever purpose you want and you don't owe me a penny. Here be a screenshot...

A while ago I wrote a chess module for Python. Now this is not a chess-playing module, rather it parses chess moves, stores board positions and works out legal moves. It can also read and write PGN files. I can fairly confidently declare myself as an expert in this kind of thing, having written the PC chess game Chess Commander.

Chess is something that is very well defined, the rules are laid out in black and white, but there are enough juicy problems and gotchas to make it interesting to work on. It was the special case moves such as en passant and castling that were most tricky. I made extensive use of Python's generators extensively which did simplify things a great deal. continue reading…