gaming

You are currently browsing articles tagged gaming.

Project Darkstar Game Server Risk Benefit Analysis

November 28, 2009 in Bootstrapping as Method, Flash | No comments

I am in the late functional Design stages of an Indy MMO, and the early technical design stages (Secret for the time being), so a couple of weeks ago when I was searching for a very inexpensive, scalable, smart solution to the ’server problem’ all MMO’s face, I found Darkstar and a couple other MMO backend products. Darkstar is an Open Source server platform developed by Sun Labs, specifically created for massively multiplayer game creation. It has a long list of useful features, and allows the development team to build application logic directly on top of it while handling all the low level server tasks which are traditionally the most difficult – concurrent data access, user connection level loading, multi-node scaling, and persistence across server crashes or shutdowns.

I looked carefully at several server platforms by analyzing technical documentation, 3rd party opinions, and in the PDS (Project Darkstar Server) case, actually building out the examples and looking over some of the source code. The result is that I have (tentatively) chosen Darkstar as the technology for my current project, and thought I would post my analysis here for those who may be evaluating MMO creation themselves. Darkstar is currently in pre-release, and this analysis is based on it’s current state and assumes successful a node scaling implementation which is expected within the next 6 months. This is a high level analysis of the Benefits and Risks of choosing Darkstar as the back-end server platform for an MMO (with small teams and Indy projects in mind, and not a lot of extra cash). Left out of this analysis is any direct feature comparison with other products. For more information, I recommend visiting their website and reading the forums, or even trying out some of their code examples yourself.

Benefits of Darkstar as a Server Platform:

  • Darkstar is Open Source – I like open source because it’s possible to contribute back to the community, and support a good thing in software. Open Source products have saved me thousands of dollars over the years in license costs, so I tend to want to support their efforts. This may not apply to all teams reading this, but is a key point for me. Additional benefits of open source are deeper understanding of underlying technology, and the ability to customize and support a product regardless of what entity initialized it. You also have a good chance that many other teams are adding useful features and tools into the code base.
  • Darkstar is Free! This beats every other server solution. Although there are some other free servers out there, none have much in the way of functionality needed for a back-end MMO. For a small game shop, this significantly reduces game production risk. It also avoids one of the success pitfalls, which is needing to scale up server licenses quickly if the traffic is not sustained while hoping revenue will also follow along. PDS offers (or soon will) easy scalability in both directions at no cost.
  • Scalable! Though not quite complete, the vision of PDS scalability is unmatched in other systems today. Both the ease and method of scaling cannot be found in other systems today (at least not at Indy price point). If you want to find out more about how scaling works, I suggest you take a look at this video demonstration of capacity level loading across nodes.
  • Superior Capacity Planning – The fact that the code base is free along with the scalability function of the product gives a unique advantage in deploying or removing capacity. If paired with a cloud based server environment, it is easy to add machines quickly as you scale up, and if demand drops off, to quickly scale back down and save costs. If the game has seasonal fluctuation or sudden peaks, this is a key cost advantage over other systems.
  • Excellent reliability in the data store – Though I have not fully tested it, the basic model avoids a key number of issues found in other server implementations around reliability of data. The primary example is the avoidance of duplication bugs and in memory errors seen in some other MMO’s. The data storage mechanism is unique and robust.
  • The Server base is really tailored to multi-player games. Other server systems are typically geared towards chat, large numbers of rooms (or shards) with few players, or other server side functions, and toss in virtual world building almost as an afterthought. Once you get past a lot of the marketer-speak on many other systems, the technology doesn’t seem to be there to the same extent as PDS. What this means to a development team is that much less time worrying about the server logic and that much more time implementing game logic when using PDS.
  • Server side game programming is easier and faster (and thus more reliable and less expensive) then any other server system I have seen. PDS offers developers the illusion of programming a mono-threaded application while maintaining a highly concurrent state. There is a number of convenient API’s for using the server, and the PDS API is quick and easy to learn. This reduces the potential for programmer error in server side programming for massive environments.
  • PDS implements roughly 80% or more of server side programming not related to game logic. Ideally, a game server would implement 100%, but I don’t think such a thing exists today. The amount PDS has achieved is incredible and blows away other server system I have seen. Since it is still in pre-release, I expect more down the line, and much of it is on their product road map.

