Issue 44 - December 1988
This month: Thrill to the full time return of program coding. Gasp as the Citadel begins to bristle with new developments. Whistle in amazement
at the addition of go faster stripes. Wonder why there is so much waffle in the intros... .
|Wednesday 8th September
||Here we are on the first day of the latest diary, and already the player bullet firing routines are in - as I said
at the end of last month, things are beginning to move quickly, especially now that all my music/sfx commissions
have been completed for the time being. At long last there is more colour on screen as the bullets have separately
mapped colour information.
|Thursday 9th September
||The first bullet routine gave a maximum range to each bullet, and in practice this looked rather strange, since
firing down a long corridor produced the effect of them all disappearing into another dimension at maximum range.
Today the routine was revised to allow each to travel as far as the edges of the screen window - the only slight
disadvantage of this method is that unless any bullet hits something there may be a tiny pause after loosing a
full volley bef ore the next bullet becomes available to fire again. This can produce, if taken to extremes, the
classic super- fast firing in tight situations - but dodge 'em while wailing for bullets so beloved of Delta
fans everywhere; only if used very cleverly can it be turned into a strategy and not a grumble.
|Friday 10th september
||Somewhere on screen the score and needed in- game information must be displayed, and the time has come to decide
once and for all where this is going to be, as many already existing routines may need to be modified slightly.
I'm not using 'sprites in Ihe border' tricks this time for various reasons. so it means losing several lines of
characters either at the top or bottom of the screen. Choosing which has occupied much thought.
When playing the game the eye finds it easier to glance down quickly to take in information - I suspect that this
is why subtitles always appear at the bottom of the screen. However, if you are playing a vertically scrolling
game the eye is always on the watch for 'baddies' arriving from the top of the screen, Also, just like reading
a book, when first presented with the screen, the brain is conditioned to find it easier to react to a 'title'
area at the top. After debating both options for some time, the top won although it will probably prove more difficult
to achieve a clean 'split' when 8 sprites appear under it!
|Saturday 11th September
||Having decided where the information is to go, I suppose I ought to decide exactly what will be displayed. The
current score is fairly obvious, but again there is a big controversy about the addition(or not) of player 2 score
and /or High score. Personally I rarely play with 2 players (perhaps I ought to rephrase that!), and anybody playing
a one player game will find the second score completely redundant, so the high score seems more important overall,
especially as a ' 1' or ' 2' can appear next to the score to indicate the current player. The other vital information
needed in Citadel will be special equipment currently available for use. and the means of selecting it in
the thick of the action. Suffice it to say that my screen editor saw a lot of action today.
|Monday 13th September
||A tricky little routine to produce the screen splits was perfected today. Since an interrupt routine from the sprite
multi p lexor may strike anywhere down t he screen, depending on the current position of the sprites, the screen
splits will be produced using an NMI (dreaded by all backup cartridges, and tricky for me since I'm using my trusty
Expert as a development aid!) A 'Non-Maskable Interrupt' is normally also generated when you tap the RESTORE key
- for my purposes, this is ideal because it overrides any other interrupt, ensuring that the screen splits always
occur at the correct position, whatever the other interrupts are doing.
Once the routine was in and working, it also allowed me to have different colours for the information bar at the
top of the screen (and hopefully an end to the ZZAP! art department printing my screenshots upside down!)
|Tuesday 14th September
||A day of preparation for the PCW show, which I shall be visitng tomorrow, plus some tidying up of routines to optimise
their speed. The use of screen border colour changes at the start and finish of interrupt routines is a very useful
development aid, showing exactly how much time is taken by each 'JSR', and helps to pin point bottlenecks and problem
areas. I suppose that they are the equilvalent of the ' go- faster stripes' so beloved of the car fraternity!
|Wednesday 15th September
||So this is what 7.30am feels like! Yawn. Slagger. Sip coffee. At least I'm going by train so I can catch up on
sleep later. With my trusty joystick packed (just in case) it's off to Earls Court to see what everybody else has
Well, what a day! Many thanks to all of you who helped to make this my most entertaining PCW show so far. The prize
for most interesting diary comment has to go to the reader who likes the bits in brackets best (this is just for
you, and all bracket lovers everywhere!)
More and more companies seem to be setting up 'satellite' stands in nearby hotels. This certainly gives more variety
to the day, but does tend to use up rather a lot of stand browsing time - at least the Mediagenic bash gave me
a chance to take a ride in a chauffeur- driven limousine! And no, I shall not be procuring one if I ever get rich
and famous. My trusty joystick did come in handy when I managed to try out a demo of the official R Type on the
64. Later on, back at the show itself, the purchase of an ST joystick extender lead meant that I can now also plug
it into the ST without perf orming any more upside down contortions (hooray!)
As the sun began to set I found myself peering once again through a British Rail window wending my weary way home
again. All in all, a very rewarding day. Apologies to all those readers who asked for me in vain at the Newsfield
stand on later days - next year I must go for several return visits.
|Thursday 16th September
||A day off to recover, and mull over the products and trends seen at the show (and to play my copy of Hawkeye
- from those nice guys with deficiencies in the cerebral department).
|Monday 19th September
||Over the last few days the main structure of Citadel has been mapped out ready for the BIG routines. Since I need
the real feeling of exploration, all of the things the player will meet on his/her travels must be positioned in
advance - and this means storing the locations and status of up to 256 objects for each level! The reason for the
ultra-compacted city generation system now becomes more apparent.
The function of an apparently useless object in the city may become obvious after another vital piece of equipment
has been found or activated, so retracing your steps must show everything in its 'last visited' state (how many
games have you played that just regenerate every meanie every time you re-enter a room? Bang goes any feeling
of a real environment!). Also, an activated city defence may be used to set ambushes in a particular area for pursuing
meanies - some of them may be indestructible using your own available weapons, and remembering the location of
the switch that activates a force field may prove crucial! Learning to use the cities own defence systems to your
advantage will get you much further into the game.
|Wednesday 21st September
||Movement of sprites is going to be on a predefined patrol basis. This will allow them to be designed in groups
which will protect the more important installations. Just like in real life, there will be comparatively empty
corridors followed by vital areas which will be very tricky to negotiate, with 'loadsasprites'. I did toy with
the idea of invisible 'tramlines' allowing sprites to move freely about the cities and home in on the player, but
if I were them, I'd prefer to have safety in numbers!
|Friday 23rd September
||My brain hurts! There really is a lot of work to complete before my multiplexed sprites can react to their environment.
First routine to be completed moves all sprites in 'sync' with the background, depending on what my static zone
8-way scroller is doing. This sounded easy enough, but I finally traced 26 exceptions where a one or two pixel
move was suddenly needed in the X or Y axes when stopping or suddenly changing direction! (It looks very smooth
now but took two days to debug). The next two routines will be SPRITEOFF the screen at the edges, and SPRITEON
if the edges correspond to the object's position in the city. Wish me luck!
|Monday 26th September
||SPRITEOFF proved to be a more typical routine - less than an hour to write, assemble and tweak. SPRITEON needs
more thought before leaping into frenzied action at the keyboard. Since there will be up to 256 objects in a level,
whenever the screen scrolls in a particular direction any new objects that should appear at any edge must he found
and plotted from a massive table of X and Y values. The main problem with this sort of routine is that unless you
are caref ul it will still be searching through the table long after the object is supposed to have appeared on
screen - shortcuts must be found to minimise processor time.
|Tuesday 27th September
new routine turned out to be rather schizophrenic, and ended up as two routines - one running every frame on the
interrupt and the other in mainline (any time remaining when the interrupts have finished!). Every piece of coding
for Citadel is complicated by my insistence on scrolling in 8 directions. In a vertically scrolling game, for instance,
you only need to check how far the background has progressed to know when to 'launch' the next wave of aliens.
Citadel checks each edge around the screen, depending on which direction the player is moving, to determine whether
an object should appear or disappear.
|Wednesday 28th September
||Well, the routines are now completely written, and debugging starts tomorrow. The trick of writing major routines
seems to be to mull over different ways of producing the same effect. Although the principles of SPRITEON were
fairly simply, most games have so little processor time left (especially if of the scrolling variety) that it is
the fastest routine that matters, and hitting on a way of streamlining it can be very important. This quite often
revolves around a flash of inspiration - it's time saving to remember, for instance, that objects arrive on the
left hand edge of the screen only when the player is moving left and so on.
|Thursday 29th September
day off (what do you mean 'get on with the debugging!') and a perusal of life, the universe and chips with everything.
I need to get my hair cut or else take up wearing a headband to keep it out of my eyes, and that would make me
look like a jogger, and the only thing I like jogging is my elbow (how about that for a mammoth waffle (a shame
it isn't an edible waffle) and the first instance of brackets within brackets!)). Anyway, I'm suffering from 'advanced
complimentitus' - another interesting letter forwarded to me by Thalamus from the left-handed Jimmy Straaburg of
Future Factory (Sweden) no less. In fact I'm left-handed too (interesting fact number 42).
Following my trip to the local scalp hacker. I popped into Boots and Smiths but there was nothing much to capture
the imagination - of course the shelves will be groaning under the weight of the Christmas releases in a little
while, since such a big proportion of annual sales happen at this time.
|Friday 30th September
||Well, all the debugging is now complete, and the traps appear and disappear at the screen edges as you move around
the city - it's really starting to come to life . As I expected, there are difficul ties where the sprites disappear
at the top of the screen, since at the moment they can either move 'over' the score bar (eg.
Morphe us) or suddenly 'blink' out before they get to it (Hades Nebula).
|Saturday 1st October
||A day of refinement (on the program, not my lifestyle!). After designing a new sound effect for the
city itself to add more atmosphere, and a neater bullet character, it seemed about time to write the sprite animation
routine so my inhabitants can stretch their legs (or wave their antennae as the case may be!). Again it is the
fastest routine which counts, and one which also anticipates ways to save memory in the animation movement tables.
When finished and installed into the game itself, another useful by-product was revealed - since objects can appear
anywhere and then start animating, all of the on screen sprites tend to end up moving 'out of sync', adding even
more life (and certainly a lot more colour) to the screen!
|Sunday 2nd October
||It's time to return to genetics - the city needs more varieties of inhabitants. Approaching the sprite design from
a different point of view. I ended up producing a shaded sphere according to basic artistic principles. It looked
a bit crude simply because with only black, mid grey and white you simply cannot produce smooth colour fading.
Then by designing features onto the surface of the sphere where the colour transitions occured. all of the 'glitches'
disappeared, leaving me with a realistic metal sphere. I was well chuffed with the final result! A few more basic
designs reared their ugly heads later (the designs were attractive but the creatures ugly!
|Monday 3rd October
||Main job of the day is to slighly
revise the design for the trapdoor opening graphics - my little spheroid all but disappeared when he appeared in
the game over the pure black gaping chasm of an open trap. Whoops! Taking advantage of the opportunity, various
other small improvements were made to the city graphics.
Incidentally, according to my dictionary, Citadel does not use bas-relief graphics, since these are defined as
'low relief' ... in which figures project less than one half of their true proportions from the background'. The
classic proponent of the 'embossed slab' look on the 64 must be Andrew Braybrook (and his creations have a beautifully
clean sunlit look - there's crawling for you!), but I'm going for a more 'solid' look, more in keeping with my
original need for a dark, oppressive feel to the cities (the first diary instalment described this as the Blade
Runer look - perhaps this should now be updated to Cyberpunk!). And with that thought I had better prepare the
screen shot file for this instalment, hopefully now printed nearby (the logo should be at the top!).
Issue 45 - January 1989
In this, the new and radically redesigned Walker's Way, Martin 'Axe Man'
Walker continues on his long and I perlious quest into the parallel universes of computer programming and magazine
journalism. So, without further ado, heeeeere's Marty...
|Thursday 6th October
||These NMIs (see last month) are causing more problems than expected - although needed for extra screen splits,
occasionally when re-entering my Expert cartridge things get corrupted in the game. I do use this device an awful
lot for debugging so the day was mostly spent coming up with a scheme to exit the program neatly. As this involved
using special techniques normally more often seen as 'ripoff protection', then say n'more!
|Friday 7th October
||The cities, having security systems operational, now need more of a feeling of 'behind the scenes' activity
- the sound effects have a hum of concealed power. TWINKLE is a routine which animates a small section of a particular
city. depending on the current background design. It will be used in many different ways, but in designing the
routine now I can incorporate the desired animation into the character set for future cities. There. Just thought
you'd like to know that. Next!
|Saturday 8th October
||Now that the traps are operational, many more sprite designs are needed to fill them, and during the course of
a day spent lounging about in the Sprite Editor, several new alien species evolved. It wasn't until later that
I realised why I kept being reminded of Dan Dare(theoriginal character created by the genius of Frank Hampson rather
than the Virgin games) - my favourite newcomer has a design rather like Dan's helmet as well as looking truly EVIL!
|Sunday 9th October
||A slight diversion today. Every time I produce a disk file for any screenshots it means hacking into the game.
In fact, all that is needed is a stand alone file with screen, sprites and just the small amount of code needed
to display them both. Once written it can be used again and again, but also means that no early copies of the game
can ever f all into the wrong hands! (ZZAP! themselves are scrupulous in this respect - you can't even get through
the front door if you don't know the combination!)
|Monday 10th October
||The next big code module should produce another big batch of additions to qameplay - at one fell swoop it will
allow traps to be activated, objects to appear underneath and aliens to explode. In preparation, various trials
were undertaken using yesterday's screenshot module to experiment with different ways of sitting the traps.
In practice this module will probably turn into several smaller chunks which rely on each other. since there is
limited time to ' hang routines on each interrupt frame. This means that the things which absolutely MUST be checked
every frame (high speed bullets for example) stay on the interrupt, but others may only happen once every four
frames (score updates certainly don't need plotting more than 12 times a second!)
|Tuesday 11th October
||In preparation for the big routine I must cure a little bug-ette that causes your in-flight bullets to lurch alarmingly
if you suddenly change direction. Otherwise aliens may well explode before the bullet gets to them - and that would
be TOO easy, wouldn't it?
As usual it was the static zone scroller at the back of it. Once I'd traced the cause of the problem it only remained
to think of the most universal way to cure it. It's very tempting, after finding a special case that causes problems,
to simply check for the special case and add an extra piece of code to combat it; this has happened before - 26
exceptions to fine scroll bytes when suddenly changing direction - but often gets unwieldy. Since the bugs are
caused by exceptions to certain rules it ends up being far better to think it through properly and treat the cause
rather than the result - then if anything gets modified in the future you don't end up testing for exceptions to
exceptions! Got that? Er.
|Wednesday 12th October
||The control mode has now changed slightly to accommodate being able to fire in any direction while moving in another.
This now allows the player to whizz past the end of a side corridor and fire a quirk burst of bullets down it or
even to fire backwards while running away! It works by locking out the direction changes when the fire button is
down, allowing you to fire by pushing the stick in any direction - and with built in autofire in the game it feels
very powerful in action.
|Thursday 13th October
||As you may remember when the screen was first split at the top to allow my score 'bar', whenever sprites go beneath
it the 64 tends to lurch dramatically, sending the formerly neat split careering across the screen with annoyingly
flickering colours. This is one of those problems that has most 64 programmers tearing their hair out, including
On the old Atari 8-bit computers there was an invaluable little bit of hardware built in which allowed you to program
the colour and screen changes to wait until the electron beam had disappeared off the visible part of the screen
before changing them 'invisibly'. On the 64 you just have to grit your teeth and produce little tables of delays
for the split depending on what sprites are 'underneath', and then write tiny routines that act like a Grand Prix
pitstop - get everything possible in advance and then when the split pulls into the 'pit' bolt it all on and bang
it out again as quickly as possible, before anything else gets very far. I've had to resort to self modifying code
(I agree with Andrew Braybrook's view that it's a bit naughty!) but it saves a few cycles, and in this case
is necessity. And if it means the difference between a lurch and a rock solid split-go for it!
|Friday 14th October
||Well, you didn't expect me to debug these splits that quickly did you? As CITADEL is 8-way scrolling, the split
is also complicated by having the screen moving up and down beneath it - this means a secondary set of tables.
I'll say no more about it, but next time you see a game like IKARI WARRIORS on the 64 with 8 sprites appearing
neatly from under the top screen split, spare a moment of admiration for the programmer (John Twiddy).
|Saturday 15th October
visit to Exeter today, to see my friends, Cyberdvne Systems, and also get some 'instant consumer feedback' to all
the improvements to CITADEL. The feeling of exploring the city and my new 'glide and fire' control mode were well
liked (what Ireally mean is that they love whizzing about blasting everythinq in sight!) Dan had some suggestions
concerning the screen split, and I actually managed to get some work done, too. It's a great feeling working in
a group - every time you groan at a bug somebody offers a suggestion (and some of them were really novel!)
|Sunday 16th October
||For the next few days I have a special quest - none other than Robin Levy, the graphics wizard from Cyberdyne Systems!
Apart from playtesting (playinq games, to you!) he has very nobly offered to play 'celebrity sprite designer' whilst
taking a few days' holiday after the completion of ARMALYTE - so the next screenshots should look particularly
inspired. Two gallons of midnight oil have been supplied, along with a spare monitor and my box of games for inspiration.
|Monday 17th October
||Have you ever had that feeling of deja vul I was looking through a big batch of old Compunet demos that Robin brought
up (perhaps I'd better rephrase that) and was lis tening to the music from HYPER SPORTS. Having never seen the
game I couldn't work out why I knew the music so well, until it finally dawned on me that the same tune was used
as the loading music in WIZRALL! I hope Martin Galway didn't manage to get paid twice!
Robin came across the same problem as I did with my sprite designing - the difficulty in pro ducing smooth shading
using only black, white and one other colour - but has already surpassed him self with some new designs based partly
on my latest renditions. Now he's venturing into the unknown and starting to produce creatures from the wilds of
his imagination. Ooo-er!
|Tuesday 18th October
||Since all the creatures in the city are defence systems, and there fore likely to be metallic in origin. our first
major graphics discussion concerned what we termed 'kinetic reflections'. The amazing alien bullets in ARMALYTE
are mostly tumbling metal shards, and the reason they work so well is the sudden glint they get when catch ing
the moonlight as they revolve (well. I like to think that it's moonlight - that's the romantic in me).
I've always wanted to use this technique in CITADEL, but now with the expert himself in the graphics hotseat I
can pick up some valuable tips from someone who has been doing it for a year already! The art is in using pure
white on the animation frame that completely faces the light source momentarily (and, of course, regu lars will
know that mine is at the top right of the screen). Andrew Braybrook used this rather nicely in some of the ALLEYKAT
crea tions, along with some rather fetching shadows, but as these ended up using a second sprite per alien it's
out for this project.
|Wednesday 19th October
||Meanwhile, back in the coding department, the door opening sequence is well underway. When a closed trap is hit
by a bullet, first the door sprite is plotted over the character version, and then the object is mapped in underneath.
Then, before the sprite door can start to open, the open version of the trap is replotted undercover of the sprites,
so that by the time the door is opening, both the contents and the open character version are in position.
Once the sprite door is fully open it is removed, leaving the open character door and the object sprite in place.
It sounds far more complicated than it looks, and in fact I doubt that many people would even realise just how
much is going on, so just sit back and enjoy it!
|Friday 21st October
||Robin has come up with some interesting variations on door designs - some even have teeth! In fact, we watched
The Return of the Jedi on video last night, and sev eral more inspirations resulted.
The door sequence has now been completely debugged, and now must be extended to accept multiple triggers, so that
if you go around spraying bullets everywhere all the traps triggered will open singly in sequence one after the
other. I decided to use a loop of eight triggers, so that the system must remember not only which traps you hit,
but in which order. I doubt if the loop will need to be any bigger than this, as long as I remove references to
the same trap being hit by many bullets, and it should be a daunting experience to see your hail of bullets turn
into a choreographed sequence of unfolding doom!
|Saturday 22nd October
||As the doors are now sliding into action, it would be nice to be able to blast the contents to smithe reens, so
the next game routine
will will be collision detection. This area of any game can prove crucial to the end playability, and cause countless
howls of anguish from players if done sloppily. How many times have you sworn that an alien missile missed you
by several pixels, and yet you still exploded?
Players like to have reasonably 'loose' detection for their own ship to allow them to scrape through a tight situation
unscathed. This is fine as long as it doesn't apply to the aliens as well - it's very frus trating to see your
caref ully aimed bullet hit an alien but carry on as if nothing had happened simply because the program only detects
collisions with the exact centre of the opposition!
|Monday 24th October
||I took the opportunity to add all the checks for multiple hits and explosions into the collision mod ule, so it
only remains for a sprite explosion to be added. I've asked Robin if he will graciously provide a sample (I definitely
ought to rephrase that!). Once inserted into the game, it looked really nice, especially as we hit on the idea
of having every animation frame of the explosion in a different colour for maximum impact (a touch of the Minter
|Tuesday 25th October
||A particularly frustrating day today, as all attempts to find a vic ious bug failed After modifying only two routines,
as soon as the game restarted Monitor got hurled halfway across the city - and then as soon as the screen scrolled
everythinq latched up- Groan. Having checked the source code for both, carefully, and finding nothing wrong I started
by passing each routine until the bug disappeared. When it does you have at least narrowed it down a bit.
Since this happened to be in an enormous routine that was finished several months ago the : dreadful truth dawned
on me - in modifying the new code a line number had accidentally been insert somewhere in the middle of everything
else, and since I'd renumbered the entire program it was 'needle in a haystack' time! In situations like these
the backup copy is vital - after adding the new code once again to yesterday's ver- sion of the source files everything
worked perfectly. Phew?
|Wednesday 26th October
||A day off to drive to Exeter with Robin and return him to the land of cream teas. After a relaxing after- noon
watching videos with the rest of Cyberdyne Systems. we ended the day with a champion- ship session of International
Karate. I was thrashed! (and me a black belt in pixel punishment!)
Since I normally work totally alone(aah!) it's been a very worthwhile experiment. Certainly it's great to have
someone close by to bounce ideas off, with the added boost of being able to write code as the graphics are being
produced in tandem. It's also allowed me to study someone else's approach to sprites, and I'm already seeing some
improvements in my own work using my newly honed artis tic eyes.
|Friday 28th October
||Time to neaten up some points of presentation and remove a few lit- tie bug-ettes from the works. Monitor now triggers
the traps on contact, as well as remotely using bullets, so you now have to be more careful when moving around,
since racing about like a mad thing will ensue a speedy demise.
The next big chunk will see the baddies emerging from their traps and pursuing me around the cor ridors of the
city. I'm glad that at least I can blow them up before they catch me!