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 . .
By Andrew Braybrook
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
inspiring. Sometimes it gets like that.
Friday 20th March
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
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
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
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
"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
" . . . 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
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. . .