Exhibiting The Hobbit: A tale of memories and microcomputers

Helen StuckeyPDF
Flinders University

 

Introduction

The challenge of collecting and exhibiting videogames is a significant issue for contemporary museums. This paper provides a case study of Beam Software’s successful text adventure of the 1980s, The Hobbit, which offers some insight to the challenge of videogames for museums.  The Hobbit is an exemplary text in this regard because it exists in so many variant forms, which raises questions about what/where/ and which one is the game.

The discussion is informed by my experiences working as the Games Curator at the Australian Centre for the Moving Image (ACMI) where in 2006 I showed The Hobbit (1982) as part of an exhibition Hits of the 80s: Aussie games the rocked the world. The game was surprisingly challenging for audiences and many found the text adventure’s gameplay alien and difficult to engage with. It was hard for audiences to appreciate the ingenuity and creativity of the design, instead they saw only unfamiliar and outdated gameplay.

The discussion also draws on my current research with the ‘Play it Again’ project, in particular the development of the online Popular Memory Archive. Play it Again is a collaborative project between researchers at several Australasian universities and three cultural institutions – ACMI, the New Zealand Film Archive, and the Berlin Computerspiele Museum. The multi-disciplinary research team is endeavouring to research, collect, and preserve the production and reception histories of local digital games in 1980s Australia and New Zealand. The Popular Memory Archive, one of its outcomes, is an online database documenting a selection of Australian and New Zealand games of the 1980s. It is a ‘curated’ collection that offers an interface inviting fans, collectors, game designers, players and journalists from the period to engage in a direct dialogue with the works (including the ability to contribute artefacts).

In the first part of this paper I consider that, despite the way we refer to The Hobbit as a single work, it was produced for over nine platforms, each differing slightly from each other. Whilst the gameplay remains consistent across all versions, the look and feel of them varies.  I ask what is lost in the act of identifying The Hobbit as an ideal amalgam of all its differing iterations or with the act of selecting a single or ‘original’ version to stand for all versions.  I argue that an understanding of the work is greatly enriched by acknowledging the subtle distinction between these multiple versions of the games. Further, I argue that the multiplicity of Hobbits actually helps preserve a better understanding of the culture of videogames of this era.

In the second part of this paper I address how the Museum might also include the strategy of capturing and displaying the experiences of original players of The Hobbit.  I propose that as well as documenting the broader culture of its reception, player stories can reconnect contemporary audiences with a sense of what makes the work significant.  Collecting players’ memories of the game – including tales such as locking themselves in the trunk at BagEnd, or the discovery that Gandalf had wandered off and got himself killed – constitutes another way of ‘remaking’ or remembering the game. In the case of The Hobbit these multiple tellings are particularly important in understanding and preserving the game’s celebrated sense of an open world.

In addition to the voices of players, are the player-created-artefacts, such as walkthroughs and speed runs that exist as legacy items for the work. Games theorist James Newman has argued the value of player-produced walkthroughs for games preservation, stating that these artefacts can offer more insight about gameplay than preserved gamecode (Newman, 2011 p110). The player-created Hobbit artefacts, some produced in the 1980s and some created later, serve to provide a deeper understanding of the game.

The Hobbit

Beam Software’s text adventure The Hobbit, was a seminal game for many people who encountered it in the 1980s on their home computers. The game had a sophisticated parser that far outreached the two word command logic puzzles possible in Scott Adams’ popular Adventure series. But even more fascinating was the wonder of its dynamic world; where time passed independent of the players actions; the objects in the world had simple physics allowing them to be carried or placed inside other objects; and non-player characters (NPC), -each defined by a small set of randomised actions- went about their business autonomously, taking a turn when the player took theirs. This dynamic world also allowed for curious emergent events that sometimes helped or hindered the player on their quest, thus fulfilling the games promise “No two games are alike”.

Many Hobbits

