We all know that designing the tutorial is often left until late in a game’s development cycle – which frequently makes good sense, as the game designers will probably have the best idea of what the player will need to know to tackle the game at that point. However, it can mean that the tutorial can sometimes be treated as sort of an afterthought, and hurriedly thrown in at the last minute to meet the deadline.
Games with patronising, boring, indecipherable, or otherwise terrible tutorials aren’t exactly in short supply – so what makes a good one? Let’s have a look at some pointers.
Hide the fact that it’s a tutorial
Let’s face it – learning is boring, at least in the context of sitting down to play a videogame. Even people who love to learn are probably not that interested in being educated when they just want to shoot some aliens.
If you’ve played more than a few videogames in your time, you’ve probably endured an innumerable amount of ho-hum tutorials that treated you as if you didn’t know how to hold a controller, or bombarded you with lifeless and overstuffed informational textboxes that you couldn’t be bothered to read.
The average gamer has grown to dislike conspicuous tutorialising, because it is often done so badly – and so the mere phrase “tutorial level” brings with it a gentle but ever-present association of “boring, time-wasting level that you probably can’t avoid doing.”
This is perhaps something of an abstract concept, but I believe that unambiguously labelling a tutorial segment as such often implies to the player that it is
- Not a part of the main game, and therefore not really important.
- A mostly educational and therefore not terribly interesting chore you have to do.
- Likely to either be patronising (in a game that the player perceives as fairly simple) or dry and informational (in a very complicated game).
- Unimaginative – couldn’t the designer think of any creative spin at all to punch up the game’s opening segments?
Zelda: A tutorial level presented well
It wasn’t until I heard someone describe the Great Plateau in The Legend Of Zelda: Breath Of The Wild as the “tutorial area” that I actually realised that that’s what it was.
Well, perhaps I’m just slow on the uptake. After all, every Zelda game for the last twenty years has had a pretty clear and conspicuous training area, and if I’d been thinking about it, I would have assumed that Breath Of The Wild would, too.
However, in my defence, the game does many things to disguise the nature of the tutorial space. For example:
- The area is very large, and the boundaries are presented in a way that makes intuitive sense – you can’t leave the area because it’s hundreds of feet above the main map, and you’ll die if you jump off. In other words, there are no clumsy solutions like invisible walls or characters who stop you at the edge of the training area and say, “Don’t you want to talk to this character we already told you to talk to earlier and get this vital item that you’ll need for the rest of the game?”
- The game leads you to believe that the scope of the area is even bigger than it actually is; the famous, stunningly rendered vista when you first emerge from the starting cave bashes you over the head with the game’s epicness and scale, and it isn’t until somewhat later that you realise that you can’t explore all of it right from the get-go.
- It’s very long and full of content – it’s common for new players to spend several hours exploring, foraging, fighting monsters, and unlocking abilities, which makes it seem more like a game world in and of itself than a purely functional area designed to prime you for the game proper.
- There is very little conspicuous tutorialising (especially by the standards of prior Zelda games), and that which is there is spaced out over the rather long duration of the tutorial. A large portion of what the player actually learns is via experimentation and good old trial and error.
There are many more ways this game obfuscates the nature of its tutorial area – such as the mini-tutorials within the tutorial, as in the segment wherein you can’t progress to the snowy area without first learning about something that will help you – but I’m conscious of turning this into a post that simply talks about nothing but Zelda.
The point I’m trying to illustrate is this: really great tutorial levels are often presented in a way that doesn’t make you think “tutorial level”, and that by teaching the player the ropes in a way that is subtle and flies under the radar you can sometimes avoid that groan-inducing moment of “having to do the tutorial.”
Employ skill gates in your tutorial
Some games do a tutorial thing that makes me really cross – they’ll tell the player how to do a thing, and then essentially lock the game’s progress until they do that one specific thing (even Breath of the Wild, I’m afraid, does this once or twice).
You know the sort of thing; on-screen text that instructs the player to “press B to backflip” or whatever, and then doesn’t let them move on until they’ve pressed that button and done the backflip – even if there is no logical given reason for the player to need to do a backflip at that moment. Therefore, the player feels that it was more of a box-ticking exercise than actually doing anything meaningful.
What’s the solution? Skill gates!
A skill gate is a part of the level design that naturally and logically prevents the player from progressing until they demonstrate that they have learned a key skill.
I’ve drawn a (very simplified) example to illustrate the idea:
In this example, we need to make sure that the player knows how to jump before we let them progress – but rather than just arbitrarily withholding progress until they have successfully executed at least one jump, we’ve built a skill gate into the level.
That is, we’ve simply designed the level so that they have to jump in order to continue – and there are coins to make it clear that the player should be trying to get up there. After this set-piece, in other words, we can design the rest of the level in complete confidence that the player has grasped the concept of jumping.
Other basic examples of skill gates might be making sure the player knows how to equip and use a sword by blocking their path with an enemy that can only be moved using the weapon, or designing a tutorial for a sniper rifle mechanic where you make it so that the player has to hit a small switch from a distance in order to open the door to the next area.
For any given mechanic you need your player to learn, ask yourself: is there an in-universe, logical way we could ask them to demonstrate their understanding of the skill?
Keep your tutorial text short
Wordy tutorials, I’m afraid, are almost always bad. Sometimes text is necessary to explain complex concepts, and I’m not denying that – but there is still something to be said for keeping it short and to the point.
Let’s consider two presentations for the same idea. Let’s say that we’re trying to do a tutorial for gun reloading in a first-person shooter – we might put the following textbox on-screen:
“You’re out of bullets! You can reload your gun at any time by pressing the X button.”
It’s not terrible, but it takes a long time to get to the point, when you could just say:
“Press X to reload.”
Something that a lot of games like to do is to try to disguise all the overt tutorialising by burying it in dialogue from an NPC, and this isn’t a great strategy either. Let’s give the job of explaining gun reloading to a grumpy soldier in the player’s platoon:
“Listen up, kid! You gotta reload if you run outta bullets – that’s just common sense! You gotta press X to make sure you ain’t caught off guard!”
For some reason a lot of indie developers (but also some AAAs on occasion) seem to think that this sort of thing is better in some way, as though “adding character” to the tutorial is the magic ingredient to making it not awful.
I’m afraid it’s clutter, though. All that nonsense just detracts from the key, essential point that the player needs to learn. “Yeah, but it’s building character,” you might say – to which I’d say it isn’t, not really, because you have to break immersion to make this character start talking about button inputs, as though that’s a thing a soldier in a platoon would ever say in real life. What we’ve actually got here is just generic videogame waffle that doesn’t really add anything meaningful and just buries the essential point.
You see, you can’t really rely on players to read text or pay attention to what anybody is saying. I’m not being flippant – it’s just a fact that there will always be at least some percentage of your players who will mash through all the text boxes and not listen to the voiceovers (and then probably later wonder why they don’t know what’s going on, but that’s a different topic…).
A good designer will always strive to cater for these styles of play if they can, and that means boiling down vital information to its simplest form. You can always put all your characterisation and your world-building and all that stuff somewhere else, of course, but when it comes to teaching the players the fundamentals, it’s always best to keep it simple:
- Press A to jump.
- Press Y to talk.
- Equip the sword on the Inventory screen.
- Open your Map.
….and so on. In fact, depending on your game and your creativity, you may even be able to adopt the most elegant method of all, which is:
Avoiding text tutorialising completely
There is an old writer’s maxim, which is “show, don’t tell.” This could probably be applied to the art of designing videogame tutorials just as well.
Some older videogames, such as the original Super Mario Bros and Mega Man games, are well-known examples of this. The principle hinges on the inclination of most players to experiment – if we return to our jumping skill gate, we could remove the on-screen button prompt and merely show the obstacle to the player.
You see, most players aren’t going to react to something like this by throwing their hands up in frustration and switching the game off. It seems that they will need to jump onto the platform, and although they haven’t been told exactly which button to press, they will probably figure it out through trial and error very quickly.
Another thing to consider that these days, the chances of your indie game getting played by somebody who has never played a videogame before are probably vanishingly small. 99.9% of the people who play a 2D platformer like the example above will already know perfectly well that the A button is “jump”, because of course it is. So why use on-screen text that the vast majority of your players will think is unnecessary or patronising? Even the ones who don’t know that A is “jump” will figure it out by themselves very quickly.
Another approach could be to use text tutorials only as a last resort. Perhaps if your player seems to have been stuck on the lower platform for longer than you would expect, you could eventually put a button prompt on the screen to help them out after all – a prompt that the vast majority of players would never see. This way, nobody gets patronised, the screen doesn’t get cluttered up with extra UI elements unless they are absolutely necessary, and even those few players who are completely new to gaming and slow to learn will understand how to advance.
Using visuals to teach gameplay concepts
A lot of gameplay mechanics and concepts could be intuitively understood simply from the visual design of the game, without the designer ever having to put explanatory text on the screen. For example, here’s a post about platformer enemy design I put on my Instagram a while ago:
In my opinion, a well-designed game should be able to communicate the vast majority of the information the player needs to learn just from the graphics alone. Can your players tell which elements they should and should not touch just by looking? Does the level layout naturally seem to indicate the direction in which they should travel? Can you make hazards “look bad”? Can you make collectables look desirable?
Above is a screenie of my own upcoming game, Cornflake Crisis. Can you tell which elements are collectables, and which is a hazard?
Videogames designed with this principle in mind require much less text, because the vast majority of players will be able to intuitively understand what’s going on from their first glance.
Don’t front-load all the lessons at once
Teaching players the ropes at the start of the game can be a problem if the game has a lot of ropes.
Let’s say you’re making a fiendishly complicated RPG with all sorts of different systems – spell casting, inventory management, stamina, hunger, crafting, you name it. An impatient designer could easily overwhelm an unsuspecting player with tutorials right off the bat, and make it so that they can’t get started until they’ve grasped every system in the game.
Instead of doing that, why not spread out the lessons across the game? You can always make it so that they don’t need to know spell casting until level three, and teach it to them later. This way, it doesn’t even feel like a tutorial – the player is likely to feel that they “unlocked” the feature, and will be only too happy to learn about the new thing they earned.
In essence, you can deliver only the most essential lessons at the beginning and then purposefully withhold some elements of the tutorial until the player actually needs to know them.
Done really well, it can seem like almost the entire game is a tutorial for itself, with concepts and skills added to the player’s repertoire slowly over the majority of the game’s arc, with the final level and boss battle bringing all of the skills together for the first time – making the player feel that everything they’ve learned has led up to the big moment.
Watch somebody try to play it
If in doubt, there is no substitute for simply getting a friend or two to play your game and its tutorial to see what they do.
I must stress that this is the ultimate tip of all of those that I have mentioned today. It doesn’t matter how elegant and clever you think your design is – if real users are struggling to pick up the concepts and play, you still have work to do. This is the essential litmus test.
In customer service, they say that the customer is always right. Well, in game design I believe that the player is always right. It’s happened to me often that I’ve sat somebody down with what I’ve thought was a really nice and streamlined piece of game design, only to find they quickly got stuck or confused (and often apologised self-deprecatingly, saying things like “sorry, I’m not very good at games,” or, “I’m a bit stupid with puzzles”).
I believe the problem is never them, it’s always you. If somebody played your game and got hopelessly stuck because they didn’t know what to do, it’s not because they’re stupid, it’s because your game had a communication problem and you need to fix it.
One more thing: rule one of watching people playtest your tutorial is to keep quiet. It’s so tempting to want to give them hints, I know, but you must resist. The customers who play the finished game won’t have the designer sitting on the couch next to them, and if the game doesn’t speak for itself you’ve got a massive problem. So try not to say anything that could influence your tester’s understanding of the situation – you want to see if they can figure it out for themselves, after all.
Tutorials are a delicate art. They are often seen as a necessary evil – and perhaps they are – but a tutorial well done can improve the entire experience of a game.
Even a very complicated game can make use of some of these principles to streamline the exercise of teaching rules and mechanics to the player and make the introductory process as painless as possible.
In any case, first impressions last. Do you want your player’s first opinion of your game to be that it is boring, derivative and patronising? There are so many things that can be done to elevate the situation and offer a smooth transition into your game and its great content.
What do you think makes a great tutorial? Did I miss anything, or get anything wrong? Be sure to let me know in the comments!