One of the biggest changes in the game industry has been the transition to service-based games¹, or games as a service (GaaS). The big enabler for this was digital delivery of games, or penetration of high-speed internet connections and “always online”².

This transition happened most visibly on mobile games, with F2P as a huge driver. Today, almost all of the revenue in mobile games comes from in-game purchases with possibly just Minecraft as an exception. The top grossing games have been pretty much the same games from year to year now.

A huge shift has also been seen on the PC games market, where most of the growth comes from “online” games like League of Legends (and other MOBAs) and Fortnite (and other Battle Royale games). The rise of esports is strongly linked with this. On consoles, the transition has been slower. Back in 2016, at the end of Destiny 1’s lifecycle, I used Destiny as an example of this.

I previously wrote on the difference of products, services and platforms. In this post, I will outline some challenges that come from when attempting to transition from products to services.

The transition from product-based game development to service-based games is hard

The transition takes a long time. What makes it difficult is that it’s not just a technical challenge, but very much an organizational one. However, as a technical field, too many people see it only as a technical problem.

Over this generation and especially now that we are nearing the end of it, we have seen many examples how hard the transition is: Destiny, Anthem, The Division, … These were from studios who know how to make massive AAA games but were still less prepared to run a service. Meanwhile, we have seen runaway success from much smaller teams that do not have this legacy on their shoulders. It took Bungie half a decade, a few games, and buying the IP back from a publisher that was more focused on annual franchises than service-based business model to be where they are now - a free-to-play title on pretty much all platforms with cross-play with no plans to release a sequel.

The game industry is notorious for is “crunch culture”, a lot of energy is used to get the game out of the door, and this is seen as the ultimate goal. For games as a service, this is however just the starting line. This in itself isn’t new, many product-based games have their post-launch content in form of expansions and DLCs or other title updates that fix bugs. Most games have “live operations” in the form of customer support and community management.

However, for service-based games the launch is neither end of a sprint or a marathon, it’s the starting point. It’s the first time the game is in the hands of real players³. The service-based game is like a startup: it’s a growth business and the launch is where the iteration starts. A normal product sees a huge spike of sales at lanch assisted with full court marketing campaigns, with seasonal spikes that ultimately turn into a long tail of “back catalog” sales. A service-based game on the other hand aims to grow year-on-year.

Some games are able to do both, Grand Theft Auto V was able to have the traditional AAA launch which was then followed with a growth that now rivals the launch through the GTA Online part of the game.

The key reason is the other side of the equation - cost. For a traditional title, the development costs go to zero so essentially all cashflows are positive after launch. A GaaS title on the other hand has significant operating costs and for this reason a downward trend of engagement is unsustainable.

The organizational challenge is that the resources needed, and the amount of operations required to run live ops often come as a surprise.

In the traditional model, the developer could act as a contractor who just made the game, got paid on delivery, and then threw it over the wall for the publisher and its marketing teams to extract as much money out of it as they could. For service-based games this is different and many of the functions that a publisher could do independent of the developer benefit from being integrated into the developer’s organization. Or, in the more and more common case of self-publishing, running live operations means a developer needs to take care of many new functions it has traditionally never even had to consider.

As an example, many service-based games have in-game events and run sales campaigns within the game - and these events happen often and regularly and outside of the platform’s own sales periods. The live ops team needs to be able to create marketing assets and work with the 1st party platforms and other media on an on-going basis instead of the publisher’s PR team pitching for visibility during the launch window of the game. In-game purchases mean that the developer needs to run customer support that can do refunds and such and cannot delegate these to the 1st party platform. Service-based games almost inevitably means servers and they need to be maintained and updated in a sustainable way. User research and player analytics has to run continuously to improve the game and cannot be just used to guide the development of the next game.

The studio developing a service-based game has to prepare for the remote, yet possible, scenario of success at a scale that means they can’t move on to a new, exciting project soon after launch. The opportunity cost of foregoing the investment in the current game and the likelihood of reaching similar success with a sequel means that the team has to - in addition to spending 3-4 years to make the game in the first place - to run the game at least as many years.

Not understanding this, it seems that a common mistake is to severely underinvest into the live operations services and tools needed to run the game. Anyone who has the battle scars from running live operations knows that there is no time to make those tools when your roadmap is filled with fixing things that are broken and making new features to grow the business. Before launch, the team only had to make new features, yet it’s likely that the live operations are run with a smaller team but are expected to deliver more. This is only possible if enough attention is given during development to make the live operation tools reliable⁴ and usable - and few join games industry to make back-end live operations tools.

One way to keep the development team honest is to ensure that there is no different development team and a live team, that the people making the features are the ones that have to support them. Otherwise, there is a strong moral hazard of throwing over the wall something that just barely works.

Business-model implications

The holy grail of service-based games is subscription-based revenue - the current in-game purchases are often called something like “recurring player revenue” in publisher’s annual reports but with the current paradigm⁵ the publishers are in an eternal fight to make the customer open their purse strings every month to keep that sweet, sweet ARPU up. Subscription-based MMOs “only” need to prove their worth so that a player doesn’t actively cancel, just like so many other services like Netflix and Spotify - the framing is the polar opposite, the player has to be active to stop spending, although often in a subscription-based offering the ARPU has a natural cap⁶.

Explicitly subscription-based games⁷ are still very rare and will probably continue to be so. However, the full transition to service-based model can in my opinion be seen achieved when we see sports franchise games ditching their annual releases. This would indicate that the model has a wide appeal even for the somewhat less engaged portion of the gaming market.

We have however seen publishers move to this direction with subscription-based offerings that give players access to the publisher’s portfolio. It’s however likely that these target the more engaged portion of the market and do not really affect the business model of individual games⁸.

Making games for the long-run

This all means that although the launch window is not as important from revenue point of view, the early post-launch is important to get the game on the correct trajectory. If things are not going to the right direction, you’re bleeding users and cannot wait months to get the features, bug fixes or campaigns done to remedy the situation. The more users you have, the more traction your operations will have.

The difference dynamics of service-based games, where most of your revenue is generated over time instead at the beginning, means that first months’ performance will be a disappointed to anyone expecting something on the same level of traditional product-focused titles. The full ARPU was generated on the instant the game was sold, and further engagement is not as important business-wide.

This is totally different especially for a F2P title, where your revenues are deferred over time and if you manage to churn less players than you acquire, you are on a growth trajectory. Even if the latter is not the case, but you still have a rock-sold retention curve, it will take a long time until your player base starts to melt.

To reap the benefits, you need to have a lean live operations machinery that cannot be burdened with the quality problems of production and at the same time make their own tools to run the game. It should be clear to anyone that the normal production processes used to make traditional titles are woefully inadequate to guarantee this.

Making a game with tail-light guarantee level of quality will be a massive self-inflicted wound in the long term, where the costs of fixing something in the post-launch will be multiple of that done during production. As long as it’s a miracle the game comes together in a shippable state at the last minute, it won’t be a miracle that players have reservations about games as a service in general.