Part 5

By Andrew Braybrook

Monday 13th April

It’s about time I had a proper pause mode in the game, so that I can return to the title screen, or quit to the monitor properly. All I have to do is round up the routines that ought to be left running in pause mode (colour updates for instance), and ensure that no routines involving object
update are called. As mentioned last month the sprite display system (or multi-plexor) expects new sprite positions to have been calculated every cycle to ensure smooth movement, During pause mode everything should stay still (partly so that magazines can take screen shots), so the easiest way to achieve this is not to call the movement routines. Trouble is, the sprite system then receives no information regarding sprite positions and shuts down, so they all disappear - not good.

Tuesday 14th April

The interrupt-driven sprite system was slightly amended to tell it to use the previous sprite positions if no new ones arrive. I can therefore now pause the game or carry out mega-long calculations in the knowledge that all the sprites will remain on screen. They may not move a lot, but it’s better than disappearing completely. Thus the pause mode is now implemented. Work has also continued on the control mode to allow the ship to be steered whilst operating its engines. The three parallax star-fields all move at different speeds and can be made to spin quite merrily. The ship’s speed will vary depending on configuration and engine mounted, but I don’t want any sluggish combinations. I hate games where the control mode prevents you from doing the job in hand.

I also enhanced the object handler to ignore non-existent objects rather than process them anyway. I used to have to hide them off-screen! I have created my first three classes of object:
1. dead objects.
2. fixed on-screen objects.
3. docking bay sprites that move away from the ship.

This completes the un-docking sequence so the main port slides off the screen as you leave it - it’s better than having it following you around. One design change now has the ship positioned on screen left to give a larger area in front of the tractor beam unit at the ship’s right.

Thursday 16th April

Put in some of the text for the title screen and high score table. With the giant-sized text and only two lines of characters available I shall only be able to print one line of the Hall of Fame at a time. This does have the advantage that I don’t have to fit the whole table on one screen. 1 will allow for ten entries for now, eight digits per score and three letters of initials. There’s not room on one line for a full name.

In preparation for the title screen I had to define some more characters: the joysticks and player symbols and a double width space. I also put in the colour and monochrome symbols, but I just remembered that I won’t be needing them because there won’t be a colour option this time - it isn’t necessary. Carefully planned painting and decorating will make the game work on either
type of TV.

I also put in the tractor beam firing mechanism which spits out a sort of cloud, but I don’t like the graphics I may change the whole routine to run that if the graphics require it. It’s no good just putting up with a routine because you sweated blood over it - if it doesn’t work then it has to go.

Tuesday 21st April

Put in some more text for the title screen and a high-score decode table. I may need to put in a save to disk routine and it’s best to keep the amount to be saved as small as possible - we all know how long the breeze block takes. As long as I can decode this data ready for screen printing fairly quickly I can put in ten entries quite happily, maybe even 20. I like full zero-suppression on scores, it gives a more professional look - better than hundreds of leading zeroes. After all, calculators stopped displaying leading zeroes soon after the Sinclair Cambridge, and that was back in the 14th Century!

I’ve also put in the redocking sequence except that the docking bay sprites that scrolled off so nicely arrive back on screen in a state of minor disarray. Well, all right - a complete shambles! This smells of an index to the individual parts getting corrupted somehow.

Wednesday 22nd April

Yesterday’s corrupted docking bay was caused by what we technically refer to as ‘raster overrun’. Put in layman’s terms that means ‘trying to do too much in too short a time’. I always wondered what would happen if I ran out of CPU time. This was caused by attempting to fade out the grids while running 21 sprites. I don’t actually need to do this as the sprites are held offscreen anyway, so I just set them up after the fade-in instead of before.

Tried putting in larger front-layer stars, but they looked too square. Changed the tractor beam to be more of a Defender-type laser. This required a total rewrite of the firing routine but it looks much better. The process involved required first working out the routine, testing it and finally tuning in - that is, slowing down some animation to alternate game cycles so that it is more obvious what is happening. I considered making it a continuous beam for repeated presses but it loses its effect. I rigged the control mode to fire the tractor beam from either the unit itself or from the engines section, which removes the necessity to keep running across the ship all the time.

