Diary of a Game
Uridium 2 Part 8
Oooh, we're almost there! Andrew Braybrook's super-blaster for the 90s is oh-so-nearly finished, with his ongoing development diary now in its penultimate month. The game's not due in the shops until around June, but AB is beavering away like a little programming demon to cram in all those wowzer features and explosions. In fact... well, we'll let him tell you all about it...
Part Eight — January 1993
Wednesday 6th January, 1993
Spent the last couple of days and some of the Christmas hols checking out various bits of our software on the Amiga A1200, as well as checking out other people's. Well, it's fast, but a lot of stuff won't run any more. In order to determine just exactly how much faster an A1200 is and to monitor how much spare time Uridium 2 has at its disposal, I've written a routine to see how much time is left after each frame is built.
That's not quite as easy as it may seem because we run a multi-tasking environment in our games so the score panel update is also eating some time but it gets shut out when the game gets busy. So just measuring the time that is left over after the score process has had its fill won't tell me when it's really in trouble, but it will let me know when it's getting close.
The next tricky bit is to display this information. This process mustn't take too long as it effectively distorts the results. Printing the answer in 32 glorious colours is therefore out of the question. I was just about to key in a table of display colours to change the score panel colour according to the percentage of spare time when I remembered all of the trouble I went to in working out how to do HSV colours last month, which, apart from anything else, required me to type in a table of 90 colours, from red, through yellow and green to blue. Ideal! As long as the spare time doesn't exceed 90% then I can just pick up a colour from this table. I knew all that HSV stuff would be useful one day!
Thursday 7th January, 1993
The A1200 showed itself to have about three times as much spare time, but then I realised that the tiny routine measuring the spare time will all get cached by the 68020 and therefore will run much quicker anyway, making it look like there's more spare time than there would be using the usual mix of blitter, copper and CPU. I'll have to try it with the cache turned off.
We've been considering alternative bonus games, more complex than the old 'slot machine' emulator of the C64 version, but less complex than a game of Chess against someone who's really good at Chess. Latest plan is a game of intergalactic bar-billiards to get the reactor core to self destruct. Not quite sure how we're going to explain this in the game scenario. Blame Mark and Simon far this one, not me. The only real way to find out if this is going to work is to program it and try it out on a few people.
Tried loading Uridium 2 on the A1200 through a stereo TV via its inbuilt modulator. Quite a good picture but the sound is rather muffled. Sounds fine through a normal monitor or the hi-fi, which is rather puzzling. Jason is looking into it. Why isn't the stereo output of the Amiga sent to a stereo TV actually in stereo, then? Is there a problem here?
Friday 8th January, 1993
It took a bit of thinking to work out what new routines I needed to do this sub-game, and a lot more thinking to work out where in the game to put the test-bed. Being a sub-game it would normally only occur after a couple of minutes playing time, but naturally I don't want to have to waste all that time just getting to the bit that I want to test, so I put that part of the game in the front of the titles sequence.
It all gets rather weird at this stage because the joystick is switched off except the fire button at this time, so I couldn't control anything. The joystick is off because I may be running a demo mode and joystick input comes from another routine rather than the real piece of hardware.
All this is now integrated into all the various joystick polling, options key press, demo record/playback routines, etc, so I ended up just having to remove a few lines of code to fool the titles sequence into thinking it was playing a real game. As Scotty said in Star Trek IV: "The more complex the plumbing, the easier it is to block up the drains". Anyway, after debugging the bouncing routine so that I can simulate billiard balls, the sub-game is basically up and running. I can quickly try out different speeds and controls on a number of people and the game does appear to be rather hard and quite slow. More thought required.
Monday 11th January, 1993
Gone dotty today. Building rotating throbbing patterns out of dots in an attempt to gather inspiration for the sub-game. My dot particle processor is quite slow when it comes down to it. By the time it has checked the position to see if the dot is on the screen and worked out where it has to go and finally worked out what colour you want it to be it might as well have used a single pixel hardware sprite. Now there's an idea!
Tuesday 12th January, 1993
Wrestled, nay grappled, with AmigaDos for the second time ever. Jason's 'Amiga Programmer's Guide' won through in the end and told me where to find the magic flags that tell me what CPU is being used. I felt that this is the sort of information that the game should have available and since I don't know how to determine which CPU is which then one may as well ask the operating system.
This is all done at boot time, when the disk is first inserted into the machine, and is communicated up to our operating system, the Kernel, just as it takes over the running of the machine. Now to try it out on the A1200 to see if it spots a 68020 CPU. Having correctly identified a faster CPU then I have the option of switching in 68020 specific assembler instructions (if SNASM will let me!) or just running a few more sprites around on the screen. I think it's unlikely that I'll take much advantage of the new chipset at runtime, but the extra memory and faster CPU will all be useful.
Thursday 14th January, 1993
SNASM didn't let me. "That's not a real instruction", it said. Never mind. There's more than one way to spoil the broth. For now though, the immediate problem is: Why won't the game run at all? Someone had put an old piece of code back into my program that gulped a hefty 32K save map buffer that I had changed to a 4K buffer ages ago. How can this happen? I had already deduced that the game was crashing because it had run out of memory so I have been looking at the major areas of the game to see where memory could be saved.
Compacted two lumps of plasma down from 7K apiece to 1K, that was quite satisfying. Now at least the program is shoe-horned back into a 1 Meg machine but I'm not sure how much memory is spare. The sub-game is still causing me no end of headaches. I have to come up with something fast, simple, exciting and a bit different. Designing the game is just so much harder than programming it. I've done enough programming now that I can code myself out of hefty paper bag without too much difficulty but designing things requires a constant flow of inspiration and new ideas. You can't buy that in shops!
Friday 15th January, 1993
Got a pretty swirly star display throbbing in and out but I can't think of a use for it at all. It displays four rings of about a dozen stars in each and is simulating 3D by effectively moving the stars in and out from the centre of the ring and making them glow brighter when further out. The rings also spin at different speeds to give a spiral effect. Nope, spent most of the afternoon trying to think how I can use that effect but I've failed.
It's about time I could load in smaller maps than the maximum size for the dreadnoughts and get them displayed in the correct position. Managed to crash the data compactor program by feeding it one of the early dreadnoughts which is quite small. Since it's not actually my compactor then I have no chance of fixing it so I'll have to change the maps to get them smaller to start with. At least I can say I've done something useful today.
Monday 18th January, 1993
Right, I feel a sub-game coming on, so I had a quick dabble on DPaint to get a rough idea of graphics sizes and colour usage. I'm going to have a fairly extensive palette change to do this display, using six colours to glow various stages of a giant defensive shield. I don't know exactly how I'm going to justify the game in the scenario but that's half the fun, trying to think up a cohesive plot for the whole thing later. Does anybody read the game plots?
Perhaps I ought to write a snooker game. Mind you, anybody who had never seen the real thing might wonder what the plot is all about. This white sphere is the agent of the alien stick creatures used to destroy the majority red sphere creatures by projecting them down into six bottomless pits. The ethnic minority spheres are then picked off one by one until none but the white traitor remain.
I've relented over the landing the Manta on the final runway. That's now back in as the robot section of the game is to be replaced. It is no longer appropriate for a transformation sequence and a robot bursting through the hull of the dreadnought. Idea cancelled due to lack of interest.
Tuesday 19th January, 1993
Tried out a new plot routine that I just feed a shape and it will display it in any of the 32 colours. I spent some time defining circles of different sizes so I can do an expanding red circle of debris when the Manta blows up. The biggest circle I did was 96 pixels across, which seemed huge on DPaint but appears quite insignificant in the game. Bigger circles are required.
The new sub-game control mode fortunately takes the same parameters as the old robot mode so it didn't take long to tune up a workable new control routine. But can anybody cope with it? This bit is now more like an asteroids control, with loads of momentum. How will people get on with this?
Wednesday 20th January, 1993
Graeme paid us another visit. This time he had one arm longer than the other because he had dragged an Amiga 4000 over so we can have a look at it, and, more importantly, a listen. Our sound routine is a little unhappy on an A4000; our sound samples are not always coming out right. They sound fine on a 500+ and a 1200, and switching the cache off on the 4000 rectifies the problem so we are talking about a timing discrepancy. The 68040 is so amazingly fast normally that the Amiga sound hardware isn't getting enough time to react. Jason is looking into it.
Mark is busy scanning pictures of rocks, asteroids, moon craters and the like for our asteroid level. He now has a flatbed scanner and a picture publishing package on the PC which allows him to digitise pictures to a very high resolution and in loads of colours. He then has to reduce the number of colours and the resolution to that of the Amiga, and re-touch the images to get them to all fit together.
Thursday 21st January, 1993
Whole day spent mulling over the sound routine. Just what is that 68040 data cache doing to our sounds?
Friday 22nd January, 1993
Another day on the sound routine. Two of us, now. A frustrating week is marvellously rounded off by getting the phone slammed down by whoever mans the phones at Commodore Technical Support. First call at 14:20 finds 'The Man Who Knows All' at Commodore still at lunch, ring back later. I figured I'd give him a while as I had some more investigating to do. Ring back at 15:12, leave it ringing for a full four minutes only to be met by someone saying "All the lines are closed now, ring back Monday at 10 o'clock" and the phone gets slammed down. Someone's in need of a holiday.
Mind you, with a short working day like 10 'til 3 perhaps I should apply for a job there. I mean, here am I, on the front line, trying to get our code working on one last machine, it works on all others, getting no support whatsoever. We've wasted three days trying to figure this out and if this is a known problem, or anyone suggests switching off the data cache, I shall be most disappointed.
Thanks to Toby Simpson and Rob Northen for being considerably more helpful in shedding some light on the problem, under the veil of secrecy that surrounds yet another Commodore product. Just what is it about this total secrecy thing? If I had a new, wonderful computer I'd be shouting about it from the rooftops as soon as it was ready. So what if the opposition find out about it, if it's good they'll be quaking in their boots, and the more people who have correct detailed information about the machine, the more products will get written quickly for it. Any new machine, no matter how wonderful, will surely die without a constant rich supply of software. I'll scratch your back, you scratch yours as well.
Monday 25th January, 1993
More test backgrounds for the sub-game. Seconded six extra colours for in-flight modification. I want to represent protective shielding on the ship's power generator with concentric circles of glowing colours. Decided to ditch the mask plot routine. I was using it to generate an expanding circular explosion, but it takes too many circle definitions, and there seems little point in going to all the trouble of running a 32-colour game only to plot explosions in one colour.
Tuesday 26th January, 1993
Coaxed two test maps of two new graphics styles out of the graphics artists, the asteroid dreadnoughts from Mark and the battle station from Simon. These will become fleets three and six respectively. Just time to put them into demo format for this months piccies.
Experience the joy, the tears and the — hey! — feelings, as the Uridium 2 diary reaches its conclusion. Keep a box of Kleenex handy. Sniff.
Andrew Braybrook Amiga Softography
Graphics: John Cumming
Music: Jason Page
O.O.P.S Kernel.: Dominic Robinson
Graphics: Michael A. Field,
John W. Lilley
Music: Jason Page
Graphics: John Cumming
Music: Jason Page
Sound: Steve Turner
O.O.P.S. Kernel: Dominic Robinson
Graphics: John W. Lilley,
Music: Jason Page
Graphics: Colin Seaman,
Music: Jason Page