Uridium 2 Part 3

Only three months into its creation, and Andrew Braybrook's Amiga sequel to his all-time C64 classic is already shaping up with the potential to be the greatest 16-bit shoot-'em-up of the decade. And the only place you'll bear the FULL story behind its creation is here, in Andrew's own words in our exclusive serialisation of his on-going development diary. The control mode is working, some of the aliens are in and bullets are flying everywhere - but there's still a long, long way to go...

Part Three - July/August, 1992

Tuesday July 21st, 1992

Following on from the minor crisis reported last time that all of the plot routines were slightly flawed in a couple of obscure situations, I've been rewriting them all. Not from scratch, you understand - that would take ages - just the meaty hits that talk to the blitter. The required end result is a set of routines that are more efficient to run and amend to create new plot routines. That process took all morning. At the moment the game consists of a mishmash of all the different types of enemy that we've created so far. This is so that I can test them all by blowing up the ones I don't want to test. It also means that I can see if all the general routines are working. The objective in the early days of a game is to create a library of routines that are all thoroughly tested so that when complex stuff goes in later I know that any problems that occur cannot be blamed on what I call the 'core'. Once all the core routines are working and they're as efficient as I can make them I can just forget about them, knowing that they're reliable. That's the theory anyway.New additions to the actual game are a slightly changed palette to give more different colour combinations and a mine-laying meanie that drifts about, attempting to deposit static mines around the screen. The meanie tries to stay on-screen by selecting a new direction that sends it right across the screen. With a fast scrolling game it's important that the bad guys get seen, rather than lagging off-screen behind the action, vainly trying to keep up with the player's movement. This one's only a simple meanie but it's beatable, which gives the player a reward in out-sussing it. There's no point in having mega-intelligent meanies with the latest missiles and cloaking devices such that they are totally invincible. I might as well just print 'Game Over' on the screen in the first two seconds and not bother to write any more.

Wednesday July 22nd, 1992

This morning's tasks were two-fold. One was to get the homing missiles nice and slinky so they get drop off from both sides of the Manta ship, then power off forwards before selecting a target and chasing after it. The second task was to think of something easier to do in the afternoon than code in the robot control mode. Unfortunately, I couldn't. Rather than have the simple 'fruit machine' sub-game of the original Uridium, I want a more complex arrangement whereby the Manta flies over the runway, transforms itself into a giant robot and then drops to the surface, breaking through the hull to the deck below. An alternate control mode then sees the player battling it out with the dreadnought's occupants Paradroid '90-style, only much simpler and quicker. And a right barrel of fun sorting it all out was. Grab routines from Paradroid '90 and Fire & Ice, add some new ones, smooth them out to make them faster and watch them not do what I wanted them to do. Background collision detection never was my idea of fun, but if everything in the game obeys the physics of solid objects properly the overall effect is better. It's one of those things you only notice if it's not there. I hate meanies that move through solid walls and floors that I can't go through.

Thursday July 23rd, 1992

A final bit of tweaking on the robot control mode allows me to walk it backwards while firing. Great for that dignified strategic withdrawal. Now to tie everything together. A lot of things need doing at once: the Manta-to-robot transformation sequence, setting up a second level with the surviving robots on it, triggering departure from the robot shoot-out, and finally getting to another airborne sequence. Such things as starting co-ordinates, a different sized scrolling window and setting up surviving robots from the previous level rather than the player's lives all need to be arranged.

Friday July 24th, 1992

Put in a control mode for the drone robot. Unlike in the main game where the drone follows the constantly-moving main ship, the drone robot can collide with the player's main robot. It needs a cunning algorithm to keep it out of the way. I've rigged it to move away from the player if it is very close, and walk towards the player if far away. This currently works in open spaces but it remains to be seen how well it copes in confined spaces. Of course, the drone can be backed into a wall and approached and is unable to do anything about it. Also put in a robot weapon that, when fired, releases a bullet casing from the gun. This falls to the ground with a shadow before coming to a stop. Looks quite swishy.

Monday July 27th, 1992