Designed by Veronika Megler and Philip Mitchel, The Hobbit was first released in 1982 on the ZX Spectrum (Fig.1). (1) It was to be a very successful game. At a time when home computers were an eccentricity, it is said to have sold over a million copies. To achieve this extraordinary figure The Hobbit was released for as many home computers as Beam director Alfred Milgrom thought viable. It was quickly ported to Beam’s other platform of choice, the Commodore 64 (Fig.2). According to Gregg Barnett, Beam’s Commodore expert, the port was simple and fast as Mitchell had done an excellent job in documenting all the routines. Everything appears very similar except for one crucial difference – the graphics run very slow on the Commodore. Barnett explains how the Commodore 64 did not really support graphics created for the Spectrum. “The Commodore is not about raw power for graphics, it’s about using fancy tricks.  So this was all old school, [draw a line fill it in] so the [Hobbit’s] Commodore graphics were quite slow and you could spend all day watching the green door fill…”(2)

s1     s2

Figure 1. The Hobbit, (1982) ZX                 Figure 2. The Hobbit, (1983) Commodore 64
Spectrum – Tape                                         – Tape

The tape version of The Hobbit was also ported to the Oric, a system renowned for attribute clash where the graphics took on a more lurid hue. The Amstrad CPC sported a whole new palette of colours (Fig.3) and the BBC Micro did not have enough memory for the graphics to be included.

s3    s4

Figure3. The Hobbit (1983) Amstrad                Figure 4. The Hobbit (1985) Commodore 64
– Tape                                                                  – Disk

 In 1985 Beam reworked The Hobbit to take advantage of the added memory of the Commodore 64’s disk drive. By this time Beam employed dedicated artists, Russel Comte and Greg Holland, who created full bitmap graphics using the fancy tricks of the Commodore 64 graphics chip (Fig.4). This allowed for more images to be added throughout the game. The game was further enriched by the addition of music composed by Beam’s in-house sound designer Neil Brennan. This new look Hobbit was released for a number of microcomputers with disk drives including the MSX, BBC Micro, Apple II, Macintosh and PC. Its appearance differs across platforms the Apple II (Fig. 5) and the Macintosh (Fig.6) display distinctly different palettes to the Commodore 64.

 

s5  s6

Figure 5. The Hobbit (1985) Apple II                      Figure 6. The Hobbit (1987) Macintosh                – Disk                                                     – Disk

 

What to collect?

The game plays the same across each platform. So why bother with the fact it loads slowly on some, does not have music on all, has better looking graphics on some, black and white graphics on another and no graphics at all on one? It is the curator’s job to make decisions on what to collect and exhibit based on framing narratives, rather than an encyclopaedic notion of collecting all possible associative material. For Hits of the 80s we exhibited an emulated version of the 1982 tape edition for the ZX Spectrum – the platform for which Beam had originally developed The Hobbit.(3)  It was not the first release, but the less buggy 1.2 which featured the designer’s on screen credits. For an exhibition on the story of Beam, it is the version that is most intimately linked to Megler and Mitchell’s creative processes. It is an obvious and sensible curatorial choice to show. But what does it mean for fans of The Hobbit on the Apple II if the Museum identifies the game solely with its release on the Spectrum? Does this make a statement that invalidates the authenticity or significance of their personal experiences of the game? What does it mean for the 1985 Commodore 64 version which features the finer graphics created by Beam’s new team of artists and the celebrated sound design of Neil Brennan? What understanding do we lose about the work of Philip Mitchell who spent several years working on all these ports?

Telling Stories

It is worth considering what kinds of stories these multiple versions of The Hobbit can help to tell. There are a number of things we can discern from looking at these differing images. Firstly it is apparent that what makes a game is not just the code but the interaction with the specific hardware. To games designers, hobbyists and most players this may seem self-evident, but an increasing dependence on emulation homogenises the experiences of playing erasing the impact of specific platforms. Secondly, in a simple perusal of screenshots we can readily identify those games that utilized the increased memory provided by use of a disk drive. A comparison of screenshots of the differing BagEnds enables us to tell a story about the era of the microcomputer in which The Hobbit was designed, where each platform had its own technical requirements, constraints and look. (Figs 1-6).

Ironically, by drawing focus to the difference in appearance, these multiples help define what the ‘game’ is.  That they are all ‘the same game’, draws attention to the key game mechanics – highlighting the gameplay as distinct from the game’s look and feel. Communicating these types of relationships can be difficult in the exhibition environment. In the hands of the curator, these differing versions can become a means to provoke interesting questions from audiences about the impact of hardware and the nature of gameplay.

An Opportunity

