Katharine Whitehorn’s Cooking in a Bedsitter: an appreciation

(Copied from my original post 15.2.2021 on the electricwordcraft.com site.)

When I went off to uni in 1977, Cooking in a Bedsitter was one of the books I took with me, and it got a great deal more use than any of my textbooks. Although Katharine Whitehorn had written it for a different generation of young people (it was first published in 1961), the material conditions of life had not changed so very much; if your student room was in a moden block you might be lucky enough to have a shared kitchen, but if you were in an old university building or living out in digs, the best you could hope for was a single gas or electric cooking ring in your room, and no fridge. There were no take-aways other than fish and chips; pizza was still regarded as foreign food and McDonalds had yet to achieve a serious presence on the high street. Chilled ready-meals were many years in the future. So if you wanted to cook for yourself, the challenges were enormous – and it was those that Katherine Whitehorn addressed. Cooking in a Bedsitter was not a book of recipes; it was a lifestyle book, shot through with her trademark down-to-earth simplicity and straightforward common sense.

It was that punchy pragmatic tone which characterised her Observer column. Take for instance her observation (early ’60s, remember) that a woman at a party needs to hold a bag, gloves, plate, drink, serviette, fork and cigarette – AND have a hand free for shaking hands. Having identified the problem, she then worked out the answer, and a photograph of her doing it appeared on the cover of her Social Survival (1968). (Bag goes on the arm, gloves between fifth and fourth fingers, serviette between fourth and third, cigarette between third and second. Hold the plate with first finger and thumb, with the thumb holding down the wineglass and the fork resting on the plate. Your other hand is free for eating, drinking, smoking and shaking.)

In the same vein, Whitehorn’s opening chapter of Cooking in a Bedsitter defined “The problem – and some of the answers”.

Cooking a decent meal in a bedsitter is not just a matter of finding something that can be cooked over a single gas ring. It is a problem of finding somewhere to put down the fork while you take the lid off the saucepan, and then finding somewhere else to put the lid. It is finding a place to keep the butter where it will not get mixed up with your razor or your hairpins. It is having your hands covered with flour, and a pot boiling over on to your landlady’s carpet, and no water to mop up any of it nearer than the bathroom at the other end of the landing. It is cooking at floor level, in a hurry, with nowhere to put the salad but the washing-up bowl, which is any case is full of socks. (p. 13)

My copy of the book had one of Penguin’s great new photographic covers of the 1970s, which “allowed the title to be ‘read’ instantly from the image alone” (Baines, 2005, p. 205). In this case the image was of a cast iron bed frame, hung with cooking utensils and food items (see above). Arresting and funny, this was an illustration of the same problem: that the place where you cook is also the place where you sleep.

Whitehorn’s answers to this problem included casseroles (“far the best way of cooking a number of different things together, as one must on a gas ring” p. 16); a damp cloth (for wiping), a water jug (for adding water during cooking) and a plastic bucket (for emptying dregs); newspaper (as a work surface and wrapper for rubbish); and equipment (“it is not a question of the best possible tools, but the fewest” pp. 20-21). All these she covered in her magisterial first chapter, followed by a supremely useful “beginner’s index” of ingredients, including “how much to buy, how to prepare, standard cooking times” (p. 27). The recipes, although they occupied the remainder of the book, were in a sense secondary; fundamentally this was a book on how to approach and think about cooking – which is why its popularity endured, even as ingredient availability expanded and food tastes changed.

Here are some of Whitehorn’s best insights, which have shaped my cooking from that day to this.

• “Cooking to stay alive.” Most of the recipes in the book fall into this category, the other being “Cooking to impress”, for which there are special tips. “(1) Finish any cleaning. You can finish cooking without shame in front of your visitors, but you cannot very well sweep under their embarrassed feet. (2) Set the table – it will reassure people that they have come on the right day, and that there will be a meal eventually. (3) Get yourself looking nice. In a house you can disappear and finish dressing – in a bedsitter, no.” (p. 145) And for the cooking itself: “Never have more than one thing that needs last-minute attention.” (p. 144) Further guidance is divided according to the category of person you are trying to impress: “(1) The troglodyte in the next bedsitter. (2) Couples … who … have forgotten what it was like to cook in a bedsitter (if they ever knew), and it is your business not to remind them. (3) Your parents, or your parents’ spies… (4) Delicious little parties à deux.” (p. 147)
• “The potato-shaped space.” “Most of us have a potato-shaped space inside that must be filled at every meal, if not by potatoes, then by something equally filling – rice, bread, spaghetti, macaroni, and so on.”(p. 16)
• On drink and parties (by her husband, Gavin Lyall). “It is a bad rule to buy the cheapest of anything, and a good rule, when faced with the temptation, to buy the best of something cheaper…. The happy fact is that nobody will know you thought of giving them champagne anyway.” (p. 175)

And here, as a specimen of how all this works out in practice, is one of my most-used recipes from the “Cooking to stay alive” section: Leeks Lucullus.

3 leeks (about 1lb)
2 or 3 potatoes
1 tablespoon grated cheese
butter
top of the milk
salt, pepper

Boil leeks and potatoes together in salted water with lid on pan till tender – 15-20 mins. Pour off liquid. Mash leeks and potatoes with a fork; stir in as much butter as you can spare (at least a teaspoon), cheese, creamy milk. Eat with a piece of toast. If you have a grill, sprinkle more cheese and brown the top. This looks like pale green mashed potatoes, but tastes delicious. (25 mins.) (p. 65)

Rest in peace, Katherine Whitehorn. Thank you for teaching me how to think about cooking, how to think about life, and that it’s possible to be smart, practical and funny all at the same time.

References

Baines, Phil (2005), Penguin by Design: A Cover Story 1935-2005 (London: Allen Lane).

