The Cult of the Peacock

It’s easy to forget that at one time all videogames had manuals. I used to like reading manuals. Manuals were cool. Now, instead of manuals, we have interactive tutorials. They take about fifty times longer to produce, three times longer to consume, and players hate them so much that their highest aspiration is to become completely transparent. Currently I spend most of my waking hours developing them. It should come as no surprise that I hate them too.

This is a story about how these things happened. It’s sort of a companion piece to the article I wrote about Liz Ryerson’s Problem Attic in that it examines the reasons why games like that became unfashionable, how this is a bad thing, and what we might do to fix it. It’s a story about the history of interaction design both in academia and the games industry, as well as my experiences travelling through those spaces. It’s a story about how I got the kink in my neck, and the slow death of the videogame manual. It begins with a teapot and ends with a peacock. More than anything, though, it is about apotheosis. There are four parts. Shall we begin?

1. The Three Commandments

In 1988 a person named Donald Norman published a book that we know today as The Design of Everyday Things. This book is sort of like the Old Testament for interaction design people like myself; it has come to define the way we think about our audience, how we shape our process, and ultimately what it is we hope to accomplish with our work.

The Cover of "The Design of Everyday Things"

More than 100,000 copies sold!

The first commandment of DOET is that there are no dumb people: Only dumb objects. As a user you are never at fault for being unable to figure out how to use something. If you can’t convince your thermostat to turn on at 8:00 AM on weekends but 5:00AM every workday, that isn’t because you’re stupid and ought to read the manual; it’s because the thermostat’s designers made the thing too hard to understand. Programming your thermostat should not require research. You are a busy person who has more interesting things to do than waste time puzzling over a dumb and incomprehensible machine. (Puzzling over dumb and incomprehensible machines is the designer’s job.)

The second commandment is to make objects more usable by designing affordances, noticeable features that show people what they’re supposed to do with an object (that is, what actions the object affords) and ideally make it impossible to use that object incorrectly. Much of DOET‘s first chapter is about how to design doors. The side of a door that you have to push inward should have an affordance on it that looks easy to push but difficult to pull; and conversely, the side that you have to pull outward should look easy to pull but difficult to push. You should be able to see through most doors so that you know where they lead and can avoid accidentally smacking someone on other end, but they shouldn’t be so transparent that you accidentally run into them or mistake them for windows. Designers are weirdly fixated on doors.

The third commandment is every software designer’s best friend and worst enemy: Use good affordances to produce accurate cognitive models of how objects work. Cognitive models are like a person’s mental map of a tool or a computer application. Accurate ones, which result from helpful and consistent affordances, allow you to recover from mistakes because you understand exactly where you went wrong and know exactly how to undo it. Inaccurate ones, by contrast, result from unhelpful or inconsistent affordances and tend to leave you paralyzed. Have you ever watched a novice computer user superstitiously avoid touching ANYTHING because they’re afraid of contracting a virus or somehow erasing all their photographs? To my grandmother, using Windows Vista is like traversing the Mines of Moria.

DOET judges the user’s needs most important, and her perspective most valuable. It is about the apotheosis of the user; it makes her into God, and with holy might it strikes the fear of Her into objects and those who make them. Designers whose products were easier to create than they are to use shall be flogged by a rolled up thermostat manual. Designers who make doors that you can’t tell whether to push or pull shall have their eyes pecked out by the ravens of the valley. Designers who unwittingly architect the Mines of Moria shall be stoned with stones until they are dead. I have it on good authority that The Design of Everyday Things transformed the people responsible for Clippy into pillars of salt.

DOET, alongside all the important research around it, culminated in something called User Centered Design, a philosophy in which “user error” does not exist and programmers are sad. Under UCD, designers first figure out what their software should do by interviewing potential users and observing them while they work. Next they prototype some way of improving those users’ lives, like an improved piece of productivity software. Then they observe how well their prototype works, then they refine it some more, then they observe how well their refinements work and then they refine the refinements. If they’re skilful and lucky, the five- or six-hundredth iteration of the third or fourth complete design overhaul will yield something that is actually helpful to people; if they’re really lucky, someone will then decide to pay for it.

2. The Shadow of the Teapot

