SpaceRat - an exercise in game programming

Almost entirely throughout my life, I’ve had access to computers. In most of that time I’ve wanted to write computer games. Most of my attempts have been aborted early on, before even getting code written. Stacks and stacks of paper have been used to sketch characters and scenery. One day in 2001 I decided to put together a small Space Invaders-like game named SpaceRat.

SpaceRat began as a set of graphics I had created for a friend’s clone of Space Invaders. I had drawn a “hero” space ship and some enemy ships. There were a number of enemy sprites that I did not use in SpaceRat, simple because they did not fit the look I was going for.

Starting off with pre-made graphics gave me the push I needed and gave me the opportunity to jump straight into programming the game. I was still in university, but was then employed in a co-operative education placement for discreet, a division of AutoDesk. Health problems prevented me from actually working at the time, and so to judge my ability to return to work, I decided that writing a game would be a good gauge.

Since I had been working at co-operative placements for my third year, and been a programmer before I had even entered university, I was able to develop a certain affinity for object-oriented design and clean code. It was with that premise that I set down the basic classes for the game’s mechanics. While the view and model aspects are not entirely factored out, the size of the codebase made that sort of thing overkill.

The game mechanics were simple from the start; rectangular bounding boxes for collision detection and a very simple physical simulation. You could say that it’s a trivial game engine, and you’d be right. I kept it simple so that I could concentrate on getting the entire project completed. While there is definitely room for expansion, with many tasks sitting in a TODO file, the basic engine is complete.

My favourite part of the completed project has always been the star field in the background. Many games with one simply scroll a static set of uniformly-sized stars at a set speed. I was never happy with that, and so I went for stars that varied in size, colour and speed. The result was a star field that gave a sense of depth and realism that just isn’t possible with a bunch of single-pixel stars all moving at the same speed. When I rewrote the engine to support Quartz, Apple’s Mac OS X 2D drawing API, the star field was able to take on an even better look.

I had originally written the code in Mac OS 9 using Carbon-compliant APIs. At the time I was using Metrowerks CodeWarrior, as it was the IDE I was most comfortable with. While the application worked natively under Mac OS X, there was no chance of porting it to x86 without a change of IDE and modifying the API used to draw the graphics and play sound.

The first hurdle I chose to jump was the XCode transition. This was pretty painless, since I had not used any Mac OS 9 specific APIs. The application would no longer be compatible with Mac OS 9, however, but this didn’t bother me at all. I was no longer using Mac OS 9, and many people were already making the move to Mac OS X.

The next step was to modernize the graphics. I had been using QuickDraw, Apple’s venerable drawing API. This was one of the APIs Apple was quick to drop in the move to x86, as it would have been quite difficult to port to a new architecture and didn’t support the modern features Quartz does. Given my simple rendering methods, it was almost trivial. I just had to flip the coordinate system and deal with the sprites as images files rather than icon resources. It also gave me the impetus to move from an integer based physics model to a floating point model. This allowed for smoother movement and smaller velocities than I had started with. The star field improved tremendously with that change alone.

The Quartz transition was good practice for me and gave me insight into Mac OS X’s graphics model. It’s a massive improvement over QuickDraw, which had still been based on a pixel-level resolution and didn’t support anti-aliasing.

One massive sticking point which has blocked me from making the complete x86 transition is my use of Apple’s Sound Manager. It too was dropped in the x86 Carbon transition, and I never took the time to find a fully suitable replacement. In any case, my sound engine had always been sub-par. When I do get around to making the change I’ll probably add 3D sound to give a more immersive experience.

The actual game is fun to play, but after the first level the levels repeat with no sense of real progress. There’s no high-score system, no real level structure and only one type of enemy. Definitely an area that’s seriously lacking panache. I’ve been lazy here, since my original goal had been reached ages ago. There’s certainly room for improvement, but I had never created graphics for new characters beyond what I already had when I started.

While the game itself is not all that fun to play, it does provide some entertainment value. It was certainly an excellent project for learning, and might be of use to someone out there to see how to make a simple game. I have left some of the QuickDraw code in the project, for comparison to the Quartz rendering methods. One good example is SRCgImageSprite versus SRIconSprite.

I can always hope someone will find the code useful, and perhaps the game a little fun. With luck, someone else will come along and fill in the gaps. I’m making the latest code available under the BSD license, so feel free to make modifications.