Part 7

By Andrew Braybrook


Monday 15th June

ST had been trying to cure our data transmission problems last week. Itís now quite rare that we successfully download a file for testing, and theyíre getting quite large so the chances of getting an error has increased. By keying in a quick analysing routine we discovered that sometimes the Opus doesnít switch its data-ready signal off very cleanly, so much so that it causes a second trigger. This only occurs briefly, but long enough to fool the C64 that another byte of data is ready. Therefore our receiving program reads in the supposed new data, and when it comes to check-for-errors time it discovers that someone has madea boo-boo. By checking the CIA latch a second time after the data is accepted, and ignoring it we have alleviated these Ďghostí images. No errors have occurred in the ten or so downloads since.

Iíve fixed the bug that allowed the ship to pass through charge orbitals in two directions, and Iím reasonably happy that everything is working correctly. Iíve put in an extra piece of information at the beginning of each phrase which shows the current level and what Iíll call the current Ďtimesliceí. This is an indication of real time taken playing games, which is used to to derive the effectiveness of your weapons against the enemy. A weapon built in timeslice ten will be fairly ineffective by timeslice 20. Each timeslice will represent about two minutes of play.

Tuesday 16th June

Half day today. Got to grips with the compacted sprites and organised the ones that Iíd drawn already. I then noticed that that many of the images were symmetrical top to bottom. This led me to try further compaction by only keeping the top half, and then reflecting the required images prior to use. The routine turned out to be quite small, and certainly simpler than reflecting left to right, which I had to do in Paradroid. Unfortunately the decompaction system went slightly wrong when the Ďit was written so long ago itís bound to workí sprite header routine failed miserably! It was supposed to nip through the compacted sprites and note where each one starts, which saves me either reading through them all every time I want one header, or holding all the headers in a table all the time. However, it managed to miscount so it got out of step with the actual images, so by the time the individual sprite decompacter got there it was picking up the wrong data completely.

Wednesday 17th June

Iíve never written one before but it suddenly dawned on me that an automatic sprite animation system would be a good idea. A lot of space has been wasted in previous programs by objects each having their own bit of animation code, like Ďevery fourth cycle add one to the sprite frame and if itís bigger than ĎXí then subtract seven from it.í This can be done on a similar basis to the automatic sprite colour system, which relies on any one sprite being used for one purpose only. This may require some duplicate sprites, but since theyíre all cornpacted I donít mind.

I had a discussion at the CBM show on Sunday about the merits or otherwise of high-ish level languages - mainly C. Personally I think itís a pig of a language, as it is totally wrapped up in its own syntax structures. It has two ways of specifying equals, either Ď=Ď or Ď= =Ď depending on whether itís in the equivalent of a BASIC LET or IF. Every other language Iíve come across manages with only one symbol, they know which one youíre talking about by the context of the line. C also makes you put curly brackets round multiple statements within an IF-ELSE structure, something which COBOL achieves by use of nothing more than a carefully placed full stop.

Thursday 18th June

The sprite animation system is playing up. Objects disappear, flash on and off and go through the wrong sequences - anything to get out of working properly. I checked the object handlers and the animation routine, found a fewerrors but all to no avail. It took until 4:30 to find the cock-up. It was the animation instructions that were wrong. Apparently eight plus three is not 83 at all! This causes sprite sequences to jump about wildly, sometimes picking Ďsuicide framesí, causing
objects to automatically delete themselves on the final frame of explosions etc. I thought it would be tidier if objects cleared themselves away.

Friday 19th June

Spent much of the day on the sprite editor. I want a design for the charge supervisors, which will travel around looking for trouble - that is, as soon as an orbital is attacked they will head towards it. However all I managed to design were a few more roamers.

I havenít had any transmission problems at all this week so it looks as if we have correctly diagnosed the fault as being cheap and untidy electronics at the PC end.

