Memory Lane: The Citadel

Sunday, 16 March 2003

Assembly language, cool. That's what I thought about programming on home computers in the 1980s. If you didn't use a low-level language, you weren't going to get good performance out of your machine. I had an Atari XE at that time and I was determine to master the machine language (ML) of its 6502 processor. I had actually learnt ML but, apart from tiny pieces of code, I had been unsuccessful time and time again creating something of any size.

[The Citadel Title Screen]

The problem with ML is that it is very, very basic. You can add and subtract integers, manipulate bits and access memory. Arithmetic and memory I could understand. Multi-byte arithmetic using the 6502 carry flag wasn't too difficult either. If you wanted to do anything interesting, however, you had to understand how the processor actually processes and also how the hardware functioned. It took a very long time before I could grasp all of the subtleties involved. I had reached the point where I felt that I understood everything about the machine - the POKEY timers, the myriad of interrupts, bank switching, the function of all of the processor registers, everything. But for me, just for me, I had to prove that I could do something with it. Time for a project.

The Project

As ML is complex all by itself, it made sense to choose a concept that was not complicated to build. Around 1991, puzzle-oriented games had become very popular, and I decided I was going to make one of those games where you push some blocks around and try to get out. I didn't want it too boringly basic, so a few extra dimesnions were thrown in for variety: pits, boulders, teleporters, bombs and a time limit. I wanted to generate simple code; to this day, it is still one of my primary goals in every software project.

[Citadel game objects]

"The Citadel", as it became named, was developed in an unconventional manner. The problem was that I was in university when I came up with the idea, and I only saw my Atari computer during the holiday periods. So the whole program - save for non-essential extras like the title screen - was written on paper while I was at university. It may seem like madness, to write reams and reams of ML on paper without the ability to try it out, but it was the only option I had. I wasn't about to spend meagre student grant resources on my own Atari system (no, that would come later).

The absolutely shocking thing is that, once I had typed the whole program in to the MAC/65 Assembler, there were less than ten bugs in the whole code. It still surprises me to this day. No other program I have ever written has been so trouble-free. The only parts of the program which proved to be problematic were those non-essential items that weren't written in advance. After this, I lost all doubt as to the importance of pre-planning and design. All that work on paper had been written carefully, slowly, with a solid design about the workings of the program formulated beforehand. The graphics handling, the sound handling, the movement algorithms - all devised in theory before I started writing the code.

There were some items that were impossible to design effectively on paper. Sound effects can only be done by experimenting on the computer itself. Further, although graphics can be drafted on paper, you never know how well they will turn out until you see them on the screen; changes are inevitable Perhaps the most problematic item, though, were the puzzles.

[Room 20]

It just wasn't easy to come up with puzzles on paper. You can come up with ideas but you have to play them to know how hard they really seem and - far more importantly - whether they can be solved or not! So, sad geek that I am, I quickly implemented a version of the program in Basic on my girlfriend's ZX Spectrum when I was stayed with her family during the summer. I had no experience of the ZX Spectrum before, but that didn't stop me. Within a few days, I had a working version of the game and was able to test out and refine puzzle designs before I went near the Atari again. This was great for me, but not so great for my girlfriend.

As I said the code was not very complicated and there is not much to comment on. I squandered the Atari's sprites (known as player-missile graphics) by using them to represent lives at the base of the screen and also the static-looking representation of the player on the screen. The sound routine was basic, although served its purpose. No smart special effects. The only smart thing about it was the block-pushing algorithm. Instead of redrawing, say, six blocks when they are pushed, you only have erase/draw the blocks at the end to simulate movement. Still, if the block motion had been smooth instead of using a jerky character-based approach, then I wouldn't have been able to get away with that.


I achieved what I set out to do. The program worked well, and I had proved to myself that I could actually program in ML. Even though I had missed the boat with respect to commercial games on the Atari computer, I still got it published through Neil Ottaway's Tiger Developments in the UK. It didn't sell many copies, but then again piracy was rampant on the 8-bit Atari. You could have global distribution without even being aware of it. However, that wasn't the point. I could write a game in ML! That's all I had wanted to know. Even with the evil that is room 25, there wasn't much about the game I wanted to change. Except for...

[The Evil of Room 25]

After completing the Citadel, I became unhappy with what I perceived as the lack of sexiness. The goal had been to create something that worked, to prove my ML knowledge could be put to use; it was not supposed to be an experiment in game design. I love cool games and I pay a lot of attention to the design and structure of games, more so now than I did back then. Let me be frank: The Citadel was a functional game but not a sexy one.

This drive to create something more attractive turned into a sort of sequal project called Orson. I will talk about it in a separate article, but it was lacking some key qualities that the Citadel had possessed. The failures of Orson encouraged me to think again about a third project, Citadel II, which would try to make a more significant mark on the Atari gaming sphere. It was going to be the Citadel again, but be far more creative and varied - no longer just a collection of blocks and boulders. Program design, including many level designs, hit paper in a big way.

It was too late, though. People were moving on from the Atari and I had to as well. I chose to focus on mathematics and leave the world of coding on the Atari computer behind. Citadel II was discontinued before a single line of code was written.

See It For Yourself

You can still run the Citadel using an Atari emulator. Download your favourite emulator and run the Citadel disk image. If you need any help running it or playing it, please have a look at the instructions I've thrown together..

Updated 20 August 2004. The Citadel was remade for PC by Byxon Games in 2004.