Six common mistakes when moving to live-service games and free-to-play

I'm a consultant in the free-to-play and live-service games -- games-as-a-service -- business, using my 20 years experience to help teams either move into the space or optimise their existing operations. Over the years, I've seen clear patterns in the types of mistakes teams make when they start building game services rather than products. In this article I will share the six most common errors.

Identifying these areas is the first step. The hard work is in transforming the organisation, practices and culture to make sure they can be overcome, in what is becoming a very competitive and unforgiving market environment.

Mistake: A lack of customer focus and service thinking

Free-to-play and live-service games are fundamentally different from traditional games in that they operate as ongoing services rather than one-shot products. The differences between these types of businesses are very significant, and it can be hard for teams to adopt the new ways of working and the change in mindset needed when they make the transition.

One analogy I often use is that of a hotel. Most traditional game teams work in a way that is analogous to the team of expert architects and construction engineers that build hotels. They use years of expertise to design a structure for that specific purpose, construct it with care and attention while trying to hit a given opening date. They complete the project to a high level of polish and it is decorated with care and attention. On opening day they leave, and probably have some well earned rest before moving on to the next construction project.

"Customers stop being theoretical concepts, whose behaviour experts on the team must try to predict"

When a game team transitions from building products to running live game services, they must retain the skillset of the 'hotel building' type, but also incorporate all of the additional skills of operating that hotel as a service. Think of the difference between installing a hotel kitchen and the act of cooking and serving food, the difference between constructing a gym and being a personal trainer, between designing a hotel suite and cleaning it after a party.

Customers stop being theoretical concepts, whose behaviour experts on the team must try to predict. They instead become real people who are frank and open about their needs and problems. There is often a need to hire new staff who like to listen and adapt to consumer feedback, more than predict and prescribe what they think will or should happen.

A live game service also needs to include bottom-up maintenance and optimisation work once the top-down process of designing and building the launch version game is complete. Developers need to hire people and build operations that monitor the service and change it according to feedback and data. This is work that needs to happen on a tight schedule. If a tap is leaking in a hotel room a visitor will expect it to be fixed right away. If there's a bug in the XP allocation in a live RPG players obviously expect the same. Hotels also run events (conferences and weddings, etc.) and rotate menus in restaurants. Live games also need to change to keep players interested and to tempt them to return.

In short, game teams need to move from designing and building for a consumer that someone else will need to worry about, and start getting ready for a business that is completely customer focused. They need to stop thinking about a project with a definite end date and get ready for the idea that a successful game could be in operation for decades. They need to stay great at building a kitchen but also learn to serve great food.

Mistake: Incorrect budget allocation

In a meeting at the end of last year, someone asked: "What is the biggest change game teams must make when they move from products into services?" My answer: "They need to get used to the idea that half their budget will be spent on UI."

This is somewhat of an exaggeration, but it can be the case for specific types of mobile games -- half of the pre-launch budget actually has to be spent on the surrounding UI elements and menus rather than the core gameplay. What is more likely is that half of the budget is allocated to many areas that aren't core-gameplay focused. This includes UI, but it can also mean backend game servers, player account integration, and the building of pipelines and processes for live updates and other aspects of live operations. More on that later.

This can cause problems for teams that are transitioning. What do they do, double the size of the overall team or halve the size of the core gameplay team? Well, both work, but in general I would suggest something in-between. The issue is often that the extra work needed for live-service games is not considered high status enough for some traditional game developers. They want to work on great visuals, AI or gameplay, not analytics tools, UI frameworks or account integration. But if a completely new team is hired just for these elements, it can often foster a completely unworkable 'us vs them' culture in the company, whereby things are thrown over the wall to a separate team with little thought on how they might work when live, leaving that new team feeling subordinate or denigrated.

"Do not under any circumstances underestimate the need to spend outside of the core gameplay"