Got a rough draft of the artwork from Hewsonís today. Theyíve been looking at my Amiga artwork, so their artwork is quite closely related to what Iím intending for the game. Iím reasonably impressed by the layout, but they didnít use my logo, just some old Paradroid-style lettering. They said my logo looked like a row of coffins in space.

Monday 22nd June

Tidied up a number of loose ends and fixed all known bugs. I had to make the Universe slightly bigger as some particles were intent on leaving it. I also reduced the size of the fastest polar speeds, the fastest bullets were just flashes across the screen, not very practical for collision detection.

Went on a programmerís fitness course at the weekend,which involved transferring graphics from the C64 (downstairs) to the Amiga (upstairs) for enlargement and enhancement. This involved memorising graphics on the C64, racing upstairs, and redrawing them on the Amiga - I bet itís still faster than RS-232. the net result is that Iíve drawn the 16 system units in 32 glorious colours at double the size for inclusion in an accompanying booklet.

Tuesday 23rd June

Toyed with the smart bomb weapon to get it to work. Itíll be a medium-term weapon rather than a once-off blast. Itíll start off at maximum strength and decay to zero after firing, so itíll affect meanies arriving on the screen. Also it wonít necessarily kill meanies outright, especially if the weapon is getting old.

The 16 systems which can be incorporated into the shipAlso put in the collision detection for my own bullets. Having a maximum of eight, and there being eight bits in a byte makes things quite simple. The bullets are small but are moving quite fast, up to eight pixels per move, so character accuracy is all that is required. Each meanie will check the character position under its centre for the presence of a bullet. Iím not using sprite to sprite hardware collision detection for a number of reasons, mainly that it isnít all that helpful in multiple collisions knowing that sprites one, two, six and seven have collided somewhere. Which one has collided with which, or have they all met in the middle? Many collisions are irrelevant and neednít be checked.

I also worked out all the data forthe weapons development table, all 57 weapons. Each has its own firing type, bullet fired, reload time, construction time, graphic number, and cost to build. Any volunteers to check that theyíre all present and correct?

Wednesday 24th June

Been doing some random spot checks on the weapons. Iíd managed to ruin the sequential fire system. It fired one bullet, waited for ages and then released the next seven in quick succession. Apparently it had waited for the gun to reload before firing the remaining bullets.

The Morpheus logo as it appears in the gameIíve started putting in all the bits that nick the energy, including collisions with orbitals, and firing the guns. Yes, the guns take energy to fire, lifeís like that. They donít take very much though, without any energy replenishing systems the ship is still good for some 1500 bullets. This will become virtually unlimited once a solar cell or other device has been installed.

Iíve also improved the smart bomb system. It kept firing by accident as I left the unit, which isnít damaging with normal guns, but the smart bomb can drain up to a fifth of the total energy so something must be done. It requires a delay beforeit fires, so l decided to use this delay properly, not just a delay for delayís sake. It counts a timer upwards and will fire when it reaches the bombís preset value. However, as it counts up, it checks itself against the current energy level. On firing it will use up the amount of energy equal to the timer, so if there is insufficient energy available during build-up it will abort firing. The later smart bombs will build up quicker and thus useless energy - theyíll reload quicker too. Iíll use sonics to show this build-up and itíll be possible to abort firing at any time.

Thursday 25th June

Some of the charge orbitals were appearing a bit late on the screen. It seems that updating one every 32 cycles wasnít quite enough so líve doubled them up so that two are updated every
16 cycles. This seems to be running everything more smoothly, except that now theyíre all decaying twice as fast, This means that I have less time to find them. This wonít be
the case in the finished game as the charger rejuenator will be visiting all the orbitals in turn, but heís not coded up yet. Itís quite difficult to find the orbitals at the moment, so I rigged up one of the systems to glow when thereís one nearby. This should be useful on later levels.

Iíve enhanced the shieldís generators so they show their current status with colour, and you can also buy another systern which shows the current status of the whole shipís shields. I have three remaining systems that donít have a current purpose.