Risks of using Darkstar as a Server Platform:

  • No SQL Database back-end. Darkstar chose a design pattern which uses a database and serialized Java classes. It is very easy to code in, but makes viewing your data virtually impossible. Though this design decision is behind many of the benefits listed above, the trade-off makes several critical game components much harder. The repercussions for this are numerous and varied, and are a downside of choosing the PDS. I have listed the main problems this causes below.
    • In order to update an objects’ current state as an admin or GM outside the game rules, custom interfaces must be added as opposed to using direct SQL tools. It is significantly more complicated to write such a tool then to write a web front end to a database.
    • Historical reporting is not a freebie as in other DB systems – Server design must include asynchronous writes to a DW DB, as opposed to using DB to DB datawarehouse methods, which is currently a well defined and solved problem. This is not as big a problem as the first, since it should be relatively easy to implement. Additionally, a large game server would need to implement something like this anyway, to avoid contention on their main database.
    • The server state itself relies upon the data store. If you want to change certain code objects (An initialize method on server startup which creates many objects only on the first server start, and non-serializableable compatible class changes), you must also remove your data or use another method such as merging changes. This makes future server patching much more difficult. It also blurs the line between what is game data and what is game logic. Since there are certain methods and objects which can’t be easily updated without potentially harming player data. It is possible a third party, which has already developed a tool to make this easier, will release something to the community, but it remains an issue for the foreseeable future. The technical details of what this means are complicated, and if you are considering Darkstar, I recommend you read up on these issues on their website to get a fuller understanding of exactly how a code patch might look.
  • Long term platform support is unknown. Currently, the only support is through forums or logging a bug issue. Since there is no formal paid support option, there is no real hope that critical issues will be handled in a reasonable amount of time as in some other open source projects. Having the code helps in this case, but it would be good to be able to get support at some point if needed, especially if the game turns into a breakout hit.
  • Oracle/Sun acquisition. Unfortunately, due to regulatory issues,  it can’t be discussed yet by the Darkstar team or Oracle, but Oracle has a mixed record on Open Source when it does not suit them. The long term viability of a project which is not aligned with Enterprise database software seems low to me. From the outside, I judge the probability of Darkstar being Oracle supported years from now to be moderate to low. That leaves long term support and improvements to the community, if a team picks it up at some later date. Historically for open source, there is not a great track record of this happening, especially with highly specialized open source software. Selecting this server technology means the team will have to take on the risk of self support and improvement for the code base years from now. Another related worry is if the Darkstar team itself leaves, as several other high profile Sun professionals have done in the past few months.
  • Documentation lacking / not regularly updated - Things on the server side are changing fast, and the documentation does not keep quite up. It is still in pre-production release, so this is not a really a fair criticism, but examples, training, and documentation is still sparse for such a complicated system. There is plenty of material for learning the basics and to get you started, but detailed manuals do not yet exist, and support tools are not offered.

One note on the list of risks to those who might look at this for their own projects. The risks can be broken along two specific lines, one is long term supportability of the product, and the other along the lines of how much work will it take to design a game out of the box. This second criticism is valid, but if you compare Darkstar to other solutions on the market, the work entailed to bring you to the same level as PDS currently offers is far greater. In other words, if you are making a buy decision on server software for MMO style games, every server I have come across has a long list of server functionality gaps, but Darkstar only has the ones listed above (which end up being far fewer then other products I have looked at). As for supportability, that is something common to most new open source projects, and not unique to Darkstar. I think the Oracle acquisition adds to the uncertainty significantly compared to when Sun was still independent, but I am hoping to gain clarity in the future, perhaps once the EU clears the deal.

The Final Say

