Ever wondered how top-selling arcade games are written? KEVIN EDWARDS reveals all

AFTER completing the BBC and Electron versions of the shoot-'em-up game Galaforce, Superior Software asked me if I was interested in writing a car racing game for the Electron.

This was intended to be a follow up to Superior's best seller, Overdrive, a car racing game which, while being exciting, didn't have any corners.

I was very interested and began work in Autumn 1986. The big question was whether the Electron was fast enough to cope with realistically moving corners. First, I decided that the game would have to be written in Mode 5. There are several, reasons for this. First, the ULA slows down the Electron in screen modes 0 to 3 and since speed is crucial I had to forget the ideally suited Mode 2.

Second, the game was to have excellent graphics and several tracks so the screen had to take up as little memory as possible. This left a choice of Mode 4 or 5.

As colour was essential I had no alternative but to choose Mode 5.

The next problem was to find a way of updating and moving the road as fast and smoothly as possible. At first a dual screen technique was considered. This requires two copies of the screen.

While one image is shown the other - in a separate block of memory - is updated. Once the off-screen image is completed it is used as the show screen. This is achieved by altering the screen memory start register in the ULA.

Swapping between two screen images greatly reduces flicker, but having two copies of the screen gobbles up too much memory. Back to the drawing board.

In the end I decided to update just the edge of the kerbing instead of redrawing all the road and grass area. This must, of course, be done on both sides of the road.

A modified line draw routine is used to create the curved road edge. When a corner is entered or exited the new kerb edge is calculated so that the program can change just the parts that have moved.

So if a section of kerb moves one pixel right the routine can intelligently redraw the kerb one pixel to the right. This is much quicker that redrawing the entire row which has moved.

Only the left kerb edge need be calculated as the right edge is always a constant distance away. A look-up table containing the offset is added to the left edge to give the required right edge position.

Also, when you go round a corner the mountains in the distance must be scrolled in the correct direction. This is done by redrawing them two pixels to the left or right of their last position.

The impression of speed is achieved by altering the colour of the kerb edge, which is made up of red and white blocks. The faster you go the faster the kerb blocks change between red and white.

In Overdrive, which was written in Mode 2, a simple palette switching technique using VDU 19 was used to animate the kerbing. For this, two (or more) colours must be set aside for the kerbing. If they are not, any graphics using the kerb colours would also flash.

As the game is in Mode 5 - a four colour mode dedicating two colours to the kerb would leave only two colours for the other graphics - one of which must be black for the background.

Palette switching would be too restricting so the kerbing is redrawn in its new colour each time it moves. This takes a long time as both sides of the road must be altered at the same time to make the movement smooth and accurate.

A lot of work went into the kerb and road updating routine to make it as fast as possible.

By the time this had been completed Superior and I decided that a motorcycle racing game would be more original than the rather dated car theme. Also, the game now became an Electron and BBC project.

The next problem was how to move bikes up and down the road area. Sounds easy, but it requires a bit of extra thought since the other bikes must go round corners, lean in the correct way and avoid going too close to the kerb.

In addition they must try not to crash into the back of the bike in front, move realistically relative to your speed, decrease and increase in size depending on their direction and generally behave in a sensible way.

To save processor time a slightly modified fast sprite routine from my last Electron game, Galaforce was used to draw them.

As Crazee Rider is intended to be a fun game rather than a simulation another feature was needed to emphasise the point.

Partly due to the very generous collision detection routine I had written it was decided that it would be fun if you could knock other riders out of the way by ramming into the side of them, which would gain bonus points.

After a little tinkering this was added and it became just as much fun hitting other bikes out of the way as racing round the tracks.

This was soon followed by a graphical hit count tally system in the top right corner of the screen. Symbols corresponding to 1, 5, 10 and 50 hits show how many bikes have been knocked out of the way.

A countdown bonus system at the end of each circuit awards 200 points for each hit.

At this stage many other things had been added such as the score, handle bar control panel area and a new six by eight pixel character font which allows more characters to be displayed on each row.

The handlebars at the bottom of the screen now contained indicators showing the rider's current speed and position in the race.

The very early versions of Crazee Rider displayed road signs at the top of the screen describing what was ahead on the road, such as a left or right corner or straight.

This was a nice feature, but it was hard to visualise what the circuit looked like so a miniature map idea, similar to that used in Superior's BBC Grand Prix Construction set, was used instead.

This shows the whole of the circuit including markers for the start/finish line and the rider's position. Thus at a glance you can see how much further there is to go and what is ahead. Appropriate action can be taken to avoid taking corners too fast for instance.

By now the game plan had been finalised. You compete against 59 other riders in races at several famous circuits. You must try to finish the race in one of the first six positions - easier said than done. If you do, you compete in the next race at a new circuit.

As you progress through the tracks the skill of the other riders improves and eventually a single mistake can cost you the race.

Next, the race start sequence was given a face lift. Start lights, other riders beside the player and revving noises were added to give the game more realism.

Several tunes and sound effects were included such as engine, skidding, crashing and bumping noises.

Then came the high score table which has six entries and allows names up to 16 characters in length.

The useful colour changing system, first used in the Electron version of Galaforce, was another essential item to be added.

Both First Byte and Plus 1 joystick control options had to be allowed in addition to keyboard. Pause and sound on/off functions were added next, along with game jump facilities allowing players to start on any circuit previously reached.

Considering the amount of animation going on during a race the Electron manages to run Crazee Rider at an amazing speed. Anyone who says it is too slow to write games on is very wrong indeed.

I hope I've proved many people wrong who thought fast racing games with corners couldn't be achieved on an Electron.

This article appeared in the September 1987 edition of the "Electron User", published by Database Publications.

Scanned in by