For the first time I can now score points to earn money to buy weapons and systems. Iíve currently got a cheat version that gives me buckets of money anyway and allows me to build any of the weapons instantly. The systems donít decay with time, as itís really the meanieís growing immunity to the weapons which causes the weapons to fail, but the systems can be blown up if the shields collapse.

Friday 26th June

Put in a new system device - a direction to nucleus indicator. This should help navigation tremendously. Begin an eight directional indicator, I thought Iíd borrow a calculation routine from Paradroid that decides which laser bolt frames to use. One problem though - ST and I realised that it didnít work... well not quite anyway. We also realised that it only has to calculate four directions, it has noticed to differentiate between up and down as the bolts are reversible. We therefore decided to work it all out from first principles.

At first our marvellous indicator was incapable of showing diagonals. We had used the line equations the wrong way round when working out whether a point is above or below 2X = Y and 2Y = X. The direction finder could turn out to be useful, so Iíve made it a separate routine from the indicator so that I can use it later for other functions.

For better between-game continuity I think Iíll rig it such that upon demise the playerís funds remain for the next game. This will allow a quicker building up of a new ship.

Monday 29th June

Put in some close manoeuvring to stop the ship if itís moving very slowly. This helps with close positioning of the ship and also lessens the times when stars are moving very slowly. It took me a while so suss out that this was not working in the engines section, as it has a quite get-out clause normally to check for dematerialisation.

I put in a toplimit for the amount of money that can be carried forward to the next game. I can just see some idiots playing level one and then quitting for half the night to build up a mega-fortune for one game. Tough luck, cheats!

Over the weekend I spotted a double star flitting between two places on the screen at high speed. Iíve been running the game for a while hoping to reproduce this error so that I can investigate, but will it happen again? No chance!

Actually got recognised in Tescoís, so to ensure that l donít get run over by a shopping trolley next time, hi to Rob and John!

Tuesday 30th June

Put down on paper all the ideas for meanie movement and initiation. This is the last big push to get the game in a playable state, the rest will just be tuning up and adding some frills. Most meanies will be generated as a result of altering the change of an orbital. I shall start them off on preset launch patterns and then switch them over to manual control where I hope they will behave with a bit of character. I want a more varied spread of speeds through the levels, and meanies will be able to generate bullets or other meanies.

Bought Slapfight last Saturday. Great game in the arcades so I had high hopes of a good game. Itís been converted very well, good playability and visuals, well done, but what about all the program refinements? No pause mode, no quit game, and to cap it all it uses sprites in the top border for the score. Well l canít see the score on my TV set, itís off the top. Black mark for that one, why is it up so high?

Wednesday 1st July


First day of overtime, I was scheduled to complete Morpheus yesterday, but Iíve missed a number of days work for one reason oranotherand I really want this game to be something special - so itíll come out when itís ready. This is an artistic expression, not something off a production line.

Started coding the meanie initiator and control routines. I didnít feel like coding a lot of routines up again slightly differently, so I decided to adapt the ones that already run the bullets and the remote. This saves code and simplifies things (famous last words).

Sure enough I ended up with no bullets and an invisible remote. Havenít the faintest idea why. The objects are getting initiated in the correct places, they just die immediately. Last time anything did that it was the animatorís fault, but not this time.

Thursday 2nd July

Found the no-bullets bug last night by staring at the listing. Apparently someone had put on in the wrong order. Wait until I find out who that was. The disappearing remote took a while longer, but was another typing error. Iíd taken the Y co-ordinate of the remoteís position, added the Y movement and then stuffed the result in the X co-ordinate by mistake. When youíre convinced that a piece of code at working you just read what you want to see, not whatís actually there.

