Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 25, 2014
arrowPress Releases
October 25, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

The Cult of the Peacock
by Brendan Vance on 01/06/14 04:43:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


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.

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.

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.

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.)

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 reining 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.

Related Jobs

Digital Extremes
Digital Extremes — LONDON, Ontario, Canada

University of Central Florida, School of Visual Arts and Design
University of Central Florida, School of Visual Arts and Design — Orlando, Florida, United States

Assistant Professor in Digital Media (Game Design)
The College of New Jersey
The College of New Jersey — Ewing, New Jersey, United States

Assistant Professor - Interactive Multi Media - Tenure Track
Bohemia Interactive Simulations
Bohemia Interactive Simulations — Prague, Czech Republic

Game Designer


TC Weidner
profile image
Great article. I agree. First one size should not fit all, i wish this industry would get to understand this once again. If your game requires a manual, make a manual. Easier said then done of course, especially if you have to pitch the idea. If it doesnt, by all means keep doing what your doing

I think some of this relates back to a few decades ago, when manuals were common place, BUT then developers/publishers started getting cheap, and started half assing the manuals. Only thing worse than no manual is a half assed one. Games went from having these really well done, well documented manuals and inserts, into having half assed after thought inserts, and it hurt game play, and enjoyment.

So then they started to do away with manuals and game inserts all together and just put the documents into the game, huge mistake and turn off. Only thing worse than a half assed physical manual is a in game manual. Again players were turned off, enjoyment lost, and so it lead to today. Which, truth be told, in many cases works well for many genres. but it does seem to handicap those genres that do require more.

I am not sure what the answer is, since physical copies of the games themselves are fading away, I dont forsee a renaissance of the glory days of physical manuals, but there does seem to be a need for something beyond what we see as the new normal.

Luis Guimaraes
profile image
"Only thing worse than a half assed physical manual is a in game manual."

I don't know I liked the animated and voiced Plasmid manuals in Bioshock a lot. I also loved the manual screens for Desperados: Wanted Dead Or Alive. And the How To Play books in the Resident Evil series. The loading-screen tips from Unreal Tournament are also a kind of in-game manuals and they're cool.

If anything, the idea of making manuals with animation and sound is one of the advantage of in-game ones against physical ones. But also, if we're talking games, interactive ones aren't a bad idea either, fighting games like Tekken and Soul Calibur have been employing them for a while and the combination of them with the loading screen system was pretty awesome in Bayonetta.

There are many ways those ideas can be improved.

Personally as a player I just open the keybinds, read it, change a couple things and go, unless it's a game very complicated and different from the genres I'm used to or unique in some important strategicalç aspects (for example: Democracy, Eador...)

TC Weidner
profile image
those interactive training scenes are fine and sometimes even fun, but they do take away a great deal of time and resources.

Hell maybe Mattel got it right at the very beginning. Small easy to read manuals with control pad overlays :)

Sam Stephens
profile image
It really depends on the kind of game you want to make. A simple game with intuitive mechanics and controls does not need much instruction for the player. A more complicated game can use tutorials to contextualize and teach certain actions. Gamers often complain about tutorials, but these opinions tend to be egocentric; ignoring the learning processes of others who need them. Tutorials can be a very effective teaching method. I see no problems with how they are implemented in mainstream games today.

Ian Richard
profile image
All opinions are egocentric, that's why they are opinions.

On that note, many players find that tutorials aren't entertaining. It isn't unusual for modern tutorials to take up an hour of your time... or limit your own options until they teach you a technique many hours into the game. I've quit more than a few games because they wouldn't let go of my hand and let me PLAY.

Are our peoples opinions less valuable to those that like tutorials? Why?

Wouldn't it be a wiser design decision to pick the right teaching methods for the target audience rather than make everyone jump through hoops for the off chance that someone never played a video game before?

Not all games or players are the same, and our methods should reflect that.

Sam Stephens
profile image
I think you may be exaggerating a little bit. I can't think of any game with a tutorial that long. Tutorials help players learn. Why do you feel that you are above learning the game? Some games are just abstract and complicated such as turn-based RPGs and strategy games. Tutorials are the only way to effectively teach players about gameplay systems in these kind of games. Sure, some players could bang rocks together until they figure it out, but I'd figure they would rather the game teach them how to play. If you have a problem with this, then fine. But this places you in the role of an opinionated consumer, and not in the mindset of a considerate designer.

