From Start to Finish: Part 2

Tuesday 2nd January, 1990

I've now worked out all the robot patrol routes for the first ship. I don't have an editor for these and so I have to work them out by hand. This makes it important to get the layout right the first time, as making adjustments is really difficult. It's usually better to throw the whole layout away and start again. We have a patrol route editor for another game which nearly does what I need, but I can put patrol layouts in fairly quickly, and it cuts out having loads of little data files around to lose or mix up.

The control mode I've been using up to now has been fairly simple and, after reading the C64 code, is missing some of the niceties of its forerunner. It was a little too easy to get into transfer mode, so now you have to centre the joystick for a short time with the button down to get the transfer spark out. Fixing this has the beneficial side-effect of allowing continuous auto-fire provided the joystick is not centered for too long at a time — very useful for the machine gun-toting sentinel.

Wednesday 3rd January, 1990

A busy day, today, it is. Got the verb in there eventually. After the Influence Device blows up, I wanted the robots to continue on their patrol routes as normal, so it requires that the robots can no longer 'see' the I.D. so they won't react to it. Unfortunately, the mechanism to achieve this also handles the hidden robot removal, i.e. the non-displaying of robots obscured by walls. Thus as the I.D. disappears, all the other robots do too. This is a little untidy so I've persuaded the system to continue to display the robots that were last viewable, but not those that weren't. I didn't want previously unseen robots to suddenly appear.

Thursday 4th January, 1990

Started work on the transfer game. Steve Turner, the boss-man, says if it only took me a week to write on the C64 it should take less on 16-bit. I reckon it took nearer two weeks to design and implement on the C64 so I ought to be able to implement a superior one in about that time, given that the graphics will be a lot better. After one day its putting up a display of yellow and blue wires, but on the wrong sides of the screen.

The all-important transfer game. Controlling a small block to the side of the screen, your basic aim is to light up more of the dots in the centre than your robot enemy.

Friday 5th January, 1990

Day two on the transfer game and it's putting the colours on the correct sides and I'm teaching each of the elements of the game how to pass power along to the next element in the chain. Wires are easy, they just pass the power along, as it is, but splitters and joiners are a little more complex. The auto-pulsers are going to be animated this time, and I want to tie that in with power passing, preferably using no bytes at all.

Tuesday 9th January, 1990

Spent yesterday implementing the anti-copy protection on Rainbow Islands and some of today testing it. Back to the transfer game, day three, and I've been explaining to it how to set up the game, putting different elements together to produce a valid working arrangement. Some patterns of splitters are invalid and must be avoided. I didn't like the way the C64 version did it, and it also relied on looking at screen character codes, which are not available on the new version.

I fiddled the random element selector to force lots of splitters and joiners so that in a short time it would run through all possible combinations. It's still getting one particular arrangement wrong, putting a dead end on an already existing wire. There are some complex rules for positioning a joiner.

Wednesday 10th January, 1990

Day four, and I really need some proper graphics to get the absolute positioning right. Up to now I've been plotting some line-drawn sprites just to get the idea of what's going on.

Sat down with Art Studio and had a puggle about with some pixels and came up with a style I could live with. Drawing the various elements in that style proved a little trickier as the elements are sixteen pixels wide for storage and plotting convenience, but they'd really like to be an odd number of pixels wide. I've done the wires like fluorescent tubes which light up and stay on while power flows, and then fade down. The pulsers and auto-pulsers have 'pumps' on to generate power, and the colour switcher is a combination of both colours. I think the elements are a lot more meaningful than the coloured blocks used in the C64 version.

The central indicator bar now features a built-in timer which fills up while you choose sides, then empties out during play. This avoids the need for integrating a digital counter at the top, thus integrating the design. I never used to have time to look at the counter anyway.

Friday 12th January, 1990

Day six, and I can now select which side to play in transfer game, and the waiting pulsers are being swapped from side to side. This type of display is a pain, being double-buffered, as two copies of the screen are required and must be kept identical at this stage. The solution to this is to painstakingly update the currently hidden screen, then swap the displays over so the hidden one becomes the visible one, and then block-copy this new screen back over the hidden one. Our font plotter is so slow that this copy is quicker than doing the changes again. This is due to the colour remapping facility which is very useful but takes an age.

