[Why do game tutorials suck so much, and who are they for? Experienced developer and author Sheri Graner Ray takes a look at different styles of knowledge acquisition and posits a way to design tutorials that will more effectively satisfy a broader audience.]

No one likes tutorials.

Marketing doesn't like them because they are never done until the very end of the project.

Producers don't like them because they can't spare the resources to make one.

The team doesn't like them because they've been living, eating, breathing and sleeping this product for so long they can't imagine anyone NOT being able to figure it out.

Finally -- the users rarely like them because they simply don't teach anything well in any way.

Yet tutorials are the players' first contact with our product -- their first impression of our work.

We only get one chance and we usually blow it.

Here's how it normally happens. At the last moment before ship, someone from marketing or PR or community comes in to a meeting and says, "What about the tutorial?"

The team groans, the producer gets a headache, and then some smart person pipes up with "Is that intern still around? The one we put over in QA? Isn't he a programming intern? Why don't we give it to him? Oh, and we can have him do the install while he's at it."

And that's how tutorials get done in today's industry.

What we need to understand is that tutorials are not only the player's first impression of our work, but also they are the onramp to our products. If our onramp is smooth, wide and broad, then more people can easily get on. If the onramp is narrow, cramped, and made of mud, then very few people will get on. Better tutorials make a better first impression, which makes for happier customers -- and thus better business.

So, how do we go about making tutorials? First we need to understand how people learn. If you've had any training in education at all, then you know about the three primary learning styles: visual, aural, and kinetic. But for those of you who haven't, here's a quick refresher:

Visual learners are those who learn by seeing information. These are the people who would rather read instructions in a book or see charts and tables about the subject than listen to someone talk about it. They tend to say things like "I see your point."

Aural learners are those who learn by hearing information. They would rather listen to a lecture than read the information in a text book. They often say things like "That sounds right."

Kinetic learners are those who want to be in motion while they are learning. They would rather be up and moving around in front of the whiteboard than sitting at a desk. They might say things like "That doesn't feel right."

Now, the important thing to remember is that kinetic learners are not necessarily "learn by doing" people. They are "learn by moving" people. I shared an office with a strongly kinetic learner for almost three years. During our design brainstorms, he would pace in front of the whiteboard. The deeper into the design process we got, the move he would move until he was actually bouncing in front of the board. Even when sitting at his computer, he would move his hands as though writing on the board; pointing and moving virtual ideas around.

Educational instructors today will tell you that there are a myriad of combinations of these types of learning, and some new ones as well, but those are still considered the basics.

Now, something you don't hear as much about is the idea of knowledge acquisition styles. Along with the three big learning styles, there are two additional knowledge acquisition styles: "explorative acquisition" and "modeling acquisition." This is the information that is important to game developers, as it can be applied directly to game tutorials.

Explorative Acquisition

Explorative acquisition people are those learners who learn by taking risks. They are the ones who push every button, and flip every lever. They want to find the risks and experience them.

The best example of this is what happens when you take a 12 year old explorative learner into an arcade and hand her a token. Typically she will rush to the very first machine that catches her eye, drop her token in and start banging on the controls while asking, "How does this work?"

She is learning by exploring -- learning by taking risks. She is going to push every button on that machine just to see what it does.

Modeling Acquisition

Modeling acquisition players, on the other hand, want to know how something works before they try it. They need to know and understand the risks and ramifications before making the attempt. To do this, modelers want to imitate or "model" their behavior on something or someone they can observe. They want to see what happens when the required activity is done right and they want to see what happens when the required activity is done wrong. Modelers then want to try the activity to ensure they get the same results with the same actions.

Now, let's go back to that arcade. While our first 12 year old is hitting all the buttons on the arcade machine, what is her friend, the modeling learner, doing? He's likely standing and watching. Why? Because he wants to figure out how it works before he tries to play it.

Unfortunately the attract loop on most arcade machines is not designed to "teach" anyone how to play. It is designed to attract players with lots of bright lights and fast movement.

So our modeling acquisition player will move from machine to machine, trying to find one he can figure out before dropping in a token. In the end, the modeling acquisition player may simply walk out with their money still in their pocket.

It is important to understand that modeling acquisition players are not afraid to learn. How many times have you heard someone say, "Oh, my girlfriend will never try a game. She's afraid of the machine" or "My Dad just won't touch that new computer we got for him. He's afraid of it"?

The assumption that modeling acquisition players are "afraid" to learn is a dangerous one as it may cause game developers to assume there is nothing they can do to reach them. However, the modeling acquisition players are not afraid. They simply are not getting the opportunity to understand the risks and ramifications before they are forced to try to learn in the explorative method.

How does this apply to tutorials?

Simply put, the vast majority of our games today have tutorials designed for explorative learners. Usually the players will be given a meager explanation of mechanics (if any) then they will be dropped into an area and told "Go run around and try things! Explore!"

