Analyzing free-to-play games development: the Game / Team Clock


There’s currently a lot of information out there about how to approach the free-to-play business model and its implications in the Game Development Process. It becomes increasingly complicated to make sense of all this information, however: how does it apply particularly to successful games; how does knowing and doing all this prevent a game from failing, and how we can make it work on our game to succeed. In this post, I’ll explore a framework to evaluate free-to-play development execution. This framework is visualized by arranging your game’s needs and your team’s strengths on a Clock shaped chart to assess your game’s viability, opportunities and risks.


Figure 01: An Example of the Game/Team Clock.


By taking a user centered point of view for inspiration, we can think about the questions players implicitly ask themselves at each step of their lifecycle as “users” of our game. The key to this framework is putting yourself in the position of a player of your game, and asking yourself 12 questions from that perspective:

  • What is the game about? The first step is figuring out a clear, unique, compelling way to describe a game to quickly grab players’ attention and interest.
  • Where and how do I get to know about this? There are many venues in which people can get to know new things: TV, websites, social networks, etc. This is why is so important to know where people are spending time.
  • Do I have access to any of the platforms in which is available? In an era with so many different gaming enabled devices, the platform in which a game is available shapes not only the development challenges but also the potential number of players to reach, and their expectations.
  • Do I understand and like the gameplay? Once you can play a game, you start familiarizing yourself with it and decide whether you understand, and like, the game or not. I’m stressing the difference between understanding and liking, because they’re both important when we compete for people’s leisure time.
  • Do I like the art and content? Games that look and feel nice do get noticed and hook people. This encompasses art, the story, the sounds and music, etc.
  • Does it suit my lifestyle patterns to play? Some games are enjoyable at any moment in which you have 5 minutes. Others require a heavier investment of time and scheduling, such as PC free-to-play games. But if a game fits into your gaming patterns (every other weeknight and some longer time on weekends, for example), then you’re more inclined to feel that you can commit to including the game into your busy life.
  • Is it not a burden? This is not asked right in the beginning, but it is increasingly present in the game’s interactions. Is it sending too many push notifications? Am I getting lots of prompts to pay before even trying to play? Is the game getting too frustrating? etc.
  • Do I want to keep playing this game? After the initial glow of the game and once you understand and like what it is about, does it make sense to continue playing? Are you getting somewhere? Is there a meaningful goal to achieve? In other words: Are you getting increasingly better engagement?
  • Do other cool people or friends of mine play it too? To play is inherently social, and it’s very rewarding to know when your friends enjoy the games you like too, or when you get to interact with other people based solely on the experiences a game enables.
  • Do I take joy in identifying myself as a player of this? This element is subtle. Are you grateful for the good times the game has given you? Do you tell (and encourage!) other people to play this game? Do you start thinking about why you like it and is it becoming a little piece of your current identity? This is a way to essentially figure out whether your game’s brand is resonating with the player or not.
  • Does this game have clear value for me? Next to identifying yourself as a player of a game, this must offer a clear value for you as a player. It’s the cherry on top of making the game part of your lifestyle. The game gives you something beyond fun. It’s a hobby, it reminds you of your childhood, you have enjoyed it so much that you want to see more of it and seek ways to support it, you tell other people that you play this game for a reason that is crystal clear for you.
  • Is it worth paying for this? After all this, having an answer for all the previous questions, you consider the trade off: Is it valuable for you to pay in the game for the things it has to offer you?

This is roughly the path of questions people implicitly ask and answer to themselves from first learning about a game to then deciding to pay for it.

This is radically different from non-free-to-play games in which the questions from 4 to 11 have to be answered before playing to whole game at length. This made the game development process so distant from people’s feedback that studios usually needed to rely on expensive focus groups, risky leaps of faith and existing brands or IPs.

Moreover, given the platform choice for some games, like in console games, many questions were rendered unnecessary to address because the platform comes with a set of expectations and assumptions. For example: you expect on the latest consoles to have things such as highly-polished graphics and long experiences to justify spending $60 on them.

These questions can be mapped to concerns you need to take care of when developing and launching a game:


Figure 02: Questions and their areas of concern.