Whitehorn, Katharine (1963), Cooking in a Bedsitter (Harmondsworth: Penguin)

See also Obituary of Katherine Whitehorn by Janet Watts and ‘Thank you, Katharine Whitehorn, for giving all the female reprobates a voice’ by Barbara Ellen.

Confessions of a teenage 903 user

(The original version of this reminiscence was written for the Centre for Computing History, which occasionally runs demonstrations of its working Elliott 903.)

In 1972, for a school to have a computer was something extraordinary. Computers then were huge and expensive things, owned mainly by universities, large corporate businesses and banks, such as The National Girobank whose TV advertisements made a big deal of the fact that it used a computer to manage its customers’ accounts. So imagine my excitement on starting secondary school that year to discover that we had a computer. And that excitement was undimmed by my first sight of the Elliott 903: a modest metal box the size of a desk, with a few smaller boxes standing on it and a teleprinter to one side. This was a long way short of the rooms full of steel cabinets with chattering line printers and whirring magnetic tape drives which I had been expecting. It was even further short of the talking and intelligent computers we knew from ‘Star Trek’ and ‘2001: A Space Odyssey’. But still, it was a real and actual computer, and that meant that it could be programmed to do things. The only question was how.

Fortunately I was friends with the top mathematician in my year, who had already been using the computer for some time, and he showed me how to write my first program in FORTRAN. Other pupils showed me how to use the Teletype in the outer computer room to type out my program onto punched paper tape, which was the 903’s medium for high-speed data input (high speed here meaning 250 characters per second). Making paper tapes was itself pretty exciting: each keystroke produced a row of up to eight holes representing a character in ASCII, with a complete set of holes being a null character to be ignored, enabling you to correct typing errors. (Backspacing the tape and typing Delete punched out any holes already there). Printing out the text encoded in a tape, and realising that we could use it for sending private messages, was also exciting. But of course the main thing was to get access to the 903 and to run a program.

So I went to see the teacher in charge of the computer, who solemnly signed a card authorising me to use it for up to an hour per week. (One hour! And kids today complain about limits on their screen time!) However, I was still a long way from getting my program to run. The computer wasn’t large enough to interpret high-level FORTAN programs directly; what I had to do was to load and run the FORTRAN compiler, one of the massive rolls of paper tape hanging from a pegboard beside the computer, and get it to read in my program and convert it to machine code. It took many efforts before it would do that successfully, because it kept finding syntax errors in my FORTRAN, which I had to find and correct and then remake my tape. Only when I had no syntax errors would it produce a new lot of paper tape containing my program in machine code, which I could load and run in its turn. I can’t now recall what my first program did, but I suspect it was something worthy but dull, probably solving quadratic equations using the standard formula. Whatever it was, certainly it was unmemorable and hardly worth all that effort.

You see there was what we were supposed to do with the computer and there was what we actually did with the computer, and these were two very different things. Our maths curriculum, devised by the School Mathematics Project or SMP, included computer programming, breaking calculations down into simple steps and using a made-up programming language called SMPOL to perform basic arithmetic operations on numbers in registers. The SMP textbooks featured an imaginary computer called Simon (SMPOL Simon, geddit?), but so that we could use our actual computer the maths teachers wrote a SMPOL compiler. We did try programming in SMPOL, but it was dreadful: painfully slow and deeply dull in its limited operations. Even the school’s administrative applications were more interesting: from time to time the computer was used for working out exam timetables, which was fun because it produced desk labels for each exam venue with pupils’ names spelled out on punched paper tape, and also for processing the marks from the scholarship entrance exams – which became exciting when one of my friends found paper tape containing the confidential raw marks in a waste paper bin. (He now works in data security!) We weren’t going to be limited to the curriculum; we took our inspiration from the very camp, very brilliant maths teacher who had first set up the 903 for the school and had actually been a pioneer computer scientist in the post-war years. Think about it: we were reasonably bright teenage pupils, and we had access to a computer. What do you suppose we did with it?

Of course, we wrote games. The tone was set by one of my friends, who wrote a program called Dork: the computer asked you quiz questions and called you a dork if you got the answer wrong. Not exactly Fortnite, but we thought it was funny. I followed this up with a program to write random sentences, picking words at random from a deliberately surreal vocabulary list to fit one of a number of grammatical forms: “the zombizical policeman urgently requires the fried egg” was a typical result. Then I wrote a game called Bath, which was a silly variant on one of the few games in the school’s program library. The original version was a (very simple) simulation of a moon landing; you had to set the level of thrust so as to land softly, but if you slowed too early in your descent you would run out of fuel and crash. In my version, you had to set the flow rate of hot and cold water to run a bath of a specified depth and temperature; I made it still more silly by having this be a giant’s bathtub, so the depth was measured in feet rather than inches, and there were appropriate in-game messages (“Fee, fi, fo, fum… (splash)”).

Between us, we also tried writing a game called Animal, of which we’d heard: the computer tries to guess the animal you’re thinking of by asking yes-or-no questions, such as “Can it fly?” The computer obviously has a limited number of questions and the trick is to get it to expand its capability by asking you for more information if you think of an animal it doesn’t already know. We never got that game working properly; I’m fairly sure the logic was flawed. We had more success with a program to play the colour pattern guessing game Mastermind, which was very popular at that time. To get the computer to guess your colour pattern as quickly as possible was a good challenge: the clever bit was to have it work out what guess would give it the most information. (The best first move, by the way, assuming the target pattern is chosen at random, is two pegs of one colour plus two pegs of another colour.) For the other half of the game, in which you try to guess the computer’s pattern, we sneakily made the computer cheat: as you made your guesses, it would change its target pattern so that its answer, while consistent with the answers it had given previously, would give you the least possible information to keep you guessing as long as possible.