Phillip supplied me with the robot animation frames, three in each of the eight movement directions. That's not really enough to show convincing walking, even from above. So, faced with either adding at least another 16 animation frames or finding another solution, my money's on thinking of a way out. How difficult can it be to control two feet separately, he says, remembering the 'Justice' episode of Red Dwarf IV, when the lads had mechanical boots on to escort them. I tried nearly all the possible combinations of add and subtract instructions before arriving at a workable system involving a leading foot which spawns a trailing foot. The idea of two independent free-thinking feet is nice but they'd probably go off on there own separate ways, rather like seven league boots when not properly supervised. So the leading foot does all the work, setting up positions for itself and the trailing foot. This system is incredibly simple now that it's done, and the feet look great as one of them is always locked to the floor, just like real life. How many video games have managed that? Most tend to 'moonwalk'. I also slowed down the robot speed to show off the walking a bit better and it's a 500% improvement, and as a beneficial side-effect the drone robot now behaves much more life-like as it fidgets about if you chase it. There's no stopping me now, I'm on a roll.

Tuesday July 28th, 1992

Twas again a Firey Icy sort of day. I only mention this because otherwise you might think I'm taking a sly day off and also it illustrates that a programmer hasn't finished with a game just because it has been released. I spent much time writing some playing tips which would be finished but for the fact that the editor crashed on me while saving out the final version. Luckily I had most of what I'd written still on the screen so I wrote it all on paper and retype it tomorrow.

Wednesday July 29th, 1992

Bit of a wondering-what-to-do day. The game is now waiting on ideas and for fatty Phillip to draw the robot feet, which he's trying to use as blackmail to get me to take out something that probably won't stay anyway. How cheap can you get? So I wrote the high score and initials entry routines.

Although boringly mundane tasks, they are still tricky to do because I like to present them differently in every game which means I can only nick tiny bits out of my old games. It has to be done sometime and it makes people think I've nearly finished if the presentation side of things is finished.

With possibly two players playing the game it has to work out if either player has just lost their last life, if so are they on the high score table and then what input device are they using to enter their initials. I've got the letters of the alphabet swinging round in a large oval with a Manta ship pointing to one of the letters. You just move the stick to rotate the letters and hit FIRE to select the letter which then slides into place.

Thursday July 30th, 1992

Drew some robot feet myself. By having one frame with a low shadow and one with a higher one it looks like the robot is lifting each foot off the ground in turn. Had a go at drawing a robot body too, which wasn't too bad but I can't face rotating it in eight directions with all the lighting done properly. Finished off the high score routine bar some text to say well done.

Friday July 31st, 1992

Had another go at drawing a simpler robot body, and threw in as many colours as possible. This helps to separate the different parts. Still can't face rotating it in eight directions. Although DPaint gives as accurate a rendition as is possible rotated at 45°, it has no idea what I wanted to draw in the first place, so the maths takes liberties with my straight lines. What I need is one totally unlit frame drawn at 45° which can then be spun to get the three diagonals and then lit. Human ray-tracing, no less. Also created another plot routine to display an object in one colour for showing that an object has been hit. It plots in this colour for one cycle before reverting to its original colours, giving a nice flashing effect.

Monday August 3rd, 1992

Phillip has yet again come up with something outside the scope of my software.

Not satisfied with a tank with a turret, he wants a tank with two turrets, each with limited rotation. So a quick re-working of the turret-facing routines to allow limits to be specified on the amount of rotation allows me to put his tank in.

During this process I also hit upon another snag with the targetting-on-player bits. The tank turret needs to get position and rotation data from the tank body, with other data coming from the player to decide where to point. So I need another pointer to the player (as there could be two players) for the turret to remember. This is all helpful the other way round as the homing bullets of the players may need multiple pointers for their target and their parent, because a new weapon I developed today involves launching a smart missile which selects a target, fires at it and then moves on to the next.

Tuesday August 4th, 1992

Finished off the double-turretted tank which is suitably deadly, and put in a pair of ships that fly past lobbing a bullet between them, an old trick from a vector game circa 1982. You can destroy either ship to make them stop or just don't get in their way. Working out the direction and speed for the lobbed bullet involved a bit of Pythagoras to get it to disappear in the right place, and getting the communication between the ships right was a pain.

Wednesday August 5th, 1992

