Training

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

Random Tidbits

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).

This entry was posted in Game Design, iDevBlogADay, iOS Development, Trainyard. Bookmark the permalink.

6 Responses to Training

  1. Pingback: Tweets that mention Training | Struct.ca -- Topsy.com

  2. Cam says:

    I don’t care what anyone says. I think your hand graphics were beautiful!

    I really like your approach to making the tutorial and gameplay understandable, even if the person does not have a firm grasp with English.

    Great article!

  3. Daniel Wood says:

    I’m in two minds about this. I’ve recently just taken out all the instructional gameplay from my own game and instead have just added some instructions in the help menu. I’ll find out how it goes soon.

    In Trainyard I think it’s fairly important to explain the different types of tile but often I do feel that the whole instructional game play this going too far. I think this sums it up nicely:

    http://www.hiwiller.com/2010/04/29/if-mario-was-designed-in-2010/

    • Matt says:

      That 2010 Mario thing is great.

      I know in-game tutorials were the way to go in Trainyard, but you’re right, they’re completely overkill in some other types of games. It’s really up to the developer to find the right balance between discovery and frustration, but lately, most games seem to err on the side of frustration. I think it’s important not to assume too much of the user’s general gameplay knowledge if you’re aiming for a broad market.

  4. Greg says:

    I love the font you are using. What is the name and was it licensed or free?

    Beautiful design overall, btw. :)

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>