I came to university in 2006, by which time DOET and UCD reigned as the dominant religion of interaction design. I came because I wanted to make videogames, not thermostat firmware; at that time, however, the universities around Vancouver had no formal videogame programs. There were really only three options: I could take computer science, I could take interaction design, or I could attend this thing called SIAT that awkwardly slapped the two together alongside Art. I chose the third option, which was a wise decision because it turned out making videogames is exactly that: The awkward slapping together of computer science, interaction design and Art. When I started to actually make games, however, I discovered that although all three disciplines were represented interaction design had accumulated the largest share of power. I was taught that videogames, being made almost entirely of software, are prone to all the same failings and benefit from all the same design techniques. Games were good when they didn’t need a manual. Games were better when they honoured their users in every way possible. Games were best of all when we viewed them as the unrighteous progeny of their designer’s original sin; they needed to be prototyped, they needed to be tested, and ultimately they needed to be saved. As the instrument of DOET I became responsible for their salvation.

A screenshot of my stupid project

Pictured: Regret

Here is an anecdote. For my upper-division game design course our team decided to make a Civilization-like set in the ice age wherein the player hunts and gathers resources to help her village survive. I spent many late nights towards the end of the project programming a tutorial system that pops brief explanatory dialogue boxes at the player only once (typically the first time she uses some relevant mechanic). We could think of all kinds of reasons why this was not ideal, but we’d been busy with all the game’s other aspects and hadn’t had time to do anything more elaborate in only 13 weeks. On the last day of the course our professor brought in a game industry expert whose task was to select the best student project and award its developers a (drum roll please) $50 Future Shop Gift Card For Excellence in Game Design. He spent about five minutes with our prototype. During that time he intentionally skipped every dialogue box, clicked around randomly, repeatedly announced he had no idea what to do, and unfavourably compared it to a hidden object game he’d played in the row behind us. He said there was definitely no way anything in our prototype could be the sexy new core mechanic for a Need For Speed sequel. Then he walked away. (Designers who expect the player to read things shall receive no $50 Future Shop gift card.)

I sent five years in SIAT, studying under the long shadow of DOET’s iconic teapot. Over that time I developed both a burning resentment of and a guilty longing for user testing that I suspect will follow me for the rest of my life. But I also learned how to make videogames, and today I am not unduly proud to say that I work in the videogame industry (where programmers are also sad). Here usability is no less a religion than in design school, although it’s a different sort of religion. We inhabit a feudal hierarchy of executives, marketers, designers and other stakeholders who each harbour their own beliefs about who players are, what they enjoy and what they will purchase. There is lots of money involved, of course, which is the domain of the stakeholders. But there is design involved too, which is the part where we diaspora from the shadow of the teapot can relieve all our guiltiest longings. As a game designer my job is to render unto Caesar what is Caesar’s, and unto the User what is the User’s. Sometimes these interests are at odds (see: The history of microtransactions), but at other times they intersect.

UCD, in games and all other software, makes for happy bosses and happy players because it helps you make justified decisions. In games there are ‘artistic’ decisions and ‘design’ decisions, the difference between them being that artistic decisions are non-falsifiable. You often make artistic decisions about your game’s intrinsic features, like what mood you want it to have, and no one can claim with certainty that these decisions are right or wrong. Artistic decisions are tough because in the absence of certainty you will never in your life convince an entire company to agree on something. Marketing will make a marketing argument, the creative director will make a creative argument, and then whoever has enough power to decide will get to decide. Design decisions, by contrast, are very falsifiable because you can test them. You first make design hypotheses, which usually concern your game’s extrinsic features like the specific techniques you use to achieve whatever mood the winner of your last argument decided. Then you make some prototypes featuring those decisions, hand them to the player, and see what works. Caesar loves design work because it mitigates risk (or at least obscures it); the User loves design work because it frees her from confusion and frustration. Everybody loves design work so much that in the modern game industry we have adopted analytics as a method of converting every single risky, contentious artistic decision into a safe, testable design decision. The Zyngas of the world do not make artistic choices about what colour to make the title screen. They simply do a split test: Show half of all players a blue one and the other half a green one, then choose the option whose test group proved more likely to click the ‘Play Now!’ button. In effect design has now been weaponised, and Art can’t really keep up.