I've noticed some weirdness going on every now and again when using homing missiles. Occasionally one will come out and chase nothing in particular or another homing missile. This is, of course, impossible. Tracking it down involved putting in little tests in various places in the code to identify when the mistake was being made. I thought that maybe if a target was destroyed by something other than the homer on its tail, the homer would still have a lock on that object's data record, so if a new homer was fired, it would use the old target data and be chased by the first homer.

I shored up that bit so that targets dying hold on to their data record for one game cycle so that the homer always spots that the target is destroyed. This did not fix the problem. The homing missiles are smarter than that! If their target is destroyed they are supposed to select a new target and chase that.

So... scenario 2: A homer chases its target, the target dies but not by being hit by the homer, the homer spots that the target dies but is not able to select a new target as there isn't one. The homer then dies naturally by timing out and hasn't cleared out its pointer to its original target, so it says "Well I didn't kill my target so someone else should give it a go". Thus it designates its target as an unselected target for new homers unaware that the target has long gone and is now a homer itself. So all I needed to do was clear out the target from the homer so it forgot about it once the target had died. Problem solved. You're nine tenths of the way there if you can just identify the problem but sometimes you only see knock-on effects and it can take a while to sort out which haystack the needle is in.

Thursday August 6th, 1992

Today is a rare day indeed - there are no known bugs in the program. That is, it's not embarrassing itself due to mistakes in my code! That means that I can write same sparkly new code and know what to blame when something goes wrong. Today's new features then are: a new graphic and algorithm for the chaser weapon that now sits on meanies until they die rather than fire at them from a short distance which was a hit unreliable for moving targets. Also added some little meanies that I'm calling thugs, which run around inside the ship for the robots to shoot at. Also a fast laser shot in one of three snazzy colours, no less. Get 'em while stocks last. Jason, our sound super-hero, says he's written a bar of the title tune. A whole bar, mind. And not just any bar either, but one from the middle!

Friday August 7th, 1992

Day off due to Hairy Paul thinking it's a good idea laying a carpet at 3am. It wasn't, but it was fun while it lasted.

Monday August 10th, 1992

Put in some new weapons for the Manta, namely an orange laser, a bomb to drop onto the dreadnought to shake the enemy up a bit, a Defender-style ioniser gun, and a wide-spread twirly thingy. With all these new weapons a method of obtaining them is required, and the hooks were all ready to allow the releasing of an object when a wave is destroyed. A bit of tampering produced a pod, looking very much like a homing missile as no graphics are yet available. Collect it and the weapon changes. One little unanticipated side effect is that in drone mode if a weapon is collected both ships get the weapon. Not sure whether I like that or not, let alone whether I can stop it. Two-player mode is unaffected so either player can pick up the pod for a weapon change.

Tuesday August 11th, 1992

Drew the graphics for the ground bomb which, if it misses the deck as it falls, heads off into the void. Changed the chaser bomb to slow it down as it nears its target. That stops it from buzzing around as it damages its target, then once destroyed it selects a new target and off it goes, at speed. Put some copper fading into the control panel to get some more colours on it and got it up to 39. It's in a bit of a wonky format so getting it from DPaint to the game involved writing a small routine to re-arrange it. I also speeded up our age-old collision detection routines to get them running faster, which could easily save a couple of raster lines. All game routines are measured not in the number of instructions or micro-seconds to execute but the depth of a border colour bar. You set the border colour to a real sexy purple at the beginning of a routine, then back to black when you finish, and see how big a bar it makes, i.e. the distance the monitor scans as it's building up the picture each frame.

Wednesday August 12th, 1992

Put in some more test attack waves of ships to have a go at shooting and producing pods to try out all the weapons available. It's no good waxing lyrical about how good the super-smart gargantua-bazookoids are if no-one can actually see them. Changed the control panel colouring to a dark green and implemented the remaining ships or robot hit points display. These are interchangeable as they are never required at the same time. The panel update is running under multi-tasking so that it doesn't waste valuable time. If the game is busy then the score display might not be updated immediately, it will get done when things aren't so busy.

Thursday August 13th, 1992

Just for presentation's sake I put in the text for the high-score entry screen and also for the player ready screen, which has to say which player is in control or, if both players are playing as a team, which one is controlling the lead ship. I've also been carving up some of the Paradroid '90 background graphics to use temporarily for the interior battles. Then I can check out the background collision detection routines a bit further and try and set up a deck to see how difficult the game is. Must put in a main title screen soon. I've cut out the Uridium 2 logo so I can drive it about the screen as sprites. Of course the game name might change so there's no point in getting too carried away.

