A Review Of My Own Programming Skills – 30 Years On
Thirty years ago, I wrote a game for the Sinclair ZX Spectrum and had the BASIC code published in Sinclair User magazine. It was November 1983 and I was 15 years old. I received a £10 cheque for its publication, and for me back then, it was like winning The Football Pools. I was a self-taught programmer and my game was based on Atari’s Missile Command; a very popular arcade game of that era.
Atari – Missile Command
You have to remember that many of the computer peripherals and storage media that we take for granted today were not around then. There were no hard drives, usb sticks or floppy disks to store computer information on. There was no internet. The ZX Spectrum stored it’s programs on cassette tapes; the ones originally designed to store audio.
The ZX Spectrum stored its programs on cassette tapes such as these
So back then, software was distributed on tape, or by typing other people’s code into your computer, line-by-line, from magazines such as Sinclair User; then saving that code to tape for use at another time.
The first page of my code, Pg. 77 (click for larger version)
The second page of my code, Pg.78 (click for larger version)
And I still pity anyone who sat at their computer, typing this amount of code in from the magazine. People who chose this method to obtain programs from others were effectively typing blind, for they had no idea how good the resultant code would be until it had all been typed in.
And clearly, the propensity to make a typing error increases with the more code there is too. Correcting typing errors in ill-copied code must have been a really tiresome exercise for these people. Yet they persevered. And probably learned a little about BASIC programming at the same time.
Remarkably, I found my old game on the internet recently. Someone had indeed managed to type in my code – and get it right. It is available to play within your browser if you have java installed. Give it a try! Just follow these simple steps. And don’t worry, you don’t have to type in the code!
Step 1
Click this link to open up the ZX Spectrum emulator at worldofspectrum.org
Step 2
Tick “I accept the risk and want to run this app.” Then click Run
Step 3
The grey window illustrates what you would have seen when the program was loaded successfully via tape
Click the grey area with your mouse. Then type R on your keyboard and the command “Run” will be shown at the bottom of the grey window followed with a flashing “L”
Press ENTER to Run the program
Step 4
Play the game. You have to wait until a screen appears that says “Press a key to play, before the timer expires”
The controls are explained before hand.
Q – UP
Z- DOWN
I- LEFT
P-RIGHT
1, 2 & 3- Move the cross-hair to the three different zones.
Review
The Good – Cross-Hair Movement
Atari’s Missile Command featured a track-ball in it’s console to enable rapid movement of the cross-hair. Essentially, it was an upside-down mouse and mice were certainly not available for the ZX Spectrum. In fact, they were un-heard of. So the first problem I had to overcome was how to make the cross-hair in my game move quickly around the screen with just the keys on the keyboard.
I resolved this issue by introducing three zones on the screen; essentially dividing the vertical axis of the game-play into equal thirds. Pressing the appropriate number on the keyboard would ‘jump’ the cross hair into that zone. That solved the problem to some degree and made the game playable.
The three zones, shown on the left hand side of the screen
The Good – Attraction Screens
The first third of my code is dedicated to attraction screens. These attraction screens were a common feature on arcade machines at that time. Their sole purpose was to entice you to play the game by showcasing game-play; demonstrating how the controls worked and what the objectives of the game were. High score tables were often displayed too; encouraging competition in the hope that players would keep coming back.
I made sure that I incorporated all those gimmicks in this game. And I made them look as pretty as a I could.
My first screen depicting lasers firing at the name of the game. My software logo above it
The controls
And the High Score Table with the option to start a new game
I used a bubble-sort algorithm to sort the scores in descending order. This was one of the first pieces of coding that I taught myself and I still find the bubble-sort algorithm useful today.
The Good – Game Speed
In terms of hardware, the ZX Spectrum CPU was 2.8 times faster than the CPU in the Atari arcade cabinets on which Missile Command was run.
ZX Spectrum - Z80 CPU running at 3.5MHz Atari - M6502 running at 1.25MHz
But, my game is written in BASIC; where every line of code has to be translated in-turn, to an instruction that the computer can understand, before it is able to carry it out. This process is known as compiling and it utilizes a lot of CPU time. Even if parts of BASIC code are repeated in a program, those lines of code have to be compiled again.
Atari’s code for Missile Command would have been pre-compiled and be in a language that the CPU would understand without the need for translation. And it’s this that made arcade machines fly.
So I was at a disadvantage; programming in a language that would result in slower game-play from the off. I needed to write my code with care if I wanted to get any sort of speed from my game. And I think I achieved just that. This game plays pretty quickly for a BASIC program running on a ZX Spectrum. It didn’t get any better than this folks!
Later in life, I started programming games on the BBC microcomputer. I used to enjoy programming that machine with BASIC code. It had a really good command that could disable the screen from refreshing until your code had finished updating the positions of all objects and completing proximity detection routines. This meant it was possible to maintain smooth flowing animation as the screen would only be refreshed when all updates had been completed. Essentially, everything that needed to move would appear to move at the same time – all in the same frame.
Animation on the ZX Spectrum was a whole other story though. Without the ability to control screen refreshing and the slower CPU, it was possible to see each object’s position change, one after the other, in a somewhat jerky fashion. Another reason to make the code run as slick as possible. And looking back at it, I’ve made it as simple as possible with no CPU hogging instructions.
In fact, I’ve kept it so simple to the point where there is no ‘Fire’ button. This detracts a lot from the Atari version. Missile Command had three ‘Fire’ buttons; one for each of the cities at the bottom of the screen. Lasers would be fired from the corresponding cities towards the cross-hair position. And multiple shots could be fired, resulting in explosions all over the screen.
To maintain a decent game-play speed in my version, a collision of the cross-hair with a meteor is sufficient to fire all three lasers at the target.
The Bad – Proximity Detection
For the purpose of this review, I’ve played my game a number of times. And I think that the only bug in the code surrounds proximity detection. Sometimes, the lasers don’t fire when the cross hair is touching a meteor. Moving the cross-hair one position to the left or right of it triggers the salvo of laser fire. It’s due to a rounding error in my code that converts the position of any meteor to the x, y coordinate system of the cross-hair. Line 335:-
335 IF 21-INT ((b(i)/8)+.5)=x AND INT ((a(i)/8)+.5)=y THEN LET I(i)=0: GO SUB 8100
The cross-hair is positioned with the PRINT AT x, y statement The meteors are displayed with the PLOT a, b and DRAW commands
Both coordinate systems are different, hence the requirement for conversion.
The Bad – Code Structure
The are some good points with respect to my code’s structure. I’ve been able to follow my code and understand the logic behind it all. Even after all these years. There are lots of REM statements (short for remarks) to enable anyone to identify the chunks of code that perform specific tasks.
My only gripe is that I must have been GO SUB mad.
The GO SUB statement was a convenient way of performing the same tasks repeatedly without duplicating the exact-same code; a precursor of today’s Function call.
Line 35 of my code:
35 GO SUB 1000
is unnecessary. That procedure is only run once. Essentially there is one line of code that creates the graphics for the game, like the laser turret and cross-hair. It’s all done at line 1010
1000 REM U.D.G.s 1010 RESTORE 1000: FOR j=1 TO 15: READ c$: FOR i=0 TO 7: READ b: POKE USR c$+i, b: Next i: NEXT j: RETURN
Line 35 could have simply contained the code in line 1010 without the need of a sub routine.
The related DATA statements could have been placed at the very end of the code.
Final Thoughts
Ok. So my attempt at creating Missile Command for the ZX Spectrum wasn’t as good as Atari’s creation. It lacked fluid animation and decent frame-rates. And a lot of the original’s features simply couldn’t exist in my program as they would have slowed the whole game down.
Yet, it was a good game. And for a program written in BASIC, it was pretty impressive. After all, there must have been something about it for it to be published in the first place.
I look back on those early years of programming with fondness: owning my own computer and being able to program it to make it do almost anything I wanted. It was almost a necessity back then – having to create your own software. People became creators and pioneers because of it; bettering themselves by learning the skills of BASIC programming.
Now, we just consume.
Reviews & Guides 