Mental Procreation Part 6

Thursday May 14th, 1987

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, 1987

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 C128s). 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, 1987

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.

Tuesday May 19th, 1987

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 orbiting 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 non-busy 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, 1987

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. I would 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, 1987

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

Friday May 22nd, 1987

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, 1987

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, 1987

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, 1987

The remote movement system was completed by allowing 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 different 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, 1987

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, 1987

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 I may experiment with it for the tape loader.

Tuesday June 2nd, 1987

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, 1987

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 converters, charge to energy converters, remote locators, orbital proximity detectors and... it even makes tea!

Some orbitals 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, 1987

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

Friday June 5th, 1987

Yesterday I half-inched some of John Cumming’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 cycles’ 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 problems. 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, 1987

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).

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 testing quicker, 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, 1987

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, 1987

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

More coding chuckles next month chums...

Series Links

Part 1 / Part 2 / Part 3 / Part 4 / Part 5 / Part 6 / Part 7 / Part 8 / Preview / Review