From Start to Finish: Part 1

From start to finish: The Diary of a Game

"Andrew Braybrook is the guy responsible for such Commodore 64 classics as Paradroid, Uridium and Alleykat. He was also one of the team behind Firebird's superb conversion of Rainbow Islands. His next game is more of a labour of love than a job, as he is converting Paradroid to the Amiga. In the first of a bi-monthly series, we follow the game's progress, as he begins an exclusive diary of a game."

The story so far...

I started writing 68000 in June 1988, and wrote a text font plotter and some sprite plotting routines first, as Graftgold didn't have any sprite-based code at the time. Our only other 68000 coder, Dominic Robinson, had been writing 3D vector routines and some fractal programs before progressing onto writing our Object Orientated Programming System (or O.O.P.S!) Kernel. After a brief dabble in the world of fractals myself, I had a go at writing a scrolling background system for Paradroid. This work was shelved in September 1988 when we took on the conversion of Rainbow Islands for Telecomsoft. That work was completed at the end of June 1989 when we were contracted to produce Paradroid on the ST and Amiga by Hewson. We are contracted to finish in April 1990, not before, so provided they do their publication properly taking the three months that they always tell us they always need, then don't expect to see the game on the shelves before July 1990.

I began the project by throwing away most of the earlier program as most of the coding was well out of date. We tend to write very re-usable code now, being heavily data-driven, and we have got a solid core of code for controlling sprite-based objects. I started by isolating all of this code from the Rainbow Islands-specific code and making some planned improvements, removing seldom-used bits to streamline the code, and adding some new features that I thought would be useful.

I'll be referring to my AMP system quite a lot, so I'll start by explaining what it is. AMP stands for Alien Manoeuvre Program, which was pioneered by Dominic Robinson and John Cumming some time ago before they joined us - although they claim I started it all off in Uridium way back in 1986. It's a method of controlling, originally, alien movements in shoot'em-ups. It's a sort of interpreted language, although when I used it, it was just for the Uridium ships getting movement instructions from a list. John and Dominic took it much further, controlling grouping of multiple objects, animation and collision controls, with looping constructs and suchlike. I have built a lower level version of this system, as the 68000 is the first CPU with enough muscle to be able to cope.

Anyway, an AMP is therefore a sub-program exclusive to an individual object telling it what to do, and can be used for just about anything, from running the title sequence, to moving a cursor around the screen, to making the doors open and shut, and controlling the player. I'll also be referring to sprites quite a lot, and usually I mean blitter objects rather than hardware sprites, but I can't quite bring myself to call them blobs! I'll start the diary from when I began full-time work on Paradroid, as there was a hazy area in the middle when I had to return to Amiga Rainbow Islands briefly to carry on the upgrades. Up to this point I had mostly been just doing the graphics for the game.

Monday 31st July, 1989

In order to test some of the new features in the core of the AMP system, I decided to design the title sequence. I first designed the logo. I had intended to split the title 'Paradroid 90' into separate letters. Paradroid is a great word for compacting, as three letters occur twice, thus saving space. I wanted each letter to arrive in turn, each casting a shadow onto the background. The logo turned out to be quite large and involves multiple colour changes on each line.

I also redrew the old font from the 64 version, as I thought it would be nice for it to make a re-appearance. This didn't take very long, although separately saving each letter as a brush soon got tedious - we must write a font editor some time! I use my own format for fonts, I wouldn't use Amiga format fonts if you paid me. The only editor I have for them only works with KickStart 1.1 anyway.

Tuesday 1st August, 1989

Continuing the title sequence, I drew some different coloured hexagons as a backdrop to the logo and credits and wrote the routines to tessellate them on the screen. I also wanted the credits to fade in, letter by letter, so I had to get the plot routines to talk to the text interpreter. The letters fade through four or five colours, but look a little flat on the screen in one colour. My solution to this was to run a colour fade through the text, which makes the letters look more interesting, but ruins the fade effect somewhat. A solution is not forthcoming at this time. Never mind; plan B: do some graphics.

After much tinkering, here it is - the Paradroid 90 logo in all its glory!

Wednesday 2nd August, 1989

The logo is split into letters and my system can cope with them arriving one at a time, but moving them all at once causes major headaches for the system; there's a lot of plotting going on. Plotting eleven 32-pixel-wide sprites onto a non-blank background, with shadows, as well as running colour changes is too much. I can only print four lines of text with colour-bars and music running before the frame-rate drops and things really start juddering.

Thursday 3rd August, 1989