What Caesar loves even more than weapons is that UCD improves a game’s market performance on every conceivable level. A game that is easy to use enjoys a wider potential audience because it requires less expertise and effort on the part of its players. It demos better at trade shows and in game competitions, where people have a limited amount of time to evaluate it. It even receives more favourable product reviews, in part because writers face tremendous competitive pressure to finish an entire game and publish something ASAP. When someone has to consume 60 hours of content in three days so she can hit her publishing deadline, it had better damn well be easy to digest. The market for games and game culture is very crowded and the competition is fierce. No one has time to sit around scratching their head; your best chance at getting anyone to look at the work you do is therefore to UCD the crap out of it.

Here is another anecdote. At my game industry job I once sat in on a testing session during which a brand new player decided he would try out each button on our title screen while talking through what he thought each one would do. He enabled and disabled mute; he found the credits where he expected the achievements to be; he tapped a few things that weren’t implemented yet. He then tapped on the button that led to our pictographic, 100% text-free ‘How to Play’ screen (by now we thought we had learned our lesson about players and reading things). He looked around for the smallest possible amount of time the human brain will allow, succeeded in recognizing that it was indeed a tutorial, and then immediately tapped the ‘close’ button. He later spent several minutes wondering aloud what the game’s controls might be. (Designers who expect the player to look at things shall not leave the office before dusk.)

3. The Cult of the Peacock

These various incentives have coalesced into a dominant school of thought regarding what games are and can be. This school teaches that if it’s not fun (or at the very least quick and painless) to be taught about some feature, we shouldn’t include it; that clarity is better than complexity; that elegance is better than messiness; that one button is better than two. It teaches that the purpose of a game is to explain itself to you, and that somewhere in the act of explaining lies that game’s intrinsic value. We have thereby converted the scariest, most contentious question of all (what should this thing be?) from an artistic decision into a design decision. We have done this because it is profitable, but also because it has a tendency to produce beautiful results.

A photograph of a peacock

Pictured: The product of an iterative decision making process.

What we’ve neglected to consider, though, are the side effects of placing so great a burden upon designers. Consider this. Each game (as well as any other work of media) possesses a ‘burden of learning’: All the things a person must understand in order to consume it as its authors intend. This burden of learning falls somewhere on a spectrum with two opposite extremes. One extreme emphasizes the discovery of features by the consumer, which is to say it ‘burdens’ her. Works on this end are often challenging to the audience in the Art sense (not the Super Meat Boy sense); they require time and energy to parse. English poetry, for example, burdens the reader by assuming she is literate and therefore omitting any kind of tutorial explaining what each Roman glyph represents or how verbs work. The other extreme of this spectrum emphasizes the teaching of features by the designer. This work is accessible to the audience, which is the opposite of challenging. It includes things like airport signage, Bolshevik propaganda and of course videogames, all of which tend to deal in clear and elegant ideas because those are the easiest to communicate.

By pushing the burden of learning further and further towards the designer (and demanding less time and energy from our users) we have managed to create all manner of wonderful games that many people can understand instantaneously without the aid of manuals, previous videogame experience, The Rosetta Stone, et cetera. These games sell really well and a lot of people like them. But each step towards the accessible end of the spectrum carries with it an unseen cost: The designer’s time and energy. A designer is kind of like a Turing machine: Given enough iterations she can figure out how to teach any player any game mechanic without causing boredom or confusion. But those iterations are not free and time is not unlimited, and for this reason there is an opportunity cost to performing them. The time a designer spends discovering how to better explain one mechanic cannot be spent improving the game in any other way. Thus, the more accessible you make a game the more time each feature costs, and the less time is available to do really anything except work on accessibility.

Over the past twenty-five years or so the burden on designers has crept forward alongside the march of technology, and as a result the form and content of games has changed. Accessible games are endlessly adaptable; that’s why we’ve all been remaking DoomSuper Mario Bros and Tetris this entire time. Complicated games are more fragile and have a tendency to boom and bust. In the ’80s it was fashionable for the Ultima franchise to use every key on the keyboard, explaining itself through paper manuals, cloth world maps and a whole lot of inquisitive key presses. But when the rising cost and complexity of development outpaced the growth of its audience, Origin Systems went extinct. (Today its bones serve as novelty shelving units for Sims 3 expansion packs.) This did not happen because Mario games are ‘better’ than Ultima games in any definitive way; the two have different strengths and are difficult to compare. Yet in the school of thought I am describing accessibility is the only possible goal. Super Mario Bros uses four buttons whereas Ultima IV uses all twenty-six of a standard keyboard’s letter keys. All. Twenty. Six. (Good luck teaching that stuff solely through clever antepieces.) Because this school of thought has become so entrenched in everything from development to marketing to criticism, Mario gets to be the state of the art while Ultima occupies a tiny undernourished niche.

