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 clone. 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 antecedents 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. They had only one request: that the game be released with a copy of the book included, to which Milgrom readily agreed: “That way you get clues on how to solve the adventure from the book. It also fills in many details we just didn’t have space for in the 48 K.” 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 Brand 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 Brand 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. Either way, it sold like crazy.
Exactly how many copies the game eventually sold 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 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.)