You can read more of my writing over at the Meeple Like Us blog, or the Textual Intercourse blog over at Epitaph Online.  You can some information about my research interests over at my personal homepage, or on my profile at Robert Gordon University.

You can find part two of this blog series here.

---

Introduction

There are few gaming genres in which the concept of the puzzle is as deeply embedded as that of the adventure, especially the text-games that were so popular during the early eighties. In many ways, the video game puzzles that we experience in modern titles are the direct descendants of those early  examples.      Graphical  games of  the era, barring  notable exceptions  such  as the Atari 2600’s Adventure, rarely had the narrative depth to offer opportunities for incorporating puzzles and focused instead on developing and presenting the ludic elements to players (Heron and Belford, in prep). The original text games lacked any kind of graphical ornamentation, choosing instead to represent the world for players in the form of written narrative which allowed for a more subtle and story-based game experience. Through the use of a game parser, a subsystem which took written commands from the player and converted them into in-game actions, text games offered an opportunity for nuanced and sophisticated input and output. Arcade-style games offered engagement through interaction with the story, if it was present at all, relegated to external documents and instruction sheets (Heron and Belford, in prep). Text games however could not hope to engage through an inherently satisfying interface, and so had to focus instead on delivering an engaging story or taxing the cerebral faculties of their players. This became one the selling points of the game itself, as is demonstrated by the advertisement shown in the image below.

It is within game worlds like these that the puzzle emerged as a first-tier gameplay element.   The first text adventures, which would later became branded as ‘Interactive Fiction’, evolved in university departments and related research institutes and on comparatively high-powered mainframes (Montfort, 2003 p87; Frenger, 1998) – often the PDP-10 or other DEC variants. Such machines had comparatively few restrictions on storage and processing in comparison to home computers and benefited too from a vibrant hacker culture that encouraged and facilitated revision, redistribution and remixing of the software source files that were located in user directories (Raymond, 2001). The result was an environment where software would be made available in a first draft form and then continually expanded by users until dozens of variants with different feature- sets were available (see for example Dalenberg, 2004). Occasionally the framework of  such programs would be used to create new programs, in a rudimentary step towards the kind  of reusable game engines that are now commonplace.

This rich culture of re-use and innovation would later spawn off a secondary branch of games – that of the Multiuser Dungeon (MUD).  MUDs were text games where the open text parser was joined  to a multiplayer server and the world designed to support potentially many players adventuring together either collaboratively or competitively. The latter aspect of this required a certain style of design that was not necessary in single player text games. Gameplay, rather than story, elements had to be the focus because of two primary complications. The first was the difficulty of algorithmically presenting narrative in a multi-user environment where cause and effect may be spread over dozens of individuals. The second was that in order to ensure integrity of  the multiplayer game there needed to be content that refreshed its state – enemies when killed would need to re-spawn, puzzles when completed would need to be reset, and players that died would need to be reborn. Although the focus of MUDs was usually on the ludic rather than the narrative for these reasons they tended to share a focus on the game puzzle as a primary selling point and key method of in-game advancement.

Both of these game forms eventually became commercially unviable despite being extraordinarily successful in the early days of computer gaming (Heron, 2013). Both however are the keystones of further gaming evolution – the text adventure became the graphical-text adventure, which in turn became simply the ‘adventure’ game expressed as either classic ‘Point and Click’ or as the more modern graphic adventure exemplified by titles such as Telltale Games’ ‘The Walking Dead’.   MUDs in turn inspired the creation of the Massively Multiplayer Online Role Playing Game (MMORPG). Early experimentations in the latter area were influential in showing the viability of MUD style gameplay with graphical front-ends. Later titles, including Ultima Online and Everquest, would show the promise in the format, and leverage the skillsets of experienced MUD developers to capitalise on the potential. These titles in turn greatly influenced the design of modern MMO behemoths such as World of Warcraft and EVE Online (Bartle, 2010; Achterbosch, Pierce & Simmons, 2008). Each new evolution brought with it numerous variations on the themes – disparate genres were intermixed to great effect, bringing with them a synthesis of gaming conventions that were later remixed and endlessly revised such as in the ‘action adventure’ or MMO puzzle games such as the innovative Puzzle Pirates. Trace the family tree of any title back far enough though and you’ll likely find a text adventure somewhere near the roots (Lessard, 2013).