Monday 15th January, 1990

Day eight of the transfer game and it's time to put in the control routine for the robot-controlled opponent. The C64 version was as daft as a brush and just picked one of the lines at random to fire down, went there, and tried to fire, often firing down dead-ends and colour-switchers. This just won't do for the Amiga. What I've written is a line evaluator which examines the side it has been given prior to play. It follows each line in turn, awarding points for good elements, minus points for bad ones. If it reaches a splitter it follows both routes in turn to the centre. It seemed like an ideal opportunity to write my second-ever recursive routine.

After evaluation, a list of points per line is left. It then reads through the list to find the line with the highest point value that doesn't currently have a pulser on it. It moves to that point and fires. By juggling with the points for each element I can rig it so that lines with a colour switcher end up with negative points and will not be fired down at all. Just as a final addition, it also gives one extra point for a line leading to an enemy colour in the middle, so it favours firing down lines that can capture a colour.

What this all means is that the opponent now displays apparent intelligence and can be relied on not to make mistakes. It must be beaten by choosing sides carefully and waiting until the right moment to fire each pulser. I think I have resolved all anomalies of the C64 version, like the situation where two auto-pulsers are firing at each other. The C64 version has to let one side win; the 16-bit version allows a colour bar in the centre to be split and awards half points to each side.

Michael has managed to lose half the background character set but fortunately we had a recent backup. Our 1 meg Amiga has died again. All it does is go green.

Tuesday 16th - Wednesday 17th January, 1990

Maintenance days, fixing slightly annoying things in the game, like the fact that pirates can't fire diagonally up and left. Their bullets are emerging slightly too close to them and think they have hit something so they blow up.

The I.D. once entered a lift and emerged in the middle of deep space far below the deck, due to its energy being zero but having transferred simultaneously with being blown up. This confused the system completely.

Poking the chips about in the broken Amiga while it's on (not recommended, really) highlights the big square beastie as the one causing the trouble, Fat Angus. Its restraining harness is not enough to stop it leaping out of its holder, doing 3 back somersaults and not quite getting back into place before Andy Pandy and Teddy get back. Well, we're on to your game, Fatty.

Thursday 18th January, 1990

I've noticed that my main block of code assembles in 518k on my 1040ST with only 538k available for assembling, what with the CLI and 'make' in there. It's time to shuffle things about and move some completed routines into another file to just link-in rather than re-assemble them every time. Brief aside: Why do most programmers not use linkers?

Jason is now working on the sound effects which I have specified. There are about 70 including 16 instruments for the music. I want the sound effects in the game to be in stereo, so sounds generated on the left-hand side of the screen come out of the left-hand speaker. I will use two channels for this, put background sounds on the third channel, and miscellaneous sounds on the fourth.

It has been suggested that each robot should have its own sound when moving and get louder and quieter depending on its distance from the player, as well as being in stereo. This is an example of a great idea in theory, but not in practice. With only four channels, more than one robot on-screen will overload the sound channel with requests for sound, let alone when they all start firing. I will settle for a different sound for each weapon, sounds for robots being hit, walls being hit and the ubiquitous explosions. The 999 cyborg may well have its own volume-adjusted droning sound as it is one of a kind — ideas are seldom completely discarded.

Friday 19th January, 1990

Michael has finished decorating the first ship, and he's used many characters in ways I'd never thought of. The A.I. Mega-compressor took 95 minutes to compress the backgrounds, removing around 65% of the data. This leaves about 28k of compressed data, more than I had anticipated. Put in a 'Game On' screen to try out the colour-bar processor. I've also shortened the eyesight of one of the robots, so that his laser fires to the same length as he can see. There's no point in it spotting you, stopping, and firing at you without success. I also had to make the mines keep the doors open when dropped, otherwise the door slams on the mine and embarrasses the sprite display priority system.

