The Gamer Brain part 2: tricks that increase in-app purchase revenue

In my previous post, I described psychological techniques that can be used to increase player enjoyment within a game. But that’s really just scratching the surface on the behavioral techniques that you find applied in the gaming world. In this post, I’m going to be describing some of the methods that game developers use to make players spend more money in-game.

As a preface, I’m not advocating or shunning these tactics. I’m merely pointing out that they exist. There is certainly a ‘moral’ element involved when you begin using covert design decisions in order to acquire money from users, but there is so much grey area and the lines are constantly evolving that it is very difficult to brand them outright as good or evil. 

The pricing revolution

In what I’ll call the ‘standard’ game revenue model, developers build a game to be as fun as they can. Players pay upfront for this game after hearing about it from friends or review sites. If they like the game, players are more likely to buy sequels or other games from the same studio.

But given the advent of digital downloads, games are now free to distribute to a theoretically infinite number of players. As such, the price points have dwindled and now free games are overwhelmingly more popular in the mobile market. Developers have had to find a new way to make money, and they have done so with in-app purchases (IAP).

But as the revenue model changed, so did game design principles. If you want to make money off of in-app upgrades or consumables, you will need to change the way your game is built to support this new economy. Developers may actually aim to make their game less interesting in some ways to incentivize players to spend money instead of just grinding it out. They may also apply what could be considered ‘tricks’ that make players more likely to spend money. Here’s a sample of the most common ones:

Price Anchoring

Frequently, you’ll see different IAP options at various price points. The catch is that the cheapest option is rarely the best ‘value’. It may cost about a dollar, but the amount of in-game currency you get for buying this option is usually very low and probably not worth the cost. The real purpose of this cheap option is to make a second, more expensive option seem like a better deal. It’ll be around 3 to 5 dollars, and you’ll get much more in-game currency - more bang for your buck - and it makes players feel like they would be making a poor decision by opting for the cheaper option.

To make this effect even more powerful, developers throw in a third option that is ludicrously overpriced. Something in the range of 30, 50, or even 100 dollars. Most people will not even consider this option. But its main purpose is to make the second option seem downright thrifty - next to 50 dollars, 5 seems like a rational and cheap option. Of course, in the app store, five dollars will get you a super-premium game with dozens of hours of gameplay. But in the context in which this is presented, five dollars seems like a reasonable price for a relatively small amount of virtual currency.

Player dis-empowerment

You will frequently see free-to-play games where the initial fifteen to twenty minutes of gameplay allows you to ‘level up’ multiple times and unlock dozens of items. It makes the player feel very powerful to progress this fast. But at some point, the game drastically increases the amount of time and currency you need to reach the next level or progress point. This is known as ‘hitting the wall’. After being accustomed to such fast progress, the player is basically in a mini-withdrawal state and is much more likely to spend real money to speed up gameplay and reach the next reward level.

Trading money for time

Probably the most dominant revenue model in free-to-play games is that the player has to wait real-world time for progress in the game. There is almost always some special currency such as Smurfberries, Gems, etc, that are uniquely powerful and very difficult to acquire. Frequently, they can only be earned by performing some tedious or rarely available task. Their scarcity and acquisition difficulty further increases their value to the player. If it takes a player ten hours to earn five gems, and are given the opportunity to buy fifty gems for a mere dollar, then that purchase begins to look like a huge value given the amount of time it would take to earn them normally. Simply put, if you are able to equate an in-game currency closely with a player’s real-world time, they will be extremely valuable and likely to generate a real purchase.

What’s fascinating about this is that the game is built to consume your time, and then graciously offers (for a price) to lessen the burden. It’s basically as if they are selling your own time back to you. And you have to admire the brilliance - and gutsiness - of this tactic.

Creating false dilemmas

This technique goes hand-in-hand with the one above. It’s fairly well-known that a person’s response to a question can be heavily influenced by the way in which the question is asked. Similarly, behavior can be affected by giving a person a carefully chosen set of choices. A great example is, “Do you want to clean your room before or after dinner”? When given this choice, the responder will think less about the fact that they are being asked to clean their room, and more about the fact that they’re given a choice as to when they want to do it. The mind enters a tunnel-vision mode and fails to see possible choices of action outside of the presented options.

