Codetapper's Amiga Site

Uridium 2 Part 7

Uridium 2: Diary of a Game part 7While the rest of you were probably snoozing in front of the telly, polishing off endless Turkey sandwiches and wandering around 'confused' as a newt, Andrew Braybrook has been busting his hump over the festive period to ensure that you can be playing his latest shoot-'em-up blockbuster as soon as possible. And by now you're bound to know that all the gory details can only be found here, in Andrew's exclusive monthly diary serialising the creation of Uridum 2. This month we're in heaven 'cos we've reached Part Seven, and the end is nearly in sight. Well, almost...

Part Seven — November/December 1992

Wednesday 25th November, 1992

Had a further visit from Mr Rushbrook who has converted most of his background graphics from seven colours to thirty-two. Let's just say I'm not Mr Popularity at the moment. The extra colours certainly help though. Just a bit more tweaking and they'll be OK. I've also been hassling Mark for all the game graphics to be converted to his new palette. This requires remapping and, being a fussy person, some re-drawing of certain areas.

Thursday 26th November, 1992

Got some of the graphics through from Mark today. Just the central Manta ship to go and then we can concentrate on creating new graphics. Added a new torpedo weapon to destroy ground targets. Only the bombs and this new torpedo can knock out walls and what I call 'destructibles'. That way you have to destroy waves of fighters to gain the weapons with which to take out the rest of the dreadnought. Landing may then only be possible after the player has destroyed and knocked out a specified percentage of the enemy dreadnought.

Friday 27th November, 1992

Did anyone spot the Renegade/Graftgold sponsored Lombard RAC rally car, number 120? Congratulations to Lloyd Shelley driving and Ray Berris navigating for starting 120th, finishing 64th and coming 8th in class N2.

Discovered how to do snakey-type multiple-sprite thingies today. Chris Wood has been here converting Fire & Ice to the PC and explained how to do it, and it's definitely cheating! We gave up after we had got to university-level mathematics using hyperbolic co-tangents and the like. Not the sort of thing you ask a 68000 chip to sort out at high speed.

Anyway, it turns out that as long as you keep at least one end of the snake moving it looks quite realistic just by each letting link of the snake take the average position of the ones on either side of it. Since all the links are updated sequentially then this averaging process is actually using half out-of-date positions as one link won't have been moved when its position is read. That actually produces a 'lagging behind' effect which looks more realistic. Now all I have to do is think of a place to use this in Uridium 2! Why is it that the simple solutions are often the best?

The latest new dreadnought design in action

The latest new dreadnought design in action. The game's getting harder now as the backgrounds are becoming littered with objects that the player must steer around.

Tuesday 1st December, 1992

Just time to make up a couple of demo disks to take to London as we are talking to certain parties regarding the production of some music especially for Uridium 2 by some well-known chart personalities. All top secret, hush-hush, say-no-more at the moment.

Wednesday 2nd December, 1992

Came up with a new method of controlling all the destructibles. Up till now for every destructible block on the background there has been an invisible object sitting there waiting to be hit by a bomb. When it does, it updates the map and the screens, produces an explosion, gives away some points and finally makes a note that it has been destroyed so it doesn't come back. That fits nicely with our system but is a bit wasteful as most of the time there are no bombs flying about.

A structure re-arrangement needs to be made so that a bomb going off has a look for itself on the map to see if any blocks are destructible. The only processing that needs to be done is therefore by the bomb. The fly in the ointment is that something must keep track of destroyed blocks, for both players, so that they stay destroyed if the players swap over due to pilot error. There is still need for a list of destructibles and I need a fast search algorithm to mow through the list and find the relevant entry to tick it off. A sequential search is NOT very efficient; there is a better way.

On later levels, the Manta must be turned on its side to squeeze through gaps

On later levels, the Manta must be turned on its side in order to squeeze through narrow gaps.

Thursday 3rd December, 1992

Wrote the necessary binary chop search algorithm which was a useful exercise at least in proving that finding the average of two numbers is not particularly fast in 68000. Although the binary search always gets to the required entry in a few attempts, each attempt is a lot slower than just hacking through all the entries sequentially — about five times slower to be precise. Can you be precise when using the word 'about'?

Things had just got to the stage where I'd got everything working silky-smoothly when Mark comes in and asks for it to be able to blow up a four-block square object as one, which I could accommodate (and I only put that word in 'cos I can spell it), and then I realised that all of today's and yesterday's work has been a bit of a waste of time.

