Part 6

By Andrew Braybrook

Thursday May 14th

Today saw the inclusion of another of Mr Pennís little suggestions, a second high score table. One will be for the all-time greatest scores which will be saved back to disk. This will be a facility only available to disk owners as itís too much hassle trying to talk to a tape deck, what with switching tapes half-way through and allowing the C64 operating system to talk to the screen, it means that I have to be careful not to mangle the system variables, which I always do! Disk I/O is much simpler, just squirt a few bytes down the serial bus and let the 1541 stir itself into action. Sorry tape owners, but cassettes were never designed for computer use, tape decks are even dying out on mainframe systems now. Still, you wonít miss what you never had!

Found a neater way of indicating which system or weapon to scrap by use of an orange and black pointer moving around the screen, sounds familiar, and it is. I know I said last month that I wouldnít resort to icons or pointers, well I fibbed. Just one teensy-weensy pointer is necessary, but definitely no icons, never. Anyway this pointer is a lot better than the old Epyx White hand which rears its ugly fingers in Star Raiders II.

Friday May 15th

Rearranged the gameís memory considerably to remove the need for my secondary set of 48 stars. Iíd duplicated the starfield characters for use in two sets, as Iím doing some screen splitting where stars could cross from one set to another. This would look very untidy if they suddenly changed to a completely different graphic. However I recently tuned up the raster split timing so finely that the split occurs off the right end of the screen at exactly the right lines where the set changes. This splitting appears to be stable, even when sprites cross the boundary, so the stars are redundant from one set.

Minor screen glitches usually appear on screen when the programmer canít be bothered to introduce a very short delay to the screen change routine to wait until the raster gets to the side border. Thus all display changes are carried out while the raster is off screen. Changes to the display mode or colours while the raster is on screen invariably cause white flickers and the infamous glitch (more so on C 128s). Sprites can cause the screen interrupt to be delayed slightly, so if all eight sprites line up over a screen change the glitch can move by a few inches - one has to take this into account, says he, attempting to excuse the glitch in GDO, which he spent ages getting rid of in Gribblyís Special Day Out. Of course all of this doesnít excuse the Ďmega canyon glitchí as made famous by Wizardry . . . remember that? Some games seem to be emulating this glitch even today, and I did tell The Edge how to get rid of it.

Anyway all these rearrangements of memory give me another 1K in the video bank, room for another 16 sprites.

Monday May 18th

Had a quick perusal through all the sprites that Iíve created so far and not used, There turned out to be 140 of them, only a few up to scratch. I drew a few more and came up with a design for the remote drone, a six-frame animated vehicle. I can display this in characters while itís on the launching pad, then run it as a sprite when itís in-flight. This gets me out of wasting four sprites all the time, as the ship could be configured with four landing pads with remotes on.

I want to set up a series of charge orbitals in a pattern in the play arena. I was using the star explosion routine with predetermined start speeds to initially show their positions on a smaller scale. This didnít work too well, as some parts flew off screen at breakneck speed while others moved very slowly. Tomorrow Iíll try another method. All I want to do is display a pattern rather like electron shells around the nucleus. The positions generated by this sequence will decide the positions of the charge orbitals in the game proper. I will be using sound to indicate proximity to the centre of the pattern.

Thursday May 19th

The patterned charge centre didnít work out. There were too many concentric rings with too few parts in each so it looked like a mass of dots (even though they were in a pattern). I decided to use the existing title screen explosion generator to produce the charge orbitals, which it does admirably. They could appear in one or two rings, a spiral or randomly distributed. I had to slow down the particles to get them to stay near the screen centre. I also fixed the bug in the position calculation routine so that the particles are moving at a fourth parallax speed in space. Iíve worked out that there will only ever be one of 32 orbitting particles or the nucleus on screen at any one time, so I need only assign one sprite to this function. This led me to define the remaining objects. Eight are for the shipís bullets, one for the remote, one for the orbitals, two for charge rejuvenators, two for charge supervisors, three for meaniesí bullets, two for roamers, and five for other assorted bad guys. This keeps the top limit to 24, although I donít expect all of these to be on screen at once. My top limit of 32 is safe, and keeping the limit of 24 should safeguard the NTSC version which requires that CPU usage be kept down.

Roamers will be antagonisers, just wanderers that keep annoying the player in otherwise nonbusy moments. Charge rejuvenators will carry charge from the nucleus to the steadily decaying orbitals - because of this decay, the rejuvenators will have to visit all orbitals periodically. The charge supervisors will shuttle around the orbitals ensuring that all is well.

