Sponsored By

Without fully understanding the meaning of terms like "microtransaction" and "pay-to-win," argues monetization design consultant Ramin Shokrizade, you don't have a basis for implementing these models -- and in this paper, he proposes a basic lexicon.

March 13, 2013

9 Min Read

Author: by Ramin Shokrizade

Automobiles and computers were so simplistic in their first 10 years that today we have a hard time looking back and appreciating just what a leap in technology they were at the time. Like all technology, they benefited from the iterative process, slowly adapting to changes in allied technologies, consumer demands, and infrastructure. Today both cars and computers have components in them that did not even have names 10 or 20 years ago. Before they could be added to these products, they had to be thought about and given names so that they then could be optimized and adapted to various uses.

Today the technology of monetization design is literally in its first years of creation. The concepts can be quite complex, but in talking about them we use broad terms like "free-to-play," "microtransactions," and "pay-to-win" to explain things that would be difficult to explain in detail. The good of this is that others can have a general idea of what you mean without a long academic discussion.

If a developer says "I am going to replace the subscription in my game with microtransactions," then we can all nod and pretend we understand what the developer is saying. We can also pretend the developer understands what they are saying. The downside to this simplification is that often no one in the conversation understands what is going on at a level that can be applied to product.

Here, I am going to attempt for the first time to put a majority of the monetization design language I have been developing over the last four years in one short article. All of these terms have been used in my other papers on gameful.org and here on Gamasutra, but never in one place.

I cannot understate the importance of a unified language for this space. Its importance goes beyond intellectual discussion. The whole "subscription vs. microtransaction" paradigm is so limiting that it is crippling our industry. There are not two ways to monetize a game. There are millions, limited only by our imagination and our ability to articulate our ideas to our fellows.

What is a Subscription?

Generally, this is a recurring charge for service. In games, it usually means you pay one fee monthly and get the entire game 24 hours a day, seven days a week. To be clearer, I describe this as the Unlimited Use Subscription Model. The weaknesses of this model are profound, and go beyond the scope of this article.

Any part of your game can be charged for in a recurring fashion, for any duration you set. You can have as many modules of your game as you like charged for in a recurring fashion. I call these limited subscriptions microsubscriptions. Microsubscriptions can be used to gate content access, boosts, time, or any other feature you can think of. There are two primary advantages to offering multiple microsubscriptions in your product:

  1. This allows the consumer to tailor your product to their needs. You can't, and should not, want to try to predict how each consumer will use your game. Make it flexible enough to appeal to the widest possible audience.

  2. This allows you to continue charging for your game service, and thus maintains your revenue stream beyond the first month.

The end result is you capture the biggest possible slice of each consumer's available gaming budget.

What is a Microtransaction?

A microtransaction is the purchase of one "piece" of your game for a set price. It is a one-time transaction that in some cases can be repeated. Used by itself, the term is so broad that it becomes a liability in any discussion. Here "what" you are selling is much more important than the fact that it was purchased piecemeal. So here I will discuss the what of non-subscription content purchases and attempt to wean you off of the term "microtransaction".

Virtual Goods Sales: Nexon began playing with microtransaction virtual goods sales when I was working for them as a designer in 2001. There are two dynamics that are important here. Do the items provide a competitive advantage? If so they are Supremacy Goods, as defined in my paper of the same name. This can have profoundly negative effects on your monetization efficacy.

Non-supremacy goods generally take the form of cosmetic and "flavor" items that do not provide a clear competitive advantage in a game. There are gray areas that may sell well, like items that are balanced but give more tactical options and thus provide more "flexibility" to the user.

Virtual goods can, in some cases, be sold by entities other than the developer. In these cases the process is often described as a real money transfer (RMT) sale. For a full discussion of these dynamics see my Real Money Transfer Classification paper.

In that 2011 paper, I broke down RMT into three categories. RMT3 is industrial gold farmers and sellers, which were organized almost 10 years ago by a company called IGE that caused considerable harm to our industry. RMT1 was the reaction to this -- what we usually now call "microtransactions." RMT2 is what came before both of these -- what I call "expert trades" between active participants in a virtual world. It was essentially wiped out by both RMT3 and RMT1.

Blizzard recently attempted to bring back RMT2 and monetize it using a real money auction house in their Diablo III product, without understanding the involved potential pitfalls. I described these pitfalls six months before anyone got a look at D3 in this paper.

If you sell an item that can normally be earned via gameplay, then you are selling game objectives, and this breaks your game, as described in my Game Monetization Defined paper. This will have negative effects on your revenue generation.

Content Sales: If there is some part of your game that is inaccessible until you pay to unlock it, then I consider this a content sale. DLC sales are exactly the same thing, though usually that term is associated with single player game products, not online multiplayer games.

Note that while players can compete against each other in single player games via leaderboards (a very useful method of motivating your customers), this also reduces the Supremacy Goods effect of selling content that gives players a gameplay advantage.

Please note that for something to be a content sale and not a time gate (see below) it has to allow access to some part of your game that is normally completely inaccessible without payment.

Time Controls: Time in-game can be rationed via time gates. A time gate prevents one player from getting ahead of another player just because they have more time to play. Turn-based games like chess and checkers do this automatically. As soon as you remove all time gates players will be motivated to win your game by not sleeping (or eating, or working, etc.). This has substantial negative effects on revenue generation (a full discussion is beyond the scope of this paper).

Note that a time gate need not strictly use a time metric. It can also ration a player's actions. Zynga does this in all of its products via the energy resource, as an example. This is a preferable approach to using time itself as the control, as a player will get aggravated if real life draws their attention or they fall asleep at the keyboard and return to find their time has expired. The greatest weakness of the Zynga time gate is that it can be bypassed completely with money, thus breaking it.

A game without a time control is a bit like an "all you can eat" restaurant. This works for some restaurants because they can just keep putting out cheap content forever. As a game developer, very little in the way of attractive content is "cheap." Once a player has had their fill of your content, they will move on as there is no way you can create content as fast as your gamers can consume it.

Uncontrolled time also acts as a Supremacy Good, with the added disadvantage that you are not being paid for it. This will make your game much less attractive to those players with huge money budgets and small time budgets (your ideal customer).

Pay-to-Win

When you sell game advantage via any of the above methods, you break the game intentionally. I would go so far as to say your product is no longer a game, but just an entertainment product at that point -- as described in the aforementioned Game Monetization Defined paper. Further, when you make the game highly competitive between players you create what is in reality an ante game, as described in my How 'Pay to Win' Works paper.

An ante game is one where you can win just by raising the ante to the point where your competitors cannot match you. Skill and effort become irrelevant. Most Facebook ante games (currently all mid-core and Asian browser games) have no cap at all.

Some games, like EA's browser-based iteration of its Command & Conquer franchise, have such high caps that the game still becomes an ante game. This has negative effects on revenue generation, as further detailed in my Supremacy Goods microeconomic model.

Superior Monetization

While your "hardcore" gamers (I define these as playing more than two hours per day on average, and typically eight or more hours on at least one day per week) may be your most vocal, they are not necessarily your biggest spenders. The person with a job, high income, and very little free time will spend a premium for quality entertainment on those times when she does have time to play.

Creating a game that provides a quality experience for these high-budget, relatively casual players without resorting to Supremacy Goods should be the ultimate goal of a well crafted monetization design. Obviously exceptions will occur in the case of niche products, but those niches can get crowded very quickly, leading to rapid loss of positive net income.

Just as there are almost infinite ways to craft said design, there are also just as many ways to really foul up your design. The key is to know your consumer, and how any change you make to your design will affect the relationship between you, them, and your product.

Read more about:

Features
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like