In the book 1001 Videogames you must Play before you Die the entry for The Hobbit reads ‘platforms “various”’ raising the question about what is lost about our understanding and appreciation of this work by this act of documentation which edits out its hardware alliances and multiple versions (Mott, p.50).  Caitlin Jones and Lizzie Muller in their examination of the history of performance and media art, reveal that what survives through catalogues and other formal documentation is the artist’s ‘idealised’ conception of the work, with little or no record existing of the works’ actual reception and experience in the gallery (Jones and Muller). Videogames, perhaps, have suffered from the reverse of the situation. The story of development and authorial intent is typically poorly recorded and the bulk of information on videogames focuses on the reception of the work. For historic games like The Hobbit this exists in the form of game reviews from the era and in contemporary retro game sites, that document the anecdotal memories of gamers.  Whilst the lack of documentation on games development is an absence that the Museum needs to address, the availability of reviews and player experiences provides an opportunity. How might the Museum access and preserve these valuable records?

Collecting Player Stories

With the Popular Memory Archive Play It Again, we are looking at the way the retro gamer sites collect both comments and remembrance from visitors and how we might work to curate, display and preserve these (Stuckey, Swalwell, and Ndalianis; Stuckey and Swalwell). These records and comments contain information that cannot be conveyed by simply playing the games. They offer both documentation of the game itself and the culture that surrounded it. For example, in a comment posted on Lemon64.com on April 15, 2004, Ed Waddington remarks on the stresses of dealing with The Hobbit’s infamous recalcitrant NPCs whose behaviour (influenced by their interaction with the player) provided them with the ability to say “no” to actions essential for the player to complete the game.  He describes Gandalf’s refusal to help him escape from the Goblin Dungeon and the struggle to get Bard to shoot the dragon.

Other curious discoveries include the memories of ‘Grandmaster’ on the Eurogamer web site, who reminisces about gorging on Elrond’s free lunches until the game informed him “your own foul gluttony kills you”.(4) Whilst comments on a YouTube video of playing The Hobbit on the Commodore 64 a player called ‘dazestorm’ complains he could never get past the kings wine cellar, reminding us that for many these games were never experienced as ‘complete’.(5)

Not all remembrances of the game are about the game itself. A blogger called Winterdrake discusses the impact that The Hobbit had on him as nine year old boy in Portugal. He tells how playing the game initiated a set of changes in his life – including encouraging him to read books, learn English and not give up on difficult challenges (Winterdrake). A number of comments on Winterdrake’s post from French and Portuguese speakers reiterate the sentiments of his youthful encounter with the foreign language game.  These kinds of stories can help communicate to contemporary audiences not just information about the gameplay but some of the reasons that game excited and intrigued players – and frustrated and disappointed them.

A History of Use

According to Patricia Galloway and Melanie Swalwell, to understand the history of personal computing we need to move away from a technology history to a history of use. They stress the importance of personal knowledge to understand personal computing (Swalwell; Galloway). James Newman, in his work with the UK’s National Videogame Archive, questions the whole validity of focusing on hardware and software preservation, arguing that it is more sensible to focus attention on documenting play, which not only can be preserved, but provides a lived experience of the game (Newman, 2011). Player stories provide a way to both examine the games and engage audiences more directly with the significance of historic games.

Player Artefacts

Other material that helps make sense of the game as played, are player made artefacts such as walkthroughs. Newman has argued that the player-produced walkthrough give rise to some of the most insightful games analysis and investigative analysis available (Newman 2011, 2012). A Guide to playing the Hobbit was a comprehensive gameplay guide written by a player David Elkan, who sent it to the offices of Melbourne House/Beam Software (Elkan). Milgrom published it as a book that became the salvation of many players.(6) The guide however is not a straight forward walkthrough as the gameworld was different with every playthrough. To address this, the guide offers a detailed account of playing in each area.  It offers a semantic map of the game, a lexicon on the principles of the parser and links the game’s puzzles back to Tolkien’s story. Published in 1984 the book is an early example of a player generated artefact that was shared with other players. It is a remarkable record of the game, complete with black and white illustrations of the original game graphics.(7)