I argue then that the roots of the puzzle in video games can be found in the comparatively humble text adventure, and that there remain lessons we can learn and parallels we can draw regarding the way in which they have been incorporated in modern titles, and how they are likely to be used and abused in the future.

A Brief History of Text Game Puzzles

The earliest roots of the text adventure are, as all issues relating to the early days of video games, difficult to accurately unpick. Sterling work by independent scholars such as Chester Bollingbroke (known as the CRPG Addict), Matt Barton (and his remarkably fascinating Matt Chat video series available on Youtube) and Jimmy Maher (who runs the Digital Antiquarian website) have made much valuable historical information available but they are attempting to document an era where the historical record is not well maintained. The most famous early example of the parser based text game is arguably Will Crowther and Don Wood’s Adventure which dates from 1976 in its first incarnation. This particular title underwent many revisions where enthusiastic devotees would take the source code and provide their own additions, ports and bug-fixes. However, even earlier examples exist such as Gregory Yob’s Hunt the Wumpus BASIC program which received its first publication in the mid-seventies (Yob, 1975). This title used a text parser to create what is in its entirety a puzzle game based on navigating shapes of particular geometric configuration to hunt the eponymous Wumpus through interconnected rooms. Hunt the Wumpus incorporates explicit spatiality along with a text parser, but it is lacking almost entirely in narrative context within the game. It is a text game and a puzzle game, but not a text adventure as we traditionally understand them.

It is Adventure then which most accurately represents the creation of what we may think of as the text adventure, including as it does almost all of the elements that would become bedrocks of the genre. It includes a text parser; narrative outlines of location; room based spatiality; and an explicit scoring mechanic which provides a numerical index of how well you have done within the game. It also encompasses a rudimentary open parser, which distinguishes it from Hunt the Wumpus which implemented instead a closed parser. That is to say, a menu driven text input system which allows you to choose from a restricted set of options. In the case of Hunt the Wumpus, these were (M)ove, S(hoot) or (Q)uit.

Adventure, later known as Colossal Cave Adventure, and most of the text games that followed it used instead an open parser. This presented the player with a vocabulary of possible commands issued as verbs, along with the identifier of the item to which the command should be applied. Many of the earliest games, such as Adventure and the Scott Adams family of text adventures, used simple two-word open parsers (Montfort, 2004, p108), allowing for constructions such as ‘get sword’, ‘repair machine’ or ‘attack troll’. Later open parsers grew more complex, allowing for advanced constructions such as ‘get the second sword from the bag and then attack the troll with it’.

Colossal Cave Adventure was inspired by Crowther’s experiences with exploration of the Bedquilt region of the Mammoth Cave system in Kentucky (Montfort, 2004, p10) and as such it could have taken the form of a simple spatial exploration of an environment. However, its development incorporated fantastical elements such as magic and staple character archetypes from the contemporarily popular Dungeons & Dragons pen and paper games. The game is primarily about gathering treasures, and in its first instance contained fifteen items to be collected. It is in this collecting that we see the first text adventure game puzzles – best viewed through the lens of the walkthroughs of the period2.

Thus, the first true text adventure contained much of the structure that would become so important to the genre – the setting of a task to accomplish and the placing of obstacles between the player and the accomplishment of the task. Solving the puzzles involved a healthy  degree  of  lateral thinking and meticulous experimentation. They also sometimes involved the intensely frustrating experience of trying to find which game command would interact with the items and the environment in the right way to trigger progress. This particular design issue became known as the ‘hunt the syntax’ problem, and we will return to it later.

