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

(This is a guest post by Raul Aliaga, a senior game designer and producer. You can read more from Raul at his website and follow him at @raliaga.)


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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. 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.
  10. 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.
  11. 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.
  12. 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:

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