Uridium 2 Part 2

Last month Andrew Braybrook, coder extraordinaire, described the laying of the first binary foundation stones to his latest opus — Uridium 2, the long-awaited sequel to his classic Commodore 64 blaster. Having got his super-sexy, 32-colours, 50-frames-per-second scrolling routine up and running, Andrew continues his saga here — and remember, it's only in The One!

Part Two — June/July 1992

Uridium 2, in my mind's eye, has to start where the first Uridium left off. All the playability from the original C64 game has to be there — the speed, the dynamics, etc — but that must be the starting point, not the finish. I have to add to that. Certainly the graphics can be brought up to date but new features must be incorporated too, and overall the game must be much bigger.

The old adage that a sequel has to be at least 237 times better than the original to be perceived as better at all is certainly true. I'll not pretend that this is going to be easy. In order to give me the best chance of making this game stand out, decisions must be made now as to the hardware requirements of this game. In order to get speed out of the Amiga I don't want to be limited by thoughts of how to make this run on other, less capable machines. Only the Amiga version matters.

Also, I think I'm going to need more than 512K, so it may be a 1Mb-only game. I know that many of you have upgraded your 512K machines with extra RAM — anyone who hasn't yet ought to seriously consider it as many more games will be coming out for the larger machines. After all, an extra 512K can be bought for around £20 — less than the cost of one game!

Monday June 22nd, 1992

Today has been a day of optimisation and consolidation. Rather than developing any new code I wanted to speed up certain functions within Uridium 2. For example, every time a bullet is fired, the fire routine asks our operating system for some memory to store the bullet's position, speed, etc, in.

As with all operating systems, no matter how well written, this is a bit of a slow process. It's much better to have forty or fifty blocks of memory ready and waiting in a list so that when you want to fire a bullet it just says "NEXT," rather than "Excuse me, Mr Operating System, but would you mind awfully sparing a little of your valuable time..." etc, etc. It may not seem much now but it could mean I can run a couple more objects around if I keep the code as lean as possible.

I've also put in the score printing routines using multi-tasking so that even if both players' scores need updating, the actual printing of the score is done whenever there's a spare moment rather than immediately, which could cause a crisis if the game is getting busy. This would manifest itself as a 'glitch' or shudder as the game failed to complete all the processing required within one fiftieth of a second.

Uridium 2 is also the first ever game I've done with a simultaneous two-player option, so it's a bit of a tangle working out which score to update. One Manta ship leads while the other plays wing-man, but the lead Manta could be either Player One or Player Two, each with a separate score. The bullets fired by each must be tagged to say who fired them so that when an enemy ship is destroyed, it knows whose bullet did it.

Phillip Williams, the graphics artist, has just finished all 46 of the Manta's animation frames, in 16 colours only, on Cyber Paint 2. I now have to convert the graphics to IFF format and load them into DPaint so that I can convert them to 32 colours. Our palette at the moment consists of four colour series in six shades. Trying to get all 32 colours onto any one sprite will be difficult but at least we can get different combinations onto various objects. We have a green series, a blue series, some red/orange/yellow explosions and some garish purples. Whatever happened to good old grey? I'll talk him into it somehow.

Tuesday June 23rd, 1992

No work on Uridium 2 today, it was a fiery, icy day.

Wednesday June 24th, 1992

One of the problems with the Amiga's 32-colour mode is that I've never done anything with that many colours before. And, although I've written the plot routines to run in 16- or 32-colour mode ('cos I like to think ahead), we have no graphics for 32 colours and only one art package that can cope, i.e. one copy of DPaint.

I drew a font in 16 colours using the ever faithful font book for Fire & Ice that never got used. This seemed like a good opportunity to add a few
more colours to it using a procedure which goes something like this:

1. Load the .NEO format picture into CyberPaint on the 4 Mega ST.
2. Save the picture out as a .PI1 file which is nearly the same as a .NEO.
3. Move the sloppy disk to the PC and run a conversion utility to change the picture to DPaint-compatible IFF format.
4. Move the sloppy disk to the Amiga and load it into DPaint.

Finally I get to play with real pixels! I added about another eight colours onto the font. Of course, everybody complains that they can't read it. I'm just putting the font in as a series of sprite images so that I don't have to write a new print routine. This should allow for a more dynamic title sequence.

Thursday June 25th, 1992

In order to cut down on the work done every fiftieth of a second I'll have to be careful not to move too much at once when printing text. Once a letter has stopped moving I can fix it in the background and then forget about it.

The closest analogy I can think of is that if you have twenty police cars patrolling a town and you want to make it look like more, you drive them to specific locations, drop off your policemen, and get out the full-size cardboard cut-out police car. You then drive the real car away to the next site. This gives the illusion of having more than twenty police cars. Of course, hot pursuit in the cardboard cut-out is not a good idea. In fact the idea is so far-fetched it could never happen in real life.

Friday June 26th, 1992

Found out most of how to get a PAL Amiga 500Plus to think it's an NTSC machine. You can do it by doctoring the circuit board with a couple of well-placed wires and an optional switch. An easier way is to phone Tony Crowther, who will tell you to hit the register at $DFF1DC with... Well something. A bit of experimentation soon finds out at least one value that works.

