The Hobbit Emulator
Valda Atkeson
Since none of the team felt qualified to write an original story, they decided to base it on an existing property. Melbourne House had been a book publisher before getting into games, and its owner had years of contacts and experience licensing Australian rights to US and UK titles. The company worked out an arrangement with the Tolkien estate for a book-to-videogame adaptation, probably the first such deal ever made.
I was an owner of the ZX Spectrum, which due it's simplicity was the first choice of microcomputer for smuggling behind the Iron Curtain. But my limited knowledge of english that time when playing The Hobbit and lack of access to book itself /published only once in soviet sattelite country with limited impression - Lord of the Rings was blacklisted by censorship in soviet sattelite countries at all/ made a very different game target - my objective was to visit as many locations as possible with a limited english knowledge, far away from finishing the game up to the end. And of course I had no idea who they were in fact - Gandalf, or other personalities in the game, because the only contact with Tolkien imaginary work was through this game, or illegal copy of the game, in coutry where they were not selling any software in shops, nor Tolkien books in bookstores. :D
I got to know Veronika a little bit when she was working through her PhD at my school a few years back. An absolutely delightful person: smart and creative and energetic. I had no idea she'd written that game entirely in Z80 assembly: that's pretty amazing. Thanks for a great piece!
In Australia the academic year starts in January, so it was just a few weeks into 1981 when a computer science student named Veronika Megler returned to the University of Melbourne for her senior year. On the hunt for a new part-time job to pay the bills, she noticed a terse note pinned to the bulletin board outside the computer center: someone needed students for some part-time programming work. The pay was ten dollars an hour. When Megler dialed the phone number on the ad, it turned out the man who posted it had started an Australian software company to make computer games, of all things, for the burgeoning UK market. The position he hoped to fill, he explained eagerly, was straightforward. He wanted to find someone to \u201Cwrite the best adventure game ever. Period.\u201D
Megler had been hacking hardware and software for years, ever since giving up first-year plans to become an actuary: \u201CI discovered I was bad at statistics and good at computers.\u201D Her old job had been managing the campus mainframe, and her few spare hours outside work and school were often spent on hobby projects like writing control programs for a model railroad (typing them in on a hexadecimal keypad, in assembler) or building her own computer from kits in magazines. \u201CI would go to the electronics parts store with my list of chips, resistors, capacitors and diodes,\u201D she later recalled. \u201CIn the store they\u2019d say, \u2018tell your boyfriend we don\u2019t have these\u2019\u2014it was not even considered possible that I might be the person purchasing them.\u201D Sexist attitudes were \u201Calive and kicking\u201D on campus; in \u201Cself-defense,\u201D Megler teamed up with one of the few other women in the program, a friend named Kerryn, to do group projects. The pair were sometimes joined by a guy named Philip Mitchell and a buddy of his \u201Cwho were amongst the few men willing to partner with us.\u201D Megler didn\u2019t often need the help. In her interview with the Australian game company, Melbourne House, she so impressed the owner that he hired her on the spot. She quickly recruited her three group project friends, too.
But the four had little experience with computer games. The company\u2019s founder was familiar with the microcomputer titles from Adventure International like Pirate Adventure, and hoped to improve on them with new generations of more capable machines. But the only earlier text game Megler knew was the original Adventure, which she\u2019d played \u201Cobsessively for some time, mapping out the \u2018maze of twisty little passages,\u2019\u201D until she beat it: \u201CAt that point it instantly lost interest for me, and I don\u2019t believe I ever played it again.\u201D Thinking back on Adventure with the prospect of designing her own game now at hand, she realized the root of her boredom was its static, unchanging structure: \u201CIt played the same way every time. Each Non-Player Character (NPC) was tied to a single location, and always did the same thing.\u201D She decided her game would be different.
Megler\u2019s game took a unique approach unlike nearly any previous text adventure. She designed her NPCs not as static objects little different from props or treasures, but \u201Canimals\u201D that could move across the map and take their own actions: they would even act in real-time if the player didn\u2019t type anything at the keyboard for a while. (Though she didn\u2019t know it, she was taking a parallel track to Richard Bartle\u2019s real-time MUD and its \u201Cmobiles\u201D with \u201Cinstincts.\u201D) Megler\u2019s characters \u201Cjust \u2018played\u2019 the game themselves according to their character profile,\u201D she later wrote:
I conceived of an NPC\u2019s character as being a set of actions that the NPC might perform, a sequence in which they generally performed them and a frequency of repetition. The individual actions were simple and were generally the same actions that a player could do (run in a given direction, attack another character, and so on); [but] these routines could be overridden for a specific character. ...The apparent complexity of the character comes from the length and flexibility of its action sequence; the character \u201Cemerges\u201D as a result. For example, Gandalf\u2019s short attention span and kleptomania were represented by a sequence like: \u201C[go] . [Pick up] [Say, \u2018what\u2019s this?\u2019]. [Go] . [Put down] .\u201D
\u201CI went through the book [of The Hobbit],\u201D she wrote, and \u201Ctried to identify common sequences of behavior that I could represent through a sequence of actions that would capture the \u2018texture\u2019 of that character.\u201D A troll might simply move about at random and try to kill anything it saw, while Thorin had a penchant for complaining, following Bilbo\u2019s lead, and singing about gold. Combined with a heavy use of randomness for both action results and map layout, the result was a simulated world at turns frustrating and fascinating: no two games would be exactly alike. In one, Gandalf might have wandered off and gotten killed by a warg; in another Elrond\u2019s secret directions might change, or he might refuse to give them at all; a carefully made map of the goblin dungeons on one playthrough would be altered by the next; and the sword you were counting on for defense might have shattered because you used it to break down a locked door.
This last kind of outcome was enabled by Megler\u2019s choice to make even the static objects in the game more dynamic. Each had properties like weight, size, and fragility, and rather than define puzzle solutions as particular commands (such as KILL DRAGON) the game often merely looked for a state (such as the dragon being dead) which might have come about in any number of ways. It wouldn\u2019t matter whether you convinced Bard to shoot the dragon with an arrow, bulked up on elf food and clobbered him to death yourself, or even if he blundered into another enemy of his own volition, fought it, and was defeated: if the dragon was dead, the puzzle was solved.
Working with other characters\u2014who could take actions that Bilbo the hobbit could not\u2014was also a key part of gameplay. A good example comes when Bilbo is imprisoned in the goblin tunnels beneath the Misty Mountains, and discovers (or waits around until) another companion has been captured too:
But another solution, if you\u2019ve mapped the tunnels, is to give your companion a sequence of orders to escape and then come back to set you free: SAY TO GANDALF \u201COPEN WINDOW, GO WEST, GO SOUTHWEST, OPEN DOOR\u201D. There\u2019s three possible outcomes to this strategy, one walkthrough notes: either the door will open with your companion waiting outside; they\u2019ll end up back in the dungeon with you because they were recaptured along the way; or you never see them again because they got killed trying to carry out your plan, leaving you alone in the lurch.
Unlike most contemporary text games written in higher-level languages like BASIC, Megler wrote The Hobbit directly in assembler. This meant the game\u2019s complex code could run at more than a snail\u2019s pace, but it also had serious drawbacks: debugging it was extraordinarily difficult. Assembler code moves individual numbers in and out of memory registers, making high-level behavior like Megler\u2019s proto-AI harder to visualize and follow:
Modern debugging conveniences did not yet exist in 1981 for Z80 Assembler. \u201CThe Basic programmer\u2019s technique of inserting \u2018print\u2019 statements to find out what is happening is not available,\u201D Megler remembered grimly. \u201CWe had characters interacting with each other in distant parts of the game, and only actions in the current location were printed on the game player\u2019s console.\u201D A crash might have been caused by some NPC action halfway across the map, which could only be diagnosed, if at all, by poring through core memory dumps. Even simple needs were hard to meet: the game\u2019s target platform had no reliable random number generator, not even a system clock, so Philip Mitchell spent endless hours experimenting with pseudo-randomness that could lend the game the unpredictability Megler wanted. Even when everything was working as designed, the game\u2019s emergent behavior often led to outcomes that seemed like bugs, such as a rampant baddie killing all the NPCs in the game before the player could even meet them.
c80f0f1006