Reinforcement learning (RL) is a popular machine learning framework that speaks to people that love video games. In fact, I discovered RL through video games, specifically Atari’s Pitfall. But, that’s a story for another day. RL is popular because it offers a framework for modeling problems, agents, and outcomes in a way that is easily understood by humans. It fits into the human mold of learning where we expect to reach a goal through a series of actions and learn through environmental feedback. Pretty much how babies learn to walk, and adults learn to play a new video game. The downside of RL is that taking an agent from the lab to the real world is never a straightforward affair. Unlike video games where every action has a reaction and a clear goal, the real world often lacks the same determinism (a single action can result in a multitude of reactions), and goals can be elusive.
Because this is the first RL article in the blog, it’s almost mandatory to describe what RL is and how it works. RL uses what is called a Markov Decision Process (MDP) that dictates that the environment is observed by an agent, and the observation is called a state. At every tick of a clock this agent observes the environment and takes a single action. In video games this could mean reading every pixel on the screen (the state would be a large matrix), and the action would be pressing any button on the joypad . There are rewards associated with actions which guide the agent towards the direction of the goal. MDP is thus interested in actions that move the agent from one state to the next until it reaches the goal. Any one of the terms I just described could be an unknown that needs to be learned. For this article we are mostly concerned about the rewards associated with the actions the agent takes.
Training an agent when the feedback is delayed is difficult. For example, any agent focused on optimizing 30-day retention (or even 7-day retention) will have a hard time with the delayed feedback. This is because learning will be very slow, many other factors may affect the results, and in real-world scenarios, it’s possible that the agent will need to take action before the reward from the previous action has been observed.
For these reasons, long-term feedback must be formulated as the goal of the agent. The long-term reward needs to be defined by local rewards that happen in the short-term. In the example of retention, which is a finite problem that is capped at 30 days, the number of days the player has been seen could be a valid reward function. What’s important is that the local reward functions are capped and do not grow infinitely.
One way to adjust the retention example is to observe if the player returns the next day. This is observable on a daily basis and functions as a sort of breadcrumb leading towards the big 30-day retention objective.
RL is a fun field of research because of its simplifications that make problem-solving enjoyable and satisfying. One standard simplification is that all observations are without noise or bias. That is to say, imagine an agent that is responsible for showing a single offer to the player every time the game loads. The action is the offer to show, and there is a reward associated with the outcome (1=player makes a purchase, 0=player doesn’t buy, -1=player quits the game). By default, RL would assume that the world would behave the same way, without bias and noise. Meaning, every time the action takes place, the reward would be exactly the same. This, of course, is not true. All actions (offers) shown will be purchased at some point, and the observed rewards will all be very similar. Similar because 99% of players will neither purchase the game nor quit the game. Noise will be as large as the reward we are trying to measure.
Solving this problem is a field of research itself because adding noise to an RL model can be done in many ways (Checkout partially observable RL and adversarial RL for some of the more unique ways). It has been shown that for the example above the No Free Lunch theorem is true. That is, without making some assumptions about the noise present in the rewards being observed, all agents can be misled due to the noise. The most common way of solving this problem is by injecting noise as part of the rewards we are trying to learn about. This is where some assumption is needed because you need to specify what the distribution of the noise looks like. Is the noise constant? Meaning, is the conversion rate for the IAP is 1.2% with a constant error of .3%? Or, is it more like a normal distribution where the error rate peaks at .3% but sometimes the error is less/more? In the end, the RL problem becomes much harder because not only do you have to know the reward for each action but also the noise.
Anytime an algorithm goes from the lab to the real world, its developers shouldn’t expect it to work quite as well, and they should expect it will require tweaks. In RL this is definitely the case. Unlike in video games, in the real world actions don’t always have a predictable consequence, and observing the consequence may be delayed and with error. The good news is that machine learning has been chipping away at this problem for decades, and many battle-tested solutions exist.
Product managers (PM) play a pivotal role in the games industry. Many PMs run their game(s) like a CEO runs a company. They manage a team, fulfill a long roadmap with countless deliverables and strict deadlines, and full P&L responsibility. Producing a successful live-operated free-to-play (F2P) game with frequent content updates, one-off events, tournaments, special sales, and a vocal community would not be possible without a PM navigating the ship.
Like the CEO of a larger organization, PMs face constant prioritization battles. They need to balance learning from the past through data analysis and player feedback with the challenges of swiftly pushing product development, meeting financial goals, and building corresponding roadmaps and teams, all while testing as much as possible. Simply put, PMs need to stay on top of everything. Needless to say, most of them are permanently overworked, and time (or rather the lack thereof) is their very own “premium currency” challenge.
Because PMs are so crucial to today’s game industry, I wanted to understand what makes them tick, how they work, how they solve distinct problems, what they enjoy, dislike, and wish for. To find out, I interviewed over 60 industry veterans, working at big name companies such as Electronic Arts, King, Disney, Rovio, Activision, Tencent, Mixi, ZeptoLab, Zynga, Wargaming, Scopely, Pokerstars, NBCUniversal, Flaregames, Kixeye, Outfit7, PeakGames, Plarium, BigPoint, GSN, Natural Motion, Nexters, and Gamigo as well as PMs at small indie studios. On average, my interviews lasted for an hour. This is the first post in a series dedicated to PMs and their incredible work.
To understand a PM’s work, we first need to understand his/her mindset. In other words, what motivates a PM, what they love about their jobs, and what they hate:
What Product Managers Love About Their Job:
1. Insight Generation
Almost every PM I interviewed expressed a profound love for “generating insights.” Coming up with a “key hypothesis,” “digging into data,” “observing how players interact with the game,” and “understanding human behavior” are frequently labeled as “very enjoyable” parts of the PM role. A product manager that runs a movie-branded game for a major publisher passionately described how he feels when he uncovers new insights:
“You are closest to data, you are the first to understand if a feature you shipped works or not. These aha-moments, the moment where you see the connection between X and Y, the detective work, these things are super satisfying!”
Many went even deeper and specifically mentioned that they particularly enjoyed “solving hard problems” that require unusual, outside-the-box thinking. I got the impression that the holy grail of problems a PM can solve is improving the core game loop such that player retention is boosted. “Sharing newly gained insights” within their game team or even “evangelizing” them within the whole organization were also mentioned as particularly rewarding activities.
2. Creative Process
Not surprisingly, product development, in all its facets, was also mentioned by many as highly enjoyable work. “Designing and developing new game features” and improving existing ones based on “learnings” received many votes. Not quite as popular, but still appreciated by several respondents, was “improving processes” (related to game management), working on “overall strategy,” and “catering to the player community”.
3. Managing a Team and Resources
A few PMs mentioned that they enjoyed their leadership roles within their teams, particularly “managing people” and “hiring new team members.” Others expressed pleasure in “financial forecasting” and general “planning.”
4. In General, Just Being a PM
The general sentiment among the PMs I spoke to was that they were overall very happy with their jobs. Generally, there seems to be a high satisfaction rate. Some of them went as far as stating, “I love everything” or “I enjoy all aspects of my work.”
What Product Managers Hate About Their Job:
1. Manual Work
Not surprisingly, there are also aspects of being a PM that almost everybody agreed they hated: “manual work” due to the use of “poor tools.” The most common responses in this category related to “tedious” tasks like “offer management,” “segmentation work,” “campaign configuration,” “in-game event scheduling,” “creative optimization” for offers and user acquisition (UA), and “test coordination.” According to many PMs, these are the biggest time sinks, with many reporting that, on average, their team spends at least one day per week manually working on recurring offers and campaigns -- time that should be spent on other, more important and financially fruitful tasks. One PM from a big publisher said that he had to literally manually copy and paste over 70 JSON files per week to support campaigns in different locations. Another PM said that she had to set her alarm clock for early hours every weekend to log in to their live-ops console and manually hit the start button for events and accompanying currency sales in different time zones.
2. Flawed and Insufficient Data
Almost equal to “manual work” PMs mentioned that “tedious data work” was among the most frustrating parts of their role. This category encompasses everything from working with “crappy tools,” “cleaning data,” and “maintaining the data pipeline” to “matching various data sets” and “losing time because of other people’s messed up data.” It shouldn’t come as a surprise that a widely loved aspect of the PM role (“generating insights”) is directly related to one of the most hated. Understanding player behavior becomes incredibly hard when you have faulty data or insufficient tools. However, understanding behavior is so important that dealing with the bad data can’t be avoided. PMs (begrudgingly) work with what they have, wasting precious time and energy along the way.
3. Redundancy and Friction
This third category has an even broader scope than the previous two with each of the mentions receiving fewer individual votes. All of the comments below share a common theme: redundancy and unnecessary friction. “Too many meetings” was mentioned several times as was working on things that “make no difference.” Many PMs disliked the process of “pitching to leadership” and “advertising within the company,” which required them to “frame numbers” to fit a particular context, and “make PowerPoints.” Some even went so far as to specifically mention ego-infused “leadership drama” and “politics”. “Managing people” got a few negative votes and therefore represents the only aspect of a PM’s work that was controversial between the respondents (a few specifically mentioned they liked this aspect of their work, while others made clear they did not).
Product managers are passionate and driven people. They are dedicated to their jobs, but probably even more so to their beliefs. They are curious, hungry for progress, and always challenging the status quo. They do everything in their power to understand player behavior. They want to have an impact, push the envelope, be the first to discover something new. They like responsibility, being thought leaders, and to “own” their game’s business in the best sense. But, because they are so aspiring and hungry, they also get frustrated by inefficiencies and redundant work. PMs hate to waste time, insufficient tools, and (unnecessary) manual labor. As process and results-driven people, they are irritated by company politics, confront boiler-plate meetings with impatience, and have a strong distaste for massaging a message and numbers so they can be internally sold, rather than assessing them purely as fact-based. As a group, PMs have many things in common. But they are also a particular bunch. They differ in how they come up with hypotheses, in what they consider to be the most relevant data, and in how they approach problems. Managing people is not every product manager’s dream, but some do enjoy it thoroughly.
Great product managers are versatile human beings that possess a broad array of game, data, business, and interpersonal skills. Finding all those skills combined in one human being is rare. That’s why great PMs are so valuable and sought after. I have heard countless times from C-level executives and top publishers that they desperately need a “great PM.”
Originating from the cartridges era, the QA department in gaming is alive and well today. Even in the current era of developers pushing game updates daily, ensuring that the game runs as intended is as critical as ever. However, the QA department has slowly acquired more and more responsibility, leaving many complex game systems without proper testing. For example, who checks that the analytics recording code generates the right aggregate data in the analytics dashboard? Who monitors basics questions like are the total number of unique players yesterday correct, how do you know what the right number is, and what timezone is the data from? For most game shops, the answer is the QA department.
The testing done in QA by definition happens at the end of a sprint or feature integration. It is assumed that the programmer and specifications were correct, that no new bugs were introduced, and that only the gaming experience needs to be checked. However, in modern games, a lot occurs outside of the player experience, and therefore many bugs go unnoticed until players realize find them and complain. This problem is why in modern games verification and validation should become standard procedure during development, adding a new layer of quality control that addresses the complexity of games.
In the simplest terms verification is making sure that a game feature was programmed correctly and that the code compiles and follows the basic specifications that were outlined. The specifications could be as simple as “every 5 game rounds show an interstitial ad before the game over screen.” While the QA department should check that this feature has been added to the game, the developer should verify that this feature is working before going home. his process is the current state verification in games.
Not as commonly seen in the game development world is unit testing as part of verification. Unit testing focuses on testing one or more small components of a piece of software to ensure that they work as intended and meet specifications. From the earlier example, a unit test could simulate the player having played 5 rounds of the game and checking that the interstitial ad code is called. Unit testing almost always involves automating the testing of small bits of code and checking that they produce some expected outcome. The beauty of unit testing is that it can be done continuously, ensuring that the game always meets the specifications. Unit testing often gets overlooked in games because it is believed that most of the testing for a game is visual or requires player interaction. But, as freemium games have become more complex, there is plenty of ground for unit testing that doesn’t require a player.
Unfortunately, some things are outside of the capability of unit testing that are still part of verification. Consistency checking, for example, deals with checking how multiple game rules work together. The interplay of multiple game rules is a common source of bugs in RPG games where game features or the appearance of characters in the game depend on complex rule systems (example, the boss only appears if the player has the sword and has HP greater than 50). Consistency checking would ensure that rules and the desired effects work together. The reason consistency checking is not common in gaming is that it needs the rules to be clearly written out, often outside of the code base. Another concept outside of unit testing but still within the broader scope of verification is static analysis. Opposed to most other forms of verification that require the game code to be executed, static analysis deals with walking through the code without actually running it. The process analyzes the code’s structure and checks that it adheres to programming best practices. Recall classic arcade games where it was possible to have the player score get so big that it went back to 0 -- that is a bug that static analysis would spot immediately.
If verification is focused on whether a game feature was programmed properly and followed specifications, validation is about checking that the outcome of the game feature is as intended. At Gondola, validation is as important as unit testing because recording player behavior can be unit tested, but only validation can ensure that the behavior recorded about a player actually happened exactly as encoded in the data. For this reason, validation often requires bringing subject matter experts into the process. In the case of player behavior, it might require talking to the team that manages player profiles to cross-check that the player profile matches the behavior. For example, the behavior data shows that the player mined for gold 5 times, the player profile should indicate that the player has 5 gold pieces. Or in the earlier interstitial ad example, validation should include making sure the right ad networks were used and that the ad request was captured on the ad network’s side. Again, the programmer alone might not have the access or the foresight to validate the game entirely, and this is a good thing.
Validation should be a group effort, and the best part is that it can be done on a live game. In the interstitial ad example, someone should validate that “after 5 game rounds” is the correct rule in the first place. This kind of validation can only happen if the feature is live in the game. To validate the game feature, you will need the product manager (PM) responsible for the insight that led to the addition of the game feature and the business intelligence person who understands the game analytics (and can pull out the correct data). Together they can validate that the game feature has the outcome that the PM envisioned.
While game testing and QA are still pivotal elements of all game development, the complexity of games has grown over the years to a point where verification and validation are a must. Often verification is pushed to the testing and QA department; this leads to overlooking common bugs until they surface months later. Validation is more common in games due to A/B testing which forces hypotheses to be validated. However, validation should be implemented in more than just the testing process; all game features and rules should be validated -- there is no other way of knowing if the feature is producing the right outcomes.
Every piece of data that a developer interacts with needs to have an appropriate data type. Broadly speaking, the data type tells the programming language how the developer intends to use a piece of data. Common data types like ‘string’ are used to represent pieces of text, and marking something as a string allows the programming language to understand that when you add two strings,you actually mean to concatenate the strings together. Similarly, when you tell a programming language that something is a large number with many decimal places, certain functionality and restrictions are automatically provided to the developer. For example, adding numbers together but preventing a number and a string from being added together.
This generally works well for most programming problems. However it breaks down when dealing with money. At first, money appears to be just a number with two decimal places, but if you think a bit longer you realize that the currency (USD, EUR, etc.) is just as important for the meaning of the data. The currency is practically as important as the + or - that comes in front of a number. Also notice how exchange rates break the “2 decimal places” rule. This is the tip of the iceberg of why money doesn’t behave like the ordinary number.
Floats do not Represent Money
Floats and doubles are two common data types used by developers to represent money in a programming language. It appears perfect because they can store very large numbers and handle fractional amounts. But, if you peak under the hood of what a float (or a double) is, you realize that float numbers are actually storing approximations of numbers. In Python for example:
1.0/10.0 = 0.10000000000000001
Which appears pretty harmless, but this error quickly escalates as you add further mathematical operations to that number. When you begin to tally up the total revenue of a game these small approximations (that often don’t show up in a dashboard because of UX rounding) lead to surprisingly large deviations.
The solution is simple: when dealing with money, you should stick to using numeric representations that contain no fractions. Integers and decimals are best for money, representing a dollar amount in cents.
Even when representing money in the form of an integer, it's important to keep track of the currency as well. If the currency is not explicitly attached to the amount, I guarantee currencies will be mixed up down the road and Euros and Dollars will be added up together.
Creating (or using) a library that manages money as a proper data type will give you a few safety nets:
- It will manage decimal representation of money (an important layer to making sure the internal 250 cents amount doesn’t mistakenly get interpreted as $250).
- It will ensure money type is immutable (https://en.wikipedia.org/wiki/Immutable_object) to prevent a value from being modified in one part of your code and having unintended consequences in other parts of your code.
- It will overload math operations to ensure that incorrect currency comparisons raise errors.
Only Convert at the End
Inevitably a currency amount will have to be converted to a base currency. At Gondola, for example, we always use USD in our reports, but this conversion should be left to the very last minute. This means platform fees and taxes are all applied on top of the original local currency amount. Furthermore, when adding up the revenue from all in-app purchases, it is best to add all like currency amounts first, and then, at the end convert all currency subtotals to USD. This reduces rounding errors and keeps results predictable.
It only takes one round of data validation to spot the need for a money type in any financial-based program. It only takes one bug that causes currencies to be assumed as USD (when they are in fact not), or a basic rounding error to generate an appreciable error at the end, to recognize that a money type can solve these issues before they begin. When validating monetary data, it’s also important to double check the ground truth since it is likely to have interesting bugs as well. Think of all analytics service providers, and ask yourself, “how do they deal with monetary metrics?” The answer is they don’t!. Writing a money type is actually a rather fun task and will give you a new appreciation for accuracy.
Michail Katkoff and Joseph Kim invited us to join the Deconstructor of Fun Podcast. During the episode, we spoke about the shortcomings of A/B testing, how to rescue a failing A/B test, why Multi-Armed Bandit frameworks are superior, and how product managers can benefit from targeting their offers and promotions to different player segments.
User acquisition expenses and production costs have risen sharply for free-to-play (F2P) games, causing their success to be more and more dependent on the longevity of their players. Therefore, increasing the lifetime value (LTV) of players has only grown in importance.
The task for product managers is clear: engage your players and retain them as long as possible to maximize LTV. To accomplish this task, product managers can’t afford to solely rely on selling standardized hard currency packs priced between $0.99 and $99.99. Special offers for new players, non-spending players, advanced players, expert players, specific offers for in-game goal achievements are crucial to extending LTV.
Additionally, live ops are needed to keep things fresh for aging players, prolong the life of existing content, and give players ways to engage with the game between major content updates and feature additions. Common ways to keep players interested are events, tournaments, challenges, changing rewards, etc. These tactics are usually accompanied by offers allowing the player to purchase additional in-game currency and items to prepare for a tournament, or replenish currency spent during a tournament.
Typically, games provide only a single offer per offer category (conversion, expert, event, tournament, holiday) to the entire player base. There is however an opportunity for product managers to target different player cohorts with bespoke offers. Below are 4 reasons why this is so valuable.
1. Impact on Offer Conversion
Willingness to pay (WTP) is the maximum amount an individual is willing to sacrifice to procure a good. In the context of F2P gaming, indicators for a player’s WTP include in-game progress, earning and spending behavior, platform, device, user acquisition channel, and many more. 1-2 of these parameters alone create player ‘thumbprints’ that can be assigned to different spending profiles. These profiles can help product managers determine which offers to present to which players. It all comes down to who-sees-what -- think of targeted advertising and maintaining ad-relevancy for different segments.
For example, Conversion offers (aka starter packs) are a popular way to get players to spend their first dollar. A typical starter pack in a mobile game costs $7.99 and includes hard currency, soft currency, and a valuable item. Such offers usually get triggered very early in the game, for instance when a player finishes the tutorial, solves the first quest, or wins the first match. If the player doesn’t convert on the first go, the offer is triggered again later. Here is the problem though: a price of $6.99 is only suitable for a subsection of players. Many players will be priced out at $6.99, while other players would happily buy a bulk package with a higher price tag but greater value. However, if the game had a “Beginner Offer” for $2.99, the previously described “Starter Pack” for $6.99, and an “Intro Special” for $12.99 a much broader range of player WTP and value perception would be covered. This method will lead to increased conversion since each player will be presented with their optimal offer.
2. Impact on LTV
A player’s LTV is highly dependent on the first purchases they make. For any given player, the specific items they purchase, the price point of those items, and the time between purchases establish a spending behavior and trajectory for their LTV. But, if you begin the first session with a $9.99 starter pack many players will be priced out, and their sense of the game will be that it is too expensive. Clearly, this is detrimental to LTV. However, if the game leads with a $1.99 starter pack, the game publisher is most likely pursuing an unsustainable LTV. It would be better to have a variety of options targeted at different player personas. For example, establishing a repeat purchase price of $10 vs. $5 early on in a player’s lifetime helps to manage the expectations of that player towards higher spending. Additionally, targeted offers don’t only help convert a higher number of players, but additionally lead to higher LTVs, thereby multiplying the conversion boost with the LTV boost.
3. Taking Advantage of Different User Acquisition Channels
When it comes to player profiling, all parameters that can be attached to a player’s persona before he/she even starts playing a game are particularly valuable since they can inform optimization decisions that impact a player’s game experience from the very first moment he/she enters a game. Often, too much emphasis is put on determining location (country). Location, however, is a very weak optimization indicator because both non-affluent (likely non-spenders) and very affluent (potential whales) players share the same location. Optimization by location is therefore not recommended because pooling all players from Russia, for example, and treating them differently than all players from the US based on the assumption that the average Russian player is less affluent (GDP suggests that) will not work. Eager spenders in Russia will be met with a very counterproductive experience. A player’s platform (iOS vs. Android, Playstation vs. Xbox) is also immediately available information. There are benefits in using platform as a determining factor because, as a whole, certain things hold true, such as the average iOS player generally spends more than the average Android player.
The user acquisition (UA) channel is much more interesting. Generally, there are 4 categories:
- Organic traffic -- the player finds the game on the app store
- Cross-promotion -- the player finds the game through a cross-promotion ad in another game by the same publisher
- Low-value ad networks -- the player is acquired through a relatively cheap network with limited targeting capabilities
- High-value ad networks -- the player is acquired through an expensive network with advanced targeting capabilities
Players that are sourced through different UA channels should have their own gaming experiences with bespoke offers so that the publisher takes advantage of both the high-quality (expensive) UA traffic and simultaneously ensures that the less promising players are still properly served. Ideally, players that come through different UA channels all have their own 'promotional journey' with a succession of offers that are suited to their player profile. This method allows the PM to a) take full advantage of better UA traffic and b) channel more money back to the performance marketing team, allowing them to buy more of that great traffic.
4. Broadly Applicable
Offer targeting is not only applicable to starter offers. PMs can substantially improve the performance of all types of in-game offers with targeting. 'Second offers,' meaning the special offers presented to players after their initial purchase, really benefit from targeting. A lot of information is gathered after a first purchase (the price point the player spent the first time, how long since the first purchase, how much in-game progress he/she has made in between) and each data point represents an opportunity for targeting.
Other examples are expert or VIP offers that are given to advanced and/or high-spending players. These can be special-event or holiday offers that are highly seasonal and only available for limited amounts of time. Other targeted offers can accompany tournaments and challenges, or be presented to lapsed or returning players to reengage formerly active players/spenders.
As a final thought, in many ways a F2P game is 10000 x 10000 Excel sheet with an almost infinite number of optimization problems. The vast majority of these problems possess so many different dimensions that they likely can’t be solved economically. However, offer targeting is solvable with machine learning and multi-armed bandit testing and can increase the value of the game for both the player and the developer.
Today, more than ever, games are not a monolithic pile of code handcrafted by two bearded developers in the basement but rather a hodgepodge of libraries, plugins, SDKs, and APIs. This wide collection of 3rd party pieces of software are duct-taped to make a game. This process is great for making games faster and with more features, but it also introduces many dependencies.
Most vendors push their SDKs onto developers like desperate startup wannabes push business cards at a free networking mingler. We all know the result, your pocket gets full of trashy cards that sit in a drawer at the office for years while the companies pivot and die before the end of the party. SDKs are popular because they create ridiculous dependencies between the game client and the vendor. Worse, than business dependency is the increased risk of crashes in the game. Next time when someone tries to push their SDK onto your game ask for their API. Here are some benefits you will discover.
No Client Update Required
A well-designed game is divided between a game client and a backend server. The game client should focus on displaying the best gaming experience possible by using the client's device to the fullest. The backend server should manage all the data tasks including managing users, leaderboards, and game content. A good game client-server relationship is one that enables developers to add and remove APIs with minimal effort. This is important because changing code on a server is significantly safer. Unlike game clients which run on obscure Chinese devices the server is under complete developer control. Integration of the API on the server side is faster (no "testing on the device" or using Testflight) and keeps the game client disentangled from 3rd party vendors.
What this means is that if you are adding a leaderboard into your game, the game client should be developed agnostic of the leaderboard provider. So instead of adopting the latest leaderboard service provider’s SDK, look for a provider that has an API. Alternatively, if you have a developer who loves doing backend development, maybe he/she takes up the weekend project of writing an in-house leaderboard service. Having the logic and data for a leaderboard sit on a server makes it easier to switch if today you decide to move from the in-house solution to Playfab’s (or vice versa). The migration will be effortless, and the players will not even notice.
API Fits into Existing Game Logic
One way of comparing APIs to SDKs is that an SDK is a ready-made microwave control panel, with code that makes all the buttons, settings, and clockwork. An API, on the other hand, is a long list of small restful HTTP calls that provide minimal functions like: “time left to end cooking,” “list of preset buttons” (popcorn, +5min, defrost, etc.), and “stop.” What this means is that when you use an SDK you are often bringing a vendor’s buttons/screen into your game. While that sounds great at the beginning, if you choose to switch vendors you are looking at ripping the controls from your microwave and replacing with something else. Good luck finding another vendor whose microwave display fits into your vintage 2014 Emerson. The beauty of APIs is that because their functionality is broken down into tiny bits you can make the API fit just about every game. Back to the leaderboard example, you can quickly replace the user registration, leaderboard updating functionality, and the fetching of top 10 players, by finding equivalent API calls from the previous vendor. APIs do not govern the order of operations (too much), and these bits of data can be sprinkled into the game where it is most logical.
Easy to Control Dependencies - No Crashes
The best aspect of APIs is that they take advantage of one of the most tested pieces of code on any OS - the internet stack. The API, let’s not forget, is not code, it is a specification of how to use a third party “website” using restful HTTP requests. So an API cannot crash a game, only its implementation. The good news is that the HTTP requests are the most tested and stable system calls you can make. Another benefit is that unlike SDK’s which can generate hard crashes in the game, API’s at their worst return a non-response. API’s that become unresponsive can be easily checked for in the code, and the game can adjust. Finally, SDKs have complete access to the integrity of the game. All SDKs have complete freedom to open a pop-up window within your game or transfer data at any point in time (often lowering the framerate of the game). These freedoms are extremely hard to restrict as many SDK’s are not open-source making their functionality a complete black box.
When depending on a 3rd party service for data, it makes sense to implement their API on your game’s server. Yes, you might need to hire another developer to do the work because your rock star 3D game developer hates working with Java/Python/PHP (because he thinks that’s for losers), but this is a small price to pay. Finding and fixing game crashes are the biggest time sinks for an entire game team, and with SDKs, they are a challenge you never truly overcome. By keeping the APIs on your game’s server, you are creating an environment where making game changes are simple, safe, and completely under your control.
About 5 years ago, Rovio, the Finnish game developer, launched “Retry” in the iOS App Store. The gameplay was challenging and loosely inspired by the 2013 sensation “Flappy Bird.” Players flew a plane through a two-dimensional 8-Bit-style world and attempted to reach checkpoints. Once they reached a checkpoint, players had the option of either paying in-game currency to unlock the checkpoint as a restart location, or they could watch a video ad to unlock the checkpoint for free.
“Retry” was the first mobile game to use rewarded video ads as a feature of the gameplay rather than solely as invasive advertising. Ever since, rewarded video ads have been an integral part of ad monetization, because, if implemented the right way, they offer a rare win-win situation: the game’s developer generates additional revenue, while the player is rewarded for his/her time spent watching the ad.
The challenge for developers is choosing the right reward that generates recurring, lasting incentives for players to engage and re-engage with video ads throughout their lifetime. Here are 6 of the most effective reward types explained.
1. Soft Currency
Free-to-Play (F2P) games usually use two types of in-game currency: A so-called “soft currency” that is earned by completing tasks in the game (collecting coins, finishing a level, harvesting crops, etc.) and a premium or “hard currency” that can only be obtained by spending real money (dollars, euros, yen, etc.). Incentivizing players with soft currency is a great strategy, and therefore soft currency is the most common reward for watching video ads. The player can immediately spend the additional soft currency on something valuable (heal his troops, acquire more ammunition, spin the slot machine another time, etc.), while the developer receives ad revenue without cannibalizing the premium currency demand which is crucial for monetization with in-app purchases (IAP).
Soft currency rewards offer another benefit: flexibility. It is crucial that the reward adapts based on the player’s in-game progress and profile. Otherwise, ad engagement will taper off further down the player lifespan. Making rewards dynamic requires flexibility and granularity. If you incentivize players with premium currency in low quantities, you will face the problem that the smallest amount you can provide is one unit which could be very valuable. Additionally, later on in the player lifespan, the smallest possible (dynamic) increase is a full unit. An increase from one to two units is a 100% boost and likely overkill for retention. Game developers are therefore much better off offering soft currency. A base reward of 250 coins can easily be adjusted to 275, 300 or further, thereby keeping players incentivized without hurting the game economy and IAP monetization.
Almost all game economies that feature a building or upgrading mechanic use countdown timers that require the player to wait for things like the new castle or latest engine upgrade to be completed. Typically, timers only run for minutes in early gameplay, but quickly increase to hours and even full days as the player gets deeper into the game. Players can typically accelerate the timer by spending currency. This game mechanic is an excellent opportunity to incentivize players to watch video ads in exchange for accelerated timers. From the player’s perspective, every decrease in time is appreciated (shave off 1h from a 12h timer). It makes his/her goal more attainable, which leads to better retention. There is also the possibility that the player is more willing to erase the last 20% of a timer by spending currency, not thinking that he just “wasted” 10 diamonds on a timer, but rather that he saved 10 diamonds (off the original 20 diamond price) by watching a couple of video ads. Depending on the setup of the game economy, the developer has great flexibility in adjusting the rewards, since time can be broken down into very small units.
3. Energy and Lives
If a game has an energy system that limits the number of successive rounds that can be played in a sitting (think Candy Crush or CSR Racing), giving out additional energy as a reward is a good strategy because it offers another win-win. The player enjoys the immediate benefit of being able to play another round while the developer actively boosts player retention without hurting the revenue potential of the energy mechanic. Players that are willing to spend real money on unlimited energy/gameplay will still do so, while other players can utilize the video ads to continue their play. Either way, the developer boosts their revenue.
4. Consumable Items
If your game economy offers consumable items (ammunition, shields, boosters, etc.) providing small amounts of these as rewards for watching video ads is a great opportunity for the following reasons: First, by definition, these items can be consumed so there will be a continuous demand that incentivizes the player to engage with video ads more frequently. Second, offering small amounts of a consumable can have an “advertising effect” where players are introduced to the utility of these items, thereby increasing the perceived value. This increases the likelihood that players will acquire the item either by watching video ads or through IAPs.
5. Vanity Items
Vanity items are purely cosmetic. Their sole purpose is customizing characters, cars, buildings, weapons or backgrounds to the players liking. Because they do not alter gameplay and win/loss ratios, vanity items such as “skins” have become highly popular in competitive player-vs-player (PvP) games such as Riot’s “League of Legends.” The advantages of offering vanity items as rewards for video ads are obvious: the developer can easily generate an endless amount of cosmetic items across different levels of rareness, value, and desirability. Sometimes, all it takes is changing colors, patterns, logos, and/or names to create dozens of new items. A portion of vanity items can even be exclusively available as incentives for watching video ads. Those items become even more desirable while preventing cannibalism of other vanity items obtained by spending currency.
6. Loot Boxes and Gacha
Rather than offering players a distinct, pre-defined reward in exchange for watching a video ad, consider offering a loot box or gacha (virtual packages with a random-chance assortment of in-game items). After completing a video ad, players receive one or multiple randomly chosen item(s). This introduces an element of chance into the video ad reward process and thereby further “gamifies” the monetization strategy. Players are likely to return more often to satisfy their desire to obtain more loot, possibly triggering a “collect them all” mentality.
Every year at GDC there are numerous talks about successful A/B tests. However, the reality is, the likelihood that your A/B test is successful is less than 20%. A successful test requires a good hypothesis, a large sample size, sufficient time to gather data, and assurance that no external factors affect the measurements. Almost always, a failed A/B test can be attributed to missing one of those requirements. Even to conclude that an A/B test will fail can be time-consuming because you’re looking for a needle in a haystack.
Not all hope is lost when a test is struggling to grow its statistical significance, though. Most A/B tests are salvageable, provided the hypothesis is bold and able to generate an effect.
Narrow the Observations
Often the lack of statistical significance is due to a large and varied test/control population. In mobile games localized to different markets with different demographics, player groups can cancel each other out. Other times one player group can dramatically overpower smaller groups. For example, the US/Canada region is the largest market for Western games makes it hard to conduct A/B tests that also includes Latin America and South Asia because the US/Canada preferences will dominate the results.
When a test begins to show no difference between the control and experimental group, and there is a sufficient number of data points, consider narrowing the population. Conduct the test in a single region only. In the mobile games industry, consider regions such as US/Canada, Latin America, or Western Europe. In an average mobile game, this might reduce the population in the experiment by 50%, but that’s a small price to pay for a statistically significant A/B test.
The number one problem I see in A/B tests is the fear of unintended consequences. So, to reduce the fear, the test is scaled back to a minimum number of players over a short time window, often in markets that are not uniform. Picking South Asia as the market to run a new paywall redesign is unlikely to work. The reason why is that the poorer the country, the larger the discrepancy between rich and poor; this means that while the average revenue per user (ARPU) will be lower than in other markets, the whales present greater value than in other markets.
Remember, while running a small test you are forgoing the possible benefits of the new paywall and incurring a small cost of running the experiment. Extending the length of the experiment increases the cost. If you can’t afford to use a larger more representative population for the test, your experiment is probably not worth the effort. So, when a test is showing little to no results, check if the population can be increased to include some additional markets.
Switch Testing Methodology
A/B tests are very rigorous and formal ways of testing a hypothesis. There are however lightweight versions that are still good ways of measuring the results of an experiment. It is easy to switch from A/B to measuring the difference-in-differences (DID) of the experiment.
Explaining DID is outside of the scope of this article, but the benefits are twofold. First, for DID to work you need to verify that prior to the experiment the control and experimental groups showed similar trends. This check is done simply by looking at trendlines and making sure they roughly match up before the start of the experiment. If this check fails, DID won’t work. I’ve encountered this situation multiple times,and I took it as good news because it also explains why the A/B test was not working either. Second, DID calculates the improvement coming from the experiment (if any exists). While it comes with no statistical significance, DID is a widely used method for social science experiments because it overcomes the barriers to running a successful A/B test.
When an A/B test is not developing the way you expect, it’s important to keep track of time. You could spend weeks analyzing data, trying to find that needle in the haystack called statistical significance. Instead, consider narrowing the hypothesis down to a specific population if possible, or, if you started with a very small user group, expand your population. Finally, have a plan B ready before starting the test. Yes, the goal is to have a successful A/B test with rock solid results, but an alternative method could salvage the experiment and be valuable to the game and company.
It’s hard to believe that 5 years ago we launched the first version of Gondola at GDC 2014. As we are celebrating in NY and SF, we want to take this opportunity to thank our customers, advisors, programmers, product people, marketing guys, graphic designers, lawyers, accountants, family and friends for being with us for all these years!
As many of you know, Gondola has recently undergone a significant technical development. We are changing the underlying statistical methodology for our platform from A/B testing to a multi-armed bandits (MAB) framework, an algorithm much better suited for managing in-game offers and rewarded video ads. With the switch, Gondola will be the most efficient game revenue management system available.
To commemorate Gondola’s 5th anniversary, we’ve started a blog to share our thoughts on game optimization and entrepreneurship. We learned a lot in the past 5-year stretch, and you'll see that knowledge come through our blog.
As always, we love hearing from you, so feel free to drop us a line at firstname.lastname@example.org.
Niklas & André
The hyper-casual game genre is very popular among mobile game studios right now. The success of companies like Vodoo and Ketchapp has pervaded the industry, and nobody wants to miss out. The idea of hyper-casual is straight forward: create a simple, easy to understand, engaging, fast-paced core game loop that allows for short playing “sprints” that have an addicting “one more round” effect on players and that can be replayed indefinitely. Studios that focus on hyper-casual try to crank out several new titles a month. While the games are still fairly rough, they are soft-launched to a small audience in countries with low user acquisition costs. Key metrics such as retention rate and average revenue per daily average user (ARPDAU) are rigorously recorded. Developers study the metrics and decide which games make the cut for further development -- most don’t. The few promising titles with the required stickiness are fully developed and officially launched.
Hyper-casual games, even the most successful ones, rarely have long shelf lives, so the monetization has to happen in a matter of months. In most cases, it’s all about high user volume, chart position, effective user acquisition (UA), great ad mediation, cross-promotion, and sheer stickiness. The most lucrative titles generate $40-50M dollars in revenue and cost less than $100K to make. Then, it’s all about repetition; can the studio do it again and again?
Hyper-casual is difficult to pull off. Success boils down to an arbitrage play. Developers need to carefully balance lifetime value (LTV) vs. cost-per-install (CPI). LTV is predominantly driven by incentivized ads while CPI depends on the efficiency of cross-promotion and paid user acquisition.
The arbitrage opportunity is disappearing, though. The hyper-casual genre has become very crowded. As a result, the average CPI is going up. Ad networks are becoming saturated with ads for hyper-casual games, causing the effective cost per mille (eCPM) to go down. As a consequence, the ad monetization opportunity for hyper-casual games is diminishing. The margin narrows, rendering the business model less viable.
For the hyper-casual genre to remain financially attractive, additional in-app purchase (IAP) monetization is required to support the faltering ad revenue. Below are five types of IAP suitable for hyper-casual players.
1. “No ads” IAP
This is the most straightforward IAP for any game that generates most of its revenue from ads: The player pays a fixed amount of real money in exchange for a playing experience that is ad-free. The concept is universally applicable and easy to pull off, but somewhat limited. Many games already offer a “no ads” package, sometimes in combination with premium currency purchases. For those games, there is no real opportunity here. Additionally, many players rely on the rewards they receive for watching video ads to boost their gameplay experience, and therefore might not want those ads to disappear. Further, even if a player buys a no-ads package, it’s only worth a few dollars and can only be purchased once in a player’s lifetime. And, with that purchase, the ad monetization opportunity vanishes entirely for that player.
2. “No-ads” Subscription
An ads-free experience can also be sold as a recurring subscription. The subscription period can vary from weekly to yearly. The recurring payments eradicate one of the most crucial problems of a no-ads IAP, but the other issues remain. Players might not view the disappearance of the ad rewards favorably, and if they do, the ad monetization opportunity is still gone the moment they buy the IAP.
3. Premium Currency - Game Economy
Several well-known hyper-casual games now feature in-game economies that allow players to purchase items from an in-game store (weapons, vehicles, buildings, etc.) for premium currency. Players exchange real money for premium currency -- classic freemium. The opportunity for additional monetization is there. It all comes down to the depth of the economy: What is the maximum amount of premium currency a player can spend if he/she exhausts every option. However, hyper-casual gameplay, with its fast rounds and high repetition rate, usually doesn’t allow for sophisticated game economies where a lot of upgrading, healing, trading, harvesting, and building needs to take place to progress. All of these tasks take time, and, thereby, prolong the core game loop. Long gameplay is the opposite of what’s intended in a hyper-casual game. Narrow economies, on the other hand, offer only so many possibilities for the player to spend premium currency and therefore limit monetization through premium currency IAP.
4. Premium Currency - Skins
“Skins” or other non-consumable items are a viable option if there is a vanity element in the game. This method requires a strong motivation to collect skins in a single-player environment or the introduction of a social layer in the game, for example, a combative component or a collaborative situation. The question is, do the elements that require interaction with other players work with the easily accessible, fast, highly iterative gameplay that defines hyper-casual games. Asynchronous play, where players don’t compete/collaborate in real time, comes to mind, but there are no successful examples of this strategy in the market right now.
5. Premium Currency - Consumables
A game economy that features consumable items (boosters, energy units, bombs) presents a good opportunity for IAP monetization. Hyper-casual gameplay thrives on an immediate reward mechanic. Consumable items that can be bought and immediately used to increase performance, boost speed, or grant additional time, integrate very well with a hyper-casual core game loop. Several successful hyper-casual games in the market show how these mechanics can be a crucial part of gameplay. Additionally, items that can be consumed/bought repeatedly allow for continuous demand without any limits to individual player spending.
As the Hyper Casual market is becoming increasingly crowded, the LTV-CPI arbitrage opportunity is shrinking for game studios. Supporting the decreasing ad revenues with IAP monetization layers can be the solution. For an implementation of IAP into hyper-casual to be successful, the general requirements are to maintain fast, easily accessible gameplay while offering instantly gratifying opportunities to spend in-game currency, repeatedly. With those boundaries in mind, depending on the game, the most promising approaches are skins (4) and/or consumables (5). It will be exciting to see where hyper-casual goes in the next 12 months.
For game developers, A/B testing is part of the standard process for deploying new game features. With a well designed A/B test, developers can get insights about the impact of said feature, how players respond, and if the feature takes the game in the intended direction. However, practically speaking, A/B testing leaves a lot of money on the table because it fundamentally assumes that there is a “best” variant. And, if there is a “best” variant, it must consequentially be applied to the entire user base.
This industry-wide problem is particularly apparent in testing offers and promotions in games. Testing whether the “Thanksgiving Sale” at $9.99 is better than the “Black Friday Sale” for $4.99 using traditional A/B testing methods does not accomplish the goal of maximizing revenue for the developer. First, the A/B test very likely won't reach statistical significance for at least 6 weeks (making the test completely irrelevant). Second, while conducting the test, revenue is not being maximized, costing the developer thousands of dollars by offering poor converting variants. Third, the test assumes that there is a “best” offer to show all players in the game regardless of spending and playing behavior.
The Multi-Armed Bandits (MAB) framework solves these three shortcomings by not assuming that there is a best variant and reaching optimal performance faster than traditional A/B tests. Here is why Gondola migrated to MAB:
Learn vs. Earn
What is often forgotten is the opportunity cost of A/B tests. While an A/B test is running, there is a cost associated with offering less optimal variants as often as the best variants. MAB, on the other hand, continuously switches between the learning phase (used to learn how different variants perform) and earning phase where optimal variants are used to maximize performance.
More Than One Solution
Anyone that has tried to run an A/B test to compare similar (but different) offers associated with an in-game event knows that the results are not binary. Though while planning an experiment it was idealized that players would all gravitate towards one of two variants, the reality is that the difference in conversion between the variants is less than 5%. There are a hundred reasons why this is the case. The most common being that two large player segments with very different preferences for variants cancel each other out in an A/B testing scenario (in mobile games the textbook example is how Android and iOS users show different preferences for offers). The fact of the matter is, there are two good variants, and it is unreasonable to expect the game’s Product Manager (PM) to choose just one. This is where MAB comes in because it never phases out a variant completely. Contextual MAB, which considers the player’s profile, can learn to channel different variants to different players.
Instead of treating every player the same way, contextual MAB attempts to make the best decision regarding learn vs. earn and which variant to present each player based on their attributes/behaviors. Player attributes can include session count, lifetime spending, player progress in the game, previously purchased offers, country, and pretty much any analytics data the game has been recording.
The conversion funnel that occurs in the first 10 minutes of gameplay is thoroughly optimized at launch. However, games are “living creatures" that are continuously growing with new levels, additional game modes, and in-game content for purchase. Externally, the game market is also evolving with new games competing for the same players, User Acquisition (UA) sources coming and going, and the fluctuating quality of players acquired. How optimal are the results from the original A/B test a year down the road? Yes, the game might still be converting players, but chances are that the funnel is no longer optimal.
With MAB, there is never a point when the algorithm determines the absolute best variant in an optimization. This characteristic is a big difference from A/B testing, where there is a point at which “statistical significance” is reached, and the PM can choose the variant with the most favorable outcome with certainty (not a chance occurrence). While optimizing a feature or offer with MAB, there is some traffic allocated to “double check” if non-optimal variants are performing better. This process is captured by the concept of regret: the difference between the total potential reward (ex. revenue) if the optimal variant was selected and the reward accrued from the actual choices made thus far in the optimization. Since MAB is always trying to minimize regret, it naturally limits the amount of traffic allocated to learning.
The game industry is at the forefront of game optimization. The reason A/B testing is widespread is that it offers the ability to reduce the risk of releasing game features and offers while at the same time delivering assurance that the results are not by chance. However, A/B testing is hard to execute due to the volatile player base, low conversion rates (often increasing the minimum number of players to impractical levels), and a long time to reach statistical significance. Today, MAB benefits from the decades of research and algorithms that deliver faster times to optimal performance, do not require the assumption that there is one best variant for all players, and continuously reevaluate to ensure the right variant is used at all times.
In virtually every online industry, product managers (PMs) rely heavily on multivariate testing for purposes of product development and marketing campaigns. A/B testing, in particular, has had a long run as the go-to solution for improving live products that are concurrently used by millions of users, including free-to-play (F2P) games. The reason is that the law of large numbers (LLN) guarantees stable long-term results for the averages of some random events. The more trials performed, the more stable and reliable the test results become.
Given the above, a F2P game with millions of monthly average users (MAU) may appear to be the perfect use case for A/B testing. However, A/B testing can be problematic - detrimental even - when used to optimize revenue in F2P games. There are several reasons why.
The first and probably most important difference about F2P games is that, as opposed to pretty much any other product, only a tiny fraction of the user base pays. In other industries, customers pay a specific dollar amount on a pay-per-use (food delivery, ride services) or recurring monthly basis (Internet service, gym membership). In F2P gaming, it is entirely common for 99% of the user base to not make a single in-app purchase (IAP) or microtransaction and therefore spend zero dollars in their lifetime The remaining 1% generate all the revenue. So, in a game with one million MAU, you only have about 10,000 paying players on a monthly basis. Within that group of 10,000 spenders, there is probably a dramatic difference in monthly spending. 90% of the paying players likely spend anywhere between $1 and $10, while the remaining 10% (0.1% of player base, or 1,000 players) spend anywhere between $10 and $10,000 per month. The curve is exponential, and spenders with monthly budgets of $500-plus are very rare.
When it comes to A/B testing, this means the following: For anything that is not directly monetization-related, such as content updates, new game modes, or additional characters, the product manager can rely on a vast user base to take full advantage of LLN and can expect reliable results in reasonable amounts of time. However, the majority of tests related to sustaining or increasing revenue rely on the behavior of paying players. This factor changes the sample size profoundly. Now the pool of suitable players shrinks down to about 10,000 spenders per month, even less if only recurring spenders or whales are the subject of the test. This small segment of players is divided further to create at least two groups (A and B), a control group and (at least) one test group.
To generate statistically significant results from an A/B test with only two groups requires an extended amount of testing time in a non-changing environment (3 or more player groups require even more time/players). Modern F2P games rely heavily on live operations, events, bi-weekly tournaments, and one-off special content sales. Anywhere between 30-50% of revenue from IAPs and microtransactions come from limited time offers. Monthly A/B test cycles are therefore not suitable for a “Christmas Special,” a “Tournament Deal,” or any other offer/promotion that is available to players for 7 days or less. That means that the testable fraction of players who spend is further reduced, putting the whole concept of “micro-segmentation” in any F2P monetization context into question. The fact that, by definition, A/B tests expose at least one group to a sub-optimal experience, generates even more time pressure to conclude the test as fast as possible.
Additionally, F2P as an industry is a constantly unstable environment. Rarely ever will the gameplay experience for a specific game remain unchanged for an entire month. Moreover, the competitive landscape and other games in the same genre are subject to constant change. Player spending behavior in your game is impacted if your main competitor releases a new multiplayer mode, adds newly licensed cars to his lineup, or runs a major sales event. It becomes even more extreme if an entirely new game or sequel enters the marketplace.
In conclusion, testing of monetization features in F2P games can only lead to reliable results if the test has a) a sufficient amount of players, b) a stable environment and c) enough time to reach statistical significance. Most monetization A/B tests fail at least one of these requirements, often multiple. Still, many critical design and business decisions are made based on A/B test setups that are doomed to be unreliable from the get-go.
There is however an alternative to A/B testing. That alternative is Multi-Armed Bandit testing (MAB). At Gondola, we're turning to MAB for our In-Game Offer and Video Ad Optimization Platform. In our next article, we'll tell you why.
If you are the proud owner of a game that features a game economy (virtual economy), try to consider your players as employees who play your game as their job.
Learning on the job
Like newbies on the job in real life, they will start off with a low level of skill and corresponding low expectations regarding their monetary compensation, i.e. they will have low expectations regarding the amount of virtual currency they earn in return for their "work." As time passes, they will get better at what they do (playing your game). This doesn't only mean that they will explore your game more, including the possibility to convert themselves into paying users (via in-app purchases, or IAP). It also means that their expectations regarding their (in-game) compensation for the work they put in (playing the game) rises simultaneously.
More Experience + More Skill = More Salary
Like in a real economy, the formula "More Experience + More Skill = More Salary" should apply here as well. The more time a player spends on playing a game, the further he dives into a game, the more money he expects to earn. At the same time, if you pay players too much, their motivation will suffer. And while only very few players could ever pinpoint that their frustration with a game was caused by insufficient compensation, a good analytics tool will undoubtedly show how increased player churn "coincides" with plateauing or even decreasing organic earning capabilities. Eventually, like in a real economy, it's all about balance.
Virtual Currency Shortage = Frustration
On the one hand, a shortage of virtual currency inevitably leads to frustration. Players feel that they are wasting their time, that their efforts remain unnoticed and that their improving skills are not appreciated. They feel underpaid, possibly even exploited. Sometimes you hear that "the virtual currency shortage is intentional so users start buying IAPs." Fair enough, but this strategy (of essentially implementing a paywall) only works if you have a highly addicting game. And even if your game possesses these sticky qualities, it will be off to a pretty bad start if you start choking your players for money right from the beginning, way before they even have a chance to get addicted to your game.
Virtual Currency Abundance = Boredom
On the other hand, an abundance of virtual currency will lead to spoilt users. Overcompensation means they can afford a wide array of virtual goods way too early in their (playing) career. They will be under the impression of playing a game that's not challenging, that doesn't reward superior skills, where everything feels numb, too easy, the same. Like in real life, a spoilt user's motivation to put in extra effort to receive additional rewards will suffer, possibly to the point where any kind of "work" (playing) will be subject to rejection. People get bored, and that's the killer for any kind of game.
Whether you are dealing with a frustrated or a bored player, both will inevitably quit playing your game, and they will do so very quickly if the game they are playing was free in the first place. We all know that the cost of customer acquisition is a multiple of the cost of customer retention. Generally, mobile marketing costs are still rising. So once a player is gone, all the work that was put in on the developer's side to onboard him in the first place was futile. Yet, this kind of churn is completely unnecessary and fairly easy to correct, even in a live game. Changing the number of available coins, rings, nuts, emeralds, or whatever your virtual currency happens to be, is a whole lot easier than changing game mechanics, storyline, graphics or other content.
5 Rules on How To Pay Your Players
First and foremost, balance is the key. Always. Abundance is bad, shortage is even worse. Your game, and especially your game's economy, is a highly specialized environment. Take an honest look and ask yourself if it is balanced in the way you envisioned it to be. Are your players truly rewarded and therefore happy? Are they starving? Or are they spoiled?
2. Growing Bankroll
Always ensure an increasing bankroll. While this sounds trivial, game developers often miscalculate the earnings capacity and/or the "game maintenance cost" (ammunition, energy, fuel) the player is confronted with right away. The result is that players barely scrape by after restocking for the next mission and are therefore unable to accumulate any wealth. They feel notoriously "broke" and all those shiny swords and shields in your virtual store will seem completely out of reach.
3. More Money Per Level
Always ensure an increasing earnings potential. Once again, it seems obvious that players should be able to earn more virtual currency when playing level 21 than they were able to earn while playing level 3. Yet, this is often not the case. Carefully measure your players income while he/she progresses through your game. Ask yourself how much virtual currency the player should have a certain points in the game, for example after 2 minutes, at the end of level 3, at the end of World One, once they reach the rank of "Lieutenant" etc. Then ask yourself if the virtual currency available to the average player (or whichever group you want to target) at this point in the game matches the prices (i.e. availability) of the virtual goods you want the player to use/have access to at that time. For example, if you wanted your players to approach the end boss in level 3 with the shotgun, then make sure at least 75% of your players can organically afford that shotgun before level 3.
4. Consider Difficulty
What is also often miscalculated is how increasing difficulty or the lack thereof can affect the virtual currency earning capabilities of players. If a player gets stuck in a certain level for several attempts, his earnings over time will decrease dramatically because he never gets to earn the full amount of virtual currency the level provides (depending on the setup of the game, he might even earn nothing at all if the level is not completed).
Similarly, if a level is very easy and/or rich in virtual currency, a player might replay that level countless time, thereby causing the opposite effect. Usually it's very difficult for game developers to change the amount of virtual currency available in certain levels, mainly because the result will be that all other levels will be out of sync and will therefore need to be adjusted as well. You should therefore consider tweaking the other cornerstones of your economy.
Example: If you determine that players earn 10,000 coins during the first 5 minutes of gameplay, but your first 5 virtual goods are priced in the range of 1,000 to 5,000, you could consider doubling or even tripling the prices of the virtual goods, thereby reestablishing the virtual currency/price ratio you originally intended. Definitely make sure to still have something of great value available after 2 minutes or one round of play. Getting players to buy something in your store very early on is crucial.
5. Gimme More!
When in doubt, always throw in more virtual currency for the player to earn. Collecting 100 coins is always more fun than collecting 10. There is just something very satisfying about flying through a field of coins and listening to the sound of an increasing bankroll. If you don't know what I mean, play a round of Jetpack Joyride or ask yourself why the guys from Orca created Pot of Legend.
A couple of weeks ago, the book "Console Wars: Sega, Nintendo, and the Battle that Defined a Generation" by Blake J. Harris was released. And while the review of The New York Times was somewhat mixed, it inspired me to take a look at my very own video game history, one that actually includes multiple gaming systems from both Nintendo and Sega.
Early Beginnings: Commodore 64
Born in Germany in 1979, I am a child of the 80s, and a teenager of the 90s. My first true gaming experiences came at the age of 9 when my cousin received a Commodore 64 for his birthday. We played The Last Ninja 2, California Games, Archon, Giana Sisters, Bubble Bobble and Manic Mansion for what feels like thousands of hours. I still consider the Last Ninja 2 to be one of the best games ever made, and the music is second to none.
Sega Game Gear
My first "gaming property" was a Sega Game Gear that I received for Christmas in 1991. My favorite games were The G.G. Shinobi, Sonic the Hedgehog, and an Afterburner-clone called G-Loc, although I never completely fell in love with any of them.
I had opted for a handheld because I didn't own a television, and I had chosen Sega's Game Gear instead of the more popular and much cheaper Game Boy from Nintendo because it was newer and featured a color display. I later regretted my choice, mainly because the Game Gear was so clumsy that it essentially required a backpack to be carried around, and also because the backlit screen drained 6 AA batteries in less than 90 minutes. Compared to the Game Boy that was very portable and only required 4 AA batteries (8 hours lifetime), the Game Gear just didn't qualify as a true handheld. The biggest problem was that I only knew one other person with a Game Gear to borrow games from, as opposed to at least 10 Game Boy owners in the neighborhood.
A little more than a year later, in the spring of 1993, I sold the Game Gear via a 200-character classified in a local newspaper (pre-Internet, very old school). The money allowed me to buy a Super Nintendo Entertainment System (SNES). To this day, I can remember how scared I was taking a bus to the city with all that cash in my pocket. I still didn't have a television in my room, so I had to use my parent's television and could therefore not play as much as I wanted. Yet, the move away from the Game Gear was still totally worth it. My first games were Streetfighter 2 and Super Mario Kart. Both were absolutely brilliant, especially when played in VS Mode against friends. They probably remained my favorite games throughout my SNES career. Other great games included Jimmy Connors Pro Tennis Tour, Parodius, Super Bomberman (unparalleled multiplayer fun) and Super Mario Allstars.
I still recall reading an article in "Video Games" about the first PlayStation in early 1994. The console had the capabilities of a contemporary arcade racing machine, and the racing game Ridge Racer by Namco had been ported 1:1 - at least that's what the excited journalist reported from a gaming convention in Japan. The fact that the PS1 had a CD-Rom and memory cards to save game progress and highscores made it even more desirable. So I sold the SNES and pre-ordered a PlayStation. It was released in Germany on 9/16/1994 (I actually didn't have to look up the date when I wrote this, I still remember!). My first game had to be Ridge Racer. It was super fast and had great driving physics, especially with the special analogue NeGcon controller that I got for it. Other milestones were Tekken and Resident Evil. I got so hooked on both that I couldn't wait for the PAL versions of the sequels Tekken 2 and Resident Evil 2 to be released. So in order to get my hands on them as early as possible, I bought very expensive imported Japanese versions. Since I had a PAL PlayStation they would not run unless I used a little ballpen spring to exercise the CD-swap trick (essentially fooling the console into believing it was loading a domestic PAL game). Pretty crazy by today's standards. Twisted Metal, the original Need for Speed and Micro Machines V3 (best multiplayer game ever) completed my list of beloved PlayStation games.
Game Boy Pocket
Towards the end of it's lifetime, Nintendo started releasing derivatives of the original Game Boy. The first one was the Game Boy Pocket, a smaller, lighter, 2-AA battery version of the original Game Boy. Starting in late 1996, it was offered for a very reasonable price. So I finally got a Game Boy because there were tons of great games that I could borrow or buy from friends that had lost interest. Maybe it was a little redemption for the Game Gear experience 6 years earlier... In any event, the Game Boy Pocket was truly portable, and I predominantly used it during the late stages of highschool to entertain myself in class (Shakespeare was just not my thing back then). My favorite games were Donkey Kong and Tetris (duh).
In 1998, I managed to afford another console without selling the previous one for the first time, partly because I opted for a used Nintendo 64 that already came with a couple of games. So I kept the PlayStation and the Game Boy Pocket, and got a N64 on top of that. Nintendo had released the N64 two years after the PlayStation, and although I remember that the system was graphically superior to the PlayStation, it never quite managed to catch up in popularity. Part of the reason was that the cartridge-based games tended to be more expensive than the CDs for the PlayStation, and I remember that variety and depth of the available games were not as great. But there were some All-Star-Quality classics that I will never forget. Super Mario 64 and GoldenEye 007 (awesome postmortem here) are among the best games ever made. 1080° Snowboarding was also awesome.
Sega Dreamcast (and the end of my story)
The last console I ever bought was the Sega Dreamcast. It came out in early 1999 and was the first 128-bit or "Sixth Generation" console in the market. The audio-visual advantages it had compared to everything else that was available at the time (predominantly PlayStation and Nintendo 64) were huge, and I had never seen these kind of graphics before. Everybody knew that the PlayStation 2 would be even better (I had perceived Sega as doomed ever since the Sega Saturn was such a failure compared to the PlayStation in the mid 90s). At the same time, everybody also knew that the PS2 wouldn't be released in Europe for another 18 months, so the Dreamcast was the way to go. In many ways, using it felt like a super polished PlayStation 1 experience. The graphics were stunning, and Soul Calibur might still be my favorite fighting game of all time. The other games I truly loved were Resident Evil Code Veronica, Ready 2 Rumble, NBA 2K, NHL 2K, Tony Hawk's Pro Skater 2, Virtua Tennis 1 & 2 and Ferrari 355 Challenge. I guess the fact that my focus had shifted to sports, fighting and racing games reflects my advanced age at this point. One totally crazy thing I got was Sega Bass Fishing with a virtual fishing rod. Even today, my friends still make fun of me for that purchase.
My console career more or less ended when I started law school in the fall of 2000, and I finally "donated" my Dreamcast to my nephews in 2004. The Dreamcast was the last console I ever bought. The reason is not that I don't like gaming anymore. It's actually quite the opposite: With the right console and the right game, you will find me playing in front of a TV at 4:30 am on a random Tuesday, with no end in sight. Ever since Apple's AppStore opened in July 2008, my new passion have been mobile games. I actually decided to quit law in 2011 and focus on mobile games as a career.
So what decided the Console Wars?
What it comes down to is content. Always. Every game console's lifeline is the game content that is available for it. Aside from drastic price disparity, the winning console in every generation (handheld, 8-bit, 16-bit, 32-bit, 64-bit, 128-bit) was always the one that had the highest density of great games. Great games attracted people to the platform which in turn allowed you to more easily find friends that you could trade games with. One needs to know that in the 90s, a SNES or PlayStation game would set you back at least $40, possibly $50 or more. Keep in mind that those are the actual prices from 20 years ago and consider how much that would be in today's money. The result was that in those pre-online days, hardly anybody owned more than 2-3 games when they first got a console, and if you were a broke teenager that number would only rise in homeopathic increments every year (birthday and Christmas). Essentially all teenagers therefore engaged in "trading" games with friends ("I borrow your Super Mario cartridge, you can have my Street Fighter cartridge for a couple of weeks"), except for maybe the very spoilt/wealthy or very non-social people. In short: If you wanted to have access to a variety of content (games), you better knew a couple of other guys that had the same console that you had. And whether other people would prefer one platform over another was predominantly due to the quality of the game content available for that platform.
In the mobile world, this is obviously pretty different. The price difference between a cheap Android and an expensive iPhone 5S is not 20%, but rather 500%. Many people don't buy a smartphone with gaming in mind whatsoever. And most content is developed for both iOS and Android, and oftentimes simultaneously released. If you consider the $40+ price tags of the old days, the financial commitment for each game today is also a fraction of what it was. The most expensive mobile game I can spontaneously think of is MineCraft at $6.99, and that seems "outrageous" in light of all the free and $0.99 games out there. But don't get me wrong: MineCraft is brilliant, and totally worth $7. So go get it!
Many game developers measure the financial success of their applications by looking at the total revenue generated on a daily basis. Total revenue, however, tells an incomplete story.
The "total revenue" trap
Consider the following situation: the overall revenue of App X is $100 on Monday. On Tuesday, that number increases to $200. Sounds like we are making a killing, doesn't it? Well, the real answer is "maybe."
In order to judge the financial efficacy of a game (or any app for that matter), the developer needs to take into account more than just total (= aggregate) revenue. Equally important is the total number of users that are responsible for generating that revenue. Going from $100 in revenue to $200 in one day is indeed great if the user base of App X stayed (roughly) the same. But what if the revenue doubled from $100 and $200, while the user base tripled? Would you still consider that a success? We might not be looking at a success-story anymore, but rather at an indication that something has gone terribly wrong. Although one might argue that increasing total revenue is the ultimate goal and hence what is described here is a success story, such growth is not *sustainable*. If the revenue per user keeps decreasing, then the game will likely cease generating any profits in the near future. Especially freemium games often fool their developers in just this way.
The solution: LTV
How can you differentiate real success from impending disaster? Don't look at revenue alone, look at user Lifetime-Value (LTV) as well. Calculating and comparing LTVs is the only way to truly measure the financial performance of your game.
The LTV of a game user is the sum of all revenues that will be collected from that user, minus the costs associated with providing the game to that user. Said revenues and costs are accounted for over the entire lifetime of the user, which starts with the game installation, and ends when the user stops playing the game. Compared to total revenue, LTV provides more accurate information in two dimensions: First, it measures the profitability of users, which helps developers identify more lucrative customer segments. Second, it takes future profits into account, and hence is more farsighted.
The reason to calculate the LTV of your existing players is to predict the net profit one can expect from the entire future relationship with a new player. Of course, different players earn revenues and generate costs in different ways, giving rise to the multitude of variants of the notion of LTV that are used by developers in practice, each involving their own set of calculations.
Once a developer has access to comprehensive analytics, calculating a user's LTV is actually not difficult at all. It is however very important to ensure that only LTVs that were calculated the same way are compared as performance "benchmarks."
5 popular LTV calculation methods:
In order to determine which formula suits what kind of game, we recently reached out to some of our fellow game developers and asked them: "how do you calculate your LTVs?" Below are our favorite answers. Note that CPI (cost-per-install) is subtracted in a consistent way across all the LTV calculation methods, and therefore not specifically mentioned every single time. Note also that none of the LTV calculation methods claim to be flawless or generally applicable. They just serve as a rough overview of how actual game developers do approach LTVs these days:
Some game developers calculate their LTVs by only taking verified in-app purchase (IAP) revenue into account, thereby ignoring any social contributions (e.g. a user is very vocal about the greatness of a game on Facebook) or advertising revenue. In short: calculate the total verified IAP revenue per active user. Done.
The "receipt" approach makes sense for games that are focused on monetizing virtual economies, because developers want to determine how much money they actually make on virtual currency IAPs (user conversion within the virtual economy). Simultaneously, they have a strong interest in not having their IAP data spoiled by ads or even piracy (corrupted/fake IAP), which is why they are relying on the IAP receipts.
"Weekly cohort" LTV
Other game developers segment their users into 52 cohorts per year, one for each week. Starting from there, they track the week during which a user first installed the game, and then calculate the LTV for each cohort (weekly group) of users separately. For example, users that joined one year ago are grouped together in the 52-week LTV cohort, while users that joined a month ago will be compared in the 4-week LTV cohort. In other words: weekly cohort LTV can be described as receipt LTV controlled for the acquisition time (i.e., the time user starts playing the game). So someone who first downloaded and played a game 4 weeks ago but monetizes today (by making an in-app purchase) will count toward the cohort from 4 weeks ago.
The "weekly cohort" approach makes a lot of sense for games with higher content depth that motivates their users to return for extended period of times (real time strategy games, adventures, puzzle games etc.).
Game developers in this group only measure LTVs for a specific (rather short) user lifetime, and then simply apply a pre-determined multiplier to the cohort (time frame) they want to examine. The multiplier LTV method thereby computes observed value (rather than life-time value) and uses it as a proxy for computing life-time value. This is essentially a variant of the "weekly cohort" approach, except that the time frame the game developer takes into consideration for the LTV is very limited, thereby ignoring all purchases that actually occur after the pre-determined cut-off time.
This approach allows developers of games with very short core gameplay loops to start comparing user LTVs very early during a user's lifetime. The high amount of repetition (tens or possibly even hundreds of rounds of gameplay per day) naturally allows them to predict LTVs much earlier than for example in story-based games that really develop (and therefore monetize) over time. Use cases predominantly include casino games where the length of each round of gameplay is not particularly dependent on the user's increasing skill, but rather on chance.
Multiplying the average revenue per daily active user (ARPDAU) with the average user retention (ARPDAU x Average Retention) leads to the "average" LTV approach. The first part of the formula (ARPDAU) is a fixed dollar amount, while the latter part is percentage of players that are still active after the first day of installing the game. Average LTV computes an average revenue metric, adjusted with the most recent information on retention. Like total revenue, this metric computes an overall figure for the entire user base.
To be fair, the average retention of all users might not necessarily be a good estimate of a particular user's retention, which is why we are somewhat skeptical regarding this calculation method.
If given a set stream of receipts from a player, every game developer will choose to monetize a player as early as possible during the player's lifetime. One reason is that only money that has actually been collected can be reinvested back into a business. The "weighted" LTV method discounts later purchases in order to emphasize the preference for "early money". Game developers follow the maxim "A bird in the hand is worth two in the bush" and modify their way of calculating the LTV by putting a multiplicative discount factor that diminishes over time in front of all receipts.
Example: Let's imagine the cohort of interest is "all players who started playing between January 17th and January 23rd." The game developer now needs to calculate the sum of discounted revenues for every player in this cohort. That is, he needs to multiply payments received by a discount factor that decreases with the the number of days between the player's acquisition and payment dates. A player who joined on January 17th and paid $1 on January 18th is therefore generally worth more than a player who joined on January 17th and paid us $1 on January 31st.
The difference is then averaged across all players in that cohort. The result is the average "weighted" LTV for that cohort.
While the "weighted" LTV method initially seems more complicated, it is the only one that applies more weight to players that monetize early during their lifetime. The true challenge is to determine the discount rate. There are many options. Some developers pick an arbitrary rule like "$1 now is worth 2% more to me than $1 one month in the future." This is really dependent on their cash flow needs. A more scientific approach would be to have an accountant calculate a capital depreciation rate. Some developers even match the discount rate to the weighted interest rate on their company's debt. Developers usually look at several different discount rates when analyzing weighted LTV.
Games with high maintenance/cash flow needs like MMOs are prime candidates for the "weighted" LTV approach. The same applies to games that seek to increase their user spending by way of aggressive (and therefore expensive) marketing campaigns.
Short of completely ignoring user LTVs, there really is no right or wrong way to approach the whole business of LTV. The correct calculation method depends on the type of game the developer wants to analyze, as well as the specific circumstances he or she is operating under. We have heard that some developers adjust their LTV calculations depending on the time of the year (July generates different results than Christmas-fueled December). Others switch the LTV calculation to a different model because they need to picture their game(s) in a slightly more favorable way to prepare for a board or investor meeting.
The cardinal rule is this: always make sure to only compare LTVs that were calculated using the same method, regardless of whether you are seeking to understand the financial development of one game, trying to compare across multiple games, or engaging in comparisons that involve aggregate industry data ("benchmarks"). Otherwise, you are truly comparing apples to oranges, and you might think that your game is doing increasingly well when the opposite is actually true.
With the incredible success of the freemium monetization model in the mobile space, Game Economies (or more accurately: Virtual Economies) have become the go-to monetization method for the entire industry. Even the conservative console market is starting to use the freemium model in some games with Sony reporting promising numbers relating to PlayStation 3 and 4.
At the same time, freemium has become a new evil, creating the so-called "paywalls" which are essentially obstacles that prevent users from progressing further into the game without paying money. These paywalls are as appreciated as the Berlin Wall once was. Players are complaining left and right about being taken advantage of, and in some circles the concept of "free-to-play" is considered to be nothing short of fraudulent. All of a sudden, people are happy to pay for apps, and the formerly hated banner advertising is "tolerable," while IAPs (in-app purchases) are the devil's children.
Is Freemium good or evil?
The truth lies somewhere in the middle. Sure, there are examples of games that try to milk players for every last cent. EA recently attracted an outrage when it released a new version of the beloved classic Dungeon Keeper. For TouchArcade to give a classic like that a 1-star review, something clearly went very wrong. Another article actually stated that "Dungeon Keeper isn't the first example of a business model completely destroying any semblance of gameplay or fairness from a mobile title. and I'm pretty certain it won't be the last." EA had tried to milk its players, and they paid dearly for it.
But there are also countless examples of carefully crafted freemium games that enrich all of our lives with awesome playing experiences that are truly free to play. And while the right design of a freemium game and especially its money-generating virtual economy largely depends on the game's genre and specifics, there are some commonalities that seem to differentiate the hated games from the loved ones.
If a game's virtual economy is almost exclusively used to make money (as opposed to generate depth and fun), chances are high that this will be noticed by its players fairly quickly. People hate the feeling of being taken advantage of, and they will object if it persists. From a game developer's perspective, it might seem unfair for players to be so unforgiving in light of the fact that they downloaded and played a great game that cost $100K (or $1M) to produce completely free of charge. But this is just an app developer's life.
The best way to ensure being trashed for "exploitation" is the excessive use of paywalls. They come in countless forms. Unsophisticated paywall games try to monetize their players right away, thereby accomplishing nothing short of driving them away before they even had a chance to get into the game. Clever paywall games, on the other hand, cash in on the same principle as a 2-hour TV movie that doesn't bother the viewer with ads for the first 30 minutes (the point in time when you are "invested" in the story) and then hammers him with commercial breaks every 8 minutes until the very end. Similarly, games manage to "lure" a user in and then try to monetize as aggressively as possible once the user has reached a certain point of engagement. They then put 95% of their content behind the paywall and choke the player to a complete standstill unless he pays repeatedly. Only really engaging games can get away with this. We all know of certain match-3 puzzles that have even made our moms pay for IAPs...
In some free-to-play games, players who are willing to pay for special powers, weapons or other features gain a significant advantage over those playing for free. This "pay-to-win" concept can be considered a paywall variation. It becomes particularly relevant in scenarios where players compete with one another directly (multiplayer games) or indirectly (leaderboards, highscores). Some argue that players are not forced to spend in order to progress, while others say that the fact that sheer game skill can be completely outweighed by financial commitments will make true fans abandon a game, thereby hurting both its reputation as well as profits in the long run.
Another variation that has recently become very popular is the so-called "energy systems." They inhibit the player by only allowing for a certain number of continuous rounds of play before requiring "recharging." Example: think of a racing game where the player's 8 gasoline units in the gas tank represent 8 rounds of gameplay. Once empty, the energy (tank) recharges itself through passage of time. Players can avoid that detour by spending money to either recharge (and oftentimes simultaneously enlarge) the tank or eliminate the restriction altogether.
Energy systems have however also been the subject of frequent complaints, mainly because they seem to be completely artificial instruments of restrictions in most games that are only geared towards monetizing the player. For that reason, some people actually call them "soft paywalls."
Selling an enhanced experience
Virtual economies can also serve different purposes, and it is equally sad and unfair that many games that do not deserve the "exploitation" label are thrown into the same category just because they are free to begin with, feature a virtual economy and offer some sort of IAP.
The biggest difference is this: games in this group predominantly view game economies as a tool of generating fun and content depth. The virtual economy aids the gameplay, rather than obstructing it. Parker's classic board game "Monopoly" is a great example for an entire game that is solely based on and around the concept of a virtual economy.
By the same token, video games employing virtual economies have been around for at least three decades. Do you remember the items Link could buy in the little store in "The Legend of Zelda" on the NES in the 80s? Yep, 100% virtual economy, even back then! At the time, there were no App Stores, no IAPs and not even the Internet. Neither Nintendo nor anybody else could capitalize on their virtual economies. So why did game developers implement virtual economies in the first place?
The answer is simple: to give the user a better experience, to make their games longer lasting and more engaging, or simply put, to make their games better! We have all played games where we couldn't wait to get the new gun to finally take on that endboss, where we played all night to make enough coins so that we could afford the new engine, or the armor or the magic potion the next day. Virtual economies motivate, they give us things to aspire to. They are therefore an awesome tool for making better games.
So how do we create great freemium games that keep players happy? By allowing them to organically make sufficient virtual money by playing the game to sustain themselves in the virtual economy. And how can we monetize them simultaneously? By offering them the various opportunities to either enhance their playing experience or accelerate their game process by virtue of spending actual money. Buying an upgraded weapon, a pack of time boosters, a coin doubler or unlocking a new world, all these things, if done right, enhance (improve) the playing experience and provide true rewards to the player. And players who feel rewarded don't feel exploited.
For the vast majority of freemium games, a paywall concept is not suitable. More often than not game developers end up not only facing enraged users, but also harming their very own financials by trying to monetize players too early or too aggressively (or both), thereby simply driving them away before they ever spent any money.
If you have a truly sticky game and want to make the most money you possibly can, there is no way around paywalls. Despite all the complaints, paywalls are not per se wrong. We have heard producers in major game companies say that "you are not monetizing aggressively enough if you have anything above a 2.5 star average review." Others say that if you do not get the occasional curse from your players, you are not engaging them heavily enough. It all depends on the developer's individual perspective and goals. And, if implemented into the right game, there can be no doubt that paywalls are responsible for many of the Top Grossing games out there today.
But you can also monetize your users without exploiting them. Your game economy will be appreciated if it offers an enhanced experience or accelerated progress for money, not the ability to progress at all. Always allow players to move through the game without having to pay money if they are willing to spend ample time. Yes, you might not monetize as well as with a more rigorous approach and leave some money on the table. But you might have also done yourself a great favor and monetized your game perfectly by withstanding the temptation to overdo it. Either way, your game will probably be much more liked, and you might make up for the decrease in initial monetization by increased user retention and therefore increased LTV (user lifetime value). Moreover, there is strong chance of improved user acquisition courtesy of great reviews. After all, these are the factors that are largely responsible for how much money you make at the end of the day. A game is kind of living thing, and it gets better the more carefully all competing interests are balanced.