I also had to increase the time taken to initiate the dematerialisation, as it was triggering too easily by accident. There’s nothing worse than dematerialising to another part of the universe just as you are nipping out for a cuppa. There are quite a number of functions allowed to the joystick while in the engine section, about the same as in Paradroid (move, transfer and fire).

Thursday 23rd April

Did some sprites for the photon weaponry. I think I’ll use three different brightnesses or colours and a number of different sizes and sound effects for them. This will enhance the difference between the weapons system. The enemy will be using similar weaponry.

To implement the weapons I need to set them up on the ship, so I’ve been working out what sort of a system I need to select new lumps for the ship. I’ll need an installation system, a ‘commission parts to be built’ system, and a ‘scrap existing parts’ system.

Monday 27th April

Started putting in the self-fired weaponry. There are three stages of initialisation to co-ordinate. First, the original ship layout set-up which decides what weapons are available, then the individual gun details have to be accessed when the weapon is activated, and finally the actual firing of the weapon to initiate a bullet. This caused some confusion as the chances of a game still working is inversely proportional to the number of instructions added. So I decided to forego the first stage of weapon set-up, as this can be rigged to work using the monitor.

Had a long duel with the assembler again when it decided that I wasn’t allowed to modify some code at a Procedure Name. All subsequent labels were apparently not in the same places on the second pass. How does it know? And why is it looking anyway? ST and I decided that the assembler is suffering from bad programming. I put in a second label at the same place as the first and now it’s happy. I reckon that will probably earn the assembler the Mickey Mouse award for April.

Tried out the weapons system. Bit of space station drifted out of the guns in a fairly random direction. Two different guns produced different effects . . . all wrong, but still . . . Decided that it’s time to print off a few routines for reference. Going grey waiting for printout.

Tuesday 28th April

Fixed the bugs in the bullet routine, It’s much easier when there’s a listing in front of you. The sequential firing gun is a bit of a disappointment - it works so well on the title screen, releasing particles one or two cycles apart in a circular motion. . . but the simultaneous firing makes up for it. Four or eight bullets released in a ring for mucho devastation.

By dinner-time the fundamental flaw had reared its ugly head. The control mode is basically unwieldy and generally all-round difficult to use. A quick pint down at The Chequers soon sorted this out. The problem was that controlling a weapon system means leaving the engine section (‘Och Cap’n’). Thus you’re left as a sitting duck on the screen just hitting fire for all you’re worth, with no means of movement, just relying on the meames walking into your line of fire - not particularly exciting, I trust you’ll agree.

The solution is to allow movement of the ship from any weapon system. This allows movement while not firing,and temporarily locks out movement while giving the enemy a pasting. The latter ensures that you don’t fire a joystick-directed bullet and immediately hare after it. By locking out the movement I only mean that it won’t allow alterations to the current direction, not that the ship will stop! This also frees up the functions on the engine unit, which is now only used to dematerialise back to the docking bay. I can also remove the fire tractor beam from the engine room routine which was attempting to cover up the inadequacies of the control mode.

The assembler definitely gets the April Mickey Mouse award for producing buckets of error messages on lines of perfectly good code, just for missing out a simple directive on a preceding line which it could have assumed to be present if it had any idea about user-friendliness. Even the COBOL compilers on the IBM mainframe could cope with this one, and they just love producing error messages like: ‘Full stop missing, assumed present’, followed rapidly by: ‘Superfluous full stop encountered, assumed not present!’

Remind me to write the next game in COBOL - it’s wonderful!

Wednesday 29th April

I put in the system block display routine today. There can be up to eight system blocks on the ship’s hull which carry out various functions and enhance the ships capabilities. There’s a twirly energy display and a current charge indicator. This routine also handles system block explosion animation, and runs at one frame every four cycles. So, by doing the animation on cycles based on the block number, it won’t have to run more than two explosions at once, It doesn’t seem to eat much CPU time anyway. If I ran it on interrupts it wouldn’t take any time at all because as every programmer knows, the way to save CPU time is to run everything on interrupt. This takes no time at all because interrupts are free. As soon as an IRQ is detected the CPU immediately switches to 20 GigaHertz mode. Only kidding . . . I'm just bored of people telling me that they ‘run the scrolling on interrupts’, or ‘poll the joystick on interrupts’ - it means nothing but it sounds impressive.

