Erik Asmussen's Dev Blog

I recently released a free demo of Robot Roller-Derby Disco Dodgeball on Steam. I figured at the same time I would run some ads on reddit to see if I could boost the impact of releasing the demo. I managed to dig up some interesting results and wanted to share them.

Reddit Clicks

During this test I ran two campaigns. One was longer and targeted at r/Games, a popular subreddit dedicated to industry news and relatively in-depth gaming discussion. The other was shorter and targeted at a category reddit calls 'gamers', which includes subscribers to a wide selection of game-related subreddits. I spent $200 on each campaign, using the same ad for each. Here are my results:

The important numbers are: $200 on r/Games delivered 165K impressions and 714 clicks at $0.28 cost per click. $200 on 'Gamers' delivered 270K impressions and 625 clicks at $0.32 cost per click.

At first glance, the second campaign ('Gamers') appears to have higher spikes, but that's mainly because it was run on a shorter duration. The broad Gamers campaign actually had fewer overall clicks then the narrow r/Games campaign. However, because a wider targeting is cheaper per-impression, my cost-per click wound up being very similar (around $0.30).

One big difference is I got about 60% more impressions out of the broad Gamers campaign. Impressions are important because they have intangible benefits of raising awareness and possibly driving traffic through direct searches via Steam. So in the future I would probably continue using the broad Gamers approach.

I'd say the $0.30 cost-per-click is a decent result, definitely better than what I've gotten in my Twitter ad experiments. With revenue per-game sale at $7, I would need about 1 out of 23 clicks to convert to a full sale in order to be profitable. This is fuzzed a bit because some people may buy the game much later on sale, some people may not click on the ad but buy the game anyways because they saw it on reddit, some people may buy a 4-pack, some people might cause 20 other people to buy it. But it's a good point of reference.

Steam Traffic

What did these ad clicks mean once people got to the Steam page? Fortunately, Steam now provides detailed traffic analysis. Here are my stats for the demo during that time period:

The big green line represents traffic primarily from the Steam New Demos page, and the purple line represents external site traffic (not stacked). 70% of those external traffic hits are from reddit, so you can consider the purple line the 'reddit' line. As you can see, there's a slightly elevated level during the first weeklong r/Games campaign, and more of a spike during the two-day Gamers campaign.

The majority of total traffic came from the page where Steam lists recently released demos. So in that sense, $400 of reddit advertising drove only a fraction of the game page traffic as what the Steam New Demos page provided.

However - traffic from the Steam New Demos page increased during the second reddit campaign, even though you would expect a steady downward decline as it moves from the top of the list. Is this spike a result of those 200K impressions raising awareness ? Quite possibly. Here is a comparison of Disco Dodgeball game page views that came from the Steam New Demos page (top) compared to total overall impressions on that page. 

You can see a big spike in clicks from the New Demos page even though overall impressions was constant. I think this is a good sign that raised awareness from the reddit ad triggered a greater clickthrough rate while it was in that list. 

Steam Downloads

It is very important to note that game page traffic is not the same as actual downloads, so I'll break that down now.

Here is a chart that shows downloads of the demo over the same time period:

Unfortunately, the first reddit campaign is washed out by all the traffic coming from the Steam Demos page, so it's tough to draw a conclusion there. However, that second huge spike can almost entirely be attributed to the second reddit campaign. At that time, there is a matching spike in traffic both directly from the reddit ad and from increased clickthrough on the Steam New Demos page. It looks like an increase over baseline of 200-250 demo downloads. So basically, that means the cost of the second ad worked out to about $1 per demo download (plus all the intangible benefits).

Conversion to Sales

Ok, so if we've estimated that it's $1 per demo download, that means I can be profitable with the ad if 1 out of 7 demo users eventually buy the full version - about 14%. Unfortunately, my conversion rate from demo to paid is actually closer to 1%. I don't know what the Steam standard is, but I'm guessing there are these specific factors involved in my particular case:  