By this time, the school had given up on trying to regulate our time using the computer. (The start and finish times we entered in the computer room Day Book were complete fiction anyway; we called it “fudging time”.) We had also given up on high-level languages such as FORTRAN and ALGOL; the compiled code was inefficient, and given the slow speed of the processor we needed all the efficiency we could get. Instead, we ended up programming exclusively in the 903’s assembler language, called Symbolic Input Routine, or SIR, which gave us the efficiency of working at the level of machine code and its 16 basic operations, but with the advantages of defined variable names which made our code comprehensible. So although we got some of our games ideas from the helpful American book 101 BASIC Computer Games, we recreated them all in SIR – partly because we didn’t have a BASIC compiler, but mainly for reasons of speed. Even using SIR, our efforts to get the computer playing draughts, let alone chess, were ultimately frustrated by the length of time the computer took to produce a move – 30 minutes or more, in the case of our chess program. Being inexperienced in systematic testing and debugging, we did not know how to deal with the long cycle time for seeing a problem, identifying its cause and making a change, so we never got these programs working properly. This did not, however, prevent us from mounting displays about them at the exhibitions of the computer room which we started putting on for school open days.

Our computer room exhibitions also featured some more serious mathematical work, given a fun visual twist. My friend the top mathematician, having read that the highest known prime number (at that time) was 2 to the power of 11213 minus 1, set out to calculate and print out that number. Of course this was more complicated than simply instructing the computer to multiply 2 by itself repeatedly; after only a few iterations the number would have been too big for the computer’s usual way of representing numbers, so he had to write a subroutine for handling numbers with very many digits. When printed out, the number took up a very long piece of paper (the teleprinter used continuous rolls), equivalent to three or four sheets of A4. Of course, we had no way of knowing whether the calculation was correct or not, so adapting a song from a much-played album of the time we used to sing:

(To the tune of ‘(Jesus Christ) Superstar’)
Powers of 2, superstar!
Do you think you’re what we say you are?

My mathematician friend also wrote a routine for plotting graphs on the teleprinter – the only kind of output we had in those pre-screen days – by printing Xs on the paper. A spectacular application of this was his graphing of a step function as a Fourier synthesis – in other words, representing it as a combination of sine waves, using more and more sine waves to get closer and closer to the square wave’s cliff edge shape. He scaled the graph so that the top part of the step was on one sheet of paper, which we mounted near the ceiling, with the straight line increasing fluctuating as it approached the cliff edge, eventually plunging downwards towards a second sheet of paper near the floor, where the bottom part of the wave continued. It was a great display; we showed how maths was fun.

What else did we show in our computer room exhibitions? Two programs from the school’s library made use of the computer’s sound generator. One tested your reaction time: after a random interval, the tone would change and you had to press a button as quickly as possible, and the computer would output on punched paper tape the time you took. The other used the sound generator to play tunes; for the exhibitions I programmed it to play Scott Joplin’s ‘The Entertainer’, which was very popular at that time because of its use in the film The Sting. We also had a program, written by our computer scientist maths teacher, to produce labels in punched tape by punching hole patterns in the shape of letters; I wrote an extended version which could also produce lower case letters and small caps, and also Greek letters for good measure.


Visually, the most striking thing we produced was a poster-sized pin-up of Joanna Lumley in her first famous role as Purdey in The New Avengers, rendered as teleprinter art. We had several examples of teleprinter art in our library, in which a picture was formed by characters of different densities printed from paper tape, greater degrees of darkness achieved through overprinting or double-overprinting; but most of these, and certainly the much-reproduced picture of Winston Churchill, had been produced by some kind of optical scanning to create the subtle shading. I produced my picture of Purdey manually, by tracing the magazine image, ruling a grid over it, and assigning a number representing one of four levels of darkness to each cell, then using a program to take this data and print the corresponding character combinations.

But the star attractions at the computer room exhibition in our final year at school was our implementation of the Star Trek resource management game SPACWR (don’t you just love six-character variable names?) which we adapted from 101 Basic Computer Games. The basic idea is that you command the USS Enterprise, engaging enemy ships in battle, the sector of space around you represented on an ASCII plot with your own ship represented by <*>, the enemy ships by +++, and stars by *. Phasers generally lock on target automatically, but cost you energy; photon torpedoes need to be aimed by setting a directional angle. You can replenish energy and weapons at starbases, represented by >!<, which you can locate with long-range sensors. I think pretty much every large computer installation in the Western world must have had a version of this game, but the beautiful thing about our implementation was that it was genuinely collaborative: one person wrote the shell, and the rest of us wrote various subroutines. I made two contributions: the first was to give the enemies a random name, phonemes being selected from a range biased towards hard and aggressive-sounding consonants, on the model of “Klingon”. (Some of the results were satisfactory, such as “Groshtak”, but others were just silly, such as “Bungon” or “Plibdad”.) My other contribution was to give the enemies a secret weapon, named from a buzzword generator which made a random choice from three sets of impressive words, giving for example “inter-phasing neutronic de-energiser”). One of the junior pupils, who we were treating as a coding apprentice, contributed a self-destruct function: if the final few enemy ships were in the same sector as yourself, you could activate your self-destruct and all the ships would be replaced by stars.

The other good thing about our implementation of this game was that we wrote it for a proper computer screen, the school at last having agreed to supplement the 903 with a visual display unit. This meant that instead of having to print out successive versions of the changing game map on the teleprinter, it could be displayed on screen and constantly refreshed. For the computer room exhibition, it also meant that we could demonstrate the game to a larger audience by connecting the VDU to an old television set in the outer room. I vividly remember, in the quieter period towards the end of the afternoon, sitting in the outer room with a couple of elderly ladies, as they watched the game in fascination, keeping up a running commentary on its progress. It was one of my happiest memories of the computer room.

