RSS

Monthly Archives: November 2012

The Hobbit Redux

Sometimes I get things wrong. Usually it’s minor errors that come down to a careless moment or something that got wedged between the teeth of my rusting steel trap of a mind. Luckily, you folks who read what I write almost always come through to correct me when I make mistakes or even when I overreach. Something like that happened with the most recent article I’ve written, but it had causes a little bit more complicated than one of my usual attacks of boneheadedness.

Virtually all of the articles published about Melbourne House and The Hobbit — of which, unsurprisingly given the game’s immense popularity, there were quite a few — describe it as largely the work of Philip Mitchell, who wrote it with the aid of Veronika Megler and Stuart Richie. These are the sources which I relied upon to write my story of the game’s development. Shortly after I published my article, however, Veronika Megler contacted me to tell me that the contemporary sources are, simply put, false. She told me that hers was the primary mind behind the game, that Mitchell developed only the parser and handled the porting to the Spectrum and the addition of the pictures after she had left Melbourne House. Richie’s work, meanwhile, was theoretical rather than technical and played little actual role in the finished game.

I was of course quite nonplussed to hear this, but Veronika’s descriptions of the game’s development and the role played by everyone were so precise that I immediately tended toward believing her. That belief only strengthened as I talked to her more. Today I believe that the official story found in the magazines is a distortion (at best) of the facts.

It’s not difficult to understand how this could have happened. The story of The Hobbit‘s development started to be widely disseminated in the computer press during the lead-up to publication of Philip Mitchell and Melbourne House’s next big adventure game, Sherlock. Thus the pieces in question functioned not only as retrospectives, but — more importantly, at least in the eyes of Melbourne House — promotions for what was coming next. It sounds much better to speak of “the next game by the architect of the hit adventure The Hobbit” than “the next game by the guy who assisted the architect of the hit adventure The Hobbit.” Thus Mitchell’s role was vastly overstated, and Megler’s correspondingly reduced; in effect the two swapped roles, with Mitchell becoming the architect and Megler his assistant. As readers like me took those original articles at face value, this version of events passed down into history.

That’s unfortunate, and I understand Veronika’s frustration at having been effectively robbed of credit that is due to her. However, I can also understand how the pressures of promoting the follow-up to such a gargantuan hit could have led Alfred Milgrom and Mitchell down the path they took. I will also just note for the record that Veronika feels strongly that sexism also played a role in the downplaying of her contribution, although I’m not prepared to levy that accusation myself without knowing the people involved better or having more evidence.

Whatever the reasons behind the changing of the record, I’m convinced at this point that Veronika was indeed the major force behind the form The Hobbit took, as well as its major technical architect. I’ve revised the original article accordingly to reflect the true contributions of everyone involved. If you’ve already read it, I’d encourage you to give the new version a quick skim again, or at the least to know that much of what I credited to Philip Mitchell in the original should rightfully have been credited to Veronika Megler. Sometimes, alas, getting to historical truth is a process. I thank Veronika for taking the time to work with me to document what really happened.

I’m actually on holiday as I write this, back in the United States again. So, it will be a couple of weeks before I’ll have more material for you. But keep me in your RSS readers, because we’ll next be rounding the corner into 1983 at last, and things just keep getting more and more interesting.

In the meantime, happy Thanksgiving to my American readers, and to everyone thanks for reading!

 

Tags: , , ,

The Hobbit

In 1977 Alfred Milgrom started Melbourne House, a book publisher, with “four and a half” employees and offices in London and his native Melbourne, Australia. Over the next several years they made a modest go of it. In addition to a stable of young Australian authors, they established something of a specialty as a publisher of mid-list American authors who lacked contracts with the larger British and Australian houses. They signed quite a variety of them: novelist Gerald Green, just coming off a career peak as the screenwriter of the high-profile American television miniseries Holocaust; nonfiction man’s man extraordinaire Robin Moore, most famous for his 1965 book The Green Berets, which spawned one of the most unexpected hit songs ever as well as an infamously jingoistic John Wayne movie; Lin Farley, one of the first to write about sexual harassment in the workplace; and Raymond Andrews, author of a trilogy of novels about a black sharecropper family in the mid-century South.

And then came 1980, and with it the Sinclair ZX80. With a PhD in “chemistry, maths, and physics” from Melbourne University, Milgrom had some somewhat atypical interests for a publisher; he had “always been interested in computers.” He quickly bought a ZX80 of his own. That August, Melbourne House published the hastily put together 30 Programs for the Sinclair ZX80, an unadorned collection of short, simple BASIC listings that could fit within the unexpanded machine’s 1 K of memory, including even a very stripped-down Eliza-like conversation simulator. The programs were credited to an alias computer gamers would soon come to recognize almost as quickly as the name “Melbourne House” itself: Beam Software, a contraction of Milgrom’s initials and the last name of another at Melbourne House who worked with him on the book, Naomi Besen.

In barely a year’s time WH Smith would be selling Sinclairs out of their High Street shops, but at this time no one in the bookseller’s trade knew what to make of the book Milgrom was now trying to sell. So he started taking out advertisements in the enthusiast magazines instead for what was likely the first book ever published about a Sinclair computer. It turned into a “runaway success,” the company’s immediate bestseller. Milgrom followed it up with more hastily produced technical books, written both in-house and by others. Melbourne House would remain one of the most prolific of British computer-book publishers for much of the 1980s. With so much opportunity in this area, their interest in publishing other types of books gradually fell by the wayside.

What with their publishing so many program listings in book form, it seemed an obvious move to begin offering some of them on tape for those who didn’t feel like doing so much typing. Accordingly, their first program on cassette, yet another clone of Space Invaders, appeared in February of 1981, the beginning of a slow transformation in primary avocation from book to software publisher. In a sometimes confusing dichotomy, Melbourne House would remain the publishing arm of Milgrom’s organization, while the wholly owned subsidiary Beam Software served as their in-house development group. Melbourne House would also sometimes publish programs created by outside developers, but for all practical purposes Melbourne House and Beam Software were one and the same entity.

Milgrom had been aware of Adventure and its derivatives for years, some of the latter of which were just beginning by mid-1981 to sneak into the British software market in the form of early, primitive efforts by Artic Computing. Realizing that the form was soon likely to be huge in Britain, as it already was in the United States, he decided to commit Melbourne House to creating one bigger and better than anything currently available for British microcomputers. Knowing he lacked the time and the technical skills to implement such an ambitious project, he posted an advertisement back in Australia at his alma mater, the University of Melbourne, looking for computer-science students interested in working part time on a game-development project. (It being the beginning of August, the Australian spring semester was just beginning.) The first to respond was Veronika Megler, a student about to begin her final year as an undergraduate with a particular interest in database design. Milgrom gave her a very simple brief: “Make the best adventure game ever. Period.”

