Game Stack Blog

Twitter icon

Running LiveOps

World art with animated people at a train station with signs 

The Practice of LiveOps

In the last blog post, we talked about what LiveOps is and why it’s important as a game development strategy. Understanding the concepts behind LiveOps is only half of the picture; we must also understand what it means to practice LiveOps. What are the actions and habits that LiveOps development teams engage in, and how can developers new to LiveOps adopt them?

LiveOps is a Journey

LiveOps is not a set of interchangeable features or workflows that can be adopted all at once. Games start primitive and become more fully formed with effort during development, and the same applies with LiveOps. I have watched dozens of live games launch and either thrive or struggle; with this a distinctive progression has emerged that all games typically follow on their path to LiveOps Mastery.

The journey begins with a live game followed by an initial incorporation of basic LiveOps practices. Next comes a phase of optimizing these practices and finally the game and team progress to mastery. Every game I worked on has walked this path regardless of the team’s previous experience with LiveOps. Every game studio, even those that already have games operating at step three, must start at the beginning of the LiveOps maturity journey with each new game. They might progress faster, but no steps are skipped without significant consequences. Each step builds upon the last and represents a logical progression of a live team’s focus and effort.

Let’s examine each step and the actions a live team practices when operating at that step.

Step Zero: Live Game

First we need a live game. This is step zero as it’s less about a set of practices than it is a prerequisite. A game must have the capacity to be changed before it can be operated. From a technical standpoint a game would ideally include both a server component and network connectivity. It is possible but not practical to operate a game that is fully client bound. From a design standpoint, a game must be organized in such a way that allows for both the game and player experience to change. In modern game development, most games meet these requirements and are ready start the LiveOps maturity journey.

Step One: Iterate your Game

The first step of the LiveOps maturity journey is about iteration. The forces driving teams to iterate their games after launch are the same forces driving teams to adopt LiveOps; the need to improve a game’s performance, extend its life, and respond to player feedback. Since the beginning, game developers have struggled with the fact that games are not perfect at launch and will never start out ready to meet their full potential. Traditional games as a product spend an increasingly large amount of money and time trying to get games as close to perfect as possible at launch. Games that start out as LiveOps games tend to accept that work will be needed post-launch and plan accordingly. Teams utilizing both development approaches often find themselves starting the LiveOps maturity journey post-launch.

The need to iterate drives the use of basic LiveOps practices. Essential parts of this step include pushing new content into the game (temporary or permanent), making changes to existing systems, and addressing bugs. Success at this step depends on how easy it is for the team to make iterations. Build, test, deploy pipelines and content management are important at this stage and decisions about content architecture and client dependencies made pre-launch come into play.

The team’s efforts during step one are mostly occupied with continuously improving and evolving the game. These iterations and changes are driven by the design team’s expertise and understanding of the audience. After launch, the design team uses data to gain insights into player behavior and test any changes against launch goals. As a team becomes more sophisticated, those insights become more complex and focused. If a team has mastered the ability to iterate and has resources leftover they will start making more focused and targeted changes, which means moving on to step two…

Step Two: Personalize your Player Experience

Step two is about creating and targeting experiences to specific players. Moving to this step is often prompted by an understanding that players react differently to the same iterations and the desire to make more purposeful and directed changes. This step requires a functional access to data and calls for adding data analysis to the design team’s decisions about what iterations to make. While data is often collected and taken into consideration at step one, the need to personalize game content based on player behavior which characterizes step two means that data must now be acted upon in real time. This necessitates a data pipeline more connected to the game itself. In fact, making the transition from step one to step two is often challenging for teams as the gap between data collection and actions based on data can be technologically difficult. Teams that make the jump find that data analysts and product managers take on larger roles.

Teams at this step focus on segmenting players into meaningful groups, targeting content to specific segments, and changing the game experience based on player behavior. These practices can greatly increase engagement and much of the goals at this step are centered around optimizing and improving metrics related to player behavior through personalization. Having a deep understanding of how player relationships with your game change over time and how to best serve players at different stages of the player journey is a primary focus of this step. Once you become great at offering individual players the right experience at the right time, you can begin to consider your players more deeply outside the context of their behavior in your game and focus on how they engage as a social group, which constitutes the bulk of step three.

Step Three: Manage your Community

The practices at this step are all about growing, strengthening, and engaging your players as a community. Teams at this step focus on brand identity, loyalty, and organic growth by fostering and maintaining their game as a social activity. Teams often make the jump to this step when they can devote time and energy to supporting activities and behaviors that extend beyond in-game play and progression. Features that support social engagement and increase the fun players have together are vitally important to this stage. Environments that help develop social connections, actions centered on group behavior, and of course data analysis, are also needed. Teams operating at this stage usually see more integration of community, customer support, and marketing with game content teams. Games I have operated at this stage saw little distinction between community managers and designers from a functional standpoint, so closely was the work of the two aligned.

Teams at this stage focus heavily on social systems such as guilds and friend networks, on shaping community through matchmaking for fun (as opposed to matchmaking for competitive balance), and moderation that encourages greater player to player interaction. To succeed, these games need to achieve harmony and deep integration of social features and core gameplay and also extend interactions outside of the game creating culture around the community.

While the steps of the LiveOps maturity journey are progressive many game teams do not reach step three or even seek to do so. Many very successful games become sophisticated at step one and never progress to step two or beyond. LiveOps success is not tied to progressing to step three, the model is simply meant to clarify how many practices are reliant on others and provide some guidance on where to begin. It may be exciting to think of deeply personalizing your game for each player, but if you cannot easily iterate your game you may find it difficult to execute on that plan. Similarly, you may want to grow a large community but without deeply understanding individual player behavior you might find shaping your community feels like taking shots in the dark. Regardless of your LiveOps goals, having a map can help you better understand how to achieve them.

Understanding LiveOps; Running LiveOps

As live games become more prevalent, and we move into this new era of games as community, more developers will look to add LiveOps to their toolkit. LiveOps can feel daunting: there are acronyms, tools, workflows, philosophies, on top of the messy business of game development. This blog will primarily seek to share knowledge and experience about what it means to practice LiveOps in modern game development and, hopefully, how we can deliver great LiveOps experiences to our players.

I hope you found this two-part introduction useful! Come back in the next few weeks and we’ll dive into more LiveOps topics.

Thank you for reading!

Azure PlayFab is a complete backend platform of live games. VisitPlayFab.comto learn more about how to implement LiveOps into your game.

Looking for even more solutions? PlayFab is a part ofMicrosoft Game Stackwhich offers the tools and services indie game developers need to build, manage, and share their passion with their audience of gamers around the world.

From the Game Stack blog


Putting Your Game at the Center with Xbox Touch Controls

Article // Dec 2, 2021

Xbox touch controls unlock new ways for gamers to interact with their games, providing fans with even more choice.

Manage Events with Sampling on Azure PlayFab

Article // Nov 18, 2021

Sampling lets you to configure the percentage of events data that you want to receive in the title tenant database.

Announcing CloudScript using Azure Functions is now GA

Article // Nov 11, 2021

After over a year in public preview, CloudScript Functions is ready for primetime.