We were invited to the Gamification for Financial Inclusion Expert Meeting hosted by CGAP (the Consultative Group to Assist the Poor) at the World Bank to participate in a day of discussions and workshops concerning how game design might empower low-income customers in order to enhance financial inclusion in emerging economies. As a part of our collaboration, we wrote about how we're using games to teach financial capability at MindBlown Labs, and what we've learned along the way.
Csíkszentmihályi Mihály is the psychologist that introduced the concept of flow, which is defined as completely focused motivation. As he defines it, people are talking about this state of flow when they describe someone as being “in the zone,” “on the ball,” “present,” “in the moment,” etc. This state of flow is described as being both incredibly enjoyable and as an incredibly powerful way of harnessing emotions in the service of learning. Csíkszentmihályi’s work isn't the only legitimate perspective on motivation, but it is a useful one to consider.
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. 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. This is why we really want people playing our game to be intrinsically motivated to do so. Csíkszentmihályi 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 player of a game. The game industry attempts to address this aspect 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 use to solve problems come in handy here. When solving problems, humans build miniature realities in their heads where only information relevant to the problem exists—this happens in our heads all the time. Ideally we as designers won’t place anything in our game that is purely random and has nothing to do with the problems the game presents, and so building a miniature reality from the reality presented by the game should be fairly 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.” As has been mentioned in previous articles, providing feedback is an incredibly important part of game design—now you have know that one of the reasons it’s so important is because it strengthens the player’s intrinsic motivation, or perhaps more accurately, prevents the frustration that would destroy said 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 this aspect by building nested loops of challenges and problems to solve in the game—in plainer English, this means that we offer 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.
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.
As a game designer, my job is to craft an experience for players. There are some challenges associated with this job that stem from the facts that I generally aim for creating a specific type of experience and that different people experiences things in different ways.
For instance, let's consider how people learn new things—and so that we don’t get distracted by the influences of education systems and cultures, let's 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 they have a constant curiosity that pushes them to pursue that knowledge. Babies are famous for sticking things in their mouth. They also abuse toys in every other way they can think of too, hitting them, throwing them, feeling them, kicking them, breaking them. 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. 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.
"Paper Prototyping" involves building a close approximation of game systems using physical materials rather than digital tools. It often saves us time, though admittedly at the expense of a few trees.
Paper prototyping for a game can look like a giant arts and crafts party. Game pieces are made out of wire ties, scribbled number lines track scores, and post-it notes turn into beautiful maps if you squint at them really hard while mentally picturing a beautiful map. Math is simplified to basic addition and subtraction—we can always model complex math later with the help of computers. One of the rules of prototyping is to know what you're looking for, in part so that you don't get bogged down with irrelevant details.
While paper prototypes are fun to put together, a decent amount of thought and planning goes into their construction. We have to make sure that the prototype models something similar enough to the proposed digital systems so that we can learn something by playing with the prototype, but we also have to keep the prototype simple enough to handle physically. Also, these materials take up space, which is a point that seems obvious until your grand prototype ends up running off the edges of any table you try to build it on. Still, a lot of creativity can go a long way, and in the long run few problems are insurmountable when duct tape is easily accessible and imagination is liberally applied.
When I was in college I decided I wanted to learn how to play the guitar. I was about to proudly graduate and to compensate for my correspondingly large college boy ego I needed to try something I would be horrible at. I figured that hearing myself squealing away on a new instrument would remind me that I wasn't that much of a hotshot, and as a bonus I'd have something I could play at parties if I ever decided I had too many friends. Basically, I was still a child, and I beg your forgiveness.
When I first started practicing on my cheap Squier, the sounds I was producing sounded less like music and more like an angry hornet's nest trapped in a shoe box. This killed my enthusiasm for practicing, partly because I didn't want my roommates to murder me, partly because I wasn't that invested in practicing in the first place, and partly because I didn't want our pet dwarf hamster to go deaf. I realize now that it was silly of me to worry, as our house parties were definitely more obnoxious and she survived those.
Most importantly, I decided that it was the guitar's fault it sounded bad, thus absolving me of any responsibility for my crimes against musicality. (Like I said, I was a child.) So, like a good little almost-college-educated problem solver who loved to procrastinate, I dedicated myself to fixing my guitar.
First, I specified my goal: 3 of my strings produced a muted, buzzing noise, while the rest produced what could be considered notes, so my goal would be to make the bad strings sound like the good strings. Next, I tried to figure out the specifics of the problem, mostly by playing more bad music and listening closely to what was happening. I figured out that the horrible buzzing only happened when I held down the strings in specific spots, which suggested that the strings themselves weren't the problem, but rather the relationship between the strings and the guitar's fretboard.
In essence, I was exploring my conceptual model of how a guitar works—thinking through the concepts and ideas I held in my mind that described how I believes notes were made on the instrument. If my conceptual model had been wrong, I might have tried replacing the strings. Instead, I changed the angle of the fretboard, and eliminated the horrible buzzing. From then on, the horrible noises produced by my guitar were solidly my fault.
Around the same time, my household was having problems with the washing machine—it wouldn't start its spin cycle, leaving our clothes soapy, soggy, and dirty. No one living in the house had any clue how a washing machine actually worked, internally, and we knew it. So we tried to build a mental model with 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 washing machine wouldn't start its spin cycle with the top hatch open, and the top hatch "thought" it was open unless it was slammed closed. We were super excited that we had solved the problem ourselves.
Unfortunately, our conceptual model was completely wrong, and when the washing machine wouldn't start the next day we slammed the hatch with comical amounts of force with no effect. 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 through years of exposure. When we enter a dark room we unconsciously slap walls searching for a light switch because we know there has to be a nearby way to turn on the lights. 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 or 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 familiarity on par with light switches. Also, many players will bring related conceptual models from other life experiences or other games and attempt to apply them to problems and challenges they encoutner 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. Players unfamiliar with those games are then left unsupported and lost.
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 causes and effects are clear rather than 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.