So when you’re playing a game, and your options are to 1) wait a long time, 2) perform some annoying task, or 3) pay real money, the real money option doesn’t seem like such a bad choice. Given the right context, it may actually be the most preferable. Of course, if the choice were simply “pay money or don’t play the game at all”, the player would find it much easier to quit without paying. So including additional, undesirable choices can foil players into performing the action you want them to take.

Opportunity Cost

People hate the feeling of ‘missing out’ on something. This certainly applies when an opportunity is time-sensitive. But another frequent use of this is when an optional item is available that would enhance a player’s actions. If the player is aware of this item’s existence, then every action they take would seem like they are missing out on this enhancement. A clear example would be a ‘double XP’ bonus that a player maybe can purchase at additional cost. Every time they earn XP, they would feel that they actually ‘lost’ the XP that they would have had if they hd the powerup. And a loss generally triggers more powerful emotion than a gain. So over a short amount of time, the player will feel a strong urge to acquire this powerup.

Random Rewards

One final example that is extremely powerful is the principle of a ‘random reward’ reinforcement schedule. What this means is that you dole out some bonus to players of various values and at unexpected times. It must be unexpected, because if a reward is expected its perceived value is greatly decreased as people feel like they ‘deserve’ the reward. And the brain simply goes haywire when it thinks there’s a chance for a random bonus when taking an action. Take a look at any casino and you’ll see rows and rows of occupied slot machines that demonstrate the incredible power that random rewards will have on people. So if you just want to increase player engagement, then this is a very effective mechanic. But it could certainly also be used to make players spend valuable in-game currency and to acquire more of it.

Summary

It’s very likely that these techniques left you with a bad taste in your mouth. People don’t like being manipulated, especially for someone else’s financial gain. Yet you will see apps that use these techniques constantly at the top-grossing and top-downloaded spots in the app store. You may wonder how evil it really is when players are spending this additional money of their own free will. And it’s certainly true that users like the availability of free games, and these new revenue models are certainly the only way to support that trend.

It’s also interesting to think that we’ve seen a similar process happen back in the arcade days. Here, players would pay a cash amount each time they wanted to play. Which is a model that is pretty brutal compared to what I’ve described above - imagine a mobile game that charged you each time you wanted to play? And certainly, arcade games were made more difficult on purpose, not just to stretch additional gameplay out of limited hardware, but to force players into repeated sessions to advance further. So this isn’t the first time we’ve seen the tactic of deliberately unbalancing the gameplay in order to advance profit. It’s more of a new iteration.

I won’t be able to settle the ‘good vs. evil’ discussion, but at least I hope that the knowledge of these tactics gives you something interesting to think about as you are playing games or building your own.

The Gamer Brain part 1: Why Games are Fun

I recently finished reading a book called Drive by Daniel H. Pink. It’s a fantastic book about human motivation and describes three attributes of real-world tasks - Autonomy, Mastery, and Purpose - that increase intrinsic reward. Tasks with these characteristics are enjoyable for their own sake, and require no external incentive. In fact, plying people with external rewards will frequently reduce the natural motivation to perform these tasks. For example, if you pay people a nominal amount of money to perform crossword puzzles, many will quickly lose interest in the task, even to the point of feeling resentment. But leave someone to their own devices without any reward, and they may be working on them happily for hours. This is very counter-intuitive from a traditional stimulus/response model of behavior.

As a gamer and game developer, this naturally got me thinking about the motivation involved with games. It’s very strange because it costs so much money and time to play games, and it can prevent us from achieving other real-world goals. Nor does it confer social status - in fact, it frequently does the exact opposite. But the obvious answer is that gaming is intrinsically enjoyable - in other words, it’s fun for its own sake - and therefore no external rewards are necessary. But that still begs the question, “why are games fun?” And Drive provided the perfect answer.