- I designed the demo as a 'long-term' sell - players can get a lot of playtime out of the demo including most multiplayer content, with the goal that dedicated players will find value in the advanced features as they invest more playtime. I'm hoping/expecting conversion rate to go up over time based on this approach.

- The game is still in Early Access, which tends to deter full version purchases.

- The game itself is very highly rated (99% positive), so I don't think it's an issue of game quality. But players getting a free demo are inherently less invested in the game than someone that made a purchase, so it's possible the wider population of demo players are less interested in the game than the core group that bought it. I will need to compare playtime of demo vs. paid players to see if demo retention is a problem.

- The number of players that have added Disco Dodgeball to their wishlist is steadily increasing, at this point at a rate faster than actual sales. I don't have full historical data on this so it's hard to tell exactly what the impact of the demo is on wishlist additions. But if a ton of people add the game to their wishlist and then buy on launch date, then the demo has done exactly its job.

Key Takeaways

- Targeting Gamers instead of r/Games got much higher impressions for the same cost with only slightly fewer clicks.

- The large number of impressions from the ad likely drove additional awareness and demo downloads when the game appeared elsewhere in Steam.

- $200 of traffic from reddit ads resulted in less traffic, but equivalent demo downloads as the Steam New Demos page did.

- For every $1 spent on reddit advertising I got about one demo download. 

- Increasing click-rate of the reddit ad, improving the promotional materials on the Steam game page itself, and increasing conversion from demo-to-paid are all ways to improve the effectiveness of this spending.

- It seems likely that demo players are adding this game to their wishlist, but the big question remains of how many will purchase on launch date or later in the future.

- The actual near-term financial benefit is low, but I think there are good indications that this investment could be worthwhile over a longer term.

- Even if a free demo player never buys the game, they are adding value to the game because Disco Dodgeball has a big multiplayer component and their presence help build up a community of players and provides a boost to network effects.

It's been a great year-and-a-half of development of Disco Dodgeball, and it finally seems like almost all of the major features I wanted for its official release are in place. So it's time to start wrapping things up and prep for its launch out of Early Access and have it become a 'real' game! 

My schedule of events for the next several weeks are:

Steam demo

Trading Cards

Some more singleplayer content

Steam friends / clan integration

Attempt to get dedicated servers up and running

Finalize in-game and promotional assets

Launch trailer

With all this considered, I think a launch date in late January 2015 will be a good target. It looks like it's a nice window where not a lot of other things are launching and perhaps press and YouTubers will be looking for things to talk about. Specific dates / pricing will be figured out soon.

The game will not be discounted again until it officially launches because I want all those people that have been on the fence to grab it on launch day for maximum impact. It's on almost 10,000 wish lists and if they all got the game at the same time it could be a huge boost!

I also won't be doing GDC or have a booth at PAX East this coming year. They were both tons of fun, but also very difficult as a solo developer and the return on investment was not significant enough to justify the cost. I think I'll have enough to focus on with launch and can also use that saved money for advertising and game assets.

I've been working on a proper demo for quite a while. I originally had the free alpha version up on my website and was unexpectedly popular (about 100 visits per day), but felt it didn't reflect the current quality of the game.

I tried uploading a more recent webplayer demo but I couldn't get the file size down to an acceptable size. Plus, it requires the Unity plugin which turns away a lot of people.

So now I'm figuring a Steam demo could allow for a more reasonable size, provide easier updating, and tap into the default Steam visibility for free demos. I know a lot of games have had mixed results with providing demos, but I think DD is a game that demos very well and I can structure it in a way that makes the full version very compelling.

I'm willing to take kind of a risk with this demo by providing a lot of functionality in the free demo (including online multiplayer), and making the demo and full versions share the same servers. There are a few catches though, and hopefully the value of the full version is made clear.

Demo players can use Quick Play (which will launch them into any existing match, or create a new random room if no rooms exist) but they will not be able to create their own custom matches or find/join specific matches. There's some interesting outcomes from this setup:

Full Version players will gain the benefit of having a lot of extra players in their rooms.