Looking back at it all now, part of me regrets the things we didn’t do. We didn’t, for example, invent the text adventure, which would have been perfectly possible with the technology; Will Crowther and Don Woods developed the original Colossal Cave Adventure in 1976-77 (using FORTRAN!), though given the limited memory of the 903 we might only have managed a Very Small Cave Adventure. We didn’t write an implementation of Dungeons and Dragons, whose rules were first published by TSR in 1974 but which didn’t become well-known in the UK till a few years later; however, two of my friends did write a role-playing game called Rule the World, in which you managed money and armies to increase your political control over country after country. (I don’t know what they’re doing now, but it’s quite possible that they’re at the top of one of the international companies or financial institutions which really do rule the world.) And we didn’t have the greater speed and memory of microprocessors, which would change the world of computing completely. It was while stopping at a motorway service station during a post-A-levels school trip in the hot summer of 1976 that we saw and played our first micro-powered arcade machines – the tank battle, the dogfight and the cowboy gunfight; it was a glimpse of the future, and we were blown away.

But much more than that, I’m glad for what we did do and grateful that we had the chance to do it: grateful to the benefactor whose bequest enabled the school to buy the computer, grateful to the teachers who inspired us and then left us to get on with it, grateful to my friends with whom I learned and laughed. I’m grateful that I learned to operate computers in an era when you could appreciate the physicality of the technology: an era when you acquired the reflex of touching a radiator before handling the machine to avoid disrupting it with a static shock, when you patched the tape reader with small pieces of Sellotape to overcome its mechanical shortcomings. I’m grateful that I became a “digital native” decades before the concept was coined, and so was unthreatened by the idea that a younger generation might have a computer-facility that I lacked. But above all, I’m grateful that I learned to treat computers with familiarity, instead of with awe and reverence, or fear and terror, as did most people at the time. When I saw the film Alien in 1980, I was astonished to see Sigourney Weaver operating her computer while drinking coffee and resting a foot on the console; never before had a computer in a science fiction film been treated so casually, as literally part of the furniture. That, I had learned, was the proper attitude to take to computers. They were there; sometimes they worked, often they didn’t, and you just had to get along with them. That attitude has served me well in later life.

Interactive narrative: Lessons from Telltale

Back in the 1990s, when the potential of interactive audio-visual media was first brought to the general population through affordable personal computers coupled with the extended storage capacity of CD-ROMs, technology commentators speculated wildly about the impact this would have on the creative arts. What would happen if you had a truly interactive novel, in which not just the reading experience but the actual storyline was shaped by the reader as well as the writer? Or a drama, in which you could, say, take on the role of Hamlet and choose to avenge your father’s death in the first Act instead of dithering around until Act III? Was the whole concept of a linear narrative with exposition and conclusion itself dead? Star Trek: The Next Generation provided a convenient cultural reference: the TV show's 1987 opening episode realised the concept of “virtual reality” through a room on the starship in which computer-generated holograms and force fields could simulate both a physical environment and people in it. The crew used this “holodeck” not only for training but for recreation; Captain Picard enjoyed role-playing Dixon Hill, a private eye from a 1940s-style crime thriller, and Captain Janeaway took on the role of the governess in a Jane Eyre-like gothic “holonovel”[1]. The optimism about digital technology’s potential for interactive narrative was summarised in Janet Murray’s Hamlet on the Holodeck (1998) [2].

"Basically, I am assuming that this movement is analogous to the invention of the movie camera a hundred years ago, and asking: if the digital environment (multimedia, networked, desktop, VR, arcade, etc.) is the 'camera,' then what will be the equivalent of the 'movie'? The holodeck provides one provocative model."
(Interview with Michelle Ellen Green)

Ten years later, this confidence had largely collapsed, not merely because virtual reality was proving to be technically a more clunky affair then early enthusiasts had hoped, but because authors were finding it just too hard to write truly interactive narrative scenarios that anybody would actually want to play. They discovered what the writers of adventure games had known for some time: that you need to anticipate and provide for anything the player may decide to do – hard enough when dealing with physical objects, but mind-bogglingly complex when dealing with non-player characters and narrative storylines. If players are going to be able to take the story in any direction they want, then you can’t write something as dramatic as Hamlet, because if the player kills Claudius in Act I then the story either has to end there or else you need to have provided additional material to allow it to go somewhere else. Even if you limit the number of choices the player has at each stage, as long as each branch leads to further choices then the tree of potential storylines quickly grows to an impossibly large size. If you try to write discrete scenes which players can encounter in any order, then you never know what they’ve seen previously, which means that every scene needs to do its own exposition. limiting how far it can develop the story. Taken together, these problems meant that interactive narratives tended towards the bland and purposeless, with largely meaningless choices about which it was difficult for players to feel much investment.[3] The few interactive narratives which are generally reckoned to have succeeded (for example, Façade, Her Story [4]) operated within a very restricted setting; the remainder never got beyond the stage of experimental works and sunk into obscurity.

This is why it’s extraordinary that Telltale Games has become successful, both commercially and artistically, in producing interactive narratives. As Dan Connors the co- founder of Telltale has commented: “We just chose the four things that people had given up on: digital distribution, episodic gaming, licensed gaming, interactive narrative, and said: You know what, it CAN be done, and we're going to do it." (Documentary ‘Telltale Games: Story Mode’, quote at 0’32”.) Ignoring modernist ideas of non-linear narratives, they’ve focussed unapologetically on good old-fashioned story-telling. Their characters and settings are strong and dynamic, drawing on the proven dramatic possibilities of pre-existing media franchises: Back to the Future, Jurassic Park, The Walking Dead (their breakthrough title), Game of Thrones, The Wolf Among Us (based on a comic series), and Tales from the Borderlands (based on the Borderlands role-playing game). The storylines are exciting, with suspense and resolution and a dramatic ending to each episode – essential for motivating players to buy and download the next. And (it should go without saying) their writers, animators, voice artists and music composers are first-rate, all combining their efforts in the service of the story.

