Part 4

By Andrew Braybrook

After four months of hard labour (ouch), ante-natal depression has reared its ugly head - and a huffy Andrew Braybrook relates his experiences with soft and hardware problems, piracy, and computer magazinesí reviews . . .

All in a rush (double ouch). . . a pensive moment, in which Andrew ponders on the meaning of life, the universe, and Hweson's deadlines. . .Wednesday 18th March

Got back from Chicago yesterday (place dropper) so itís back to Morpheus today. To compact my sprites and still be able to use them I have to write a de-compact sprite routine for the game, create the sprites I want and compact them in the first place. The de-compaction was easy, it just converts the data for one sprite into its real image. Since the images will be small, they will be a small clump of data with zeroes before and after it. I shall convert the leading zeroes to a one-byte count, and specify the size of the central data clump. This should convert each 64 byte sprite down to a more-manageable 15 or so - quite a saving.

Confession: I donít actually have any sprites for this system drawn up yet, Iíve not been able to draw anything that I regard as suitable. To get the data compacted I decided to write a BASIC program. It is easier to stop and can report errors in a more friendly fashion than just setting the border colour. Of course it will be a lot slower, but I wonít be running it too often - I can survive on test data for a long time.

Iíve been thinking about the sprite combining system and have decided that the X and Y reflections are unsuitable, as images will be drawn with light coming from one side so any reflection will cause an incorrect image. I will have to produce any reflected images myself.

The materialisation sequence is also causing some concern, but with some fancy raster splitting I may be able to draw up a second character set with a see-through ship and combine it with the current ship, then fade it out by converting the data to run through the grey shades.

Thursday 19th March

This dematerialisation thing is all round the wrong way. Iíve been looking at it from a cameraís point of view. The film director would watch the ship disappear from the docking bay, fade the picture, fade back in on another part of space, then rematerialise the ship. However I think I should be looking at this from the shipís viewpoint, or at least a remote camera associated with the ship. Thus the grid and stars would fade into nothing, leaving the ship, then the new stars would fade back in. My big problem has been separating the ship from the grid, I canít just split the screen since the ship can overlay the grid by up to two characters, and both are built from the same character set. Iíve sort of boxed myself into a corner by attempting to extend what Iím achieving on the C64. I do still have all the sprites free so I may be able to second them for some evil purpose.

I think the reason why there has been a spate of vertical or horizontal scrolling games is that those particular formats are best when using most of the C64s capabilities. Itís nice to extend the playing arena for the game, and the C64 hardware was designed to help this. In Morpheus Iím attempting not to use the smooth scrolling facilities which make up a large part of that distinctive Commodore look. I therefore have to push further in other departments to end up with a satisfying product, like the gameplay.

Iím not having much luck designing any suitable sprites. I had a quick thrash on the sprite editor but didnít produce anything particularly
inspiring. Sometimes it gets like that.

Friday 20th March

Day off.

Monday 23rd March

Tried to get some sprites drawn on the sprite editor. Iís difficult to visualise the game when you donít know what half the graphics look like. I remember Paradroid went through a stage like this. I still want to avoid the same old spaceship designs, and with a sixteen-frame animation system I ought to be able to come up with something . . .

After a few hours I gave up, having produced nothing of any use to man or beast. I brought in the Amiga today so I decided to fire up Deluxe Paint and try to draw some sprites with that. I enhanced my Morpheus mock-up picture for inspiration, but no sprites were forthcoming.

Boy Racer Braybrook poses alongside his Fiat X19. . .
Tuesday 24th March

Went to Hewsonís to discuss life, the Universe and everything. Apparently I have to finish Morpheus this year!

"ST was trying to communicate with extra-terrestrials by waving an RS-232 lead in a skywards direction, which was causing pretty patterns to appear on the Spectrum . . ."

Wednesday 25th March

A day of judgement. I think I may have an overall sprite style. I need to show which of two factions each sprite belongs to, its strength, and they have to be able to move in any direction without looking as if theyíre going backwards. The game scenario is also evolving. In the beginning there was a pretty star in the middle of nowhere. A small reaction in the heart of the star produced two split particles which split from the star in opposite directions. These each split into two and each one split again. These particles then begin to drift towards their respective partners, and when they meet, fireworks. Your mission Jim, should you choose to accept it, is to bring the particles together more gently by capturing particles from one charge centre and deploying them at the other. Two particles of equal but opposite charge will cancel each other out, but two like particles will combine and become stronger. lalso hope to introduce neutral charges and photons to upset the situation.