Demo players will be able to experience a lot of the functionality, but they won't be able to try out the specific modes and features they like on demand.

Demo players won't be able to easily join up with friends, because they'll be randomly placed in rooms.

My goal is that players that enjoy the demo will find enough content that they keep coming back, but once they get hooked they will start to want better control over the matches they play. It's kind of like MOBA-style monetization where you can try out a bunch of heroes, but can pay to guarantee access to the ones you really like.

Another restriction is that stats, XP and leaderboards are not tracked in the demo. Players are reminded of this on the round results screen after each match. The hope is that demo players feel an opportunity cost by not having their stats tracked and not gaining levels. For someone that is really into the game, this could be a strong reason to upgrade.

Lastly, I'm allowing unlimited Bot Matches but with restrictions on the arenas that are available. It seems players really enjoy a wide variety of arenas and for players that are using the demo a lot, the obvious advantage of extra variety might push them to buy.

Oh yeah, and demo players won't have any moustache on their robot : )

Recently there's been a lot of discussion around the ethics of compensating YouTube channels for coverage. These arrangements can take the form of 'Brand Deals', where a channel is financially rewarded and given early access to a sought-after title in exchange for positive-slanted coverage. The general opinion is that as long as these agreements are disclosed, then consumers are sufficiently informed. However, it's not quite as simple as that because of some powerful psychological forces that may not be apparent to consumers or content creators.

Cognitive Dissonance

