iPhone Game Development

Me: I just spent the last six months in the basement of my mom’s house. I made this really SWEET iPhone game called RacketSmackit. You’re the first person ever to play it other than me! I’m going to stand one inch from your right shoulder while you play.

Me: *hands unsuspecting innocent an iPhone*

Unsuspecting Innocent: This looks cool. But… umm… what do all these shapes mean? And why is that thing rolling around like that?

Me: *face palm*

You know that stinging feeling your palm leaves after this experience. It’s not pleasant. Ideally there would be no palm involved after demoing your game. You want people to pick it up and get it right away. Instead, you’re often left with that funny facial expression that can only mean one thing: confusion!?! Dum dum dummm!

In the best case your user wants to learn how to play your game. These people will treat the confusion as a challenge and try to figure out how to manipulate your crazy contraption. More often than not they will succeed… and then purchase the full version of your app ’cause they happen to be trying your well crafted Lite version. Fantastic. The problem is when the user becomes confused and reacts negatively by rejecting your app. This is terrible for a million reasons of which the least important is the $2.99 you missed out on. No, the good will and happiness a positive experience creates is the biggest value a single customer can provide. They end up being your free sales force. A free sales force that writes reviews, tells their friends, talks on your forums, and basically shmears it all over the web like it was a deliciously crafted cream-cheese spread.

Before I give you the secret to creating Shmear Shpreaders, it’s important to understand why your Unsuspecting Innocent takes out his confusion face. When you show your game to someone new, you are removing all of your assumptions from the experience. Let me say that again with different words: After spending months in a basement eating, breathing, and sleeping your idea, you end up creating all sorts of assumptions in your noggin’. These assumptions allow you to quickly make decisions and are important while building a product. Show the game to someone who hasn’t been in that basement with you and — BAM — they have no idea what a what-ja-majingle-hoobit is.

Preventing confusion comes naturally to the few talented designers in our ranks. But the rest of us mere mortals can use this assumption removing trick to our advantage. Here are some simple and cheap ways to mitigate the all mighty face-palm:

1. Hallway usability testing: Walk down the hallway to the first person who you can interrupt. Hand them your iPhone and ask them to politely try out your game. This works best if this person has not played your game before. It works even better if they are kind of like the type of person who will be playing your game when you ship it.
   
2. Friend Focus Groups: Call up your four friends. Tell them you are ordering pizza. Instead of busting out the trusty Soul Calibur, pass around your iPod with the pepperoni pie.

Actually collecting information from someone testing your game is a matter of watching for when they use their confused face, asking them questions, and taking notes. You’ll want to ask pointed questions such as “What did you think was going to happen?” and “Why did you do that?” Try to be reactive. It’s especially important not to guide your tester or ask guiding questions. If you do this right,  you’ll find that things you thought were obvious just didn’t make sense. Those stinkin’ assumptions strike again!

Once you identify the assumptions you’ve made, it’s time to go back to the basement and get to work. You need to figure out how to encode your assumptions in the game experience! How you do this is entirely dependent upon your game and what problem areas you have. Generally speaking adding tutorials and changing the visual queues of an object help. You’re on your own for this part.

It’s important to remember that this process of removing assumptions and encoding them in your game should be cyclical and frequent. Just like everything else, it’s easier to address these issues when you catch them early in development.

Everyone likes three easy steps. So… I present to you my Three Step Plan for Mitigating Gameplay Confusion:

• The way you reduce player confusion is by encoding your assumptions directly into the game experience.
• The way you find your assumptions is by asking players questions when they get confused.
• The way you find confused players is by demoing your game. And if you think you are demoing it often, do it twice as often.

Happy coding!