Back to the system blocks . . . they can have different colours, which requires colour RAM update,so the addresses of these have to be noted by a previously executed routine which setup the ship’s data. Colour RAM and screen RAM locations are mathematically related, and the assembler is awfully good at subtraction so this is no problem.

I had to optimise the grid fade-out routine to make it run faster, the docking sequence was running out of time, as indicated by my coloured order stripes. By optimise I mean fiddle it to execute quicker, which usually involves doubling the amount of code or using self-modifying code or both! I wish to admit here and now that selfmodifying code is disgusting and very difficult to debug, but a good assembler makes mistakes less likely. There’s nothing like a good assembler, and my assembler is nothing like a good assembler!

Rounded off the day by amending the sprite editor. It has a really . . . what’s the word . . unusual’ selection of default colours - white purple and cyan. It also uses the border to indicate which colour you’re painting with. This is rather silly, as a bright border completely alters the onscreen colours. These problems were fairly easy to solve as they all use the VIC video registers, so I just had to look for where it set the border colour and tell it to use black. The editor also has an annoying habit of printing in black, regardless of background colour. On a black background this is no use to man or beast - hack!

Friday 1st May

Started putting in the weapon and system selection routine which includes total ship replacement, commissioning, installing and scrapping of weapons and systems. I will need a means of regulating real time so that units can’t be commissioned quickly by cheating. The selection mechanism must cross-check various lists of parts available, with parts being built and spaces on the ship to fit all these goodies.

I got out the Paradroid listing to see how the console logging-on routines worked. Morpheus will be allowing updating of data, so it must be done carefully. Maybe it should just produce update records for the overnight batch to run?

I’ll confine all input to joystick only, and without an on-screen pointer. Although I am more sympathetic to mice and icons these days, there’s a time and place for everything. I wouldn’t use them just because they’re fashionable - they must be functional.

I’ve got it displaying the right headings so far, and for most of the categories it studies the appropriate data and reports whether there are systems or weapons available or present. It’s taken me a long time to figure out how to clear the sprites from the previous screen. After all the trouble with them disappearing when there wasn’t time to update them, now I can’t get rid of them! Even brute force and ignorance didn’t work the first time. Got rid of them in the end though - I’ll not be outwitted by a couple of sprites.

Tuesday 5th May

Chief test pilot and critic Robert Orchard had his first look, the atmosphere was not entirely unlike a Del Monte advert. De Man from Del Monte, he say: ‘control mode eez not working wery well.’

We also decided that the ship is too wide. Suggestions of allowing it to flip onto its side to fit through narrow gaps were severely dealt with. The weapons are too near the edge to see the full effect, and meanies approaching from the top do not give enough warning.

So today is shrink the ship day. I removed the connecting tunnel to the weapon stations and cut down their width. The only reason they were so big to start with was to allow me to separate the harsh white highlight along the top edge from the - coloured weapon ports. In the event I made the weapons ports white as well so I can combine the two in the same graphics space. A full-width ship is now reduced to 13 characters high from 19. It looks a little more streamlined now. One of the effects was that the ship passed over the grid, which it doesn’t do in its present form, as it doesn’t reach. I moved the grids in slightly to restore that effect. This made the docking port sprites look overly large so I cut them down too. I had wanted to reduce the number of sprites onscreen anyway. The game has to run on an NTSC C64 as used in the good ole US of A. Their C64s run about 16% slower on raster-synchronised games because their TV sets have to spit out 60 frames per second as opposed to our 50. Offset by this is the fact that their C64s actually run slightly faster (not a lot of people know that). Thus everything I run in the game for the European version has to have 16% spare time at least. I can use that time for increasing sundry items like the number of background stars, anything that can be altered once the game has loaded in and had a chance to sniff around and adjust to its surroundings.

