Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Trying to nail down the sometimes slippery concept of LiveOps and define what exactly it means and how it's done.
The concept of LiveOps has been around for about as long as games have been online. The lineage can be traced back at least to the first professionally organized MUDs (multi-user dungeons; text based multiplayer games) in the late 1980’s. Personally, I’ve spent the entirety of my 17 years in the industry working in LiveOps frameworks. I have seen the approach go from serving relatively small, niche communities in online virtual worlds, to being a driving force behind the free to play explosion, to influencing many of the most successful games being made today.
Despite its growing importance however, LiveOps remains a tricky term for developers to agree upon. Between the rapid expansion of internet connectivity and the explosive growth and change of game development we’ve struggled to define and distribute information about the techniques we use to make great live games. And for LiveOps specifically, the increasing prevalence of terms like Games as a Service and DevOps have made things even more challenging.
So, what follows is my attempt to provide a general definition of what LiveOps is and how it is done, drawing on my own personal experience as a developer. For context, that experience has been mostly in large scale MMOs, some casual, some AAA, some premium, some free to play. My point of view trends more toward design and I will approach many of the concepts of LiveOps from a design or player experience lens.
LiveOps is a portmanteau of Live Operations. The “Live” refers to any game that is not static and has some element of connectivity. This need not mean a multiplayer game or a competitive game, simply any game which is engineered and designed with the ability to change or have some form of persistence. “Operations” means to take care of something over time. In reference to games, this implies actively managing a game over time, and often iterating on the game experience.
But that’s just a definition. Functionally, LiveOps is a way of thinking about game design and development processes that is great at supporting games that are focused on long term engagement, because at its heart, LiveOps is about taking care of a game and the game’s players. This holistic understanding of LiveOps permeates all aspects of game development for teams that work in a LiveOps framework and means that ultimately, LiveOps is an all up approach to game development that differs in a few key way from static, or product style game development.
LiveOps calls on us to think of our players as a community. A complex group of people that come and go, have an evolving relationship with the game, and an evolving relationship with each other. Because LiveOps games seek a relationship with their players that extends over time, they must consider long tail motivations like the desire for new skills, new or deeper relationships, and desire for more autonomy as a driving force behind core game loops. Finally, since players may play a LiveOps game for many years, games must consider how they will fit into their players’ lives well beyond a singular entertainment experience.
LiveOps is a player-centric approach to game design. Product style games tend to be very developer-centric; they seek to deliver a developer’s story, a developer’s point of view, or a developer’s crafted experience (all wonderful things that make product style games uniquely great.) LiveOps games, by contrast, are primarily focused on what the player wants, how to deliver opportunities to the player, and satisfying player needs. That is not to say that LiveOps games lack design vision, in fact, they need it all the more as navigating the gap between what players say they want and what actually pleases them is an endless challenge. Still, priorities are shifted in a LiveOps approach toward satisfaction (how the player feels after playing) and away from attraction (how excited the player is before they play.)
LiveOps is an iterative approach to game development. Because we see our players as an ever-changing community, and our design is player centric, LiveOps games are never really done. We must keep trying things, testing things, and evolving the game to please our community. LiveOps achieves this through frequent game updates that seek to test out hypothesis about player behavior and then evaluate the results with data. This necessitates the ability to push content and other changes very frequently; LiveOps games are often architected as modular, independent features that can be iterated on without fear of dependencies. LiveOps games also usually store large amounts of content data on servers instead of in client apps so they can be changed without the need to distribute new client versions.
All of the above boils down to philosophy; a way of thinking about and approaching game development that is centered around the idea of a live and evolving game. But understanding the concepts behind LiveOps is only half the picture; we must also understand what it means to do LiveOps. What are the actions and practices that LiveOps development teams engage in and how can developers new to LiveOps adopt these practices?
LiveOps is not a set of interchangeable features or workflows that can be adopted all at once. Just as games are developed using a process by which they start primitive and become more fully formed with effort, so too are LiveOps practices adopted. And not all LiveOps practices are created equal. Just like pre-launch development, LiveOps is a journey. Unlike pre-launch development, LiveOps is additive instead of sequential. You never stop doing the basics, you just add optimization and then advanced techniques.
Of course, great LiveOps actually begins well before the game is launched. Designs that support iteration and long term engagement need to be a core part of your game if you plan to operate it in the long term. But for the purpose of this article I am going to focus more on what comes after launch.
Let’s examine each phase of the post launch LiveOps journey and the actions that a live team practices when operating at that step.
The first thing a newly live team must focus on is iterating on your game. The ability to make quick, iterative updates to your game is the most foundational LiveOps skill. When I say iterate, I do not mean releasing planned DLC content, I mean making small, frequent changes and additions to your game in response to player feedback and behavioral data to slowly improve the game over time. This seems like an obvious step, but many AAA games still spend millions of dollars attempting to avoid it; attempting to make the game as close to perfect as possible before shipping. This can lead to games with content architectures that make it hard to iterate once the game is live.
The forces that drive game teams to iterate on their games after launch are the same forces that drive game teams to adopt LiveOps in general; the need to improve a game’s performance, extend its life, and respond to player feedback. Essential parts of this phase include pushing new content into the game (temporary or permanent), making changes to existing systems, and addressing bugs. Success at this phase depends on how easy it is for the team to make iterations and the quality of feedback and basic data pipelines in getting the development team the information they need to make changes.
The game team’s efforts during this phase are mostly occupied with continuously improving and evolving the game to make it better. These iterations and changes are driven by the design team’s expertise and understanding of the game’s audience. After the launch of the game, the design team also uses data to gain insights into player behavior and test any changes against launch goals. As a team becomes more sophisticated at LiveOps basics, those insights will become more complex and focused. If a team has mastered the ability to iterate and has resources left over they will start making more focused and targeted changes, which means moving on to phase 2…
LiveOps optimizing is about creating and targeting experiences to specific players. Moving to this phase is often prompted by an understanding that different players react differently to the same iterations and the desire to make more purposeful and directed changes. This phase requires functional access to data and calls for adding data analysis to the design team’s decisions about what iterations to make to the game. While data is often collected and taken into consideration during phase 1, the need to personalize game content based on player behavior which characterizes phase 2 means that data must now be acted upon in real time. This necessitates a data pipeline that is more connected to the game itself. In fact, making the transition from basics to optimizing is often very challenging for game teams as the gap between data collection and actions based on data can be technologically challenging to bridge. Teams that make the jump find that data analyst and product managers take on larger roles and are better integrated into live content teams.
This phase is all about serving content and experiences to players based on who they are and how they behave. This is what most people are thinking of when they talk about gathering up tons of player behavior data, but that data is only valuable if you can do something with it. Teams can become mired in this phase by collecting more data than they know what to do with, which is why I suggest diving deeply into this phase only after a team has gotten good at making iterative changes to their game.
Game teams in this phase focus on segmenting players into meaningful groups, targeting content to specific segments, and changing 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 players’ relationship with your game changes over time and how to best serve players at different places on that player journey is a primary focus of this phase. Once you become great at offering individual players that right experiences 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 phase 3.
The practices at this step are all about growing, strengthening, and engaging your players as a community. At this phase, you should be thinking of your game as more than a collection of systems and content; discussing the game, making fan art, reading a tie-in comic book, meeting guildmates in real life, these are all a part of your game. This phase of LiveOps is all about brand loyalty and reaching organic growth and sustainment i.e. not paying for acquisition. While a lot of this work happens literally outside the game, support and integration with game systems are what separates the best from the rest. Features that support social engagement and seek to increase the fun players have when playing together are vitally important, as is data analysis and actions centered around group behavior and creating environments that help develop social connections.
When most game developers think of community they think about moderation and social media presence. But for communities to form and thrive, they need something to talk about and that usually comes from events inside the game. Sometimes that means creating content that won’t move the needle on core metrics like playtime but will create a strong community moment. Game teams at this phase focus heavily on social systems like guilds and friend networks, on shaping community through matchmaking for enhanced fun (as opposed to matchmaking for competitive balance), and moderation that encourages greater player to player interaction. To succeed at this level, games need to achieve harmony and deep integration of social features and core gameplay but also extend game interactions outside of the game itself creating culture around their game community.
While the phases of the LiveOps maturity journey are progressive many game teams do not reach LiveOps Mastery or even seek to do so. Many very successful games become very sophisticated at the basics and never progress to phase 2 or do only the minimum amount of optimizing. LiveOps success is not tied to progressing to phase 3, the model is simply meant to clarify how many LiveOps practices are reliant on others and provide some guidance for teams starting out in LiveOps 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 players’ 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.
LiveOps can feel daunting: there are acronyms, tools, workflows, philosophies, not to mention the messy business of actually developing a video game. I hope this article has provided some clarity or at least put a stake in the ground for what LiveOps is and how it gets done.
If you find LiveOps interesting, or if you just like listening to developers talk about game development, check out the podcast I co-host: The Art of LiveOps. We just wrapped up season one which consist of 19 interviews with game development veterans sharing their experiences making live games. New episodes should be flowing soon as we start up season 2.
Read more about:
Featured BlogsYou May Also Like