Let’s adventure some definitions for each one of these concerns:

  • Unique Value Proposition: It’s the short, clear, attractive, unique description that permeates your whole game.
  • Visibility: The aggregated set of outlets in which people can find out about your Unique Value Proposition, visible where they spend time.
  • Platform: The place/device where people play your game.
  • Gameplay: The core experience of your game and its evolution.
  • Content: The elements that shape your game’s core experience and enable people to perceive it through their senses.
  • Lifestyle affordance: The way all previous elements fit on the (ever diminishing) leisure time of people’s busy, constrained lives.
  • UX Affordance: The way all previous elements not only fit, but are made more accessible, convenient, and affordable.
  • Meta Gameplay: The motivation for the longer run.
  • Community: The social aspects of your game and the part of the experience that happens largely outside your game application.
  • Identification: The positive encapsulation of all previous elements for each player.
  • Value accessibility: The clear realization of the reasons why YOU play THIS game (and not others).
  • Monetization: Whether you’re willing to pay for the previous reasons or not.

Additionally, we can map each of these topics to key areas of the Team’s Expertise, and which areas carry the biggest effort on each topic (note: your mileage may vary):


Figure 03: Concerns and their key driver Expertise.

You start with a strategy to make a game, coming either from business or creative inspirations, and then you make sure Marketing puts the game on people’s minds, making them come together to play a game designed and developed by tech, art and design teams, with additional effort contributed by teams including Product, UX, Live Operations, Community Management and Analytics to operate the game as a service (even if a light one), to finally encompass this pursuit as a Business.

Of course, for each team, considering your proper definitions of the 12 topics and your particular game, the matching can be different, and all the Teams areas of Expertise are involved to different degrees on each Player Concern:



Figure 04: Player Concern / Team Expertise Relationship Matrix.

Entering: The Game/Team Clock

Now, we can map these Player Concerns and Team Expertise areas to regions on a clock for better visualization:


Figure 05: The Game Clock.

For your particular game, each “hour” will demand more or less effort to make it successful. Conversely, depending on the particular shape of your team, you can score competence and expertise in lesser or higher degrees on each of these Concerns. The key is to be conscious about your game’s requirements for success, to be honest about your team’s execution reality, and to make a match between your game and your team, that has the lowest possible gap.

We can even place the game companies that focus on each Team Expertise area on different parts of the clock as well:


Figure 06: The Team Clock and the types of teams they gather.

Successful teams play on their strengths. Since we have now plenty of platforms and the possibility of using quantifiable insights through metrics and analytics, a lot of new game companies are created focused only in the early life cycle, considering aspects such as Monetization, the Unique Value Proposition, Marketing/Distribution and the Platform considerations, usually under the assumption that the next phase is “just” the game part.

Indie Game Developers start right from the Platform, Gameplay and Content aspects before exploring the other areas, because their strength lies in the game development part, considering that the Unique Value Proposition, Visibility and Monetization will come naturally from a great game.

In the subsequent region is where we have the divergence and conflict on approaches, because from 6 to 9, we can find scaling, growing startups together with successful indie game developers. So which approach can get you there? It will depend on your particular project and how well it aligns with your team’s strengths.

No matter how much effort you put on the early part of the cycle, if your game is not good enough, it will not take off. No matter how much marketing, monetization, analytics, etc you throw at your game besides great gameplay and high quality content, you will only continue to fool yourself with hope until you run out of money. On the other hand, a unique, great polished game has no chance to survive on a small platform, if it’s complicated or a burden to play in itself, or if it’s pursuing an audience blindly without correcting it to cater better to the people that actually like the game.

In general, we tend to fixate on evaluating the approach of scaling startups or successful indies, disregarding the complementary elements that took them to 6 to 9, and hopefully on the holy path to 12. Startup founders learn all about the business elements of the ones making it, disregarding the importance of having a great game and a great team to execute. Indie developers try to emulate successful Indies that already have strong games, that have become brands of themselves, and don’t pay attention to how the successful Indie started, and which mix of factors made them successful beyond having a great game.

Finally, in the region from 9 to 12 we have the “Unicorns”, the games and their developers who are very, very successful. King’s Candy Crush, Supercell’s Clash of Clans and Hayday, and Riot’s League of Legends. Among the Indies we can consider Mojang’s Minecraft, together with Nimblebit’s Tiny Tower and their subsequent games, among others.

The way to use this framework is to assess your projects needs and your teams strengths, providing a score on each User concern and Area of expertise, to look for potential gaps.