The remote droid and landing padContinued to write the bullet and meanie initiator and handlers. Since meanies can fire other meanies instead of bullets, I can have a whole sequence of meanies. They have differrent conditions for generating others, randomly, only when wounded, or only when killed. Generally meanies will only take one shot to kill, but outdated weapons will be less effective. Injured meanies will have different flight pasterns, usually wild retreat, but slightly scratched ones may well get vicious. The smart bomb should ha can interesting effect on them, especially an outdated one.

Was interested so read in this monthís ZZAP! that multiloads are okay if they load the next level while youíre playing the current one , even if itís deliberatly lengthened to give the loader time! This type of loader is loading data by getting the cassette to cause interrupts rather like Novaloed docs. This leaves about 50% of the CPU power to the main games and no interrupt capabilities. You could get more CFU steam up by slowing down the loader, and you could try to split the screen using NMIs, but I suspect that screen splitting would be impractical as it is heavily tied into the progress of the raster, which stops for no man. So this type of loader is fine for games with no raster splitting and little CPU usage, but donít expect that sort of thing in Uridium PIus 2 and Alleykatís Revenge which would use all available CPU wellie most of the time, This said, there are moments in games where very little is happening, for example when ĎPlayer Readyí messages appear, so short bursts of I/O are possible. Seaching tapes is not really practical though, and waiting for CBM disk I/O is like watching paint dry. I think the short-term answer is better data compaction. I could have loaded each Uridium dreadnought from disk into its 9K buffer, each is 512 characters wide by 17 deep, but by compacting this data I could specify each one in about 600 bytes. Thus I could fit 16 layouts into about 12K with overheads. If that were all decompacted at once it would take 144K, more than two C64s full!

Many multi-load games donít bother to compact data like background pictures, because they have already accepted that disk I/O is inevitable, so whatís another ten seconds of load time, if they donít have to spend anytime working out how to get the best use from data. If they thought about it more they could cut multi-load I/O times down by 75%, but the perceived value of a game that loads from disk is much higher because you think youíre getting more for your money.

Friday 3rd July

Finished off the meanie and bullet handlers today, now all Iíve got to do is get them to work. I want the bullets to hit the shields and explode if the shields can take the hit, otherwise the bullets will skid across the surface of the ship doing more damage. I also want the meanies to bounce off the ship in a realistic manner, or get squashed against it if they canít get out of the way, such is the power of a large ship.

Realistic bouncing is always a problem, because although itís fairly easy to detect when the ship has been hit, it is not so easy to decide what direction to bounce off at. I got round this by defining a perpendicular direction from the face of each ship character. Any meanie approaching a block can be reflected across this perpendicular axis and pushed away. I also enhanced this by adding that if a meanie approaches from an unusual angle it will be allowed free passage.

Fired up the game alter a multitude of assembly errorshad been fixed. All was going well until I fired at a charge orbital which is supposed to release from one to eight meanies or bullets. This however did not happen. What did happen is that the game totally froze. Now Iíll have to take out the routines one by one to find out which one caused it. This is always a problem when you add lots of inter-dependent routines at once. The code seems intact, it restarts okay after reset without reloading any files. There may well be an infinite loop coded in there,

Monday 6th July

There I was, checking all the routines for possible reasons why the machine locks up, and I came across a JSR $0000, a call to a routine at the 6510 data direction register? I think this could be the cause. The jolly old linker has left a gap in the code because it didnít know what the real address was supposed to be. It didnít bother to tell me that it didnít know because ever since day one it has whinged about not being given a transfer address. I donít even know what one of them is. Iíd gladly let it have one but I donít know how to tell it either. The manual doesnít mention transfer addresses. I got so fed up with it telling me to give a transfer address that I told it to keep messages like that to itself, so it kept two unresolved labels to itself too. This is altogether more serious, it works without a transfer address, but it sure as Hell wonít work with unresolved labels in it.

Tuesday 7th July