ceMelusine hrtz
profile image
I feel that you reading a very reactionary and conservative position into this essay that, in my opinion, is not there. Brendan isn't suggesting that games need to return to their supposed "hardcore" roots. Instead, he is suggesting that the current User-Centric Design principles, that seem so common in all corners of the development world, are actively training players to expect that they do not need to think at all in order to understand a game. Intuitive mechanics and controls don't really exist as some universal truth. These words are just stand-ins for what has already been trained into players. They are essentially just what is fashionable and commonly used. That in itself is fine. The bigger issue is that when anyone tries to do anything differently (Problem Attic, for example) it is largely ignored simply because its creator chose to forgo a tutorial so as to be better unified with the game's overall aesthetics. We lose out on such games because we become blind to other ways of thinking.

Ian Richard
profile image
Is it really considerate to force me freeze the game to tell me "You can use the control stick to move! Good job!" on my second time or third time through a game? How about for people who played previous games in a series or similar games? Is it considerate to waste their time explaining that you aim the crosshairs towards the bad things?

A considerate designer would ask the players "Would you like to go to boot camp and learn how to play the game?" New players can learn, but experience players don't need to waste time.
Design is about picking the right tool for the right job. Sometimes that tool is a tutorial, sometimes it's a well placed enemy to teach the player how to play.

- - -

This video seems rather fitting. It's demonstrates the way mega man taught the player without tutorials. This video actually changed the way I look at early stage level design.

Just a word of language, there is plenty of bad language.

Another game to look at is Half Life 2. It's opening is nothing short of genius in teaching the player to play without interfering with play.

Player's can be taught in less intrusive ways than pop up's and lengthy explanations.

Sam Stephens
profile image
That fact that you feel tutorials are a "waste of time" is very telling. Learning is a difficult and slow process. Some learn faster than others, but everyone needs some guidance. Even if you are familiar with a certain style of gameplay, many others will not be. And that was my initial argument; that those who complain about tutorials do so from a perspective relative to their own skills and abilities. Studying game design means stepping back and understanding how all players, not just one's self, approach gameplay challenges. Do so, and you will see that many need the guidance offered in tutorials.

Sam Stephens
profile image
As a side note, Half-Life 2 totally features tutorials and a slow build-up. They are not quite as explicit, but that is because Half-Life 2 is no where near as complex as some games.

Ian Richard
profile image
Requiring a player to invest time into something he has already mastered against his will IS a waste of time. That's why repeating long sections on death has gone out of style.

If a player isn't enjoying your game, I don't think anyone will call it "Time well spent". In fact... many people complain about such things.

I know that you and I won't see eye to eye on this and I'm happy to withdraw.

