Over the past few months, I've been converting my 1986 computer game Bestiary to run in a web browser. (The alpha version is now playable online here, with forum for comments here.) The conversion has made me think about how computer games have changed since the days of 8-bit machines like the Sinclair Spectrum, the BBC Model B, and the Amstrad CPC. Most obviously, today's games usually have stupendous graphics, professionally commissioned music and top-notch voice acting. These days, even "adventure" games such as Bestiary, which are more about narrative and intellectual challenges than rapid hand-eye coordination, usually conform to this model of high production values. (See for example the winners of the 2013 Adventure Gamer awards.)
But technical innovations aside - which not everyone sees as progress (text-only adventure games still have their devotees, though they tend to call them "interactive fiction") - there have also been changes to the basic rules of adventure games, to eliminate frustration which is not a necessary and intended part of the game's challenge. Games design, in other words, has moved on, to give players a better experience. And since I see an analogy between games design and learning design (both being about setting up an environment to create an experience for an unknown person or people whose actions you cannot control directly), at the same time as I've been bringing Bestiary into the world of 2014, I've been thinking what lessons each of these changes may have for the way we teach and how we can improve the experience of our learners.
No guessing
Text adventure games were the original virtual reality, following the model set in Crowther and Woods' 1975 Colossal Cave Adventure: text description of a location ("You are standing at the end of a road before a small brick building") and text input of commands ("Enter building", "Get lamp"). The player experience was one of exploring a virtual environment, encountering problems and challenges, and overcoming them by using objects found in the course of the adventure. (For example, a hostile snake blocking the path could be driven away by releasing a bird to attack it - but you had to catch the bird first.) [1]
When it worked, the text interface of adventure games worked beautifully and immersively, but there were two regular frustrations. The first was the experience of knowing exactly what you needed to do but being unable to find the right verbal command to make it happen. For example, lighting the lamp to pass through a dark corridor is easy enough (LIGHT LAMP), but if it started attracting unwanted creatures what command would you use to put it out? You might find that PUT OUT LAMP was interpreted as equivalent to PUT DOWN LAMP, because the parser could only deal with commands of the verb-noun form. You might wonder about OUT LAMP, which is hardly usual English outside of Macbeth, or EXTINGUISH LAMP, which isn't usual either though at least not odd, or perhaps DOWSE LAMP, although you'd probably need a source of water for that to work. Imagine trying and failing with all of those, and then finding that what you were supposed to type was LAMP OFF: your next utterance (outside the game) might well be a different two-word phrase ending in OFF.
Text commands in CP/M and DOS - which you needed to operate computers before the mid-1980s - brought the same frustration of knowing what you wanted to do but being unable to find the right words to bring it about. After the Apple Macintosh introduced ordinary computer users to mouse-based operation, game designers started producing graphical adventure games with point-and-click interfaces; for example, The Secret of Monkey Island (1990) had the player select their command verbs from a menu and then click on the appropriate object or location in an animated scene. Later games such as Broken Sword (1996) and The Longest Journey (1999) did away with the need for command verbs totally, by having the pointer's effect changing according to context, or by providing a right-click menu for the player to choose an action on a selected object. Such point-and-click interfaces make it easier for the player to communicate their desired actions to the game, eliminating the need to guess command words.
Graphical interfaces also removed the second frustration of text adventure games: the lack of distinction between scenery (which you can only look at) and objects (with which you can actually do something). In the original Colossal Cave Adventure, for example, one of the locations had a long piece of text describing a spectacular view of a volcano, which mentions lava, rocks, glare, ash and brimstone in the air, alabaster formations in the cave roof overhead, rocks in a gorge, a bottomless pit, a geyser of blistering steam, a barren island in the middle of a sulphurous lake, and an incandescent wall.[2] However, all these things were just scenery to be admired; if you tried to do something with any of them, even examine them, you just got the default responses YOU SEE NOTHING SPECIAL or YOU CAN'T DO THAT. The authors clearly wanted to give the player has a sense of immersion in the virtual environment, but at the same time could not program responses for every possible interaction with everything in it. The general problem with text adventures is that the longer and more detailed the descriptions, the greater the risk of players becoming frustrated by trying and failing to do things with the scenery.
A graphical interface allows an escape from this dilemma: the scenery can be as detailed as the designer wishes, but as long as an actionable object is signalled by a change in the mouse pointer (typically, a magnifying glass for something you can examine, a hand for something you can pick up, a speech bubble for someone to whom you can talk) you need never be in any doubt as to which objects are actionable. Without being unfair to the player, the game designer can hide a tiny object on a cluttered workbench, or have a new object become findable in a place you've already searched - especially if, as in many contemporary games, you can toggle on a view which highlights objects that are actionable.
What are the lessons for learning design? That learners should never be in a position where they have to guess what to do with our learning materials; we should always provide them with enough signs and cues to make it obvious what it's possible to do and how they can do it if they wish. Too often we are lazy in our labelling and information architecture; in my own university, for example, we are only just starting to eliminate from our teaching websites the many unclear and unhelpful labels, such as "Module resources" (surely everything on a module website is a module resource?), "Module materials" (how is this different from "Module resources"?), or "Useful resources" (does this mean that the others aren't useful?). Too often as teachers we burden learners with too much information and too many links, making no differentiation between what's essential, what we recommend, what's optional, and what's there simply for credibility or atmosphere rather than actual use, such as references, copyright acknowledgements, and legal notices. Learners have enough of a challenge with the subject matter of their learning; they do not need any additional challenge in trying to find a resource because they don't know what we've called it, nor should they have to guess how to do meaningful work with a resource which we've put in front of them.
No lockouts (no blind alleys)
Going down blind alleys and having to retrace your steps is a necessary part of exploration, whether in an adventure game or in a learning environment. However, in classic text adventure games, it was quite possible to go down a blind alley which would effectively lock you out of all further progress. For example, in Sphinx, at one point you would fall down a deep hole, out of which you could not climb, but which contained a car jack. When I played the game I wasted a lot of time trying to use the jack to get out of the hole - reasonably enough, I thought, since a jack is a device for elevation. It was only after I'd given up the game in disgust that I learned that getting out of the hole requires another object, which you need to have already picked up before you fall down the hole (which you need to do to get the jack, because the jack is needed elsewhere in the game). My own game Bestiary requires the player to cross an ocean and return, which they can do either by boat (but they're shipwrecked, so they can't use the boat for the return trip) or by using a magic talisman which transports them through the air (but it falls from their hand as they fly, so again it's a single-use object). In the original version, if you used the talisman to cross the ocean for the outward trip, or if you sailed over in your boat without having first obtained the talisman, you would be stuck on the distant continent with no means of return.
Designers of the early adventure games (including me) thought lockouts were acceptable, because we counted them as part of the challenge: you not only had to do the right things to complete the game, you had to do them in the right order. We assumed that players would be willing to replay the game until they got it right and also that they would save their position regularly, making it relatively simple for them to return to a state of the game prior to their bad move. But we underestimated the frustration caused by lockouts and players' sense of being punished for something which was no fault of their own and which they could not have anticipated. These days, as a matter of course, games avoid lockouts: they're designed so that it's impossible for the player to leave an area irrevocably without having collected all the objects and spoken to all the people they'll need to advance the narrative and complete the game. My ocean-crossing puzzle in Bestiary would be unacceptable to players today, so when I converted it for the web I modified the game so that it's now impossible for the player to cross the ocean in the wrong way.
What are the lessons for learning design? That we should not allow or encourage learners to get into a situation where they find that they’ve gone a long way down a blind alley and have to throw their work away. True lockouts are rare in education, except perhaps in badly-designed qualifications where innocuous-seeming module choices can rule out the pathway a student later wants to take; but we still often create situations in which it’s possible for students to waste precious time and effort in ways which could have been avoided. For example, we present students with long and crabbedly-written guidance documents, which they have to read practically to the end to find out that it’s not relevant to their situation and that they didn't need to read it at all; or we ask students to work with a case example from their own experience but provide them with no way of telling whether their chosen example is going to be suitable for the tasks ahead of them except by actually doing those tasks. We need to provide learners with quick feedback on their study choices: confirmation that they’re on the right road or warning if they’re going wrong or have failed to do something essential. Saying that learners can learn from the experience of a dead end is like saying that a lockout in a game is just another challenge, and we shouldn’t allow ourselves that excuse. If we don’t respect the value of learners’ time and effort, we can expect them to feel badly treated.
No death
In old-style adventure games, death could come suddenly and without warning: if you tried to move in a dark location without a source of light, if you did the wrong thing with a dangerous object, if you angered a violent character by choosing a bad option in a dialogue tree. Death was often a necessary part of the game; there might be no way of discovering the dangers in the game world other than by running into them and dying. The assumption was that a player could reload a saved game to return to a point before they encountered the danger and either avoid it or try to deal with it in a different way. Some games even included an OOPS command, which like the Cmnd-Z or Ctrl-Z keystroke today had the effect of undoing your last fatal move; other games automatically saved your progress at key points in case you forgot to do so for yourself.
Despite such efforts to make death palatable by minimising its inconvenience, there has been a great deal less of it in adventure games since the late 1990s. I think this has been a result of adventure games becoming more focused on narrative, rather than just exploration of a virtual world: forcing the player to go back to an earlier stage in the game breaks their sense of an on-going storyline. Those games which do include the possibility of player-character death, such as the Broken Sword games or Cognition, are normally ones which include a thriller element, so it's a requirement of the plot that there should be moments of tension when the character is in some kind of jeopardy. Other games create danger and tension without actually allowing the player character to die; for example, in The Longest Journey, there are two points where April Ryan is threatened by some kind of monster, but in both cases she cannot actually die: the monster simply chases her around the room (while tense music plays on the soundtrack) until the player works out the move she needs to make to escape. But on the whole the absence of death has become so much of a norm that The Book of Unwritten Tales (2011) includes the character of Death sitting gloomily unemployed on a derelict boat because no one ever dies in adventure games anymore.
What are the lessons for learning design? That we should not underestimate the impact of failure on learners, and not create situations in which there’s a good chance that they will fail totally and irrevocably. We cannot, and should not, remove the risk of failure entirely, because experimentation and therefore risk-taking are a necessary part of learning and growth; but we can and should make sure that learners have every chance to avoid disaster. We can provide them with warnings, we can provide them with opportunities to try again and learn from their mistakes, and we can provide them with the possibility of failing in small ways, so that they can learn not to fear mistakes and find that recovery is possible.
In learning design, just as in games design, what we are striving for is that the learner / player should always be able to continue learning / playing, without the burden of an unintuitive interface or the fear of lockout or death. Game on, as they say.
Postscript
Since writing this post, I've had confirmation from an unexpected quarter of my view that text commands interpreted by a parser present irredeemable usability difficulties for adventure games. Emily Short is probably the leading figure in the UK community for authors of interactive fiction (IF), which is what they themselves call text adventures. And yet she writes:
“I can tell you why I write a lot less parser IF (as a proportion of my overall output) than I used to: accessibility. I’ve put a lot of effort over the years to making parser games that would be friendlier and more inviting. I’ve spent many many hours watching people play them, and reading responses from novice players, and showing off IF in classrooms and at conferences. I’ve experimented with different UI approaches, with adding graphical feedback, with buttons and menus and status windows. A good proportion of my messing around never saw the light of day because it was self-evidently ugly or inadequate. And I’ve finally, about fifteen years on, accepted that there is nothing I know how to do that will make a parser-based game a sufficiently inviting prospect for the majority of players. Tutorial text, external help materials, more synonyms, better error messages, attempts to highlight key nouns and list key verbs for the player — you can spend hundreds of hours on those sorts of helps and still not manage to make a parser-based game that is as immediately comprehensible as a choice-based game is by default.”
References
[1] The history of adventure games is told in (1) the film Get Lamp, which features interviews with many of the game creators (watch it here, the film starts at 7'30", ends at 1:38:12; (2) a Wikipedia article; (3) a series of videos starting here; (4) a web article here.
[2] The complete text of the original Colossal Cave Adventure is here.