On the coding front Iím not happy with the star rotation, itís slow and heavy on CPU usage. Thereís enough work to do running 32 moving objects, so the star rotation is out. Iíve coded the grid fade-out routine which took all of 15 minutes to write as an existing routine was easily modified to carry out this task. Now I can fade our the multi-layered grid slowly or quickly, and while it is moving to choreograph the docking sequence using existing routines.

ST meanwhile, having written Amstrad Ranarama in two weeks flat, was trying to communicate with extra-terrestrials by waving an RS-232 lead in a skywards direction, which was causing pretty patterns to appear on the Spectrum. Why bother to build art interplanetary craft when you can use RS-232 ... Aaarrgh!

Thursday 26th March

Iíve actually managed to rustle up a few sprites hang out the flags! I needed an animation sequence to show two obiecis cancelling each other out, so I drew an implosion sequence which involves a circle of dots spiralling inwards, followed by a twinkle. This takes fourteen frames of animation in total. I also enhanced the docking bay sprites slightly and put them all together ready for inclusion in the game. Iím getting a better idea of memory usage now, so I can so I can put various chunks of data in their final places.

I then set up the colour table for the sprites that I have drawn, each sprite image always being the same colour. I can modify this table Ďin-flightí to cause glowing effects and such-like, so itís not too restricting, and saves me a lot of time not having to worry about getting the colours right during the game.

Weíre having minor equipment troubles, the 1570 needs a dab of glue as itís getting a bit tetchy, the 1541 wonít read anything, ST has blown up the C64 and the 1541 analyser disk has a read error unit! Iím also still trying to soak out the coffee from my Amiga keyboard which causes some keys to stick, so itís not been our day. ST is keying in the sound routine on the PC and will be making further enhancements to it, probably in a mixture of 6502 and Z80!

Friday 27th March

Started to sort out the game structure. The game will involve frequent returns so the docking bay for information updates and ship repairs. Rather than just obtain new units to bolt to the ship, I want to make it a little bit more realistic, by the player having to commission units to be built, cash in advance. This building may take a while, so you wonít get them immediately. This will require some part text, part graphics screens to supply information to the player. I feel some nifty raster splitting coming along as the VIC-lI chip already has its hands full running the sprite multiplexor. It will either mean the main-line program waiting for particular raster positions every 50th of a second, (requiring it to never get involved in any long routines), or a bit NMI use. I favour the latter as itís more flexible and doubles as a security against cartridges. Hackers wonít be able to remove the NMI code as it will be an integral part of the game. That should muck up "Supadupahackem MK 999 - the cartridge that reaks into absolutely everything up to the year 1997 and automatically mails 26 copies to your family and friends." And it still canít do Uridium Plus, chuckle.

I also wrote and keyed-in the data and code for the system to display any of the three basic ship layouts on screen, completed with chosen extra weapons and systems. Now that I can use local labels with the cross-assembler I donít have to wrack my brain coming up with six-letter unique names like RFLOP3, I can just put . . . LOOP everywhere. I bet Iíll regret it when I try to understand this code in a yearís time.

"My Amiga appears to be decaffeinated too!"

Monday 30th March

I had a long duel with the cross-assembler today, cross being the operative word. I wanted to do the equivalent of a GO TO DEPENDING ON using an assembler macro, which is basically a way of inventing your own assembler commands. The assembler however insisted on producing 27 error messages, all for one line, where I had to use this new command called JUMPY. No clues were given, just a bundle of error messages like "Labels not allowed here." Where, you stubborn goat of an assembler? Give me a clue. Finally we decided that the assembler has a bug in it as it doesnít evaluate parameters properly in a FOR-NEXT loop. Thus I had to key in the same thing nine times, twice. Thereís modern technology for you!

Some technical problems resolved, the 1570 only wonít read disks when the PC is switched on. Itís getting zapped by magnetic radiation. The solution? Always switch off the PC when loading from disk. Probably not, move the 1570 to pastures new. This means that I can screw the top back on it, as currently I have the cabriolet model 1570 Ghia for easy maintenance!