Colossal Cave Adventure directly inspired the game Dungeon, which itself was later renamed Zork in response to a trademark violation notice from Tactical Studies Rules, the publishers of the Dungeons & Dragons game (Anderson & Galley, 1985; Brewer, 2014). The word ‘Zork’ in itself was a bit of internal MIT slang, used when referencing to an unfinished program.  The first version of Zork was released in 1977 on the PDP-10 platform, and underwent the familiar lifecycle of authorised and unauthorised expansions and revisions as the source-code was shared and modified by fans.

Three of the original developers of the game would go on to be part of the team that founded Infocom in 1979 (Anderson & Galley, 1985), and the first commercial title released for home computer by Infocom was Zork. By then it had become so large and unwieldy that it had to be serialized into three titles released respectively in 1980, 1981 and 1982 – this in itself a natural consequence of converting the source code into something that would work within the limitations of a home computer. The first Zork game is a treasure hunt like Colossal Cave Adventure. The second incorporates the first stirring of a rudimentary plot. The third incorporates an over-arching motivation in which the player is adventuring to prove themselves worth of the title ‘Dungeon Master’. All three games incorporate the puzzle elements that defined their inspiration, although the complexity and subtlety of these was often enhanced considerably and obstacles began to include a certain degree of randomness that made the outcome of an interaction less deterministic. Consider for example the randomness troll battle that forms part of the challenge of the cellar, again as represented by a contemporary walkthrough3.

It was a variant Zork under the designation of DUNGEN that directly inspired the development of the first multiplayer text adventure, which was implemented by Roy Tubshaw at Essex University in 1978 (Bartle, 2003, p4-5). This was the first MUD which derives its name from  the fact it was  a ‘Multi User’ variant of the Dungeon style games, although in terms of content and design it was its own unique title. In 1980, Richard Bartle collaborated with Roy Tubshaw on the project, implementing many new locations and puzzles (Bartle, 2003, p5). When Tubshaw graduated from Essex University, the project was handed off to Bartle. In 1980, MUD (now known as MUD1 to differentiate it from later versions) became the first multiplayer online RPG to be made available to a general audience as Essex University connected to the ArpaNET (Bartle, 2003, p6). When it did, it inspired a whole generation of similar games over several decades (Bartle, 2010). The influence of Colossal Cave Adventure and Zork are easily ascertained in MUD, although here the terminology and style of game diverges considerably. Puzzles within the world of MUDs are usually known instead as ‘quests’, and their focus is on their use as a gameplay tool. Scoring of puzzle completion remains a common feature, but usually expressed as a separate category of ‘quest points’ rather than a single score which represents in-game progress. The puzzle design vocabulary between the two  families of games is and was widely shared, but the way in which they were integrated into the world was different. Early single player games revolved around the idea of progressing a story to  reach the end. Most puzzles then were easily identified and must be actively solved – in fact, puzzles were often used as a technique to slow down the speed at which players could complete a title to  ensure a sense of value for money. Within MUDs, a different tack is taken with many quests being hidden and passive, with the finding of the quest being as much a part of questing as actual completion. This requires a different set of expectations – that completion of the quest is optional, and not core to success within the game. This in turn has had the impact of making many MUD quests seem comparatively trivial in comparison to their single-player alternatives.

Those who played MUD1 and later created their own games according to a similar framework would find  this  regime  of  quest  provision  mirrored  in  many  games.    Discworld  MUD (1992-present) contains over two hundred quests, and very few of these are especially involved or core to progress. One for example involves buying an oil can from a general shop and using it to oil the hinges of the gates of the Assassin’s Guild. Another involves encountering a ‘sad man’ within the game and giving him a hug. This particular game, as may be obvious from the name, is based  on the popular Discworld series of books by Terry Pratchett, and this introduces another layer of potential obfuscation of quest provision – in this particular game many of the quests are inspired by sections of the books, and those who have not read the relevant book or internalised its various nuances may find that they are given few, if any, in-game hints as to the way a quest is to be identified or completed.

