On tutorials, part 1

I’ve had both the chance and misfortune of working on quite a few tutorials. Scope ranges from AAA mega-productions to flash adver-games. It’s a chance because when you work on tutorials, you get to build direct communications with the players, and your work is likely to make an immediate impact on the appreciation of the game. It’s a misfortune because there are a lot of misconceptions regarding tutorials and too often, they are done too late in the development cycle. Too late at least to be as good as they could be, which is a serious misfortune because they matter so much to players.

This post is the first in a series on tutorials. This is not meant to be a guide on how to design tutorials but simply a series of thoughts – musings, really – on the subject.


The old way: Front-loading

Sometimes, a game will front-load all of the tutorial content. This means that you have to play 100% of the tutorials before you get to play the game at all. Games used to be terrible at this when I was in my twenties, a long time ago; action games (mostly) would start with a training level that felt completely detached from the rest of the content, yet you absolutely had to complete this in order to start playing.

To me, this is like the developers saying “I hate tutorials, you should too and we should all get rid of this crap ASAP.”

Unfortunately, this approach hurts the experience and, in the world of freemium games where you just have a few minutes to capture your player’s attention, this is a terribly ill-conceived solution. In the case of a story-driven game, this is counter-productive because by front-loading the skills and actions in the game, not only do you delay the player’s satisfaction, but you also rob yourself of the opportunity to keep the game fresh at a later point, through the unlocking – or even better, unveiling – of new abilities.

How much hand-holding is enough?

Some users can’t figure out anything by themselves while others hate to be robbed of the opportunity to do so. Often, as a designer, you’re asked to cater to both extremes of this spectrum.

Your typical tutorial is heavily scripted and won’t let users to do much exploration, which is great for one type of players but not the other. Typically, you want to make your tutorial fool-proof, which means that you’ll over-explain everything. The reasoning is simple: while you aggravate those who get it, you make sure that no one is “locked out” of the game.

Sill, there are ways to explain everything in details for those who need it, while respecting those who can figure out the game and would like a chance to do so.

  • If your game is deep and features a lot of interactions, have you considered breaking it down in short sequences? This way, users can choose what explanations they want.
  • Have you considered forcing all players to learn the most basic interactions, but making the rest optional? Your game could feature several tutorial levels, but only the first few could be mandatory. This works great with the previous point.
  • Does your game provide a way to easily re-visit tutorials? Some players will want to try something by themselves, but will later try the tutorial if anything is still unclear.
Tetris Galaxy tuto screenshot

The Galaxy mode of tetris brought so much newness that the tutorial had to be broken down into very small bits

“I’m sorry but I gotta go!”

I won’t name any title here but I’ve seen tutorials that could take up to a whole hour, with the only save point at the very end. You don’t want to put your players in a situation where they’ve played 45 minutes of tutorials, they have to stop for whatever reason, but they don’t know if doing so will delete their progress. This is another case for breaking down your tutorial into short bits. Not only do they let players learn your interactions and skills in a more controlled manner but you give them control over the pace at which they do so. In some cases, this control will let them answer the door or cook diner.

Soon, on ex Ludis …

The next part will talk about an ideal approach, and why it’s not always applicable.