It should be clear to anyone that is interested in computer games that the mobile gaming market is growing very fast and, with smartphone penetration still accounting for only 40% in even major markets, that there is room for a lot more growth and for several years still.
It is also clear, to anyone who is actually making mobile games, that creating a game that people want to play en masse, let alone pay for (or in) en masse, is extremely hard. There are already over 130,000 games already submitted to the Apple App Store. Games like CSR Racing may be pulling in US$12million in their first month, but there is a very long tail in action here and the average revenue for a mobile game is reportedly less than US$4,000. Whilst it is still theoretically feasible to develop a mobile game for a few thousand dollars (working unpaid still has an opportunity cost even if there is not an actual monetary expenditure) most games from professional studios will have development budgets ranging from US50,000 to as much as US$1million.
The costs do not stop at simply making a game; far from it, next comes the marketing cost. Developers that base their plans/hopes/dreams around some form of free, natural virality are most likely going to fail. This is especially true of iOS games where (a) getting discovered requires being at the top of the charts, and (b) getting to and staying at the top of the charts costs lots of money. Putting that even more succinctly; getting visibility for your app WILL cost money….and no small amount of it.
Developers frequently drop a pot of money into user acquisition services such as Tapjoy (players are incentivised to download your game) or FreeAppADay (where players go to find normally paid-for apps being offered for free temporarily). These, and other methods, invariably cost from $10,000 and upwards on ‘day 1’. For a game to be profitable it needs to:
(1) generate revenue per user (ARPU) at a rate that exceeds the average cost per user (ACPU)
(2) reach a critical mass of users to ensure that the ‘net’ profit covers the initial development cost.
We must also consider that ‘net’ revenue is the gross sales revenue minus a whole host of direct costs starting with Apple (30%) but possibly also including any sales taxes, licensing costs, publisher’s cut, partner revenue share and on-going infrastructure (e.g. server) costs.
It is also very rare for a game to be created then launched then left unattended. We are in a ‘games as a service’ era and games are usually hooked up to some form of user behaviour data collection and analytics tool nowadays, meaning that developers can see what is working and what is not. That means not just technical bug fixes but user interface improvements, tutorial re-working, revisiting game variable to achieve better balancing, editing narrative, creating new content and new features. A game that does at all well will invariably be ported to other platforms (Android, Windows mobile/8, Amazon Kindle) and/or be localised for different territories. That’s more cost folks.
So, making games, marketing them and maintaining them costs a lot of money. It is a crowded market and one where customer loyalty is low and where new/different games are foisted at players from all angles. If, therefore you want to make games for the mobile phone and tablet market, you had better be clear about what kind of games you are going to make if you want to have a chance of achieving breakeven let alone amassing huge profits. What are the options? I boil these down into four (broad but distinctly different) game types. These are:
 Casual games (that work on mobile devices) – ‘play by yourself on the move’
Conceivably this can includes games that involve more than one player – e.g. two players, one finger each on same screen – but is invariably about single player games. If done right then the games are designed for the specific hardware capabilities (some might say ‘limitations’) of mobile devices but many are copies of web, PC or console games which are simply ported to mobile because it is feasible to do so not because it is sensible to do so. Cut The Rope, Plants vz Zombies and Fruit Ninja are exemplars of this category of game but for each of these there are a hundred (make that ten thousand) Tic Tac Toe clones and shoddy platformers. If you make this class of game then you need to be highly aware that the only benefit you have over console, PC and browser games is that your game can be played on the move. Design for that modality of use not for what is technically achievable.
 Casual social games – games that have a (vaguely) social layer where you ‘play by yourself….then see if your friends can beat your score’. Put another way; ‘games that are given another dimension because your friends are involved to some degree’.
These games are usually characterised by being a fundamentally single player experience on top of which is bolted a ‘challenge friends’ and/or leader-board functionality. This is rapidly becoming the de facto design pattern for mobile games. I regard this as a somewhat lazy and possibly an commercially finite approach. It is often achieved with basic functionality provided by third party services such as OpenFeint or GameCentre that very much looks and feels ‘bolted on’ rather than having been crafted to enhance the player experience. This also leads to several frequent interruptions to the playing experience in the form of registration, login and pop-up leader-board or achievement screens that look completely different to the game art and UI. If this is done well, e.g. where the playing experience is genuinely enhanced by the ability to try to perform better than people you know, then there is quantifiable end user value. This doesn’t disguise the fact, however, that the product is essentially still a single player game. These services also all exit to ultimately build a user-base for the service itself (e.g. to engage the user with advertising or cross-promotion interstitial ads) and that commercial goal conflicts with the game developer’s goal of engaging and retaining their player as long as is possible.
There is a secondary type of game in this class that closely resembles the Facebook/browser-based ‘social game’ type. Numerous social games have made their way to mobile devices (e.g. Farmville, CityVille and Ravenwood Fair) however the game-play remains fundamentally of a single player nature which is augmented with the social mechanics of, for example, gifting, sharing and visiting and where such behaviour is rewarded with free virtual goods, in-game currency or other utility value. Despite seemingly interacting with friend’s in-game on a frequent basis, the nature of those interactions exist solely to bring about free user acquisition for the developer rather than to deliver intrinsic fun from playing. You interact with your friends because you have to not because it makes the game more fun in of itself.
 Synchronous multiplayer games – ‘play with or against other (probably quite hard-core) players in real time….on a mobile device’.