Debugged most of the meanie routines, and now Iíve got enough data in the game to generate several different types in a number of different ways. They are firing flak at me which can blow up onboard systems and damage the ship. Their manual movement patterns are switching in, but arenít yet positive enough to force them to move in any particular way, itís just a question of line adjustment.

The main problem that weíve come across is that the game consists of moments of high activity followed by longer periodsof travelling to another orbital. Finding theorbital is a bit haphazard. There area number of systems toaid navigation, but I donít want to make them all available at the beginning. Iíve come to the conclusion that I need a medium range radar display.

Wednesday 8th July

I didnít want to put a radar screen in, but if the game requires one then it shall have it. Now, where shall I put it? I canít incorporate it into the main ship design, itís too big. I refuse to make it a sprite or two and bung it in the top border. Iíll hang it below the game logo. I drew some scales round the edge to makea border for it but it looked rather sketchy. The actual coding didnít take very long but on firing up it didnít work. Not a radar plot in sight. Upon moving about I could occasionally get a dot to momentarily appear and that was all. I studied the code for ages and there was no way at all that it could possibly fail, but it did.

By 6.30 I was getting very cross indeed, the C128 nearly got thrown out of the window. It then suddenly dawned on me what I had done. Since I am plotting two orbitals every cycle it takes 16 cycles to prepare all their positions. I then spent the next 16 cycles copying one row of the radar to the screen, so this also takes 16 cycles to complete. This copying process is spread over some time to avoid doing time-consuming operations all at once - it also carries out the function of clearing out the old radar images once they have been copied to the screen. All this was jammed into the one routine, the first 16 cycles prepare the radar, the next l6 copy it to the screen. Now the problem is that this routine is called twice each cycle, so it copies the radar across, clears the old image, copies the now cleared image across again and finally clears it again. The setup needs to be done twice, but the copying and clearing must only be done once. How could I be so stupid? Donít answer that.

Thursday 9th July

Changed the radar surround to a more solid border and built it up into more of a crest to fill it out. ST suggested that it be a different colour from space to distinguish it from the background so we eventually decided on blue. It looks quite neat now and serves its purpose very well.

Paul Hughes dropped by to discuss some new anti-cartridge techniques and loader. He left his Koalapad with me as I intend to use a bit-map picture as a loading screen, hopefully for the disk and tape version. Iíve done a mock-up on the Amiga-beast and it all looks feasible, trouble is I donít know how to use the Koalapad. Iíve tried turning it upside down and rolling it about on the table but I donít have big enough area.

Friday 10th July

Spent much of the day thinking about how to run the charge rejuvenators, the ships that periodically ferry charge from the central nucleus to the orbitals to counteract their decay. This involves getting the craft to the orbital (easy), carefully driving round it (not so easy) and finally docking with it from above (difficult). As the orbitals are positioned in a circle or other pattern around the nucleus then some are easy to approach from above, others are much harder and require more complex guidance.

Iíve changed my mind about the charge supervisors, apart from deciding that l only need one at a time. Iíll make it appear in the distance and slowly approach to use the 3D depth effect a bit more. Itíll appear after a while around any attacked orbital.

Monday 13th July

Put in some enhancements that Iíd thought of over the last couple of days. I had to reduce the number of active meanies to six as they are eating up the CPU time. This isnít too much of a problem as Iíve also thought of a way of keeping them on screen without them crashing into the ship, they now run circles round it like Nigel Mansell on Silverstone.

I put in the code to run the rejuvenator, and after teaching them a bit of basic navigation they can now find their way from the nucleus to any of the orbital. They have to move quite slowly as they arrive, so that they can find their target accurately. Then I reveal my coup-de-grace, the 16 frame animation sequence to drop their charge and replenish the orbital.

Iíll have to write the game instructions out soon, Iíve already done the page numbers, now all I have to do is fill in the rest.

My interpretation of the logo - now I ask you, does that look like a row of coffins?


Read the Preview


Read the Review


Get the Game


Continue Reading