If I split the logo into 32-pixel-wide chunks instead of letters, I can get the logo into seven sprites instead of eleven, and by using an enormous frig to fiddle the amount of background restored to a minimum, I can run it faster, but I'm still not happy with the overall look.

I split the logo into 32-pixel-wide chunks as my plot routines all need either 16 or 32-pixel-wide data. This simplifies clipping off the side of the screen and is adequate for most things. Larger sprites are displayed by ganging-up images next to each other. I want the logo to move as a whole and am prepared to drop the letter-by-letter arrival.

Friday 4th August, 1989

Nailing down the colour palette is always difficult, but does need to be done early as all the graphics must be drawn with respect to the palette. I use DPaint II to sketch things out and experiment, but I use Art Studio to actually create and store my sprites. I write my code on a 1040ST with the Tempus editor and assemble with the HiSoft assembler, and link the object together with the Metacompco linker. I assemble most of my graphics into the code itself, so ultimately I need them on a GEM disk. We have various means of getting graphics to and from the Amiga, mainly involving a lot of time and pain, so I try to avoid it as much as possible. I have something of a love/hate relationship with the Amiga: I love what it does, but I hate the way it does it!

Early decks shots. The picture on the left is an experiment using DPaint II, whilst the second set of pictures on the right are the finalised graphics - for now, anyway!

Back to the palette. I've decided on sixteen basic colours, split into four sets: lone miscellaneous set of four colours, and three sets of four related colours, ie. the same basic colour but four different brightnesses. This gives me four greys, four yellow/oranges and four floating colours for the different ships. The miscellaneous colours are black, a colour for space (probably very dark blue) and variable colours for the alert status display.

The observant among you may have noticed that sixteen colours is less than the Amiga is capable of, but is as many as is practical. Running 32-colour graphics costs 25% more space for the screens, 20% more space for the graphics and an effective 16% loss in CPU and blitter time due to extra screen DMA. I would ideally like this game to run at 50 frames a second, but this is not possible as the amount of screen plotting that I require, even running at 25 frames is going to be pushing it. No, the hardware sprites aren't going to help because I need the robots and bullets to interact more with the background, going under door lintels and lift controllers. I'm much more concerned about producing a good, playable game than putting something on screen that's more amazing than the best demos you have seen, but has no lasting interest. Trust me, I know what I'm doing!

Monday 7th - Friday 11th August, 1989

I spent this week preparing the graphics for the doors, energisers, alert blocks and various combinations of walls. I also converted the old AMP routines for running these objects to the new system and tested them. I will be using a map editor to create the decks for the ships, but this has not yet been written. John will convert the Rainbow Islands mapper to support a larger character set, over 1000 characters instead of 256, 16 decks plus a scratchpad instead of 4 rounds, and any sized deck instead of 256 X 40 fixed. Until this is done, I will use Rainbow Islands round filled with my new graphics - it'll be good enough to sort out the scrolling system.

Monday 14th - Friday 18th August, 1989

Started the week by designing the graphics for the influence device which the player controls. Being on screen all of the time, this should be graphically superb, as well as being small so that the controlled robot underneath can be seen and identified. I want to have very few gauges and words on the control panel, mainly because the actual screen playing area is so large, and so the player's graphics should show the different modes that the influence device can be in. Anyway, what does an influence device look like? Answers on a postcard to...

The week's proceedings were rudely interrupted by Rainbow Islands being officially tested at Commodore's Hall of Fame, where they have one of every version of the Amiga ever available. There were quite a few. The upshot of it is that some of the Gary chips do not allow blitter-friendly mode, which is quite a blow, as I used that extensively. We therefore had to think of a new strategy for blitting objects. Fortunately (or unfortunately), we know two people with such Amigas so we can test the new version without going all the way to Commodore. This is all relevant to Paradroid, because we will be using many of the plot routines from Rainbow. Had to fix my 1040ST which was refusing to read disks. Took it apart, poked it about with a big stick, put it together again, and, voila, it works again. Marvellous thing, technology.

Extra features are being added to the Amiga version. Seen here is a shuttle naturally enough - a deck's shuttle bay: "a nice set piece to have."

Tuesday 22nd August, 1989

At last, I'm back to Paradroid. Today, I'm redesigning the 'cell system' that we invented for Rainbow. The background will be broken up into characters, just like the C64 version, which makes collision detection robots disappear if they can't be seen by the player. The cell system allows us to put the characters on top of existing ones, on or off screen, singly or in sets. These cells can be piled on top of each other and were used to do the Rainbows themselves. Now I wish to use them to do the doors and other destructible blocks on the decks. I need to be able to plot or unplot one of the many cells, and hide them. The cell system could also be used for laser fire. What the cell system allows me to do is put objects on the screen that don't move against the background, and leave them there until such time that they are removed. It cuts down tremendously on the plotting overheads. Plotting objects is one of the biggest spenders of time in the Amiga, the blitter is fast but at the expense of stopping the CPU except when the blitter pauses for breath.

