Designer Mike Stout takes a look at examples of in-game training that skip the boring tutorials and teach players the rules of the game by letting them play the game.
Mike Stout (@MikeDodgerStout) is a veteran video game designer.
Whenever I try to write about training in video games, some kind of firestorm erupts around it. Inevitably every bad training segment, every inelegant technique, and every failed experiment is brought up as an example of why "training is bad, and I prefer to have my games with NO training, thank you very much!"
If you search tvtropes.org (a database of clichés found in pop-culture media) for the word "tutorial" it returns more than 10 different tropes surrounding things people hate about video game training. By comparison, I only found two articles about how much people hate downloadable content.
The saddest thing is this: That's not what I'm talking about when I write about training.
I can't have the conversations on training that I want to have with people because of this misperception.
What I mean when I talk about video game training boils down to a really simple idea that I'm sure almost everyone has seen executed well in one or more great games: If you are very clever with your level design, you can train players on how to play the game by having them... play the game.
As I hope to show, this is not a particularly new or revolutionary way of looking at training. It's also not sexy and exciting, and when it is done well, a designer's best hope is that the player will not even notice that the training is there -- which is why you don't see a lot of people trying to talk about it.
However, when done poorly, training can be one of the worst things in a game.
Before I move on, I have to mention one of the oldest game training methods there is: The Manual. For those of you too young to remember, manuals were tiny paper booklets that came with a video game. These booklets were filled with pictures, seizure warnings, and (perhaps most importantly) how to play the game.
Manuals are a pretty good way of teaching people how to play your game, but they have some obvious downsides:
They rely on the ability to read, which isn't appropriate for all types of games or all audiences.
They can be easily lost (or not sold with a used game), which leaves your players without training at all.
They can fall victim to all the same problems that in-game training can. I elaborate on those problems a little later in this article.
They add a bunch of time from the point players buys your game to the point they actually start playing. Whether in a manual or in software form, this is not desirable.
Because of these and other weaknesses with instruction booklets, game designers started trying to put training directly into the game -- sometimes with more success than others.
One thing that most games have in common is that they have rules; rules which define the bounds of the game, how it's scored, when it ends, and how the players all interact with the game and each other. If you gather a group of players to play hide-and-seek, you can't play until everyone knows who will be "IT," what the legal hiding locations are, how long the "IT" player has to count, and so forth.
If two players whip out a chess set, there can be no play unless both players know how the pieces move and what the winning conditions are. (Or whether or not you're using the "En passant" rule.)
What it comes down to is this: Somehow, the game's designer (the kid who comes up with the rules) has to explain those rules to players (the other kids).
If the first kid (the game designer) can't explain the rules, there will be no game. The first kid must train the others.
If the player doesn't know how to play your game, they CAN'T play your game.
The trail blazed by early designers is littered with the corpses of failed training experiments. Given how completely necessary it is for players to understand the rules of a game, a lot has to go wrong before teaching players how to play a game becomes intolerable to the players.
Here are a few very common (and completely reasonable) reasons I hear for why people hate training:
"Training wastes the player's time!"
Players are usually referring to incredibly long tutorials (some longer than six freaking hours), or that mandatory firing-range segment tacked onto the beginning of their favorite first person shooter. This is an immensely hate-able convention, so hating it is understandable -- it's just not what mean when I say "training."
"Training is forced on the player!"
This usually comes up when players describe a long list of un-skippable or otherwise incredibly annoying "help" that you must experience before you're allowed to play the game. This kind of thing isn't elegant or particularly player-friendly -- and it's also not what I'm talking about when I say "training."
"Training is boring!"
This exclamation usually precedes a list of forced tutorials that hold your hand step-by-step, not allowing you to learn anything on your own, explore the world outlined by the game's rules, or generally to… you know… play the game! It's even worse the second time you play, because you already know this crap and want to get to the good stuff! This is also not what I'm talking about.
"Training is insulting!"
This is usually some kind of "do you want to switch to easy mode" BS. The tone of these kinds of tutorials is condescending or otherwise assumes the player is not a reasonable human being with a mind capable of discovery. The other common occurrence is the help text that arrives after you've already been doing something for a long time. For example: "Press A to jump!" for the 50th time.
This isn't what I'm talking about either.
Ah, the shooting range – where heroes are made, not born.
"Training is aesthetically inappropriate!"
Sometimes this is really obviously inappropriate -- like when your character is a bullet-spewing power fantasy and you have to start the game learning how to point and shoot a gun at a target. Sometimes it's less obvious, and only slows the game down or breaks the flow during a part of the game where the pace should be accelerating (a.k.a. the first level).
Nope, that's not what I mean either.
"Most of the time, training doesn't even work!"
This is usually in reference to a quick "flash up the controls screen one time and never again" sort of tutorial. Other times it's about how a game will train you on something in level 1, then not make you use it again until you've forgotten how it works.
"Wait… how do I do a long-jump again?"
As you probably guessed, this is also not what I'm talking about.
"I like exploring and discovering things for myself. I prefer games that leave me alone and give me space to do that."
This feeling of exploration and space to experiment is the end result of exactly what I mean when I talk about training. If you design your levels (or content) with training in mind, you can train players by letting them play the game.
“Are you sure you have a brain? Press X to confirm” (Tutorial Parody from Far Cry 3: Blood Dragon)
I want to share one of the most famous examples of this "in-gameplay" type of training: The first two screens of the original Super Mario Bros., for the NES.
In an episode of Iwata Asks, Nintendo CEO Satoru Iwata talks with Super Mario Bros.' designer, Shigeru Miyamoto about this first screen and all the "hidden" training built into its seemingly simple design:
On goombas:
Iwata: If you play the game for the first time with no prior knowledge, you're going to run into the first Goomba and lose a turn.
Miyamoto: Right, that is why you have to teach the player in a natural way... to avoid them by jumping over them.
Iwata: Then when the player tries to jump and avoid them, there are going to be times when they get it wrong and end up stomping on the Goomba. By doing that, they learn in a natural way that by stomping on them, you can defeat them.
On power-up mushrooms:
Miyamoto: ... When you play, you encounter a Goomba right at the start and it's shaped like a mushroom. When you hit a box and something that looks like a Goomba pops out...
Iwata: You run away.
Miyamoto: Right, you run away. This gave us a real headache. We needed somehow to make sure the player understood that this was something really good…
Iwata: If you avoid the first Goomba and then jump and hit a block above you, a mushroom will spring out and you'll get a shock. But then you'll see that it's going to the right so you'll think: "I'm safe! Something strange appeared but I'm okay!" But of course when it goes against a pipe up ahead, the mushroom will come back! (laughs)
Miyamoto: Right! (laughs)
Iwata: At that point, even if you panic and try to jump out of the way, you'll hit the block above you. Then just at the instant where you accept that you're done for, Mario will suddenly shake and grow bigger! You might not really know what's just happened, but at the very least, you'll realize that you haven't lost the turn.
In these two screens, the player is (as Miyamoto puts it) "taught in a natural way" a large number of important skills a player needs to play the game.
For example, Mario begins at the left of the screen. The whole screen is empty, and the player feels safe to experiment with the controls. If the player presses A, Mario jumps in place. If the player fidgets with the controller, she learns how to run right (Mario can run left, but the camera doesn't scroll that way).
The whole first screen is engineered to let players discover the controls for themselves and the whole second screen is engineered to make otherwise difficult-to-understand game mechanics (like a power-up that looks like an enemy) easy for the player to learn by discovery.
There is a chance a player could miss all of that the first time through, but since the game starts you over from the beginning every time you die, you have to go through it again and again. Eventually it will work, and you'll "discover" these almost hidden rules.
Pudding Monsters
One of my favorite examples of a mobile game that does this well is Pudding Monsters. The first set of level designs is dedicated to teaching you the basics of the game. I've posted a picture of the first three levels of Pudding Monsters below, along with descriptions of what the player is supposed to learn in each puzzle:
Level 1
In Level 1, players learn to touch and slide a monster towards another monster. If the player slides a monster in any other direction, the monster slides off-screen and the puzzle starts over. Players also learn that when monsters collide, they combine into a single, larger new monster.
Level 2
In Level 2, players learn that there are other, non-movable, parts of the level that the pudding monsters can collide with. Doing so allows you to turn corners. This also can teach players that sometimes a puzzle requires more than one move per monster. The player can also solve this puzzle a number of different ways (moving the top monster VS the bottom).
Level 3
Taking everything they've learned from the previous two levels, the game teaches you that when a puzzle can be solved multiple ways, the designers will place "Star" tiles on the ground. If the player finishes the puzzle with all of the stars covered by monsters, you get bonus points. Notice how there are ways to get both two and three stars on this level.
Cut the Rope
Cut the Rope displays more text than Pudding Monsters, but you can still see how the level designs ramp up and train the players on basic skills, one at a time (red arrows and text are mine).
Level 1
Level one teaches the players the win state -- namely that you have to feed the two candies to the monsters (one to each) by cutting the ropes that hold them up. It also introduces you to the idea of completion stars.
Level 2
Besides falling, the first level does not demonstrate any physics to the player, so they won't necessarily know that candies can swing around while attached to ropes. This puzzle teaches them about the swinging physics of candies, and how multiple ropes effect how that works.
Players also need to learn that it's possible to put the puzzle into a fail state (which you need to reset the puzzle to find out). This is the first puzzle where that is possible (by cutting the top-left rope or the bottom rope first)
Level 3
This level introduces a lot of ways to fail, but still only presents one way to win. The primary thing this level teaches is how candies can bump into and push other candies. The first missions make it very difficult not to get all three stars. Eventually levels will introduce complications that make it more difficult to finish the level while getting all the stars, or which have multiple solutions..
One of my favorite examples from gaming history comes from the Super Nintendo game The Legend of Zelda: A Link to the Past.
The first two rooms of the Eastern Palace, the game's first dungeon, are my favorite bits of training in the whole game.
By the time the player reaches the Eastern Palace, the game is transitioning its training towards prompting the player less and letting them explore more. Because the player knows all of the basic moves by this point, mysterious changes to the controls happen much less frequently, so text prompts are not needed as often.
Whenever the designers introduce new puzzle elements within a new dungeon, the player has to learn how to interact with those elements simply so they can solve the harder, more complex puzzles later on.
Up to this point, the player has learned only three ways of opening doors: find a key, kill enemies, or pull a lever. Many of the puzzles in the Eastern Palace use two new methods of opening doors, namely hidden and obvious floor-buttons.
The puzzle concept is simple, the player needs to find the floor-button and have Link stand on it to open the door, but if players don't know to even look for a floor button, the puzzles break down and get arbitrary very quickly.
The easy (perhaps lazy and inelegant) way to train this would be to lock the player in a room with a floor button and an exit. When the player gets through the exit, lock the player in a new room with a button hidden under a pot and another exit. Once players get through these two rooms, the designer could safely assume that the player would know what they needed to know to proceed.
In this case (the first room of a dungeon) I can see why the designers wouldn't want to lock the player in. If a player decides not to do the dungeon, the designers want that player to be able to leave, roam the world, and find upgrades -- then come back when they're ready to start the dungeon.
There are also many single-room hidden areas around the game that you cannot proceed with unless you have a specific item. A dungeon with an unlocked front door and no obvious way to proceed might look too much like one of those hidden rooms, and players might give up and look elsewhere for the Eastern Palace.
A floor button under the center pot opens the center door.
Open corridors to either side confirm that the center door is the way forward.
The solution they came up with solves all of these potential problems. In the above image, the player enters from the bottom. The middle door is closed, and can be opened with a floor button hidden underneath the middle brown pot. The doors to the left and right are open, and lead up to the second screen.
If players take one of these doors, they can see the only way forward is through the platform in the center. If this wasn't there, the player might enter the room, run around a bit, then leave (thinking they're in one of the aforementioned single-room-required-item puzzles and not seeing any solution they know of to open the door).
Being able to see the way forward indicates that the solution to the puzzle must be in room 1.
In the second room, the player must step on the obvious floor button to open the next door. Because this isn't more interesting than finding a hidden button, the player must also deal with enemies in this room.
I don't think anyone makes a bad training segment on purpose. I don't think developers want a part of their game to frustrate a player -- let alone the part of their game most critical to the player's understanding and enjoyment of the whole experience.
Sometimes, though, when a game is about to ship and everything is chaotic, we have no choice but to throw in a lame tutorial, an obvious annoying help message, or something equally inelegant simply because we have no time to do something better. It happens to the best of us, and I'm not sure any game (except maybe Super Metroid) has done it perfectly. I know no game I've ever worked on has done it perfectly, as hard as we've tried.
Sometimes, despite our best efforts, the elegant training-as-level design we tried to create doesn't work -- and we must patch it up with something less desirable at the last minute.
But if you like games that leave you alone and let you discover things for yourself, this kind of training should really excite you as a player or as a game developer. Many games do this on one level or another, and when it works well it is incredibly powerful.
Knowing this and working with it is, I think, a much more productive mindset than "Man, training sucks."
You learn to play (and teach people to play) the same way you learned hide-and-seek from that kid on the playground: as a part of playing it, one rule at a time.
If you'd like a really thorough analysis of how this method of training players was used in one of the greatest games ever made, I suggest you read Hugo Bille's excellent The Invisible Hand of Super Metroid.
Also, Josh Bycer also recently wrote a post on what he calls "Organic Design" here on Gamasutra, and I'm pretty sure he IS talking about the same thing I'm talking about.
I recently wrote an article on pacing and archetypes that explains some useful tricks for achieving this kind of training (namely my ABCs trick from the linked article). By introducing and pacing mechanics the way I mention in that article, you also naturally gain some of the benefits of this kind of training.
You May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)