MonthJanuary 2015

Free-to-play as an indie?


As an indie game developer, I will probably never build a free-to-play game again.

Before I get into the details on why I’m saying this, let me add a little context. As it is often the case, I got the idea for this post while reading an article on about the free-to-play marketing trends for 2015. I’ve had the chance to develop a free-to-play game during my time at Execution Labs and got to understand the lingo and market specifics for this type of game. If you check out the article, you’ll have a glimpse of how complex making, or at least marketing, a free-to-play game has become. Between the load of knowledge and acronyms you need to know and the sheer complexity of building and maintaining a free-to-play game, I think it’s just not worth it.

Free-to-play data

The type of data you need to look at when doing free-to-play

Free-to-play is hard(er) to design (well)

Traditional/premium games are hard to design. Developing an original concept, refining the gameplay into something fun, maybe develop an interesting story and possibly adding some selling features such as multiplayer, while dealing with technological difficulties is no easy task.

I found free-to-play design to be way harder.

This is because you’re no longer designing a game that will simply be fun. Proper free-to-play design needs to integrate the business elements that govern this type of game directly into the design. This means your user acquisition, retention and monetization need to be thought out, from the start, in your game design. It’s not just about making a game that is fun and interesting. It’s about building an experience in which a player, who did not pay for the initial game, will want to come back every day, tell his friends (or complete strangers) about to game to invite them in and will want to eventually pay. This is excessively difficult to do, because as soon as one of those three elements are off, it will be difficult for your game to succeed. From the player’s point of view, the game also has a lot less value that a traditional premium game. Unless the player becomes hooked and pays, the game essentially becomes a throwaway product. This puts a lot of pressure on the developer to make a game so compelling (or with a really efficient hook) that the player does not simply abandon the game or uninstall it immediately.

These elements constitute something that is difficult to deal with as a developer, even more so as an indie. If getting players to stay and eventually pay is hard, it means you need a lot of players. Which brings me to my next point.

Marketing for Free-to-play is as expensive as marketing for AAA games

You may be tempted to think that by making a game free, a whole bunch of people will download it. The truth is there are loads of other free-to-play titles out there and unless yours stands out in any way, it will drown in the torrent of small free-to-play games that are released every day. So, how do you get players in your game? The answer to this, at least for companies that have money, is to use ads. This is usually in the form of publicity in other games, Facebook and other reliable sources of players that incite players to install another game. These types of ads are driven by Cost per Install (CPI) in which the company that shows an ad pays when a player actually installs the game presented in the ad. As you may have read in the aforementioned article, it can cost between (on average) 1$ to 2$ to acquire a player in an ad network. This can add up pretty quickly. The article also mentions that if a payed-for user ends up paying 10$, then it totally worth it. That would be true, but another common statistic is that a very small number of players actually end up paying. In order to get those 2% of paying players, you need to pay for a lot of other users. These users will, at best, keep playing your game for free until they convert, or at worst, uninstall your game after playing for a few minutes. This can cost over tens, hundreds of thousand dollars, even millions.

The original problem that indies met was that using traditional means for marketing (TV publicity, etc.) was unattainable because of the steep price of media publicity. At first, free-to-play seemed like a genuine answer to this, and it was for a while. As more players entered the free-to-play game and understood the market needs, the competition and cost to get noticed also went up. At this point, the current market is that you need money to get people to download your game (unless you get lucky with viral propagation). Even if you have the money to get some downloads, you’re then confronted with the problem of the previous section, which is get people to stay, play often and eventually pay. This means that you need to really understand what players do when they are in your game. How do you accomplish this?

Free-to-play is Big Data

So, you have a certain number of players that are coming into your game, but only 10% of them stay on the first and only 0.1% end up paying. What’s going on? Heck, how do you even get this information? When you have a free-to-play game, you need to understand how players are behaving. To do this, companies log player’s actions in a large databases, usually using third party tools, such as Flurry who are specialized in doing such things. Once you are effectively logging all these players actions, you can start analyzing the thousands of data entries that are obtained through the logs. This means that part of your job as a developer of a free-to-play game is to analyze data on a daily basis.

Unless you are really interested in statistics, you won’t be working on your game, you’ll be crunching numbers. And before you have statistics that are significant, you need to have enough players that have played over a certain period of time. The results are not necessarily instantaneous. So, what do you need to do in the mean time?

Free-to-play is continuous (and more complicated) development

I mentioned before that user retention is an important factor in the success of a free-to-play game. User retention means that players come back regularly to play you game, hopefully over a long period of time. In order to keep people interested (and acquire enough data), you need to continually add new features or content so that they can keep playing, so that players might pay (or pay more). This means that you can’t simply start working on another project easily; you need to keep developing for your other free-to-play project. This is not necessarily a bad thing, but as a developer, I know I like to move on to new projects sometimes.

On top of continuous development, you need to have a more diverse set of competencies in order to develop a good free-to-play game. It’s not just about UI, AI and rendering and other traditional stuff, it’s also dealing with servers and databases, which makes for more complex development. It also means that you need your game to be online at all times (in most cases) for people around the world. This can be hard to do for a small group of independent developers.

And on top of that, all the big players are continually making for more elaborate games, with more complex features. Again, it’s hard to stand out in such a market.

I’m still doing free-to-play