There's a considerably easier way to do all this keeping track of destructibles that I would expect just about any other programmer to do, and that's to just save away all 32K of the map (one for each player - making 64K) each time the player is destroyed. That way all the destructible blocks are just there waiting in the map for next time. No fancy search algorithm, no having to list all the destructibles, no having to go through that list destroying all the ones already hit and all it costs is 64K of fast RAM. Got buckets of that — don't know what to do with all the damn stuff!

Friday 4th December, 1992

In went the map preserve and restore routines and out went the binary search routine. Shame, that, because it was rather clever. Trouble is that it wasn't blatantly clever — not that preserving the map is blatantly clever either, but it's certainly faster than the old method so in it stays. Having two graphics artists working on a game starts creating filenaming problems. I was numbering the fleets of dreadnoughts in the sequence that they were being created in, and Mark is numbering them in the order that they will end up in the game. Result: Fleets go missing as they get copied onto my hard disk as the same number gets used twice. A massive renaming exercise was therefore undertaken to organise everything so that no more accidents occur.

On a lighter note, my desk has moved seven feet to the left to fit even more graphics artists into the room. Question: How many graphics artists does it take to change a light bulb? Answer: One, but you have to impress upon him the importance of not changing the light bulb at all, it's really good as it is.

parts of Uridium 2 are beginning to look more reminiscent of the C64 original

As new graphics arrive and are implemented, parts of Uridium 2 are beginning to look more reminiscent of the C64 original.

Monday 7th December, 1992

Another re-vamp of all the weapons occurred today. The torpedo weapon is officially in, to enable the destruction of certain weaker wall sections; the chaser weapon has been tightened up as it has trouble when it is on the trail of moving objects; the bombs were affecting too wide an area causing too much mayhem too quickly so they've been cut down a bit; and the ioniser weapon has been changed from two thin bursts of toothpaste to one thicker one. Miscellaneous fixes also included making the last smart bomb fired actually work and the bonus score pods give points to the correct player, both howlers in their own rights.

And did I say last Thursday that I'd got buckets of fast RAM? Well, the cupboard is bare and the doggie is going to have to eat cake, or — to put it another way — whoops, I've used all the memory up.

Tuesday 8th December, 1992

Got a new map. Ship Two of Fleet One to be precise, so I had to put in all the meany generation points, activating the lifts that bring ships to the runways and all the Uridimine ports. Also put in collisionable walls for the first time, which highlighted an ongoing problem, i.e. you just can't see the high walls until it's too late. Put some black and yellow warning stripes round the edge of the wall, and then tried putting some garish patterns on the wall tops. Tried various wallpaper designs before settling on a throbbing colour pattern. More 'art deco' than military camouflage, but playability is at stake here, you know.

A concession to one of Jason's moans is that you can now fire other bullets while the shield is up so you don't get impatient waiting for it to run out. Also in is a fade to all white as the dreadnought melts away for dramatic effect. It also speeds up the proceedings somewhat.

All collisionable objects have yellow and black warning surrounds

Note the tall towers, which the player's ship can crash into — all collisionable objects have yellow and black warning surrounds.

Wednesday 9th December, 1992

The latest addition is a 'gunsight' for the torpedo weapon so you can see where the torpedo is going to land more easily. The calculation to find the right landing position is rather hairy as the torpedo is fired from a moving platform so it takes the speed of the firer, adds a constant speed for the action of firing and then arcs down to the ground, and the sight has to know where it's going to hit.

Gun turrets that appear from inside the dreadnought have been added. A small hatchway opens and the guns raise up, fire one shot and then retreat underground.

Friday 11th December, 1992

Blowing hot & cold on the A1200.

Monday 14th December, 1992

The game has started running out of memory all over the place so it's getting quite tight in there. First plan was to cut down on the amount of map that I saved for remembering all the destructibles. Then it hit me. Why save all the map? Why not scan it for character codes that have been destroyed and just remember where they are? Even preserving 1,000 possible locations for each player only uses 4K, not 54K. The restore map then just reads the list of destroyed locations, updates the map before the player restarts and it's all ready to go. This is the third method tried and also the simplest, smallest and quickest.

The two Mantas skim the surface of one of the dreadnoughts from the first fleet

The two Mantas, one in computer-controlled 'drone' mode, skim the surface of one of the dreadnoughts from the first fleet, whose biomechanical, skeletal structure probably owes a lot to the work of H.R. Giger.

Tuesday 15th December, 1992

Spent all day working on some routines to convert RGB colours to HSV colours. Anyone who has played with DPaint and changed the palette will probably have noticed that you get two sets of three sliders to adjust the colours. RGB colours is how the hardware expects you to supply colour information and HSV is just another way of specifying colours, like using Matabele Gumbo Beads for money. It's just that the translation is a bit tricky, you see.