But what about the interactive element? How is playing a Telltale game different from watching an animated film? The first thing to be said is that their interactivity is quite limited.[4] Although as a player you have choices, some of which seem as though they have decisive significance, you cannot actually affect the overall storyline; even when it seems you have freedom of movement, you are in fact travelling on rails. But the second thing to be said is that the interactivity which the games do afford is precisely that which enriches and deepens your involvement with the story. In other words, rather than trying to provide for whatever the player might try to do – which would be impossible – Telltale have focused on providing what is most important in terms of its impact for the player.

Here’s how it works in Tales from the Borderlands. You alternate between two characters: Rhys, a middle-ranking executive in the cut-throat Hyperion corporation, who descends to the wild-west planet Pandora in a desperate attempt to reverse a career disaster, and Fiona, a Pandoran con-artist whose ambitious scam goes wrong and is driven into an uncomfortable alliance with Rhys in the hope of winning even greater loot. The thrilling storyline has many moments of tension and danger for your characters, and one of the ways the game increases the suspense is by introducing uncertainty through dialogue choices. An early example of this is when as Rhys you have to ask the way from a violent-looking gang of bandits while your friend Vaughn is very obviously carrying a briefcase of money chained to his wrist; as Fiona, your first challenge comes when you need to talk your way past a huge bar-room bouncer, while a Wanted poster with your face on it is prominently on the wall beside him. From the point of view of the storyline, your dialogue choices make no difference; no matter what you say as Rhys, a fight will break out, and even if you completely mess up your lines as Fiona your sister Sasha will rescue you and get you into the bar. But what the choices do is make you identify with your characters: like them, you are forced to make a decision about what to say in a difficult situation which could turn nasty at any instant.

Other sequences get you to share your characters’ uncertainty and confusion by making you search for the way to advance the story. When Fiona returns to the home of her friend and mentor Felix, she is looking for something which will explain his recent actions, and what she finds is a sequence of clues which lead her to a hidden message which he left for her. When Rhys arrives at the concealed Atlas base, he has to find where it is and how to get in by tracing power cables. In such sequences, as in a conventional point-and-click adventure game, you can move your character freely around the immediate environment, examining and using any objects which he or she finds there. For a few minutes at least the tension of the story relaxes, and like your character you experience a period of quiet uncertainty while you hunt around to find something which will help you move on and get closer to your goal.

But it is never long before the pace picks up again and you find your character in immediate lethal danger. In such situations, the game requires you to react quickly. When a bandit is swinging an axe at Rhys, an arrow appears on the screen and you have to swipe in that direction to make him dodge; when Fiona is struggling to close a door before a gunman takes a shot at her, you have to tap the screen repeatedly until a progress bar is full; at other times, targets appear on objects which you need to tap quickly in order to hit them, throw something at them, or jump onto them. If you fail to do so within the time limit, your character dies. The skill challenges are not difficult, and the penalty for failure is not harsh – you simply go back to just before your death so that you can try again – but the need for constant alertness increases the tension and emotion, and the sense that you are protecting your character’s life deepens your investment in them.

Less obviously but more interestingly, the dialogue choices build your involvement with the playable characters by allowing you to fine-tune their personalities and relationships so that they feel realistic and convincing to you. For example, at the start of the second episode, Fiona and her sister Sasha fire their caravan’s turbo boost to get out of danger, but Rhys and Vaughn fall off the back in the middle of the desert.; there is no way that they can stop the caravan and go back for them. “You think the guys will be okay?” asks Sasha. You as Fiona have the response options: “They’ll be fine” / “They have a chance” / “They won’t last the night”. Your choice doesn’t affect the storyline (beyond the immediate dialogue), but having to make it prompts you to work out how you see Fiona’s character and her relationship with Sasha, and what you think about her developing attraction to Rhys (she flirts with him, and you as Rhys have the option whether to flirt back or not).

Another example, from early in the story, involves Rhys and Vaughn, who have survived their certain-death encounter with the heavily-armed bandits by summoning an even-more heavily armed battle-robot who in a blazing shoot-out despatches them one by one. (Though Loaderbot does the actual shooting, it’s you, as Rhys, who instructs him to fire at each target, thus implicating you, the player, in the killing.) It’s very violent, and there is a lot of (cartoon) blood. Afterwards, Vaughn is left a gibbering wreck (“I never wanna see somebody’s brains come out of their nose, not ever again”) and he starts wondering why they’re still alive and thinking about the bandits who died. As Rhys, you have the three dialogue options: “It’s over now, we made it!”, “They got what they deserved”, and “It was kinda fun”. If you want Rhys to comfort Vaughn, you can choose the first option, and his dialogue acknowledges Vaughn’s fear and disgust while observing that they’ve found they have the ability to come through such situations. Vaughn eventually accepts Rhys’s reassurance: “I guess you sort of have a point, somewhere in there.” Alternatively, if you want to play Rhys as someone who trivialises violence or finds Vaughn’s response irritating, you can choose the third option, and he says: “Aw, c’mon, It was a little fun. Right? You cannot honestly stand there and tell me that it didn’t feel kind of great to kick all those guy’s asses.” Again, after some hesitation, Vaughn goes along with your lead: “Okay… yeah… it was a little… awesome. But I’m sure it was as traumatic as it was fun. We’re probably going to need some therapy in the future, you know that, right?”