The further we shift the burden the higher we raise the bar, and it has now reached so absurd a height that the decisions we make to reach it defy all reason. My last project was an iPad game. Because the user will not pay money for things on the App Store, the project was based on microtransactions. Because the user exists perpetually in a state of ‘about to abandon your game in favour of watching cat videos’, it was essential that our menus (and their embedded microtransactions) were neither confusing nor boring, remaining unobtrusive while simultaneously being present all the time. Because the user will not read a bunch of text, these menus somehow had to communicate all their associated game mechanics instantaneously through graphics and interaction alone. Everything had to be snappy; everything had to work perfectly. I spent four solid months implementing UI for this project, about three quarters of my total time investment. I worked longer hours than I ever have, becoming snappish, aloof and even more cynical than usual as mild burnout set in. I developed neck problems that won’t go away. It was one of the worst experiences of my life. We succeeded in the end at producing an excellent user interface, but it’s hard not to view that as a Pyrrhic victory. I might have fared better had it been possible to, say, spend one afternoon writing a one page document explaining how the game works. I might have, in that case, spent four months (minus the one afternoon) improving the actual videogame part of our project. But that is not what we do in games anymore, because no one will read a one page document. Instead I spent that time iterating endlessly on features no one would identify as our product’s primary source of value but which everyone agrees are essential to resembling a high quality videogame (and thereby generating commercial and critical success). The proof is in my creaky spine: It is not what we explain but how elegantly we explain it that the industry values most. This fact is as abhorrent and destructive as it is lucrative. (Designers whose tongues are made of silver shall be rewarded with an opportunity to raise the bar from which they hang.)

The modern videogame is like a peacock, and affordances are its proud and luxuriant tail feathers. The primordial videogame was a humbler beast; but when our fondness for big, healthy, shimmering affordances came to the forefront of our affections, natural selection took hold. With each generation the feathers grew and grew. Eventually the beast became spangled all in affordances, its tail feathers ablaze even though it had little worth affording. Today we are both blessed and cursed with a giant kaleidoscopic rear end, as irresistible to female peafowl as it is to hungry feral cats. Videogames are caught in a Fisherian Runaway (what game designers might call a ‘race to the bottom’). Our belief in clarity and elegance, though it has yielded spectacular results, is not the very best way to make videogames; it may not even be a particularly good way. We suffer from the bar we’ve set for ourselves and the burdens we place upon designers. We are wrongly convinced, even in the critical community, that works like Problem Attic are unworthy of attention solely because they prioritize different features and challenge players in a way we deem to be unfashionable.

I don’t think this is what DOET intended. In truth, The Design of Everyday Things has only so much to say about videogames as an art form. Unlike a thermostat or an operating system, no amount of study can tell us exactly what a videogame should do for a player; its purposes are fundamentally artistic rather than designed. Sometimes they can be messy and often they can be obscure, but these are virtues in themselves. Games are made of software, but they are not only software. They can benefit from good affordances, but there is joy in discovering features for oneself. A videogame is not an everyday thing; yet by behaving as if it is we’ve warped the practice of game development. Our wayward school of thought pretends towards DOET‘s long shadow, but its claim is illegitimate. It does not honour the user by bringing her the best possible work; instead it coddles her by doing what she asks rather than imagining all that she might appreciate. In the process it leaves her without imagination, blind to the world beyond the tail feathers. It is more like a cult than a religion, and its time should pass.

4. Resolutions

It’s easy to forget that at one time all videogames had manuals. I used to like reading manuals. Manuals were cool. Now, instead of manuals, we have interactive tutorials. They take about fifty times longer to produce, three times longer to consume, and players hate them so much that their highest aspiration is to become completely transparent. Currently I spend most of my waking hours developing them. It should come as no surprise that I hate them too. (Designers who covet the heresies of their forebears shall lead a life of want.)

