Defender - Diary of a Game

(Written 27/03/2007)

This game really starts with Pong. For me it does, anyway. Pretty much the first thing I code for a new platform is always Pong. It’s a simple enough game to be able to put together in no time at all, it provides the opportunity to work with input and output, and, unlike “Hello World”, you get something useful at the end. So, my first DS project was Pong. I’ve written this loads of times before. So far, I’ve written Pong in AMOS, Blitz Basic, RM Basic, QBasic, Spectrum Basic, Modula-2, Flash, bas2c for the Cybiko, C for the Cybiko, C for OSX (SDL), C for the GP32, C for the GBA and Java. Those are the ones I remember, anyway. Here’s a quick list of the things I discovered whilst writing it:

  • Initialising a screen for text output screws up any other kind of output on that screen (took me a while to figure out that one);
  • The latest version of PALib has a bug in its sound code, so C++ projects won’t compile unless the offending functions are modified and cast to (u32*);
  • PALib is much easier to work with than libnds;
  • I like working with objects.

I even got to bung in the OctaMED module I wrote 12 years ago for the Blitz Basic version.


I took away two main things from writing PongDS. Firstly, I’m going to use PALib. Libnds is great, but PALib offers so much more. If I knew more C code I’d probably be willing to give libnds more of a chance, but I really just want to get a few games running. The real low-level stuff can come later.

Secondly, I’m going to use C++. This is tricky because I haven’t got an awful lot of C/C++ experience, and I’ve never really finished any object-orientated games. My Java games don’t have any presentation (intro sequences, options screens, etc), and I switched from Flash to Java just before ActionScript 2 appeared. Before then, real object-orientation in Flash for games was impossible because it was just too damned slow. Any games I make will therefore have to be structured in a way I’ve never really attempted before in a language I’m not too familiar with. I could code in straight C, which would halve the amount of new things to learn, but I’ve been working on object-orientated business apps for so long now that the thought of going back to a procedural language when there’s a perfectly good OO language around really doesn’t appeal.

Choosing a project to work on was more difficult than I expected. I’ve got a few ideas for things I’d like to do with the XNA framework, but until Parallels supports 3D acceleration that’s out of the question - I’ve just switched over to a MacBook and refuse to go back to a Windows box. Parallels is fine, but no dual booting and definitely no Windows-specific hardware, other than the Thinkpad I lug around for work and my file server. No interesting game ideas leapt out at me for the DS until I hit upon the idea of Defender. I love Defender. Specifically, I love Mark Sibly’s version of Defender for the Amiga, which must be one of the first games I ever had the sourcecode to and tried to tinker with. It seems such a perfect fit to the DS and looking around on the net, it seems that the DS is starved of a decent Defender clone. The official version is crap, and the only homebrew version is a half-finished port of Defendguin. No thanks. Some initial thoughts about the port:


  • Up: Up
  • Down: Down
  • Left: Left
  • Right: Right
  • B: Fire
  • A: Autofire
  • L: Smartbomb
  • R: Hyperspace
  • Start: Pause
  • Select: Reset (whilst paused)

That breaks with the arcade tradition, but then I hate the arcade controls. The controls above are chosen based on the assumption that, had the original coder had access to a joystick, he’d have used that instead of the dozen buttons on the arcade machine.


I’m going to copy Mark Sibly’s version shamelessly. I’m going to steal his sound effects. They’re stolen from the arcade anyway, so he can’t complain. I’m also going to pinch his graphics and pilfer his sourcecode. Essentially, I’m going to port it to the DS from Amiga Blitz, with a few DS-specific enhancements.

Screen Layout

The main action will be on the top screen. I’ll have a score, hi-score and life counter at the top of the screen, and the main playfield below. The second screen will show the map, which will fill about 2/3-¾ of the screen, and a “Defender” logo below it. I might pinch the marquee from the arcade for that.


A few options to make things easier for those of us who are hopeless at Defender:

  • Number of lives (3-5)
  • SFX test?
  • Number of smartbombs (3-5)
  • Number of continues?


I haven’t written any four-track MOD files in years, and I was never particularly good at it when I did write them. I might fire up the Amiga and give it a go, though. Music will be limited to the title/options screens if there is any.

High Scores

It occurred to me that web-based high-scores would be great. It then occurred to me that if this game is open-source (it’ll be released under the GPL when it’s done, same as everything else I do), the authentication method will be visible to everyone. There will be no security on the high-scores, so people can cheat without making any effort. Scratch that idea, then. High-scores will have to be saved to the local non-volatile RAM (or whatever the DS uses as long-term storage).

Game Structure

  • Start off with a logo sequence
  • Next to options screens
  • Then game

Corporate logos make homebrew look much more professional. Hate the damn things in commercial games because you can’t skip them, so skipping them has to be possible in this game.

Today I’ve been working on the logo sequence. I’ve got an old friend with considerably more artistic talent than me working on a new logo for Simian Zombie, and he seems to have loads of good ideas. They match my own - if only I didn’t have stupid fingers I like to think I’d have come up with something similar.

To this end, I’ve written a handy slideshow class, that consists of three parts. First of all, I’ve got a bitmap class that takes 8-bit or 16-bit image data converted by PAGfx and stores it in an easy-to-use fashion - loading a bitmap into a screen is now just a question of calling “bitmap.draw()‘. It abstracts away the 8-bit/16-bit difference, too - one class does both completely transparently. Secondly, I’ve got a SlideshowImage class, which stores a bitmap and the length of time it should be displayed. Finally, I’ve got the slideshow class itself, which stores a sequence of images and cycles through them one by one until the user presses something or it hits the end of the sequence. It’ll then exit or loop, depending on how it’s been set up.

In half a dozen lines of code, I can now have two totally different slideshows running on the DS’ screens, showing a mix of 8-bit and 16-bit images. I knew there was a reason to go for C++ over C. One observation - in C++, when trying to load an 8-bit palette into a screen, you have to cast it as (void*) or you’ll get an error. Looks like another bug in PALib.