By requiring you to respond to the non-player characters and their take on the unfolding drama, the game prompts you to express what you feel about them and the character you are playing, even though in most cases your choice only affects the next line or so of dialogue. However, some dialogue choices have consequences which are fed back to you later: the characters remember what you’ve said and done to them. For example, if as Rhys you choose to instruct Loaderbot to self-destruct during the fight with the bandits, when he later reappears and greets the other male characters with a fist-bump, he will pointedly not do so with you. It’s a painful moment of rejection, for Rhys and for you playing him, because you are implicated in his action. (You as Rhys have the opportunity to make it up with Loaderbot later.) Such choices are flagged to you as the player, after you have made them, with the onscreen message that the other character “will remember this,” thus notching up the emotional impact of the moment by promoting you to imagine what the implications of your decisions will be. The overall story requires that the main characters move from initial starting positions of mutual mistrust and caution to ones of trust and co-dependency, and your decisions do not change that, but your dialogue choices control the speed and manner in which this happens.

Every 15 minutes on average, you have to make a major and potentially story-changing decision, half the time as Rhys and half the time as Fiona. Most of these decisions have to do with trust and betrayal: whether or not to shout a warning to someone who has betrayed you but is about to trigger a lethal booby-trap; whether to meet up with the other main characters and work together or to proceed separately and possibly reach the prize before they do; whether (as Rhys) to put your fate in the hands of the lying and unreliable Fiona or the ghost of the charismatic but psychopathic Handsome Jack whom you used to idolise. Many of these decisions do actually change the storyline, though in a limited way: sometimes there are two alternative branches which then converge; sometimes the same scenes are played out in a different order with different characters present. But once again the extent of the difference is not what gives these choices their emotional impact; in a story filled with thrills and danger, decisions about trust, mis-trust and betrayal are critical to the characters’ fortunes, and by making you take those decisions the game forces you walk in their shoes for a while, even if you end up in the same place at the end whatever you choose. (A complete list of the major choices, and their consequences, is included in this online Walkthrough.)

I have often made the analogy between games design and learning design (for example here and here), so what are the lessons for learning design from games such as Tales of the Borderlands? What Telltale have done is to abandon the fictional holodeck as a model for interactive narrative, rejecting the techno-fantasy of total freedom and total empowerment for the player / reader, which is neither possible nor desirable; they have returned to the traditional strengths of good story-telling, focusing on just those interactive features which deepen players’ involvement, increase their emotional stake, and give them a sense of agency in moving the story forward, The lessons of this for learning design, I believe, are that we do not have to apologise for the traditional strengths of good teaching – compelling topics, clear explanations, well-designed cognitive scaffolding - and that when we seek to enhance these with technology we should focus our efforts and resources on features which really increase value for the learner. Increasing value through cognitive effectiveness is familiar territory for us; for example, when designing simulations for learning, as I’ve previously observed, we focus on simulating those things which learners are most likely to get wrong, so that they can make those mistakes and learn from them. But another way of increasing value is to deepen learners’ involvement, emotionally as well as intellectually. The emotional aspects of learning, though present in our design practice, barely figure in our design thinking: we have an intuitive sense of what will be interesting for learners, what they will find fun or challenging, and how we can work the occasions for such emotions into the design of our learning experiences, but we do not have well-established ways of thinking and talking about this.

When I first started writing distance learning materials back in the 1990s, I was taught to plan my units in terms of a “storyline” or narrative sequence, which would put the necessary topics into a logical order and give a satisfying shape to the whole. This practice, which I believe originated at the Open University, seems to have fallen out of use, because I've not encountered it since. The metaphor of the narrative and the analogies between teaching and story-telling, between learning design and the design of a reader’s or player’s experience, are I think overdue for a revival.

Notes

[1] Star Trek’s holodeck was introduced in Encounter at Farpoint (Wesley Crusher falls into a stream) and further demonstrated in Code of Honour (Tasha Yar shows that a holographic opponent can throw you to the dojo floor). Captains Picard and Janeway were seen fantasy role-playing in The Big Goodbye and Persistence of Vision respectively. Many episodes showed the holodeck being used for training (for example, Chain of Command Part 1, Worst Case Scenario) or recreation (for example, Fair Haven), while introducing the more sinister possibilities of holodeck addiction (Hollow Pursuits, Pathfinder) and of being unable to distinguish between holodeck and reality (Ship in a Bottle, Projections). Some holodeck characters were or became self-aware: Professor Moriarty (Elementary, Dear Data), Vic Fontaine (His Way), the Emergency Medial Hologram (Caretaker), and Michael Sullivan (Spirit Folk). The holodeck also allowed the scriptwriters to indulge in genre spoofs: the Western (A Fistful of Datas), James Bond (Our Man Bashir), a French Resistance drama (The Killing Game), and Flash Gordon (Night, Bride of Chaotica!).

[2] See a review by John McLaughlin, and links to other reviews here. See also Murray’s ‘Inventing the Medium’, her introduction to the book New Media Reader.

[3] The problems with interactive narrative are summarised by Steven Johnson in Wired, 'Why no one clicked on the great hypertext story'and by Ernest W Adams in his 2005 lecture to Game Developers’ Conference ‘Interactive narratives revisited: ten years of research’. An academic article summarising the issues is Mark O. Riedel and Vadim Bulitko ‘Interactive narrative: an intelligent systems approach’ in AI Magazine 34 (2013), 67-77.

[4] In the celebrated Façade, you play a guest visiting the home of a couple who are on the edge of breaking up; the narrative is not disrupted by conversational non-sequiturs or failure to respond to your remarks, since the other characters are supposed to be bickering and preoccupied with their own thoughts. (See an article analysing its design by Alex J. Champanard.) In Her Story (many reviewers’ Game of the Year for 2015), you are viewing video clips of police interviews following a suspicious death; the game's interactivity is limited to providing you with clips on the basis of your keyword searches, but the construction of the narrative is entirely yours as you try to understand the story of the woman being interviewed. (See the short discussion in my Seen and Heard blog entry for September 2015, and reviews in Adventure Gamers, The Guardian, and Rock Paper Shotgun).