Tuesday 23rd January, 1990

I'm not happy with the I.D. bouncing off robots and being swung round to face its new direction. This makes ramming things difficult and also if you fire at a robot but it keeps on going and bumps into you, it is the I.D. which immediately flips round and you can't shoot until you've rotated back. I need to separate the current moving direction from the current facing direction, which up to now has been one and the same. 1-his means adding a new field to my sprite control block and changing all of the routines which use the current moving direction field to hit both fields as required.

Friday 26th January, 1990

Inputting the new sprite-facing field, which incidentally has improved the control mode no end.

I also introduced a number of new bugs, the main one being that collisions with other robots aren't handled even as badly as before, i.e. not at all.

Due to a limited palette, I have decided not to darken the deck when all of the robots have been disposed of. Instead, a message and sound effect appear when the last robot is removed, and on entry to an empty deck. A similar message is generated when no robots remain on the whole ship, indicating that it is time to leave.

Tuesday 30th January, 1990

I had been putting in my sound assignments as absolute channel numbers, but in order to cater for all eventualities, such as the new Atari STE having its YM sound chip hooked up in stereo, I want to refer to the sound channels by name, then I only have to change one place to re-assign the sound effects to different channels. I could then get the channels deliberately mixed up so you have to face the monitor away from you and play watching in a mirror to get the sound effects right!

Michael has redrawn my rather scrawny messenger robot to make it bigger. It certainly looks better now.

Wednesday 31st January, 1990

Finished working on the 'transmission terminated' game over screen which follows the fabled 'interference' screen, which appears as you lose contact with the I.D. I did the latter using four updated characters on the 064, nice and cheap, but this time it is going to be more expensive.

Rather than start the game in one or two preset places, I want to start on any one of the transmat positions already defined. I've clustered six such points together so that'll be the most likely place to start, but there are other, more dangerous places to start. I don't want any impossible start positions but it's nice to show off the meaner robots earlier on. It's just a case of knowing when to run away.

We've changed one of the security droids into a throbbing, wobbling droid as two of the security droids looked very similar.

This is a screen beginners can expect to see a lot — the death screen! Should the enemy droids prove too much, your death will be signalled by a blaze of static, and this fearful message.

Friday 2nd February, 1990

Put in the new drinks server and disruptor-toting security droid. The drinks server seems to be carrying a couple of cups and a bowl, while the disruptor droid is a shiny black mean-looking droid if ever I saw one.

Got the interference screen done using four small sprites showing similar, wiggles, placed randomly over the screen. My coup-de-grace is a sync-line which wipes quickly down the screen while the interference drifts slowly up the screen.

Monday 5th February, 1990

Until now the robots have preset start positions and do not start to move until they are near the screen. This saves time as I'm not running more robots than necessary. The side-effect of this is that the robots are very predictable after a while. In order to alleviate this I've made some robots only pseudo-random. I can choose roughly what sort of order a robot will be, but not exactly. Others can be exactly fixed by type, so even with an unlucky setup I can guarantee some easy robots. In order to further randomise the deck, all of the robots are activated at the start and are free to roam about. The overheads of running a robot off screen are not too great as it has fast get-outs of all lengthy routines if it is not near to the player.

Tuesday 6th February, 1990

In order to encourage faster gameplay, raiders will attack the ship after a preset time, and get more and more frequent. Raiders have 'jaunting devices' which allow them to beam directly to any part of the ship. They then wander about for a while before 'jaunting' out. There will be a master countdown for each ship. No pirates will appear for about twenty minutes on the large freighter, enough time for good players to clear it. After that, pirates will begin to jaunt in, riot very often at first. After a while there will be a few of them around all of the time, more on later ships.

