For if you had a certain kind of mind, as David Braben did, the muteness of the machine, when you turned it on, was full of promise, not disappointment. It meant that it was going to do whatever you told it to do; whatever you could think of to tell it to do. It was like taking delivery of a sort of universal engine. If you bought a powerful electric motor and put it on the table in your bedroom at home, you wouldn’t expect it to do anything interesting unless you attached it to a pulley with something that needed driving at the other end. This was the same, with a couple of differences. This engine acted on information, not objects, and it didn’t just impart one kind of change to what you gave it to work on, as the electric motor did when it put objects into motion. If you handed it some information, it would put it through whatever transformation you cared to specify. Really whatever transformation. It was truly universal. At command, it was a slicer, a condenser, a heaper-up, a puller-down, a sorter, a randomiser, a multiplier, a weaver, a mirror-image maker, and far more. Moreover, you could have an unlimited number of transformations of different kinds. You could get it to do another thing to the result of the previous transformation, and then another thing, and then another; you could get it handing some information back and forth between you and it, you taking a turn to change it, then it taking a turn; you, it, you, it, you, it. At any rhythm. For any length of time. (To an amazing extent, this last promise was literally true for the BBC Micro. The BBC’s specification for its TV tie-in machine had called for high-quality components, and Acorn responded with a design so robust that a BBC Micro controlling a geology exhibit in the Science Museum ran continuously for eight years without malfunctioning.) Of course, you had to learn exactly how the engine worked to be able to command it successfully. It didn’t respond to wishes, only to instructions framed exactly right in its own narrow and exact vocabulary. You had to think in its terms, you had to go to it; it wouldn’t come to you. It answered an error with an error. Nonsense in produced nonsense out, with no allowance made for good intentions, no tolerance extended to the nearly right and the half right. But if you had the kind of mind that perceived the universal engine’s promise in the first place, you tended also to have the kind of mind that delighted in mastering the engine’s unforgiving details. In his bedroom in Epping, Braben threw himself into learning the machine with the same intensity that, in other decades, he might have brought to building radio sets, or working out the aerodynamics of model planes, or building HTP-powered rockets, like the young John Scott-Scott. He was teaching himself to be an engineer, an engineer not of solid stuff, but of abstract stuff which lured him on with the prospect that if he learnt its rules well enough, he could make the engine mimic the behaviour of any solid thing. He could do aeroplanes on the computer, if he wanted. Reduced to its mathematical essence, a flying plane is just a set of relationships between lift, thrust and drag, governed by equations that are entirely within the scope of a universal engine. He could have planes; he could have spacecraft, if he wanted. It helped that he was only eighteen. As he pointed out to me when I interviewed him in the winter of 2001, he had no responsibilities then, apart from schoolwork for his A-levels. He could immerse himself as deeply as he wanted, for as long as he wanted. There was a psychological pay-off too. In the small domain of a program, he had what the big world rarely gives to eighteen-year-olds: the chance to say yea or nay and have his instructions followed to the letter. It was a small but real kind of power.
Backwards and forwards. You, it, you, it, you, it, following a particular set of rules that state what moves are legitimate and what aren’t. Question: what does this sound like? Answer: a game. By 1982, video games had been around for years, ten years if you counted from the birth of Pong, the first arcade game, or twenty if you were a really finicky scholar of the genre and reckoned from the night in 1962 when mainframe engineers started playing Space War on the PDP-1 at the Massachusetts Institute of Technology. But in 1982 most video games either came in great big arcade cabinets or on cartridges for the Atari, a home console made by an American toy company. In neither case could you actually get at them or try your hand at writing your own, unless you happened to work for the manufacturer. It made a big difference if you had access to a computer on your account, as another boy with the right kind of mind was discovering over in St Albans.
*
Ian Bell was nineteen. Like David Braben, he was bound for Cambridge in the autumn to start his degree, but first he was taking a gap year between school and university. He had a job in his dad’s office at the Malaysian Rubber Producers’ Research Association. During the day, he tended the microcomputer that controlled the MRPRA’s tests on rubber samples; but at 5.30, when the lab emptied, he could stop thinking about the software for the stretching, twisting and compressing equipment, and start doing things that compensated for the frustration he’d felt in the computer room at his school. There, there’d always been a queue for the four TRS-80s, and you had to do most of your programming on paper, a spiritless and inert experience compared to real communion with the machine. Now the MRPRA computer was effectively his own. He was computationally independent – at least till 7.30 or thereabouts, when his father clocked off too and they drove home to supper. To begin with he played Space Invaders. ‘But you can’t do that for long.’ If that were true for everybody, the arcade manufacturers would never have garnered enough 10p pieces to stay in business. For most people, Space Invaders was a notoriously sticky experience: one of the first video games to demonstrate that players could be seduced into endless absorption. But it was true for him. He wasn’t satisfied with the to-and-from interchange you got as a player; he wanted the deeper conversation you got by making the game.
His first effort was a computer version of the board game Othello. Fledgling programmers often started by adapting board games. That way, the rules were given you, and the problem was nicely limited. Othello ‘was to Go what draughts are to chess’. Two players took turns putting down white or black pieces on a board eight squares by eight, and if your pieces successfully surrounded a pocket of your opponent’s, they all flipped over and changed to your colour. Making Othello work on the screen, however, still required him to solve a fistful of problems: how to display the black and white counters and the board, how to manage the flip-over elegantly, how to code in routines that would turn the computer into an adequate strategist. There was a literature on graphics programming and on strategy algorithms, of course, but it wasn’t available in the MRPRA building in Wickendenbury between 5.30 and 7.30 in the evening, so he made it all up himself; and as he wrestled with tree searches and pixel positioning, he came to the exhilarating realisation that waits to be discovered by the determined person exploring any new technology. It didn’t matter that he was working it out as he went along. Teaching himself didn’t put him at any real disadvantage because there were no experts yet, at least no experts at implementing this game for this platform at this moment. When a technology is immature, as the technology of the microcomputer was in 1982, it really isn’t a very long journey from your fumbling starting-point as you turn the machine on for the first time to the outer edge of what anyone, anywhere knows. Apply yourself, and within months or even weeks, you can be in genuinely new territory. It didn’t matter that Ian Bell was only nineteen. If his Othello worked – and it did – it counted for as much as anyone’s program. In fact, it seemed to him, as he started to look around the cassettes of entertainment software that were on the market in 1982, that it was probably better than most of them. (David Braben had made a parallel discovery. Setting up his Atom had cleaned him out, so he couldn’t afford to buy Acorn’s Games Pack till he’d been programming for a couple of months; and then he found that his own home-grown games were already better than Acorn’s official offerings. ‘I was so disappointed! I mean, I don’t want to be rude, but they really were crap…’) From this followed a train of thought that went past at lightning speed. Slow it down a little, and its elements could be seen to be arranged in
the form of a classical syllogism. Thus:
1. These games are crap, but sell for money.
2. My games are not crap.
3. Therefore my games could sell for money.
It was a moment of revelation, both philosophical and commercial.
But in order to do this, to do new things with the machine that other people would pay for, you had to get under the bonnet. BASIC was a fine tool to learn programming with; it was a fine tool for creating software that was, well, basic. But programs in it occupied far too much of the limited working memory of a microcomputer, and it was horribly slow. The trouble was that BASIC was an ‘interpreted’ language. Suppose you had a line of BASIC code, say:
20 LET C=2*3.14159*R
When the computer executed it, it worked its way along the line from left to right. It recognised 20 as the number identifying the line in the program; it recognised LET as a valid command in the BASIC instruction set; it recognised the equation as a way of creating a new value for C by multiplying a value for R which it already knew. Then, once it had understood each of the separate pieces of the line, it looked up equivalents for each instruction in the routines of the much lower-level language that the computer’s processor chip could actually understand. The chip did the multiplication and handed the answer back to BASIC, which then proceeded with stately patience to the next line. The convenience of BASIC lay in its ability to let the user ignore all this. You didn’t have to know exactly how the processor set about doing a multiplication; you didn’t have to know exactly where in memory the value for R was being stored. But the price for convenience was the laborious step-by-step translation of everything you wanted done. And although BASIC’s own underlying code sat on the ROM chip, the BASIC program had to be squeezed into working memory while it ran; it was easy for all those leisurely procedures to overwhelm the machine’s capacity.
The way to get anything ambitious done was to write the program directly in the language BASIC translated into: assembly code. Assembly code wasn’t quite the processor’s native tongue – that was machine code, pure primitive binary commands. But assembly code was only one layer up from the silicon. Using it, you’d forego BASIC’s automatic grasp on the state of the system. If you wanted a number remembered, you had to specify exactly into which of the 16,384 possible locations on a 16K block of RAM you wanted it put. If you wanted multiplication, you had to lead the machine through every single stage of the process. Suddenly, you were responsible for the entire flow of very simple commands that allowed the computer to function. Move this, store that, compare these – anything large-scale you wanted to achieve emerged from a torrent of tiny moves, each of which had to be precisely documented in inscrutable strings of letters and hexadecimal numerals. Assembly code looked like this:
2220LDY#16:JSRTAS3:EOR#128:AND#128:
ORA#3:STAINWK+30
2235LDAINWK+29:AND#127:CMP#16:BCSTA6
2240LDY#22:JSRTAS3:EORINWK+30:AND#128:
EOR#&85:STAINWK+29
Next to a program listing in BASIC, a large amount of assembly language seemed disconcertingly featureless, its functional twists and turns not labelled as such but all blurred together into a giant soup of code. And there always was a large amount, because for every line of BASIC you’d need at least five lines of assembly code. Writing in assembly code was a long, slow, finicky business. If BASIC programming was like putting together an Airfix aeroplane kit with ready-made plastic parts, assembly-code programming was more like building a model suspension bridge from matchsticks.
Yet, if you succeeded, your program (as David Braben puts it) ‘went like the wind’. Assembly software didn’t just run a bit faster; it ran ten times faster. All at once your computer became immeasurably more powerful; more powerful than most users ever suspected, more powerful maybe than even its manufacturers suspected. There was also a partial compensation for losing the universality of BASIC, which would run on almost anything. Which flavour of assembly code you wrote in was determined not by the particular architecture the manufacturer had given your machine, but by the chip. If you wrote in ‘6502 assembly code’, the instruction set for the Mostek 6502, the program could be made to run on any machine containing that processor: a good half of all the microcomputers on the market then, from Acorn’s Atom and BBC Micro to the Apple IIe Ian Bell was using at the rubber lab. Suitably tweaked, your code became portable again.
Ian Bell’s Othello, coded in 6502 assembly language, ran so fast he had to slow it down artificially. Otherwise, every time you put down a piece on the board, the computer came back with its move – bip! – before you even had time to take your finger off the key. It was spooky; it rather spoiled the illusion that you were engaged in a cagey battle of wits. He introduced a pause, during which nothing really happened at all, but which the human player could interpret as the computer thinking. Then he sent a clean copy of his code to Program Power, a software company temporarily riding high in the games market. As it happened, his was one of two digitised Othellos to fall through their letter-box in a Jiffy bag. So Program Power played the two Othellos against each other to see which was better. The rival Othello beat Ian Bell’s at the higher skill settings – not surprisingly, since he had had to make up all of the game strategies off the top of his head. But his performed better at the novice level most players would start on, and at every level it ran faster and smoother. Program Power announced that they were thinking of releasing both of them.
Emboldened by this – and by an old school-friend’s success at getting £500 from Acorn’s software arm for an arcade-game adaptation called Thrust – he took the next step and started work on a completely original game, one with no antecedents at all. Free Fall would put the player in charge of a little animated astronaut who moved about inside a whirling space station and battled aliens that materialised with a shimmer, like the shimmer effect used for the transporter in Star Trek. It was a much bigger project than Othello. There was a lot to learn: sound effects, rules to make weapons fire in a straight line, collision-detection algorithms (so that the computer knew when the astronaut hit the space-station wall), rules to control a rising tempo (so the game gradually got faster and harder). And as he worked away on these things and played other people’s games with a critical eye, he started to think about the conventions that governed the infant games business. Free Fall was going to be fairly conventional – one leap forward at a time was enough – but why, for example, did there always have to be a score? Games were supposed to be fun, and a score in the top left-hand corner of the screen was certainly one way of measuring how much fun you were having. But why should it be the only way? Why should all the experiences a computer game was capable of giving you have to be forced down the same channel and structured so that they could be assessed in a number? If you thought about it in functional terms, he reflected, a computer game that made getting a high score its point was really just a kind of Heath Robinson device. To drive that single number upwards, the game provided you with a madly complicated interface, all string and pulleys and multiple levers. There must be other ways, ways which respected the integrity of the game experience in itself. Real life was commonly agreed to be a pretty interesting experience, and it didn’t have a number floating in the corner which went up every time you successfully crossed a road … In short, he was beginning to develop strong views about ‘gameplay’, the quality in the world of video games which is hardest to define. It doesn’t reside in how a game looks – though some games rich in gameplay are also superlative eye candy. It’s a term for the intuitive satisfaction the universal engine can give you when the dynamics of an imagined world are calculated just right.
*
Meanwhile, back in Epping, David Braben had decided that of all the things a micro could summon for him, he did in fact want spaceships. His first effort had been a nuclear-war game based on the arcade classic Missile Command. Whoever caused the most megadeaths won. ‘I was young. That’s my excuse, anyway.’ But now he had b
egun to get interested in the imaginary space behind the screen. Most games then treated the screen as a flat plane facing you as you played, somewhere for two-dimensional events to take place. The aliens marched from the top of the screen to the bottom in Space Invaders; the spaceship in Defender flew from left to right. But in theory there was no reason why you couldn’t treat the screen, instead, as a window onto a 3D domain. First, you had to imagine a block of three-dimensional space directly behind the glass: a little theatre with the screen as its transparent front wall. Any point in there could be located with three co-ordinates, standing for its distance up, its distance across and its distance back – the x, y and z co-ordinates David Braben used in maths at school when drawing three-dimensional graphs. If you wanted to put a whole object into the space rather than a pinpoint, it was just a matter of defining the co-ordinates for each of the object’s corners. A pyramid would need four sets of co-ordinates, a cube would need eight. But then the geometry got more complicated, because, after all, there was no real space back there, just the cathode-ray-tube innards of the family TV. What he was trying to achieve was the illusion of a 3D object on a 2D surface, which meant that the x, y and z co-ordinates he had calculated then had to be distorted according to the rules of perspective. These had been formulated by Renaissance artists trying to fix an illusion of depth on whitewashed monastery walls in egg yolk-based paint, but they worked just as well for pixels. Deform a shape on a flat plane so that it dwindles towards a consistent vanishing point, and the human eye interprets it as a solid presence. Morph the co-ordinates for your computer object so that they stretch towards the vanishing point, map them as locations on the flat screen, and the eye looking at the little dots of light you have actually put there is fooled into seeing them as the object itself, the object you first thought of, floating in the digital dark.
Backroom Boys Page 10