Tutorials 101 - How to Design a Good Game Tutorial - Extra Credits

We've talked previously about how a good tutorial is integral to being able to deliver a deep, rich game and still reach a large audience. Today, we're going to talk about how to actually put one together. While the specifics vary from game to game, there's a few simple rules that pretty much every game should be able to follow. Number one, less text. Text is a terrible way to deliver a tutorial. It kills pacing, it destroys immersion, and it'll often be skipped by the very players that need the tutorial the most. Like everything else in games, your tutorial should be interactive. The player should play through the actions they have to learn. This not only creates a better experience for the player, but it also ensures that they actually understood what the tutorial was trying to convey, as opposed to text or even in-game cinematics where, once they end, you have no idea if the player actually understood what you meant. Number two, don't front-load your tutorial. Many game designers seem to think that they need to deliver every piece of information the player will ever need right at the beginning of the game. Any first-year teacher or HCI

student can tell you how bad an idea that is. Yet, somehow we manage to forget it all the time when building games. If you front-load your tutorial and teach the player everything at the beginning, they'll be overwhelmed with information and under-supplied with engagement. Throwing so much information at a player right away means they're likely to have forgotten a lot of what you taught them by the time they need it. It also means that they might very well get bored with your tutorial and either start rushing through it, skip over it entirely, or simply turn the game off in disgust. If a player skips your tutorial, you've failed as a designer because you've wasted resources making your game less for the player. Instead, you should provide the player with information as they need it. Introduce gameplay elements as they become important. If you do this, the player gets to start playing faster. It allows you to give them information in digestible chunks, and it means that they'll get to start practicing what you taught them right after they learn it. Remember that this goes for all the parts of the game, not just the commands the player will input. If there's a UI element that they won't use right away or a menu that won't do anything for the first 30 minutes of the game, don't clutter up the screen with it. The less info you throw at the player from the outset, the better. And when you do introduce new UI elements or commands,

it'll be even easier to make the features you're introducing glaringly clear. Because there really can be little confusion about what's being introduced when a brightly highlighted compass or a mini-map suddenly slides onto the screen. Number three, make the tutorial fun. All the time in this industry we trumpet the fact that people learn better when they're having fun. And somehow we seem to forget this fact when we build our tutorials. Your tutorial should be exciting and interesting. They should be as engaging as any other part of the game. Now, this is hard to execute on, but vital. For most games it's necessary for at least some of the tutorial to happen at the very beginning. And like with books and movies, humans are prone to snap judgments about their entertainment. If you can't grab the player in the first 10 minutes of play, you're going to lose a large part of your audience. And the whole point of the tutorial was to make your game accessible to more people. Here you simply have to remember to use all the things that make the game play you're teaching fun in the first place, and then make it fun in the tutorial, too. The Modern Warfare training missions, basic braining in Psychonauts, the City of Heroes intro mission, and the Death Knight starting quest chain in World of Warcraft, all great examples. The best example of this is, of course, Portal, which was 90% tutorial, but was so much fun that none of us seemed to notice. Number four, reinforce learning

through play. Going along with making the tutorial fun and distributing the tutorial throughout your game is the idea of reinforcing the things taught in the tutorial by highlighting their use in gameplay. You don't want to make this hammy or overly telegraphed, but you need to help the player understand how to apply the tools they learned about in the tutorial during actual gameplay. Again, if you can make your tutorial feel like gameplay, or better yet, simply be gameplay, this should mostly solve itself. Number five, listen to your players. Your tutorial is probably the most important thing in your game to play test. When you're a designer who's been working on a project for a year or two, it's very easy to think that things are intuitive or obvious that are actually totally incomprehensible. When you build a system and spend eight hours a day with it, it becomes second nature. And that's great, but it often blinds us to what needs to be taught. Case in point, James was once brought in on a consulting gig for an RPG-esque PC game. As a designer, one of the first things he always does is press every button. But after about 15 minutes of trying, he couldn't figure out how to open his inventory, so he had to ask. The answer? Triple-click the player. After years of working with the system,

no one in the company even thought twice about it. Here, simple playtesting is the answer. As always, don't talk to your players. Watch where they get stuck. Watch what they have trouble with, and then listen to what they say to you. After that, then you can ask questions. Additionally, be mindful of your demographic. It's very hard to get past our own personal perspective, and so sometimes we forget that things that seem second nature to us might not be to everyone. For example, James recently had an astute young designer come up to him shocked by the realization that the young end of the demographic he was working with might not be able to read yet. Luckily, with quick thinking and dedication, he was able to work around this one and deliver a tutorial that any age can use. But, you'd be surprised how many senior game designers forget similar things. For all you beginning designers, the most common one to forget is that not everyone might be familiar with the conventions that you're used to. Using WASD to move? Better make sure your target audience is used to that, otherwise you're going to have to teach them. Lastly, there are two more simple tips to remember. One, tutorials should be skippable or shouldn't interrupt the flow of play. You don't want to have to force everyone to sit through your tutorial every time they start the game again. Two, anything conveyed in a tutorial should be accessible at all

times. It doesn't have to be in any deeply immersive fashion, but simply putting a help encyclopedia in the options menu or giving the player access to how-to videos from the pause screen will go a long way. After all, we've all come back to a game after having put it down for 6 months and forgotten how to do that one stupid thing. And if you can't easily go back and refresh yourself on how to play, you're going to put that game down again and probably not buy the sequel. But, for all this, reason that tutorials seem haphazard and in many cases just inadequate, boring, or terrible isn't because most professional designers don't know this stuff. It's because often the tutorial is left as one of the last things to be completed in the development cycle. And how can you distribute the tutorial through gameplay if all the game play is already built? How can you make sure your tutorial is fun if you're scrambling to get the product out the door? Simply put, as a designer, you have to think about how you're going to teach the player to play your game as you're building it. If you don't do this, if you don't consider the communication problems that are inherent in every complex decision in your game, you'll deliver a clunky front-loaded tutorial at the last minute and really take away from the player's experience. It's not something that's hard to do and it doesn't actually cost any development dollars. It just takes discipline.

Discipline to always be mindful of how you're going to teach the player as you build the play itself. Because every game is an education. Every game brings us to worlds we've never been to and throws us into situations we don't recognize. Every game asks us to translate between some series of button presses or clicks and actions happening on a screen. So every game requires a tutorial. And if you're mindful of this and disciplined in your design, you can create the best tutorial there is. One that no one remembers is there. See you next week. Woo!