In contrast the You Tube video speedrun “ZX Spectrum The Hobbit completed in 7 minutes!” by Jammajup01 offers a reading of the game against the text. It a different kind of walkthough, documenting one players scheme to beat the game by playing the system and not the story. To ensure a speedy pathway Jammajup01 avoids the Goblin Dungeon  a place where the links between areas are generated using ‘special routines’ resulting in the possibility  of different relationships between areas for each play through.(8) However, by avoiding the Goblin’s Dungeon, he does not ever encounter Gollum or get the ring, making it a curious ‘telling’ of  Tolkien’s Hobbit. As a document it helps reveal how the gameworld operates, offering a way to discuss both the ingenuity of the world design and that of players.The third player created artefact is perhaps the most fascinating and most valuable for exhibiting The Hobbit. Wilderland (2012) shows what is really going on in the world created by Megler and Mitchell. In Wilderland the original game code for the Spectrum runs in an emulator and as the game is played, Wilderlands user-friendly interface shows the internal state of the machine.(9) Windows surrounding the game screen display the state of objects and animals, a map with the current positions of animals and a log of what all the other creatures (NPC) are doing. (Fig. 7)  The Wilderland software passively observes the memory of the emulated computer (without interfering) to see what is happening in the game. Coupled with knowledge of the data structures used in the original source code, such as what ID numbers represent, it produces a record of events in a format that can be understood by the user.(10) The creator of Wilderlands motivation for building the interface dates back to the 1980s, when he was playing the game and encountered the cryptic message “this room is too full for you to enter”. Anxious that this would mean that he would miss out on an important part of the game he started looking into the source code – a difficult task on the ZX Spectrum.(11) What he has since created exposes what is happening in the game to reveal hidden relationships between the user and the system. For the curator it literally offers the opportunity in the gallery to make visible the invisible, enabling a deeper level of engagement with the artefact for the museum visitor.

s7

Figure 7. Wilderland (2012) CH
 

Conclusions

What is collected and preserved now, become the fragments that future historians and curators will use to structure the histories they tell (Lowood, 2011). We need to start thinking about the kinds of stories we want to preserve and what resources will help us tell them. Working with historical games we have minimal opportunity to ask developers to provide rich resources, most of which are now lost.  Nor can we communicate directly with active player communities to capture their knowledge. The process for historic games is more archaeological in its approach. We work with fragments and although we may still (for the moment) have access to the original game artefact, it is not the full story.

Videogames offer complex relationships with the player and it is often what players do with the object of design that is as significant as the work of the designer. Exhibiting player memories and artefacts can provide an understanding of the game that is far richer and nuanced than that generated by just presenting the game as a playable object. In addition, collecting and displaying versions and ports, can help a curator tell more complex stories about the era of the microcomputer and their influences on game design.

The challenges of collecting and displaying videogames take the Museum away from its traditional object/author focus. Games history is not a history of objects that can be satisfied by simply archiving examples of hardware and game software. A playable game may be comparatively mute in the gallery. By including the voices of the players we can help provide a rich and diverse historical record. The history of videogames of the 1980s is a history of tales of collaboration and cheating, of personal goals and emergent play and the development of relationships to the game beyond the engine. It is a history of versions, ports, hacks and tinkerings. The case of the ‘many Hobbits’ suggests the story of videogames of this era is perhaps best captured and communicated through a series of fragments and artefacts that document the intent of the designers, the differing versions encountered and the distinct voices of multiple players.

 

Notes

(1) For the design of The Hobbit Veronika Megler was principally responsible for the design of the game world and Philip Mitchell for the games parser. CH in his forensic work in creating Wilderlands notes that two distinct styles of coding distinguish the two designers work.

(2) Barnett, Gregg. Personal interview.  27 December, 2012.

(3) Ideally ACMI would have exhibited the work on original hardware but due to issues of resources and reliability this was not possible. To draw attention to the act of emulation two versions of The Way of the Exploding Fist were exhibited side-by-side emulated and on a Commodore 64.  Curiously most people preferred to play the game on familiar PC hardware and the Commodore was favoured only by those who had lived through the era.

(4) Comment posted in 2007 to “The Hobbit Review”, Eurogamer.net 2007. http://www.eurogamer.net/articles/the-hobbit-review. Accessed 12 December 2012

(5) “i remember this well, i never could get past the kings wine cellar, i get in the wine barrel and the wine barrel would be released into the portcullis waterfall, the barrel crashing far below to the rocks below and instant death” Comment posted in 2010 on You Tube Video ‘The Hobbit adventure game for the C64’, 2008 http://www.youtube.com/watch?v=SZsyv5aKw4U. Accessed 10 December 2012