Figure 07: Example Game/Product Needs and Team Expertise.

When we have a slightly higher competence for something required on our game, we have a competitive advantage; conversely, lacking the expertise to address needed concerns for a game or product to be successful pose Execution Risk. A considerably higher expertise over a Game/Product need is untapped potential, and a good alignment is Execution Feasibility.


Figure 08: Game/Product Needs versus Team’s Expertise comparison.

It’s important to note that even though this framework is conceived for free-to-play games, it can be extended to premium games as well, to study how to make the most of your team’s key areas of expertise, and how your work fits in the larger scope of other teams and their games. This is, for example, the reasoning to include Mojang as an example of a successful indie game developer: it doesn’t operate Minecraft as a service (not heavily at least), but it has a brand so strong that its operations can be roughly described as “Continue catering to your (large and established) audience”.


This framework is a practical way to ask questions about your game and your team to make the decisions that effectively contribute to your game’s success. The questions, the Player Concerns, the importance of each element may vary greatly among platforms, game genres and your team’s motivations. My hope is that this can be an effective starting point.

(Originally published at Mobile Dev Memo, on June 9th, 2014).

A practical Free to play Game Economy Design example -with spreadsheet!

A freemium game typically involves an in-game economy that is crucial to the game’s performance in engagement, socialization and monetization. This economy is also closely related to the game’s balance, by being positioned right on the sweet-spot where challenge and progression intersect. To understand how all these things relate to each other, we’ll review a fictional small game and will take a closer look at a basic set of parameters for the game economy on an actual spreadsheet.

The Game: “Chess Blitz”

Let’s consider a fictional game, “Chess Blitz.” The game uses a traditional chess board and pieces, with the following alterations:

  • The board starts empty, except for the King on a random tile of the first row for each player. The player has an inventory containing the standard set of pieces, plus slots for a limited amount of boosts.

  • On each turn, players can make up to 5 actions: deploy pieces, move pieces according to their movement rules, or use boosts.

  • Capturing a piece awards gold; equipping a boost before starting a match costs gold.

  • The winning condition is to capture the opponent’s king (not just a checkmate), which awards gold.

  • There are three boosts:

  • Bombs: When deployed on any tile, a bomb destroys the piece on it (if any) and a random number of pieces on the eight adjacent tiles. Destroyed enemy pieces do not reward gold.

  • Freeze: When deployed on any tile, it freezes the pieces on that tile and the eight surrounding tiles for the next turn.

  • Shadow: When deployed on any tile, shadow hides the pieces under that tile and the eight surrounding ones for the next three turns. The opposing player can neither move to nor from the shadowed area.

The previous boosts, and packs of ten units of gold, appear randomly on empty tiles of the middle two rows of the board at the beginning of each turn. If a player moves a piece to a tile with a randomly dropped boost, it is equipped if there’s room available, or it disappears if there’s not. Gold is added automatically.

Boosts or gold packs on the tiles can be destroyed by bombs; they can also be hidden with shadows, but cannot be frozen.

The player can have several matches running asynchronously.

To get an idea of how something like this would play, Hero Academy is a good example, as this game somewhat approximates Hero Academy’s gameplay. (Please note that our example is only to illustrate the concepts discussed in this article; “Chess Blitz” is not necessarily well balanced or consistent in its design.)

The Economy

The game has the following set of parameters that define its balance and economy:


Table 1: Parameters and values of our in-game economy.

These parameters, together with the previously described rules, define the game’s balance and economy. For the purposes of this post, we will assume that they define a reasonable game experience. If you want to learn more about Game Balance, Ian Schreiber’s Game Balance Concepts is a good place to start. Also, Daniel Achterman has several posts on #AltDevBlogADay covering spreadsheet examples for content and systems design.

We will also not cover all the extensive product metrics themselves; our goal is to model and better understand the relationship between in-game parameters. For a more detailed explanation of product metrics, see Andrew Chen’s “How to create a profitable Freemium startup (spreadsheet model included!)” and Eric Seufert’s “A comprehensive free-to-play game model: revenue, DAU, virality, and retention (spreadsheet included).