As human beings, we have an incredibly strong unconscious motivation to maintain a consistent world-view. This means we have constructed a mental model of the way the world works - these people are good, these people are bad, these beliefs are true, etc. This model of course includes a view of ourselves - and we generally think of ourselves as honest, rational, positive forces. (Nobody thinks they're the bad guy!). This belief structure gives us great comfort.

But sometimes we are presented with information that is at odds with our mental model. The introduction of conflicting data that must be reconciled creates a mentally painful state called 'cognitive dissonance'. It's very difficult to throw away beliefs that have given you comfort and guidance for many years, and so people tend to resolve this state by rejecting the new information to fit with their existing world-view. Naturally, we aren't consciously sorting out our thoughts in this way - it is a subtle and automatic process. It means that every human basically is equipped with a huge invisible information filter, and is a big reason why polarization tends to happen in things like politics.

Psychology of Paid Coverage

So how does this relate to games coverage? Well, put yourself in the shoes of a YouTube channel. Someone approaches you with a compelling offer to give you access to a hyped-up new game and pay you in exchange for a few videos or tweets about it. Being an ethical person, you agree to the deal only on the condition that you enjoy the game. But it's at this point that you become subject to cognitive dissonance. 

Nobody wants to think of themselves as a sellout - someone that would betray their audience and hype up a bad game for a paycheck. So an incredible thing happens - for people that accept these brand deals, their subjective perception of the game is unconsciously nudged in a positive direction so that they can more comfortably feel that their advocation of the game is honest. They tend to wind up with the pleasant belief that 'The game is good, I would happily have promoted it anyways'.

Perhaps this is true, but it's also extremely difficult to be aware of our own biases. And this effect is not going to take an extraordinarily terrible game and suddenly make it GOTY. However, it can definitely influence things like word choice, enthusiasm and benefit of the doubt granted to a title, and therefore give an overall more positive tone to coverage than it would have had otherwise - which may then go on to impact consumers' reaction and buying decisions.

Disclaimer

I know that creating YouTube content takes a lot of work, is subject to normal business considerations, and feel that these channels should be properly rewarded for their effort and impact. Sales of my game Disco Dodgeball have substantially benefited from video coverage that it has received. (I have not done any paid deals.) YouTube channels fill a lot of gaps that traditional press will miss, consumers are generally more informed as a result, and I hope that this symbiotic relationship between games and YouTube channels will continue for a long time.

I'm organizing a big Disco Dodgeball competition to raise some money for charity and also get more people into the game! I'll be sending out more info soon, but here's the high-level details:

During the event week, participating streamer channels will challenge one another to 5v5 team duels. Timing / match format is up to channels and whatever is most convenient for them. You might just do one big matchup, or a best-of-17 series - whatever you want!

Streamers can recruit a team from either their subscriber base or from a list of players that sign up on the game's Steam forums. I'll do the work of matching players to time slots if channels need extra players to fill out a team.

I'll also help match streamers among each other if you just want to play against random channels.

The game will be sold at a discount for the duration of the week.

Half of game sale proceeds during the week will be donated to charity.

If you're a streamer and want some keys to hand out to your subscribers for training purposes, I'll be able to provide them

I'll maintain a public calendar of all the participating channels and the times for which they've scheduled their matches.

If you'd like to participate as a channel or as a potential player, just join the mailing list here and I'll send out specifics when they're ready.

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 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.

(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: NSData, NSString, NSNumber, NSDate, NSArray, 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.

(Back to Part 1 - Overview) (Skip to Part 3 - Sending Match Data between participants)

For the rest of these posts, I'm going to assume you're using the default GKTurnBasedMatchmakerViewController - mainly because I haven't gone through the process of creating a custom one, so my advice would be useful in that context.

In this post I'm going to discuss a bit of detail around initiating a new match, or loading a match in progress.

For both situations, you only need one GKTurnBasedMatchmakerViewController instance. It automatically detects if you have any matches in progress, and if you do, it'll present the current game list. Otherwise, it'll bring you directly to the new game setup screen.

The 'matches in progress' list automatically splits your games into 'Your Turn', 'Other Player's Turn', and 'Game Over' categories, which is determined by the GKTurnBasedMatch data. Specifically, this is derived from the currentParticipant and status (GKTurnBasedMatchStatus) properties.

This view will update in real time if one of your matches change, which is very nice and saves you some coding work. I've found that if you delete a match directly from this view programmatically - that is, without using the swipe-to-delete UI functionality - it will not update the view immediately. This is probably a bug that will get fixed eventually, and won't affect you if you don't code in some background delete functionality.

This view also features a plus button in the top-right, which brings you to the new match view. And that's why you don't need to create two separate view controllers for games in progress or new games.

Also, the logic for initiating a game is very similar through both the 'games in progress' and the 'new game' screens. Both will call this method as soon as you click on an existing match or hit the 'Play Now' button:

turnBasedMatchmakerViewController: didFindMatch:

This returns a GKTurnBasedMatch object. You should immediately store this match in a retained property. You'll need to access it later, and there's no guarantee it'll still be around then unless you retain it. For example:

self.myTurnBasedMatch = match;

After retaining your match, you still need to load your match data. To save bandwidth, match data is only loaded upon request and it'll be nil until you explicitly load it. So within the didFindMatch method, I call the following method on the newly retained GKTurnBasedMatch object:

loadMatchDataWithCompletionHandler:

This will return with an NSData object representing your match data, and will also update the data of your retained match. Remember at this point you may either be starting a new game, or loading an existing game. You can tell the difference by looking at

[matchData length]

If this is 0, then it means you have a new game. Note it will not be nil - match data is only nil if you haven't loaded it yet.

If you have a game in progress, proceed to update the state of your game based on the match data - I'll cover some detail about how to do that in a later post. If you have a new game, initialize any state variables that you need. From there, simply present the game view.

One last piece of advice - You will probably run into a situation where you need to update the game logic (or possibly fix a critical bug) between app versions. You will probably want to make the app versions incompatible, or else a player with the fixed version might be matched against a player with the old buggy version. However, any games in progress are not affected by multiplayer compatibility. So you need some logic within your app to detect version incompatibility within this match loading process.

The best way to do this is to have a variable within your matchData that specifies the minimum app version for compatibility. When each player takes their turn and updates the match data, they should update this value with the minimum version of the app that is compatible with the one they are on. When loading matches, you should compare the current player's version to the minimum version, and if it doesn't meet the requirements, cancel the match load and prompt the user to update their app instead.

For example: Player 1 is stuck on old version 1, and Player 2 just upgraded to new version 2. The versions are incompatible. Player 1 takes their turn, and minimum version is set to 1. Player 2 takes their turn, and updates the minimum version to 2. Now when player 1 tries to take their turn, it'll know their app is out of date and will cancel the match load.

On the other hand, if you do want both versions to be compatible - if you're just updating some graphical element - Player 2 should keep the minimum version at 1. Then both players can continue playing without interruption.

(Skip to Part 2 - Starting and loading matches) (Skip to Part 3 - Sending Match Data between participants) 

I recently released a new version of my digital board game New World Colony to include support for the turn-based online matchmaking feature in iOS 5. I learned a lot, and am really excited about the potential for this feature because it allows lesser-known titles to have robust multiplayer. I'd like to share my experiences from this process in order to help other developers implement this feature in their own games.

First of all, why implement this feature? The biggest reason is that it greatly expands the use that players can get out of your game. Although multiplayer has been available in iOS for a while, until now it was only possible to create real-time matches (without creating your own game server, that is). This meant that players needed to be looking for matches at exactly the same time, and for games with small audience, it's almost impossible to reach a critical mass where enough players are online to form an active community. Turn-based matches allow players to start a match whenever they want, and they will be joined by an opponent at some future point in time. Play can pass back and forth without the need for both players to be playing at the exact same time. 

The other great reason is that players are probably hesitant to start an online match if they don't have a huge amount of free time - they don't want to have to quit in the middle of a game. However, with turn-based matches, this allows players to pick up a game, play a turn in about a minute, and set it back down. So it greatly lowers the time commitment for any single play session, and this is a huge bonus for mobile games.

Ok, so how do you add this to your game? Here's the high-level details. I'll go into each of these steps in a bit more detail in later posts.

Initial setup

The very first step is to authenticate your player with [GKLocalPlayer localPlayer] authenticateWithCompletionHandler:]. As soon as the player is successfully authenticated, you should set the delegate for the [GKTurnBasedEventHandler sharedTurnBasedEventHandler]. Doing so will allow your device to receive updates such as when a match ended or the turn changed from player to player. 

Creating a Matchmaker View

At this point you'll have to make a pretty important decision. You'll need a way to present users a list of all the games they have in progress. Do you want to use the built-in matchmaker view controller, or build your own? There are some significant pros and cons.

Using the out-of-the-box matchmaker saves several steps up front, and updates automatically as soon as a turn event is received which is very nice. However, it also allows users to quit out of turn and erase matches at will, which create quite a large headache because of all the new edge cases you'll need to take care of, and it will make tracking stats and achievements much more difficult (more on this later). Building your own games-in-progress view gives you better control over these events, but obviously requires more work because you need to download all the match data and format a view controller yourself. 

For New World Colony, I used the out-of-the-box matchmaker view to present games in progress. However, if I were to start again from scratch, I probably would have created my own view because it can eliminate many of those annoying edge cases that can wreak havoc with your game logic.

Setting up a new game

The GKMatchmakerViewController optionally displays games in progress, but it can also let users create new games. For simplicity, I would definitely recommend using the GKMatchmakerViewController to do this rather than creating a custom solution. It saves you lots of steps, and very nicely also includes a place for users to rate the game (which as you may know can be a challenge otherwise). Players can set the number of participants, and invite other players as well. You get a lot of functionality for 'free'.

Loading match data

Assuming you're using the GKMatchmakerViewController - once a player selects an in-progress match, or starts a new match, your GKMatchmakerViewController Delegate will receive a 'didFindMatch' notification and hand off a GKTurnBasedMatch object. You should never create GKTurnBasedMatch objects yourself - instead, matches will be handed to back to you from the matchmaker. You can also call [GKTurnBasedMatch loadMatchesWithCompletionHandler:] to retrieve an array of matches.

Once you've got your match, retain it, and then load its data by calling loadMatchDataWithCompletionHandler on it. This will return the all-important matchData property of your GKTurnBasedMatch. Without this, your GKTurnBasedMatch will not have any data and you can not restore its state properly.

On brand new games, the 'participants' property of your GKTurnBasedMatch will contain the current player, and several placeholder participants that have a status of 'matching'. That means they'll be filled with real players later on when they join up. 

Now that you've got your match data you can use it to recreate the game state. If the [matchData length] is equal to 0, then it means you've got a new match and you can create a new game state. 

Note that when a player creates a new game, they may actually be joined up into an existing match that is waiting for an opponent. So even if the user is creating a new game, you may actually have existing match data that you need to process.

Ending the turn

Ok, the player has taken some action and it's time to end the turn. It's fairly easy to pass the turn to the next player. Simply call endTurnWithNextParticipant:matchData on your currently retained GKTurnBasedMatch. You need to tell the match who will be the next participant, and what the game state data will be within matchData. Be warned that the match data has some size restrictions on it, so you need to carefully compress your match data. I'll offer some tips on that later on as well.

If the player had invited a friend during the initial match creation, this is when that player would receive the invitation - not when the match is first created. Also note that if any player declines an invitation, the entire match is cancelled immediately. 

Notifying users of their turn

It's important for other users to know when their turn is up. Remember the GKTurnBasedEventHandlerDelegate that you set up earlier? Now's when that comes into play. All players (except the one who just ended the turn) will receive a notification through this delegate via the method handleTurnEventForMatch:(GKTurnBasedMatch *)match. 

It's up to you to determine if it's actually the local player's turn on each device. Fortunately, it's easy to do this by looking at the currentParticipant property of the match you were just handed. If the currentParticipants's player ID matches the player ID of the locally authenticated user, then you can notify the local player that it's their turn - preferably using the handy GKNotificationBanner class.

Ending the game

On the surface, this is fairly simple. When a player meets a certain victory condition, you can call endMatchInTurnWithMatchData: on the currently retained GKTurnBasedMatch. All you need to do is update all the match participants' matchOutcome properties (so we know who won or lost), and send the new match data. It'll notify the other users that the game is over, and that's that.

But this has the potential to get extremely complicated. For instance, what if a player surrendered? Or the game finished due to hitting a turn limit and you want to ensure the winning player gets notified? When and how do you adjust stats and achievements? These complexities will be discussed in a further post as well.

Wrapping up

So that's a high-level overview of how your game state needs to flow. It's fairly easy to get a basic game going, but as I hinted at, there are some subtle complexities that can create a lot more work for you. 

I'll follow-up in the next few days about some specific implementation guidelines for what I've covered above, and will provide some source code for you to hack at yourself.

If anything is unclear, please let me know in the comments and I'll either update the post or address it in a future post.

There's a lot of great stuff in iOS 5 (including a list of features which can be viewed here) but the feature I am most excited about is the built-in support for turn-based online matches.

I can't get into specifics since it's still under NDA, but a good summary of what users can expect from this feature is available on Gamezebo.com. In essence, developers can fairly easily make their games offer 'play-by-mail' matches like Words With Friends currently does.

The reason this is so exciting is that I think it's going to drastically improve the usefulness of Game Center, especially for smaller developers. While Game Center is currently great at high-score leaderboards, its matchmaking service leaves much to be desired. Essentially, players need to be searching for a match at the exact same time in order for a game to occur. This works for extremely large and popular games, but for the vast majority of games the service is almost useless because the chance of finding another live player is extremely low. And the chances are even less if you try and add custom match settings, or more than two players.

So allowing for asynchronous matches is huge since it means that multiplayer is now an option for games of all sizes where it functionally was impossible before. My digital board game New World Colony has a functioning single-player mode, but its multiplayer lobby is a barren wasteland. Which is pretty tragic for a game that is built for human vs. human matches. So iOS 5 will make a dramatic difference for players of this game, and I think has a chance to expand its user base by a significant amount.

In fact, when designing future games, I would almost definitely implement some kind of turn-based mode to allow for this feature. Real-time matches just aren't feasible unless you're a big-budget studio, and having online matches can drastically improve the use that players get out of your game.