**The birth of a Paradroid - Part One** (Zzap64 n°3 Juillet 1985) ________________________________________________________________________________ Over the next few months we're running a special series of features covering in detail the way a computer game is developed. We shall be following its programming, production and promotion actually through the eyes of the people concerned. The game we've selected for the job is the new one planned by HEWSON CONSULTANTS, provisionally called PARADROID, which is due for release in the autumn. It's being written by Hewson's ANDREW BRAYBROOK, whose previous game GRIBBLY'S DAY OUT gets a Sizzler review in this issue. This month we're printing the first of several extracts from Andrew's diary. By the time the series is complete you'll have obtained a unique insight into the way a software house goes about its work. ________________________________________________________________________________ The thinking behind the game ---------------------------- Here's Andrew Braybrook's explanation of his plans for Paradroid: Gribbly's was all cute so this one is going to be high-tech. It is based around a large space ship. What you actually play on is a scrolling large-scale view of one of the decks, seen from above. You'll be able to access a plan of the whole deck but you won't be able to see the details on that. Another screen will be a side view of the ship so you can see where the deck is in relation to the whole ship. Other views include logging o n to the ship's computer. The thing you actually play with are robots shown from above. There's going to be lots of them. If you want to know more about a particular robot what you do is log-on to a computer terminal. From there you can sift through all the robots and get large side view pictures and you can select things to get more information. I've been working hard on it for about four weeks, but I was working on utilities - programs to help make the finished game - for a couple of weeks before that. I always like to do the character set first because it buys time while you're thinking about the rest of it. It's probably the easiest thing that you can do. It's not really an arcade adventure - it leans more towards arcade. Gribbly's I wanted to be a non-violent game. All of the zapping and violence that I couldn't get into Gribbly's will be going into this one. Last week we designed the game's 20-deck space-ship, but I'd like to actually build one just to make sure it all works - all the lift shafts tie up and the decks fit together. Maybe I'll try using Lego. Dunno, it might work. So far I've got a little robot skating about inside a test deck plan. You can log onto a console, select an option, make an enquiry on the test robot and get a big picture of it. The piccie uses all eight sprites combined (the maximum a vailable on the 64 at any one time). Despite being a view from above, I intend y ou won't be able to see anything behind a wall. You'll have to go into a room to actually explore it. Wednesday May 1 --------------- Zzap 64 have asked me to keep a diary and today I have to start it. Feel like a mega-star. Decide not to let it change my life. Design form on which to lay out my robot data detailing which sprites make the picture and other bits and pieces. Feed it into Easyscript and run off a few copies. Feel pleased because it's cheaper than photocopies. Decide I need a bank of words to choose from to describe each robot. Write a Basic program to load in the codes. Rediscover how much I hate Basic programs. Spend half an hour at end of day trying to think of something interesting to write in new diary. Fail. Thursday May 2 -------------- Must prepare working copy of game to date to give to Robert (chief test pilot) for his comments before weekend. Suddenly realise this means writing and debugging complete console log-on procedure. Decide not to panic. Grill Steve (Steve Turner is another Hewson programmer) on how he did the scroll in Avalon. Decide to do console on same lines. Have to design meaningful looking icons. Not easy. True test comes when someone tries to identify them. Friday May 3 ------------ Get menu screen working so that icons appear and are correctly highlighted. Feel pleased. Find error in robot display routine. Fix it and a six-sprite robot appears in all its glory. Great! Program is just about stable enough for Robert at end of day. Everything has gone well. Too well. Robert has a habit of mangling things that I write. Tuesday May 7 ------------- Arrive fresh and keen after the extra day off. Have bought my own C64 at last. No need to stay behind 'til ten o'clock playing games any more. Only cost me £139. Feel a bit disloyal towards my old Dragon 32. Got comments back this morning from Robert (our chief Test Pilot). Not too bad considering. Scribbled some notes on the changes necessary. The main robot graphic was indistinct on his TV and as this will be on the screen nearly all the time it will have to be enhanced. Also wrote routine to display the small scale map. Also in the post was a new cartridge Monitor program which I'd ordered. (A Monitor program lets you look at what the C64 is doing by displaying memory and registers, etc on the screen - Ed.) Perhaps it's my lucky day? It looks useful with lots of juicy commands in it. However the game must be altered a bit internally to fit the Monitor - it'll have to save some of its variables elsewhere. Haven't decided where yet. Overall the day has been a bit slow but pretty good nonetheless because of the arrival of the new tool. Wednesday May 8 --------------- Mapped out the side elevation of the ship and designed some graphics to display decks and lifts. Worked hard on the routine which draws the deck plan to convince it that it can also draw the side views. It listened to me in the end. At least I think it did. No doubt it's got some nasty trick up its sleeve even now. The space ship had to be shortened to fit the full side view on to the screen - I used a bit of artistic licence and felt happy with the result. Oh no! The first accident with the new Monitor. All today's graphics in jeopardy when the Monitor decides to lock up. I hit the reset switches (both of them - one on the Monitor cartridge and one on the C64) to try and rescue things but to no effect. I sit fuming at the machine. Up jumps Steve Turner with a bright idea. Two or three times a week we get a mains spike (courtesy of the electricity board) which causes the C64 to crash but with its memory still intact. Perhaps if we generate a spike of our own I can regain control of the machine... Decide against ringing the CEGB to ask them to switch off a power station or two. Instead Steve starts leaping round the room switching the fan heater on and off. Very entertaining. Needless to say it doesn't work. Eventually Steve begins to tire. I give up and pull the plug out. Nothing for it but to key the stuff in again... At the end of the day I start coding the map of the side elevation of the ship in hex (a number system used extensively in machine code programming). This time I do it on paper first. I'm not going to trust that Monitor again for a while. Thursday May 9 -------------- Continued with the hex of the side elevation and keyed in some new routines which decode the deck data into a plan view. Did some other mods which Robert suggested. More fun and games. I discover that my Assembler (the program which generates machine code from the programmer's assembly code) won't work with the new Monitor despite claims to the contrary by the manufacturers. Consider merits of abusive phone call. Decide such action would not fit my image and wouldn't do any good anyway. Resign myself to lots of plugging and unplugging of the cartridge every time I want to assemble. Lay plans to wire up or buy some hardware to fix the problem. In the meantime write myself a note in capital letters REMEMBER TO UNPLUG BEFORE ASSEMBLY. I only forget every other time. Despite problems cartridge works quite well and has already rescued me from one screen full of rubbish. Time to assemble and have a look at progress to date. Aha! The small deck plans are not appearing on the screen. I scrabble through the code and after some head-scratching I discover the, er, deliberate error in the plan routine. Assemble again and Bingo! There they are. Wrong colours but still encouraging. Most other fixes appear to have worked, ie. not working as planned but not crashing the machine either. Modern technology fails again. I attempt to straighten my shatterproof ruler and it shatters. Middle section flies past Steve's ear and frightens the cat. Can't find where it landed. Monday May 13 ------------- Back to grindstone. Tackle deck plan and get it looking respectable but sideviews could do with dressing up. Not pretty enough yet. Major graphics update takes most of afternoon. Design a new robot. It comes out looking like Kenny Everett with short legs. Ponder - do robots have beards? Decide to leave it for the moment. Rage and frustration! Something in machine is eating characters and gobbling sprites. Decide to remain cool, calm and collected. Doesn't make any difference. Nasty munching continues unabated. Tuesday May 14 -------------- More frustration. About to test program when one of data files disappears from disk. Inspect. Machine tells me there are 667 blocks out of a possible 664 on disk. Decide this is not logical. Wonder how Dr Spock would cope. Missing file is lost in seventh dimension of Commodore brain cells. Return to back up and key data in again avoiding Monitor in hope of not repeating this fiasco. Back to graphics. Steve suggests my subtle grey colour scheme for side views is boring. Debate ensues. I lose. Try new psychedelic combinations. Eventually agree grudgingly to white, yellow, orange and red. I grumble. Add some more graphics. Now diagonal lines are causing herring bone effect. Horrible. I'm going to have to change all graphics. Bleaaahh! Wednesday May 15 ---------------- Right. Today's the day. Can't delay any longer. Have to write the routine that hides the robots except when they're within sight (a bit like hiding the ghosts in Pacman except when they're in your corridor). Idea comes from a game called Survive which I wrote a few years ago on an IBM mainframe. Up to six players all trying to ram or shoot one another with two computer controlled assassins. You knew when there was another player on your level but you couldn't always see them. Never knew what was around the next corner. Great stuff! Oh joy! Mid-afternoon and the routine is in and works first time. Steve claims that he was the one that thought how to make it work. Typical. "Has Kenny Evrett put a Hex on Andrew's Prog ?! Will Steve stop the cat from eating the ruler ? Will Paranoid Paradroid learn to shave ? These and other questions will be answered next month !!" **The birth of a Paradroid - Part Two** (Zzap64 n°4 Aout 1985) ________________________________________________________________________________ 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 privilliged insight into what it must be like to cull from the keys of a Commodore 64 the trills and spills that will make a hit game. This month having forgotten his fight with the cat and the lost ruler, Andrew turns to the more interesting aspects of programming like pencil chewing. ________________________________________________________________________________ Thursday May 16 --------------- Redesign consoles today. New ones are much more curved, less detailed in a way, but definitely clearer. THINKS ... Maybe I'll drop multi-colour mode and use 16 colours instead. HMMM. ... I need some orange anyway. Yes, then I can work on some less gaudy colour schemes including the greys. Friday May 17 ------------- OH MY HEAD! Late start today,due to 'night on the town yesterday. Implement colour changes and design some more graphics. Get some very tasty pastel shades using clever pixel plotting. Looks good to me. there again, maybe it's the effect of the beer. Will it look okay on a poor quality TV Dunno. Take a tape copy home for some screen shots. Monday May 20 ------------- Rip out character animation routine carried over from Gribbly's Day Out. Implement clever new one. Squeeze three numeric counts into 1 byte and write a hefty routine to maintain all counts independently. Save a byte here, save a byte there. Get lots of lovely room for other stuff. Great! Still don't know how the robots can be made to behave properly given all the different types that will be running around. This week is not going to get any easier. Tuesday May 21 -------------- An average morning's contemplation until ...ZAP WHIZ POW ! An idea for a game within the main one, fighting for control of a new robot. Instead of just a graphical sequence showing the takeover of a new robot, why not have to play for it, you against the robot's brain? Base it on logic circuits and use some existing routines. A whole new game segment in a small space! Wednesday May 22 ---------------- Get stuck into new transfer game. Get screen setup working almost perfectly. Game is beautifully simple but under pressure it has great possibilities. Now I've gotto convince it not to give impossible setup situations, since it is relying n a stream of random numbers, courtesy of Sidney the sound chip. Thursday May 23 --------------- Finalise the screen setup for the transfer sequence. Work out which arrangements of play elements are impossible. Devise rules to ensure that they are never selected. Discover rules are very simple which makes life easier. Feel pleased. Work out how to run the game itself and begin coding when Andrew Hewson drops in to spy on us. I proudly demonstrate the new creation. "What on earth is it?" he says. Not one of his most helpful, constructive of illuminating comments. I rage inwardly. Friday May 24 ------------- Attempt to implement the mechanism that runs the transfer game. Do the design. Try to get it right. Scrawl some rough diagrams. Looks good Write the code and try it out. What a mess! Study notes. Twit! Should have read notes more carefully when writing code. Make corrections. Ahaaa! Every-thing's nearly working except for annoying flicker. Search for cause of flicker. No luck. Start to grumble. Search some more. Still; no luck. Grumble out loud. Okay. Decide that annoying flicker is not going to get me annoyed. I can either get game working but with sprites that flicker, or I can get nice steady sprites but it won't work. I try grumbling REALLY LOUD. No effect. This program is clearly deaf. End of day. It's Friday and I'm tired. I go home. Grumbling and annoyed. Monday May 27 ------------- Bank Holiday. Play a bit of Guardian. Mend joystick with four lumps a aluminium to stop contacts from bending. Study listing of transfer game whilst pretending to do something else SO as not to get annoyed. Got it! A logical fault. Annoying flicker disappears. Am annoyed for not spotting fault earlier. Get carried away. Can't see why one routine is called twice so decide to fix it so it doesn't mind being called twice rather than fix error properly. This is called the steam-roller solution. Calm down. Feel guilty about steam-rollering. Tuesday May 28 -------------- Work on getting the transfer game looking vaguely presentable for some more screen photographs. Put in a lot of icing like displaying the number of gizmoes left and a countdown to game start etc. Game now takes up about 2K bytes and is bigger than had hoped. I'II have to squeeze it in somehow. Wednesday May 29 ---------------- Study transfer game. Tune up speed and duration. Robot player has no intelligence so give it a couple more shots on average to make up for stupid moves. Change colour of robot player from blue to purple to show details better. Decide transfer game can now be shelved for later inclusion in main sequence. Sit back and enjoy a warm glow of self-satisfaction. Decide to reward myself by having fun designing logo to appear on side of main spaceship. Fiddle with R,F. for Robot Freight. End of day. All attempts at logo are garbage. Warm glow fades. Thursday May 30 --------------- Sorted out some bits of documentation about Gribbly's Day Out and tidied them up. Got the new screen shots back, still underexposed, this game is going to cause people problems because of its white background, chuckle! Back to main game. Do some more graphics -- a better looking lift, a block of consoles and some different floor sections. Work out what information is required to get the lifts functioning, not much fortunately. Friday May 31 ------------- Key in lift shaft routine. Reorganise the screen setup routine tidying up all the initialisation activities. Up to now have been working on test data. Now things are getting serious. Decide I have to key in some real decks. Suck my pencil whilst considering the problems of lift co-ordination between decks. Hmmmm ... definitely going to be complicated. Some hard thinking yields immediate results - I get a mouthful of pencil shavings. Oh happy day! GDO gets Game of the Month in CCI.. Decide this is a good opportunity to ask boss (Steve Turner) for new pencil. Tuesday June 4 Doom and gloom this morning. Program keeps on crashing. Slog through code finding several errors Serves me right for rushing through it yesterday. Eventually I can tour around all the decks and use lifts if I'm careful. Worry about excessive pause on leaving lift whilst machine sets up current deck. Decide to do setup whilst in lift. A lot of extra work but result is nice. Very elegant. Eeerk! Thunder and lightning in the outside world. Take fright at possibility of losing all today's work due to power surge. Scramble to save everything in sight, (Andrew was obviously luckier than we were, the same lightning-induced power surges caused the ZZAP! computers to crash taking several K of unsaved copy and subscribers with them. Much shouting and cursing and retyping …! -Ed) Having a bit of trouble telling the difference between orange and red as an alert status. Since green, yellow, orange and red are traditional, this could be a problem. Commodore orange isn't bright enough. Wednesday June 5 ---------------- New pencil arrives. Chew on it whilst considering how to shuffle storage to give more space for deck data. Assign last 4K. More changes will require a goodly amount of pushing and shoving from now on. Work out mechanics of enemy robots. Many will operate on a network of invisible roads and junctions. Some may be sentries, others just 'on-the-beat'. The whole ship will have its robot crew defined at the start, and each decks-worth will be expanded and used on entry to that deck. Each deck will have a main variety of robot, along with a random selection of others. Thursday June 6 --------------- Continue to scribble robot notes. Steve suggests a neat way of compressing three bytes of information into one. He's a bright lad. Gives me a lot of patrol routes and junctions. Reminds me of my IBM mainframe game Survive. Hmmmm ...a problem. What happens if a robot wants to come onto the screen when all eight sprites are already busy? In GDO I kill the new object and nobody notices. I could lose it temporarily and let it reappear next time you visit the deck. No, better not. Someone's bound to notice and moan about it. Need something to speed things up when most robots on a deck are gone, such as the baiters in Defender. Have to sleep on that one. Nearly redefine the walk to show a 3D aspect, but don't want to do everything in 3D. Decide it looks a bit too ugly. It's been very much a thinking day. Friday June 7 ------------- Off to the Commodore Show in London to spy on the opposition! Don't see anything particularly devastating. Enjoy listening to the music played by Jeff Minter. Monday June 10 -------------- Steve's out today, so get to work on a pretty title screen. Do some drawings and like them. Try same on screen. No. Not right. Dabble for a while with graphics on screen and come up with a different style of letters. Not bad. I want it to look like the letters are stamped on metal. Use part of Commodore graphics set for first time ever. Tuesday June 11 --------------- Oh, oh oh oh oh! Behold! An idea. why not use work from title screen for deck walls? Leap around room full of brilliance or insight. Steve tuts and hisses at disturbance. Calm down, try a small setup. Nag Steve to look at possibilities. Decide to try a whole deck in new scheme. Hack, hack, hack for ages and then fire up new version. What a transformation! Very metal, superb and solid. Stop for a cup of tea to celebrate progress. Set up some alternative colour sets and, using light colours for background, now have schemes in yellow, green, red and blue. Game now looks totally different, although consoles and lifts work well with the new set. So just by chance and by doodling on the character set editor, the game has undergone a major change in appearance. Much self-satisfaction with new look. Nobody commented either way on the previous look, except to say that it's different, ie politely saying that they don't exactly go overboard on it. Burn the heretics, I say. Drown the non-believers! Wednesday June 12 ----------------- Old turbo saving routine must make way for tables of data. Five minute job think to myself. Hours later I'm still hacking at them. Curse myself for patching and fixing them in the past without recording the changes. After much disk and tape loading and saving the new turbo works properly. Fix a couple of small details in the game. It now takes 20 minutes to assemble the game from source, it's just so s-l-o-w and when it finds an error right at the end ---aaaarrgh!! How long can Andrew's new pencil possibly last? Will the Commodore character set survive the launch into space? Will the cat ever come back? Will we ever see a Paradroid? These questions and more may be answered next month, who knows ? **The birth of a Paradroid - Part Three** (Zzap64 n°5 Septembre 1985) ________________________________________________________________________________ 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 privilliged insight into what it must be like to cull from the keys of a Commodore 64 the trills and spills that will make a hit game. This month having forgotten his fight with the cat and the lost ruler, Andrew turns to the more interesting aspects of programming like pencil chewing. ________________________________________________________________________________ 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. 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? 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. 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. 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. **The birth of a Paradroid - Part Four** (Zzap64 n°6 Octobre 1985) ________________________________________________________________________________ Here is the final part of ANDREW BRAYBROOK's diary of events leading up to the completion of his new game PARADROID, as the pace host up to get it out in time... ________________________________________________________________________________ Monday July l5 -------------- Finally discovered why the controlled robot doesn't bounce off the other robots. Seems I was a victim of my own brilliant idea, Anyway it's working now for the first time and makes the game a lot easier. Had to get rid of the blue title screen colour scheme because I couldn't find another colour to write on it with. White was the only colour I could use, and that's not allowed because at one point I change the background to white. Put the program name at the top of the screen in fancy writing. Spelt that wrong in my haste. Made up the first rough version for Andrew Hewson to look at. There's still a lot of data to be put right, mainly relating to the robot enquiries, and two important routines are still not in. One is the sound routine This I shall swipe, from Gribbly's at the appropriate time. The other is the firing of lasers, by the meanie robots. Tuesday July l6 --------------- Corrected known errors in the patrol table and deck plans, and distributed some more 'decorative blocks' around some of the decks. On compiling the deck plans, I had only 2 bytes to spare out of 38/40 reserved. Close shave that. Noted all the errors in the current version ready for update and then got down to organising the robot data. Printed off some more forms to assimilate all the data and filled some ~ with data on the 12 robots currently existing. Will have to extend the dictionary of words in the system for some new descriptions to go in. Wednesday July l7 ----------------- Designed some more sprites for the robot pictures, including messenger robots, a maintenance robot and the big meanie cyborg, the king of them all Now have 17 of the 24 robots done. Had to think up descriptions for them all, and added another hundred new words into the bank of words. Keyed in the appropriate data for the descriptions and sprite displays, then fired up the game with the new data. Only 3 minor mistakes to correct, then everything looks great. All the robot data is written on paper because it's the safest storage medium in the house, bar none! Thursday July l8 ---------------- Test pilots got their grubby mitts on a safe version of the game yesterday. The Verdict: quite unplayable. Getting the hang of it slowly but don't like it much. The control mode has got quite complex and this is mainly due to the lack of a second fire button. Don't want to use the keyboard because it's inconvenient. Can't use 2 joysticks because not many people have 2 serviceable joysticks. Large headache ensues from trying to think of a new easier control mode. Instead of pressing the button to choose which of the robot or the gunsight to move, they must each move independently but at the same time, and from the same input. Then just pressing fire will shoot the guns, activate transfer, log onto consoles and activate lifts! Can it be done? One other problem of the control mode was that if you wanted to fire at an approaching robot, getting into fire mode was via transfer mode, so we tended to it by accident. I can prevent that by insisting that contact occurs for more consecutive cycles with the button down. Then you can move away or release the button if you don't want to transfer. Difficult problem to sort out, causes late night thinking session. Friday July 19 -------------- Put in the new trial control mode. Only has 2 modes, mobile and transfer. The gunsight is supposed to behave intelligently and try to be where you want it all the time. Turned out to behave like a well-known flying hamburger: got a mind of its own, does what it wants, better success when you don't try to control it, and generally useless! Ripped all that out and had a rethink. Simplicity being the order of the day, tried putting the gunsight on the screen in a position proportional to the speed that the robot is travelling at. Unfortunately the gunsight seemed to want to leave the screen instead of heading for the centre when stopped. Turned out to be because the robot doesn't really ever move, but the deck layout moves in the opposite direction to create the illusion of movement. Hacked about some more. Control mode still doesn't work. Monday July 22 -------------- Got the new control mode working yesterday. Don't like it. Test pilots don't like it. Thought about it some more. Decided to design the last 7 robots instead. The last 7 are mainly the big meaty battle and security droids. Experimented with a couple more new-type appearances. Got some very nice-looking beasties out of the sprite editor. Still don't know what to do with the control mode. Tuesday July 23 --------------- Noticed that the last deck had an extra wall tacked on to it. Realised how it had got there and set about shortening the deck data. Had to remove 4 bytes. Managed to shave off a couple here and a couple there. Carried out what should be the penultimate graphics update, tidying up any loose ends and adding the final words into the text dictionary. Also put in data to display the last 7 robots correctly. Had to adjust the appearance of 2 robots slightly. One of them appeared to have long black hair in curlers. Looked like the archetypal Mother-in-Law! After much nocturnal thinking about the control mode, I've decided that the gunsight will have to go. The concept was rather elegant, but it's just not practical in a battle situation. You not only have to get firing direction right, but range as well. I think I'II have to revert to the old-fashioned, tried, trusted and medically proved eight directional dual laser. Thus Andi (second test pilot) will be able to fire a shot behind him as he runs away, as well as fire forwards to clear the escape route. This is because the gun will fire in the direction indicated by the joystick, and NOT by the direction of movement of the robot. The robot is slower to respond to the joystick because it has acceleration and momentum. This system should speed up the pace of the game considerably. I'll have to put my gunsight in another game sometime. Stay tuned! Wednesday July 24 ----------------- Improved the transfer game to display who is who. Since you can pick sides, it's easy to get confused. It now displays the appropriate robot sprites on each side. People who have played the transfer game don't like the tossing the coin situation if the transfer is a draw. They'd actually rather lose every time than leave it to a 50/50 chance. Strange! I'd rather have the chance myself. I could have a game option to alter the transfer draw-game situation. No. Think I'll give you a replay in this case, another chance to transfer. Started work on the new laser firing routines. The only sticky bit is working out which sprite to display for lasers, which depends on which way you point them. I have 4 sets of 2 sprites of reversible twin lasers to pick from. Perhaps a random choice will be more likely to be correct than if I sit and think about it! Discussed the possibility of making 'The film of the diary'. Decided that Harrison Ford would be ideal to play myself, with perhaps Woody Alien playing ST. Decided to abandon the scheme. They'd probably want more than a free copy of the game! Thursday July 25 ---------------- Put in the firing laser routine. Fired the correct images in all directions first time. It got a bit confused when no direction was set, and the laser bolts just sat on top of my robot. ST then had the brilliant idea that any robot under control could fire its own weapons system. That presents the problem that many don't have weapons. Since the Influence Device that you ultimately control has a small laser turret on top, this could be used as a backup low-power weapon only. Upon transfer to an armed robot, that robot's weapon system takes over, and is more powerful. There will be 4 grades of weapons then, lower-power, twin laser, high power single laser, high power twin laser, and disrupter. The disrupter just hammers all robots in visual range that are not disrupter proof. Since other robots carry them too, they will be used against you. The game has more speed now, as intended, so I'm feeling a lot happier about it. Friday July 26 -------------- Tuned up the destructive powers of the different weapons. Cured the error that meant that shooting big robots with the 'Pea shooter' lasers actually gave them energy! Put in the enemy firing routine. Haven't worked out how to deduce the correct laser sprite for the right direction but it should at least fire something. Instead it looked pretty similar to the previous version. They didn't fire anything at all. Increased their chance of firing, but nothing. Not interested. Must be pacifist robots. Monday July 29 -------------- Found out why the robots weren't firing much. Double use of a variable. Fixed that. Also fixed the code that would have made them fire in exactly the opposite direction. Realised also that the clever-clogs routine to determine which angle lasers to display didn't work because when ST thought of it, he assumed that the 6510 chip would be the same as the Z80 when setting the carry flag after a subtract. Wrong! Totally the opposite. Immediately the old robots really let fly, lasers, distributors, everything. All of a sudden, the ship becomes a battlefield. You get everything your own way on the easy decks, the little robots can't fire, but as soon as you meet the big boys, whoomph. Needs plenty of tuning up, but it's looking good. Tuesday July 30 --------------- Second Pre-Production copy sent off to Hewsons today. Just the sound routine and tuning up to go. Spend much of the day playtesting the game, looking for any faults. Found a couple of subtle errors and fixed them. Everything seems to be working as designed now. It's much tougher than before and still haven't managed to clear the whole ship of robots, although I've come fairly close. I'm beginning to form ideas about how to play it. Gordon Hewson phoned to check on progress and suggested that instead of just being blown up when out of energy, if you're controlling another robot, it should be destroyed. Thus the Influence Device escapes to possibly fight on. This was such a good idea, and ties in with a similar result of transfer failure, that I put it in straight away. Your current robot explodes, leaving the Influence Device beneath, but with low energy. Thus, provided you avoid any remaining incoming shots life goes on. Taking home the sound routine tonight to scribble some modifications, ready for keying in tomorrow. Wednesday July 31 ----------------- Altered 'ye-olde-faithfulle' sound routine incorporate some new processing for more varied sound. Built a small test-bed program so as not to have to the whole game up just to invent some sounds. Played about with some variables. Got it to sound like Ancipital then Elite. Cured a few bugs in the sound routine and started again. Got a sound that should be good for background noise, just left running when there aren't any other sounds to do. It's quite difficult to listen to a sound that you like, say on TV, and then try to figure out how to get SIDney to mimic it. Cards on the table, I really can't cope with sound sometimes. It's just a case of trial and error, play with the variables until you hear something you like, then assign it to a particular event in the game. Thursday August 1 ----------------- Penultimate day today. Must finish by tomorrow evening. Got to grips with the sound routine today. Produced 27 sounds, including 2 that I hadn't intended to put in. Assigned all the sounds to their appropriate places in the program, and remove all the development calls, like the exit to the monitor. I need the last 1K memory which was for the monitor's benefit. Re-assembled the program with great anticipation. What a time to get another disk write error. Now it won't assemble. Had to transfer all the source files to another new disk. Finally got the new supersonic version fired up. Many sounds seem slightly different from what I created. Upon inspection it appears that the sound routine has an error on it which didn't show up earlier. Fix that. Now it sounds almost as intended. Great! Friday August 2 --------------- The final day. Decided to ditch the idea of music while the title screens are running. It seems that you need rather a lot of music to make it interesting. I haven't much space for a tune, no more than 150 notes on each of 3 voices, perhaps 20 seconds worth. Most people that I know switch the music off after a short time anyway, whatever game they're playing. Decided to opt for a random sound generation system, as accidentally discovered yesterday. It's obvious that the sound chip knows much more about sound than I do, so I'll just let it use its own random numbers to generate sounds. Having set that up, it sounds like robots conversing, in robot language of course, like R2D2 with a lot to say for himself. Played the game looking for errors and cleared the whole ship with no fiddles for the first time. Spotted 1 or 2 items worthy of alteration, but nothing major. Putting a version on cassette to send to Hewsons. Hopefully it will require no further alterations, and is thus complete for my pay, although much still needs to be done before it goes on sale. ________________________________________________________________________________ From now on the story moves to Hewson Consultant's HQ in Abingdon, where Gordon Hewson takes it up. ________________________________________________________________________________ GORDON'S STORY Monday August 5 --------------- Paradroid arrives in the post as promised. Make mental note to thank Andrew and nip out the back to start playing it. Spend half an hour tracking down a free C64. We never seem to have enough machines. Escape to a corner of the warehouse -- noisy but away from the phone. Start playing. Oh yes, Oh yes. It's really come together since I last saw it. Good old Andrew. Start off shooting everything on sight. Then discover the transfer game. I use the lifts and wander all over the ship. Get a definite feeling of space. Hmmmmm... An hour later and I decide I like the unique feel of arcade action and strategy but I'm unhappy about the joystick handling. Spend half an hour trying to pin point the problem for Andrew. Right that's enough. I mustn't play this game all day there's work to do. Debbie says the roughs of the artwork (the picture to go on the cassette case and in the advertisement - Ed) arrived. Oh disaster! Back at my next desk to study artwork and I hate it. Call in Debbie to discuss it in detail. We study the calendar and realise we have to act very rapidly if we are to change it. Fix appointment with advertising agency for tomorrow. Tell Andrew (Hewson) the bad news. He isn't very pleased but it's too bad. If we are to fix this artwork we have to drop everything to get it done on time. End of day. Contemplate events. I hope we can fix this in time. Tuesday August 6 ---------------- To Brighton with Debbie to see advertising agency. What on earth made us choose an agency so far from our base in Oxford? All day at agency struggling to describe to them what we need for Paradroid. Grab a pork pie for lunch -- these business lunches are not all that they are cracked up to be! Leave at 6.30 with a headache and a rumbling tummy. Stop to eat on the way home. Arrive at Andrew's house at 10pm to find him dozing in front of the television. He runs Debbie home and then we discuss the artwork problems over a cup of coffee. It's been a long day. Wednesday August 7 ------------------ Play Paradroid again. Tear myself away to phone Andy Braybrook and discuss handling problem. Many ideas thrown up and discarded. Decided it needs more thought. Thursday August 8 ----------------- Andrew (Hewson) is getting agitated. The press are enquiring about preview copies for Paradroid. We decide that we have to hold them off until the handling question is resolved. We've got a backlog of work to go through the word processor and Andrew's fidgeting about that too. Staff will insist on taking summer holidays! We decide that the Paradroid instructions must take precedence over other word processor work. Friday August 9 --------------- Steve Turner rings to say that he and Andy Braybrook have been working hard on the handling. He sounds optimistic so maybe they've cracked it. I hope so. Tuesday August 13 ----------------- The new artwork roughs arrive. They're not too bad. Debbie and I spend hours pouring over them and then hours more on the phone to the agency. Wednesday August 14 ------------------- New version of Paradroid turns up but I have not time to play it. Today is the day when we are shipping the first commercial copies of Southern Bell (for the Spectrum). A month's worth of business all in one day because all the shops and distributors need stocking up. Everyone's working flat out. We finish at about 7pm and I run up Paradroid. I get on really well and hit my highest ever score straight off. Yes, the handling is right. Perfect. make it to the top robot -- a 999 -- and spend a violent 20 seconds blasting everything to kingdom come. Very satisfying. Thursday August 15 ------------------ Debbie orders the film master for the Paradroid bar code. Friday August 16 ---------------- The bar code master arrives. We're getting there. I look over our launch plans to get Paradroid into the shops on the 20th September. Andrew Hewson is busy organising screen shots, press releases, press copies and the like. We check out the print schedule. The stocks of cassettes, shells blank tape, library cases are checked by Bill, the Production Manager. One of our programmers, Mark Goodall, checks the mastering system and the security system. Everything looks OK. We've got a lot of work to do by September 20th but it's under control. End of the day and we prepare to go home. 'Aaagh', Debbie wails from her office, 'I've forgotten to order the side labels.' Gosh SHOCK HORROR!! Can the lack of side labels possibly hold up the release of Paradroid? Find out next month in Zzap! when we bring you not only the film of the diary but the REVIEW OF THE GAME! ________________________________________________________________________________ Some notes and observations from Andrew Braybrook At this point, the following items have been used in development. 2 Pads of A4 square paper 1 Pad of A4 lined paper (Mostly for this diary!) 15 Floppy disks (4 retired due to errors) 9 C15 cassettes 3 pencils (type H) 1 shatterproof ruler, (1 piece still not found) 1 quickshot II joystick (couldn't stand the strain) 300 sheets of print out paper (approx) 5 man-months of effort (850 man hours) Also purchased for development: 1 hex calculator(invaluable) 1 monitor cartridge (useful) At this point it is interesting to read the original scrawled notes on a small piece of writing paper that I wrote one evening all those months ago. Some ideas were curtailed for one reason or another, other ideas were amplified, but the overall direction of the game was there, although very little graphical detail had been thought of. Much of the game's look today occurred by trial and error and a certain amount of good fortune along the way. Here is the original specification in full: Cute and hi-tech don't go together. Instead of robots, just use the digital specification numbers as per fighters in Lunanack. Player has access to detailed data specifications of robot. Player controls an 'influence' which may be transferred from robot to robot at a cost to the source robot's energy of a 'takeover' or 'dominate' cost of the robot to be taken over. The reverse process will be possible, provided sufficient robot energy is available. The new robot's energy value will not be known, of course, until transfer is complete. The weak robots cannot, say, take over the strongest, but have to climb a flexible ladder in stages. Build a picture of robot with data from bolt-together pieces. Each robot has: Internal energy for all functions. Dominate value, based on robot's intelligence and power. Security class (Privilege)- allows access to computer data, security areas, etc. Armaments, or none. Mobility, maximum, but degraded by damage. Armour, protection from shots, not usually able to withstand 1 direct hit. Other miscellaneous background data. eg year of manufacture, model no. Types of robot: Menial droids. Personal servants. Protocol. Ship maintenance Security robots Battle droids Command robots.