In this example, we need to classify each parameter into the following categories:

  • Numbers visible to players: This defines the initial experience and sets the expectations—at least at first—of the game’s fairness and relationship among different game elements. These should change only for the player’s benefit, if at all. Otherwise players will perceive the game as “not playing fair.” In this category, the most important concerns belong to game design and UX, otherwise, you might end up with something that it’s not fun or engaging to play at all.

  • Numbers invisible to players: These numbers can be adjusted after a game, or a game’s feature, launches. These are usually modeled as random variables whose distribution is typically hidden from players (Note that savvy players may guess/estimate this distribution in the long run). The hidden and random state of these variables enables game designers to  carefully tune a game post-launch without significantly impacting the player experience, at least when done within reasonable bounds.

In an actual spreadsheet, we will also examine the following sets of numbers:

  • Metrics: These are the numbers that are going to be tracked, or in the case of live games, that are currently available. When the game hasn’t been released yet, these can be approximated by running simulations or multiple play-testing sessions. In the case of new features added to a live game, they can be estimated using existing metrics from similar mechanics.

  • Desired outcomes: These numbers detail the desired monetization, socialization and engagement goals within the game. This set is where all business and product concerns are concretely modeled together with the game’s balance itself. Using both metrics and desired outcomes, developers can adjust their game while it is live.

These numbers and their relations can define a basic vision of the economy as a Flow Network, considering “sources” (e.g. where coins come from) and “sinks” (e.g. where money goes) of a particular resource we want to monitor (i.e., the first two sets of numbers) and the relation among them with regards to player behavior and the game’s engagement, socialization and monetization goals (the third and fourth set of numbers).


Figure 1: A simplified flow network for the game’s gold.

The players’ behavior that is measured (or in our case, simulated) through creating matches and playing against other people determines the amount of gold they can earn capturing pieces, winning matches and through random drops, all of them within the stated values for each of these actions (e.g.: inventory, rewards). Another source of gold is via purchases, a.k.a. our monetization point.

The price of our monetization point and the distribution of random drops allow us to tune the gold flow in the game (although we can also influence that indirectly by adjusting the other probabilities we previously defined).

In Figure 1, the size of the coins illustrates a particular case of relative size for gold earning among players, from the metrics, for each source. Our goal is to model this flow of both player actions and resources, considering desirable bounds for particular values of player behavior we want to monitor.

With all this information, we can construct an actual spreadsheet! Take a look at it here. In the first section (Table 2), we outline the values that exist on several interfaces of the game, show the numbers that set the expectations of players and define the core balance of the game.


Table 2: Game parameters.

Table 3 captures the random distributions or values that can be adjusted while the game is live (for the purposes of fine tuning):


Table 3: Adjustable values and distributions.

The third set (Table 4) encompasses all the metrics that we currently track to determine the status of the game’s balance and economy (Again, in our case this is a simulation of values; note that by using the “random” function, these values change in every instance of the document. Bonus points for you if you understand the reasoning behind each formula on the simulation).


Table 4: Simulated in-game metrics.

The design of an in-game economy involves decisions about which metrics to track, since you want the maximum amount of actionable information from the smallest stream of data possible. In this example we can see several metrics, some of them tied more to the overall product (e.g., DAU, invites), some of them more closely related to game design issues, such as boosts purchased and used.

Notice that we have three columns labeled “UG.” These columns stand for “User Groups,” partitioning the audience in three different sets. This is important because average values across all users tend to “hide” subtle nuances and differences in their behavior. It is a very good practice to consider at least three different segments partitioned according a quickly computable rule, such as number of consecutive active days, number of daily sessions, etc. The rules to segment players would vary greatly depending on each particular game, data sources and other practical computing reasons, such as tools available, ETL pipeline, frequency of desired reports and their calculation time, among others.

An important note about data sources: If your game is already live and you’re adding features, you can approximate future engagement based on previous player behaviors. If it’s a new game and you have data from previous games, you can do the same, adjusting accordingly for differences in gameplay, audience, platforms, etc. If you have no data at all, we recommend performing simulations that consider thorough systems design, market research and other sources of information. However, this process is beyond the scope of this post.

Finally, it’s crucial to examine the product’s goals, metrics and checks:


Table 5: Desired in-game metrics and outcomes.