Luckily, Megler had plenty of ideas about how to approach that rather vague objective. She had played just one adventure game in her life — typically enough, the original Adventure by Crowther and Woods. Yet she already felt she knew enough about the form to say what she didn’t like about it, what she wanted her game to do differently. She hated the threadbare world and static nature of Adventure, the way that most of the possible interactions were pre-scripted so that certain verbs only worked in certain places and many perfectly sensible actions were completely unprovided for. Most of all, she hated the way the other characters in the world had nothing to do, no possibility of reacting to the player’s actions. In place of solitary, static puzzle-solving, she imagined a dynamic environment filled with other characters moving about the world and pursuing agendas of their own — something that might actually feel like living inside a real story. Both Megler and Milgrom also very much wanted to get beyond primitive two-word parsers, something only Infocom had so far managed.

Megler recruited a partner to work with her on the game, Philip Mitchell, a fellow senior with whom she had already worked on a number of group projects and whom she knew to be both easy to get on with and a skilled programmer. Milgrom himself added a third member to the team specifically to help them with the parser: Stuart Richie, who was doing a dual degree in English linguistics and computer science, with a special interest in combining the two fields.

At first, the game was planned as a generic fantasy adventure. However, none of the people involved had any experience as writers of fiction. At some point during the early stages of development, someone (it’s unclear exactly who) suggested that it might be possible to adapt J.R.R. Tolkien’s The Hobbit. Once named, it seemed the obvious candidate for a story. Bilbo Baggins’s quest to kill the dragon Smaug and return safely with his treasure, overcoming trials and tribulations along the way, was not just suitable for an adventure game but practically identical in the broad strokes to the structure of most of them. And The Hobbit was very popular — probably the most-read fantasy novel of all time, in fact — which would guarantee the game an eager audience. (I’m going to assume from here on that you’ve read the book, which I think is probably true of most everybody reading this blog. If you haven’t, you should. It’s a consistent delight, with none of the reactionary nostalgia for an older, class-bound Britain that sometimes bothers me about The Lord of the Rings.)

Unlike more naive characters like the Austin brothers, Milgrom knew that he needed to work something out with the Tolkien estate before releasing a commercial game based on the novel. About six months in, with some demonstrations ready to show them, he made contact. As Milgrom put it in later interviews, he had “contingency plans” if the Tolkien people should turn him down — presumably, filing the proverbial serial numbers off and releasing the game as a generic fantasy adventure after all. But luckily they were very receptive. As I write this, we’re awash in hype over the imminent release of the first of Peter Jackson’s Hobbit movies. It’s amazing to consider that thirty years ago the Tolkien estate was willing to entrust the property to a tiny publisher like Melbourne House employing a few kids working part-time when not at university. Tolkien was then, as he is now, the premiere fantasy writer. It’s just that the position of fantasy fiction within popular culture has changed incalculably, in no small part due to trends whose roots I’ve been chronicling on this blog.

Even with the novel to provide a world and the outline of a plot, the team had an insanely ambitious brief, one that obviously was not going to fly on the current Sinclair machines. Nor had Sinclairs made their way into the Australian market in any great numbers anyway. The most popular PC there at the moment was a Hong Kong-built clone of the TRS-80 sold through the local Dick Smith chain of electronic stores: the dubiously legal Dick Smith System 80. These machines shipped with only 4 K or 16 K of memory, but with a bit of ingenuity could be expanded up to 48 K. They also used the Z80 processor found in many machines, including the Sinclairs. Milgrom and his team decided to make their game on their hacked 48 K System 80s, under the assumption that by the time it was finished other, more consumer-friendly machines with the necessary attributes would be available to which they could port it without too much hassle. This practice of targeting tomorrow’s hardware today is now common in AAA game development; The Hobbit was perhaps the first example of it.

Of course, with 48 K and no disk drive to work with for virtual memory (Australia, like Britain, was still firmly cassette-bound), they still had one hell of a task in front of them. Megler remained the linchpin of the project, developing a whole adventuring system that should be at least theoretically reusable in future games. She also went through the book to develop a plan for the game, mapped the major events and characters to locations in the world, and added them to the engine’s database. Mitchell worked on a full-sentence parser that would allow the player to talk to the other characters in the world and even order them about. He called his system “Inglish.” Together, the code for the engine and the parser was eventually squeezed down to about 17 K, leaving the rest of the memory for Megler’s database. Richie, who was employed by Melbourne House for only a few months, contributed no code, and his ideas ultimately had little influence on the system. Milgrom’s idea of hiring a linguistics expert to develop a parser is one of those that sounds better in theory than it works in reality. As countless other programmers have learned, developing a good adventure-game parser has more to do with common sense and careful diligence than elaborate theories about linguistics or natural-language processing.

The Hobbit‘s development had some similarities to a student project, a certain abstract naiveté that sometimes threatened to send the team wandering hopelessly off course. They were having great fun — perhaps sometimes too much fun — just playing in this world they were building. Thanks to all of its random dynamism, it constantly surprised even them. Megler sometimes played the system like an early version of a god game such as The Sims, injecting new NPCs just to see what would happen and what kind of chaos they would cause with their fellow actors and the player: “I’d written in an angry dwarf that kept trying to kill you, and if you did something (I don’t remember what) it became a randy dwarf, and kept following you around and propositioning you. But Fred and Phil decided that was a little too much, and made me take it out again.”

And then it was the summer of 1982, the semester was over, and — in a demonstration of just what a part-time, semi-amateur project this was — Megler, the primary architect of all this, was suddenly gone: “I was bored with full-time programming and debugging, and eager to get on with a ‘real career’ (which gaming wasn’t, back then).” Only Mitchell stayed behind, to be hired by Milgrom as a regular, full-time employee. By this time The Hobbit was in a relatively finished form, a bit rough around the edges but basically a playable game on the TRS-80/System 80. Now the ideal platform on which to actually release it had come around, just as they had hoped it would: the first Sinclair Spectrums were just reaching consumers back in Britain. What with Melbourne House’s distribution network in that country and the tiny size of the domestic Australian market, the Spectrum and Britain were the obvious target platform and market respectively for their game. Luckily, the Spectrum used the same Z80 chip as their development platform, and had the same 48 K of memory. Porting Megler’s engine to the Speccy should be relatively simple.

