Friday, June 4, 2010

Audio/Kinesthetic as a gamer learning device

Tutorials in games have become the norm.  It used to be that the player was expected to read the manual in order to fully understand the controls and know what was expected of them.  Over time, the onus has changed to be on the developer, to make sure the player can pick up the game and know what to do.  This isn’t a bad thing – since load and installation times have exponentially decreased, the time in which I’m willing to read the manual has also decreased.  However, thinking about the four learning types – Visual, Auditory, Reading/Writing and Kinesthetic – in-game tutorials don’t always seem to be the most efficient way of teaching the player.

Most often they’re highly kinesthetic.  The player is put into the game and expected to wander for a moment before being given a helpful graphic of the controls, or a text prompt telling them what to do.  Okay, so that’s kinesthetic and visual.  Most of the gamers I’ve tested – as a lecturer in interactive narrative, I see a lot of gamers – turn out to be auditory/kinesthetic types.  Having a voiceover of the on-screen text can be helpful, but can really break immersion if, as in Dungeon Siege 2, a character is saying something along the lines of, “Press the spacebar, maggot!”

Where does the fine line fall between Visual and Reading, though?  Should you choose text, or an image?  How do you place it on the screen?  Should it be transparent?  Will it take away from the inherent visual balance of the on-screen image if you overlay your giant diagram of an Xbox controller?  Does it really matter?

Yes.  Visual learners will be distracted from the game by bad visual design just as much as an Auditory learner will be distracted by poor quality sound design, just as a Kinesthetic learner will be distracted by bad control scheme design.  As an aside, all control schemes should contain the possibility of personalization.  Nothing can ruin a game more quickly than having to press unfamiliar keys when something else seems far more intuitive.  You, as the designer, can only guess at your ideal player.  Not everyone is ideal for your purposes.  Allow them to have input in a way that’s going to make the game less frustrating for them to play, and therefore more inclined to put up with some of your other design decisions.

But we were talking about tutorials.  If you want your player to learn, you need to find a way to address the same information in at least 4 different, non-invasive ways.  It’s no good having a giant image flash up on the screen if it obscures the action.  There’s no point playing an important audio clip when some kind of exciting visually action is occurring.  It’s no good having text pop up in the same circumstance.  And it’s no good showing the player what to do if you don’t let them do it themselves afterward.

Now, this may be frustrating, especially when described in this way, but my ideal situation for a tutorial would then run thus for any given interaction:

Use text to show the player what’s about to happen.

Show an image/in-game scripted event of the player character doing the proposed action, with an animated, highlighted version of the controller on-screen, interacting as the player would, in real-time, to perform the required action.

At the same time, play either an audio clip that rewords the previous text, or says something from an in-game character who would either be relevant during this interaction, or work as some kind of narrator, to reinforce what’s happening on-screen.

Then let the player perform the action.

At any point, the player should have the option to skip this sequence with a single button press, obviously not related to the control being taught.  If necessary, you can use the start or select button as the skip function, since those are usually unassociated with any in-game interaction apart from menu controls.

This is a lot of work.  It certainly won’t be easy.  But the benefits of appealing to more than one learning type outweigh the time-cost involved.  Obviously the above is for a third-person game.  In first-person games, the show-then-let-do element can be removed.  Bioshock 2 was the closest I’ve seen to a proper in-game tutorial.  It combined on-screen prompts with audio and visual feedback in the form of communication with your daughter and an arrow pointing toward the goal, but didn’t include a diagram of the controller, only the name of the button within the text itself.  It assumed knowledge of the Playstation 3 controller, such as knowing which of the two shoulder buttons is L1, and that L3 involves pressing in the left analogue stick, something that would be completely alien to a first-time console player.  People argue that games shouldn’t have to cater to these ‘n00bs’ but really that’s just a form of lazy elitism.  If your game is not accessible, you’re lazy.  It’s as simple as that.  After all, it’s far better to provide the option and let the player decide whether or not the information is valid than to not provide it in the first place and risk alienating or frustrating your audience.

Never forget, casual gamers like to feel smart, too.  Just because they aren’t currently part of your hardcore fanbase doesn’t mean they won’t become an avid fan, if catered to correctly.  How popular your game is relies on your ability to give your player what they want.  Don’t sell yourself short by fixing your control scheme in stone.  Don’t stop the player from getting to the fun part of the game by having an unskippable or boring tutorial.  And don’t confuse and frustrate the player by providing prompts that they can’t understand.
The player is your friend.  They give you money.  Remember that, and do your best to make them happy, even with simple things such as tutorial and interface design.  They may not know when it’s right, but they’ll sure as heck know when it’s wrong.

No comments:

Post a Comment