Codetapper's Amiga Site

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

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

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 anywa,. 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.

Another of the many on-board rebellious droids, shown here as you prepare to enter the transfer game

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?

Thursday 8th March

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.

Friday 9th March

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

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

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

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

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 cant 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

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.

A humble ST, complete with Rainbird's trusty OCP Art Studio is used to develop the sprites

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.

Thursday 22nd - Friday 23rd March

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.

Monday 26th March

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

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.

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

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.

Monday 2nd April

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.

Thursday 5th - Friday 6th April

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

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 bitter 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

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?

Wednesday 11th April

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

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

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.

Wednesday 18th April

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

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 corning into the Amiga?

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

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 a couple of years make in terms of game design, isn't it?

Post your comment

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments

You may enjoy these articles...

From Start to Finish: Part 3

Comedy

If you look inside many Amiga games, secret messages have been hidden by the programmers. Richard Aplin was the king of hiding messages in the startup-sequence file, and his Line of Fire and Final Fight startup-sequences have become legendary! The Sensible Software team were also prolific at hiding messages in their games.

From Start to Finish: Part 3

Interviews

A collection of technical interviews with Amiga programmers that worked on commercial software in the glory days of the Amiga (late 1980s to early 1990s!)

From Start to Finish: Part 3

Maptapper

The Ultimate Amiga Graphics, Level and Map Ripper!

From Start to Finish: Part 3

Random Rants

A random assortment of rants relating to the Amiga!

From Start to Finish: Part 3

Sprite Tricks

An explanation of how many famous Amiga games utilised sprites in weird and interesting ways