Within text games, the nature of the presentation and interaction creates a set of unique difficulties that other puzzles in other contexts do not exhibit. The first is that given the nature of an open parser, it may not be at all obvious what interaction is available when a player is in the vicinity of a particular item, or within a particular room. Such games may offer special, contextual commands (Heron, in prep) that are used only in particular locations and never used again and so each puzzle must be considered not in terms of a fixed, consistent interface but in terms of shifting, often incompatible, command forms. Most games allow for players to interrogate their surroundings by choosing to focus on descriptive or functional elements with commands such as ‘look at machine’. This will in turn present a description of the machine, which may contain subtle syntax hints through the use of specific verbs in the text. However, the task of identifying quests is further complicated by the fact that just because an unusual thing is present, it doesn’t necessarily mean there is a puzzle associated. Text games live or die by the quality of their writing and it’s necessary for text game developers to be generous in the text they provide. In other games, being able to look at a bud on the stem of a flower in a garden may imply that the bud is significant. This level of detail however  is a regular feature of the rich and detailed environments that define text games. In the early days of these titles, memory and storage considerations limited how expansive a world could be  because the text, even utilising the clever compression schemes of developers such as Infocom (Maher, 2012a) and Level 9 (Maher, 2012b), simply wouldn’t fit. Modern titles don’t have these limitations and thus it’s possible, and perceived to be desireable – such as the guidelines given to creators on Discworld MUD that they ‘must define every noun’ (Drakkos, N.D). All nouns within a description also have their own followup descriptions, and that each of these followup descriptions have each of their nouns described, and so until no undescribed nouns are left. While this depth can be impressive, it also makes it difficult to differentiate between text being presented because it’s relevant to a puzzle and that which is being presented purely for allowing the player to investigate their surroundings.

Particularly in environments where the existence of puzzles is kept secret (Karlsen, 2008), potentially anything can imply the existence of further interaction choice. An NPC standing in a street shouting ‘I NEED HELP’ is almost certainly a prompt that a quest is available, but what about a woman in a shop saying ‘I wish I could afford meat for my family’? That can easily be simple flavour text, or a prompt that giving her money in some fashion may actually be an in-game puzzle. Tronstad (2004) argues that this is best understood as a seduction, and when well-designed the thrill of discovery and teasing out of promise may meet that description. Day to day however, it tends to takes the form instead of an unwanted chore.

Players then are left with an unpalatable situation – to treat everything represented in the game as a potential puzzle, and then methodically explore all possible syntax formats on the off-chance that a quest is present. This is the ‘hunt the syntax’ problem, which in turn is exacerbated by the fact that the word chosen by a developer to represent an action may not match the most logical words chosen by the player.

This comes coupled with a need to obsessively read everything the game presents, because a quest cue may be found literally anywhere and with any degree of subtlety. Prominence in   presentation in text games does not imply prominence in game mechanics – for many developers, the more obscure a quest hint is the better, as being informed of a quest is regarded as a reward for having fully explored a game environment. Some games, identifying puzzle obscurity as a key usability defect, have incorporated extra-diegetic solutions such as ‘questsense’ or other out-of-character systems for indicating proximity to a quest (Drakkos, 2012) but these compensations remain rare because of the legacy of secrecy in puzzle design.

When a quest is found through these means and then completed without help the sense of satisfaction can be considerable (Tronstad, 2004).  However, more common are two other outcomes – wasted time searching for quests that don’t exist, or blithely walking past quests that do.  There are many more quests that could be but aren’t than real quests themselves. This is a problem in puzzle presentation that is rarely exhibited in other games where graphical representation of all interactive elements is mandatory, and the nature of the interface permits options for offering recognition based visual cues (Heron, in prep). It is difficult to truly obscure the existence of a quest in a graphical game – within a text game Chekhov’s gun4 is only relevant if we see the gun on the mantelpiece in the first place. All too often, the nuance of text fails to naturally reveal the existence of in-game puzzles unless external means are adopted.