Sam Stephens
profile image
Again, it's not about you as an individual, it's about the entire body of players (i.e. every person on the planet). Just because you mastered something (highly doubtful as you said that you've quit games before even completing the tutorials) does not mean that others are at such a level.

Radek Koncewicz
profile image
For the most part I really liked the piece -- both its content and writing style.

It definitely sounds like you're much more interested in playing with game mechanics than focusing on an ever-increasing need for elegant interfaces (despite a certain level of fondness for DOET). Considering how many "UX" experts and usability consultants there are in the field, it also makes me wonder how prevalent new specializations in game design will become, i.e., will we start seeing job ads for tutorial planners/integrators?

Hope the manual experiment proves rewarding!

tony oakden
profile image
Particularly true of mobile games for all the reasons the author mentions. Any indie considering a mobile game should read this article really carefully and take note. Producing in game tutorials is, time consuming, difficult and very frustrating for a programmer to do, but without them your mobile game is pretty much dead in the water. The more complex the game, the more effort you'll need to put into tutorials. I'd much rather be spending my time making another game. I guess that's one of the reasons I won't be doing anymore mobile games.

Brendan Vance
profile image
I could probably write another thousand words about about all the horrifying minutia that go into mobile controls. Even a problem as seemingly obvious as calculating the velocity of a swipe is something that could eat a limitless amount of time. (Should you average the last few milliseconds of signal in order to account for jittery fingers? If you make a really long swipe, should that change the way you interpret things? How much? If you change direction midswipe, is that still the same swipe? How do you determine how long a swipe has to be so that you can define 'midswipe'? Should there be a minimum velocity players have to reach in order for it to be a swipe, or is distance from the start point sufficient? (If it is, how much distance should you use? If it isn't, what should the minimum velocity be?) What is the deadzone of a swipe, and is it worth applying when the player hasn't tapped on some interactive thing that would be selected assuming she does not begin a swipe? Etc, etc, etc.)

I have spent entire days trying to reproduce the exact dynamics of iOS's native swipey components. I often wonder how long it took those folks to produce them in the first place.

Ara Shirinian
profile image
The essential problems with "interactive tutorials" as most commonly realized can be expressed as a result of a combination of factors:

1. Teaching the player how to play is usually one of the last things developers prioritize.
2. Overall development resources are frequently overstressed, so developers have no time to do these the right way.
3. Explicit tutorials end up being developed as standalone modules that separates 'game' from 'not game,' instead of weaving teaching into the intrinsic design of the game (and without belaboring the player), because that's harder, takes longer, and requires a lot of expertise.
4. Unfortunately there remains a wrongheaded culture pervading this industry that believes that the most accessible and effective way to teach something is to restrain the player and then make them read.

Robert Green
profile image
Regarding your #3, one time it can get tricky is for sequels to fairly complex games. I haven't played Assassin's Creed 3, but from what I've heard, it shows off the worst-case scenario, which is a several-hour long linear tutorial that even players who have spent 100 hours in AC games before have to go through before the game opens up and allows players the freedom they likely want from the series.
At some point, a separate 'quick summary tutorial' starts to look quite appealing to many gamers.

Andreas Ahlborn
profile image

Just debunking this myth, that I keep reading and reading again: one of the first reviews of AC3 criticized the "overly long" introduction, and it is indeed the fact that one of the core mechanics (naval combat) is introduced almost 4-5 hours into the game.

But in no way is this exposition a several hours long tutorial, every now and then when you need to perform a new move some short info is popping up on the screen.

I think the problem some of the veteran-players had, that they couldn`t immediately jump into the tree hopping and frontier exploration they craved for and were overly critical of the time this game took to grant them the freedeom of a true open world game (as you pointed out).

I my self am not a huge fan of this intropduction (its certainly one of the weaker parts of the game) but in the context of the story I find it kind of necessary because it shows the character development of one of the main figures and has a certain intersting twist (which I won`t spoil here)

Robert Green
profile image
It's true that the whole thing isn't a several hour long tutorial, but it IS what Ara is suggesting - a tutorial integrated into the game. When you combine the number of gameplay mechanics that the game wants to teach you with the desire to let the player experience each one properly before moving on, plus the narrative elements weaved in, what you end up with is a several hour long linear section of gameplay.
In some games, that's fine. For a metroid-style game, it's assumed that you'll be unlocking new abilities at key points in the game and you can be taught as needed. I guess the real question is this: "is exploration/freedom a key selling point of my game, and if so, how long before I give players that freedom?". I've heard Final Fantasy 13 takes a dozen or more hours.

Ian Richard
profile image
I gave up on FF13 after 8 or 9 hours and I don't think I'd even unlocked all the core features. I really wanted to like that game... but it got to me.

I actually think they were going for the "Unlock features throughout the game to make it continually feel fresh" rather than "Let's make our game a tutorial". But the experience ended up feeling shallow because the game never reached that level of depth I'd expected as a fan of the series.

Sure, it may have reached the level of older games eventually... but I have things to do. If you haven't hooked me in 10 hours... I'm going to read a book, learn a language, or maybe just play a different game.

Brendan Vance
profile image
What I always liked about the Final Fantasy franchise was how pluralistic it was; yes there was JRPG combat and yes there was melodrama, but also there was stuff like exploring towns and talking to people, weird chocobo-related minigames, scouring different kinds of places for different kinds of secrets, trekking across a vast world map, the great power and responsibility of owning an airship, the charming insanity of Blitzball, etc.... It was messy and weird and inclusive of everyone's tastes, and it all managed to achieve a sense of holisticness because it seemed like everyone on the dev team was having fun together.

I feel earlier entries in the franchise have a magic in them that is more than the sum of their parts. With XIII, though, the company managed to streamline out all the things I enjoyed while accentuating two of the things for which I never really cared, and as a result I found myself no longer included in their target audience.

I know many people really like XIII so I don't intend to whine (at least not TOO much) about the game not being made just for me, but I am tempted to claim they threw the baby out with the bathwater on that one.

Wylie Garvin
profile image
I mostly play console games, and I appreciate the modern trend of games that teach players how to play them. I like modern tutorials that are gameplay-based and in-world. Yes, they take a lot of effort from the designers and developers, a lot of iteration to get right. There's an opportunity cost for sure, but I'm far from convinced that all of that effort spent on modern tutorials is wasted. Even with decades of game-playing experience, I still enjoy a well-crafted tutorial that helps acquaint me with the controls and important mechanics. Even if 80% of them are equivalent to something offered in another game I've played before, having that orientation is helpful. Even for a game I've played before, I tend to start a new game (and do the tutorial) if it has been several months since I last played it. Only after I'm reacquainted with the controls and key mechanics do I load my old save game and continue. We want players to enjoy their gameplay experience, which can be severely hampered if they don't know about or remember certain controls or mechanics. Manuals are a cheap solution to this problem (or might be if players were actually willing to read them). Accessible tutorials are a much more expensive solution to the problem, but a vastly better one too.

Here are my three biggest complaints (about bad tutorials):

(1) Tutorials that can't be skipped or disabled somehow. If you're replaying a game for the 3rd or 4th time, being forced to endure a 20-minute-or-more tutorial is really annoying. Just give players the option to skip it. If its longer than 5 minutes, consider letting them skip individual sections too. Or do it like recent Assassin's Creed games: chop the tutorial up into lots of separate scenarios, one for each mechanic you need to teach, and give players access to them all from the menu at any time. Bonus points for letting the player go as slow or as fast through the tutorial area as they want to (or can).

(2) Tutorials at the beginning of the game that teach mechanics you'll never use until halfway through the game. This is just lazy. Teach mechanics to the player shortly before they first need to use them. Its nice if they are allowed to use them before that point too, but don't try to *teach* a ton of stuff all the beginning if they don't actually need it yet. Should do it like the Zelda games (for each dungeon you have a new item or weapon, and encounter obstacles where you learn how to use it while not under stress, then the mechanics of the boss at the dungeon's end usually requires you to use that item or weapon several times to defeat the boss). Or like Okami (each time you get a new brush technique, a brief non-skippable tutorial forces you to draw the new glyph correctly, twice I think).

