This is part two in a series dedicated to musings on the craft of creating in-game tutorials. Part 1 can be found here.
It’s not always easy to break down all of a game’s skills into individual “lessons”. You have to make a lot of trade-offs.
First, there’s the granularity of your tutorials. You probably have to teach some very basic skills, because there’s going to be a minority of players who never held a controller before. Yet, you don’t want to bore or even insult those who are very gaming literate. If you have to front-load the tutorials (see the previous post), you have to strike a delicate balance because your audience wants to be taught everything, yet they want the very opposite because they would like to be over with it ASAP, and start playing the game for real.
Then there’s the actual test. You can’t let players go forward if they haven’t mastered the basics but you don’t want to fail them mere minutes into the experience.
But one general rule applies: Players would rather try to learn by themselves, if it’s reasonably doable, instead of being told what to do. In the end, if this works, players will end up feeling better about themselves, which is probably the subconscious reason why they buy games in the first place.
No matter how many tests of skills you put across our players’ paths, some simple rules can help you make this a painless experience:
- Try to create setups with clear goals. Everybody likes to be able to gauge their own success. “Try to survive as long as possible” will not work as well as “You have to survive another 2 minutes”
- Show obvious means to succeed. Don’t create a test of weapons skills in an environment that looks like a pathfinding puzzle.
- Try to create setbacks instead of failures. Failing to jump across a chasm should bring you back to the jump off point, not kill you outright. You’d be surprised how focused – and even obsessive – players can become in situations where they can hone their skills.
- If your game has a scripted story, try to make the tutorial fit in the fictional world. The tutorial feels less like a chore if it’s going to bring you towards some form of closure, not pull you away from it. Why do so many games make the protagonist a victim of amnesia? They tried to do just this but I guess they ran out of ideas after the first one.
Now some games do this well and even push this all the way to its next logical step, which is exactly my next point.
Tutorials indistinguishable from the rest of the game
Everybody’s favorite implementation of a tutorial – or at least, everybody with whom I’ve talked about this – is to have them embedded seamlessly in the story and in the game world. You learn one skill, it makes sense to learn it at this point, then it gets challenged, and the story moves forward. You learn another skill, it gets challenged, then both skills are challenged together. And so on, and so on, always in a fashion that fits within the narrative. Usually, in these games, you get new skills and new gadgets all the way to the very end because this represents the high-level loop that drives the long-term motivation.
Examples that come to mind:
- Half-Life 2
- Super Mario Galaxy
- Zelda (pretty much the whole series)
(I know my examples all come from Valve and Nintendo. Others do this as well but I can’t play everything out there and these two companies are not only renowned for this but they have often been innovators in this field.)
This solution has many benefits: It doesn’t break the immersion, it focuses on having fun, even when learning the most basic skills, and it feels empowering for the players because they feel gradually more powerful and more resourceful as the game advances. In short, I would say that this solution has two major advantages:
- It merges the story of the game and the story of the player’s experience. This works wonders for immersion.
- By offering a steady stream of new powers, it’s better at doing what games are enjoyed for: Making your brain feel good about itself.
This is something that’s strongly story-driven and scripted but not every game is necessarily story-driven or scripted. Also, this takes time, tools, and then more time for more iterations. And you probably need a plan B, in case things don’t pan out as expected. It’s pretty well known that even the best at this often scrap plenty of their work and start over. For details, I suggest googling for post-mortems from Valve. You could say that, in the ideal case, when everybody agrees with this plan, the proper authoring tools are available, and you have staff on hand with a lot of experience building exactly this kind of progression, you still have bad surprises, you have to adapt, change, iterate more than many would find reasonable.
And then reality hits you in the face
Now imagine that you’re trying to implement this last solution in a game that doesn’t have the needed resources. Not every project has the tools, the staff, and especially the iteration time to deliver ideal tutorials. You, as a designer, may be able to envision the best game possible but, in reality, it can only become a reality in a very limited set of circumstances. And worse still, maybe your project doesn’t have the usual prerequisites of being built around a linear, scripted progression and a strong story. If your game has no story, no linear progression, you could have all of the means necessary, and this would still represent an immense challenge, perhaps even an impossibility.
So, depending on your situation, it may be wise to make the painful trade-offs early on. The best plan is the one that lets you adapt the quickest because you should expect to learn quite a few facts about your own tutorials for reasons explained in the previous post on the subject. Making a good game always requires trade-offs, even more so in the case of tutorials.
Soon, on ex Ludis …
Writing instructions no one wants to read and delivering features your team doesn’t want to work on.