For today’s iDevBlogADay post, I’m going to be talking about in-game tutorials. I’ll explain what they are, why you should use them, and how I implemented them in Trainyard and Trainyard Express.
A foreword: I know a lot of people are expecting me to talk about how Trainyard Express has performed since being released last Thursday. Well, it’s been doing amazingly and blowing away all of my expectations. It’s currently the #1 free app in Italy and it’s climbing quickly in the UK and in Canada. There’s a lot I could say about it, but I feel like it’s only getting started and I really don’t have any hard conclusions to provide yet… Only to say that doing a lite version was 100% the right thing to do. I feel like I’m probably giving away too much content, but I think that’s what I have to do to get noticed, and it’s working, so I’m ok with that. Now back to your regularly scheduled post:
What are in-game tutorials?
In-game tutorials are a visual way to show a user how to play your game within the game itself, usually using the game’s own engine. I think it might be easier to explain what they are by explaining what they’re not: They’re not instructions screens, controls screens, or long-winded paragraphs of text.
Why use in-game tutorials?
If you want users to enjoy your game, they’re going to have to be able to actually play it. I know it seems simple, but I’ve played way too many iOS games where it felt like figuring out HOW to play was a puzzle in itself. A paragraph of text is never a good way to teach somehow how to play your game. Your instructions will probably introduce all sorts of terminology that the user won’t be familiar with, which’ll just confuse them. I’d be willing to bet a lot of money that most users don’t read ANY of the text they see in games anyway.
I haven’t done any localization in Trainyard, but my two biggest sales regions this past week were Japan and Italy. I believe this is in large part to the in-game tutorials, because players can get a complete understanding of how the game works even if they don’t understand English. As a part-time dev, I can’t justify spending money on localization, but having great in-game tutorials is the next best thing. Here’s an interesting challenge: replace all of your game’s text with wingdings or some other gibberish font, then give it to someone who’s never played it before, and just watch (no helping!) as they try to ∂learn the game.
I know the usual alternative to a “wall of text” is to create a few pages of instructions. These are usually quite visual, with screenshots of the game itself and little arrows showing what certain things are and what they do. This approach is much better than text, and it’s good enough for some games, but it’s still not ideal. You’ve got your whole game engine sitting there, why not use it? If it’s at all possible, you show what it looks like when the game is actually being played. I know I learn way more about how a game works from watching a Youtube video of someone playing it than I do by reading it’s instruction screens. There’s something to be said for “discoverable mechanics”, and you definitely don’t have to give it all away, but the user shouldn’t ever feel like they might be playing the game wrong.
How did you do tutorials in Trainyard?
The tutorials in Trainyard are spread out over the first 10 “cities” of puzzles. That means that there’s a tutorial roughly every five puzzles. I didn’t want to swamp the user right at the start, so I only gave them the bare minimum amount of information they needed at any given time. I think it worked out pretty well and gave the game a nice flow.
The tutorials are made from a few components, but the key thing is that they look like the game and they use the game’s engine. I made a hand that dispatches fake touch events on the Trainyard grid just like real touches do. The ridiculously ugly hand has an over-the-top tapping animation so that it’s really easy to see what it’s doing at any given point in time.
There are multiple tutorials on each different concept, and each individual tutorial is broken into steps. A step is a section of the tutorial that plays out and then waits for user input to continue. I never assume the player has a certain reading speed, so any time there’s text on the screen, I let them choose when to continue. Each step is broken into actions, which are basically any of the things that can happen, like moving the hand, showing text, and resetting the puzzle.
I wanted everything to be dynamic and easy to edit and tweak, so I built a simple xml file to describe the tutorials. I won’t go into details about what I do with each node, but feel free to ask me if you’ve got questions about how I implemented any specific part of it. I know the schema is a bit weird, but it makes a lot of sense once you get how the system works. You can see the xml for all the tutorials here: http://struct.ca/files/trainyard/tutorials.xml
In the original 1.00 build of the game, there was no tutorial skip button. It was a common request from beta testers, but I decided against it because I was willing to risk aggravating users early on to keep them from getting aggravated later (by not knowing a technique to solving a puzzle). This was such a common request after release that I eventually caved and put it in, but with a little adjustment: If players try to skip a puzzle, they’ll get an “Are you sure you want to skip this tutorial?” popup, so they have to think hard about their decision.
Another first-release complaint was with the speed of the tutorials. Everyone complained that they were way too slow, so I shortened every single delay and generally made it all run much faster. I also took out quite a few of the text popups, and even took out one tutorial entirely (the one that explains how to go around rocks).
It wasn’t until the last 20% of Trainyard’s development that I switched to using in-game tutorials. I had written and implemented a whole pile of text-only instructions/tutorials for the first set of puzzles, but it just seemed rushed and amateur. The in-game tutorial system probably added a month’s work to the project (working part time), but I think it was worth every minute I spent.
PS: The whole “text vs. gameplay” thing also plays an important role in marketing. Why have bunch of bullet points about your game on your site, when you could put a video of someone playing it instead? (ala minecraft.net).