THE CONVERSIONS CAPER
Well-known games author Peter Scott reveals some of the secrets of his technique for squeezing quarts into pint pots
To say that I specialise in converting games to the BBC Micro would be an understatement. Of my last eight games, seven have been conversions and there are another two lined up.
Doing a game conversion presents a completely different set of problems to creating and writing an original one. The main task is to decide what can go in and what has to come out - and the overall goal is to keep everything in.
Unfortunately most games originating on other micros are written specifically to take advantage of the hardware facilities they offer - such as the hardware sprites on the Commodore 64. Now it's even worse with converting games from 16 bit machines with 1 Mb of memory, making my job even harder.
I try to avoid seeing too much of a game before agreeing to convert it. This may sound crazy, but if I'd seen some of the originals first I'd be doubtful that it could be done at all. Once the decision is made it has to be done somehow.
Some companies offer more help than others for the conversion. With Barbarian I was sent discs full of source code, a comprehensive cheat version, original graphics files and telephone help numbers. But, as it turned out, I used only the disc.
Since then all I insist on is a cheat version and complete solution - it's vital to play it through thoroughly to work out when, where and how everything is done.
Memory always presents the first, and most persistent, problem. A Commodore 64 has 60k to play with compared with the 25k maximum of a BBC Micro. Multi-loading doesn't help, as games are usually designed around set levels and load points that can't be changed. But luckily the original is often wasteful of space which can help - in Predator four lengthy 60k loads were reduced to just one of 25k.
Leaving memory aside, each game usually presents one special problem in the conversion process. Once that is cracked the rest follows naturally - if not easily. Here's some of the difficulties I've encountered and how I tackled them:
The first conversion I did was Barbarian - the highly rated chop `em up on the Commodore 64. The main problem was this: How can the automatic opponents be controlled? Only by cheating. When the human player starts a move it's stored and the character goes through a sequence of up to 10 moves before the next decision can be made. So the micro-controlled opponent can be made to react as soon as the attack has been registered - instantaneous response and an unbeatable opponent. After this the difficult bit is fine-tuning it so that there's a gradually increasing level of difficulty. This process took almost as long as writing the game itself - everybody at Superior Software, as well as myself, played it hour after hour trying every possible way to fool the machine.
The advert caused a stir, but in my opinion the only thing wrong was the hackneyed rescue the woman scenario.
The Last Ninja was the next job and it's one I'm still very proud of - the sheer size was daunting, with well over 100k brought down to 60k. The main obstacle was the 3D scenario.
The Commodore 64 used hardware sprites and an immensely complicated distortion routine to change 2D base graphics into 3D versions for display on the screen - it could take nearly 10 seconds for one screen. I scrapped all this and used sprites - lots of them.
If you watch carefully you can see that the Ninja hardly ever goes behind anything - which simplifies the programming tremendously. It can seem that his feet go behind screen objects - but they don't, they're just both the same colour, black. Pretty sneaky.
Next came Barbarian II which, I think, is one of the most graphically impressive games I've produced.
The programming involved in getting the massive sprites moving smoothly was the main task here. I ended up using compacted graphics expanded on to a backscreen then copied almost immediately to the display.
Storing the scenery proved very memory-hungry until I realised that all I needed to do was redraw the entire screen on the backscreen before putting the sprites on, then display it.
After that came the couple of hundred frames of animation - a very long job. The game solved the sexist scenario problem - you could play male or female - which doubled the graphics.
My first film license was Predator. Here the overriding programming problem was the parallax scrolling used - the foreground moves faster than the background - and the main sprites being in front and behind objects.
This was solved quite simply by using the backscreen to build up the graphics then transferring it to the display with hardware switching rather than software. The sprite routine was quite complex as it had to decide which to draw first depending on distance from the viewer.
The first 16 bit conversion I had to tackle was Ballistix. Luckily the original was by Martin Edmondson who had written many BBC Micro games and he provided invaluable help. The difficult task was the movement of the main ball, working out the angles for rebounding smaller balls and having everything moving around smoothly and logically into the bargain.
The solution - as it often proves to be when programming for speed - was to use a look-up table.
It was very extensive and derived from mathematical formulae, mapping the speed and angle of any ball hitting another one Momentum was then added and a lot of fiddly fine-tuning began.
Getting the screen to scroll pixel by pixel wasn't too difficult using a good sprite and the ubiquitous backscreen. The graphics themselves were a problem: Going from a 320x200 16-colour Atari ST screen to a 160x160 4-colour BBC Micro one. Compromises had to be made but 300k went down to 26k.
After Superior Soccer - my first non-conversion in many months - came Lest Ninja 2. This was identical in form to the original but had twice as much graphics.
The answer was a highly efficient compaction routine which squashed the originals down to 40 per cent of their initial memory requirement. Rewriting old code proved to be hard - trying to remember which piece of code did which task.
Last Ninja 2 had lots more opponents and many more animated effects - in fact there are 100 frames for the main sprites alone - not counting 70 screens of detailed backgrounds.
And there was a bug, which was discovered the day before duplication - when I was visiting a friend in Scotland. It was mostly fixed after several hour-long phone calls, but I still had to come home early to finish the job.
I'm currently working on Hostages from the French software house Infogrammes which specialises m highly original and sometimes quite strange games and are eager to support the Acorn machines.
Hostages has three levels involving arcade and strategic skills. Each is completely different in form and play - it's a bit like programming three entirely separate games.
After this comes Sim City which is a very nice strategy game where you take control of a city and have to build houses, provide services, cope with disasters and so on.
I feel that conversions are vital to keep the BBC Micro visible in the software market. The High Street stores are much more likely to stock a game with a recognisable name.
So if you want versions of games
like Operation Wolf, Robocop and Batman from Ocean, or Strider,
Black Tiger and E-motion from US Gold why not write to them?
It's worth a try, and it keeps a certain programmer off the streets.
This article appeared in the July 1990 edition of the "Micro User", published by Database Publications.
Scanned in by dllm@usa.net
http://www.stairwaytohell.com