I'm one of those people that likes to get each bit of code working perfectly before going on to the next bit, so if something goes wrong there's a good chance it was down to the code that I'm working on at the moment. Sometimes though you need a lot of code to test a new feature out. Let me elaborate...

I've just finished the score printing routine which I need for debugging information (I just get it to print any number of interest rather than the score) but... In order to test that, I need to be able to really score points, so... I need bullets to fire (which are done) and I need a target to shoot at. Rather than code all of the enemy ship formation routines I have set up my cursor to be an enemy bullet and an enemy ship, so I can shoot it for points or run into it to test the explosion routines.

Monday June 29th, 1992

Took delivery of some explosion graphics and a large mine, which I used as a Uridimine, a device used to chase unwanted players away from the nice friendly alien motherships. Having three different sets of explosions means that we can make the explosions more varied, mixing frames, choosing random sets and seeding small explosions from bigger ones.

Tuesday June 30th, 1992

Put in the drop-off ship which Phillip has been working on. It's 96-pixels square and the player's ship or ships are launched from a rear hatch, ready for battle. The drop-off ship then runs for cover. It looks best in darkish, moody greys so I think I've finally talked him into getting the greys into the game. Nag, nag, nag.

Wednesday July 1st, 1992

The problem with wanting to just try things out is that you write the code quickly because you want to see results. Then you think of things that you can't do with what you've written so you have to rewrite it. A game with five different game modes and three different control methods per player, able to detect possibly both devices while playing a demo game, amongst other things, becomes a right tangled mess. And it's watching for a change of those options as well. Coupled with the editor on the PC crashing at an important moment, all this made for a confusing day. And the game doesn't look any different apart from an animated high score display.

Thursday July 2nd, 1992

Put in an option select screen so I can see if the game is playing the same game as I think I've selected, with all the right control modes. It is. Wow! Spent the rest of the morning designing the data layouts for the enemy ship formations. All features from the original Uridium must be incorporated plus enough room to add extra features. By the end of the day I had two formations, one of three ships and one of five, created, moving, firing, being shot, and purging if too far away from the player(s). All that took at least a fortnight to write and debug in the original game. Wonder if the boss will give me the next two weeks off?

Got my new keyboard to play with. No, not a Peavey DPM3SE plus super synthesizer but a 287,000-key PC keyboard, with sensible function keys down the side where you can get them SHIFTed or ALTed with one hand. What a good idea. I'm sure our original PC XTs could do that five years ago, then some bright spark thought: "Let's move all the F-keys to the top where they're really awkward to get at!" Brilliant!

Friday July 3rd, 1992

Black Friday. Today the first hardware sprite graphics got drawn — the enemy ship bullets. But can I get this brute of a computer to display them? All I get is a strip of garbage down the screen. Those routines all worked in Fire & Ice. What is it that I don't understand about this? I'll have to take this slowly and just test one image at a time. I'm sure it's a hardware problem. I hate leaving problems to solve overnight, let alone over a weekend. My mind just works overtime and I get cross.

Monday July 6th, 1992

As I suspected — and I'd been planning the test to prove this all weekend — the sprites displayed get their size and position from the first two words of the display data. These are, in fact, nothing to do with size and position, which it was told about earlier. This all worked in Fire & Ice so why doesn't it work here? Well, I'm fed up with it. And what do I do with code that I'm fed up with? Throw it away and write something better.

So, for the first time I now have a sprite multiplexor on the Amiga that allows me to re-use the three 15-colour hardware sprites that aren't already busy. "Not much spectacular about that," I hear you say. But this routine has a contingency plan. Since the hardware sprites are being used for enemy bullets it would be a blow if some flickered, or worse, didn't get displayed at all, i.e. the Shot-By-Invisible-Bullet syndrome.

What my routine does is use the hardware sprites as best it can and any that don't fit which would disappear are converted to normal blitter objects. I never thought I'd ever do something as ridiculous as that; after all, it's a technique used by the AmigaDos graphics library. For an encore I've put in some background collision detection so that player bullets and the player ship stop when they hit walls or other tall objects.

Tuesday July 7th, 1992

Worked on our disk system to make it more AmigaDos friendly. Failed. Went to see the great rock band Spinal Tap at the Albert Hall.

Wednesday July 8th, 1992

What a band! Great atmosphere, had a marvellous time. Go, Nigel. Go, In the absence of our wayward graphics artist and going by the old saying "If a job's worth doing, it's worth doing yourself" I got out the old DPaint disk and had a play with some spinning circles for a coming-out-of-Hyperspace effect. I thought I'd write an eight-line BASIC program to generate some co-ordinates using sines and cosines but could I get it to work? Fallback mode consisted of some paper, a pencil, a calculator, and a Braybrook-can-round-a-negative-number-better-than-a-grotty-BASIC-program frame of mind!

Thursday July 9th, 1992