This in turn tends to introduce an extra dose of ‘laterality’ in the thinking needed to accomplish a complex task – the strange conniptions required to solve many puzzles in interaction fiction are well known, with examples such as the Babelfish within Infocom’s Hitchhiker’s Guide to the Galaxy attaining almost legendary status (Simpson, 2005; Karhulahti, 2013). Given the flexibility of an open parser, almost any action can be attempted on almost any item within any environment. This flexibility in turn creates a mental expectation that sensible solutions will be possible. Generally though only the designer’s ‘correct’ solution will be ‘solve’ the quest and this may be difficult to find given the nature of the environment. Puzzles in text games, which are often compared to riddles in oral traditions (Montfort, 2003, p37-63; Tronstad, 2005) may have many sensible solutions, but usually only one that is correct. In the best case, the answer will be obvious in hindsight – that is however not always the case.

More frustratingly, the way in which commands are allocated to items and rooms creates the inconsistent situation where the specific object you’re using isn’t the one with the quest handling code. The example of the sad man in Discworld is relevant here – only one specific sad man can be hugged to give the quest, and there are many more ‘sad men’ in the city. In other situations, you may for example be expected to give a fishing net to a fisherman, but the net you give them isn’t the net that the quest itself recognises. Thus, a sensible solution is attempted, is rejected, and then the player re-evaluates other solutions until, often by luck, they find the specific net that works for that specific fisherman. Text game puzzles then often have many ‘hunting’ flaws – hunt the quest, hunt the syntax, and often hunt the specific.

Such issues are not unique to text games, with many ‘point and click’ adventure  games having similar issues. Autered games (Townsend and Heron, 2013) tend to suffer from these issues less freely. The kind of multi-developer, hobbyist environments in which MUD development particularly still thrives (Heron, in prep; Heron, in prep) however are fertile ground for these issues to grow.

Combine these issues with the early text game industry’s focus on puzzles as a way to artificially slow player progress and you have a recipe for some appallingly frustrating game experiences through both intentional design choices and the inelegant quest and puzzle tropes as discussed above. The focus on expressiveness of interaction via an open parser and relatively ‘sandbox’ game world was responsible for many heinous game design errors in early text games. One of the most common flaws was when solving a puzzle would lock off earlier parts of the game world. Those who did not fully acquire the necessary game items during their first few hours of playing would often find the game locked into an unwinnable state because future puzzles depended on the ownership of an item now inaccessible. Similarly, failing to complete a puzzle early on may lead to the reveal only at the end-game that you could not possibly win, and that all your save games were compromised because they contained the same unwinnable game state. Consider for example the Zardian Cruelty Scale discussed in Douglass (2007, p88) which discusses these and related issues.

Text game puzzles too may suffer from issues of representation – the written word offers opportunities that graphics cannot (Heron, 2013), but it also makes certain categories of information especially difficult to succinctly articulate. ASCII and ANSI protocols allow for surprising fidelity in terms of graphical representation, but the skills needed to create art using these systems are rare and becoming rarer. Even if the skill-sets are available with a development team, there are limitations as to what we can realistically ask of linear scrolling text. It is possible to create a grid- based display to represent puzzle state, as is done often in the game Epitaph Online but such state cannot be effectively represented if it changes independent of the player. A text based game of minesweeper is entirely feasible. A faithful text-based representation of Snake is not because the position of the snake changes whether or not the player interacts with the game. We can provide constant updates of snake position in the form of repeating, linear ASCII displays. Our eyes and information processing faculties do not cope as scrolling repetition with this as they would with incremental updates of a fixed display. Such displayed can be accomplished with text protocols (but the facilities are rarely in place within text game engines and often not supported in external tools that may be used to access them.

Part two and bibliography to follow.