The Speccy did also have one important feature that their development machines had lacked: color, bitmapped graphics. Milgrom decided that illustrations could be the cherry on top of his next-generation adventure. He commissioned an artist, Kent Rees, to create — on paper, as was the norm at the time — pictures for about 30 of the game’s 80-odd locations. Mitchell then developed a system to trace these images and import them into the computer, using the vector-drawing techniques pioneered by Ken Williams for Mystery House. (You can see clear evidence of this in the finished game; the computer draws each line and fill one by one before your eyes, like an artist recreating the picture each time.) The illustrations are by no means stunning, but they were certainly novel in their time, and sometimes do manage to add a little something to the atmosphere.

Interestingly, Mitchell continued to do most of this work on the System 80, a much more pleasant machine to work with thanks to its real keyboard. He only moved the finished product to the Spectrum when it came time to test his handiwork. (To add to the irony, the TRS-80 would be one of the few platforms on which The Hobbit would never get an official release.) Thanks to some very efficient drawing algorithms as well as smart text-compression routines that rivaled those of Level 9, Mitchell was able to pack the entire game, with illustrations, into the 48 K Spectrum, a remarkable feat indeed when one considers that he had no recourse to external storage — 48 K was literally all he had to work with for code, text, data, and pictures.

As summer passed into fall, the game was settling into its final form. But now a persistent problem threatened to derail everything: a multitude of tiny glitches and bugs that cumulatively began to overwhelm the experience of every session the longer it continued. Rather than crafting interactions by hand, Megler had striven to make The Hobbit a dynamic simulation. Monsters and other characters move about and act differently in every session, guided by random chance as well as their disposition toward the player (attacking Gandalf, Elrond, or Thorin tends to get you on their bad side); every object has a weight, size, and strength that determine its interactions with every other; each character, CRPG-style, has a certain numerical defensive and offensive strength as well as a health level for determining the results of combat. This could all lead to fascinating examples of what we would now call emergent behavior or even emergent storytelling, but it could also lead to a welter of bugs and general weirdness. Tracking these down turned into a nightmare, as the randomization and dynamism of the world meant that many were impossible to reproduce consistently. This had presented a huge challenge even when Megler was still on the project:

The Hobbit was a tough game to test. Unlike the other games of the time, it was written in assembler, not BASIC, and we would find bugs in the assembly and linking programs. Also, it was not deterministic, and the game played differently every time you played it, as a result of Philip doing a lot of work to develop a “perfect” randomizing routine. Literally, the player had a turn, then each animal had a turn, and the animals just “played” the game themselves according to their character profile, which included interacting with each other. In essence, the animals would do to each other anything that they could do to or with you. So we would constantly have animals interacting in ways that had never been programmed or envisioned. The game would crash because of something that happened in another part of the game that you as the user (or person testing the game!) didn’t see, because the game only showed you what was happening in your location. For a while, we had terrible trouble with all the animals showing up in one location and then killing each other before you got there, before I got the character profiles better adjusted!

Melbourne House struggled with these problems for a time, but eventually, as development stretched toward the eighteen-month mark, seems to have just declared it good enough and pushed it out the door. A telling disclaimer in the manual indicates that they were aware that it wasn’t quite in the state it probably should have been: “Due to the immense size and complexity of this game it is impossible to guarantee that it will ever be completely error-free.” And indeed, the first release of the game in particular is riddled with inexplicabilities. Swords break on spider webs; Bilbo can carry the strapping warrior Bard about for hours; Gandalf and Thorin can walk through walls; garbled text and status messages obviously meant for the development team pop up from time to time. Melbourne House released a version 1.1 shortly thereafter, which fixed some of this but — oops! — also broke another critical interaction, rendering the game unwinnable. Version 1.2 soon followed, but throughout the game’s long published history Melbourne House seemed to remain stuck in the same perpetual game of whack-a-mole. Today it’s still remembered for its bugs almost as much as anything else.

The parser is beset by problems of its own. It does understand a lot, including, for the first time anywhere to my knowledge, adverbs. It’s possible, for instance, to “viciously attack the mean goblin,” although I’d be shocked to learn that it doesn’t just throw away the adverb as it does articles. Yet in other ways, especially in early releases, it’s very frustrating to work with. It’s possible to “climb into the boat,” but not to “enter” or “get in” it; possible to ask Thorin to “carry me,” but not to ask him to “take me” (talk of randy dwarfs aside, no double entendre intended); possible to “look across the river”, but not to “look over” it. When I recently played the game I had at least two occasions where I knew what to do but just could not express it to the game no matter how hard I tried, and finally had to get the answer from a walkthrough. Coming from someone who’s played as many text adventures as I have, that’s a condemnation indeed.

Playing The Hobbit can be, as stated in the perfect title of its one MobyGames review, “strange.” In spite of the grand ambitions, expecting even a shadow of the richness of Tolkien’s world (not to mention his prose) in a 48 K adventure game is expecting too much. There was no real possibility of presenting the temporal element that is so important to stories. Instead, the plot of the novel is mapped to the game’s geography: moving further eastward gets you further and further into the story, from the beginning in Bilbo’s hobbit hole to the climax at Smaug’s lair. (The Battle of the Five Armies, like all of the dwarfs except Thorin, is left out as just too complicated to deal with.) This has the disconcerting side effect that you can travel back in time whenever you wish: the trolls’ camp is just two moves east of Bilbo’s house, and one move west of Rivendell. Needless to say given such a compressed geography, the sense of embarking on a grand journey that the book conveys so well is largely absent. That it works as well as it does is a testament to the book’s almost uniquely adventure-game-suitable quest narrative. Few other temporal landscapes could be mapped even this neatly to the geographical.

The experience feels rather like wandering through a series of stage sets depicting the major scenes from the book — stage sets which are also being wandered by a bunch of other characters just smart enough to be profoundly, infuriatingly stupid. Your companions on the quest, Thorin and Gandalf, are both singularly useless (or worse) when left to their own devices. Never one to let circumstances get in the way of avarice, Thorin will “sit down to sing about gold” in the midst of a goblin, warg, or dragon attack. Gandalf, meanwhile, is also attracted to shiny objects; he constantly plucks random items off your person (“What’s this?”), then tosses them on the ground and wanders off when his one-turn attention span expires. A critical element of the game is the player’s ability — and occasional requirement — to give orders to other (friendly) characters, to have them do things beyond the abilities of a four-foot-tall hobbit. Sometimes they do what you ask, but sometimes they’re feeling petulant. Perhaps the seminal Hobbit moment comes when you scream at Bard to kill the dragon that’s about to engulf you both in flames, and he answers, “No.” After spending some time with this collection of half-wits, even the most patient player is guaranteed to start poking at them with her sword at some point.