Given the not insignificant downsides, you may wonder why I have chosen Darkstar for my own projects. The real reason is functionality, followed closely by cost. First, a quick note on functionality: it is unmatched. Yes, there is a lot of work required to make sure patching is viable and you can modify and track data. However, both of these issues are currently widely discussed by the Darkstar community, and it seems reasonable to assume they will be tackled in the future. Now, a quick look at costs. See my other post on Indy Game Economics 101 for an in depth view of game revenue vs. cost, but with a server that takes no upfront cost or licensing cost, it is the best value for the money. Support costs may be higher if internal support requirements grow rapidly, however existing projects don’t seem to have this complaint.

Tags: , , ,

Indy Game Economics 101

November 15, 2009 in Bootstrapping as Method, Flash, Startup Challenges | 1 comment

I recently entered the Indy gaming market, a crowded market if ever there was one. I liken being an Indy game designer / programmer to being a first cut author, except without an entire publishing industry looking for hot talent. Imagine being an author and getting your first book put on Amazon for download, or included in an online store along with millions of other titles, many of which have name brand recognition, thousands or millions of dollars in marketing spend backing them, or a lower price point (free). Your book is new, it touches universal themes, the writing is solid, and the characters alive. Still, it is useless unless people see it and buy it. How is such an author to make enough to feed the family?

Similar to the author I describe, Indy game shops face a steep uphill battle to make a game profitable. In this post, I will walk you through the basic economics of game distribution, price points, revenue models, and the business side of game design. In future articles, I will expound on low or no-cost marketing initiatives, distribution methods, and design for cost and quality.

Revenue Models for Independent Game Shops

There are a variety of revenue models to pick from, all of which can make your game profitable. Each method has different pros and cons, and are generally not mutually exclusive with other methods. If you can reasonably include one of these methods with your game, then include it, even if other revenue streams are already integrated. I like to look at each model from the perspective of the question “How many (unique) users do I need to have before a game is likely to make a million dollars?”

Revenue Model: Advertising

Probably the most widely used today for small independent games, advertising is when you use an ad network of some form and include it in your game. You can run ads during load screens, between levels, at start up, and really any time you want to. The most well known ad network today is Mochi ads, which adds additional benefits to the game design team by distributing the game for you.

Benefits:

  1. Ads are very easy to add and can boost your bottom line.
  2. Ad networks may help distribute your game to many game portals (generally for flash only)

Downsides:

  1. Some users are turned off by ads. If you throw in too many, you may lose customers.
  2. It can be hard to charge for a game up front, and then force users to sit through ads. Some games have been burned by this recently, but it may come to be more accepted by the gaming populace over time.
  3. Ads pay very little.

How does it pay?

Assuming you hope to make some cash from your game, lets see how ads work for payoff. Similar to ad supported web sites, you need a lot of traffic to generate any significant revenue, so your per-ad payout is going to be low. You can find published rates for CPM anywhere from $.05 per 1000 ads shown to roughly $1 per 1000 ads, though in actual experience you are unlikely to see a rate this high for any extended period. Across all games, the general consensus for average rate  is around $0.30 per 1000 impressions. This assumes a decent but not incredible game. This means you will need more then a billion players to break the $1 million mark on your game. That’s a lot of players. I have heard that using Mochi nets a game an average of 1 million plays, so a decent game can generate around a thousand dollars from advertising. One important thing to keep in mind is as the quality and popularity of your game increase, the expected CPM increases, and the value of each player increases accordingly. There are some games which can be supported purely on this model, but generally only the top 10 or 20 games in a year.

Revenue Model: Direct Sales

Direct sales ask a gamer to shell out up front for your game. Some recent successful examples of this method are Machinarium, which retails for $20 a copy. This nets you much higher revenue per player, but it is a lot harder to get a single player.

Benefits:

  1. Higher upfront payout per customer
  2. potential to generate a lot of revenue quickly

Downsides:

  1. Generally requires high quality game play and play length to attract customers.
  2. Distribution channels are more challenging. Options include through your own website, Steam, Amazon, or for some games XBox Live or PlayStation Network.
  3. Requires a more extensive marketing effort to get the word out.
  4. This model can be significantly harmed by piracy, as seen with other indy games with a 90-95% piracy rate.

