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

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.

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