And actually, therein sort of lies the secret to enjoying the game, and the root of its appeal in its time. It can be kind of fascinating to run around these stage sets with all of these other crazy characters just to see what can happen — and what you can make happen. Literally, no two games of The Hobbit are the same. I can see what Megler was striving toward: a truly living, dynamic story where anything can happen and where you have to deal with circumstances as they come, on the fly. It’s a staggeringly ambitious, visionary thing to be attempting. Infocom had already moved somewhat in that direction with Deadline, but (probably wisely) had hung the more dynamic elements from a scaffolding of pre-scripted set-piece events — and even at that it was easy in early releases in particular to break through the sense of realism of the simulation.

Needless to say, the idea doesn’t entirely or even mostly work in The Hobbit either. There are still enough traditional puzzles that it’s too easy to lock yourself out of victory and have your living fantasy become a Beckett tragicomedy. Then there’s the wonky physics, the way that entirely random developments can ruin your game, and of course all of those bugs that often leave you wondering whether some crazy thing you’re seeing is an expected part of the general surreality that surrounds you or just something gone haywire. (At a certain point, it kind of ceases to matter anymore; you just go with it.) To say that the game’s reach exceeds its grasp hardly begins to state the case; the thing the game is reaching for is somewhere in orbit above its firmly earthbound self, being an experience huge teams of developers still haven’t entirely succeeded in delivering today. But still, The Hobbit plays like no adventure before it. In my recent game, a warg somehow got into the wood elves’ compound long before I got there. I arrived to find him prancing atop the corpse of the one who should have captured me and thrown me in a cell. Suddenly my problem was not how to escape from the elves but how to get past the warg, a very tough customer — not exactly how it played out in the book, but an exciting experience nevertheless. Sometimes, when it works, The Hobbit can be kind of amazing. It stands today as the direction that was largely not taken in text adventures, and at its best it can make you wonder why.

Expensive American imports aside, The Hobbit marked a whole string of firsts for the British adventure scene: first full-sentence parser; first illustrated game; first title licensed from a book (this would have been a first in the American market as well); not to mention first crazy experiment in emergent text-adventure storytelling. And it arrived just as Spectrums were finally getting to consumers in big numbers, and as said consumers were eager for flashy new experiences to enjoy on their new machines. The Hobbit, in short, became huge. It was a hit out of the gate, and just kept selling and selling as months on the market turned into years. Melbourne House made ports for virtually all of the other viable computing platforms of the time, as well as enhanced versions for disk-drive-equipped machines that improved the graphics, added atmospheric music, and offered a little bit smarter companions, a little bit better parsing, and a little bit more to do. It was in this form that the game finally reached American shores in 1985, through an arrangement with Addison-Wesley. The game promptly became a big hit there as well.

Indeed, The Hobbit seemed adaptable to any market or promotional scheme. In its original British incarnation, it was minimally packaged in a rather garish box typical of the young scene there. In the United States, it was beautifully packaged in a classy fold-out box with a lovely, understated cover illustration drawn by Tolkien himself — one of the best of the golden age of computer-game packaging. The American version of the game even came complete with a copy of the book included.

Exactly how many copies the game eventually sold on both sides of the Atlantic is a matter for some speculation. In High Score!, Rusel DeMaria and Johnny L. Wilson state that it sold more than a million copies, but even given its undoubtedly phenomenal popularity I tend to be leery of such a figure given what I know of sales figures for other games of the era. An article in the British magazine Computer and Video Games dated March 1985 guesses that it may have sold up to 200,000 copies by that point. With its entry into the American market (where it was a hit, but not the phenomenon it was in Britain) and continued popularity in Britain, it’s very possible that the game ended up selling half a million copies in total, but it’s hard for me to see my way to much more than that barring better evidence. Still, even the lower figure makes it an excellent candidate for the bestselling text adventure of all time, challenged, if at all, only by Infocom’s Zork I. (The most played text adventure, of course, is and will likely always remain the original Adventure.) The Hobbit made Melbourne House as a major software publisher. And it largely made the British adventure game as its own unique thing, ready to go its own way and try its own things rather than remain beholden to the American approach.

As I write about The Hobbit, “strange” is a word that comes up again and again; everything about it seems anomalous. It’s strange that the game that made the British adventure game should have come from half a world away. It’s strange that a game with such an atypical approach to the form should be the best candidate for the bestselling example of said form of all time. It’s strange that the first publisher to license a book should have been tiny Melbourne House, not one of the more established American publishers. It’s strange that what is, in all honesty, something of a bug-ridden mess should also have such a compelling quality to it. It’s strange that a game based on a novel should be all about emergence rather than attempting to recreate the story of the book. It’s strange that the woman who came up with this new vision of how an adventure game could work left Melbourne House and the burgeoning industry before The Hobbit was even complete, never to return. The Hobbit is most interesting because so much about it is so unlikely.

If you’d like to try it in its original form for yourself, here’s a copy of the Spectrum tape image and the manual. There are lots of Spectrum emulators out there; I use Fuse. Of course, you can also find heaps of other versions out there for heaps of platforms, including the enhanced, disk-based versions that feel more fleshed-out than the original. But never fear, all retain at least a light dusting of the bugs and oddities that are so critical to the Hobbit experience.