A scanned image of the Ultima 4 manual describing what the 'A' through 'Y' keys do

Not Pictured: An explanation of what the ‘Z’ key does. It brings up “ztats”.

Fortunately I plan on changing the way I spend my time: I’m going to write a lot of manuals! I think manuals might be the best way to improve videogames. I wrote a manual about Problem Attic that I mentioned earlier, and it was a very rewarding experience. It was beneficial to the author because it served to raise a little bit of awareness about the game (which is especially important for works that inhabit an atypical position on the ‘burden of learning’ spectrum). The piece got way more attention than anything I might have written about GTA V or something, firstly because the market for that stuff is extremely saturated and secondly because games like GTA V don’t really require analysis. (Some poor programmer already destroyed herself making that thing accessible enough for everybody. Maybe hundreds of programmers.) Most importantly, the act of writing it helped me learn a lot about Problem Attic and improved the way I think about videogames.

If you are a critic, I highly recommend writing a manual about a game you like. Game authors often can’t write about their own stuff because to produce an ‘official’ reading of their work would limit everyone else’s ability to interpret it. Their work must speak for them; only we players can speak back. Techniques like close reading can help build a comprehensive understanding of what makes games truly valuable (not just what makes them easy to learn). And by building this understanding we take important steps towards reigning in the cult of the peacock; as game festivals and other high-brow critical establishments pay more and more attention to challenging works the critical pressure towards accessible games will start to subside; ultimately we might even gain a better semblance of balance (like every other popular medium enjoys).

When I’m not writing manuals I will probably continue developing videogames, and I’d like to change the way I do that as well. I plan on thinking much harder about how I evaluate potential game features. “Because then the user doesn’t have to think” or “but how do we teach that?” should not be trump cards in every single argument about whether to include stuff. It’s easy to turn everything into a neat little design decision, but making a few more artistic ones would be better in the long term for users and for my sanity. I also plan on thinking very carefully (and complaining very loudly) about the actual development cost of implementing what appear to be vital or ‘must-do’ features just because they increase the size and lustre of our tail feathers. It’s greedy to make something shiny just because we feel we can; it’s smarter to consider just how many ‘could-do’ features we’ll lose in the process, and whether our game might be diminished by recklessly chasing the bar. It’s okay to ask for trust from your users rather than just money; sometimes they even enjoy it. I think it’s important to build that trust through improving game literacy rather than trying to eliminate the need for it.