Wednesday May 20th

Put in some of the coding to run the remote drone vehicle. This will sit on the landing pad until activated, and then buzz round the screen with its own gun mounted on top. Control of the main ship will temporarily be lost while flying the remote. I anticipate being able to leave the remote out in space near the ship as a decoy if required. I also think that it will become permanently lost if it strays too far from the ship. Iwould also like different drones to have different handling capabilities.

During launch the remote has to switch from being characters to a sprite so that multiple remotes can be carried without using too many sprites. Only one remote will be operable at a time, naturally, as one only has one joystick.

Thursday May 21st

Spent the day at the Institute of Directors discussing the ways of the World with Andrew Hewson.

Friday May 22nd

Worked out yesterday that the playing area of Morpheus is in fact 256 by 256 screens, per level, some 65,000 screens big. This is probably why it is quite difficult to locate the orbitals, as even moving at more than one screen per second it would take over eleven hours to explore it all! This is quite impractical, so I decided to shrink the Universe to a more manageable 64 by 64 screens, such power! This would still take about an hour to cover, but Iíll be providing sonics to guide one into the centre, itís only fair.

Tuesday May 26th

Put in the remote vehicle movement algorithm but wasnít happy with it, so I took it out again. It just felt wrong as the movement seemed to always be in straight horizontal or vertical lines, this game definitely has a more Ďcircularí feel to it.

The remote drone is a peculiar beast, a sort of central vertical fuselage with a hole through the middle, the purpose of which will become clear later. It then has four protrusions, two at the top and two at the bottom, each supporting a rotating triangular block, viewed end-on to allow me to show off varying grey shades as the light falls upon the surfaces. The mysterious hole through the centre is for aiding landing of the remote by being able to see the flashing centre of the landing pad through it. Thus it is possible to line up accurately, knowing that it will land if the entire hole is flashing!

Wednesday May 27th

Changed the remote to run on a polar vector system which allows it to fly in circles if required - Iím not quite sure what to do with it if itís allowed to fly miles away from the ship! I also have to cater for all combinations of ship, Iím only allowing one active remote at once, but the ship could have up to four landing pads with remotes on. I have to prevent the take-off of a second remote, but allow it if the first is later destroyed in action. I shall have to enforce the restriction that a remote must land on its own pad,not another, due to the way the remoteís firing characteristics are picked up. I know it would be nice to drive oneís X-19 into next doorís Porsche garage and get a Porsche 944 out the next morning but lifeís not like that, anyway, Iíve tried it and it doesnít work!

Tuesday May 28th

The remote movement system was completed byallowing the ship to leave it in any place and fly away, the remote will keep going at the speed it was left at. itís best to leave it stationary if you want to find it again, and this enables the player to sacrifice it as a decoy. The movement turned out to be a bit tricky to tune up, so there arenít too many possibilities for good control, so Iíll stick to the one set of parameters for all remotes, but still give them differcnt weapons.

The co-ordinate system used for this is really confusing as there are two centres, one near the ship at the top left of the screen, and the other wherever the charge nucleus is. Itís like drawing two pictures on two bits of tracing paper and sliding them over each other, with the additional complication that one set of co-ordinates can Ďwrap aroundí. I just have to remember which set of positions any one object is running against.

Friday May 29th

Iím rounding off the ship improvement system by putting in the bits where you have to get involved in financial matters. Yes, I have a new routine called Ďtaxmaní, the bit where you have to pay for things. This requires setting up some prices and co-ordinating the score displays for two players. All scores accumulated in the current phase are added into the funds for buying new parts. I also have to display the current funds on the screen during the buying phase, so I persuaded the score update routine to do that for me. It didnít seem to mind too much, I just pulled the wool over its eyes and it was none the wiser.

I need a monetary unit for all this. I reckon that Intergalactic credits have been used enough,so I may well stick to good old Alleykat Guineas. They have a certain air of quality about them, like Florins, Furlongs and British Thermal Units.

Monday June 1st

Since the ship is run on energy it seems logical that the Ďend of gameí condition is when you run out of the stuff. Then what happens? Well normally the ship might blow up. Iíve never quite understood why electrical equipment has stacks of gelignite bolted into it so that the slightest fault can cause a firework display. I expect it was thought of by the same person that decided that bombing fuel dumps in scramble miraculously fills your tanks with rocket fodder. Thatís the excuse, now the problem. Thereís no practical way of blowing up a enormous ship on the screen. It was suggested by a Welsh correspondent that the ship should glow red, white out, when fade away into billions of pieces as executed SO Spectacularly by the Earth in the Hitch-Hikerís Guide. Well, take away the billions of pieces and thatís what Iíve done.