[5] Indeed, Adventure Gamers website, although reviewing the titles (very favourably), excluded them from their 2016 Adventure Game awards on the grounds that they were pure stories, including neither exploration nor puzzle-solving.

Talking on the radio or on the web

Reading Charlotte Higgins' excellent history of the BBC, and its accompanying articles in The Guardian, I've been struck by the analogies between the early broadcasters, working out how to use the new medium of radio, and those of us in universities working out how to use the online medium.

This passage from a letter by Hilda Matheson, BBC Director of Talks between 1926 and 1931, seems particularly relevant to our making of audio and video in which academics talk to students.

The thing broadcasting does, or can do, its chief claim as far as the spoken word is concerned, is that it provides not a silent-printed word, a dead word if you like, but a living and very personal contact with an individual. The crucially affectionate link that grows between listeners and announcers, between listeners and regular broadcasters ... is something quite peculiar to broadcasting. [p 35]

If a lecturer's audio or video is doing nothing more than delivering information, then we might as well have put that information in text and saved some money, as well as improved convenience for students. But of course, we are not in the business of content delivery: we are in the business of education, for which the relationship - the personal relationship - between teacher and student is a vital part of the magic, the spell, the spiel.

The learning technologies of 1990

To celebrate a colleague’s clocking up 25 years on the staff of The Open University, I put together a slideshow to remind us all just how long ago 1990 was. Amongst other things, that was the year in which Margaret Thatcher was forced to resign, Germany was re-unified, and the first Gulf War began. Top films of the year included Ghost, Pretty Woman, Home Alone, and Back to the Future III.

But what was learning technology like in 1990? Three events from The Open University’s history remind us how things were back then.

First, there was a change to the transmission timings of the TV programmes made and broadcast by the BBC for OU students. From the time of the OU’s first course in 1970, when domestic video recorders were many years in the future, these programmes had been transmitted late at night or in the early morning, so that – as became a legendary British curiosity – not only OU students but insomniacs and early risers could study art history, theoretical physics or human psychology in the hours before or after regular programming. In 1990, the BBC moved all its educational broadcasting, including OU programmes, to an overnight “Learning Zone” (“zone” was very much a word of the period) on the basis that people who wanted them would record them and watch them later at a time of their convenience. This marked a technology milestone, in that for the first time the OU was working on the assumption that video recorder ownership was now so widespread that all of its students owned and (perhaps more crucially) were able to program it.

At that time at the OU, only students on certain courses were required to have a computer, or at least access to one. The minimum specification of that computer had been the subject of much debate, being eventually fixed around the capabilities of the Amstrad 1512: an IBM PC “clone” from the company of Alan Sugar, who was then famous not for firing apprentices but for manufacturing cheap and sturdy computers for the business market. In 1990 however, the argument erupted again when the minimum specification was breached by a computing course which – because of the requirements of a database package – demanded that students have a computer with TWO floppy disk drives, instead of just one. (Most personal computers at this time did not have a hard disk drive, let alone a CD-ROM reader.)

In 1990 an internet connection was also a rarity for domestic computer users, though about two thousand OU students and lecturers were required to have one in order to use CoSy, an early computer conferencing system. Such things were new and unfamiliar to those outside academic science and the computer industry; CoSy had to be accompanied by a long and detailed manual, in which operations were explained through the analogy of working on a desktop with different files and folders which might be open or closed. (Few people other than users of the Apple Macintosh had experience of a windows-icon-menu-pointer system; Microsoft’s attempt to create a rival system called Windows had only reached version 3.0 in 1990, and was still vastly inferior to the Mac OS.)

These kinds of trips back into the past can be great fun. (So can seeing what kids of today make of the cutting-edge technologies of yesteryear.) But if we find the VCRs, floppy disk drives and dial-up internet connections of 1990 quaint, we should resist the temptation to imagine ourselves superior to the people we were back then or to congratulate ourselves on how much progress has been made. Rather we should be reminded of how many of the technologies which now seem so obvious and central to our lives will in fact prove transitory and doomed to ultimate obsolescence. William Gibson, the author of the 1984 SF novel Neuromancer and regarded as something of a prophet of the digital world, once commented on his attitude to new technologies:“whenever I’m shown something like Google Glass, … [I imagine] what it would look like in the display cabinet beside the cash register in a [charity] shop - I try to imagine how they'll look in ten years time. It's a very good exercise for putting it in perspective. In a charity shop you'll find all the once-new technology, gathering dust as all things do.”

That’s the great thing about history: it can give strip away our temporal chauvinism and give us perspective. How will the learning technologies of today look in 25 years time, I wonder?

The Waggler, the Knocker, and the sponge on a stick: science and craft at the Wedgwood Museum

I was surprised recently to hear several people in my university say that they wanted learning design to be more professional and less of a craft. I've always been proud to count myself an expert craftsman in it, so this was a bit of a blow and I wondered what they actually meant. I think they meant that they want learning design to have a better evidence base and a better grounding in theories of learning - which is fair enough, but if they're hoping to achieve the scientific certainty of being able to say "this works better than that" I believe they're going to be disappointed, because such certainties aren't available in the educational world. However good your evidence, however well-grounded in theory your learning design is, I believe when you've actually trying to make something you still have to resort to craft.

A visit to the Wedgwood Museum put the relationship between science and craft into perspective for me. One of the things for which Josiah Wedgwood is famous is the experimental quantitative rigour with which he perfected the materials for mass-producing his fabulous decorative tableware. One of the museum's iconic exhibits is a tray of ceramic slips, each having been fired with a slightly different glaze, which he used in the research for what became known as Jasperware. So that is a kind of exemplar for a scientifically based production process: the glaze needs to be mixed like this, and not like that, for the best results; the research says so.