(Sources for this article include the web links in the post itself as well as interviews, articles, and profiles in Computer and Video Games #27, Computer and Video Games #41, Crash # 3, Popular Computing Weekly Vol. 1 No. 36, Popular Computing Weekly Vol. 2 No. 43, ZX Computing Vol. 1 No. 6, and Home Computing Weekly #5. And Veronika Megler herself was an invaluable source for this latest, revised version.)

 
50 Comments

Posted by on November 16, 2012 in Digital Antiquaria, Interactive Fiction

 

Tags: , , ,

The Speccy

To put it mildly, Clive Sinclair was not pleased by the BBC’s decision to make the Acorn Proton the standard bearer of British computing. He had some legitimate complaints to levy. The process of selecting the machine, for one thing, could under no interpretation be considered fair and above-board. The BBC had simply handed the contract to the government-controlled Newbury, then when that fell through slipped it to Acorn as the most viable remaining manufacturer that was not run by Sinclair; his company and others never had a chance. The price of the Acorn machine also seemed at odds with the BBC’s original intentions for the program. The £400 BBC Micro Model B (the really practical and desirable model) was simply too expensive to become the fixture in everyday British homes that the BBC had imagined. And then there was the question of whether a government agency had any right or business to interfere with the workings of private industry in the first place. (Admittedly, this was a question that Sinclair, like so many businessmen, tended to answer differently depending on whether he was the one directly benefiting from the government’s largesse.)

In addition to practical complaints, however, Sinclair was personally wounded by the BBC’s choice. They had chosen Chris Curry, the erstwhile junior partner he had mentored, over him; anointed Curry’s company the Great Hope for British computing rather than his own. In response, he lashed out. His interviews from the period — and he did plenty of them — read like the reactions of a jealous lover, strewn with invective toward the BBC peppered with occasional expressions of dismay that they didn’t pick him. From the August 1981 Your Computer:

“When you have a company like ours, which is easily dominating the whole of Europe in personal computers, we believe we have done a very important job in popularizing computers. It is a real disappointment to have your own national broadcasting corporation completely ignore you.”

“What the BBC is doing, it is doing badly and it is damaging the whole progress of computers in this country. We have put a new version of BASIC into our machines. It has been highly praised in the UK and abroad, because of its editing facilities. We developed into it features such as single-keyword entry. None of that is in the BBC version.”

On the perceived slight of not being consulted in the government’s planning for IT Year ’82:

“The government has it so wrong. Frankly, they are so bad at it, it would be better if they left it alone. Fine, they should be doing things for the computer market, but this recent Department of Industry scheme is so peculiar. We were not even talked to.”

But Sinclair reserved his most strident scorn for the rival whom he perceived to have gone behind his back to make the deal with the BBC. All pretense of civility fell away from his relationship with Curry, whom the BBC “for some strange reasons allowed to stick [their] logo on his machines” which would otherwise not have a chance in the marketplace. No shrinking violets themselves, Curry and his partner Hermann Hauser responded in kind with shots at Sinclair’s “duct-tape” brand of engineering that made his machines an impossibility for a serious organization like the BBC. Even Paul Kriwaczek, the producer of The Computer Programme, got in on the act to defend the BBC’s choice, calling Sinclair’s machines “throwaway” products. It was quite a petty display all around, if also a very entertaining one.

Sinclair largely won this public-relations war. The British computer industry was full of other, smaller companies feeling equally spurned by the BBC deal, equally convinced that their own latest designs could have fit the bill much better than anything Acorn had to offer. Sharing a common enemy with Sinclair made them, at least in this sphere, his friend. With virtually the entire industry standing on one side and just Acorn and the BBC on the other, it was easy to conclude that the BBC Micro must be the bad idea and/or botched execution they said it was. On Sinclair’s side most of all, though, was his popular image as the benevolent “Uncle Clive,” largely the creation of his advertising agency, Primary Contact.

Sinclair certainly looked the part of the slightly eccentric but ultimately cuddly boffin, and Primary Contact played the image up for everything they were worth. As Ian Adamson and Richard Kennedy wrote in Sinclair and the “Sunrise” Technology, even long before the controversy over the BBC Micro, “Sinclair was marketed as the maverick doyen of hi-tech, the lone entrepreneur with the vision to take on the Americans and the Japanese. The implication was that by supporting Sinclair the consumer was advancing the cause of British innovation in the face of the brute strength of foreign marketing might.” Now the entrenched bureaucrats of the BBC could be added to the forces he defied. The Clive Sinclair of the popular imagination spent his time puttering away in a basement laboratory somewhere before emerging with designs that were both simpler and better than the competition thanks to his grounded British know-how. He then, unmaterialistic boffin that he was, sold them for a ridiculously low price and just blinked bemusedly when praised for it. Spreading the joy of computing and helping his country were their own rewards. His anger at the BBC was the righteous anger of the honest, practical man confounded by sycophants and politicians.

The reality was very different. Sinclair certainly had electrical know-how, but he was no computer engineer. His machines were designed by others to his specifications, which always began and ended with the price he intended to sell them for and the profit margin he needed to preserve even at that price. Except for these absolutes, all else — including not only features but fundamental quality controls — was negotiable. Characteristically, Sinclair got most involved with the actual engineering of his “creations” when hunting down which component parts he could source for the cheapest prices. Personally, he was domineering, uninterested in the opinions of others and possessed of a deadly combination of overweening arrogance and a deeply buried insecurity that occasionally flashed to the surface when his decisions were questioned. His contempt extended to his customers, whom he regarded as sheep waiting for the Man of Genius (i.e., him) to tell them what they wanted. Surprisingly, Sinclair didn’t even believe that that would necessarily be computers in the long term. He had come into this field largely to finance the quixotic further development of two absurd products he had been dreaming about for years: a miniature, portable television and an electric car. Computers were just a means to that end, a way to capitalize on a passing fancy of the fickle everyman.

Of course, as French philosophers have taught us, the perceptions engendered by mass media are often as real in practical terms as anything else. The British computer industry needed a company hell-bent on selling its machines so cheaply that almost anyone could afford one, even if that meant cutting some corners. And the British public needed an Uncle Clive persona to put a friendly, comfortably British face on all of this disruptive new technology and tell them they had nothing to fear from it. Sinclair was such a terrible businessman that this ride couldn’t possibly last very long. But it would be fun while it did; whatever else you can say about Clive Sinclair, he’s never been boring.

When not sniping at the BBC in the press, Sinclair spent late 1981 and early 1982 pushing hard on his own new computer that would show them how wrong they had been to choose Acorn over him. The successor to the ZX80 and ZX81, it would borrow much of its internal and external engineering from those earlier machines, remaining a tiny thing that looked more like a desk calculator than a computer. The big change, from which it derived its name — the ZX Spectrum — was the addition of color and graphics capabilities. It would deliver these in a package costing just £125 for 16 K or, in another coup, £175 for a full 48 K, well under half the price of the 32 K BBC Micro Model B.

In many ways the Spectrum was a typical Sinclair product, the result of brutal cost-cutting. The keys were made of squishy rubber, which further added to the calculator-like impression and were only marginally more comfortable than the membrane keyboards of the ZX80 and ZX81. Many choices seemed a product of the echo chamber inside Sinclair, owing little to any sort of practical real-world considerations. When designing the ZX80, the company had developed something they called “one-touch” BASIC programming, which matched each BASIC command word to a key on the keyboard. The idea was that the user need only type a single key for each command instead of the whole word, thus cutting back on typos and limiting the interacting she had to do with the ZX80’s atrocious keyboard. As they added more commands to their BASIC with each successive model, however, the idea became increasingly ridiculous. By the time the Spectrum emerged the user had to memorize arcane sequences for many commands that required holding down multiple shift and control keys and some octopus-like finger dexterity. The sequences were both more difficult to remember and more difficult to enter than just typing in the words would have been; some commands actually required as many or more key strokes than there were letters in the word. How this absurd system could have made it out the door is a mystery — or perhaps a tribute to the dominance of Clive Sinclair, who had decided that “one-key” entry was a key to his company’s success and wasn’t interested in hearing otherwise.

In other ways, though, the Spectrum was a Sinclair like no others. Sinclair wasn’t exactly a company one might have expected to deliver cutting-edge aesthetics, but they shocked here. The machine’s externals, by industrial designer Rick Dickinson, have been enshrined — and for good reason — as a design classic. The svelte ebony case with its flash of color stands out from all of the other computer models of its era, with their chunky, lumpy frames and acres of bland beige plastic.

In practical terms, the Spectrum finally answered a question that had been uncomfortably nagging at the backs of the minds of many people ever since this computer thing got rolling in the press. Everyone understood that computers were the wave of the future and all that. But, if you weren’t running a shop and needing to keep inventory or something, what could you really do with one? Sure, a small minority might spend hours every night tinkering with the vagaries of BASIC, but that was of little practical value and destined to remain a niche interest at best. For everyone else, most notably children and teenagers, the Spectrum finally provided a better answer: you could play games. Its graphics hardware could display fifteen colors at a resolution of 256 X 192, with the very significant restriction that each 8 X 8 block of the screen could use only two of them. Still, combined with the 48 K of memory that allowed a decent scope for complexity in game designs, it was good enough. Its tiny size even meant that you could stuff it into a trench-coat pocket to cart to your mate’s house after school. For all of the caveats and limitations that came with it, the Spectrum was the right machine at the right time at the right price to launch computer games into the mainstream in Britain.

In retrospect one of the most bemusing things about the feud between Sinclair and Acorn is that, as Curry and Hauser at least remarked in their more lucid moments, the BBC Micro and Sinclair Spectrum were barely competitors at all. Sinclair largely created a new, home-computer market in Britain, just as Commodore did with the VIC-20 in the United States. (The VIC-20 was also sold in Britain, but didn’t have quite the same impact.) The BBC Micro, meanwhile, put Acorn in a position similar to that of Apple in the U.S., making more expensive, better supported machines for a more “professional” (or, at least, well-heeled) consumer.

The Spectrum was officially launched on April 23, 1982, but it’s pretty safe to say that no consumer received a machine before June. Sinclair, who often trumpeted in interviews that he “never made the same mistake twice,” was nevertheless “utterly astonished” by the demand for the new machine, as he had been for each model that preceded it. The company’s practice of advertising that consumers who ordered directly from them would receive their computers within 28 days prompted much ire as waiting periods stretched to three months and beyond. This in turn prompted a sternly worded warning from the Advertising Standards Authority, a ritual that played out with every Sinclair product launch. It was 1983 before Sinclair cleared its backlog, at which time the company started the whole shortage over again when they reduced prices by more than 25%. In the end none of the angst mattered that much. Where else, Sinclair asked, were customers going to find a 48 K micro with 15-color graphics capabilities for his prices? Most people would wait, he figured — and he was right.

So, IT Year was a success beyond architect Kenneth Baker’s wildest dreams. At its end there were three times as many computers in British homes as there had been at its beginning. One could certainly argue how much of this explosion was really due to the government’s efforts; one suspects that Clive Sinclair would have some strong opinions on that subject. But, however we apportion the credit, things would never be the same; computing in Britain went mainstream with the IT Year and, crucially, the Spectrum. A generation of British children went to school to learn about computers and BASIC and many other subjects on the sturdy BBC Micros. The same kids came home to hang out with friends and play games in front of their “Speccys.” Can you guess which machine is more fondly remembered by Britons today? The poor BBC doesn’t have a chance.

The Spectrum also spawned a huge games industry to feed this eager market. Speccy programmers came to love the machine, as much because of as in spite of its limitations. With its crazy BASIC entry system and dry error messages like “Nonsense in BASIC,” the Speccy felt like theirs — quirky, slightly off-kilter, and somehow distinctly British in its sensibility. Many of the games they produced had a sensibility to match, very different from that of their American cousins. It’s mostly the innovative action games like Manic Miner and Jet Set Willy that are remembered today, but the Speccy also had adventures. Oh, boy, did it have adventures — thousands of them. We’ll look at one of the earliest and most important of them next time.

 
11 Comments

Posted by on November 12, 2012 in Digital Antiquaria, Interactive Fiction

 

Tags: ,

A Gallery of Unfortunate Events

A philosopher’s life is a dangerous one…

 
9 Comments

Posted by on November 9, 2012 in Digital Antiquaria, Interactive Fiction

 

Tags: , ,

Phoenix and Acornsoft

Cambridge was the heart of the early British PC industry, home of both Sinclair and Acorn as well as many supporting and competing concerns. Indeed, Cambridge University can boast of some of the major achievements in computing history, to such an extent that easy characterizations of the university as “the MIT of Britain” or the town as “the Silicon Valley of the UK” seem slightly condescending. It was Cambridge that nurtured Alan Turing, the most important thinker in the history of computer science, and that supplied much of the talent (Turing among them) to the World War II code-breaking effort at Bletchley Park that laid the foundation for the modern computer. Most spectacularly of all, it was at Cambridge in 1949 that EDSAC-1 — the first stored-program fully electronic computer, meaning the first that could be programmed the way we understand that term today — first came online. (The earlier American ENIAC was programmable only by switching logic gates and rerouting cabling in an elaborate game of Mouse Trap that could consume weeks. At risk of wading into a debate that has swirled for years, there’s a real argument to be made that EDSAC-1 was the first real computer in the sense of being something that operated reasonably akin to what we mean when we use the term today.) In 1953 Cambridge became the first university to recognize computer science as a taught discipline.

For decades computing in and around Cambridge centered on whatever colossus was currently installed in the bowels of the Computing Laboratory. After EDSAC-1 came EDSAC-2 in 1958, which was in turned replaced by Titan in 1964. All of these had been essentially one-off, custom-built machines constructed by the university itself in cooperation with various British technology companies. It must therefore have seemed a dismaying sign of the changing times when the university elected to buy its next big mainframe off the shelf, as it were — and from an American company at that. Coming online in February of 1973, Phoenix — the name was meant to evoke a phoenix rising from the ashes of the newly decommissioned Titan — was a big IBM 370 mainframe of the sort found in major companies all over the world. However, just as the hackers at MIT had made their DEC machines their own by writing their own operating systems and tools from scratch, those at Cambridge replaced most of IBM’s standard software with new programs of their own. Thus Phoenix became, literally, a computing environment like no other.

For more than two decades Phoenix was a central fixture of life at Cambridge. (In hardware terms, there were actually three Phoenixes; newer IBM mainframes replaced older hardware in 1982 and 1989.) It was used for the expected computer-science research, much of it groundbreaking. But it also, like the contemporary American PLATO, became a social gathering place. It provided email access to a whole generation of students along with lively public discussion boards. The administrators delighted in replacing the stodginess of IBM’s standard MVS operating system with their own quirky sensibility. Phoenix’s responses to various pleas for HELP are particularly remembered.

HELP SEX
Phoenix/MVS, being of essentially neuter gender, cannot help with emotional, personal or physical human problems


HELP GOD
Please appeal to deities directly, not via Phoenix/MVS


HELP PHEONIX
Pheonix is spelt Phoenix and pronounced Feenicks.


HELP CS
CS is a standard abbreviation for Computing Service; it is also a "gas" used for riot control.

Given this freewheeling atmosphere, you’d expect to find plenty of games on Phoenix as well. And you wouldn’t be disappointed. Phoenix had all the usual suspects, from card games to chess to an implementation of Scrabble with an impressively fiendish AI opponent to play against. And, beginning in the late 1970s, there were also adventures.

Both Crowther and Woods’s Adventure and Zork (in its Dungeon incarnation, as “liberated” from MIT by Bob Supnik and ported to FORTRAN) arrived at Cambridge as one of their first destinations outside the United States. Like hackers across the U.S. and, soon enough, the world, those at Cambridge went crazy over the games. And also like so many of their American counterparts, they had no sooner finished playing them than they started speculating about writing their own. In 1978 John Thackray and David Seal, two Cambridge graduate students, started working on a grand underground treasure hunt called Acheton. It’s often claimed that Acheton represents just the third adventure game ever created, after Adventure itself and Zork. That’s a very difficult claim to substantiate in light of the number of people who were tinkering with adventures in various places in the much less interconnected institutional computing world of the late 1970s. Amongst just the finished, documented games, Mystery Mansion and Stuga have at least as strong a claim to the title of third as Acheton. Still, Acheton was a very early effort, almost certainly the first of its kind in Britain. And it was also a first in another respect.

Looking at the problem of writing an adventure game, Thackray and Seal decided that the best approach would be to create a new, domain-specific programming language before writing Acheton proper. The result, which has been retroactively dubbed T/SAL (“Thackray/Seal Adventure Language”) today, but was simply known as “that language on Phoenix used to write adventures” during its heyday at Cambridge, represents the first ever specialized adventure programming language. (Even the PDP-10 Zork had been written in the already extant, if unusually text-adventure-suitable, MDL.) The T/SAL system is something of a hybrid between the database-driven design of Scott Adams and the more flexible fully programmable virtual machine of Infocom. Objects, rooms, and other elements are defined as static database elements, but the designer can also make use of “programs,” routines written in an interpreted, vaguely BASIC-like language that let her implement all sorts of custom behaviors. Thackray and Seal improved T/SAL steadily as dictated by the needs of their own game in progress, always leaving it available for anyone else who might want to give adventure writing a shot. Meanwhile they also continued to work on Acheton, soon with the aid of a third partner, a PhD candidate in mathematics named Jonathan Partington. It grew into a real monster: more than 400 rooms in the final form it reached by about 1980, thus dwarfing even Zork in size and still qualifying today, at least in terms of sheer geographical scope, as one of the largest text adventures ever created.

Yet the most important outcome of the Acheton project was T/SAL and the community it spawned. The system was used to create at least fourteen more games over a decade. Freed as they were by virtue of running on a big mainframe from the memory restrictions of contemporary PC adventures, designers could craft big, sometimes surprisingly intricate playgrounds for a brainy audience of budding mathematicians and scientists that reveled in the toughest of puzzles. For those on their wavelength, they became an indelible part of their student memories. Graham Nelson, easily the most important figure in interactive fiction of the post-Infocom era, was an undergraduate at Cambridge during the heyday of the Phoenix games. He writes in Proustian terms of his own memories of the games: “They [the Phoenix games] are as redolent of late nights in the User Area as the soapy taste of Nestlé’s vending machine chocolate or floppy, rapidly-yellowing line printer paper.” Nelson’s later puzzle-filled epics Curses and Jigsaw show the influence of these early experiences at Cambridge in their erudition and sprawl.

Yet we shouldn’t overestimate the popularity of the Phoenix games. Running under a custom operating system on an IBM design that was seldom open to fun and games at other installations, they had no chance to spread beyond Cambridge in their original incarnations. Even at the university, their sheer, unapologetic difficulty made them something of a niche interest. And authoring new games in the rather cryptic T/SAL required an especial dedication. Fifteen games in over ten years is not really a huge number, and most of those were front-loaded into the excitement that surrounded the arrival of Adventure and the novelty of Acheton. During most years of the mid- and late 1980s it was only Jonathan Partington, who in authoring or co-authoring no fewer than eight of the fifteen games was by far the most prolific and dedicated of the T/SAL authors, that continued to actively create new work with the system. It’s probably safe to say that most of the Phoenix games had (at best) hundreds rather than thousands of serious players. Still, they would have a larger impact on the British adventuring scene outside of Cambridge’s ivory tower in a different, commercialized form.

One of the first at Cambridge to pick up on the T/SAL system was an oceanography professor in his early thirties named Peter Killworth, who had been taught a healthy appreciation for the brave new world of possibility that Adventure represented by his seven- and three-year-old sons: “I was constrained by what I knew about computers, but they treated the terminal as a person. While I was trying to work out what an axe was doing in a computer program, they were chopping the nearest tree down.” Killworth was intrigued enough to start tinkering with T/SAL as soon as he noticed it. He wrote a simple physics problem using the language. Through it he got his introduction to the interconnected web of social problem-solving that made the experience of playing and writing early institutional adventures so different from those on PCs.

“I had a problem which revolved around using a pivot to get up a cliff. Put weight on one end, and the other goes up — but you have to be careful to get the weight right. I programmed it on the mainframe, and left it for a friend to have a look at. When I came back next morning, I was deluged with messages from people I’d never heard of, all telling me where I’d gone wrong in the program.”

Encouraged by all this interest, Killworth decided to make a full-fledged game to house the puzzle. The result, which he completed even before Acheton was done, he called Brand X. It was a treasure hunt fairly typical of the general Phoenix aesthetic in its cruel puzzles and relatively heady (by adventure-game standards) allusions to Descartes, Coleridge, and the Bible. Figuring that was that, Killworth then returned his full attention to oceanography — until the arrival of the BBC Micro and Acornsoft caused him to start thinking about his game again a couple of years later.

Of all the technology companies in and around Cambridge, Acorn worked hardest to foster ties with the university itself. Chris Curry and Hermann Hauser made the most of the connections Hauser had formed there during the years he spent as a Cambridge PhD candidate. With Acorn’s office located literally just around the corner from the Computing Laboratory, the two had ample opportunity to roam the corridors sniffing out the best and the brightest to bring in for their own projects. They considered Cambridge something of a secret weapon for Acorn, taking the university itself into their confidence and making it almost a business partner. Cambridge reciprocated by taking Acorn’s side almost en masse as the British computer wars of the 1980s heated up. The university grew to consider the BBC Micro to be the machine that they had built — and not without cause, given the number of Cambridge students and graduates on Acorn’s staff. Clive Sinclair, meanwhile, who like Chris Curry had not attended university, displayed only a grudging respect for the Cambridge talent, mingled with occasional expressions of contempt that rather smack of insecurity.

Acorn Computers had helped one David Johnson-Davis to set up a software publisher specializing in software for their first popular machine, the Atom, in 1980. Now, as the BBC Micro neared launch, Acornsoft would prove to be a valuable tool to advance the goal of making as much software as possible, and hopefully of as high a quality as possible, available for the new machine. Just as their big brothers had in designing the BBC Micro’s hardware, Acornsoft turned to the university — where prototypes were floating around even before the machine’s official launch — for help finding quality software of all types. They offered prospective programmers a brand new BBC Micro of their own as a sort of signing bonus upon acceptance of a program. After a friend got a statistics package accepted, Peter Killworth started to ponder whether he had something to give them; naturally, his thoughts turned to Brand X. He rewrote the game in the relatively advanced BBC BASIC, using every technique he could devise to save memory and, when that failed, simply jettisoning much of the original. (Ironically, the physics problem that got the whole ball rolling was one of those that didn’t make the final cut.) He then presented it to Acornsoft, who agreed to publish it under the title of Philosopher’s Quest, a tribute to the game’s intellectual tone proposed by Johnson-Davis’s right-hand man Chris Jordan. It was published in mid-1982, the first game in the Acornsoft line. Killworth hoped it would sell at least 500 copies or so and earn him a little bit of extra pocket money; in the end it sold more than 20,000.

Even in its chopped-down microcomputer incarnation, Philosopher’s Quest provides a pretty good introduction to the Phoenix aesthetic as a whole. An unabashed treasure hunt with no pretensions toward narrative or mimesis, its geography simply serves as the intellectual landscape to house its puzzles. To understand the game’s level of commitment to physical reality, consider that, after swimming underwater for a while, you can still strike a match inside the whale that swallows you. (Don’t ask.) We’re a long way from Zork III and its realistic simulation of the effects of swimming in a lake on a battery-powered lantern.

Yet the writing is as solid as it can be within the constraints of 32 K, with occasional flashes of dry wit and an awareness of culture beyond Dungeons and Dragons and Star Wars that’s pretty rare amongst games of its era. The parser is the typical two-worder of the era, but the game doesn’t strain to push beyond its limits, so it only occasionally frustrates. While not huge, the game is amazingly large given the memory restrictions under which Killworth was operating and the fact that he was working in BASIC. He was already an experienced programmer of weather and ocean simulations thanks to his day job, and his expertise comes through here. He would later speak of an “unofficial competition” with the Austin brothers of Level 9, kings of text compression, over how much text they could cram into the minuscule amounts of memory they had to work with.

The puzzles are a mixed bag, sometimes brilliant but always heartless. The very beginning of the game tells you everything you need to know about what you’re in for. You start in a store from which you can only remove two out of four items. You can increase this number to three through a clever action, but there’s no way to know which one of the four you’re not going to need later in the game; trial and error and learning by death are the rules of the day here. Still, some of the puzzles border on the beautiful, including one of my favorite guess-the-verb puzzles of all time. (Yes, like much in the game this puzzle violates the Player’s Bill of Rights in depending on outside knowledge, but, atrocities like Zork II‘s baseball maze aside, this has always struck me as the least of adventure-game design sins, especially in this era of readily accessible information on virtually any subject. I rather like it when a game sends me scurrying to the Internet in search of outside knowledge to apply. And I feel really special when, as in this case, I already have the knowledge I need.)

Other puzzles, however, are cheap and unforgivable in that way all too typical of early text adventures. There’s a vital room exit that goes completely un-described and thus can be sussed out only by beating your head against every wall in every room when you’ve reached the point of total frustration. More than anything else, the game takes delight in killing you, a parade of gruesome if often clever deaths, most of which you’re going to experience at least once in the course of playing; these are not jumping-off-a-cliff-to-see-what-happens deaths, but rather innocently-entering-a-room-only-to-be-trampled-by-an-elephant deaths. The deaths are so numerous and so absurd that they almost come off as parody. More so even than many other old games, Philosopher’s Quest can be enjoyed today, but only if you can get yourself in tune with its old-school sensibilities. Unsurprisingly, it and the other Phoenix games are very polarizing these days. Graham Nelson among others remains a big fan, while still others find them an exercise in masochism; see this old newsgroup thread for a sample of typical reactions.

Peter Killworth continued to write adventures after Philosopher’s Quest, for Acornsoft and later Topologika (who also published quite a few of the other Phoenix games for PCs). Already by 1983 he was earning twice as much from his games as he did from his Cambridge professorship. He later dismissed Philosopher’s Quest and its sometimes arbitrary puzzles as something of a learning exercise, but he always retained his reputation as an author of difficult games. For Killworth’s follow-up to Philosopher’s Quest, Castle of Riddles, Johnson-Davis had an idea that would begin something of a tradition in the British adventure-gaming scene. Acornsoft and Your Computer magazine sponsored a contest with a prize of £1500 worth of Acorn hardware and a £700 silver ring to the first person to solve the game. It took winner Peter Voke, Britain’s equivalent of the American adventure-gaming machine Roe R. Adams III, a full eight hours to solve the game. (Runner-up Colin Bignell made a mad cross-country dash through the night to get his winning entry to Your Computer, but pulled up in his car in front of the magazine’s headquarters just 20 minutes behind Voke.) Killworth also authored one of the classics of the sub-genre of adventure-authoring guides that were popular in the early and mid-1980s, the aptly titled How to Write Adventure Games. He died in 2008 of motor neuron disease. Even when he was earning more from his adventures than he was from his day job, games were just a sideline to a significant career in oceanographic research.

We’ll likely be revisiting some of the later works of Killworth and the other Phoenix authors at some point down the road a bit. For now, you can download Philosopher’s Quest and Castle of Riddles as BBC Micro disk images. (I recommend Dave Gilbert’s superb BeebEm emulator.) Most of the original incarnations of the Phoenix games, Brand X included, have been ported to Z-Code format, playable in my own Filfre and countless other interpreters, thanks to a preservation effort led by Graham Nelson, Adam Atkinson, and David Kinder following the final shutdown of Phoenix in 1995.

 
 

Tags: , ,