Interview with Clive Gringras

This is taken from the September 1995 issue of the Acorn User magazine.

Warren Burch and I met in a computer shop called Fairhurst Instruments in Cheshire. Warren had recently breezed through a Computer and Electronics degree at Durham University; I'd just started my Law degree at the University of Sheffield. Within months of meeting we were churning out programs, each constructed with the same division of energy and skill. Warren was the main coder; I was responsible for the ideas and graphics. And out of that fusion eventually came ... Trojan.

Trojan was a three-dimensional space game with combat and missions. It was fast, colourful and championed the true power of the Archimedes, with one problem; Trojan simply was Elite. While Warren and his friend Stephen Pollard brainstormed amendments to prevent the game from infringing the copyright in Elite, I mused on more legal solutions. I can recall the sound of Warren's jaw dropping when I told him of my simple solution: we should write Elite for the Archimedes. After much negotiation with the authors of the BBC version, Ian Bell and David Braben, we were finally given the go-ahead. In May 1991, the twenty-hour days commenced.

Speed or style?

As mentioned earlier, Warren and I had different approaches to the same challenge. Warren would break down a task into logical portions, and then write the quickest, most efficient code to solve the problem. I was the dialectic opposite. Looks and feel were my main concern. This tension between efficiency and appearance, lubricated with black coffees and shepherd's pies, created the quality that Archimedes Elite was heralded for.

The favourite arena fo these compromises was in negotiations about the front-end. In Elite, ships and other objects in space are represented by "golf clubs" superimposed on an elliptical grid, but how do you portray the "golf-club" as moving over the elliptical grid? If the club is simply re-plotted each frame, the previous club will be left on the grid, creating a mess, so you must delete the previous club first; there are two main ways to delete this old club.

The quickest procedure is to plot over the old club with the same shaped club, but in an EOR colour. For our purposes, this means that the grid "underneath" the club is left unaffected and the club disappears. Unfortunately if the two clubs cross one another, the crossed area vanishes.

The slower method to delete the clubs is by brute force. Simply "blit" out all the clubs, "re-blit" the scanner and then draw in the new, moved, clubs. The testing we did on this suggested that it was at least five times slower than using the EOR method. However, when we saw the results of this slower method we were both convinced it was worth it.

The above quandary was not even in the same league as the irritation caused by the golden console itself. Although we knew that the scanner and readouts had to be the conform to the BBC Elite layout, we also knew that we should take advantage of the increased resolution and palette of the Archimedes. I designed about nine different consoles in Atelier - each as artificial as the last. By the time the sprite was compressed into the game, either I would have decided it was awful, or Warren would hate it.

We finally achieved this sought-after depth by chiselling out the centre of the console. The allowed ships and objects to fly slightly nearer without being "clipped" by the top of the console. Again, it caused a slight speed loss because we couldn't simply blit the whole playing screen as a rectangle. but we were finally happy with the console.

For this reason the triangle-plotting routine had to be frighteningly fast. It was the time-critical aspect of the Archimedes Elite. Eighty two percent of game time is spent plotting triangles. Even with Warren's incredibly optimised triangle routine, it remained quicker to recalculate the position of 50 ships than to plot one small fragment of shrapnel. This was why the triangle routine was written in pure Assembler - it had to be rapid.

Of course, not all of Archimedes Elite needed to be written in Assembler, due to the 80-20 rule; 80 percent of the computer's time is spent in 20 percent of the code. There is no speed gain in using Assembler to plot, for example, trading information; C is very capable and the user will never know the difference. Believe us, apart from taking a further six months to program and debug, a 100 percent ARM Elite would not have been perceptively quicker.

Ships that pass in the night

It is probably important to correct another rumour about Archimedes Elite. We didn't merely use the code from BBC Elite, tweak it and the add some colour to ships. The game had to be rewritten for two reasons. First, the code used in the original BBC version was very tight 6502 assembler, a far cry from C and ARM on the Archimedes. The second reason was self-imposed: we wanted to stretch the Archimedes to the limits those two Cambridge undergraduates stretched their BBC to in 1984. It would have been too easy to rewrite a game written for a 32K BBC for a 1024K Archimedes without altering the specification. However, we were of the opinion that Archimedes Elite needed more ships, more interaction and more realism.

The creation of more ships was achieved, primarily, with the use of Silicon Vision's SolidCAD, the most professional 3D modelling package in the Archimedes' market. Sculpting a 3D spaceship out of thin air is never easy; one must work in three separate views and attempt to keep in mind a representation of what the craft should look like on completion. With some kind reprogramming of the modeller thanks to Yunas Nadiadi, we were able to effortlessly port these 3D creations straight into our game. All of the three-dimensional shapes that appear in Elite, everything from the huge Generation Ships and Space Stations to the tiny Escape Capsules and Caimen, were crafted with SolidCAD. We got so carried away with creating new ships, we almost ran out of snake names!