Thursday 24th August, 1989

It's time to implement that cell system; there's no putting it off. It actually turned out to be a lot easier than I was expecting. It just looks messy when you have to link up a doubly-linked list in one place and three singly-linked lists in another. The system is pretty flexible though, as I can get from any part of the system to any other quickly. Whether I can use the system to its full potential depends on how many things I can think up for it to do.

Friday 25th August, 1989

Put the doors in, and got them working. The doorway is effectively open, but the cells are plastered on top to show a closed door, When approached, the cells go invisible and a sprite takes over to show the door opening, and remains there until no robots are near. It then shuts, the sprite disappears, the cells reappear, and the door appears to be closed. The beneficial side-effect of all this is that I can leave a door lintel there when the door is open and the robots will go beneath it. I shall also use the cell system to do shadows for other static objects suspended above the deck, like the energisers.

Graftgold themselves. From left to right: Gary Foreham (programmer on other projects), Jason Page (sound and graphics), Steve Turner (the boss!), Dominic Robinson (O.O.P.S kernel), David O'Connor (programmer on other projects). In front, is Andrew himself (diarist extraordinaire and self-proclaimed mega programmer!).

Tuesday 29th August, 1989

Made up two RS-232 leads today, which we use for the download of the game from ST to Amiga. We are one short anyway, and we also need another lead to get two PCs talking to each other. I did serious damage to my fingers when I stood on the soldering iron lead and the iron slipped through my fingers, melting quite a lot of my skin. "Gosh, that hurts!", I said (Yeah, I bet! - Ed), and got to some cold water fast. I expect it'll heal eventually.

Wednesday 30th August, 1989

Drew the energiser, the lift head and an alert block, and implemented them; shadows courtesy of the cell plotter. I want all these destructible so that players spending all their time on the energiser will find it shot from over them. Sitting under the energiser lights on the ground below to spin up to speed and energy is supplied.

Thursday 31st August, 1989

Changed the design of the influence device and started work on the control mode. It's a nasty one this because all the robots can be controlled will have different characteristics, as well as graphics. Also, their weapons will be different, if they carry weapons at all, and the one control mode has to cope with all this. Got the lone Influence Device skating around, which has its own shadow casting on the floor below. Rather than a black shadow or stippled blob, the shadow darkens the colours it covers.

Friday 1st September, 1989

Spent the day adjusting the speed and acceleration variables for the player and adding in some weapons to fire. Unlike the C64 version, which featured linear speeds, I am now using a polar system. The main difference is in the diagonals which, in a polar system, a short cut is to apply full X and Y speed in diagonals resulting in a faster diagonal speed.

Monday 4th September, 1989

John has been working on the deck mapper, which is written using STOS with some 68000 routines for graphics support and... (sound the trumpets!) the A.I Mega Compressor. This marvellous piece of software takes a set of decks and looks for similar patterns in them, and substitutes 'macro codes'. It does up to 8 passes of the maps, either horizontally or vertically looking for repeated patterns and finally removes all the spaces resulting usually in the removal of 75% of all the data.

Designed by David O'Connor and written by myself, it's probably one of the most complex routines I've ever written, not least of all because debugging it was really tricky as it needed to run under STOS. We also had to write the decompressor to get the original data back, so if it went wrong we couldn't be sure whether the compressor or the decompressor (or both) were wrong. The bad news is that it also needs to be changed to allow 16 decks of varying sizes instead of 4. This didn't turn out to be too tricky, and it worked second time, so now I can't use the deck I created in Rainbow Islands format. So it's time to design a working deck with all the combinations of elements for thorough checking.

Up to now I've had a full 25-line screen scrolling with an overlaid score and energy bar. With the aid of a border colour change I can see that this is taking a very large chunk of the available time without even running any robots around. I have therefore decided to cut the screen down to 24 lines and put the score and energy on the blank line above the main screen. I can then relegate the score update process to a lower priority task in our multi-tasking system so that it only gets updates when there is time available. The only disadvantage of this method is that, if there is a lot going on, the score might not update for a few frames. Not a heavy price to pay when so much time is reclaimed and available for the main tasks, scrolling and plotting sprites. Maybe later I will use the hardware sprites for an overlaid score, but they aren't very wide and there are heavy colour restrictions. If it looks prettier in more colours, I'll leave it where it is.

