QUEST
TONY OAKDEN reveals the problems he found whilst writing this arcade game
QUEST is a large arcade adventure I began programming about 18 months ago. It features a young lad called Walter Cobra who goes in search of the mysterious Golden Dragon.
Most games of this type tend to use either Mode 2 or Mode 5. I wanted Quest to be different from others on the market, so Mode 1 was used.
This gives very fine detail, but unfortunately is limited to four colours. However some pretty effects are possible by dithering.
This is a technique where alternate pixels are plotted in different colours. Due to the low resolution of most monitors and TV sets they run together to give another colour.
The palette was switched between screens to brighten up the game even more.
The BBC Micro version uses interrupts to keep the colours at the top of the screen constant, but despite trying several techniques this could not be achieved on the Electron.
This interrupt, and the hash at the top and bottom of the screen, are the only differences between the two versions.
Electron users might be interested to know that the game was just as difficult to fit into a BBC Micro as it was into the Electron.
There are many different types of animal in Quest. Each has a different appearance, and in addition they also have individual characteristics and behaviour patterns.
This posed problems due to the limited amount of memory available, so certain routines had to be shared by different sprites.
Take the small robots which bounce off the walls: They use the same collision detection routine as the man, but because they are smaller the routine needs different parameters. This worked very well - except that they also bounced off the man. To solve this problem a method was needed to make them attack if they were touched.
The game already contained a proximity detection routine, used by the bats to detect the man if he got closer than about 10 pixels. The robots use the same routine, but again, they use different parameters.
One feature peculiar to Quest is the ability of certain animals to move freely between screens - ghosts and robots both move on and off screens.
The robots always start at the same place when you enter a screen, but they will sometimes come on to a screen while you are trying to negotiate an obstacle.
The ghosts will follow you between screens and are quite intelligent.
The idea is to try to tie the action on different screens together, giving the feel of a complete game rather than a series of individual screens.
All animation is controlled via a series of flags and parameter blocks. When a new screen is drawn, all the flags are cleared and if a particular animal is needed a flag is set and the corresponding parameter block initialised.
The structure of the animation routine is very simple:
- The keyboard is scanned.
- The man is moved accordingly.
- Any other animated characters are moved.
- Has the man reached the edge of the screen? If he has, draw the next screen.
- Has he run out of energy? If so, end the game.
- Loop back to the start.
Because there is more action on some screens than others, a method was required to run the animation at a set speed. I eventually did this by resetting TIME to zero at the beginning of the animation loop and then checking to see if it was less than eight at the end.
If it is, the program waits until TIME is greater than eight. The Basic equivalent is:
This locks the animation at a maximum of one frame every 0.08 sec, or 12 frames per second. By varying the time limit, different effects are possible - that is how the Time Warp feature was created.
The resultant game is, I hope, a good blend of well animated characters and interesting patterns. However, the code is a nightmare of nested loops and subroutines.
A good analogy would be a swan, which from the bank appears to glide gracefully along, but under the water has huge ugly paddles frantically churning away!
The map, is made up from an 8 by 10 grid of screens. The address of the data for each screen can therefore be calculated, eliminating the need for a look-up table.
This made designing the game very difficult, as each section of the map has to connect and the puzzles had to be spread out, with many challenging animated problems in between.
Each screen is built up from 15 blocks on a five by three grid. This is a rather coarse way of doing the job, but by using one byte per block 256 possible shapes are available. For example, block number two is a solid square, while 17 is the elephant.
In fact only numbers 0 to 63 are defined, 64 to 127 use the same data as 0 to 63, but are inverted. Numbers 128 to 255 use the character set.
By having two passages in one block it was possible to build some very complex mazes. If you play the game on a standard size monitor there is something like 50 feet of passages in the ghost maze alone.
Each block is built up from an eight by eight grid of characters. These are the smallest element, and consist of things like the bricks, leaves and metalwork.
Again there is a total of 256 possible characters, but only the first 64 are defined as data. The next 64 are inverted, and by EORing the character with a striped mask additional shapes became possible.
Some of the objects in the game, such as the key handles and cross, are also used to create interesting effects.
Finally, the operating system routine for drawing triangles was incorporated, but an undefined graphics number was used to obtain the striped effect.
A small utility was needed to design all the shapes and sprites used in the game. There did not seem to be any suitable commercial packages available, so an editor was written in Basic.
The sprites and other objects were initially designed on paper and then modified. I was particularly pleased with the caterpillars and ghosts.
As the sprites are printed on the screen a routine was included which doubled their height, allowing the display of nice big sprites.
Unfortunately, the Electron is not fast enough to draw a lot of large sprites in Mode 1, so they are automatically drawn at normal height if there are more than a certain number. They are EORed on to the screen, because this is the simplest way of moving them about without corrupting the background.
I have always considered that it is the puzzles in an adventure which make the game interesting.
Quest was to have as much variety as possible. I particularly wanted to avoid the situation where every puzzle is solved by simply taking the appropriate object to the correct place.
Wherever possible extra animation was included when a puzzle was solved. A good example is the elephant, which has to be moved to get into the next section of the game.
I wanted the elephant to actually move out of the way rather than simply disappear.
The sprite animation routine could not be used because of the beast's size and the way the data is stored. So a fast software scroll was used to actually move each byte of the elephant in turn, one byte to the right.
This worked very well and the same routine was used with several other objects.
Another puzzle I was keen to include was a time-related one. To do this a real-time clock was needed. It runs independently of the game and uses the interval timer crossing zero event to generate an interrupt every 60 seconds.
The routine works by resetting the interval timer to -6000. It is incremented by the operating system every 0.01sec, independently of the game.
As it crosses zero an interrupt is generated which passes control to an interrupt routine which resets the timer to -6000 and increments the clock. Control is then passed back to the main program.
Several objects in the game have to be used correctly. The program allows them to be dropped and picked up again at almost any point.
This was quite tricky and meant having to keep track of their position and also make sure they were dropped in a sensible place - not floating in water or in mid-air.
This meant I had more scope for problems involving lateral thinking. I also had a lot of headaches trying to make sure the player could not get into areas of the game by using objects in a way I had not expected.
Eight passwords have to be found to log on to the terminals. I had a lot of fun deciding what these terminals should do - and I think some will bring a few surprises.
My favourite puzzle is the music room. This is, I believe, the first musical puzzle ever included in an Electron arcade adventure.
To get the organ to play a true scale was rather difficult. The pitch of each note is stored as data and as the man moves over the keys his position is used to calculate which note is played.
Most of the sounds use envelopes, and a small editor was used to define them. This made it easier to get some quite interesting effects. However, the sounds are, by necessity, very simple and I hope unobtrusive.
I have played Quest all the way through on several occasions and can finish it with the game clock showing 12.06 - about 1 hour 10 minutes real time.
There is plenty of energy available in the game, and providing you stop and think, all the screens can be negotiated without losing too much.
The underwater section is perhaps the hardest, as there is a severe time limit. The secret is to put your head up in the air pockets as often as possible.
The game was programmed on an Acorn Electron with Plus 1 and Plus 3 expansions. With the Plus 3 active the amount of free memory is very limited, so I used ACP's sideways ram and E00 DFS to get PAGE back to E00.
The whole system was generally very reliable, but I did find one or two minor bugs. Trying to save files to disc in Modes 0 to 2 sometimes resulted in disc errors. This could be due to the reduced speed of the system.
Some data is stored in the screen memory and I had to save in these modes. To get around that I used a technique I saw in Electron User, where the operating system is temporarily forced into Mode 6 to increase the processor speed.
I also used this technique to speed up the machine while it is drawing the screens.
When developing a game like this, the source code has to be loaded, modified, assembled and the resulting object code saved back to disc.
The modified source code then has to be saved and the new object code reloaded with the rest of the game in order to test it.
If there are any problems - and you can bet your disc drive there will be - the source code has to be reloaded and the whole operation repeated.
On a bad night I would do this perhaps 100 times, so cassette tapes would be completely useless, and the discs and drive had to be as reliable as possible.
One important lesson I learned while working on Quest was always to keep at least two backup copies of the game. I would also recommend using good quality discs for the main backup at least. I also try to rotate them to avoid over working one disc.
On the BBC Micro Mode 7 can be used for assembling machine code. This leaves about 28k of ram for the source and machine code.
On the Electron, Mode 6 must be used instead, which reduces the amount of ram available.
One dodge to get round this is to assemble the code into the screen memory. Set O% to &6000, P% to the start address of the machine code and use OPT 4 to 7.
You can see the machine code being built up on the screen, and it leaves extra space in the program area for the assembler text. But remember to turn off the cursor.
Quest is my first serious game, and I must admit it nearly drove me to the point of despair. At one stage last year I decided to give up altogether and sell my computer in order to buy an Amiga.
I actually placed the adverts, but then changed my mind and decided to press on and see what happened.
I sent the game to Superior Software just after Christmas and they immediately wrote back to me. Since then I have worked solidly on it every night to get it debugged and versions finished for the other machines in the Acorn range. Superior lent me a BBC B, and were most helpful with suggestions and advice.
I aim to stay with the Electron for a few more games at least. I feel the machine still has a lot of potential and is only now being programmed to its limits.
I am already planning the sequel to Quest and hope to have it finished later in the year.
I have worked out a way to cram
even more into the micro and have devised some devious puzzles
to keep Walter amused.
This article appeared in the May 1988 edition of the "Electron User", published by Database Publications.
Scanned in by dllm@usa.net
http://www.stairwaytohell.com