Common around this strategy is packaging a Demo which is free to play and gives the player a good feel for the game. This means you actually need to sell two products to your customers – first a demo which they play and enjoy, and second the game itself. It is easy to leverage ad networks or other models with the demo to improve distribution and revenue from non-buyers.

How Does it pay?

This kind of sales can pay off very quickly if the game sells even decently. Assuming the $20 price point, you will hit your $1 million mark after only 50,000 game purchases. You can hit it faster if your demo is ad supported and does well. The main challenge with this strategy is in gaining distribution through third party channels, marketing the game, and convincing players to purchase instead of pirate your game.

Revenue Model: Micro Transactions

Micro transactions have been used for some time by game companies, even longer then most people realize. Micro transactions consist of selling pieces of your game to players over time, so their up front cost is lower or even zero. Players can be sold a variety of products including the game itself and expansions (the earliest form), additional game content such as expert levels or new areas, player items, fashion accessories for avatars, or virtually any game feature you can imagine.

Benefits

  1. Players can consume your game with lower up front risk due to lower cost. This increases total players
  2. There is typically a higher ceiling for player expenditure then with direct sales. A direct sale gives a max of $20 of revenue per player, but every time you add a new virtual good to the game, players increase their revenue potential.

Downsides

  1. The game must be designed to support these transactions. If not, they will generally not sell well. This can be difficult, since you must provide value to both non-paying and paying customers without unbalancing the play ascpects too greatly.
  2. Traditionally, it is difficult to successfully sell players items when not in a multi-player environment.
  3. Some players are turned off by the idea of spending any money on in game items. This is known as the ‘penny gap’ where some players refuse to pay for anything no matter the cost.
  4. If you use multiplayer, which is common in this model, ongoing server costs will dampen profits, and a large percentage (80-95%) of players will be non-paying customers.

How Does it Pay?

Studies have shown that paying players in these kinds of games are price insensitive, so you can charge sometimes significant amounts for certain items. Additionally, players which spend one time are also likely to continue to spend over the life of their gameplay, averaging around $30 per paying player. Unfortunately, many of these games have poor purchase rates, hovering between 1 and 5% of players being paying players. Thus, if we assume that you get 4% of players paying $30, it takes around 800,000 players to hit a million dollar revenue. Keep in mind that this is revenue, not profit. Since by nature this model assumes online play, you have additional costs for servers and support, which will detract from your bottom line. It is possible through good game design to change these numbers so a higher percentage of players are paying customers, and they pay more for the content, though that is another discussion entirely.

Revenue Model: Licensing

Licensing can be a rewarding model. You sell your game up front for big bucks directly to a game portal, distributor, or other third party, and make money regardless of how well the game does.

Benefits

  1. Make money regardless of game popularity
  2. It is possible to license to multiple 3rd parties depending on the terms of the agreement.
  3. You may be able to use this model in conjunction with advertising depending on terms of the agreement.

Downsides

  1. You lose some control over your game – publishers may request changes or additional features.
  2. You are unlikely to be able to use certain other revenue models such as in game or up front sales.
  3. Most license agreements are relatively low revenue.

How Does it Pay?

This model pays well if you have fewer views, and poorly if you have many. It is highly unlikely you will hit a million dollars with this model unless you make many high quality games. In general, licensing deals run from $100 to $10,000 at the very high end. This is not a lot when you consider salary costs for team members. The saving grace of this model is when you sell it multiple times and also distribute with an advertising model, or have a game which you don’t believe will make a lot in advertising.

Conclusion

Overall, there are a variety of revenue models to choose from. Most of these models rely heavily on the game design, and vice versa. It is wise to select a revenue model during the early design phase of a game in order to ensure the maximum revenue potential is achieved. Adding features to support one or another model at the end of thr project is likely to degrade overall game playability and under-perform from a revenue perspective.

All but one  of these methods share one thing in common: They don’t do well unless you have a lot of players. Players are mostly willing to pay for good entertainment, though you have to present a clear value model for them to make a decision. Competition is fierce for attention, so making a high quality game is still the best way to make a buck.

Tags: , , , , ,