(3) Tutorials that are too abstract, or interrupt the flow of the game too much. If you can teach game mechanics through in-game events, that is WAY better than pausing the game and popping up a dialog box full of text. A good tutorial progressively introduces mechanics and controls and tests that the player understands them, while *simultaneously* introducing story, characters, dramatic tension, etc. Consider the first 15 minutes of Halo 1, where the Covenant attack and Master Chief has to run through a battle-torn ship before he even gets a weapon. Consider the first 15 minutes of Deus Ex: Human Revolution, where Sarif Industries comes under attack and Adam has to respond, and *ignorable* tutorial videos are offered to the player as each tutorial obstacle/teaching moment is encountered. Consider the tutorial level of Dark Souls! [grin]

Sam Stephens
profile image
Very good comment. It shows that tutorials can be very useful for some people and a hindrance when they are poorly designed.

Brendan Vance
profile image
These are good points. I think it is probably inevitable that the most popular games of the medium will spend vast amounts of effort on teaching, and this is probably a good thing! Accessibility has many advantages. I just want players and developers alike to think very carefully about the ramifications of making those choices, and to open their minds more to other kinds of games that make different ones.

Dark Souls is, as always, a really interesting example here. It does include some semblance of a friendly introduction to its control scheme (insofar as anything in Dark Souls can be described as 'friendly'). Much of the time, however, it makes very bold choices about what NOT to explain to the player because it expects her to investigate and experiment and pay attention.