In this section is where all the core economy design happens. In our example, we set minimum and maximum limits for gold, daily sessions and game invites, as examples of monetization, engagement and socialization, respectively. We also have additional columns to check if our reported values are within our expectations. These ranges should take into consideration the game funnel model you wish to have for your game, as well as the User Groups you’ve defined. You should also include any metrics goals you have for your game’s balance that are considered “healthy” for the game, such as limits on the usage of boosts, the usage of a boost relative to each other, etc. A game like this would probably require a matchmaking system, which can also be determined by the metrics regarding the players’ performance on matches.

However, this is just the beginning. A full economy design of a complete game would involve players’ progression, content unlocks and virtual asset purchasing information, dual (or multiple) currency tracking and relationship, deeper socialization metrics regarding other player actions and their currency or gameplay incentives, among many, many others. Additional questions from our example game might include:

  • How can we model the inclusion of a premium currency and purchasing of premium sets of pieces?

  • What would happen if we raise the limits for pieces in the inventory through purchases?

  • How would it affect the game if there are no limits in the inventory, but deploying a piece costs gold?

These questions can, and should, be considered in a full economic model for our fictional game “Chess Blitz”; however, we are only looking at high-level concepts in this example. Good, tightly designed games require input from many other sources, e.g., market studies, systems design, platforms and user acquisition channels.

Originally published on April 29th, 2013, on

Designing “10000000″ as a Free To Play Game

1000000 [iOSAndroidSteam] is a puzzle-runner-rpg-like game developed by Eightyeight Games. If you haven’t played it, I seriously recommend to check it out since it’s awesome, and its story of development and success is as amazing and inspiring as the game itself.


Figure 01: The game in its PC/Mac port.

What’s also interesting is that the game allows itself to be designed as a Free to play game. It is a particularly good example because is indisputably a great game, is accessible for any platform you’d like to play it and we can use it as an example for this thought experiment of making it Free to play.

So here we will discuss a brief overview on how the game can be tweaked and expanded in its design to suit a Free to play strategy, and what would imply doing so, changing from a defined product to an ongoing service. From this point, we’ll assume you have played the game. If you feel like just reading, check here or here (not recommended).

Design changes and expansions

Using the Free to play triangle lens we can discuss three venues for monetization: Skips, Unlocks and Boosts. They are based on traditional “sim management” games, so we can adapt the triangle here to Content, Unlocks and Boosts.

  • Content: Pretty much all the game’s content is available behind locks achievable through gameplay and achievements, but the game could include more dungeons, sets of tiles, new achievements, episodic content or new heroes. Also, maybe just selling the music can be a good and simple trick.

  • Unlocks: All the locks on things that are accessible through “repairs”, the list of upgrades, access to dungeons, the alchemist potions. An additional element could be putting caps or limits on the amount of resources (wood, rock, coins and XP) that can be had at a time and unlock them through monetization/other resources. In 10000000, you can carry at most 4 items on a run: another potential source of revenue could be selling the ability to increase that limit so players can carry more.

  • Boosts: This is relatively straightforward, since when you’re playing you receive weapons, food, keys, orbs and scrolls that you can carry to the next run and act as boosts. All of these can be sold separately.

There are also two key areas for feature expansion. The first is a storage room that can hold any extra boosts the player found while running or purchased at the store. This causes the player to manage more effectively how they proceed on each run. These limits could be expanded through purchases.

Second, the Alchemist room enables a particular effect at the cost of a trade off. This should be changed to a boost fashion in which these alchemist effects can last only for one run, possibly with less strict tradeoffs and also stored in your storage room.


Figure 02: The Alchemist’s room

A third, possibly controversial expansion would be “crafting”. Retention is a huge issue in mobile, and something that could help to promote players to craft a plan to come back can be precisely the tradeoff of time versus money for alchemist effects, in which traditional game resources can be used so their “resource flow” closes. This is particularly important since puzzle/running games might have good retention but low frequency of use per week. Hence, this add-on would allow players to increase their chances to move through an engagement/monetization funnel in a better way.

However, the Triangle suggests to monetize with at most two of the methods, which is sound advice. Given that 10000000 isn’t a place to “enjoy watching an aquarium” such as DragonVale or Hay Day, the clever thing would be to stick with unlocks and boosts.

So that would be it, if we were only considering monetization aspects of Free to play games. As of now, we have discussed monetization venues for in-app purchases (which many paid games include), but free to play games must include social aspects within their designs. In a nutshell, non-paying players can be your best sources of new players (for another more general discussion, see here).