First you write the manuals. Then you get the literacy. Then you get to stop feeling quite so bad all the time. This is the hypothesis. I long to test it.


  1. Fasox says:

    I hate the new “holding hand system” that every game has now and i agree with you in most of the points.
    But, for example, the part of “…our project. But that is not what we do in games anymore, because no one will read a one page document. Instead I spent that time …” i must disagree, its true that most of “gamers” won’t read anything, and look the “X” button instantaly after the page popup. But force them to read it, making no other way to learn it. Seems wrong to me.
    Lets take an ios game as example, i want to download it and play for 10 minutes or so, and close it once the “free time” is over, i wouldnt read anything to learn to play (unless, i know the game worth it previously to play it).

    And here it is one anecdote from me:
    I took one game of mine to a game-expo, the game has a minimal tutorial where it teach the controls.
    But the game also needs from the player think in a special way (taking Portal for example). My time was running out so i decided to make a pictographic manual, no one read it , they just jumped it and 5 minutes after they were like “What the fuck you want to me to do?”.

  2. Pingback: Great Read: The Cult of the Peacock « New Rule

  3. Pingback: The Sunday Papers | Rock, Paper, Shotgun

  4. Pingback: Юзеру юзерово и геймдизайн глазами недовольного разработчика | Sergey Galyonkin

  5. Pingback: What I’ve Been Reading: January 12, 2014 | Refrigerator Rants

  6. Slow Dog says:

    Minecraft has sold over 33 Million copies. It’s expected to hit 50 Million this year. It has no in game tutorial. Also two of the bestselling books for children over the Christmas period in the UK were Minecraft Manuals.
    I guess the affordances folks may just say “Imagine how many more it would sell if were easy to learn”.

    • Yes! Imagine! Just imagine how much more! Ten… one hundred times more!? Can you see the mountains of gold; crinkled dollar bills folded into delicate semi-sentient origami dragons!? “You can never have enough money, right” they would say, standing astride the backs of a thousand computer science interns drawn out by the smell of all that lucre… by the promise of a dream job alongside their heroes, Jeb and Notch! The hollow drumming of their fingers on 3rd party nock-off apple keyboards, a thousand lowered heads, a thousand voices hush during every stand-up! Vance you fool! The answer has been in front of you the whole time! Money, Mr Vance! Moar money!!!

  7. Blob says:

    Well said indeed…
    I would just add that, for me at least, learning is an integral part of what makes games interesting. You have to learn the controls, you learn the game lore (if there is one), and you learn the game’s system of rules – which you then learn to exploit in order to maximize your score/result. All this learning is a challenge and overcoming that challenge gives me as a player a sense of satisfaction. Without challenge of one form or another a game is useless – it is no longer a game, it becomes just routine repetition of established patterns, much like working at an assembly line.
    As an extreme example of a learning-based game, take realistic flight simulations. There, studying the 200+ page manual and learning how to operate an airplane in all its complexity is really half the fun. Granted, it may not be everybody’s cup of tea, but there is a persistent and dedicated community of flight simmers out there, nevertheless…

  8. Nixitur says:

    Very well said.
    But, as has been said, while the “Race to the Bottom” is present almost anywhere, we still have our Minecrafts, DayZ’s, Garry’s Mods (not a game, but it’s still hilariously difficult and complex with no tutorials) and Dwarf Fortresses (which is free, but the developer lives comfortably off of donations).
    Of course, those are the exceptions, but there is definitely a market for video games that are mainly about the joy of discovering new elements.

    I’m not a designer, just a player, but when I read a game’s manual (if it exists) and look up the key mappings (as I’ve learned to always do when I was younger) and then the game starts an interactive tutorial and expects me to not have read anything about how the game works, I just get extremely frustrated.
    One of the worst offenders was, I find, Prototype. I had several powers throughout the tutorial, but when I pressed what the options told me was the “change powers” key, it just didn’t do anything.
    At first I thought I did something wrong. Then, I thought the game was broken. But no, as it turned out, it was just a tutorial and the designer decided to coddle me, hold my hand and, all in all, treat me like a child.

  9. Keeping it Real says:

    Amazing! Golden words being spoken and this is the state at which video games should be headed. Everyone can learn from this.

  10. 🙂 good article. I have also more often than not ripped open a games packaging expecting to burst my way into a fantastical and unshakable world of suspended disbelief only to find a two sided leaflet advertising a completely different game and slumping crestfallen, limp back to my hovel where I reminisce about better days gone by… Sigh

    This is probably more nostalgia than anything else and I have a cure for that… EBay 🙂 I bought big box copies of all of the quake games, duke nukem 3d, and numerous others (I even have a boxed creative 3d blaster voodoo 2 12mb, affectionately referred to as.. the precious)..

    That said, putting more in the box can be taken too far:

    Basically though, games need to be more accessible because more people are accessing them. This is OK. As a designer, I can deal with that. Surely, esigning a game well enough to not need a manual should be seen as a wonderful challenge rather than a burden…

    That said there are still games out there that def do require a steeper learning curve of the player (hello Crusader Kings II) but for these, I think most people rely on ‘Let’s Play’ sessions on YouTube.

    I love what he was saying about watching user tests and letting them inform the design. I did this one project in uni ( where I included no instructions, no interface, no menu, nothing.. This was fitting for the game as you play a newly disembodied spirit, still confused as to what they are doing in the underworld. I had about 20 people test it over the course of development and it was one the highlights of my year. You make an assumption as to what the player will do if the staircase that was there a moment ago suddenly isn’t or when they can’t see the platform they have to jump to, you build a prototype and then you get to watch to see how the player actually reacts.. Awesome

    I think more and more though, we’re going to need to look to the indie scene to find new designs that might merit more intense instruction. Commercial games will continue to be distilled further and further down to things that people already understand, candy crush saga I hate you, you $63 million a month in revenue bastard.

  11. donnorman says:

    You understand! You get it1 Thank you for the delightful article thoughts (and words of praise for DOET (now out in a newly revised and expanded edition).

    I have some thought to add, bot to your (Brendan’s) article and to commentators.

    Games are supposed to be difficult and challenging. Manuals are seldom read, and therefore the more we can do without them, the better. (Yds, I also like well-done manuals.) But the challenge of a game should refer to the deliberate structures and challenges of the game design, not to figuring out the goal, purposes, and controls (unless, that is truly what the designer intended.)

    How can one balance ease of use with the challenges and difficulties of play? That’s where the skill of the designer comes into the picture.

    I believe it is possible to design game controls and other features in ways that do not require manuals, especially for experienced game players. Attract screens (remember them?) can also serve as tutorials without feeling like one. Similarly, there can be other features whose purpose is to demonstrate and te4ach but that are so cleverly done that they are not perceived as such.

    Consider the author of a novel or detective/crime/spy story. They have to tell the reader a lot of backstory, but this stuff is really dull. How do they do it? They will introduce a younger character who is new to the scene, so that either the hero has to explain a lot of stuff (but in a natural way), or the new person will unearth material and rush to tell others. The others may even respond with boredom, but the reader of the story gets informed.

    In a first-person shooter, maybe the old veteran off on the side kills the wicked troll and shouts, “yes! command-back-arrow, double click, twist the wrist works again!”

    You figure it out.

    Thanks for the great analysis and rant.

    Don Norman (yeah, author of Design of Everyday Things)

  12. Though it may not seem related, I think that part of the success of eSports (or even the rise of WoW) is precisely in their complexity and requirement of external knowledge. Users can spend hours researching forums, reading guides, watching videos and in many cases posting their own insights. For instance, Team Liquid’s StarCraft 2 forums have a thread devoted to configuring and tuning your mouse settings that is 149 pages long with 4800 posts. Certainly overkill, but like anyone who is in to competitive car racing could wax poetic for hours about suspension tuning for various track surfaces. Back in the hey-day of WoW, the Elitist Jerks forum featured complex Excel spreadsheet calculations and mathematical models for optimized casting rotations and items. League Of Legends almost mandates innumerable hours researching professional play if you want to get good (which, when I said that, made my game designer friends who were trying out LoL break in to a frothing rage). I know these are fairly extreme, but again talk to any fantasy football fan and they will be doing similarly complex calculations about their players. These extra-game knowledge systems and communities are a huge part of what makes these sorts of games fun and engaging over a long period of time. It becomes really clear when you go to the bar and talk about games. It’s hard to sustain a long conversation about AAA titles like GTA4 because it’s all so self-obvious. But get someone talking about their WoW raiding career or the recent LoL OGN tournament and… well, I hope you have time for another four beers.

  13. Brotoles says:

    My friends used to mock me because I’d always read the manual first before playing a game 🙂

    One of the best manuals I’ve ever read was from a Monty Python game (Monty Python and the Holy Grail, from developer “7th Level”)

    It seems as if the group itself has written the manual, it’s super super funny, and one might even wonder if it’s not better than playing the game itself (though the game has some really fun writing too)… For example:

    “Note: The hard disk is a very technical piece of equipment that is used by the computer industry for doing things that other things cannot do. NEVER attempt to use your hard disk in a gravity field of less than -275.89 hectoids.”

    Now that’s some useful information! ^_^

  14. Pingback: Nintendo and Design Woes | Game Design Random Death Match

  15. Pingback: Racing (but mostly ranting) | Tagra Reviews Things

  16. Pingback: Blowjobs, Loneliness and Glitchhikers | Brendan Vance

  17. Pingback: Fashion, Emptiness and Problem Attic | Brendan Vance

  18. Pingback: Form and its Usurpers | Brendan Vance

  19. Pingback: Recommended Because You Watched Live Executions | The Conversation Tree of Woe

  20. BexEd says:

    Excellent article! One thing I really appreciated, though: “Some poor programmer already destroyed herself making that thing accessible enough for everybody.” I immediately saw myself in this person’s place – thanks for using ‘herself’. It’s rare that I see myself in others’ descriptions of programmers.

  21. Pingback: Tracing the Alternative JRPG | vextro

  22. Pingback: Form and its Discontents | Brendan Vance

Leave a Reply