For example, there is no friendly blacksmith hanging out at Firelink Shrine who is going to tell you ALL ABOUT how to upgrade your weapons and armour by giving you a starter piece of Titanite and a little quest to upgrade your brand new straight sword to +1. Including such a friendly blacksmith would probably damage the game's tone and diminish the impact of arriving at Firelink and meeting your new best friends Petrus and Crestfallen Warrior.

It's important to remember, I think, that teaching somebody how to move around or execute a weak attack is hard to make into a convincing artistic statement; there are only so many ways to dress it up and sophisticated players can spot them from a mile away. (See: Amnesia as GROOOOOOAN NOT THE AMNESIA THING AGAIN.) This is why most films do not see fit to begin by gradually introducing the viewer to the idea of camera cuts through a character who has miraculously gained the power of teleportation.

Robert Green
profile image
I wonder how much of the focus on UCD comes from focus-testing among people with no investment in the game. If you perform usability sessions, where the goal is to have the players all intuitively understand what's happening, then that's what you'll ideally end up with. But if the player had just paid $60 for a game, they're not going to walk away from it in 5 minutes just because they couldn't figure out how to open the first door.
Of course now that most games have no such buy-in, and no physical manual, maybe that's all irrelevant.

Brendan Vance
profile image
Yes. At a certain point it becomes absurd to try so hard to compensate for someone's lack of investment in your work. And as a person who cares quite a lot about the games I choose to play I don't often enjoy it when they cling to me like those hawkers at the mall who sell nail maintenance products.

Jakub Majewski
profile image
I think one of the big problems with tutorials, the reason why players hate them so much, is that they are infuriatingly redundant and ruinous to the pacing.

Gamer literacy has not gone away. In spite of our best efforts as game designers to deprive the players of any need for thought, players shockingly enough continue to think independently. Even more shocking, they don't only think, they even remember. They go into our game remembering not just what they did five minutes ago, but even what similar games they have played in the past few months. Sometimes, even the past few years.

So, the player enters your brand-new first-person shooter. He knows, just from the back of the box (or the online description) that this game is about walking around and shooting stuff. He has even figured out that the enemies will shoot back at him. Well, what about figuring out the controls? Well, it so happens you (wisely) cribbed them straight from whatever other FPS had been most successful recently, which in turn had done the same with regards to a previous game: in short, you have the standard controls that everyone uses.

By the way, did I mention that your marketing department has spent months trying to figure out how to get the message across that your FPS is exactly the kind of thing an FPS player will enjoy? It might sound like a daft, blindingly obvious thing to say, but just think about the implication: your company has gone through a heck of a lot of effort to ensure that the game will be played by people who have already played other FPS games, and therefore know the standard FPS controls.

So, the player goes into your game both knowing what to do, and how to do it. He wants to enjoy a fantastic game that, like a Hitchcock movie, starts with an earthquake and then just gets more and more intense.

Instead, he gets a tutorial.

In my career as a games designer, I have time and again butted heads over this. I come from a film background, I wrote my Master's thesis comparing film and game narrative - so to me, it always seemed very important to make sure that the first five minutes of the game are as intense and representative as possible, because just like in a movie, it's those first five minutes that get your attention. And I have simply never succeeded! It just seems impossible to get this across. You spend hours telling your bosses why a tutorial is unnecessary, why it just slows the pacing down and ruins the game opening: no, they want a tutorial in there just in case. Last time (an air combat game called Dogfight 1942), I figured I'd try a different tack: they want a tutorial? Ok, I'll give them a tutorial, but I'll pack it with action. I'll set the player up to fail, and when he does, we'll pat him on the back and make it clear that his failure is expected. He won't get angry over the excessive difficulty, but he'll be piqued enough to immediately click the "next mission" button to assuage his wounded pride. The next mission, of course, was nice and slow-paced - now that the player had been shown all the game had to offer, we could afford to slow down and gradually build up again.