Friday August 14th, 1992

Having had a further play with the robot control mode, especially with the drone robot attempting to follow the player, it is clear that the drone is going to get itself caught on narrow bridges and do its "I'm completely stupid" impersonation and try to home in on the player and plough into the bridge sides. Let's see if I can fix it. This is the fun bit because I know the control mode well so I can adjust it fairly confidently and know that I won't wreck it (but I made a backup just in case!) After some investigation I decided to rig the drone 'intelligence' routine so that the drone ignores homing on the player if he didn't move last time and wait until he's walked his way out of trouble before resuming. It looks very clever and handles the background better than a player who's not-really-concentrating-too-hard-at-all actually.

Monday August 17th, 1992

Put in a title screen to get the game logo in. This needs to be bigger really, but it'll do for now. I've rigged up the inside sequence to allow the player robot(s) to be destroyed by the thugs rather than escaping by taking off after the last point of energy is removed. The main task will still be to destroy as many generators as possible within a time limit, but I don't want to put that in yet as there's nothing more annoying than getting to an important bit to test when a time limit suddenly destroys everything. By the way, thanks to Steve Allan for his kind words in September's The One. Graftgold have no immediate plans to put Morpheus on the Amiga. Uridium 2 will take a few months yet and after that I'd like to tackle another original project. It might be fun to do, though.

Tuesday-Thursday August 18th-20th, 1992

Another Fiery Icy session.

Friday August 21st, 1992

I wanted to put in a meaty mass-devastation weapon which has a slow reload time to ensure that not too many go off at once. That's the easy bit, and I can stop the two-player team from getting one each by only releasing one at a time, but the drone mode gives the new weapon to both ships. Each has its own reload time but they can both fire on consecutive frames. Time to do this properly and set it up so that each Manta gets its own weapons. It's not too tricky to do, but it is a bit messy, with pointers to weapons tables, object and player data all flying about at once. Picking up weapons needs to be smarter too as there's no difference between the player and a drone, so the weapon exchange from a pod to a player must be done by the player, not the pod. All the pod knows is that it has hit a player's ship.

Next month!

More graphics! More game design secrets! More exclusive info! Can you handle it? We can't!

PIC: With the game's ten power-up weapons now full implemented, Uridium 2 is starting to look a lot more impressive graphically - even if much of the action is still taking place over a blank experimental backdrop. The alien waves are becoming more intelligent, too - all good early pointers towards a top-quality blast when the game is finally finished.

PIC: The Paradroid '90 style walking-robots section, where players can earn top bonus points by destroying the big internal reactors before bugging out and escaping. Note the little "thugs" that constantly attack our heroes. Fortunately, the robots can leave at any time via one of the level's emergency exits.

PIC: The graphic frames for the Manta's intelligent homing missiles, showing how they turn to track a moving target. The strange mine-like objects at the bottom, though finished, are still waiting for Andrew to decide what he wants to use them for.

PIC: And here are the animations for the robot that the Manta transforms into for the end-of-ship sub-game. You can't see the feet here, as they are drawn as separate objects and added by the program later. Notice how the frames haven't simply been flipped - each one has been painstakingly drawn to ensure a realistic lightsourcing effect.

PIC: The famous ioniser "toothpaste" lasers, originally used in Defender and lifted by Andrew for Morpheus make a comeback in Uridium 2. Look at those zingy beams go!

PIC: At the end of each dreadnought, the Manta craft(s) transform like those famous "Robots in Disguise" and crash through the hull. Note the tank with two independently-firing turrets - a programming headache if ever there was one...

PIC: Yes, you guessed it... it's the high-score table. Erm... and that's about it, really.

PIC: It may look vary pretty, but Uridium 2 will almost definitely NOT be looking like this Deluxe Paint mock-up. Andrew isn't sure about the organic feel of the backgrounds, and will probably end up reverting to the more familiar shiny steel constructions that original Uridium players will be familiar with.

Series Links

Part 1 / Part 2 / Part 3 / Part 4 / Part 5 / Part 6 / Part 7 / Part 8 / Part 9 / Where are you Uridium 2?