These kinds of games are rare and for two good reasons: firstly, they require a level of technical infrastructure and service provision that is typically very expensive to put in place and to maintain, and, secondly, because it is statistically unlikely that any one player has many friends that likes (an downs) the same game they do and whom are able to play that game at exactly the same time on a regular basis as they do. There is also the factor that in order to do so they may also require the same device/platform as you. ‘Android on a Samsung? Sorry you need an iPhone 4 or higher to play this game”.
Synchronous collaborative or competitive play is major aspect of the PC and console gaming experience where play sessions are much longer, happen at more regular (often coordinated) times and in environments conducive to that activity e.g. where you can strap on a headset and swear a lot. The very nature of synchronous gameplay tends to lend itself to more traditional, or ‘hard-core’, games genres which is not mass market (when expressed as a subset of the mobile phone gaming market overall). Mobile game play typically happens at unplanned opportunistic times, for very much shorter sessions spread throughout the day at a wide variety of locations many of which do not offer a reliable cellular or wifi network connectivity. I see synchronous (‘real time’) multiplayer gaming as a small niche that offers creatively interesting but commercial limited opportunities.
 Asynchronous multiplayer games – games where ‘the entirety of the fun is derived because you are playing with (or against) friends but which do not require an immediate data exchange’.
This is the class of mobile game that I think truly fit the ‘social mobile game’ definition. Whilst a real time (type 3) game is clearly about a genuine interaction with other (real) people and fundamental to gameplay, the very fact that this will be practical to only a very minor subset of mobile gamers make it, IMHO, by definition ‘antisocial’. Asynchronous mobile games, when done well, deliver playing experiences that are very much enhanced by the involvement of others but which do not fail to cater for the very real modality of mobile device usage (‘anytime, anywhere’). Indeed, these games deliver an experience that is intrinsically fun because they are using a device that exists to enable communication and interaction between people who are not physically together in the same location and which does not require cumbersome peripherals or – at least not all of the time – power supply or data connectivity. Asynchronous games can be somewhat ‘lossy’ in that the exchange of data isn’t overly time-sensitive.
My archetypal example of this kind of game is Draw Something (OMGPOP/Zynga). It’s success may have been over a fairly short time frame (approx. 6 months) but it reached 90million downloads and delivered outstanding revenues (reportedly $50-75million).
The title of this ’blog is about where I believe the (greatest) opportunities lie for mobile gaming. Given that commercial success is highly dependent upon successfully acquiring users and at a cost that is less than the revenue that they generate, how then do the different types of game (as defined above) contribute, or not, towards this goal?
Casual mobile games – no direct user acquisition benefit. These games lack both the instruments for users to spread the word to other users and the intrinsic motivation for them to do so. You are playing a single player game on your mobile device. Your progress in game and enjoyment of it are totally unrelated to whether or not your friends may be playing it. Score 0/10
Social casual mobile games – some benefit if the developer owns the user data, however that is rarely the case when using third party APIs such as OpenFeint. Zynga have a whole raft of ‘X with friends’ games in this category and have built an eco-system aimed at capturing that user data and then cross-promoting their games (thus avoiding the $2/user cost of acquiring users through other channels). Most developers are unlikely to be able to afford to replicate that ecosystem too any degree. Equally, as these games can be played as a single player experience, the user’s motivation to connect social network accounts and to enable ‘sharing’ etc is not necessarily high. Visibility of the game name and link on Facebook is a positive factor but one that is limited by the fact that the game isn’t immediately playable on that platform if you are not using Facebook on the same mobile device. Score 5/10
Synchronous multiplayer mobile games – whilst there is the logical argument that players must have other players with whom to interact with in this case, (a) the potential user reach is fairly insignificant, and (b) the likelihood is that you will be paired with/against strangers by the system (in order to ensure there are enough people to take part) rather than being required/motivated to bring new players that you actually know into the game. Score 2/10.
Asynchronous multiplayer mobile games – these are the very definition of what makes the foundation for a genuine virally-promoted game as you have to have friends to play with or against or you can’t play yourself. There is not alternative state. These games – such as OMGPOPs Draw Something – invariable involve a very early screen asking you to connect Facebook or Twitter accounts or to send out email invitations. There is certainly a trust barrier here and having a genuinely stellar game offering is unquestionably of fundamental importance, but get that right and your entire user-base is acting to expand itself. Make a great game that is unquestionably fun and which delivers that fun over a sustained time period (e.g. has longevity to the play experience) and you have a hit on your hands that should only need seeding with an initial paid-for user-base. Score 10/10.
So, asynchronous multiplayer games it is then…..but what makes for a good asynchronous game?
Mobile gameplay needs to be designed not simply just to work on mobile devices but also to be designed for the mobile device user. These are quite different things that are often overlooked. Just because the iPhone 4/iPad2 could deliver highly impressive raw computational and graphical power capable of delivering ‘near console’ game experiences doesn’t make it appropriate to do so. Who has 20+ hours to play a game on their iPhone where each level takes 20minutes or more?
An inelegant but essentially accurate term to describe the prevalent modality of use is ‘dip in and dip out’ gameplay. Contextual scenarios involving stops at traffic lights or being in the queue in Starbucks typically get used to illustrate this and these resonate with casual geeks and professional analysts alike. They also ignore the fact that something like 50% of mobile game play time actually happens in bed or on the sofa where the user sessions are not measured in seconds but dozens of minutes. ‘Dip in and dip out’ gaming is certainly very important but it is not the only factor.
We are only just beginning to understand the specialist craft of effective mobile game design but a crude rule of thumb of revaluating any game concept’s appropriateness for mobile deployment (versus PC, Facebook etc) could simply be:
 Is this game fundamentally fun because I can play it anytime and anywhere?
 Can I start playing, stop playing and re-start playing with minimal ease?
To those questions we can then assess the level of genuine organic user acquisition by asking:
 Is this game made fun because people being able to play with or against their friends is central to it’s design?
If you can answer ‘yes, yes and yes’ then go build that game!