From Start to Finish: Part 3

Some ten months after Andrew Braybrook and the Graftgold team started work on Amiga Paradroid '90, the game is now finally nearing completion. Most of the decks are in, as are the rogue droids, and all that remains is to tie up the loose ends along with a few other problems. So, in this the last part of Andrew's Diary of a Game, read on as he gradually starts to reach the light at the end of the very long tunnel.

Tuesday 6th March, 1990

I have just completed the robot enquiry system and input all the text about the robots. All the texts are drawn from a dictionary of about 200 words so some of the sentences are a little bit odd, having to re-use certain words rather than put in new ones. The dictionary in the game is currently limited to 256 words overall, a number which I thought would be plenty when I first wrote the text printer. I've started populating the 3rd ship with robots and other sundry items like crates and cups of coffee. This involves looking through each deck layout in turn, deciding where the robots should start, and where they can all move.

Wednesday 7th March, 1990

One of the new large decks that I've just done has seven lifts on it, one more than anticipated in the system. A quick fiddle of the way the lifts work alleviates this so that lifts not near the screen get removed from the system and re-allocated when they are nearby. I thought it was already doing that anyway, it is with most other objects. Still, you live and learn. I've also completed the side view of the third ship - huge, it is, with over 130 resident robots.

Thursday 8th March, 1990

The third ship was getting rather large; it takes nearly three hours of computer time to compress the decks, to around 20% of their original size. In order to save a bit of memory, I removed a small deck from the layouts, which ultimately saved about 2K.

Meantime, Michael has been drawing full-screen pictures of some more robots. These are also compressed, by one of Dominic's wee routines this time. After bolting the compressed pictures together, the game loads them all in at once and caches them in slow memory. Each one is then decompressed as required onto the screen. This all worked nearly magnificently except that the black bits on the picture came out bright green. Two errors caused that; I set up the wrong palette and Michael didn't remap the black colour. One all, replay next Wednesday evening, seven-thirty kick off.

Made up the first ever 512K master for testing to see how much memory is actually spare. and to see if it still works. Took home to test.

Another of the many on-board rebellious droids, shown here as you prepare to enter the transfer game. I wonder why he needs the... er, well developed accomplice?

Friday 9th March, 1990

A black day indeed. There I was, thinking all was going really well; played a whole ship all the way through, got the end of ship bonuses, it started to load in the second ship... and ground to a halt. I then realised that the load ship screen was using some allocated object blocks and had thus fragmented my dynamic memory. I start off with a vast field of memory and begin to carve it up, always taking the big chunks out first. Trouble was I took a couple of little chunks out, then gave the big lump back and asked for a bigger lump. Although I had enough free memory available, it wasn't all in one place. Result: system panic error. AmigaDos has the same sort of hassle. Quite often DPaint II complains on a 512K Amiga for similar reasons, as would any software using this design philosophy. It means that you can run more software at once if they all share the resources, but if they squeeze too hard, something will break.

Monday 12th March, 1990

Further testing of the 512K version has revealed a major error in the game. It spontaneously combusts sometimes when I enter a lift. The whole game just stops. This I find odd, as I haven't played with the lift routine for some time, and nine times out of ten if a bug appears, it is to be found in the most recently altered code.

I've decided to ditch the 'deck cleared' message. It uses the font plotter and slows the game down as it appears and is totally superfluous now that the deck lights darken when the last robot is destroyed. I'll keep the 'ship cleared' message, it doesn't happen as often so it doesn't matter if things slow down a little then.

Tuesday 13th March, 1990

Still looking for the bug. It's a really good one: the interrupts all get stitched so the machine is totally dead. Just to continue showing progress I'm continuing to populate another ship, and worrying a lot. It doesn't normally take this long to sort out a bug. I rarely lose a night's sleep these days by having an unsolved bug to think about.

Patrolling one of the detailed competed decks, the wandering Influence Device is attacked by a tri-laser-wielding droid - you have two choices: destroy him with your weaponry or merge with him for a bout of transference.

Wednesday 14th March, 1990

Jason was playtesting the game when it decided to leave the loading ship music running during the game. Since I go to great lengths to switch this off I was quite surprised. Yet another problem to think about.

The main breakthrough with 'The Bug' came just before lunch time. I was tracing the game through and it went into the sound reset routine, which basically tells the sound manager to be quiet and then waits for its interrupt server to do so. This never happened. Of course, looking through the sound manager code it was obvious that it could not fail to complete its task.

Following rule 15 paragraph B of the bug-fixers guide 'If the code can't fail, it ain't executing it at all' it transpired that not only had the sound manager been shut down, but all interrupts had stopped. Now, I didn't get where I am today by shutting down the interrupts on the 68000, especially as I run my code in user mode most of the time so it's tricky anyway, then it can't be my fault.

