As we know, part of game design involves challenging players to overcome and solve the problems and puzzles we put in their path.  By overcoming these challenges, players have fun, feel smart, learn things, and are motivated to tackle future challenges in the game.

Unfortunately, not every player will be guaranteed to solve every problem put before them.  Players who are already invested in a game will spend around 10 minutes trying to progress in some way before giving up in frustration.  At this point, many players will also feel dumb.

Obviously, we do not want our players to feel frustrated and dumb.  So, in order to keep players from feeling this way, or perhaps out of fear that some will ever feel this way, game designers are occasionally guilty of designing challenges that treat all players like they really do possess only a very limited amount of intelligence.  After all, the >99% rule (which I first heard about during a GDC lecture by Randy Smith), can be fairly terrifying.

The rule points out that if just one million people ever play a game, and 95% play through the game without getting stuck and frustrated, that still leaves fifty thousand people who did get frustrated, probably stopped playing the game forever, and possibly told their friends about how dumb the game was.  That’s a lot of people.

What if we want only ten thousand people to ever feel frustrated, out of a million players?  We can do the math backwards: if there are just five challenges throughout the whole game, or in other words, five opportunities for a player either to feel successful and smart or frustrated and dumb, then we would want only two thousand people to get stuck at each point.  This means that 99.8% of players need to successfully complete each challenge.

Ensuring that completion percentage can be a bit daunting, especially when we consider that most games contain far more than five challenges.  But treating players like they’re dumb isn’t the answer because they aren’t really dumb, and they certainly don’t like being treated  like they are.  In fact, if we provide too much guidance as designers, we once again make players feel dumb, and we have once again failed.  Players only feel smart and have fun if we provide just enough guidance… but not too much.

Hitting that sweet spot of “just enough” guidance can seem tricky.  Playtesting extensively helps.  Tracking metrics of player performance helps spot areas where too many players get stuck.  When Valve was playtesting Portal 2, they not only checked to make sure that players weren’t getting stuck too long on any puzzle, but they also checked to make sure that most players weren’t solving puzzles too quickly.  Ideally, we’ll eventually be doing something similar.  Mostly we’ll be keeping an eye on how players interact with the game and make sure that players are challenged by obstacles designed into the game and not by other things that might have emerged from the design that distract, mislead, and confuse.

Activities are generally defined to be intrinsically motivated if people engage in them “for their own sake.”  If people engage in an activity in pursuit of some reward that is external to the activity, they are driven instead by external motivation.  In fact, intrinsic motivation is just a fancy name for motivation created naturally from undertaking the activity.  Importantly, people tend to enjoy activities more, perform better and learn faster if they are intrinsically motivated to do them instead of externally motivated.  This is why classroom grades aren’t great motivators for education, why promising future bonuses upon completion of a milestone to overworked employees can actually decrease moral, and why the “achievements” built into games can be considered harmful if poorly designed or implemented.  We really want people playing our game to be intrinsically motivated!

“Dr. C” defined five aspects that describe intrinsically motivating activities, and as game developers we have various ways to design these aspects into our game.

1) “The activity should be structured so that the actor can increase or decrease the level of challenges he is facing, in order to match exactly his skills with the requirements for action.”  In case it isn’t clear, the term “actor” here would be the person playing the game. The game industry attempts to address this in various ways, by letting players choose their own gameplay difficulty or building dynamic difficulty levels that respond to player performance.  Jenova Chen designed a game as a part of his MFA thesis that allowed players to actively and elegantly control their level of challenge at any time in the context of gameplay.  He called the game, appropriately, “Flow.”

2)”It should be easy to isolate the activity, at least at the perceptual level, from other stimuli, external or internal, which might interfere with the involvement of it.”  It turns out the processes the human brain uses to solve problems comes in handy here.  When solving problems, humans build miniature realities in their heads where only information we think relevant to the problem exists—we do this all the time.  The last time you got sick, you probably tried to figure out what food or person to blame.    Ideally we as designers don’t place anything in our game that is purely random and having nothing to do with the problems the game presents, and so building a miniature reality from the reality presented by the game can be straightforward.

3)”There should be clear criteria for performance; one should be able to evaluate how well or how poorly one is doing at any time.”  This is why we always offer very clear goals to the player; players use goals and their progress toward them to evaluate their performance.

4)”The activity should provide concrete feedback to the actor, so that he can tell how well he is meeting the criteria of performance.”  We’ve mentioned in previous articles that providing feedback is an incredibly important part of game design—now you know that one of the reasons feedback is so important is because it strengthens the player’s intrinsic motivation, or perhaps more accurately, prevents the frustration that would destroy their motivation.