I’ve also been tuning up the control mode. It’s now a maze of delays and decisions, all in an attempt to make it transparent to the player. I rigged the weapons to remember the last-fired direction to reduce joystick-bashing. It also helps to differentiate between the functions of firing or leaving the weapon. I sometimes wonder whether I should keep a badly tuned version around to emphasise the fact that the game has actually been tuned up properly.

I managed to wreck the starfield completely in an attempt to improve its randomness - all the stars went and hid off-screen! Further adjustments put all to rights, so now the stars are tied to the screen with no extra off-screen areas - Any star leaving on the left will arrive on the right, but at a different height. Similarly, stars are re-shuffled vertically. The only purpose of the starfield is to give an indication of speed and direction, which it does admirably. Having done this I can reduce the number of on-screen stars from 30 to 18 and it still looks like the original number.

ST and I have devised the ultimate cheat mode to incorporate. The most comprehensive POKE of all time. Just hit any key on the keyboard, the score will set to all nine and it will print ‘GAME OVER’. Just what is the point of an infinite lives POKE? The game is supposed to be challenging entertainment, not a boring wander through the graphics. If you want graphics, go and watch a film. It’s not winning that counts, it’s how you play the game.

Wednesday 6th May

Adjusted the starfield again to produce more distant particles and less close ones. This should enhance the effect of depth. I couldn’t really spot the difference, but at least I feel better knowing that it’s doing it properly.

I’ve put in the hull selection system but left out the bit where I have to pay for it. This makes the testing easier. The actual gameplay mechanism just gets in the way of program debugging.

Thursday 7th May

Put in some more code for upgrading the ship, namely selection, installation and scrapping of on-board systems. This appears to be working after a fashion. It did hiccup a couple of times and actually crashed the machine, something that rarely happens these days.

Eventually disaster struck. I filled up the 384K RAM disk on the Opus with assembler files, so the marvellous assembler just quietly gives up. It doesn’t actually report an error that it couldn’t finish writing a file, it waits until the next stage falls over when it unexpectedly reaches the end of the file. A massive re-organisation followed to split the main code into two smaller lumps. This involved isolating the code that is unlikely to change from the stuff that I’m still working on. Of course, saying that a piece of code is finished is a guarantee that it’ll need changing tomorrow at the latest, but it’s time to be brave. This makes the assembly time shorter as well - it was getting boring, taking over two minutes.

Having a lot of trouble linking the two modules together. All my routines have gone undefined, even though I can see them in front of me. Come seven in the evening, ST and I suss out what it is in order to not have to key in all the routine names to make them known to other modules you can just put ‘ALLPUBLIC’ which says that all the names encountered will be made available. However, this marvellous option doesn’t pick up procedure names, which is what most of my routines are. Apparently sometimes procedure names are labels, and sometimes they’re not. You can JUMP forwards to them but you can’t forward reference writes to them. You can make them PUBLIC by naming them one by one, but not by declaring them public all at once. This makes the Avocet AVMAC65 assembler a dead-cert for the May Mickey Mouse Award, the first to hold it for two months in a row. I can’t see anything beating this!

Friday 8th May

This scrap weapon facility is causing an embarassment. it’s elevated itself to a ‘scrap whole program’ facility! I’m not entirely sure why this is, I’ll need to look at a listing.

Meantime the select system facility requires that I display an individual system. I can only display eight at once and some configurations require that I display nine on screen, so I’ll have to convert the character data into sprite data. The way I’ve organised it requires colour changes by adding one to each bit pair in the byte with no overflow, for the multi-colour data. Rather than painstakingly separate each bit pair in turn, I worked out the logical operations to achieve this in one go.

Andrew Hewson came along to discuss business and declared Morpheus to be ‘Eccentric’. I’ve no idea whether that’s good or bad!

Monday 11th May

Discovery of the day: my new programmer’s calculator has a delete key on it, so no longer do you have to re-key the whole ten-digit number if you make a mistake - brilliant. How come it’s taken this long?