This bug only occurs on a 512K machine, not on a 1 Megabyte beast so it's either a corruption or maybe a memory allocation fault. On a whim I decided to trace the memory allocator, especially its strategy when unable to pass the required memory back, i.e. failure on a 512K machine. Suddenly it dawned on me, the memory allocator switches off interrupts while it is playing with doubly-linked lists, and doesn't restart them when it fails. That's one to Dominic and his Kernel.

Spent the rest of the week on cloud 9 having fixed a bug in the Kernel and generally pottering about with ship layouts.

Monday 19th - Wednesday 21st March, 1990

Still quietly decorating and populating ships. The stages in the life of a new freighter are as follows:

1. design freighter on paper showing walls, lifts and general ideas for decks.
2. give design to John Lilley to set up on the mapper program.
3. give shell of the ship to Michael to put floor designs and detailed console layouts on ship, the really creative bit.
4. assign doors, lifts, energisers, consoles etc, to map.
5. put in side view of decks and shafts.
6. test integrity of lift shafts and positioning of doors etc.
7. draw patrol routes, with co-ordinates on original paper map.
8. input patrol routes and assign robots to patrol points.
9. assign sundry objects. e g. crates and alert blocks to decks.
10. thoroughly test layouts.

This whole process takes the best part of two man weeks altogether.

Thursday 22nd - Friday 23rd March, 1990

Found a long-lost bug in the tank turret AMP (Alien Manoeuvre Program, remember them?) that meant that when fired upon it fired three shots back and then stopped. I'd got so used to it doing this that I had forgotten to look for that one. As soon as I fixed it and the tanks fired back continuously the lunch-time testing team of Gary and Jason have complained non-stop for its re-instatement. Now I would never put a bug back into a program. but... they're getting violent, so I'll re-program the tanks to fire three shots back and then stop. OK lads, put the monkey wrench away, now.

I have a version of the pirate/raiders that are resident, for locking away in the brig and so forth. On meeting them in enclosed corridors I was surprised to be quite successful against them. Then I discovered why. They were not defined up as an enemy, so their bullets did not inherit that enemyness, and they passed right through me - not a scratch. Better fix that one. I'm not going to tell Gary and Jason though.

A humble ST, complete with Rainbird's trusty OCP Art Studio is used to develop the sprites, but they are then ported over to the Amiga where extra colours from the machine's better palette are used.

Monday 26th March, 1990

Every now and then a couple of wandering robots will seemingly grab hold of each other and dance, ad infinitum. The only way to stop them is to fire at them. I never intended that to happen at all. They have a random waiting period and are then supposed to both turn round and walk away. Fortunately, my inter-robot collision routine passes back some important information, like what direction a robot was hit from. By looking at that, a robot can determine whether it is already moving away from the collision and thus do nothing. Only the robot or robots that caused the collision will turn round. Since doing that, not one pair of robots has been seen doing the waltz at all.

Thursday 29th March - Friday 30th March, 1990

Having got all the plot routines working and clearly defined, that is, I am unlikely to want to change them, I must now persuade the blitter to do the work instead of the 68000. I hate working out minterms, both the methods in the hardware reference manual strike me as being artificial. What I really want to know is: how does the blitter deal with minterms?

Anyway, the shadow plot routine was a doddle, so much so that the first minterm plotted everything back to front, so I had black squares running about with robot-shaped holes cut through them, bleah!

The particle plotter is best done with straight code, you still need to plot about five or six raster lines per blit to make up the overhead of setting up the blitter in the first place. After that it is much faster. I have one plot routine that I haven't used yet, so its about time to lose that one. Slash. tear, rip.

Monday 2nd April, 1990

Spent the day at the European Trade Fair. Ocean kindly picked up our award for Rainbow Islands being voted the Best Conversion. I'm sure they'll send it along to us soon. Many thanks to all who voted for it.

Most of the decks are now complete, and all that remains is to pick out the few troublesome bugs that ruin the game's continuity and polish.

Thursday 5th - Friday 6th April, 1990

In order to test Paradroid on a stand-alone basis, free of the parallel link from the ST where all the source code is kept and where remote debugging is done from, it is necessary to put the game and all loaded data files onto a bootable Amiga disk. This is not quite as simple as it might seem as both of our Amigas are deficient in some way. Let me elaborate: Our 1 Meg Amiga is required for debugging as it keeps extra symbols in memory for the debugger, the game is too big for me to develop on a half Meg machine. However. the RS232 download software won't work with the 1 Meg Amiga, so to make up a disk I have to switch to the other Amiga.

The half Meg Amiga won't boot from any disk with the parallel cable connected, so I have to unplug the lead, boot up, download the disk-maker software, and finally unplug the lead again to persuade the RS232 to work. Marvellous, this technology stuff.