As an indie, doing all this is possible, but very difficult. Even if you forgo the money part, you’ll still have difficulty keeping up with all the other aspects.

Despite all these arguments, I’m still currently working on a game that is free.


Because free-to-play as a business paradigm has opened up opportunities for games that diverge from the original market. There are different ways to make money (such as ads). It’s also a good way to get some visibility. You don’t have emulate the big companies and make really complex games; you can aim for smaller projects.

It’s true, there are lots of games that already aim small and hope for some money. It works for some, but not for others. But, in the end, I still believe that if you do something that stands out, you may have a chance at fortune.

Or at least a free coffee everyday.


Bad teammates – How to identify them


Assembling a good team is a hard thing to accomplish in a professional setting. Finding good team members to work on an indie game project can be even harder. Indies will often turn to friends, co-workers and ex-co-workers to complement their teams. Others will look on the internet, in forums such as the collaboration subsection of the TIGSource to complete their team. Regardless of the method, however, you must be careful on who you bring in your team.

While I’ve mostly worked with lots of great people, there are a few notable bad exceptions that ended up being pretty crummy. In some cases, it can be hard to spot them at first. Some of these bad teammates may even be your friends. It’s important that you identify these bad apples as soon as possible and deal with them appropriately. I’ve made a list of things that I’ve observed that may be signs that you are dealing with a potentially bad teammate.


Bad teammates?

The Bad

Bad Work Ethics

I’m specifically talking about amount of work hours and amount/quality of work produced. When one of your teammates works a lot less than the others, or produces lesser quality work, it weighs down on the team. When working indie full time, make sure you identify core work hours or a clear time system and that you respect it. Some people will be tempted to come in late, leave early, take an extra day off, because they are leading the “indie life”. It can be frustrating for the whole group in these situation, creating tension and diminishing motivation.

This is especially difficult to deal with when working part time. In those cases, it’s important that everyone set their expectations on the amount of time that can be given for the project. If some people cannot follow up on their promises, it’s probably best they leave the project, or get less revenue or equivalent. On the other hand, you will often find one person that will want to work more than the others, because they are very motivated by the project. That’s OK, but it must be clear to them that the others can’t necessarily follow that pace.

It can be super annoying, but if you feel someone is not working enough (or hard enough), start writing down their hours or contributions. You can then use this information to see if your suspicions are correct. Another way to deal with this is ask everyone to log their hours in a tool.

People with Double Standards

I’ve seen people who want to apply rules to the group, but don’t follow the rules themselves. Maybe they’ve noticed that another colleague is often on Facebook, but they themselves are often on YouTube. They want to confront these people with the problem, when they are a part of the problem too. These people are problematic not only because they can potentially cause tension between teammates, but also because they think they are excluded from the rules somehow. And when someone thinks they are above the rules, bad things happen. I find this behavior is often associated with someone that has a superiority complex.

Bad Diva Behavior

Speaking of superiority complex, this one is a classic problem in the games industry. Divas think they are the center of the world and that they are better than everyone else (sometimes at everything). If one of your teammates is constantly boasting about their qualities and work, or worse, putting down other people’s work, you’re probably dealing with a diva.

This can also manifest itself in more subtle ways. Subtle divas will try to delegate boring tasks to others because they think they are above these tasks. Or they might say they are not motivated by certain decisions/tasks and will justify working less efficiently because of “motivation problems”. In some cases, I’ve seen people who said they were unmotivated because some people did not look at them during the morning stand-up meetings.

A good dose of confidence can be good for business types, presenters or lead positions, but taking it too far is problematic.

Titles Over Responsibilities

Many times I’ve seen people come talk to me about their team and have over-the-top titles for some of their team members. I’ve seen one guy say he had a producer and an executive producer in his team of 5 people. Although the previous situation is ridiculous, I’ve seen many people insist that they have “big” titles when their actual role on the team was not that important. In some cases, it might be OK to give yourself a relevant title if you actually have the responsibilities for it. Titles are meant to represent the fact that you are responsible of something (important). The problem is when someone says that they are CEO, but just draw or code in their corner all day. Usually these bad teammates are just interested in looking good and might be associated with any of the previous behaviors.

I also have a pet peeve with people who say they are CEO of their one man “studio”, but that’s another subject!

The Ugly

The ugly part is actually dealing with these bad teammates. This is never easy whether you’re in a professional setting or a more laid-back indie setting. It can actually be harder in the latter case.

I think the best thing to do (in both cases), is to actually sit down with the concerned individual and tell them how their behavior is problematic. This can be done one-on-one or with a small group, depending on the situation. Stay calm and try to explain how the behavior is causing trouble and how you’d like it to change.

If the person doesn’t listen or denies the problem, you may have to let go of them sooner or later. Getting stuck with the wrong people can be very problematic down the line, so it’s often better to get rid of them, rather then letting them weigh you down.

I know I’ve regretted not “firing” someone in the past, and it’s not likely to happen again.

In the end, you should listen to your instincts. If you feel something is wrong, then something probably is. It’s important to identify these things early on, so that you can deal with them quickly, before it’s too late. Oh and I know, I missed an opportunity by not naming a sub-header “The Good” to complete a perfect sub-header combo. But that’s OK, at least I got the bad and the ugly in there!


© 2017 Indie Dev Guy

Theme by Anders NorenUp ↑