ST now thinks that the C64 that we sent for repair isnít blown up after all, it wouldnít load because the C2N had thrown a wobbly. Thatís now all crated up ready for repair. Wonder if theyíll find anything wrong with the C64? My Amiga appears to be de-caffeinated too!

As far as Morpheus is concerned I roughly know what the control mode is supposed to do, but Iím giving the player more freedom so Itís going to be a little more cumbersome to learn fully. I shall try to introduce the new features during the course of the game rather than have them all available at the start. The game has to be instantly accessible.

Tuesday 31st March

Tested the new routines to display the three con figurations of ship. I only noticed after a couple of tests that no ship at all had appeared. This was simply because I hadnít told it which of the three ships I wanted. I was lucky that it didnít crash as it had been reading random data, but unfortunately my routines tend to have plenty of Ďexit on errorí clauses to prevent such catastrophes. After correcting a couple of blocks with the wrong numbers in, I am now the proud owner of a rounded-metal ship construction kit.

ST and I had a discussion on whether I should set up the ship with the front facing left or right, I wanted it to be left as it would be different from most other games. Had you noticed that more games play facing right? For example: Scramble, Nemesis. I canít think of any that only play to the left. This is partly because we read things from left to right, our brains are more accustomed to the movement. If I set my default direction the other way round it may subconsciously jar with the brain, putting people off the game. So, even though my ship will move in all directions (not all at once, incidentally, unless you overheat the engines) I shall configure it to face to the right. This means that two of my thus far created eleven blocks are already redundant as they face left only, I guess some prototypes never make it. It does free up some more graphics space though.

"I hope I never get stuck in a lift with any miserable types who didnít find it amusing!"

Wednesday 1st April

Iíve got three different sized ships on screen and this morning I thought of another configuration, so that makes four, which is a nice number for a programmer to deal with. The system that ignores or displays extra weapons pods on the ship is also working. This system can also display the landing pad for the remote ship to be launched from.

The game can now display the docking bay of its own free will. I no longer have to set its variables up using the monitor. Itís all starting to fit together. I happened to notice that not many stars were being displayed in the bottom half of the screen. Upon checking I discovered a remnant from the rotating starfield days. A quick cut and thrust of the delete key and itís gone.

I also pottered about with the character graphics to design some new pieces for the ship, and keyed in polar to X-Y vector conversion table, 512 bytes of juicy hex to allow eight speeds in 32 directions. I should now be able to generate better circular movements.

I gather that some people have tried my little 6510 accelerator. Okay so it doesnít quite speed up the C64 to mega speeds but you have to laugh. It seems to have taken anything from fifteen minutes to two hours to key in depending on manual dexterity. Lucky I didnít pad it out too much, eh?

Itís interesting to study peopleís reaction to the hoax, one or two people were apparently very grumpy indeed, hurling abuse in all directions. I reckon that just shows the Human animal for what it is. Greed had set in at the thought of gaining extra CPU wellie for nothing and then it was snatched away. I hope I never get stuck in a lift with any miserable types who didnít find it amusing!

Thursday 2nd April

Designed some graphics for what Iíll call the system blocks. Each ship configuration can carry a number of these, two on the smallest ship, up to eight on the largest. These system blocks will be for additional Ďpassiveí systems on the ship, no weapons, but additional energy, charge holders, tractor beams and the like. These will be prime targets for the enemy and may be destroyed. Up to 32 system blocks are being budgeted for, each with its own colour scheme. The energy display block consists of eight frames of animation and its speed of rotation will show the ships energy. I will need a system to plot these blocks into the character set. Only eight blocks are needed on the biggest ship at four character a piece, So I have reserved 32 (that magic number again) characters for these, I couldnít afford the space for 32 different blocks in the character set as there are only 256 available, so plotting these on screen will involve updating the character set in-flight. I donít want to push the timing so Iíll have to devise a routine to plot explosion frames only on cycles where the energy display isnít being plotted. I may then have to queue up any further explosions although I donít think that too many explosions will occur at once.

"In about a four hundredths. of a second Iíll ring the fire bell and you go and change the character set. "

Friday 3rd April

