As an industry, when we think about Games as a Service, the tendency is to obsess about user acquisition and monetisation.
This is understandable because they are the most obvious path to commercial success, however the reality is that focusing in this way leads us to forget about one of the biggest drivers to success in games – retention. Yet without this, user acquisition spend is less effective, and monetisation of the game is reduced.
As an industry, we’ve also recently been considerably influenced by the success of Hypercasual. These games have grabbed headlines with their incredible focus on fast iteration and testing, which has proven to be an amazing way to build a games business.
However, whilst we can learn many useful lessons from Hypercasual, we must be careful to be aware that these games are intended to not retain players and therefore we must not misunderstand the lessons that are relevant to other genres.
As a developer, there is a range of support available to help your game with user acquisition and monetisation – you can get to support to grow through Ads, App Store optimisation and publishing. However, there isn’t currently much support available to help you retain players – to help you design, launch and prepare games for the long haul.
However, for those developers who want to make games which players play for years, it’s a critical aspect of the game.
MMOs are probably the first kind of game which come to mind for many gamers when they think about games which players play for years; indeed the folks at Jagex even coined the term ‘Living Games’ around the Runescape phenomenon. However, these aren’t the only genre which has an ‘evergreen’ quality for players.
Look at how long games like Clash of Clans, Candy Crush and 8-Ball Pool have lasted at the very top of the mobile charts; but this isn’t about platforms so many PC titles including World of Tanks, League of Legends or even Minecraft have benefited from ongoing engagement with their very active communities.
Games will, perhaps inevitably, continue to move further towards services rather than products. Whilst there is nervousness on the part of some developers due to some headline grabbing poor implementations, game that want to create a truly authentic living experience led by players must focus on building a service that benefits players. Finding support to deliver this should be as much of a priority for developers as finding a publisher to help with marketing and user acquisition.
So what is LiveOps anyway?
When we talk about engaging players for years, we are essentially talking about LiveOps (or live operations).
At Fundamentally Games, we define LiveOps as:
Doing more things
And this only happens in a game when players (and player lifecycle) are placed at the heart of every decision and action made by the developer and their partners.
Understanding the player lifecycle
When a player first plays a game, that isn’t the end of the story for the developer. The player has a lifecycle they will follow, which varies depending on the type of game – in particular whether it’s a product or a service.
A Product (generally) focuses on getting as many players as possible over the barriers to install at launch and then managing the longtail of additional users over time.
A Service (generally) focuses instead on building up value for existing players and matching that to their changing needs over time. It’s about ongoing living value for players, rather than one moment in time.
With a service, when players discover a game they need a reason to act, which is delivered through activities in the game that create a sense of anticipation (and fear of missing out). However, getting a player to stay is as much about the player learning how that game fits into their daily routine as it is to help them learn the controls and the value of playing.
LiveOps requires that an understanding of what it takes to activate players who discover the game and move them to become engaged players. It means looking at the motivations for players to convert to spending money inside the game, specifically on things that they care about and value.
It also means understanding what ‘Super Engaging’ means for different cohorts of players and how that can become an aspiration for the community to continue to engage and spend; not only with other players but as part of social engagement with their friends and followers.
But what is LiveOps in practice?
LiveOps is about creating authentic predicable delight for players.
This requires a never-ending process of deciding what events, promotions, content and feature players most desire and delivering it consistently in ways which build trust and a sense of community. Done right this will then feeds into the growth of the game including user acquisition, and subsequently monetisation, leading to increased revenue.
LiveOps means rethinking how the game puts what players think, and what players do, at the heart of all decision making.
It’s a process that requires continuous improvement and review. Data (responsibly gathered) is critical and needs to be set-up to reflect the players journey through the gameplay and to allow an understanding of where the player is in their lifecycle.
However, it’s not just about looking at gameplay data. It’s critical to also understand how a game is performing in the market – tools like Game Refinery or Reflection.io can be instrumental for this, and also the impact the game is having on the market through social media and press activity – tool like Fancensus can help with this.
In the end it comes down to a community manager engaging with the community across all social media tools (including the game), activating the right configuration files to kick off the scheduled events for that day, week or month and then reporting back on what has worked and where improvements could be made.
When to start thinking about LiveOps?
It’s a cliché to say that you should think about LiveOps early. But its true. That does not mean you necessarily need to act beyond the design implications or that you need to have a community team ready to go before you start cutting code. What it does mean though is that you need to think about the tools and settings that you will later rely on, for the Live team to be able to operate the game.
At a minimum you should try to ensure that you cover at least these three key things when starting to think about LiveOps:
Who gets woken up at 3am when the game has problems?
How will the Live team configure daily/weekly/monthly events and promotions without needing developers?
How do you make sure only the Live Team can release tested content & features to players?
Don’t underestimate how simple it can be if you plan early; and how costly it could be if you fail to consider this early enough. To quote another cliché – “Failing to plan is planning to fail”.