But if you go to the demonstration area, where staff will show you how pots and vases are actually made, you get a different picture. Yes, everything which they do depends on the precisely controlled composition of their materials; the maker of slipware vases needs a plaster mould which absorbs water out of the slip at a predictable speed, they know and allow for the precise percentage shrinkage on firing (it's 12% by the way), and they can count on their glazes and pigments working properly even though their original toxic ingredients such as lead and arsenic have been replaced with less harmful substances tested and selected to still behave just as Josiah Wedgwood intended. And yet, when it comes to hands-on working, what counts is craft skill, with craft or folk terminology.

Jasperware vases usually have a decorative design in a contrasting colour. To get the decorative application out of its mould, they use a tool called a Waggler. It's rather like a handle of a spoon, precisely shaped for its job of easing out a delicate and fine-detailed sliver of clay, And they really do call it a Waggler; the demonstrator told me that there was a scientific name for it, but he couldn't remember what it was. It gets better: to firm up the clay in the moulds, they use a wooden mallet with its head covered with enough cloth to give it just the right amount of bounce, which they call a Knocker. And when they throw a pot or a vase on a wheel, to reach in and remove the excess water from the bottom after they've finished, they use a piece of bathroom sponge taped to the end of a bit of stick, which they call "the sponge on a stick".

The custom-made tools, or tools put together from things lying around, and the folksy names for them, are characteristic of craft and its culture. You couldn't ask for a clearer demonstration that no matter how scientific you get, you still need a Waggler, a Knocker, and a sponge on a stick.

The Waggler

The Knocker

The sponge on a stick

Share and enjoy

The draft text for some course materials I was producing included a section called "Share and enjoy". In a meeting for last minute editorial revisions, one of my colleagues proposed that the section heading should be changed because "Share and enjoy" was naff. I observed that a stronger reason for changing it was its use in Douglas Adams' 'Hitch-hiker's Guide to the Galaxy'. The blank faces around me suggested that this media reference wasn't as well-known as I'd thought, so it's worth exposition here.

It comes from the second series - Fit the Ninth, to be precise - which wasn't represented in the TV series or the film, which is probably why it's not as familiar as, for example, Vogon poetry, or Life, the Universe and Everything.

NARRATOR: 'Share and Enjoy' is, of course, the company motto of the hugely successful Sirius Cybernetics Corporation Complaints division which now covers the major land masses of three medium sized planets and is the only part of the Corporation to show a consistent profit in recent years.

The motto stands - or stood - in three mile high illuminated letters near the complaints department spaceport on Eadrax - 'Share and Enjoy'.

Unfortunately its weight was such that shortly after it was erected, the ground beneath the letters caved in and they dropped for nearly half their length through the underground offices of many talented young complaints executives - now deceased. The protruding upper halves of the letters now appear, in the local language, to read 'Go stick your head in a pig' and are no longer illuminated except at times of special celebration.

Once again, I'm astounded at the prescience of Douglas Adams. At a time when most commentators were forecasting either techno-utopia or techno-dystopia, he foresaw technology being used in the service of corporate blah, of marketing and PR. This is a universe in which the lifts not only welcome you but refer you to other buildings containing lifts produced by the same manufacturer, where the shoe companies use techno-military hardware to enforce sales of their unsatisfactory footware, and where the drinks machines threateningly command you, as they dispense their disgusting liquids, to "enjoy your drink". Yes, he saw the future all right.

Reference
Douglas Adams, The Hitch-Hiker's Guide to the Galaxy: The Original Radio Scripts (London and Sydney: Pan Books, 1985), pp 176-77.

Visions of the future

As part of the Guardian’s Generation Y series, four authors wrote short-short SF stories about the media of the future. All were dystopian, and interestingly two of the four focused on the issue of personalization (as distinct from customization, see below), taken to the extreme: where you can view only the online content which has been deemed suitable for you, not by some Big Brother central state but the commercial forces of advertising and profiling.

In “News hacking is the new glue sniffing” by Laurie Penny, teenagers gather in a seedy dive to read the news: “not only the news that’s been tailored to their age, interests and background, but any news” - for example, that Tottenham has been under military occupation for two months, which is blocked if you have a London login. They hack the internet service to create open logins, which is a risky pursuit; “companies can and do sue users for loss of potential advertising revenue”.

In “Paper” by James Smythe, a man on the underground is reading his own (digital) Paper, which is feeding him news and gossip about the Oscars ceremony and trying to get him to buy a suit similar to the one worn by one of the actors. He sees a woman reading about an unfolding war on her own Paper, but he can find no trace of it in his own (although he finds “war” occurring in the names of TV shows and films, and a story about a fight between two women on a reality TV show). A message comes up: “Based on your social profile, we have predicted that these will not be interesting to you. Would you like to know more about best actor at last night’s Oscars?”

Generation Y, it seems, has no truck with the happy hippy utopian vision of the internet as a free space for (hedonistically) sexual expression or (politically) democratic protest. Some of us old ‘uns never believed it anyway, but the younger generation sees perhaps more clearly – despite, or perhaps because, being more immersed in online social media – that the digital world replicates all the power structures and social tensions of the physical, though amplified and on a larger scale. Let’s be careful out there, as they used to say in Hill Street Blues.

Note

“Personalisation” and “customisation” are similar and the words are often used interchangeably, but there’s an important distinction. In usual usage, “customisation” is what you, the user, do to select the things you want; for example, you can “customise” the Toolbar in Microsoft Office so that it contains the icons you want to see most frequently. “Personalisation” is the system choosing what to put in front of you, based on what it knows (or thinks it knows) about your and what you want; targeted advertising or, more benignly, Amazon recommendations, are personalisation.

No guessing, no lockouts, no death - games design and learning design

(Updated 21 April 2014 - see postscript at end)

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.