Still no graphics artist. Apparently he's on holiday. Looks like I'll have to do the graphics myself again today. I nearly shuffled all the colours in the palette and remapped all the graphics to that palette, just to get better shadow effects, then I thought better of it. The shadows cast in the game at the moment are fairly subtle. Had I gone ahead with the palette changes they'd have been about as subtle as Rambo catching butterflies.

Friday July 10th, 1992

I've been thinking about Monday's sprite multiplexor all week. The data to plot is stored in hardware sprite format, so if it gets overloaded it has to convert the data to blitter format and plot it the slow way. So just when it's busy it has to do even more work. This is not clever. Against that the data is nice and compact. If I store the data in blitter format, when it gets overloaded the data is all ready to plot, and when it's not busy it has time to unravel the data and convert to hardware sprite format, which has to get copied to another place for display purposes. It's more efficient in my head — whether it is in the game is more difficult to tell.

Monday July 13th, 1992

Gary had us all staring at the screen watching for what he-said was a background graphic momentarily changing and then changing back again. This is, of course, impossible. Only he could see it, and despite many times saying "Look! It did it again!", nobody else spotted it. Time to get him certified, I reckon.

The main changes today have been in darkening the colours in the palette and doing the shadows in black. This is by no means elegant of code, fleet of foot or pretty as a picture but it is more striking and is in to stay.

Tuesday July 14th, 1992

Something was stomping all over some important data tables in memory. It took only a few seconds to realise what was happening, but the real question was "Why?" It's one of those situations where any feature added that afternoon could have caused it, which was a blow because I'd only added one new feature and that hadn't been executed yet. Desperation says that a line of code somewhere has gone AWOL so restore it from yesterday's backup and it'll go away. It didn't!

Just by luck on one test run the game lived a little longer, time enough for me to spot that the shadow plotter wasn't working and a blob appeared on the control panel in the shape of a shadow.

My new feature required a change to an important data table that causes all routines to be re-assembled, and the shadow plotter was a new one that missed that process. But, although I now know why it was going wrong, I don't really know how. I suppose it doesn't matter, 'cos it's fixed now.

The new feature was a system for fast targetting by homing missiles. Say you had a tin-can fetish and wanted to find all the different ones in Tesco's. Rather than search through all the aisles, it would be nice if there was a map by the door showing where the cans were. So Tesco's is the list of all objects in the game, the cans are enemy targets, and the fetishist is the homing missiles being launched. Easy, eh?

The other major addition today is an animation for player bullets hitting walls, another use for the hardware sprite multiplexor. And I've got it doing the Manta jet bursts as well. Glad I wrote that one.

Wednesday July 15th, 1992

Discovery of the day: "move.w ccr,d4" is not a real 68000 instruction at all, contrary to my reference book. It's only implemented on 68010 CPUs or better. Getting hold of something as simple as the carry flag for later reference without suddenly destroying it becomes a major problem. All I want to do is see if the player has tripped over a 10,000-point boundary to award a bonus life. How difficult can it be?

Put in a hangar roof for the player to fly under to give the game a 3D look. This led to problems — the homing mines must also go under the roof (easy) but not take short cuts through walls (tricky). The homing mines were not doing any background collision detection. Now, at least, you can give them the slip by hiding behind walls.

Thursday July 16th, 1992

Bad day for the interleaved plotter (the routine plotting most of the objects using the blitter). I found two cases where an object is partially off screen and the background doesn't get restored where it was.

A kludge fix can isolate that case and compensate but the whole thing needs a rewrite. It's bad news because nearly all the other specialised plot routines are based on it.

Next month

Will Andrew manage to fix his plotting routine or will a kludge suffice? Hold on to your potatoes — you'll find out next issue!

PIC: A selection of the latest Manta sprites — it's possible the final ones will have less bright colour schemes. The frames in the bottom half of the screen show the ship turning into a Transformer-like robot — it's possible this feature will be included in the game for when the ship lands at the end of a level.

PIC: Gosh, look at those explosions! These are what you'll see when the Manta crashes, so though you may be sulking, you'll lave something nice to look at.

PIC: The big mothership, originally to be the craft that dropped off the Manta at the start of the level, may now be used as an end-of-level baddy.

PIC: The new graphics have ready made the world of difference to Uridium 2's physical appearance — it's already looking like a polished game. Note the tank and Uridimine launcher in the centre of the screen, two nasties that are already functioning.

PIC: Andrew's recently added a hangar roof to the background graphics — the Manta can pass under the grille for a neat 3D effect. The result's certainly impressive — in the two-player shot below, you can see the second ship inside the hangar — but getting it to work has caused Andrew no end of aggravation. Notice also the first enemy ships, which are attacking in firing to preset patterns. Currently, this is all there is of the background to see — it's basically just a short testbed used to make sure everything's functioning correctly. The proper background designs will be implemented at a later stage.

PIC: The man himself — when Andrew came down for the photo-shoot, he thought he'd squeeze in a quick plug by wearing a Fire & Ice T-shirt. Unfortunately we decided to cut out the actual logo — if you want an ad in this mag, you'll have to pay like everyone else. So there.

PIC: The Manta is hotly pursued by the game's first set of flying meanies. Note the craters in the background ship's hull — in the final version there will be dozens of destructable surface features.

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?