Analyzing Your App Using Game Thinking: Part 1 – Difficulty

Two weeks ago I had the great pleasure and privilege of participating as a coach at Amy Jo Kim’s Game Thinking Live event, a two-day training seminar introducing innovators and entrepreneurs to principles of game design that can be applied to the development of their own non-game products to make them more engaging. As I went over the training materials in preparation for my coaching responsibilities, I thought about what I teach my own game design students at The Los Angeles Film School, and one additional thing that I thought might be helpful to innovators was to show them how I teach my students to analyze the games that they are developing to ensure that they are delivering the intended user experience.

Five factors that I cover on in analyzing games are difficulty, complexity, depth, pacing, and replayability, and in post I will focus on…

Difficulty: The amount of skill a player needs to overcome the game’s challenges.

For challenges in games to be engaging for players, they need to have the right level of difficulty. When players play a game for the first time, their skill level for playing that game is low, but it will likely improve as they continue playing a game. However, if the game’s challenges exceed the abilities of the players’ current skill level, it can lead to frustration. Conversely, if players’ skill level is increasing faster than the challenge, it leads to boredom. The results of both of these situations is the same: players will leave the game.

Yet if the difficulty of a games’ challenges increases at the same rate as the player’s skill levels, it can keep the player engaged in the game. This balance of difficulty is an important factor in keeping the player in a state of flow: the mental state in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. When players experience flow, time stops, nothing else matters and when they finally come out of it, they have no concept of how long they have been playing.

So, what does this have to do with creating an app that isn’t a game? Well, a project that is created using Game Thinking begins with implementing its core learning loop. This is the basic level of engagement in your app. It is comprised of the following elements:

  • A repeatable, pleasurable activity that’s connected to an internal or situational trigger.
  • Feedback that drives learning and skill-building.
  • Progression and investment with re-engagement triggers.

Take a look at the second element.  Feedback that drives learning and skill-building.  When you play a game, you gain skills and knowledge that prepares you to take on greater challenges.  The same is true with using an app.  As you use an app, the skills and knowledge you gain transforms you as you engage with the product experience, allowing you to gain more value from the app.  Setting your app’s difficulty properly helps to ensure that there is a smooth learning curve for the user to advance from Onboarding to Habit-Building  and increases the likelihood that they will continue on in the Player Journey to Mastery.

If you are to transform your players, must properly adjust the difficulty of using the app to the user’s skill level.  How do you know what the appropriate skill level is for your users?  Simple: ask them during playtesting, “On a scale from 1 to 5, with 1 being very easy and 5 being very difficult, how difficult was it to use this app?”  You can also ask playtesters how empowered they felt using the app or whether the app did what they wanted it to do, since negative responses to either question might be a result of the app being too difficult for them to use.

Remember that the difficulty of an app is individual to each user, so be sure to collect this information from a wide pool of playtesters.  Also be sure to collect information when they first begin using this app and at multiple points during their Player’s Journey, because their skill will improve the more they use your app.

Unlike games, most apps can never be too easy to use.  But what should you do if your playtesters tell you that your app is too difficult?

One potential solution might be to provide more information about how to perform the various actions in your app or even about what the purpose is of some of your app’s features. Information can be given through help screens, tutorials, tips or even by encouraging your users to discover on their own through experimentation about how features work.

Another potential solution to try is to give users more of whatever resources they need to perform the app’s actions — whether that resource be time, points, virtual currency, or data.

When users report that they need more time to perform your apps actions and there aren’t any direct time limits implemented in your app for you to adjust, such as the delayed effect of performing an action due to your app’s performance speed, it may be that any aiming mechanisms (whether be how your users aim a camera for taking a photograph or aiming their fingers for touching the correct user interface location) needs to be re-evaluated.  Or if the user needs to perform a combination of key-presses to perform at time-sensitive action, you may need to find a way to revised the user interface to make fewer key-presses necessary or not require the user to be as dexterous when using multiple or complex control mechanisms. Users may even report that they don’t have enough time to perform actions simply because there isn’t an effective indicator that tells them they are ready to perform that action.

If your app allows users to perform certain actions until they’ve accumulated enough points or currency to do so, but users report that doing those actions is too difficult, the solution may be a simple one — either don’t be so stingy in awarding points or currency required to do later actions, or lower the costs of those actions.

In the case of your users reporting that they don’t have enough information to successfully perform actions in your app but you know that you are definitely providing that information to them, you may be requiring the users to memorize too much information, and it may be necessary to move (or duplicate) the data display to be closer on the user interface to where the user performs the action needing that data.

Requiring the player to memorize too much information or operate too many controls may be an issue of the app not being too difficult, but being too complex, a problem that we will examine in detail next week.



Implementing Risk/Reward Decisions In Games

My wife is a watercolor artist who sells her artwork at nearby art fairs several times a year, and I attend as her “roadie” to help set up and take down her booth.  She had signed up to participate in the Ventura “Champagne on Main” street fair last Saturday, but she was feeling tense about this one.  It wasn’t that she didn’t think it was a good venue for selling her art; it was the weather. According to the forecasts, the wind would be 23 miles per hour that day, and she was concerned that the wind would blow down her booth and destroy her framed art.  We eventually decided to take the risk, and while she was rewarded by selling some pieces in the morning, by the early afternoon the winds were so severe, we had to close down the booth early.  All in all, the risk did not pay off, but it did make for an exciting adventure.

So what does this have to do with games? Well, according to Civilization creator Sid Meier, a game is a set of interesting decisions. For a decision to be interesting, it must have the potential for both advantageous and disadvantage outcomes, depending upon which choice a player makes.

Of course, it is also essential that the choice does not have completely predictable consequence; otherwise, the choice would not be much of a choice. Either the risk or the reward (or both) must have some level of uncertainty, and finding the right balance between the two is an important task for the game designer.

There are several ways in which the game designer might introduce uncertainty to these outcomes:

  • Randomness: Adding an element of chance to either the advantageous or disadvantageous outcome is probably (pun intended) the most common way of creating risk and reward decisions.  The uncertainty of the result of a die roll or a shuffled deck is the basis of gambling and board games, but random number generation is also at the core of combat and encounter calculations in video games.
  • Imperfect Information: Not providing the player with enough information for making an informed decision is another way to introduce uncertainty. Imperfect information can be achieved in games through concealment, such as through card hands in a gambling game or a fog of war mechanism in a strategy game, or by misleading the player through purposeful red herrings.
  •  Other Players: It can be difficult to predict other player’s actions if their goals, strategies or tactics are hidden from us, or if the other players have incentives either way for cooperating with us or betraying us. One particularly tense scenario is a social dilemma here players have the avoidance of a shared penalty for cooperating, but an individual reward for betrayal.

There are many ways in which risk/rewards decisions can be implemented in games.  Typical implementations include risking the danger of an enemy or obstacle to reach a goal; risking limited resources to take an action that might not be successful in either achievement or effect; B risking an opportunity to make a choice that cannot be reversed.

Such trade-offs not only create a feeling of tension within a game, but also promote cognitive immersion as the player must calculate the odds of the advantageous and disadvantageous outcomes and do strategic planning to prepare for either result.

However, if the odds or success are too low or the penalties for failure too high, risk-reward decisions may wind up causing some players to abandon the game.  And so, creating risk-reward decisions becomes a metagame of risk-reward decisions for the game designer.