I had wanted to display the starfield with the text character set for some time. The difficulty was that it required 48 star characters in both character sets. Having accepted this as a necessary overhead I wanted to use this fact to combine text and graphics on screen simultaneously. Not just a simple split screen but more integrated.

This involves raster splitting and created the dilemma mentioned earlier (27th March). I canít use full blown raster splitting for screen changes as the VIC chip is already using these. Thus I must try using the NMI time which is like an alarm clock that tips the bed over, ie: you do wake up immediately. I couldnít quite see how to use only one set of interrupt routines to run either a straight graphics screen or a mixed screen. I then worked out how much extra coding is required to split the screen, and itís quite minimal. So one set of interrupts runs all the time, but in graphicsonly mode the splitting just gets the same character set instead of a different one. The game has to function correctly in either mode anyway so itís no real overhead running a small quantity of unnecessary code all the time. Itís a case of by the time youíve worked out which function to carry out, you could have done them both anyway.

Of course the structured approach would be to just duplicate one and a half Kilobytes of code to create two interrupt systems and change one instruction, however, on a limited memory system this is not particularly practical. Anyway I implemented the NMI timer system which takes its cue form the top raster interrupt that sets the first sprites. This starts a timer which basically says:

"In about a four hundredths of a second Iíll ring the fire bell and you go and change the character set."

This routine then sets the timer for the next split, four times in all down the screen. This also has the beneficial side-effect that it screws up ALL cartridges, including the ones that claim to the contrary (they just donít test them on AlleyKat, Uridium Plus, Terra Cresta, etc).

"Sorry couldnít find them in the shop." Well, they were looking in the local greengrocers! Very exhaustive test I must say. My nameís Ben Elton, goodnight!

Monday 6th April

I found it quite disturbing to read one of Mr Mangramís replies in the May ZZAP! Rrap regarding reviews, which posed:

"Which would you prefer, an earlier black and white review . . . or a full colour review a whole month later?" This has been echoed by Commodore User recently claiming to be first with this review and first with that review.

Well, since Iím on the receiving end of the review I figure that having spent six months producing a game, it deserves an accurate review, not to be treated like another lump of nothing on a production line. How can it possibly get an accurate review if the reviewers are simply trying to he first to get to print?

The game should be played on and off for a couple of weeks, how else can you test lastability? Surely youíd rather read an accurate appraisal of a game, so what if it is a month later than a bad one. If youíre like me you wait for all the reviews anyway, so whoever got the review out first will be forgotten!

Also, since the magazines get early review copies of the game then the review could well appear before the game is available anyway. That just frustrates you, upsets the shops and wastes everybodyís time. Applying this to Morpheus, I hope to finish it by the end of June, but it is unlikely to be released before September as the packaging and advertising will then go into full swing.

I think itís ultimately up to you, the games players, to write to the magazines, especially if the standard of review is slipping. Tell them you want accuracy of facts with plenty of detail. Colour is obviously preferable as this is how most of you will see the game, and you donít just want regurgitated instructions, anybody can do that, you want an objective review of what the game is like to play, what new original features the game contains. Am I right or am I right?

I put together most of the undocking sequence today. The ship now accelerates to the right, the stars and grids moving in the opposite direction. The grid then fades out and the stars change. The stars changing gives me a sneaky chance to build the required sprites over the old grid data. The only thing not yet in is the docking bay relative movement, it should gracefully scroll off, but at present it just sits there. This will all be tied-in to the sprite movement system, so Iíll leave that for now.

Itís a long time since Iíve had the grid off the screen. It needs the full screen size to give the 3D effect more impact, and it gives me a better idea of the playing area size. With a large ship with all its extensions itís nearly the full screen height.

Tuesday 7th April

Iíve rooted out a major stumbling block in the theory of the gameplay. I wanted two particles or charge centres to split from a star. These would be of opposite polarity, I then wanted them to split again into two particles of opposite polarity, and finally split again. This raised the problem that an already negative particle canít really split into a negative and a positive one. It would have to split in another Ďdimensioní, not necessarily a physical one, but a mathematical one, for example: matter/anti-matter, positive/negative clockwise spin/anti-clockwise spin, red/blue, whatever, provided the two opposites cancel each other out, the last example simply being an arbitrary rule, which is all that a game really is, a collection of arbitrary rules. Whether you match these to a real sport, or a simulation of some physical process or something totally abstract is entirely up to the prcgraminer. I think that may define the originality of a game or a clone, whereby a clone game has attempted to copy the arbitrary rules of another, itís just worse if they nick the graphics and sound as well! But back to splitting particles. I canít really justify multiple splitting, it just complicates the situation. Iíve resolved this by just having one split from a central star, although into more than two parts.