No manuals really go into details about how to do it so, as it's an artistic matter, why not ask a graphic artist? Why not then ask them how to nail jelly to the ceiling? They'll be grateful I worked this out one day. By the way, the reason for doing this, other than that it's been something I've wanted to know how to do for some time, is that when you're fading between certain colours using RGB values you get undesirable colours in between. The old Atari 800 uses a system more like HSV, it had sixteen colours, and sixteen brightnesses of those colours, great for metallic effects. Some of those colour fades aren't even reproducible on the Amiga.

Anyway, the maths was a bit tricky, not complicated but messy, but now I can convert from RGB to HSV and back, the horrendous bit turned out to be fading between two HSV values. It all hinges on defining a circle of ninety hues (the H in HSV), then deciding how much white is NOT mixed in (the S in HSV, for saturation of colour, lack of white) and finally the brightness of the resulting colour (the V in HSV, for... voluminosity, or something)!

Then to fade you just rotate around the circle of colours by the shortest route and move in and out of the circle for brightness. With a bit of up and down for saturation. Marvellous, eh? How does this affect me, I hear you ask? Well, maybe in a game or two I will use these routines to more effect but for now the Manta glows prettier colours and that's it!

Wednesday 16th December, 1992

Added shadows to all the walls on Mark's new deck and put in some appropriate meanies, like space ships on the runways and Uriditanks on the surface. Spent much of the rest of the day marvelling at all the sexy new instructions on the 68020 chip, as featured in the Amiga 1200. They (Motorola) seem to have thought of all the things that are awkward to do on a 68000 and added new instructions and addressing modes to handle them. Wow! By the way, I still don't know if the A1200 has any more sprites than previous Amigas. Probably, as the advert goes.

More action above that Giger-inspired dreadnought

More action above that Giger-inspired dreadnought. Here the collisionable walls are really obvious — just look at those chevrons! Doesn't stop them being easy to smash into, though...

Friday 18th December, 1992

It's a 'Thinking about the game design day'. That's my excuse, anyway, for writing a grand total of six lines of code. But as we programmers say, as long as they're a good six lines of code...! Had a drink of coloured water at lunchtime and it turns out that one of our graphics artists is a kleptomaniac. I promised John I wouldn't say who it was though. The very fabric of society is coming apart at the seams. It's a sad old world.

Monday 21st December, 1992

I'm making the reactors more difficult to kill by allowing them to shoot back, and they also have satellites to absorb shots. I have to really sort out the underground bit as we only have some test graphics and no real layouts as such.

Work stopped rather abruptly for the Graftgold Christmas lunch at The Victoria which got an all-round thumbs-up. Unfortunately for Uridium 2 not a lot of work got done in the afternoon. Some of our Christmas stash of drinks bit the big one and everyone ziggy-zaggied off home into the sunset. More thinking and designing will need to be done over the festive season ready for some gratuitous programming in the New Year.

Next Month!

Duh... Part Eight.

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?

Post your comment

Comments

No one has commented on this page yet.

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

Andrew Braybrook Amiga Softography

Rainbow Islands
Rainbow Islands
Developer: Graftgold
Code: Andrew Braybrook
Graphics: John Cumming
Music: Jason Page
AmigaOSGame
Paradroid 90
Paradroid 90
Developer: Graftfold
Code: Andrew Braybrook
O.O.P.S Kernel.: Dominic Robinson
Graphics: Michael A. Field,
John Cumming,
John W. Lilley
Music: Jason Page
AmigaOSGame
Simulcra
Simulcra
Developer: Graftgold
Code: Dominic Robinson,
Steve Turner,
Andrew Braybrook,
Darran Eteo
Graphics: John Cumming
Music: Jason Page
Sound: Steve Turner
O.O.P.S. Kernel: Dominic Robinson
AmigaOSGame
Fire & Ice: The Daring Adventures Of Cool Coyote
Fire & Ice: The Daring Adventures Of Cool Coyote
Developer: Graftgold
Code: Andrew Braybrook
Graphics: John W. Lilley,
Phillip Williams
Music: Jason Page
AmigaOSGame
Uridium 2
Uridium 2
Developer: Graftgold
Code: Andrew Braybrook
Graphics: Colin Seaman,
Mark Bentley,
Simon Sheridan,
Stephen Rushbrook
Music: Jason Page
AmigaOSGame
Virocop
Virocop
Developer: Graftgold
Code: Iain Wallington,
Steve Turner,
Andrew Braybrook
Graphics: Colin Seaman,
John Kershaw,
Steve Wilkins,
Terry Cattrell
Music and sound: Lee Banyard
Game design: Iain Wallington,
Colin Seaman,
John Kershaw,
Steve Turner
AmigaOSGame