What I usually suggest is that some elements of what would be the old team -- core gameplay, etc. -- should transition into different roles for the live service, and be augmented by new hires with the specific experience or knowledge needed for this type of work. A gameplay server coder might become a backend engineer, a more technical game designer might move into data analysis, or a UI design lead might see their team grow and become more important in exciting ways. Often I find that there are people on the old core team who relish the opportunity to learn new skills and make this type of change. Often it guarantees career longevity.

What is vitally important is that the people working on overall budgets and staffing allocation do not under any circumstances underestimate the need to spend outside of the core gameplay. Live game services that do this fail. Despite what old-school developers might think, in my experience it is simply not possible to rely solely on good core gameplay to drive consumers to come back and play again and to spend. Meta-progression mechanics, monetisation integration and a general high quality-of-life outside of the core gameplay is essential.

Never, under any circumstances pull significant numbers of people out of the non-core gameplay work and into fixing issues with the core gameplay. It is much more advisable to cut features or drop production values (more on that next) in that circumstance.

Mistake: Production values are too high

Last summer I watched a candid interview with Gears of War's Rod Fergusson, where he revealed that he almost cancelled Fortnite while it was in development because it didn't hit his quality bar. He is one of the world's great experts in AAA game development and has contributed to some amazing projects, moving recently to lead Diablo at Bizzard.

This error -- of nearly cancelling one of the biggest games of all time because the quality bar wasn't high -- is indicative of a very common issue when AAA devs transition to live-service games or free-to-play. They fail to understand the need to drop some of the production values they are used to pushing as high as possible, in favour of increasing production values (or otherwise improving consumer experience) elsewhere.

In reading my two previous mistakes you might have asked where all this extra money will come from. Often the answer is in diminishing areas that would be considered critical in AAA development -- the 'production values' of the core gameplay. This can include graphical fidelity (including assets, shaders, particles and lighting) but can also include other things like the musical score and elements of movement (physics or animation). It's often ingrained in traditional developers that they must hit the highest possible quality bar in order to succeed, and this is certainly the case in premium AAA games, but things change a lot as developers move outside of that space. There's a lot of reasons to do this, but here are a few:

• As stated in the previous point, there's lots to do in a live-service games that isn't about core gameplay, but needs to be presented at a similar quality level to the core gameplay, which must therefore drop in quality to control budget and team size.

• Linked to the above, a player who is almost mindlessly grinding a mission for the fifth time to find that elusive epic weapon will care a lot less about the placement of visual environment details in that mission compared to someone who is experiencing it only once as part of an immersive cinematic experience.

• live-service games need to produce vast amounts of content, both pre and post launch. In order to move from producing a small amount of tailor made content to huge amounts of more repetitive or modular content, generally the production values of that content will need to drop.

• Free-to-play games in particular need to reach a wide audience. So they need to run on devices with lower systems specs - older consoles, weaker PCs and less expensive phones. This means a focus on making the lower-detail assets look good, often at the expense of higher detail work.

It's worth noting that when the low-fidelity Forntite looked like it was taking off, Epic cancelled the AAA-quality Paragon and allocated staff over from that project to Fortnite. Digital Extremes reportedly did the same when Warframe was taking off -- it moved staff from contracting work on AAA games in order to better serve the lower-fidelity but more profitable Warframe.

Mistake: Ignoring the importance of pipelines and practices for post-launch

When developers launch traditional product-based games, to a degree they are 'throwing something over the wall'. The game is complete, the tools may never be used again, and the codebase might never again be touched. If there is post-launch work on patches or a little DLC, it might be completed by a different team, and the vast majority of the actual work is already done pre-launch.

During the pre-launch period, the developer usually moves through long phases with gates in-between -- pre-production, production, finalling, etc. With many months or years to complete each phase, unoptimized tools can be used. The process of taking something from an idea to a finalised playable thing can take a long time as it can be tested by experts on the team who are trained in assessing unfinished work.