Monday 9th April, 1990

Well, Paradroid '90 is now essentially booting itself off the disk and running in some sort of fashion. Unfortunately, one of the ship data files has mysteriously been cut short so one of the ships won't work, the screen just appears to be a jumbled-up mess. All of the screen drivers that use the blitter are fine, now that I've logically inverted the mask on all of the graphics. The blitter is a strange beast, for the first and last word masks to work correctly, the data mask has to be the opposite way round from the way the 68000 would like it.

Tuesday 10th April, 1990

Remade the boot disk and this time all the files are complete. Must have been cosmic interference from the Graftgold geo-stationary satellite, which for convenience is placed on the end of a big stick attached to the roof. I've been pondering over what to do with the hardware sprites for some time. There aren't really enough of them to handle the multitude of moving objects in the game, most of which go under and over bits of background scenery anyway. I have plumped for pressing them into action as an overlaid score and energy bar. Using them in three-colour mode in conjunction with a few copper instructions to change the colours every line should be enough to get the desired effect. How difficult can it be?

Any relevant info on the deck you are about to enter is called up between stages, and details the classes of robots you are likely to encounter.

Wednesday 11th April, 1990

Well, I can't find the sprites. I've got all eight of them positioned on the screen, not necessarily quite where the hardware reference manual would have me put them, but they're supposed to be on the visible screen; sprite DMA is switched on and the DMA pointers are reset. Where are they?

I hate looking for things in Dominic's Kernel. He said I'd enjoy trying to get sprites working. Now I've found out why. He's switching off the sprite DMA every frame. No wonder I can't see them. Gary nobbled the Kernel so now my sprites will appear. But no, they're still not there.

Thursday 12th April, 1990

Back on with the miners' helmets and we're off into the dark dank depths of the Kernel once more. What's this? A weeny little copper fragment that switches the sprites into hide-behind-the-playfields mode. I'm pretty suspicious of the palette handling too. I think it's changing the sprites to all black every frame. I just can't prove it. More sticking-plaster and the Kernel is back on its knees again, and yes, my sprites are here at last.

Steve, the boss, has been playing the game for the first time in ages and had a small gripe regarding being able to spot the Influence Device quickly when it beams in. Some sort of attention-drawing display is required. I knocked up some AMPs to cause a whole heap of particles to zoom in towards the player during the beam-in sequence. It looked quite pretty but I calculated that it was running at least three hundred particles to do it, more than a half Meg machine would allow, and the game grinds to a halt while it's doing it. I'll have to calm it down a bit.

Tuesday 17th April, 1990

Visit to Hewson to show them the latest version of the game and tell them how wonderful it all is. Meantime, Michael has been beavering away on the giant pictures of the droids. More than half of them are done now, all the difficult ones, so he says, just the seven-stone weakling ones to go.

Just for reference purposes, on the left is a screenshot from Andrew's 64 version of Paradroid, notice how different the new, improved, biologically-cleaner Paradroid '90 looks - it's amazing the difference in terms of game design, isn't it?

Wednesday 18th April, 1990

Having got the game nearly finished, I can now work out what sound effects I want. I know what sort of overall effect I am going for, and I have to scour the game looking for events that will produce a sound. I am directing most in-game sound effects to the left or right-hand speaker, depending on where on screen the effect is coming from, which takes two channels. One of the remaining channels is for background effects, like the deck burbling noises and the alert klaxon, and the other channel is for miscellaneous other effects of importance. Counting up, over sixty effects are required, plus thirty-two instruments for the music, which should keep Jason busy for a while.

An addendum to the saga of the Amigas not talking to the parallel and serial ports properly is that neither sound sampler that we have will work with either of our Amigas. I'm beginning to suspect that we've broken something in there.

Thursday 19th April, 1990

Jason and Gary each took a sampler home to try on their own Amigas. Both of them worked. Jason has therefore decided to obtain the required samples at home. One that always causes trouble is the white noise used for explosions. In Rainbow Islands we actually sampled a C64 doing white noise! Our friends at Rainbow Arts, Julian and Boris, tell us that they sampled an atomic bomb going off, but we haven't got one of those.

We have an algorithmic sound effects generator, which means that we don't have to just sample everything raw, we can make effects from simple samples just like the C64s SID chip uses simple waveforms. This gives us great flexibility with the sounds and doesn't burn up lots of valuable chip memory with huge samples. Of course we can just play a raw sample if required and we will be doing so for the main Paradroid 90 theme.

