Recently, I’ve been playing Zachtronic’s latest game SHENZHEN I/O. The game is about using assembly level programming to create programs by using circuitry and CPUs. To help, the game features a 41 page manual that reads like the company manual you get at work. Despite the manual, I had to turn to outside help to learn the basics of the game.
Trying to learn the game, I started to think about how we learn things both in and outside of a class setting, and that games might hold a better solution.
RTFM:
If you’re reading this right now, then chances are you have tried learning something at some point in your life. Manuals are always structured around giving you everything there is related to the product in question. Textbooks can be several hundred pages of information laid out as boring and un-intuitive as possible. And finally, we have actual instruction from a teacher, parent, friend, etc.
We’re going to ignore manuals for putting something together, as they are laid out in a step-by-step order. I want to focus on when we’re learning how to do something or use something.
In previous posts talking about learning games, I talked about the three essential elements of tutorials: What am I doing? How do I do it? And why am I doing it?
Being able to explain all three are important for someone to learn not just how to do something, but how to apply that knowledge. Applying your knowledge is vital, and where we see learning stumble.
Telling someone what the buttons do in a forklift is not the same as actually driving and using it. The issue is that teaching in an isolated example does not prepare them for using something for real.
Breaking down learning by complexity and priority can make it easier to teach someone new
On the flip side and a tangent, throwing someone into the deep end is obviously not a good way to teach someone. When I was first shown how to drive by a driving instructor, he took me out for the first time on a highway driving 60 MPH.
I honestly can’t remember anything that man told me; all I remember is my heart racing and thinking I was going to die.
The order that you present something is just as important as how you present it; something all educators should learn.
Priority Learning:
In previous talks, I brought up the topic of the order that new mechanics and instructions are presented. There are two elements to this that you need to understand: The complexity and the priority.
As a general rule, you should be teaching in order of lower complexity to higher. If I’m learning to be a mechanic, don’t ask me to take apart an engine before I’ve even used any tools.
That’s the easy part; here’s where things get challenging. The priority is based on the immediacy of a role or lesson. Just because something is easier to show someone, doesn’t mean it’s the right time to teach them.
Concepts need to be explained and understood before moving onto the next
Too often, manuals and books will switch gears between chapters and lessons.
The reason is that they want to introduce all the basic stuff, then the moderate, and finally the advanced. The problem with this framework is that information is not being given enough time to be fully processed.
If I just read a chapter about using if/then statements and then the next one is dealing with arrays, where’s the carryover of knowledge? A good instructor should not only present topics that are easier to learn first, but also stay on the topic for as long as it’s relevant.
Delayed Learning:
I can give you an example of this problem straight from the SHENZHEN I/O manual. The manual’s first topic talks about the difference between simple I/O and XBUS functionality. This information is not important for someone brand new reading it for the first time. The first lesson should be the basic command language with examples.
The reason is that everything about creating programs and the rules of the game flow from the language. Instead, the manual shows off more examples and talks about advanced rules and statements before we’re presented with the statement list. As a point of reference, the actual statement list doesn’t show up until page 15 of the manual.
Once someone has an idea of what they’re doing (creating lines of code), it will be easier for them to understand the logic and rules.
Our next point goes back to showing someone: “The How,” of learning and that has to do with examples.
Lead by Example:
Examples are one of the best ways to teach someone about how something new works. There is a big difference in being told how something works, and being shown how it works. For every lesson you want to teach someone, there should be a tutorial that goes with it.
Seeing something in action is different than reading about it in a book
With the SHENZHEN I/O example, the game features examples of programs, but not of how the commands work.
What’s worse, because the player doesn’t understand the command language, they will have to return to the earlier examples after reading further into the manual.
You should never be taught in an order that requires backtracking to learn lessons.
It’s okay to repeat instructions in the form of different examples. You can have a basic example that is taken out of the normal context, and then an advanced one within the context. This is where the difference between “pseudo code” and showing real programming examples can come in.
One important point about examples, the player must be interacting with the game. Again: Watching something is different than actually doing it.
Building a Better Tutorial:
Teaching can definitely take a page from good game tutorial design. Designers have been challenged to explain advanced and often esoteric concepts for years now. Likewise, there is always room for improving tutorial design.
Understanding the order of importance is crucial for being able to teach someone correctly; even in open-ended games. Everyone needs a benchmark for where to start with learning a new concept. If you throw the player into the fire, even simple games can become difficult to learn.
Once again, you should be consulting your testers, both new and old ones, to determine the hard areas of your game. While new players may not be able to tell you much about how your design works, they can certainly help you to see where they are stumbling with your concepts.
Ultimately, the easier it is to start playing your game, the greater the chance that people can at least learn it. If you’re not careful, you can easily turn players away before they can even decide if they like your game.
I know that good tutorials are not high up on the priority list of game design, but they can mean the difference in getting new fans or losing out. For the future, I’m curious to see if VR and AR will open up the doors for more accessible (and cheaper) simulators. While I may not be flying airplanes any time soon, it would be interesting to see what just goes on in a cockpit.
If you enjoyed this post, please consider donating to the Game-Wisdom Patreon campaign. Your donations can help to keep the site going and allow me to produce more great content. Follow me on Twitter @GWBycer, and you can find daily video content on the Game-Wisdom YouTube channel.