When moving over to live-service games, the process flips on its head. In successful game services the vast majority of the work happens after launch. When releasing live updates to a game service, the process of moving from idea to consumer-facing implementation is much shorter, being weeks or days rather than months or years. In order to work faster, toolchains need to be easier to use and more efficient, and version control and version management needs to transition from a mostly linear to a much more multi-threaded process.

"It's often ingrained in traditional developers that they must hit the highest possible quality bar in order to succeed"

Building and managing more complex and efficient systems like these takes much more manpower than the tools in a traditional game model, where mistakes are less time-critical. Game teams that don't recognise this might launch a game with promise, but struggle to make the early content drops that are needed to capitalise on this promise or rapidly respond to consumer feedback. This is even worse if the team has been crunching before launch and they don't have the energy left to do the real hard work of responding to that feedback. Avoiding crunch is very important in the phase running up to the launch of a live service for this reason -- momentum needs to be at least maintained, if not increased.

The gathering and analysis of feedback is another important element of live service operations, often ignored or critically de-prioritized by traditional game teams. Once live, it is no longer possible (or needed) for experts on the game team to act as 'consumer predictors' or 'consumer simulators' -- we often call these people creative directors. What is instead needed are people who are able to accurately gather real information from the real consumers that are now using the live service.

This data might be qualitative (scouring support tickets or Reddit threads) or quantitative (gathering player data directly from the game itself), but whatever form it takes it must be gathered and then analysed. The ability to coldly and carefully analyse data without prejudice is very rare from traditional game developers, so used to building a gut-feeling hypothesis and then finding a way to justify it. Because of this, I generally advise data analysts to be drawn either from the more analytical people on the team or hired from outside businesses like the web or financial services, and I suggest that they operate independently of the more creatively-driven traditional designers on the team.

Mistake: Cosmetic-only monetization in free-to-play games

With free-to-play clients, specifically those building PvP multiplayer games with core audiences, discussion on the design process often starts with a limitation on what we can and cannot design. The most common restriction they place on the design is that there should be no 'pay-to-win' mechanics, or that the game's monetization should be cosmetic only.

This restriction often comes from a reasonable position -- games that are perceived as 'pay-to-win' can suffer a serious audience backlash that can damage or kill the entire service. On the other hand, developers see that some of the most lucrative games-as-a-service have cosmetic-only economies.

But there's a problem with this assumption. The games that make billions from cosmetic-only economies typically only succeed because of the sheer numbers of players. On a per-user basis they actually have very poor monetization, relative to games that use more aggressive methods. This is because for a multiplayer game that is built from the ground-up to be about dominating other players, the proportion of the audience who are interested in self-expression via cosmetics is rather small.

The gigantic games that make billions from cosmetics are veritable unicorns -- one-in-a-million successes -- often built by teams with profiles, levels of consumer goodwill, or resources that are simply inaccessible to most developers. These are the Epics, the Valves, the Blizzards. Sometimes they might have hit the market so early and built an audience when it was much cheaper to do so than it is now. Riot and League of Legends would be the best example of a very smart team that capitalised effectively on this early mover advantage.

For untested or less experienced devs, the assumption that they will build an audience of this size is very risky, and in that situation I always warn my clients away from a cosmetic-only economy. They run the risk of sinking the project or even the entire company by leaning on an assumption that they will become (by user numbers) one of the most successful games in the world, or that somehow their game is special and will convert a much larger proportion of the audience to cosmetic self-expression than others.

"Free-to-play business plans and forecasts should be built around realistic, self-sustaining goals, not best-case scenarios"

You might have spotted a potential tautology here -- maybe these games became the biggest in the world because they only sell cosmetics, and are therefore able to appeal to a wider audience that wants a simpler or more 'fair' monetization model. While unlikely, this could be the case. But even so, given per-user monetization in these games is not good, the developers needed massive pockets to pay for the operation of the live service before the audience grew big enough to sustain itself. Very few teams have this amount of money to spare after spending all that money on getting the game to launch. More on that next.

