Mental Procreation Part 7

Monday 15th June, 1987

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

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

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

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

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

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

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.

Also 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 for the 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, 1987

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.

I’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 before it 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, 1987

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

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

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

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

First day of overtime, I was scheduled to complete Morpheus yesterday, but I’ve missed a number of days work for one reason or another and 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, 1987

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.

Continued 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 different 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 deliberately lengthened to give the loader time! This type of loader is loading data by getting the cassette to cause interrupts rather like Novaload does. This leaves about 50% of the CPU power to the main games and no interrupt capabilities. You could get more CPU 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. Searching 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, 1987

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

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

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 periods of travelling to another orbital. Finding the orbital is a bit haphazard. There area number of systems to aid 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, 1987

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 make a 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 16 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, 1987

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

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

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.

PIC: The 16 systems which can be incorporated into the ship.
PIC: The Morpheus logo as it appears in the game.
PIC: The remote droid and landing pad.
PIC: My interpretation of the logo - now I ask you, does that look like a row of coffins?

Series Links

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