No dice. First, I struggled for months to keep everyone focussed on how this was supposed to work: the moment I turned my back, somebody would say "yes, yes, it's nice that it's so intense, but this is supposed to be a tutorial, we need to slow the pacing down". Then, at the very end of the project, somebody further up arbitrarily decided to simply replace the existing tutorial with a new, excruciatingly boring one.

I don't know if my idea was a good one. The tutorial mission we had sure was exciting, but who knows - maybe the players would ultimately not appreciate being put in a situation where they are doomed to be shot down in the very first mission, even though the cutscene afterwards makes it clear that they've bailed out, and it's all exactly as expected. What I do know is that the replacement tutorial was a boring piece of junk that simply eviscerated the game opening, making it feel like the game itself is boring. Given how many players don't bother playing longer than the first 20-30 minutes of a game - I know that for far too many people, we never got a chance to show that deeper in, things get more exciting. On top of that - while I'm aware that the game had far too many flaws, and would not have had great reviews either way - I can't help thinking that reviewers also marked down our gameplay specifically because that first tutorial mission, combined with a couple of slow-paced missions that followed, set them up to assume that our mission design in general was boring. First impressions are a bitch...

Brendan Vance
profile image
It is definitely true that the metered pace of heavily-tutorialized games can do significant damage to their tone, especially in the early going (and ESPECIALLY for sophisticated players). And I too find it distressing that we developers face pressure to both adopt the metaphors, control schemes, tropes, etc of other popular games while ALSO pretending the player has never seen any of them before. To me that is greedy design.

Ian Fisch
profile image
Sorry but I generally disagree with your post. I don't think figuring out the basic rules of how to play your game is the kind of discovery that makes great user experience.

Look at Xcom:Enemy Unknown. It's a very deep game, and there's plenty to discover, but thanks to thousands of smart design decisions, it's easy to learn to play.

Was this time consuming for a designer to create? Probably. But the time of one designer saved tons of time and frustration for tens of thousands of users.

Jason Withrow
profile image
I generally agree with yours. I've spent much a discussion about tutorials lately sharing this anecdote about Egoraptor's famous praise of Mega Man X's silent tutorials: when I first saw MMX being played, the older kid who had the game could not work out wall climbing. Neither could his sister, his friend, his other friend, me, or my brother. Jumping up against a wall just doesn't make _sense_. We kept restarting and trying to get out of the hole before the floor fell, as I recall, assuming the drop was a dead-end trap (we'd played games from the 80s, we knew how this worked. We out-thought the tutorial, and were punished for it). What the internet remembers as an elegant triumph of the non-tutorial, I remember as the moment that stopped a game dead for five semi-experienced child gamers and ruined an expensive rental.

I feel these basics are really just basics to be overcome. "The time of one designer saved tons of time and frustration for tens of thouands of users," exactly. Games may be "fundamentally artistic" but if that artistic experience is gummed by a failure of design, it becomes a failure of artistry as well, especially if the artistry never occurs because you're stuck in a pit in a futuristic highway!

John Flush
profile image
You have just described everything Apple does for me. It took me a while to get use to Apple UI because it wasn't natural from a person that actually knew how to use a computer. It wasn't hard to figure it out though, if you don't know what to do, hold the button or smash all your fingers on the device in frustration... viola Apple products.

If you think about it though, that pretty much describes the non-technical response from humanity when interacting with technology so the design clearly appeals better to the masses, thus why it has been adopted so widely. Eventually though the masses will realize they would like to get to more features faster and we will start complicating the design again. I look forward to that day.

Andreas Ahlborn
profile image
Highly amusing and insightful article into the oversimplification excesses the games industry is guilty of !

Colm Larkin
profile image
I have been inspired to create a manual instead of a tutorial for my upcoming game thanks to this!

Side note: I think having a manual will be a selling point!

Douglas Scheinberg
profile image
Ultima used all 26 letters? That's nothing! Nethack has almost four times as many commands, thanks to the magic of the Shift, Ctrl, and Alt keys - and also uses the punctuation marks, too! And although there is indeed a list of what every button combination does, the value of such things as the "sit" command is left for the player to discover. ;)

Douglas Scheinberg
profile image
Nowadays, it seems that players often write their own manuals and put them up on