Learning to Run
This is the second part of the Learning Curve trilogy. The first part, Learning to Walk, explored how I became a game programmer in the 1980s.
It is 1992.
Beyond small projects, I couldn’t finish a damn thing. I had folders crammed full of design sketches for games and numerous disks littered with crude prototypes. I was apt to spend my time on title screens and structure, leaving the actual game bit to be “filled in later”, always chasing the high of creation without actually creating something. I believed I was a genius of unearthly codemagick power yet had nothing to show for it except for the work I did with my father: Blitz, Runaround, Escape and also Runaround II (published in New Atari User #53, Dec/Jan 1991). I needed to prove that I had the discipline to see one of my own ideas through.
But that wasn’t all I needed to prove. If you wanted to get decent performance out of an 8-bit computer you had to do the business in assembly language. I’d written plenty of machine language snippets and done my share of hacking commercial games to make them easier so I believed I could write one of those grandiose machine language games if I wanted to. But development in assembly language is like having to marshal individual grains of sand into a sandcastle. The scale of the task was enough to subdue any hubris. I needed to prove I could write a game in machine language.
I threw one more goal onto this project of projects. This game I was going to make? I was going to sell it like a proper developer. If I pulled this off, I would never doubt my Atari skills again.
Now assembly language programming is so low-level that you spend most of your time writing routines to copy memory, print text, plot graphics and watch paint dry. Sometimes, you’re even coding up basic arithmetic. In the new game, I needed a routine to convert X and Y co-ordinates to a corresponding location in the computer’s graphics memory. The calculation I needed was SCREEN + 2X + 80Y. In a high-level language, this is effortless. In machine language, it is 36 instructions.
I knew I had keep the project relatively unambitious because I’d never finish it otherwise. But what kind of project? Thank God for Germany.
At this time, German puzzle games were sweeping through the European Atari community, introducing us to concepts like Sokoban and Tetris for the first time. A Sokoban-alike seemed to be unambitious enough although I still baulked at churning out a pure Sokoban clone, sprucing up the concept with a few extra dimensions: pits, boulders, teleporters, bombs and a time limit.
Which means it’s time to confess the ickle teeny weeny problem in my grand plan. I was no longer living at home because in September 1991 I had moved to Reading University to study mathematics. The family Atari computer was 144 miles away. As I was on a student grant with no extra funds coming in, buying a second-hand Atari computer or even a television was beyond my budget. It seemed unlikely that I’d ever get the project moving if I only worked on the game during the holidays at home but, with no computer, what could I do? The solution was obvious.
Paper and pencil!
The whole program – save for non-essentials like the title screen – was written on paper while I was at university. I didn’t have any reference manuals with me either, so relied entirely on memory when it came to processor opcodes and hardware substructures. Yes, without doubt it is crazy to scribble out reams of pages of assembly language without the ability to test a single subroutine but fortunately it was obsession, rather than discipline, which saw me through. Adopting paper as my principal coding environment meant I could let rip instead of reining in the urge to create. I will not lie. This was awesome fun.
On 15 August 1992, I began typing the program into the MAC/65 Assembler. It still blows my mind that once the whole program had been typed up, testing revealed there were less than ten bugs in the entire game code. We’re talking about level plotting routines, the sound algorithm, input control, timer countdown, score management… practically everything. The only parts that required work were aesthetic concerns like the design of the title screen, graphics and audio.
No other large project I’ve worked on has been so trouble-free which is likely down to the unusual approach to development. I couldn’t squander my limited facetime with the computer so studied and revised the graphite version of the code countless times before the holidays. Also, writing in pencil is a slower and more contemplative form of coding than composing directly on computer. (One negative repercussion is that it convinced me of the sanctity of the Waterfall Method of project management for far too many years.)
The game was working but I was missing one essential ingredient.
I had been sketching some puzzle designs but each one needed to be refined and proved to be solvable. Some of the designs, like the penultimate room, were full of moving parts – and working through such a level using only the power of imagination was not going to cut it. I needed to test them in the game.
After spending some time with my parents, I then drifted down to my girlfriend’s family home in Devon. Although we were supposed to be enjoying some quiet time together, the obsession was still there like a shoulder devil tempting me to keep working. I wanted to test puzzles. That’s all I wanted to do. Test puzzles. My girlfriend’s family didn’t have an Atari computer but they did have an old ZX Spectrum. With no Atari computer, would could I do?
Any developer worth their salt would obviously have rewritten the entire game from scratch in ZX BASIC even though they had never programmed on a ZX Spectrum before.
Don’t look at me like that. Do you not understand the word “obsession”?
With a ZX BASIC reference manual as my guide, I redeveloped the game on the Spectrum in a few days. It was easier than I expected so, well, it was only natural to add custom graphics, pontificate on the colours and design appropriate sounds. Soon enough I was able to use the Spectrum version to test the puzzle designs. I translated each design into numbers and… had to apologise to my girlfriend for staying up to 4AM each night working on the program.
Question time, folks. How did I transfer the finalised designs from the Spectrum to the Atari?
Congratulations, paper and pencil wins out again! The levels were stored in a numeric format but I worried I’d make a mistake and screw up nuanced layouts that had been tested thoroughly by my girlfriend and her father. To limit the possibility of error, we also drew every level on paper to accompany the encoded version. I say “we” here but it was actually my girlfriend who copied down every level design.
On 4 January 1993, the game project called The Citadel (Joel Goodwin, 1993) was complete. It was sent to Neil Ottaway on 23 February, who was running a small UK outfit called Tiger Developments.
Ottaway took the game on and priced it as a minor release along with his own Tarkus and the Orbs of Doom (Tiger Developments, 1993). See below the first advert for the game in New Atari User #63, Aug/Sept 1993.
Writing a commercial machine language game for an Atari 8-bit computer in 1993 is too late for any accolades. Even though Ottaway also distributed games in Poland through a company called ASF, The Citadel only sold 26 copies in total.
Remuneration was pitiful as prices had already fallen to dampen piracy (you could have global distribution without even being aware of it) and encourage the few Atari consumers left to open their wallets. However, lest we forget, money wasn’t the point of the project.
It was a rite of passage to prove I was capable of making a solid game alone. All that was left was to tell my father that I had pulled off this epic task against crazy odds and I had earned the right to be called a grown-up. He could be proud of this.
But he already knew I could do it. What I hadn’t expected was a slightly awkward moment where I struggled to find the right words to explain why I had excluded him. It was yet another example of youthful narcissism, ignorant that this moment was my father’s rite of passage, to have his son proudly tell him he was no longer needed. Despite my awkwardness, this wasn’t some moment of soap opera drama: everyone was happy for me. And the mega-fortune I was obviously not going to rake in.
In review, there wasn’t much about the game I wanted to change. Except… well, it was workmanlike and didn’t need to be written in assembly language. After all, the ZX BASIC prototype I created in a few days was eminently playable. The Citadel was a functional game but not a sexy one. The game had been a personal journey, not an experiment in game design.
The urge to create something more attractive turned into a sequel project a couple of years later. Now into my PhD, I was blessed with a more chunky postgrad student grant. Money was no longer as tight so I picked up a second-hand Atari 130XE enabling me to program at will.
Guess what? As I didn’t write the entire program on paper in advance, the development was frustrating and painful, each test revealing more and more bugs. This is despite reusing the plumbing of The Citadel. The result was a game called Orson (Joel Goodwin, 1995) which was a Sokoban clone. Orson looked and felt cooler.
Orson and its level editor were published as a bonus disk program in New Atari User, which I had been deluging with articles. Although I liked Orson I couldn’t get that excited about it – it was just Sokoban. It was more sexy but lacked the depth of The Citadel.
The failure of Orson encouraged me to think about Citadel II, which would try to gouge out a more significant mark on the Atari gaming sphere. It was going to be The Citadel but more creative and varied – no longer just a collection of blocks and boulders. There would be secret areas, lasers and mirrors, growing biomass, themed zones (I was into Sonic the Hedgehog at the time) and an antagonist to defeat. Program design, including level ideas, hit paper in a big way.
But Citadel II would never see the light of day.
- Do you want to play The Citadel? Play the brand new version in PuzzleScript or go check out the Running The Citadel page if you want the original.
- Some kind soul has added The Citadel to MobyGames, complete with screenshots and even a “Did You Know?” sidepanel.
- There is a Let’s Play on The Citadel without commentary.
- I have also been added as a developer to Atarimania.
- My self-penned bio on the Page 6/New Atari User website.
Here it is at long last, a “developer commentary” of The Citadel and Orson.
Download my FREE eBook on the collapse of indie game prices an accessible and comprehensive explanation of what has happened to the market.
Sign up for the monthly Electron Dance Newsletter and follow on Twitter!
9 thoughts on “Learning to Run”
Citadel looks like a game I’d have enjoyed. Let’s see: right, down, right x 3, up, right x 6 and down into the exit?
I was ok with writing the engine for a puzzle game but actually designing the puzzles always threw me – I wonder if I’d do better at the required meta-thinking now.
It’s a bit odd to find out that all the time the chap I’ve been chatting about games with was a bleeping savant. The Paul Morphy of game programming or something, what what you did with that pencil being the equivalent of a eight-game simultaneous blindfold chess match.
Phlebas, that is indeed the correct solution to Room 01! I don’t recall exactly how I came up with the puzzle designs. Something along the lines of having a “theme” – e.g. partitioning the level into rooms – and then iterating on that. I’m going to try to make a bonus video this week which is a developer commentary on The Citadel and that may shed more light on the thinking in each level.
Matt, hah, I don’t know. I used to think pretty highly of myself – I was the top of everything kind of child – but as I went through university I began to understand what I didn’t understand and became a lot more humble. Indeed, this is the core of the final part which will be posted in January. I don’t feel all that smart these days because I seem to rely on Google and Intellisense more than common sense but you did tell me something valuable – that it was worth writing this up. I’d had the idea from long ago to write up the story of The Citadel but felt too self-indulgent; it’s the story of a kid who thought he was smart but procrastinated away whatever smarts he had.
What the “pencil story” really tells you is how much time I had spent on the Atari. Which was lots. I knew the computer like the back of my hand. I can still cite a lot of Atari technical details from memory right now. Yet I can never remember in the C language for loop whether the test condition is the second or third parameter.
Really liking this series – probably because I loved coding as a teenager and also procrastinated my way though dozens of projects. For some reason I always wanted to make a FPS, but never got beyond basic movement. What flummoxes me now is that for about four years I made the same crude prototype, over and over, convinced that this time it would be a science-fiction masterpiece or whatever, but never getting beyond sliding collisions with walls.
You’re right about the pencil story. If I were in that situation, I’d have to write it in pseudocode and hope for the best. Everything else – actionscript, unity, even my childhood language Darkbasic – is contingent on autocomplete and stackoverflow now.
James, this procrastination habit has dogged me into later life. I keep looking back to the Time Before Children and thinking WHERE DID ALL THAT LOVELY TIME GO. Making the time to write Electron Dance is the hardest job, but somehow I’m “accomplishing” more now that I did before I had children. There’s more procrastination in the final part.
I really do feel like Google/Stack Overflow and the modern IDE have conspired to make me stupid. I never learn anything any more especially as these modern enhancements make it far easier to work in programming languages you know nothing about. Language wars haven’t helped either. I don’t know what I should “back”. I followed VB.NET for awhile which turned out to be the shunned member of the .NET family.
It’s not always without its burdens to be a talented child! Direction is needed, certainly. And humility.
Also, wow, just a couple of years before Super Mario 64, and you were not only playing but even making games for the Atari!? A different world from mine (born 87). 🙂 During that time I played the Super Nintendo and Playstation…
Right, there you go, I’ve added the video at last.
@Ava: And the downside to a console upbrinhing is no programming! I’m not sure how much humility I really have, truth be told.
This stuff is gold! I know you’re not an arrogant guy, but there’s just no way of telling that paper & pencil story without you sounding like a hero. Any code of mine I test gets at least 20 bug warnings even if my computer’s not on.
I know, David. When I was writing it, I was thinking is there any way I can write this without sounding arrogant! I don’t know the actual number of bugs but it was somewhere below ten (part of me thinks it was 3 or 4, but that’s not guaranteed). However, it’s quite unique; most of my work is crawling with bugs and that includes the corporate software development I do today.
Comments are closed.