The Designer's Notebook: Eight Ways To Make a Bad Tutorial

[In his latest Designer's Notebook column, veteran Ernest Adams takes a frank and factual look at in-game tutorials, explaining exactly what games do wrong so you can make sure that, when you set out to create your tutorial, you do it right.]

In the early days of the game industry there were video games (console or arcade) and home computer games. Video games threw you into the deep end of the pool: you faced an onslaught of enemies with minimal instruction and you either sank or swam. Mostly you sank, which is how arcade games made their money.

Computer games were more complicated than arcade games, so they gave the players manuals to read before starting to play. These days we don't expect players to read manuals, so we give them tutorials instead. Tutorials introduce the player to the user interface and the gameplay. They should explain how the player interacts with the game world, what she's trying to achieve, and (briefly) why.

Recently I had the privilege of serving on the jury for the Extra Credits Innovation Awards, which meant that I had to play -- and therefore, learn to play, several games in a hurry.

One or two had tutorial modes so bad that I decided we'd better talk about them. Bad manuals and/or bad tutorials are already Twinkie Denial Conditions, but the Bad Game Designer, No Twinkie column in which I introduced them didn't go into much detail.

Tutorial modes exist to teach the player, and game designers are not natural teachers. We're used to creating challenges, not explaining principles. Throughout most of the game, the players are expected to learn things on their own through observation and experimentation.

As Raph Koster has pointed out, much of the fun of gameplay come from learning to master the game, but this process is inefficient. The tutorial shouldn't be like that. It should tell players what to do and show them what happens when they do it. It should let the players master the basic elements of using the software -- guiding them into the shallow end rather than throwing them into the deep end. But as I recently discovered, there are a lot of ways to do it badly. Here are a few.

Force the player to take the tutorial. Whenever the player starts the game over, make him go through the tutorial again. Do this even if he has played it a dozen times before. Bore him with explanations of things he already knows. Irritate him with tiresome trivial challenges. Waste 10 or 20 minutes of his time before he can get to the fun part.

Games often include unavoidable tutorials because the tutorial also constitutes the first level or two of the game. There's not much harm in this if the player can turn the game's advice off, or interrupt it. But making the player struggle through a swamp of information he already knows is tedious and annoying.

The simplest way to resolve this is to put the tutorial in its own optional area, separate from the rest of the game. It works for many game roles. Soldiers, athletes, pilots, and for that matter, kings and city planners all go through training phases before they start their real work. If you really want to build your tutorial as part of your main game, make sure the player can turn the teaching elements off and just play straight through.

Square Enix's Nier

Make the player read a lot. Give the player screen after screen after screen of introductory material to read, with nothing to do but press a button to move from one to the next. Write it in faux-medieval language full of anachronisms, or worse yet, as the monologue of some tiresome mentor character with a lot of irritating verbal mannerisms. ("The A button swingeth thy sword! Essay it now. Aye, 'tis well done.") Display it all in an ugly typeface that was originally intended for headlines or poster titles, but never for large blocks of text.

I once played a Japanese game whose tutorial mode consisted of ten solid minutes of pressing a button to move to the next screen of text. Of course, by the time I reached the end I had forgotten half of it. Players will remember much more if they learn by doing.

While I'm at it, don't make the player read huge amounts of back story, either. The opening crawl of the first Star Wars movie takes one minute and 14 seconds, from "It is a period of civil war" until "restore freedom to the galaxy" fades off the screen. If that was enough for George Lucas, it's enough for you. Let the players learn the rest from context.

Describe buttons and menu items badly. You can make your tutorial mode even more irritating by including references to a button without identifying it clearly. For example, say "Press the Sell button in the upper left of the screen" when there are five different buttons up there and none of them labeled Sell. Similarly, tell them to choose menu item X when no menu item X is visible. Put the actual menu item X down a level or two in the menu tree with no instructions about where to find it.

Buttons with icons on them take up less screen real estate than text does, and they don't have to be localized as much, so they're generally a good idea. However, the player needs to learn what the icons mean and what the buttons do, and the tutorial should teach this.

When your text refers to a button, highlight the button on the screen at the same time – put a golden glow around it or something, and make it pulse or flash.

If you refer to something down in the menu tree, be sure to indicate the whole path. Don't say, "You can find it on the Graphics tab of the customization menu," say "Select Help > Preferences > Customize and choose the Graphics tab." This might seem obvious, but you would be surprised how few games do it!

Leave steps out. Get partway through a step-by-step tutorial and then suddenly stop giving the player instructions. Leave her on a game screen full of buttons and menus with no idea what she's supposed to do next. After she has hesitantly tried something, suddenly start giving instructions again without any reference to what she just did.

Some tutorials need to be more thorough than others. The more unusual your game, or unfamiliar its subject matter, the more you need to explain things. I'm not objecting to limited tutorials here, but to a tutorial that starts out with a detailed explanation and then suddenly disappears. Whatever level of detail you choose, maintain it throughout.

Punish the player's inexperience. When the player makes a simple mistake, go back a long way and explain everything again in excessive detail -- or make the player go back a long way. You can drive his frustration level up by punishing small errors with long delays.

When I'm trying to learn how to jump in a game, one of the things I hate most is falling down a long chasm that takes me two minutes to climb out of before I can try the jump again. This is bad enough in normal gameplay, but it's inexcusable in a tutorial mode. When a player fails at a jump, or any other physical challenge, she should be able to try it again immediately.

One of the games I played for the Innovation Awards had a tutorial in which you actually lose the game! It wasn't very clear about what I was trying to achieve, but I tried to do what it told me to, and at the end, it said I had lost. I can hardly think of a more discouraging start to a game. Completing the tutorial should have give the player positive emotional rewards. If the player fails at the tutorial, then clearly the tutorial itself has failed.

Patronize or humiliate your player. Tell the player "Very good!" in an overly chirpy voice when he has successfully managed to find and press the Enter key. Do it every time he does this. Praise him as you would a four-year-old who has just learned to button his own shirt.

Alternatively, humiliate your player when things go wrong. Tell him what a loser he is. New players love being harshly criticized for not knowing the very things that the tutorial is there to teach them.

This doesn't require much explanation. The emotional tone of a tutorial should be positive and encouraging without being condescending. As in the rest of life, constructive criticism is useful, but abuse is not.

Force the player to complete the whole tutorial. It's possible that partway through your tutorial, the player will feel that she's got the picture and is ready to go ahead and start the game. Oh, no. Not a chance. You put a lot of effort into that tutorial and she is going to have to finish it whether she likes it or not. After all, it's your game, not her game.

If you have a separate tutorial level, let the player quit it and move on. If your tutorial is built into your ordinary level progression, let the player turn off the tutorial elements.

And finally...

Don't give them a tutorial at all. Devise what you think is an ingenious and totally intuitive interface, preferably without a HUD or any on-screen indicators that would prevent the players' complete immersion into your brilliant universe. Make it so transparently obvious that no instruction is needed. Throw them in and wish them luck.

One of the games I had to judge for the Innovation Awards did exactly that. The UI left me nauseated -- its 3D first-person view weaved drunkenly around, apparently in an effort to convey the notion that my avatar was feeling sick and disoriented.

It worked; before long, so was I. It also took me five minutes of experimentation with its supposedly intuitive user interface just to figure out how to open a door.

The totally intuitive user interface has been a holy grail of human-computer interaction for decades now. I'll be blunt: there's no such thing. Unless you're making a computer game about using a computer, the machine's input devices are unlikely to correspond to the real-world activity that the game simulates.

I worked on Madden NFL as far back as the Sega Genesis days, and I can tell you that choosing a play, then snapping the ball, passing it to one of several receivers, catching it, and running with it are not trivial with three buttons and a D-pad. We did it very successfully -- but we still had to ship a manual with the game. There wasn't room for a tutorial in a Genesis cartridge.

The arrival of the Wii controller and more recently the Kinect has moved the issue to the foreground again, and some people are very excited about the possibility of Minority Report-style interfaces. These folks have forgotten -- or probably never knew -- why the computer mouse was invented in the first place. Touch screens are tiring to use for long periods, because you have to hold your arm up all the time. Waving your arms around, as in Minority Report, is even more tiring. It might look very swishy and cool, but you can't do it for hours on end.

Players don't need a tutorial as much if they have specialized gear, of course -- a high-end joystick for flight simulators (but they'll still have to press a key on the keyboard to lower the landing gear), or the DK Bongos for playing Donkey Konga. But you can't count on the player owning these devices unless you ship them with the game, and that means he still needs a tutorial or a manual for his ordinary controller.

Put simply, your user interface must map the machine's controls to game-world activities, and somehow, somewhere, you're going to have to explain that mapping. And your interface almost certainly isn't as intuitive as you think it is. You've been playing your own game for months or years, so it's second nature to you, but your players are new to it. They need a tutorial. Really.

Conclusion

Some of you might have noticed that this isn't very constructive criticism. I have identified a number of things not to do, but I haven't told you how to create a good tutorial. That's because it's hard to create general rules for a medium as diverse as ours is. A tutorial for a shooter game will necessarily be very different for one from a construction and management simulation. The best positive advice I can offer that covers all the cases is, be sure you try out your tutorial on complete novices -- and your game too, for that matter.