Jason wants me to switch the low pass filter off, so that the sound effects are clearer. I didn't believe him that to switch that off you also switch off the power light on the Amiga. What berk thought of wiring those together? Why isn't the power light actually monitoring the power coming into the Amiga? Isn't it rather dangerous that you actually have no real indication that power is gushing through the machine? Come the glorious day, brothers, I know one hardware designer who'll be first up against the wall.

Friday 20th April, 1990

A niggling thought about widening the door overlay has finally got to me. There are two droids which cause minor embarrassment to my system and I when they rotate in a doorway. Their arms or other protuberances (ooo-er) overlap the door edges and show through. By widening the door lintel overlay I can cover their, and my, embarrassment.

Jason has almost finished the sound effects, and so I can switch out the dummy sound routine and run the new one, still with the Rainbow Islands tunes in for the moment. Now that's what I call odd.

This is a 729 Armoured Tank - one of the deadliest around. Ask yourself this: 'do you feel lucky, punk?' One of the more powerful rogue droids shown both in detail and in action - well worth beating in the transfer game, if only for the weaponry.

Monday 23rd April, 1990

We can prioritise each sound effect so that the important ones get heard. It's always a problem trying to balance the sound, what with over sixty effects fighting over four channels, not all at the same time, fortunately, but you get the idea. All the weapons firing are fairly low, and the explosion effects are higher so they interrupt the former. More important effects are normally short so they don't just hog the channel.

The big meanie cyborg has its own drone sound at four different volumes so that as it approaches the player it gets louder. It's also stereo panned so you can hear what side of the deck it's on.

Tuesday 24th April, 1990

David spotted a minor discrepancy in the system that no one else had. He wanted to pummel a sentinel on emerging from a lift so he stood facing in the required direction, operated the lift, and was most disgruntled to discover that his facing direction had been randomised. I hadn't bothered to preserve it as I didn't think it would matter. It has taken eight months to spot it so I nearly got away with it. Still, it's in now. Advanced players can now use this facility, and in fact I may position droids so that on later ships it is necessary to do so.

Wednesday 25th April, 1990

Put on the rubber gloves again and dived into the Kernel to fix its sample switching. Now that we have longer samples for the instruments such as drums, we had noticed that the samples were not always switching between instruments and some sound effects. The audio DMA must be switched off for a short, fairly undefined, time to shut it down properly. The hardware reference guide was rather vague about how long exactly. I don't think it really knows. It actually depends on the playback rate, so I've shut the channel down for one call to the sound manager, or one hundredth of a second. Using a software delay loop could be disastrous if someone has a 68030 turbo-nutter CPU.

The robots mill about outside Andrew's set piece - the impressive retro-firing shuttle.

Thursday 26th April, 1990

Jason's still complaining about the sound routine. He'd quite like a total rewrite but he'll settle for his bass drum being a bit louder. Our software enveloping is a little slow to start so the sample is already fading out before the envelope has even got to full attack. Being a full bass drum sample it's entitled to supply its own attack envelope in the sample so the player now wallops the volume up to full from the word go, rather like Jason and Michael's portable CD players.

Friday 27th April, 1990

Jason has had the tunes on SoundTracker for some time, so it didn't take him long to convert them to our format and try them out. So far he has done one three-voice tune for the high score entry, leaving one for the letter entered sound effect, and four four-voice tunes for intermediary stages in the game. Due to a chronic shortage of chip memory I have decided to load in the samples for Jason's super-atmospheric tune separately. On a boring old 512K machine this would mean switching out the currently loaded ship, a real pain every time you return to the titles sequence, so we have an alternate tune for that. For those people with 1 Meg or more, the samples will be loaded once off and kept. Also, all the ships can be in memory at once without reloading. Such are the perks available to those people with upgraded machines.

I've started writing out the game instructions, always difficult when you already know the game inside out, as it difficult to gauge what people need to know just to get started. I also want to convey the complexity of what is going on in the game, not because you need to know it, but because if you do know it then it makes the game more understandable. Once in possession of all the facts you can plan winning strategies against the game.

Monday 30th April, 1990

Officially the last day. Michael has delivered the last of the large robot pictures, and Jason is happy with the music. In fact, I have one ship left to populate with robots, which is about two days work if it all goes smoothly. The game is working well, there is just about enough free memory in the machine to cope, despite a last minute scare that the disk system needs about 24K before it'll consider doing anything useful.

The instructions are just about finished and we'll be producing some support material in the form of ship layouts and pictures, and I still have to produce a shop demo version, which may also be suitable for a demo cover disk. I hope that someone somewhere will enjoy the game. I've tried to put the emphasis on gameplay in the true tradition of great games but still do graphic and sonic justice to the Amiga.

Thanks very much to Andrew Braybrook and all the guys at Graftgold and Hewson for their help in making this diary. Look out for a review of the game, hopefully, next month.

Series Links

Part 1 / Part 2 / Part 3