Mr Penn himself rolled up yesterday with Mr Liddon but I didn’t have Morpheus at home so they didn’t see it. It can be very dangerous showing the press very early versions, even if he was on holiday. The freshness of a game wears off, I never did get my Gold Medal for Uridiwn! Nevertheless Mr Penn suggested a recoiling gun at the front, while Mr Liddon suggested finding some food! I’m all in favour of recoiling guns, so 20 minutes of updating the code and the recoil mechanism is in and working. It’s quite a small gun anyway but it comes under the ‘nice touch’ heading.

Found the bugs in the install and scrap sections. I was tying myself in knots trying to ensure that the right messages appear on screen, supressing later ones in favour of important early ones. This resulted in sometimes not resetting internal pointers, so having installed the last weapon it still thought there was another one left, so it picked up rogue data and fell base over apex.

Tuesday 12th May

Finally completed the set of ship enhancement features. The game now allows all functions to be used without having to fiddle anything. I haven’t yet put any restrictions on commissioning new ship parts. If I put in the bit where you have to pay for them, I’ll need some money, which is derived from points scored - but there’s no way of scoring points at the moment!

I keep running out of RAM disk space again on the Opus, it’s just not big enough for a growing program, and certainly not enough for a grossly inefficient assembler.

I had to move the text bars further apart to allow more of the weapons stations to be visible.

In order to control the time taken for units to be built, the game notes how long you’ve been flying the ship. Pausing will stop the clock, so it’s no good leaving it paused overnight to get the extra weapons built! I’m just wondering what units of time I should use - days I suppose. I’d rather use something more mystical, like the Dalek’s ‘Rels’ - they use them to measure everything: time, distance, energy, mass, the lot. It must make Dalek Physics lessons much shorter.

I’d just like to add my two penn’orth to the ‘which 16-bit machine should I buy to play games on?’ argument. Let’s get some facts sorted out.
1. There are as many arcade games out for the Amiga as for the ST, mainly due to the higher numbers of Amigas in the US. At the moment you just have to search harder to find the Amiga software.
2. The Amiga hardware was designed primarily by the designer of the Atari 8-bit hardware (Jay Miner, a very clever guy), and is aimed at doing all the things that games need to do, smooth scrolling, manipulating large graphic images quickly and producing high quality sounds.
3. The Atari ST contains just enough hardware to make it graphically superior to most 8-bits. It has a large colour palette, but cannot smooth scroll using hardware. The only smooth scrolling possible will thus be limited in colour, vertical only, on a small area or very s-l-o-w. Sonically it has a very old chip indeed, as used in the Amstrad CPCs and Spectrum 128s, not as powerful even as old SID.
4. Despite what Commodore still maintain, the Amiga chips were designed with games in mind and will be used as such. How much business software uses four voice stereo sound? Or smooth scrolling?

There will be some great games appearing on both machines, some already have, but anything the ST can do, the Amiga can do equally well, usually better. The reverse will never be true, provided programming standards are similar. In conclusion I would say that the Amiga to the ST is like the C64 to the Spectrum.

Wednesday 13th May

Added one or two new graphics to the set of onship systems which look quite nice. It’s difficult to come up witha whole set of graphics which all look different but have to blend in with the same surroundings, but I’m sure you don’t want to know about that I I’ve started to organise the ‘ecosystem’ within the game for the meanies. Each level will be played over two alternating phases with the ship able to commute between the two via the docking bay. I want to create different atomic-style structures of a central charged impenetrable nucleus surrounded by charged particles that have to be recharged by a chargecarrier that shuttles between them and the nucleus (phew). Each particle decays with time and must be revisited periodically. The main ship gun, nicknamed the toothpaste tube, can suck out and store this charge. This may cause other things to occur, and you may not be the only one trying to steal the charge!

Richard Groome paid us a visit and he may be able to help us with a little surprise on the music front, we’ll have to do some feasibility studies, but we’re hopeful. Can’t say any more about that yet, very hush-hush, top secret and all that.

To Be Continued...