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.