Free-to-play business plans and forecasts should be built around realistic, self-sustaining goals, not best-case scenarios. That means cosmetic-only economies should never be considered. This is a harsh reality, often shared by consultants with inexperienced teams. Sometimes developers mitigate this issue by going premium-plus-microtransactions. Sometimes they will place more emphasis on player-versus-environment mechanics where 'pay to win' isn't such an issue. Sometimes I work with them on innovating between cosmetic-only and pay-to-win, drawing on the best elements of both.

Mistake: Post-launch panic!

When we compare traditional game products with live-service games and free-to-play we see huge differences, but there's one that usually causes the most hand-wringing and consternation among first-time developers, publishers and money people -- the immediate post-launch performance of a game.

Successful product-based games generally have a pattern of user behaviour (and indeed revenue) that looks something like the sketch below. The game launches, and day one or weekend one is the biggest peak of activity and money. This then tails off in a nice smooth curve until the activity and revenue is minimal, by which time hopefully you have another game (sequel or otherwise) ready to launch.

The key component that causes all the consternation is that the day one or weekend one performance is always the peak, and within a month something like half the lifetime activity and revenue has been accrued.

With successful live-service games and free-to-play games this graph looks very different. Firstly, the tail of the graph is much longer. Top performing GaaS can stay live and with a healthy audience for decades; Jagex launched Runescape back in 2001, but it had its biggest ever year for revenue in 2019. Clash of Clans was launched in 2012 and had its best month for revenue month since 2017 in June of last year.

Another key difference is that audience and revenue might decline seriously in the first few months after launch, looking in the short term like the game is about to fail. This is definitely the case in two very successful free-to-play PC games, Warframe and Path of Exile. My analysis based on public data shows that both services spent the first six months to a year of operation with audiences in decline, before turning them around to the knockout successes they are today. Let's then sketch out a graph of the typical user volume/revenue behaviour of a successful live-service games.

The launch month is good, with pent up demand and maybe some traditional marketing or a feature from a platform holder. The audience then declines as some of the large number of people who initially tried it during that phase decide it isn't for them, but with subsequent (and regular) updates -- the bumps on this graph -- the audience starts to increase.

This is driven by updates that expand the game so it is now better value for money than it was at launch, as well as quality-of-life improvements that make it more fun and easier to use. Perhaps the analytics team has worked with the developers to increase average player lifetime value by improving retention or optimising monetisation. This means the team can now afford to run ads to acquire users. Perhaps player sentiment is so high that they begin evangelising the product and the developer doesn't need to run marketing campaigns at all.

Whatever the case, it is very important not to panic on that initial decline. Yes, it could indicate that the launch was the peak of the game's performance and therefore a service with a short life. But it could also be the beginning of a Warframe or a Path of Exile -- a perennial success destined to be one of the greats.

The fact that this decline can happen means two things for the team. Firstly, they must not accept this initial drop-off as a guarantee of failure. It should be considered a normal feature of a service launch and not a reason to assume this will be the peak. Secondly, it shows the vital importance of allocating sufficient budget (or gathering more money after launch) to pay for service operations through that dip, where the game might even be making a loss in terms of cash-flow, never mind the whole project being in the red. It is entirely possible that over the years there have been many games that could have been billion dollar successes, but they were cancelled or ran out of money too early and never got a chance to get to the inflection point.

As you can hopefully see from this list of common mistakes, the transition from a product-based to a service-based approach should be taken very seriously. World-class performance in the former is no guarantee of success in the latter. In general, mistakes are made in budget and staff allocation, with insufficient funds allocated to UI, backend, tools pipelines, and the live phase of the project.

Much more difficult to overcome, though, are the cultural and mindset changes needed to move developers from a process that relies on singular creative vision, building to a definitive moment of glory at launch, to one that is open-minded, customer focused, and with an eye on longevity and flexibility.