So it’s true that games and video games in particular can motivate players by what I call the ‘Rat Brain’ system of motivation. These are the various instinctual drives that affect behavior without requiring very much conscious thought. Evolutionary biologists refer to this system as the “Four F’s” - Feeding, Fleeing, Fighting, and Reproduction (har har). Games emulate the conditions that trigger these instinctual drives. For instance, fighting or racing games can raise adrenaline, much like a roller coaster, and cause an endorphine release when the tension is resolved. This is similar to how we respond to the fight/flight drives. And many simulation games will cause an almost compulsive need to monitor and allocate supplies. I would argue that this taps into the ‘feeding’ drive, in the sense that wild animals need to be constantly aware of their environment to ensure access to a future meal. As for reproduction, I would say that exaggerated physical attributes of games’ heroes and heroines at some basic level taps into this drive, as does the need for competition and dominance.

So these aspects will definitely motivate behavior - just look at any row of slot machines to see how powerful this basic stimulus/response pattern can affect humans - but gaming is motivating on a much deeper level than that. And that’s where Pink’s “Autonomy, Mastery, and Purpose” take over.

Think about all the open-world games like Grand Theft Auto, or the RPGs like Oblivion and Skyrim that allow you to be who you want to be and go where you want to go. These are perfect examples of games that give the player near-complete autonomy, and as a result it’s very satisfying as a gamer. Generally, players don’t like being lead down narrow corridors with huge signs pointing out every turn. 

The drive for mastery is evident in many games that require skill or reflexes. Every time you play the game, assuming the game provides the appropriate amount of visual feedback, you learn from your mistakes and get better over time. Obstacles that used to be challenging are now easy to bypass. And great games will be designed in such a way that allow the player to discover and master the rules of the world on their own, rather than have it explained condescendingly to them. It’s an extremely rewarding process.

And many games tap into the desire for purpose as well. Purpose does not necessarily have to mean improvement in the real world - it just means that you have a clear goal and your individual actions bring you meaningfully closer to that objective. It can be satisfied at a basic level by things like achievements or mini-missions, but a great narrative will also give a player purpose. Minecraft is hugely successful in a large part because players determine their own purpose (which also taps the Autonomy motivational source), and they’ll spend dozens of hours building a railway or a castle. Every block of cobblestone that they collect is used for this larger purpose, and it makes every action immensely satisfying.

But why are games such great sources of these motivational attributes? It is simply because games are built by developers that have complete control over the environment, its rules, and your progression through the world. In comparison, the real world is hectic, complex, and random. In the real world, we frequently don’t have the necessary autonomy to make our own decisions. Or the challenges we are presented with are too difficult or too easy, and we’re unable to learn and develop mastery at the appropriate pace. Or maybe we’re just working for an external incentive like a salary which strips tasks of their inherent purpose. But it’s the real world, and we don’t have control over these things. So that’s why people work for external rewards, while getting very little motivation from the intrinsic nature of the task.

Of course, work can feel intensely rewarding - provided the worker has sufficient autonomy, has a sense of purpose, and is gaining mastery. And there’s no doubt that games can feel like work as well, if they’re designed poorly and the player has little motivation to continue. This is further evidence that it’s not the specific action that is inherently rewarding, but the motivational context.

So remember that as a game developer you have complete control over the conditions of your game, and should take advantage of that to maximize the intrinsic reward for your players. If you’re building a new mechanic and it just doesn’t feel right, take a look from a psychological/motivational perspective and see if adding or boosting player autonomy, mastery, or purpose will turn a boring task into a rewarding - and fun - activity.

Part 2 covers the various psychological techniques that are used to make players spend money on virtual gaming goods.

Adding turn-based multiplayer in iOS 5 Part 3: Sending Match Data

