How About a Gaming PaaS?
The Game Development Lifecycle
Generally speaking, a strong social game development team can produce a new social gaming title in less than 6 months (15 people or so), for somewhere between $750K – $1M. You then spend about 2-3 months in beta testing where you perform your A/B optimization.
Social analytics company, Kontagent, is one of a few who is trying to help new social game producers execute a systematic way of optimizing the game – improving specific metrics whether they be the purchase of virtual goods, upgrading to a paid account, increasing viral referrals/invitations, or simply getting people to spend more time playing. At the end of the 8-9 months and about 50K “beta users”, you know whether you have a dud or something with a nice ROI (lots of “whales” or gamers who spend massively on virtual goods and gifts). Also, if you’re fortunate, you can have multiple titles in play at any given time.
Once launched subscriber populations of massively multiplayer online games shows that they all follow a similar life cycle, but predicting at launch how different titles will perform or how long their subscriber populations will continue growing remains challenging—player populations can experience sharp increases or drops in a period of just a few weeks.
What is Considered Viral? A Game “Success”?
When one thinks about a social game, what’s considered a win? What are the chances that more than a handful of publishers will produce viral games?
Whether you are using developerAnalytics, or AppData to measure your Facebook game activity, most social gamers talk about DAU (and to a lesser degree MAU). Kabam’s Kingdom of Camelot is ranked as follows:
- MAU (Monthly Active Users):#172 (1,562,489, just under Quiz Monster)
- DAU (Daily Active Users): #109 (358,898, just under CSI, Crime City)
This is out of about 130,000 apps being tracked on AppData (not bad to be in the top 100/130K or 0.1%).
But what’s happening behind the scenes? What drives MAU, DAU…the “K-Factor”. Application or game penetration rates are measured the same way biological viral infection rates are. So that if your K-factor equals 1, then you ‘infect’ one new player before you stop being infectious, either through death (not signing back in) or not being contagious (not inviting your friends). With this formula, game designers want K factors above 1, far above 1.
What are the number of vectors? This is your player base. It’s basically the number of players that you are starting with. “Welcome to your new universe, have look around.”
How contagious are your vectors? These are the number of opportunities your players have to connect with and infect new players. “If you invite 10 friends, you get the blue chip. If you invite 100 friends you get the red chip.”
What is the duration of infection? This could be seen as time online, or time playing the game. “Plant this tree and watch it grow, make sure you come back to water it every day.”
How does a player get reinfected? Once a player initiates play and infects others, they still need to return to the game and get reinfected themselves. “Your friend Pat just accepted your request, thank her.”
So what are the feedback loops that drive social casual gaming? As Arthur Grau mentioned in his comparison of gaming to advertising, “Advertising [gaming] is based on one thing, happiness. And you know what happiness is? Happiness is the smell of a new car. It’s freedom from fear. It’s a billboard on the side of the road that screams reassurance that whatever you are doing is okay. You’re are okay. “
According to Josh Rose (CEO of Flying Wisdom Studios), yes there is the “You’re okay”assurance factor in games like Farmville and Cow Clicker. The games make the world appear ordered and understandable. In gaming there is also the challenge reward–when you achieve something you previously did not think you could. This accomplishment sends a “nice, warm” feeling that brings you back to the game.
There are 3 factors that create this sense of assurance or reward. Each of which can be either fixed or variable in their delivery, so that in their permutations of 2 x 2 x 2 they become the 8 feedback loops that drive the four metrics.
- Payout: This is the payback for taking any action within the game. When fixed it is always the same, like when you get ten points for getting a friend to join. When variable, the payback changes depending on random or pre-determined factors.
- Interval: The interval is how often you can take an action. Some plants take longer to grow than others, or you may be able to invite a set number of friends per day, or have to wait for your mojo to recharge before shooting your next round. Intervals may be fixed or variable.
- Investment: Investment is how much effort it takes to act. In the case of Second Life the investment may be significant, whereas with Cow Clicker, you are one click away from completing your action and getting satisfaction. Again, fixed or variable.
So in using the 8 permutations, let’s describe one possibility. Variable payout, fixed interval, and fixed investment. In this case, a quarter slot fits the bill. You have no idea what the payout will be, you can play as often as you want and always know what your investment will be per play. Pretty successful.
So, lets say that you figure out how to develop a viral game. How do you scale your infrastructure based on the demand?
Cloud IaaS For Gamers
I forget who I was talking to over at Joyent, David Young….Jason Hoffman or Brian Brown, but I was a bit surprised when I heard that about 75% of their new customers in 2010 came from gaming companies. Yeap, three-quarters of new cloud services business came from aspiring “Angry Birds” so to speak. They’ve done a great job in building a cloud platform that meets the specific needs of gaming companies (more multi-user or social gaming, than single-user mobile downloads, of course). Evidently, the value proposition of cloud applies well to game companies as well.
The traditional approach taken by most game publishers and providers of large-scale multiplayer online games is to install a dedicated infrastructure for each game. This approach has many drawbacks. It involves high risk and investment with little knowledge of how successful a new game will be.
Game publishers and developers face several ‘‘pain points’’ related to this problem:
- Sharing existing infrastructure across game titles—Repurposing servers, changing software stacks, and reconfiguring the network to accommodate a new game or function is often a cumbersome, manual process.
- Scaling the infrastructure in response to player demand—Adding and removing servers, support functions, or other resources is not automated.
- Managing a large, heterogeneous game server infrastructure—Server and network management is typically well outside the core competency of game providers.
This is where the services of a Joyent for gamers really proves to help.
The Needs of Massively Multiplayer Games
When I was recently having lunch with my friend Chris Carvalho, COO at social gaming company, Kabam, he spoke to the many servers (I won’t quote the numbers…but there are many) that they have hosted in Joyent which support their Facebook games. It was interesting to talk about the needs of the social gaming providers in general – it’s definitely one of scale, and response, and behind the scenes it’s a data-driven business.
I also spoke to another peer CEO (in the gaming space), Frederic Descamps, founder of A Bit Lucky (developer ofLucky Train, a Facebook app which lets players send trains throughout their network of friends). They are using public cloud IaaS giant, Amazon (AWS) and cloud management tool, Rightscale. There are clearly many moving parts to managing the IT infrastructure of a social game, and specific tricks of the trade to not only build and scale, but measure the effectiveness of the game.
Platform requirements for multi-user games extend beyond the basics of elastic compute from IaaS providers though. Additional requirements include:
- Automatic Scale-Up / Scale-Down based on resource usage
- Workload Migration (across platforms, by geography)
- Game Lifecycle Management (this one is key)
- Game Communication Services
- Development Tool Environments
- Game Intelligence/Optimization
And how do we get all the above in a single platform that is consistent across all game titles within a publisher? This sounds much like a Gaming PaaS.
I had numerous exhibit hall discussions at the Game Developer Conference 2011 regarding the potential of a Gaming PaaS. It seemed that maybe there was something to my position on vertical PaaS platforms as the future for new cloud-based application developers (see my PaaS post here)….coupled with a potentially growing population of savvy game developers who can serve their local game markets.
I decided to take the outcome of my discussions to some of the brain trust at Electronic Arts, including Greg Schaefer, VP & CTO, Global Online at Electronic Arts, and Andrew Corcoran (“Corky”), VP International Strategy and Development. If anyone could provide some unbiased opinions it would be Greg and Corky. Of course, the optimism subsided a little. According to Greg and Corky it’s not a question of whether one can simplify identity systems, recommendation systems, or BI databases, but it’s rather a question on whether there are going to be more than a handful who are successful in the gaming space….driving the need for a generalized platform.
Game Ecosystem Considerations
So what is the “game ecosystem”? Console games, downloadable mobile & handheld games, PC downloadable games, online browser-based games (tied to social platforms like Facebook and not), and streaming games (from providers like Otoy or Gaikai).
If I paint a controversial picture, it would be game consoles diminishing, while social networking (casual) and other online games replace them. Although this will not be the case, it represents a trend which is dominant – online games are growing.
Who’s Developing Online Games?
Based on a simple view of game publishers on Gamemapdev, there may be 2,000 publishers with an average of 10 people per publisher, or 20K developers who could utilize a public game PaaS platform.
Is there an Emerging Mid-Market?
In talking to Eric Knipp at Gartner, he says, “Social gaming alone will be a $1b market in the next several years. That’s a big enough market to justify the entry of gaming platforms that support rapid social game development.” But I don’t think Eric’s enthusiasm supports the need for a public PaaS for gamers, but rather development platforms that can be sold to both the handful of established publishers as well as the long-tail of aspiring publishers (solutions like the HTML5-based multiplayer game development kit, Game Closure, or augmented reality platform, StringLabs, are compelling solutions for all).
If There Was A Gaming PaaS
A gaming services platform design follows several basic PaaS principles. First, the platform and associated services should be minimally intrusive to the game applications and, at the same time, still provide value to game providers by relieving them from managing the system infrastructure. A platform must be general enough to support many types of games (so that it can be shared), yet still be able to be tailored when necessary by an individual game publisher. A second possibility that follows from this is a modular platform architecture which allows game publishers to take advantage of functions that address their needs and forego others that may not be as relevant. Finally, to ensure the flexibility and extensibility of the platform, open standards and open-source tools should be used wherever possible, consistent with the principles of the On Demand Operating Environment (ODOE).
Logical platform architecture above shows the logical relationships of each of the architecture components. Conceptually, the platform may be thought of as a layered architecture, with upper layers comprising application-level services and lower layers acting as system-level services. At the bottom are the IaaS providers of the hardware and networking infrastructure, consisting of shared clusters of game servers, database servers, proxies, content servers, and wide area network (WAN) connectivity. As the number and distribution of players and games grows, the platform may be deployed in multiple IaaS locations. Above the infrastructure layer are the main systemlevel services, which consist of non-game-specific functions, such as server and network monitoring and server provisioning. These functions are generally useful for any game and for many auxiliary game functions. Server provisioning will be customized to install specific application code, but the basic provisioning operation—for example, on demand installation of a software stack on a target server—is common to most game applications.
Control, content, and reporting are more sophisticated functions characterized by higher complexity and functionality or requiring more substantial modifications to work with each game application. For example, the executable deployment function must interpret the requirements and policies as specified by the game provider and transform these into provisioning operations and orchestration policies for the provisioning controls. Similarly, the game and player statistics reporting function requires interfacing to the game to extract such information.
Atop this logical functional stack is the game application itself. At this level, the primary platform services can dynamically partition and distribute the game over multiple servers. A number of distributed game server architectures and middleware solutions are available that provide this service for games instrumented to use them.
Hence, the partitioning and scaling services are embedded in the game application. In addition, an important function at this level is the game-specific performance monitoring that is collected directly for use by the distributed game middleware to make its resource management decisions.
Note that the top layers set the game service platform apart from a general utility-computing platform for other applications (IaaS). These layers represent the key set of services and components we have identified that are needed to adapt the on demand computing model to online games.