(6) Milgrom, Alfred.  Interview by Noe Harsel and Helen Stuckey, 2006.

(7) Milgrom recounts that they received a lot of correspondence regarding The Hobbit mostly requesting help with the game. (Milgrom, Alfred. Personal interview. 20 March, 2013) Barnett recalls taking a call from an irate mother complaining that her son could not get any “a” words to work in the game. He politely asked where they had purchased the game and heard the son in the background begging his mother to get off the phone. Barnett had set up the tape version of the Commodore 64 game so that tape buffer held executable code, if you had a pirated copy of the game the “a” database would be missing. (Barnett, Gregg. Personal interview. 27 December, 2012)

(8) Veronika Megler explains that she designed the location database so that each direction or exit could have a “special routine’ associated with it if desired. “…if a character (player or non-player, in most cases it made no difference) went in that direction, any special routine associated with that direction would be applied. In this way, for example, a door could be associated with certain physics (e.g., a character couldn’t go through if it was carrying more than a certain number or size of goods). Such a routine could also have deposited a character in some randomly chosen « next » location.” Veronika Megler, Personal Communication, 12 November 2013.

(9) I am using the term ‘original’ here to refer to the games 1982 release for the ZX Spectrum. CH notes that the version of game code Wilderlands runs is neither the buggy v1.1or the bug fix v1.2 but a copy of his own tape from the era which his forensic studies reveals is slightly different from both these versions.

(10) Thanks to Craig Harrington for his explanation of Wilderlands in action.

(11) Armed only with a rudimentary printer and according to him not much programming knowledge CH attempted in the 1980s to determine how the gameworld of The Hobbit ‘worked’. He tried again with a PC in the 1990s this time revealing the database-like game structure with its tables of objects, words and rooms. But it was not till recently that he found that tools to expose the inner workings of the game, an almost thirty year journey (CH, 2012).

References

Elkan, David. A Guide to Playing the Hobbit. South Melbourne: Melbourne House, 1984. Print.

Galloway, Patricia. “Personal Computers, Microhistory, and Shared Authority: Documenting the Inventor-Early Adopter Dialectic.” IEEE Annals of the History of Computing 33.2 (2011): 60–74. Print.

CH. “Wilderland: A Hobbit Environment.” 2012. Web. 10 Feb. 2013. http://members.aon.at/~ehesch1/wl/README.txt

Jones, Caitlin, and Lizzie Muller. “Between Real and Ideal: Documenting Media Art.” Leonardo 41.4 (2008): 420–421. Project MUSE. Web. 10 Feb. 2013. http://muse.jhu.edu/

Megler, Veronika., Mitchell, Philip. and Milgrom, Alfred. des. The Hobbit, Beam Software, 1982-1987. ZX Spectrum, Commodore64, BBC  Micro, Amstrad, Dragon 32, Oric, MSX, Apple II, Macintosh, PC Booter. Videogame

Mott, Tony, ed. 1001 Videogames You Must Play before You Die. New York: Universe, 2010. Print.

Newman, James. “(not) Playing Games: Player-Produced Walkthroughs as Archival Documents of Digital Gameplay.” The International Journal of Digital Curation 6.2 (2011): 109–127. Print.

—. Best Before: Videogames, Supersession and Obsolescence. London and New York: Routledge, 2012. Print.

Stuckey, Helen, and Melanie Swalwell. “Retro-Computing Community Sites and the Museum.” The Handbook of Digital Games. Ed. Harry Agius and Marios Angelides. IEEE/Wiley, Forthcoming. Print.

Stuckey, Helen, Melanie Swalwell, and Angela Ndalianis. “The Popular Memory Archive: Collecting and Exhibiting Player Culture from the 1980s.” Making the History of Computing Relevant. Ed. Arthur Tatnall. Berlin: IFIP Springer, 2013. Print.

Swalwell, Melanie. “Questions of Microcomputers’ Usefulness in 1980s Australia.” Media International Australia 143 (2012): 63–77. Print.

Winterdrake. “The Hobbit (ZX Spectrum, 1982) And How a Kid Became a Geek.” Winterdrake. 2011. Web. 10 Mar. 2013. http://winterdrake.com/the-hobbit-zx-spectrum-1982/