Birth of a Paradroid Part 3

We continue with our everyday story of programming folk as ANDREW BRAYBROOK, the man who wrote GRIBBLY'S DAY OUT, struggles over the creation of his next game for Hewson Consultants called PARADROID.

Here we are given a privileged insight into what is must be like to cull from the keys of a Commodore 64 the thrills and spills that will make a hit game. This month Andrew suffers from errant disk drives and missing robots, but at least Kenny Everett is looking better...

Thursday June 13, 1985

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.

Friday June 14, 1985

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 17, 1985

Paradroid's opening screen, with the metalic 'relief' effect on the lettering.

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?

Tuesday June 18, 1985

Plan view of one of the decks.

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, 1985

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, 1985

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, 1985

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, 1985

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, 1985

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, 1985

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.

1. Upon meeting, two robots instead of bouncing off each other, lock together in mortal combat.
2. Robots slowly drift off their courses until they are in great danger of missing the junctions altogether.
3. 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, 1985

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, 1985

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, 1985 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, 1985

No it's not Kenny Everett, nor is it Steve Turner's holiday postcard - this smiling, relaxed face is that of none other than Andrew Braybrook having just recovered a piece of missing code.

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, 1985

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, 1985

A schematic side view of the space ship showing each deck and the lift shafts.

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, 1985

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, 1985

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, 1985

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, 1985

The Paradroid font with m and w letters twice as wide as the others.

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, 1985

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 11, 1985

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.

Series Links

Part 1 / Part 2 / Part 3 / Part 4 / Review