One feature we would have liked to include in Archimedes Elite was point-of-light shading. The reason this wasn't included was not laziness or inability; the Archimedes' palette simply isn't large enough. Either we used 64 colours with, therefore, only four ranges of shade, or 16 colours with 16 shades. Both options looked shabby and less realistic than block colours, and we found dithering the colours looked messy.

This all being said, even choosing block colours isn't easy. One particular choice of colours almost started an argument. I had designed a new-look Boa called, in true Elite tradition, the Boa II - sleek, fast and pink. But Warren objected to this colour. So strong was his aversion to pink that on one occasion Warren tried to compile the code without the ship. We finally came to a compromise that we would include on the Ship Datacards that the ship could be resprayed by Berch (as in Burch) industries on Birera.

[Boa II pic]

Interaction in action

Our philosophy behind Archimedes Elite was simple: the player should not be the centre of attention. To put this into practice, every object in space had its own mission. A ship's behaviour in space was out of our control as soon as the game's ship "director" had selected them for inclusion in a particular scene. For the first time in Elite, ships fought each other. Sometimes we'd fly out to the sun and see 30 or 40 pirates at war, only to be stopped by a band of Police Vipers with their unique white lasers.

We also introduced ships flying in formation: Missionaries in herds; Mambas huddled in groups to protect wealthy pirates; Vipers in sixes and sevens. The temptation was to pick off one Viper with a shot up the glowing boosters - less effective than one on the body, as the laser bolt is refracted by the plume of the booster - and then watch the other Police gracefully break formation like ballet dancers. Unfortunately, this temptation wore off after we realised that five Vipers don't play fair after you kill one of their buddies.

Sorting the men from the boys

Our discussions with David Braben and Ian Bell sometimes ended up with Ian or David saying that a particular aspect of the game was quite tricky. Docking computers was a case in point; Ian said they should "sort the men from the boys". He was right.

The first hurdle with docking, as any Commander knows, is getting lined-up with the letterbox (opening slot) of the space station. This was achieved by marking a point out in front of the letterbox with an invisible buoy. However, lining up with the letterbox is the least of a Commander's worries; it's the "boxing" or matching the rotation of the letterbox that really flummoxes.

We decided to imagine that there was one "arrow" or vector sticking out of the right wing of the ship and one out of the left side of the space station. As the station rotated, the two vectors described various positions of the hands of a clock. When the vectors pointed in the same direction, it was safe to dock without scraping the craft. Therefore we coded the flight program to minimise at all times the angle between the two vectors. Because the flight program actually manipulated the Cobra, the added bonus was that - if present - yaw boosters were utilised, and the player could still use the Cobra in case of trouble. Needless to say, the next communication from Commander Bell began, "Hello men..."!

The programming of missiles was also demanding. If the missile flies too quickly it's no fun to watch and it's even less fun to avoid. If it flies too slowly it can be outrun. But that is only the half of it. If its maximum turn angle is too obtuse, it can end up overturning and circling a target in simple harmonic motion like a fly. And if it can't turn enough, it can overshoot and never come back. So how did we solve this complicated mathematical riddle? With the use of complicated vector algorithms? Intricate formulae? Well, not quite. We used that tried and tested scientific principle of trial and error! By the time our missiles didn't overshoot and weren't too accurate we'd shot over a thousand of the blighters.

Before we're asked, yes, we did use a special Commander with infinite missiles. And, no, we won't be releasing that file.

Some things never change

There are two specifications that should never be changed for any version of Elite. We wanted to ensure that in Archimedes Elite the planets in the Galaxies and the trading prices adhered rigidly to those in BBC Elite. To do this we needed the actual code used by Ian and David. But it wasn't as simple as that. The unseen difficulty was that the code that generated all this information was quite machine-specific, because the algorithms used were tied in with the workings of the BBC. Because we couldn't face having our galaxies different from those in the original Elite we took no chances; Warren wrote a small 6502 emulator to run that section of code.

Clive Gringras

Comments by the Elite pages author:
Amongst other things this article mentions Generation Ships. There are rumours that these were present in the very first edition of ArcElite, although I've heard no confirmation. Apparently there is no ship description for one in the game. I like to think that it has been cleverly hidden somewhere that has (to date) eluded the most determined of hackers, or at least those that I have heard about! It also mentions Vipers having white lasers, not blue. Oh well. Probably a genuine mistake. There was also a "Thank to.." bit I haven't typed out, which mentioned the development of an Elite tune that never made the game. I wonder what that would have sounded like?

Return to the main Elite page