(Back to Part 1 - Overview)
(Back to Part 2 - Starting and Loading Matches

Ok, now we have a turn-based match started and we’ve created a new game state. The first player takes some actions, and is ready to pass their match data on to the next player. You’re going to need to call something like this:

[self.myTurnBasedMatch endTurnWithNextParticipant:newParticipant
  matchData:gameData
   completionHandler:^(NSError* error){
show a message or something here}];

The self.myTurnBasedMatch is the retained GKTurnBasedMatch that you received from GKMatchmakerViewController: didFindMatch.

The completion handler is a method that allows you to present a success or fail message once the turn has been passed on, and maybe allows the player to quit the game.

The real key is the (NSData*)matchData. This is where you need to store all of the key properties of your game. That would include what level or map you are on, some attributes of the players, what actions they took during their turn, etc. 

But you’re probably storing your game data in a local NSDictionary. So how do you turn your game data into NSData?

One way to do this is to use NSKeyedArchiver.

[NSKeyedArchiver archivedDataWithRootObject:gameDataDictionary]

Previously, there was a 4kb size limit on turn-based match data, which was fairly restrictive. But as of February 1st 2012, this was raised to 64kb (source: https://developer.apple.com/news/index.php?id=02012012a). You can transmit a lot more data now, but you may still want or need to optimize your match data for faster downloading. Fortunately, there’s a nice alternative available called NSPropertyListSerialization:

NSError* error = nil;
NSData* compressedData =
   [NSPropertyListSerialization 
   dataWithPropertyList:(id)gameDataDictionary
   format:NSPropertyListBinaryFormat_v1_0
   options:0
   error:&error]; 

There are several formats, but NSPropertyListBinaryFormat_v1_0 will give you the smallest size. Using NSPropertyListSerialization will easily cut your match data size in half.

So the second player will now receive that compressed data. But then you’ll need to convert that compressed property list back into a readable game data dictionary:

NSError* error = nil;
NSPropertyListFormat plf = NSPropertyListMutableContainersAndLeaves;
NSMutableDictionary* gameData =
   [NSPropertyListSerialization propertyListWithData:matchData                      options:NSPropertyListMutableContainersAndLeaves                                  format:&plf
   error:&error];

There is one other consideration. You’re probably using your own classes and objects to store game data, at the very least something like a Player class. And your gameDataDictionary is probably going to contain an array of Player objects. But if you try and use NSPropertyListSerialization on a dictionary containing custom objects, you’ll get the following error:

Property list invalid for format (property lists cannot contain objects of type ‘CFType’)

This is because property lists can only contain the following object types: NSDataNSStringNSNumberNSDateNSArray, or NSDictionary.

Not a problem though. You just need to encode your custom class (“Player”) into one of those supported formats, preferably NSDictionary. In this case, all of your Player properties are added as entries in a dictionary, and then that dictionary is sent in matchData. On the receiving end, you’ll need to convert your NSDictionary back into a Player.

Here’s some more detail on this item. First, create a method within your Player class (or whatever custom classes you’re using) that converts your Player class into an NSDictionary or NSArray. For instance:

-(NSDictionary*)encodedPlayer
{
   return [NSDictionary dictionaryWithObjectsAndKeys:
   self.playerName, @"playerName",
   [NSNumber numberWithInt:self.goldCount], @"goldCount",
   nil];

}

Then when decoding the match data, you’ll need to recreate your player from the dictionary. Basically the reverse of the process above. It would look something like this:

   
NSArray* playerArray = [matchDataDictionary objectForKey:@"players"];
for (NSDictionary* playerDictionary in playerArray)
{
   Player* decodedPlayer = [[Player alloc] init];
   decodedPlayer.playerName = [playerDictionary objectForKey:@"playerName"];
   [self.players addObject:decodedPlayer];
   [decodedPlayer release];

To save space, make sure you’re only including properties of your objects that can not be retrieved any other way. If you have calculated derived properties of objects, leave them out of the property list dictionary and instead re-derive them after loading the match data on the receiving player’s end.

As a final note, if you’re really pressed for space, NSArray is about twice as space-efficient as NSDictionary. But it makes uncompressing data a bit more difficult because you’ll need to worry about trying to retrieve array indices that might not be there, either because the data element is blank, or maybe you added a new property between game versions. But can definitely be worked around if space is a premium. If you like, you can have your main game data stored in a dictionary, and all of your custom objects serialized as arrays.