5)”The activity ought to have a broad range of challenges, and possibly several qualitatively different ranges of challenge, so that the actor may obtain increasingly complex information about different aspects of himself.” We address by offering the player short term goals and long term goals, where the short term goals build toward the long term goals.  When players start playing they only need concern themselves with the short term goals, and over time start looking toward the long term goals, meaning they have more goals and more information to keep track of in total.

The ways that Dr. C’s work is important to our own work at Mindblown Labs won’t all fit in one article, but that’s okay—we can revisit Dr. C’s ideas in weeks to come.

Source: Csíkszentmihályi, M. Intrinsic rewards and emergent motivation. In M. R. Lepper and D. Greene (Eds.), The hidden cost of reward. Morristown, N.J.: Lawrence Eribaum Associates, 1979.

For instance, lets consider how people learn new things—and so that we don’t get distracted by the influences of education systems and cultures, lets look first at how babies gather new information.

Babies are natural explorers, with a deep need to know things and understand the world that is so new to them, and have a constant curiosity that pushes them to pursue that knowledge.  Babies are famous for sticking things in their mouth, which is why many toys have choking hazard warnings.  They also abuse toys in every other way they can think of too, hitting them, throwing them, feeling them, kicking them, breaking them, and so on.  Babies don’t do this out of a deep hatred for the toys they’re given—rather, they do these things to gather as much information as they can about the properties of the object they’ve found.

Babies use a series of increasingly self-corrected ideas to map out how reality works. They actively test everything because everything is new to them, and they do it much like a scientist would, first by making an observation, then by forming a hypothesis, then by experimenting on that hypothesis, then by drawing a conclusion, and then by testing all over again.  This is also precisely the same way that many people learn new games.

In fact, much of game design theory is itself designed to interact with people that still learn like babies (and its an pretty fantastic way to learn, by the way).  Fundamental design concepts such as providing strongly designed positive and negative feedback to players work brilliantly if the player is poking and prodding and testing everything around them.  These players actively do things just to see what will happen.  They trigger “causes” in order to see what the “effect” is.

But not everyone learns this way.  A large portion of the population doesn’t like to poke or prod or cause anything to happen unless they already know what the effect is.  Many games weren’t designed with these people in mind at all.  The player will start playing and wait to be taught the effects of their potential actions, while the game waits patiently to explain the potential effects once an action has occurred.  Both parties are waiting for the other one to start a conversation, so the dialog never occurs, and because players are people and the game is not, the player is usually the first to grow frustrated and leave the game alone forever.

As game developers we need to try hard to identify the different ways that people learn and then (ideally) design the game in such a way that it is accessible to as many people as possible.  Our game will have a tutorial system that will hopefully address the needs of those that want more information beforehand while still remaining unobtrusive to those that want to poke and prod.  Of course, in order to find out how well it works we’re going to have to test it and see what happens—we haven’t yet found anyone who will tell us the exact effect of our designs before we put them in front of players.

I ran through the problem in my head.  First, I identified my goal: eliminate buzzing in the problem strings so that they sounded as clear as the good strings.  Next, I tried to figure out what might be causing the problem.  By running my fingers up and down the fretboard, I determined that the buzzing only occurred when I held the strings down in a specific spot, behind a specific fret.  This suggested that the strings itself weren’t the issue, but rather the relationship between the string and the fretboard on my guitar.

In order for me to think through this problem any further, I needed to reflect on my conceptual model of how the guitar works–the concepts and ideas in my head that described how I believed notes to be made on the instrument.  I knew that when I pressed down on a string, the string hit the closest fret (a raised bump on the neck of a guitar), which in essence shortened the length of string available to vibrate, which translated into a specific note.  I also knew that if anything disrupted that vibration, the note would not play cleanly.

I decided that the strings were hitting a second fret as it vibrated because the angle of the strings coming off the fretboard were too low and solved the problem by changing that angle. However, if I hadn’t understood how frets worked on a guitar, I might have tried changing strings to fix the problem.  Or perhaps if I had thought that strings were perfectly parallel to the fretboard, and not realized that the angle could be a problem, I might have tried sanding the problem fret down, causing further problems.

Two weeks ago my household was having problems with our washing machine–it wouldn’t start its spin cycle.  None of us had any clue how the internal workings of a washing machine worked–we had no conceptual model, and we knew it.  So we tried to build a model in a method used by infants everywhere–we did things and watched what happened.  We turned knobs, kicked it, shook it, pressed buttons in different orders, slammed the top hatch down… and suddenly it started.  Suddenly we had some information to add to our conceptual model: the connection that didn’t let the spin cycle start with the top hatch open was breaking, and by slamming the hatch down we forced the connection to work.  We were excited because had solved the problem ourselves–and because we got to wash our dirty clothes.

Unfortunately, our conceptual model was also completely wrong, and when the washing machine wouldn’t start the next day no amount of hatch slamming solved the problem. Eventually we hired a professional to diagnose the issue, and his conceptual model was markedly more accurate than ours.  It took him about 3 minutes to tell us that the machine’s fuse had blown.

