Thursday June 13 |
Decide today that the doors on the ship didn't look
good enough. Played about on the graphics editor with intent to draw the doors in the same style as the walls.
Had to alter the door routines to handle the doors differently, and needless to say, on the first attempt got it
wrong. Vertical doors worked as intended, but I forgot that horizontal doors were done differently. Also changed
the alert status block to be in the same style.
"Sneakily altered ST's gory sunset colour scheme to a blue decor, much nicer. No taste
that bloke!"
|
Friday June 14 |
Redesigned the graphics for the side elevation to
get rid of the herringbone effect. Used the same style for the rest of the deck plans. It's nice to have a style
for the whole thing, otherwise it starts to look like a hotchpotch of all sorts of meaningless patterns, rather
like many platform games these days! The side view plan also required alterations to fit the new graphics, and
looks very tasteful indeed. Sneakily altered ST's gory sunset colour scheme to a blue decor, much nicer. No taste
that bloke!
Designed two new robots to look on the robot enquiry
screen, a dumpy little litter cleaning beastie, and a huge sentinel droid. Get past that if you can. The system
is holding up well with the input of more words and pictures and has not faltered yet.
I also wanted a nice dark and dingy grey colour
scheme for some decks. Used dark and middle greys all over the place, and black. Didn't look dark enough until
brightened the border to yellow, which gives a better contrast. The lighter the border, the darker the on-screen
colours appear to be, and vice versa.
|
Monday June l7 |
Keyed in some new characters that I had designed
at home yesterday for the new consoles, again in the same style as even/thing else. Also keyed in the data for
the title screen, with PARADROID written in giant-sized letters. Since this data is only required one in a blue
moon, I've found a nice little cubby-hole in the C64 for it, along with some seldom required text. Thus my plan
to use 68K of the C64's memory is realised! I'm using the 64K RAM and 4K of I/O devices. Had to do some fancy RAM
bank switching during the game, but it leaves more room for important things.
Also mended one or two little errors that I had
noticed and after some minor modifications, the title screen appears. Looks good.
Lo and behold, half past four, and Commodore strikes
again. Entire user-defined character set disappears from disk. Directory says it's still there, 9 blocks long,
except that there are now 673 blocks on the disk, 9 more than physically possible. Great, thanks a lot guys! I
really wanted to key in the console data again. This sort of thing really annoys me. Can't anybody write a decent
reliable operating system?
"What do I want the bullets to look like? They must look OK travelling in any direction. Do I want them
animated, and to change colour? The answer to these questions is, possibly."
|
Tuesday June 18 |
Changed most of the small-scale deck plan graphics,
as they were looking rather ugly, still reflecting the old look of the ship. Simplification is the order of the
day. It's no good being overcomplicated if you need a magnifying glass to see what's happening. Now the small plans
look sleek and modern, much better.
Sat down and scribbled some more routines to run
the robots. The same routine can also handle explosions and bullets, except ... What do I want the bullets to look
like? They must look OK travelling in any direction. Do I want them animated, and to change colour? The answer
to these questions is, possibly. I'd like the different robots to use different weapons. From simple shells to
electric clouds and energy blasts. Thus some robots will be very difficult to tangle with, spitting doom and disaster
all over the place.
Tried to draw some bullets on the sprite editor.
Some days you can sit for hours and not come up with a decent graphic. This is one of those afternoons. Inspiration
has failed. Best to leave it for a while.
|
Wednesday June 19 |
Worked out some lively-looking routes for patrolling
robots to zoom about on, and marked them on my maps. Then took my robot round to all the patrol junctions and noted
the co-ordinates. Finally keyed the points and valid directions from them into the assembler.
Lifted a few more useful routines out of Gribbly's
that used to run the Meanies and after several adjustments they should be capable of running the robots, missiles
and explosions. Think I'll start off with a simple demonstration that can just display some static robots. No point
in being too ambitious at the moment. So many new routines and data need to be co-ordinated just to introduce one
new element into the game. I'll wait until tomorrow before I try to assemble all of this. I'm sure it'll put up
a fight!
|
Thursday June 20 |
Put in the last few bits and assemble it all. Fired
it up, and on attempting to display an enemy robot we get… a blank screen. Restore doesn't recover it, neither
does the reset switch. Load it all in again, same thing happens. Try cutting out different suspect routines, each
time it either gives me a blank screen or a mess. Spent most of the day staring at routines that were swiped from
Gribbly's and must therefore work. Even ST supersleuth can't find anything wrong with them. I can't isolate which
lump is causing the crash. I can't even think what sort of error can cause this type of crash.
At about 4.30pm I was dreading going home, as I
get nightmares when I can't find mistakes in my programs. I mentally scan all the possibilities and usually find
it in the end, at the cost of a night's sleep. On skipping through an ancient routine that I keyed in weeks ago
knowing I'd need it later, I discovered on close inspection a single one-byte instruction that caused all the damage.
It's one of the most devastating single instructions known to mankind, the PLA. One of them too many and it's goodnight
forever! Feel very, very relieved at finding error made when copying it across by hand.
"Not quite sure why it thinks it's necessary to blank the screen when it crashes. Perhaps it's just embarrassment.
It doesn't help to diagnose things when you can't see anything. "
|
Friday June 21 |
Amended the sprite display routine and got to grips
with the collision detect and handle routines. These together analyse what object is touching another, and deal
with it accordingly. Such things as robots exploding when shot are handled by this. Got that wrong as well! First
time, instead of the gunsight causing explosions, I had to ram the other robots with mine to blow them up. That
was quite good fun. I think I'll incorporate it into the game. After all, the big battle robots would be able to
just barge past the litter clearing robots.
Managed to get another PLA instruction into the
proceedings, which had a similar effect to yesterday's one. Not quite sure why it thinks it's necessary to blank
the screen when it crashes. Perhaps it's just embarrassment. It doesn't help to diagnose things when you can't
see anything.
|
Monday June 24 |
Tidied up the sprites for the robots currently in
the game. Only five so far. Kenny Everett now looks a bit more like a robot.
The task within the game is becoming more concrete
now, and with the fixing of the sprite collision routine, a certain amount of game tuning can begin. This is the
part that many programmers don't bother with at all, witness the reversing witch in Cauldron. Rather like building
a Rolls Royce, then not tuning the engine at all. The object of the exercise is supposed to be to make the game
as playable as possible. Is it easy for many people of differing abilities to play? Pottered about for some time,
experimenting with speed and acceleration of the gunsight. Might have to make it slower.
CEGB caused machine crash at lunchtime. Thunderstorm
caused another crash later in the afternoon.
|
Tuesday June 25 |
Put in the robot patrolling routine. Fired it up
with great air of anticipation. I've been thinking about this for weeks. Could it possibly work first time? Just
caught a glimpse of a couple of robots as they hurled selves off the screen at breakneck speed. Change decks.'Hi
guys.' Vvoom, gone. The ones on deck one however are just sitting there, contemplating, but never moving. I can
make the robots reverse direction if I can get in their way before they migrate. Occasionally one leaps across
the screen, but rather fast. They take little or no notice of my patrol points and as for the walls and doors,
they are totally ignored.
|
Wednesday June 26 |
Discovered the bugs in the patrolling routine. Upon
correction I observed several robots wobbling along the predefined courses, shudder as they make up their minds
at the corners, then toddle off in another direction. Followed a couple of them all over the deck and observed
a number of unforeseen problems.
- Upon meeting, two robots instead of bouncing off
each other, lock together in mortal combat.
- Robots slowly drift off their courses until they
are in great danger of missing the junctions altogether.
- The robots are so fast that it is nigh on impossible
to shoot them.
Of these, the first two are fairly easily cured
by more careful programming. The third problem is one of design. If the game system doesn't give you a more than
adequate ability to complete the task in hand, then either the game must be made easier, or the weapon more powerful.
|
Thursday June 27 |
Robots are now moving along their pre-set courses.
They pause at junctions as if they are looking around, then move off. They also wait for the doors to open before
going through them, which is jolly decent of them. The whole game is looking more complete. I've slowed some of
the robots down to keep them on the patrol routes, and hopefully make them easier to thump.
|
Friday June 28 |
First day working at home as ST has gone on holiday
for the fortnight. Tried to assemble game after making some changes. My disk drive seems to be causing problems.
After 20 minutes of assembling with no errors, it didn't produce an output file. Feels rather like landing on Mars
and finding someone's been there already. All that effort for nothing.
Assumed that the disk was worn out. Copied everything
I could to another disk and reassembled. Finally produce an output file. Load the code in, with anticipation. *%!$&*!
Now the data files such as the character sets and deck plans won't load. Two duff disks? I don't think so. Tried
loading some other disks. Seems to be labouring somewhat. Seems to be a 50/50 chance of loading something even
slower than normal, or not at all. Panic. Why didn't I bring ST's disk drive home?
|
Sunday June 30 Supplemental |
Race over to Robert's house with disk drive. Confirm
that my drive can't load files properly. Try assembling new code on Robert's drive. No output file produced. The
plot thickens. Robert has some useful utility programs to try. Disk doctor program reveals that one disk has a
bad track and is thus faulty. A head alignment program confirms that my disk drive has a bad head alignment. I
expect it of Commodore tape decks, but not the disk drives.
|
Monday July 1 |
Get good old reliable disk drive from ST's house
and painstakingly copy all source files to a new disk for the umpteenth time. Finally assemble all the game to
see the effect of the changes made last Friday morning. I think things have returned to normal at last. Designed
some more graphics for the shuttle ship and two landing vehicles for the cargo decks. Have now mapped out on paper
most of the other decks.
Now I have to sit down and convert them into computer
data, which is just a case of hard graft.
|
Tuesday July 2 |
Converted the remaining twelve decks into hex and
keyed them in. Took about five hours for each process. Boredom set in towards the end. Lucky Wimbledon was on TV.
Fiddled the game to start me off on each deck in turn. Only two came out as planned. The rest had some errors in
them, causing some very weird deck layouts indeed. Nothing that can't be cured. The shuttle ship and landing vehicles
look as different as intended, very pleasing. In carrying out all the new changes only one disk file managed to
get mangled by the operating system, wouldn't mind, but it wasn't even one that I had changed recently.
|
Wednesday July 3 |
Corrected the new deck data then wandered around,
noting the lift locations to tie in with the lift routines. Forgot one of the limitations of the system that says
lift shafts mustn't be placed at the very top of the deck. Had to alter two decks of data to cure that one. Noticed
also that one particular shaft is marked on the side view as accessing five decks, whereas it should access three.
I seem to have become nocturnal working at home.
With no fixed hours I now work from 11am to 5pm then 9pm to around 2am. Having just realised that there's only
four weeks to go to my expected finish date, things are starting to go into overdrive.
|
Thursday July 4 |
Worked out the robot patrol points for the new decks
and sat in the garden converting them into hex. Another four pages of gobble-de-gook roll off the production line
and are then keyed in. Found one or two stray robots upon touring around, and found the errors that caused them
to end, up leaning drunkenly against a wall.
Still can't think of a way of prettying-up the console
menu screen. It looks rather boring at the moment.
|
Friday July 5 |
Activated the 'hidden robot removal' routine for
the first time. After correcting the usual 'Did it really want that value preserved in register?' error, it's working
fine. Rather disconcerting to watch as anything going out of view disappears, all at once as opposed to sliding
out of view. One thing I forgot was that robots in adjacent rooms which you can't see, open doors which you can't
see opening. This again is rather disconcerting. It should be OK like that though, as it gives you more advanced
warning of approaching meanies. Have to see how the test-pilots react.
Received a postcard from ST on holiday. He'd apparently
had as much fun as me last Friday. A true tale of disaster.
|
Monday July 8 |
Designed and implemented another seven robots. I'm
exaggerating their designs to suit their purposes to make them more obvious and different. Some of the robots,
when seen 'bolted together' for the first time look rather different from my expectations. Their colour schemes
affect this considerably. Some look better, some not. Two of the new robots require alterations due to them looking
dreadful. Others spark off ideas for new robots. Anyway, twelve down, twelve to go. Also designed a small block
to decorate the store rooms, and prepared a lot of changes to the code.
"Unfortunately since the other robots damage each other, the little robots get duffed up by the bigger
ones before I can get to them! "
|
Tuesday July 9 |
Gave most of this month's diary to the word processor
to eat. It seemed to enjoy it. Spent the rest of the day (and night) arranging the pre-game screens into small
enough sections to fit into the space on the screen Towards the end of the fourth page I totted up how much memory
this would all take. I'd allowed about 2K or 2048 letters! That really doesn't go very far. Realise very soon that
I need more like 4K. Fortunately the space saved by the smaller patrol-routes table can be used for the title screen,
which leaves me with 4K under the I/O devices, (SID, VIC and the CIA twins), for the new text.
Arranged the text neatly like a word processor would,
which involved a lot of vigorous rubbing out and rewriting. In my current character set the small 'm' and 'w' letters
are twice as wide as the others, which makes things more awkward. I suppose that was my own choice. Can't blame
anyone else for that.
|
Wednesday July 10 |
Keyed the new text into my Basic ASCII to AB codes
converter, and after 3K of instructions had been entered, I had to dunk my typing finger in some cold water.
Got down to the meaty business of putting the new
changes into the game. Had to amend nearly every file to source code, about twelve of them.
|
Thursday July ll |
Tested the new amendments and made some further
changes. Now it's time to incorporate the Transfer Game into the system to see how the game plays. Space is getting
rather tight so I have to split the transfer game code into the two sections, one to be put into the main game,
the other to set up the other end of the machine where there's some free space. This operation is going to be a
long one, and because of its complexity, must be done in one session. Began this marathon session at about 7.00pm,
having been working for most of the day already, but I was in the mood to get this done.
Time: 2.00am.
After much chopping and changing, I've now got a
workable program. The power flowing along the lines is now animated for the first time and works as hoped. I can
now play the game roughly as it will be. Since it's deliberately difficult for a lowly servant droid to transfer
to a great big hairy battle droid, the transfer is difficult. This is because you start off as the lowest of the
low. First problem, where are all the lowly robots? Every robot so far has been a nasty security droid. Unfortunately
since the other robots damage each other, the little robots get duffed up by the bigger ones before I can get to
them!
Finally finish hacking at 7.30am. Watch a bit of
Breakfast TV whilst waiting for the program to assemble. It's much more comfortable programming in the cool of
the night.
|