I've also designed a game logo on Deluxe Paint last night which may or may not he used in the official artwork. Itís a full screen of logo so I canít really dolt in the C64, although Imay experiment with it for the tape loader.

Tuesday June 2nd

Finished off the graphics for the onboard systems and worked out how to run them all. Itís all very well having a system selection utility, but itís better if the systems actually do something. Iíve got to take into account that some units can be fitted in more than one position to double up the effect, shields and solar cells immediately spring to mind.

Wednesday June 3rd

I have some system graphics that I donít know exactly what to do with yet, but Iíve put in some systems such as solar cells, battery units for energy storage, shield generators and replenishers,energy to charge convertors, charge to energy convertors, remote locators, orbital proximity detectors and . . . it even makes tea!

Some orbirals are leaving the Universe and Iím not sure what to do about them, Iíve randomly repositioned them at present which was fairly stupid because I now donít know the polar vector to get to it.

Thursday June 4th

Spent the day at Hewsonís (does this imply that you did no work? - Ed).

Friday June 5th

Yesterday I half-inched some of John Cumrningís sprites that probably wonít get into Zynaps, which is a pity because theyíre really good. I had a good sift through them and as an experiment I changed all their colours to my three grey shades, and horrors of horrors, they all just died. This is why Iíve been having so much trouble designing sprites, my Ďsave a few cyciesí method has finally caught up with me. Using the three greys doesnít offer enough contrast. Iíll still use two greys but allow the third colour to be anything. I then proceeded to prove the point by designing an animated sequence of 22 sprites for the charge rejuvenator with no ensuing probiems. Why has it taken me so long to discover this? Answers on a postcard to (cont page 202)

My onboard energy systems donít seem to be working some of the time - oh goody, an intermittent bug, my favourite!

Monday June 8th

A nice up to date listing has appeared on my desk courtesy of the ST Printing Co. This is good for spotting all the howlers. First off, the Universe will be variable in size, AB has decreed it. It will expand as the game goes on to increase the difficulty level. Any particle leaving this Universe will be caught and shot (or marked up as dead anyway).

More coding chuckles next month chums. . .The intermittent system bug was caused by the last system on the ship not being processed, hence the sequence in which the systems were installed was causing the systems to fail in different ways. Any one system would work on its own, but they wouldnít all work together.

Iíve added some more systems and weapons to the development sequence, which shows the current units that are available and steps through them as the game progresses. In order to make testingquicker I have a cheat system which starts me off with plenty of money and all units are built instantly.

Iíve also rigged the game to start on any of the first eight levels, but Iím not going to tell anyone how to select a level - other than to say that it has nothing to do with the keyboard or joystick. I figure that this will be a reviewersís initiative test, letís see whoís paying attention.

I understand that a certain conversion from a certain Spectrum game by a certain Compunetter contains some Uridium sprites. I thought it was considered polite to seek permission for such a deed if this is indeed the case. Canít say as Iím particularly enthralled at having my graphics ripped off - originality it appears, has died.

Tuesday June 9th

Another rearrangement of my source code occurred to move some more completed routines into a dark cupboard where Iím bound to need them again. On assembling I was Left with something of a bug, the title screens were executing at breakneck speed, they decided not to bother with any of this 50 frames per second nonsense and go for about 300 instead. The explosions fair ripped out of the centre. A bit of exploration revealed that a routine had been corrupted by another routine running rogue. Lucky it didnít cause a disastrous corruption. Certain opcodes cause a total CPU shut down. After fixing the error I noticed that the docking sequence now takes much less CPU time, which is a pleasant surprise. Iíve no idea why, I expect isís magic.

Had to Laugh at a CCI article on Andrew Hewson which said of Uridium,í . . . too amazingly close, a Hewson rival commented, to a Sega coin-op that looked very like it but scrolled the other way.í

They were talking of Starforce which did indeed inspire the graphical style, but if they think the game is in any way similar then itís no wonder that their Uridium clones didnít sell. Apart from that it was very interesting, especially the picture of Cyborg Hewson, with a Manta
perched on his shoulder, beats a parrot any day!

Wednesday June 10th - Monday June 15th

A brief interlude is to occur, whereby AB has a few days relaxation at Alton Towers to escape the election.

Read the Preview

Read the Review

Get the Game

Continue Reading