In experimenting with the polar vectors Iíve begun to compose the title screen sequence, using routines that will be used in the game too. I now have a many-coloured central star which can randomly spit out particles, in circles or in spirals. This also allowed me to check the polar vector table that I keyed in recently. I told the particles to stop moving when they left the screen, sensible enough I thought, Iíd rather they didnít float about through memory. Instead the ones that left off the top bounced back and rained down the screen. This gave rise to the programmerís warcry of: "That canít possibly happen!" Quite often bugs cause things to occur that havenít been programmed in yet, or things occur that you wouldnít be able to program in a month of Sundays. if you tried. This one turned out to be miskeyed data in the polar vector table on the one number out of 512 that! happened to set the particles to as they left the screen to stop them. Glad I found it at this stage rather than when the data will be used for sprite movements.

" . . . we decided that the only course of action was to operate "

Wednesday 8th April

The Opus has been causing some concern as it has not been reading from ĎDrive Aí properly, which is a blow because it reads all of its boot-tip instructions from it, so we canít run anything. Upon the
advice of the suppliers we decided that the only course of action was to operate, just an exploratory to discover whether the drive or the disk controller was at fault. We swapped the leads from the two drives and it booted up from ĎDrive Bí so we swapped them back and it booted from ĎDrive Aí, problem solved, it was probably a loose connection. Saves sending it back anyway.

Further organisation of my ship set-up data means that I might be able to actually interpret it in a useful manner. Itís all very well being able to set up these different ships, but the game will need to reference this data later, so it needs various pointers into all the tables to be able to get at the right information quickly.

One thing that has puzzled me, is that all the sprites disappear in the changeover from the title screen to the main game. I wanted this to happen anyway, but I didnít tell it to do that. I realised that this is because the sprite multiplexor clears out the sprite table ready for the next position, which donít arrive if itís busy setting up the screen - so what am I to do in the pause mode? All the sprites will disappear. Any offers?

Thursday 9th April

Took the bull by the horns and began work on the control mode. From a programming point of view this is the most complex one that Iíve done yet. It is arguably the most important part of the program, as it is the interface between the player and the game. It must therefore be very carefully tuned up to allow the player as much freedom as possible, to make his or herown mistakes and not be able to blame the game afterwards!

It took a while to actually get the thing started as Iíll be using the fire button to move from one section of the ship to another, but I was also using this to return to the monitor so every time I tried to move on the screen it returned to that. A quick alteration put that right, but the flashing blue square representing the current position refused to move. This was because it thought it was in two different places at the same time. Realising my error I fixed the initial start position routine that always locates the engine room. I began by moving at rocket speed. Moving one character position every cycle is too fast. I gave it a delay of three cycles in any square but controllable movement. Having rigged the hold down fire-button to disengage from a particular system and put in the movement, I needed the routine to re-engage into another system and identify it so that the proper things occur when using it. Itís no good sitting in the landing bay being able to fire rockets. Thatís where I needed to access into the ship setup table.

Got that system up and running too, and implemented my first use of my JUMPY macro, the wonderful GOTO DEPENDING ON.

Friday 10th April

Got to thinking today that I may move the ship a few characters to the left so that the primary play area is on the right-hand side of the screen. This will have the effect that the ship will actually touch the docking bay structure, which canít be a bad thing. Maybe Iíll try it. Iím also planning the title sequence and considering the possibilities of a demo mode, but Iíve never been to fond of them. Itís quite hard to demonstrate a fairly complex control mode well.

ST has been finishing work on the new sound routine for the C64. Heís upgrading it for more complex sounds and music. He did try to explain some of the new ways of producing sound effects to me but itís really hard to relate a bunch of numbers to a sound effect. You just have to experiment with it. I wonít be putting the sound module in until the last few weeks, so maybe ST will send me on an IBM sound effects course in Florida!

To Be Continued. . .

Read the Preview

Read the Review

Get the Game

Continue Reading