Every time your Influence device changes levels, an exterior map of the space station is shown. At present, only two levels are finished, but when the game is released you will be able to move freely between them all.

Wednesday 6th - Friday 8th September, 1989

Adjusting the screen size means changing the sprite clipping window size, ie, the area inside the map in which sprites may be plotted. This also applies to my colour-bar system to stop colour changes occurring above or below this window. Also, the O.O.P.S Kernel needs to know what size of screen I require and where any full palette changes are to occur. This is the tricky bit as the very mention of object-orientated programming makes me forget everything I know about coding.

Spent the rest of the week putting in the sprite/background collision detection to stop the robots and the player driving through the walls. This time it'll be idiot-proof. First of all, find me an idiot.

Monday 11th - Friday 15th September, 1989

Put in the first robot and a weapon for it to fire, a flame-thrower, which must also collide with and stop at walls. One of the problems about using real robot images rather than markers is that they need to be displayed in all directions, with the lighting right for all of them, so I can't reflect them. This is going to be very expensive on memory. I have settled on 8 different images for the robots at 45 degree angles. Some robots will have independently swivelling heads, which being smaller can have 16 images at 22 degree angles for really smooth rotating.

Monday 18th - Friday 22nd September, 1989

Drew an opening and closing hexagonal hatch to put on the floor as a sort of airlock. It sits there open until approached, when it closes to allow robots to walk on it. It operates in a similar way to the doors, but in reverse, so it didn't take too long to implement.

The thought of drawing up to 24 different robots in 8 different directions doesn't fill me with enthusiasm. John had this idea of designing the robots on a 3D CAD system and then we can display them from any angle. Also, this allows us to use large images of the robots for the console look-up system. John built one and did a mock-up screen showing the robot from 4 angles and it looked very impressive, so this looks like the way to do it. I dug up the C64 version and picked 21 of the original robots as a starting point for John to work with.

Using handy Graftgold's useful map construction kit, decks for Paradroid are literally pieced together like a jigsaw.

Tuesday 26th - Friday 29th September, 1989

All of the robots in the C64 version were moving round predefined patrol routes. I wanted most of the new ones to do that as it makes them out to be more intelligent than just blundering about crashing into things. I put in a homing system so that the robots select their next target point and head for it. Unfortunately, inaccuracies in the homing system are causing them to keep banging into door posts as the doors are quite a tight fit. This needs a rethink. The rest of the week is disrupted by the PC Show.

Monday 2nd October, 1989

My first robot is now patrolling round quite happily, selecting new routes at the patrol points and generally enjoying life.

Tuesday 3rd - Wednesday 4th October, 1989

Now it's time to put a second deck in and see if I can get between them using the lifts. As with the C64 version, if you get in the lift and just exit on the same deck, then all the robots and bullets will be in exactly the same place, otherwise it could be used as a cheat to reset the robots. On a fresh deck the robots are effectively unpacked and restarted as it keeps a full track of only the current deck. Of course, destroyed robots never reappear, but the others are reset to their original starting positions.

I experimented on DPaint II at home that night with the new palette and came up with a new style for the walls. Most of the other graphics need only be remapped on to the new palette. The doors need changing completely to fit in and are one of the most difficult to draw as the door shadow has to work properly and the sprites have to match the background and the cell system. This time I actually got some work done and got it saved. For some reason, the version of DPaint that I have got is very unreliable and crashes at the most inopportune moments, often when I am running short of memory. Sometimes it boots up with a screen corruption and it's easy to spot when it's going to crash; other times it waits until I have created something worth saving before it goes.

The Influence Device takes a trundle through an unfinished deck. Notice that so far the floor graphics haven't been added.

Thursday 5th - Friday 6th October, 1989

Redrew all of the graphics to date. Only the logo remains the same, as it is drawn in the two colours reserved for in-flight colour changes. In my rush to put all the pieces together, the only thing I forgot to do was actually change the colours in the palette set-up, so all the new graphics came out in the old colours. Fixed that: now it all looks much better. I've coded the routine to check whether the robot can be seen from the player, what I call 'hidden robot removal' which again uses one of Dominic's routine - this time an adaptation of a line-drawing algorithm. That also works a treat but eats more time.

A second deck has now been drawn to test out the lifts. This routine will drive an animated display, but for now I just want it to set up a new deck and work out my position on that deck. Got the scale a bit muddled up as one routine was working in characters, and the other in pixels, which caused some rapid scrolling off the bottom of the deck into oblivion.

To be continued...

Series Links

Part 1 / Part 2 / Part 3