Complaints from the lunch-time play-testing department include the fact that the transfer game is quite tricky and often it's not possible to transfer to a lowly hoover. I obliged by supplying the player with an extra pulser to satisfy hero syndrome. This crops up a lot, to compensate for the one-against-many situation and to give the player an extra feeling of power and achievement. Hero syndrome also crops up in the collision routines: the player takes about half the damage of the other robots. Hero's syndrome is present in all games, mostly in the form of the player having a more powerful spaceship, extra weaponry and smart bombs. In Paradroid 90 the player actually BECOMES one of the enemy, and as such would have no advantage over others of the same type. A small dose of hero syndrome makes the game so much more playable and therefore enjoyable.

Wednesday 7th February, 1990

It's Michael's birthday. Hoorah! Hoorah! Hang out the flags. To celebrate, he delivered a couple of new droids for inclusion in the game. I also caught the game out, putting the newly generated robots down facing in the wrong direction. This mainly affected the non-walking sentinels used to specific points. It's no good them facing the wall.

Michael had a beer or two after work.

Thursday 8th February, 1990

It's Steve's birthday. Hoorah! Hoorah! Don't put the flags away yet. I put some more robots on the first ship to complete its population of 95 droids. Had wander around as a casual observer. I can use the monitor to switch off various features, like natural energy decay, collision damage and the robots ability to sense the player. Then it is easy to watch the robots wander about. I spotted some dragging along walls trying to reach patrol points that they shouldn't be. A quick look at the data usually locates the problem.

I've also been adjusting the pirate timer. It's not too pleasant when they start appearing, so I want it to expire only if the player is progressing quite slowly. They're actually not too much trouble to deal with: they have weak armour and not much energy, so they're easy to blow away. Serves them right, really.

Friday 9th February, 1990

Started coding the console access system where the player can log on to any console and find out more information about various aspects of the game. There's a side view of the ship, showing it inside and outside, detailing which decks still contain robots. The plan view shows a small-scale representation of the current deck, and such information as the number of robots and raiders on the deck and ship. The droid library will show large pictures of all of the droids less powerful than the player's current robot, and finally some in-game statistics.

Designed the second freighter, the USF Odyssey, over the weekend.

This useful information screen gives indication of how many robots are left and which part of the ship you are on.

Monday 12th February, 1990

All bar one of the firing droids has its own weapon type. The 999 cyborg is nearly complete and it would be nice for it to have its own type of weapon. I tried a Ghostbusters-style electric spark with very little success, but got an interesting fat smudgey (is that a word?) sweep by accident. Then I hit upon the idea of concentrating the beam into one sharp line, not unlike my original sprite-drawn flame which I threw away. The downfall of this weapon is that it draws a long line out of individual dots, each under its own control with animation running — quite a processing overhead. I eventually settled on plotting half as many dots with twice the interval between them. To make the weapon that bit more interesting, Michael drew an expanding star of light which forms at the gun of the firer before releasing its power.

Tuesday 13th February, 1990

Taken delivery of the 999 cyborg, floating around on his hover base. One mean dude he looks, too. The animation frames that would have been used for his walking are being used for the recoil of his gun. We tried a couple of variations on these frames to get it just right. There's a bit of tidying up to do about the star build-up position before he fires, but other than that, it's great! The weapon gets a double sound-effect, once for the start of its build-up, and once when it is released.

Wednesday 14th February, 1990

The cyborg hover-base is a little bit too long. When rotating in a doorway he protrudes quite a lot into the walls. Michael shaved a few pixels off his base and now it looks a lot more comfy.

Implemented the statistics information. The game has been counting up this data for some time, it's only now when I get to display this data that I'll find out whether it's really working. I'm only using 16-bit unsigned numbers so I'm hoping that they won't round. I've worked out that you'd have to fire continuously with the fastest reloading weapon for over three hours to get near to worrying the system. Anyone daft enough to try that deserves all the divide-by-zero errors they get. Actually, that particular case will be detected, for anyone worried about the integrity of my code.

Friday 16th February, 1990

Started doing the high score entry display. I've been drooling over Dominic's Anarchy high score table on the old Speccy for years, check it out if you've still got one. I've known how to do it for some time but not yet had an excuse to try it out, so here goes, but with a new variation.

