Birth of a Paradroid - Part 1 from issue 3


The Birth of a Paradroid

( I don't actually have this issue anymore (it must have got lost over the years), so I was bowled over when the following arrived in my mailbox, all formatted and ready to go. Many thanks to Dave Foreman for sending it in. - Alex )

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 on 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 available on the 64 at any one time). Despite being a view from above, I intend you 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.

"Horrible. I'm going to have to change all the graphics. Bleaaahh! "

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.

"Design a new robot. It comes out looking like Kenny Everett with short legs. Ponder - do robots have beards? "

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 Everett put a hex on Andrew's prog? Will Steve stop the cat from eating the ruler? Will the paranoid paradroid learn to shave? These and other questions will be answered next month!!


This feature was typed in/OCRed by Dave Foreman


Birth of a Paradroid - Part 2

bottom
 


Home