Conceptual models support problem solving.  If conceptual models are wrong, it doesn’t really matter how well we know the exact result we want–we won’t be able to see what we need to do to achieve it, or worse, we’ll think we see exactly what we need to do while actually having no clue.  Then, when we don’t get the result we expected, we’ll get frustrated.

Some conceptual models are completely ingrained in many of us through years of exposure.  When we enter a dark room we unconsciously look for a light switch which we know will turn on a light despite being visually unconnected to it because of our mental model that associates the switch with light.  When we encounter problems involving less ingrained mental models, we take in passive auditory and visual clues and poke and prod in order to build one.  Sometimes, when all of the elements of the model are visible, easily isolated, and give direct feedback when manipulated (like with a guitar), we can build strong conceptual models quickly.  Other times, when the elements are hidden and feedback to prodding is limited (like with an old washing machine) the models that emerge are weaker and often simply wrong.

Games present players with problems to solve, and players rely on their conceptual models of how the game works in order to solve them.  Frustration occurs when the player’s conceptual model doesn’t match the real model that was designed and implemented into the game.  To make matters more complicated, game designers’ systems and models are often things players have not spent a lifetime interacting with, which means we can’t really ever assume light switch level familiarity with even our simple systems.  Also, many players will bring related conceptual models from other life experiences or other games and attempt to apply them to the problems and challenges they encounter in a new game.  And lest a designer get lazy, it is very easy and not uncommon for us to design problems that seem simple on the surface, but that actually build on top of conceptual models that are ingrained into those who regularly play a certain type of video game but absent in those who don’t.

As game developers, we want to avoid player frustration, so we need to carefully and clearly communicate what our models are so that players can grasp the concept fully enough to put pieces together–but not so fully that all of the presented problems are solved for them by the game.  We want to be more like a guitar than a washing machine–visible, isolated parts that provide instant positive and negative feedback when investigated, where cause and effect is clear and not misleading, where solving a problem feels more like exploring (and playing!) than an endless endeavor of random tactics that might hopefully result in some clean clothing.

This is a problem you encounter a lot, though, as you work with kids at an after-school program.  The next time you encounter a ball rolling around your hands are full of paperwork, so you kick the ball into the bin.  More accurately, you kick the ball near the bin and have to try a few more times to get it in, because you don’t actually have a ton of foot control and dexterity.

You gain dexterity, however, as you continue to use your feet to move the ball on future days–you seem to be carrying stuff with your arms a lot.  You gain control of the ball as you learn to guide the ball around children and toys scattered across the floor.

And then your foot-based ball-guiding skills plateau.  You have only minor reasons to get the ball into the bin faster than you have been, and if you take any risks or experiment at all with your control of the ball, you might end up hitting a kid in the face, so you play it safe.  Taking risks, experimenting, and failing are the key to learning, and because you can’t afford to fail, you stop learning.

Then you join a soccer team.  Suddenly the bin is far across the field and called a goal, and the obstacles to maneuver around are real people who are in turn maneuvering against you.  The amount dexterity and control required to place the ball where you want it to go has gone up dramatically.  Furthermore, you have other people on your side who would work with you if you could figure out how to communicate and coordinate quickly enough.

Luckily, the consequences for almost any type of failure in this context is very low.  You lose some games.  You play some more.  You do experiment, you do take risks, you do try new things, and you do continue to fail–and so you continue to learn and eventually improve.

Games take real problems and move them into a context with severely watered down consequences for failure without actually diluting much of the motivation for winning, thanks to some quirks of the human brain.  (A recent Yale study shows that almost the entire brain is engaged when people play games like rock-paper-scissors, alluding to the amount of resources brains devote to winning even simple and trivial contests.)  The power of strong motivation and interesting combined with the opportunity to reflect and glean lessons from past experience makes for an absolutely fantastic avenue for education.  While foot-based ball-guiding skills are of limited value in “real” life, there are other things we can teach that have considerably more value.

There’s more to this topic of using games for educational purposes, certainly–interactivity and accessibility are important factors, for instance, and more may be written about them here in the future.  Also, excitingly, both the fields of game design and education are fluid and continually advancing, so finding the intersection points between the two is a constant challenge and learning experience itself. Luckily, I get the opportunity to tackle the challenge almost every day.

As lead game designer at Mindblown Labs, I aim to create elegant, compelling gameplay while at the same time paying close attention to the lessons the game’s mechanics impart and the behaviors the game’s dynamics encourage.  In short, I want people playing our game to naturally, almost unconsciously, learn real life financial literacy skills, motivated by the game to take risks, make mistakes, and learn lessons that would be costly in to learn in real life yet fun to overcome in a game.

Now, the real work begins. . .