To which the modeling acquisition player will say, "But what will happen when I do this? How bad will it be if I make a mistake?" And then, because it is not comfortable for them to learn in an explorative method, they will simply shut it off.

A classic example of a tutorial designed for explorative learners is from one of the first iterations of the World of Warcraft tutorial.

World of Warcraft

World of Warcraft, when it was first released, had no formalized tutorial. Instead it had a series of "help" buttons which appeared as "!" icons at the bottom of the screen when the player encountered a new activity. The player only has to click on these "!" to get help with what they had just encountered. Sounds great, right?

If the player is an explorative learner, yes it does -- but not so much, if the player is a modeling learner. I played that game for three days and never clicked on one of those "!"s. In fact, I only did so after someone looked over my shoulder as I was playing and saw the entire line of exclamation points across the bottom of my screen. "Why haven't you clicked on those?" he asked. "Because I wasn't told to!" I responded.

The early WoW tutorial is a classic example of a tutorial that was designed for explorative learners who will click on everything just to see what it does. However, for the modeling learner, the concept of clicking on something without fully understanding what will happen when they do is a distinctly negative experience.

Because I was never explicitly told to click on those icons nor given a chance to see what would happen when I did, I never clicked, and thus the learning process was completely lost to me. I was being expected to learn things in a manner that was not natural to me and was not comfortable.

I recently checked back in with World of Warcraft and noticed that Blizzard has made some changes. The "!" icons are gone, replaced by pop up boxes that have both a textual and graphical representation of what the player needs to do to for the activity they have encountered. This is certainly a better presentation for the modeling learner, but not quite perfect.

Remember, the modeling learner wants to imitate or model their behavior on what they see. They also want to understand fully the ramifications of what they are doing. This means they often want to repeat the action until they are comfortable with it; until they understand what it is they are doing.

Therefore, a tutorial for the modeling learner should allow them to repeat the activity until they say they are ready to move on. If we only allow them to try something one time, it can make them feel rushed and even more uncomfortable than they did before they tried the action. The more uncomfortable a player is with learning a piece of software, the less likely it is they will stick with it or even use it at all.

If we were making accounting software which the person had to learn in order to do their job, then the users would have no choice but to learn it. They might resist learning it or they might try to find alternative methods of learning it on their own, such as working with friends or watching experienced used work with the software.

However, we are an entertainment industry. Players can shut our products off at will. Therefore we MUST make it easy and comfortable for them to learn our games if we expect them to continue as customers or become evangelists for our products.

One way to think about developing a tutorial that takes modeling into consideration is to realize that the player needs to understand the actual software and its interfaces before they can learn the game.

Otherwise the modeling acquisition player is so busy trying to learn how the software works, that they cannot also learn how the game works.

Think of it as trying to learn how to parallel park while trying to learn how to start, stop and steer the car at the same time. For the modeling learner, they are trying to figure out the ramifications of what they might have to do, while at the same time trying to learn the finesse of parallel parking.

The idea of teaching the interface first then teaching the game can get objections from game developers from a design standpoint. They will say that by having to actually explain the interface they will be "breaking the fourth wall" and this is counter to the concept of "immersion." While this is a legitimate concern, I believe if the player is too uncomfortable learning to play the game, then the immersion will never happen.

Simply put, a modeling acquisition player needs to understand the risks and ramifications of how the software works before they can begin to become immersed in the story or design of the software. We as developers should never be willing to sacrifice potential customers for the sake of "immersion."

It might seem counterintuitive to try to make tutorials for both modeling and explorative acquisition. Explorative acquisition players often object to the idea of a modeling tutorial as "dull" or "too slow." They may feel that this lack of immersion or slow speed is detrimental to them continuing to play the game. Yet at the same time, the modeling acquisition players take one look at an explorative acquisition style tutorial and throw up their hands and walk away. Is it possible to make a tutorial for both types?

The answer is yes and the secret lies in using the explorative acquisition player's natural tendencies. By adding a simple "Move to next step" button to each tutorial page or section, the explorative acquisition player isn't forced to participate in a modeling acquisition style tutorial. At the same time, the modeling acquisition player is free to practice or "model" the action as many times as they want. Besides, we know the explorative acquisition player is going to hit every button on the page anyway!

Overall, understanding the differences between modeling acquisition players and explorative acquisition players is key to producing tutorials for our products. By knowing that modeling learners want to understand how the actual software works before they use it, we can ease their acceptance of the product and adoption of the game as their own.

At the same time by providing the explorative learner the opportunity to "skip past" the modeling sections quickly and easily, we can ensure the explorative acquisition player doesn't get bored and shut the game off either. By understanding both types of learning acquisition and making accommodations for them we can begin to build tutorials that provide easier access and better player retention for our games today.