What social features can we include in this game? Endless runner games usually allow players to share their scores as a text on social networks such as Twitter or Facebook, but that’s rather limited given the unique aesthetic of the game, and specially its music. The guys at Nimblebit know this very well with their feature of sharing towers in Tiny Tower, planes on Pocket Planes and now video on their latest game: Nimble Quest, through the Everyplay service. See it at work here.

10000000 is an excellent game to share video replays to feel closer to the excitement of the game itself and sharing amazing feats that can be achieved in it. One additional content tweak would be increasing the animations and “pyrotechnic effects” of achieving chain reactions with the tiles in the running zone. When you’re playing and doing amazing feats, you feel great but you’re focused on the tiles, and when someone else is viewing, it would be nice to have something for other people to watch that is spectacular.


Figure 03: Sonic performing stunts mid air.

For example in Sonic Dash, they control the pacing of races and allow the player to do some “quick time swipes” for Sonic to breakdance in the air. This looks awesome and also wins some rings if done right.

If we want to go nuts, we can even discuss a room dedicated to store these glorious gameplay images and/or videos so the player herself can revisit them in the game or have it for her friends to see, but that’s a lot of additional work, development-wise.

Execution tradeoffs

We have discussed monetization and social aspects for the game to be considered a Free to play game, is that it? Well, not so much. Free to play games start when the game launches, and operate as a service, not a product. This cannot be stressed enough as it is easy to overlook in practical decisions and prioritizations how to approach the execution of these designs and handling the expectations associated to them.

So what does all this mean? In addition to the elements mentioned above they need to pass a check for game balance from a qualitativeperspective and a quantitative one, hopefully informed through analytics -especially when the game is already live. Additional checks must be passed regarding UI, accessibility, and timing of the monetization elements. There’s a huge amount of games that hide away the options to pay more under too many screens, unclear menus or the wrong timing for monetization, making it annoying instead of convenient.

Adjusting the expectations is another important issue. It is fairly easy to fail at Free to play with a great game, even spectacularly. Many times this is because developers fail to see the service aspects and just throw in some IAP without too much thought about them, only to claim foul when they don’t get disgustingly rich overnight.

Then all the work needed with art, programming, balancing and testing needs to be estimated and considered to be split in several iterations that have different tradeoffs on different platforms when they go live. For example, monetization re-designs would allow the game to be set free and include more revenue venues but it would not achieve all of its strength without the social features. On the other hand, working the social features first would put the game in the eyes of more potential players that still would be stopped at a paywall if they’re not willing to pay anyway. However, the social features discussed here can be integrated in the game without making it Free to play at all and it could potentially be a good thing anyway.

In my particular opinion, I would thoroughly design all the aforementioned elements up to a point of actual estimation of the development work needed and consider the tradeoffs with the actual resources available and any other strategic considerations for the game. 10000000 is already present on several platforms and the best course of action would be to set up a minimal analytics service on all platforms to monitor the game’s performance and then decide how to go from there, possibly making it free to play on Android first (and possibly anAsian localization). Then moving these changes to all platforms including the social features, that can be developed for the game to scale once you have data and revenue to support such scaling.

Where do we go from here?

This was a general discussion to a deeper level of how to take an already great game to millions of players through the Free to play model, considering several aspects of the decisions involved.

For more detailed discussions on monetization and Free to play, I recommend to check:

To understand all the nuances involved in the design of a Free to play “casual” successful title, Candy Crush Saga:

The controversial decision made by Candy Crush developers of not to use a virtual currency in their game and going with direct purchase of boosts draws special attention. This was a risky and bold decision (albeit a good one given the game’s performance).

For expectation handling and pitfall avoidance: 7 Ways to Fail at Free-to-Play. On social aspects, a previous post of mine: Some social game design principles before launch. More resources in general, my previous post: Almost everything you need to know to enter mobile game development on 2013.

In summary, 10000000 is a great game, that includes within itself many options to make it a game that allow players themselves to put a better price on the value of the whole experience -a fun, convenient and social experience. When we analyze the tweaks and additions we can make to the game, we must take into consideration the costs and benefits of each improvement and how they can add value to the whole game incrementally. This will change from a finished, bounded product to an ongoing live service dedicated to its community of fans.