Dominic's score table had colour bars passing vertically down above and below the high score entry, the upper bar casting a shadow on the letters. I've changed that slightly by having my colour bars pass down over the letters casting a shadow, then looping back under the letters going upwards, before looping back round at the top and starting again. What do you think, Dom?

Slight error with the statistics keeper as I cleared the first freighter for the first time, and I destroyed one more robot than existed on the ship to begin with. Clever! The Sentinels and other walking robots have a number of different ways of behaving when destroyed. It turned out that one particular method resulted in a Sentinel not ticking himself off as dead when he went, so he got re-incarnated next time I passed through that deck.

Another droid shown in stages of preparation, this time a humble 302. This droid is used to ferry messages to and fro and is essentially a menial.

Monday 19th February, 1990

I'm now running desperately short of memory in 512k. I remember discussing with Steve Turner two years ago that if it took us nine months to fill a 64k Commodore 64 with a game, it would take years to write a game that filled 512k. Well, here we are, two years later, seven months of game-writing on and I'm short of memory. Basically what we hadn't considered was the fact that we'd need two 32k screens, a third scrolling buffer of 40k, 68000 machine-code is about double the size code for code, and graphics are about twenty times more memory consuming. I would also venture to say that one's coding has greater depth and is considerably more complex. I'm now getting things to happen that I really want, not having to write something that vaguely does what I want only much simpler. To that end, Paradroid 90 is much more what I would have liked to have coded on the C64 five years ago.

Tuesday 20th February, 1990

We've rationalised the transfer game indicator as it was originally supposed to show not only who's winning, but by how much. Unfortunately, the light display was vaguest when the transfer game was nearly drawn, when you most needed to see who was winning. We tried a number of graphical ideas, but the small size and large requirement meant that we didn't come up with anything. We (Michael and I) have decided to use a colour spark, tying in with the spark emitted by the I.D. in transfer mode, to indicate who's winning — no spark means a draw. The top of the indicator also glows to emphasize the colour.

Wednesday 21st February, 1990

Put in a game options screen, called up from the title screen, allowing selection of one of either joystick, mouse, keyboard controls and the ship to start on. I'll allow players to start on either of the first two ships to start with, up to any of the first four once they have been reached. I would have also saved this number to disk with the high score table but for the fact that in this day and age, viruses abound and I wouldn't recommend anyone to run around with a write-enabled original game disks. Our disk filing system requires that one of our disks be used to write on so supplying a blank disk would be fruitless and wasteful. 'Ts a sad day indeed when a man can't Scribble on his disk in the privacy of his own castle.

Thursday 22nd February, 1990

Having a bit of difficulty with the robots patrolling again. Every now and again one of them smashes into a door post instead of going through it. This, it turns out, is due to slight inaccuracies in our vector homing routines. In order to make it easier for these routines, I deliberately move a robot onto the exact position of the patrol point when he gets close to it, reducing inaccuracies. This is, however, an illegal thing to do as sometimes this unofficial move can cause a collision with another robot that cannot be correctly backed out, so two robots get locked together, twisting and turning for evermore. The solution to this was that, instead of physically moving the robot to the exact spot when it got near, I just set up its next move to the exactly the distance required to get it to the exact position. Thus it makes that next move legally itself and can back it out if it causes a collision.

This doesn't actually make a lot of difference to the original problem as the inaccuracies in the system still cause the robots to thump into door posts. They're not even getting the exact horizontal and vertical cases right. What I actually have to do is round the answer I get from the angle calculator and rely on that, since all doors are vertical or horizontal anyway.

Michael has just about completed work on the first large picture for the droid library. It's the battle droid that was his first sprite for the game. A magnificent example of robotics engineering.

Droid Library Images

Before the transfer game begins, you are treated to a picture of the droid you are about to link with for supremacy. Mike Field drew each of the droids using Cyberpaint 2, and started of with a simple line drawing of each of them. Each one is hand drawn, starting as a rough sketch, and gradually being filled in and polished. After that, the picture is added to a 3D grid and extra views of the droid are added:

Series Links

Part 1 / Part 2 / Part 3