If you are a game player of a certain generation, you tend to think of video games as products. Your purchasing experience used to be that you bought a copy of a physical game and took it home with you to play on your non-internet-connected console of choice.
Games these days are very different, behaving more like services than products. Not only has the method of delivery changed (from physical acquisition in a store to online download from a site or platform), but the actual design and composition of the title favors an always-connected methodology. Modern games require an internet connection simply to function, even if only to upload a save point to the cloud.
But the differences go deeper than that. The use of the internet as an intrinsic part of a video game’s design has given rise to the term “LiveOps,” a shortening of “Live Operations.” The LiveOps revolution has completely changed the video game industry, bringing with it a whole new ecosystem of opportunities and challenges for game developers around the world.
In simple terms, LiveOps is the process of managing a video game after it goes live; that is, once it’s been released to the public for download and users have begun playing it. This pertains specifically to games that have some kind of internet connectivity, which the majority of games these days do. LiveOps can involve one or more of the following components depending on the goal and vision of the developers of the game: bug fixes, new features, time-limited content, exclusive offers/features, content based on user feedback, tune-ups of existing features, and more—all of which require game development and quality assurance teams to roll out these updates.
In the past, the function of LiveOps was limited to just bug fixes after a game was released. Internet connectivity made delivery of patches a relatively simple matter, requiring nothing more than starting a game and waiting for the fix to download and install itself. On the surface, this is an obvious benefit, as players of PC games were once forced to find, download, and apply these patches manually.
However, developers have come under fire for releasing games containing known errors, understanding that a patch could and would be released shortly thereafter. This practice has received a lot of community criticism from players who would rather wait to receive a more fully functional game, rather than play a game with obvious problems from the outset.
Over time, LiveOps has become what it is today: developers tend to release the most basic version of a game first and then add more content and updates based on player reception. Such content can include elements like character skins for new appearances, items and weapons that affect actual gameplay, and even full game overhauls that significantly affect a game’s environment and play style. The first release is now considered the “stock” content, and subsequent releases are designed to keep people engaged with the game. In many cases, these updates are monetized to bring in extra revenue outside of any possible monthly subscriptions players might be paying.
An early example of LiveOps is for the mobile game Bingo Bash (currently owned by Scopely, originally released on Android and iOS in 2011). Bingo Bash is an online casino Bingo game. At the time of release, Bingo Bash had the barebones Bingo gameplay mechanics. Nowadays the game has a large catalog of existing added content and an aggressive LiveOps cadence (the frequency at which changes are released), with updates and new content released as often as every 2-3 weeks.
A more prominent example is Diablo 3, released by Blizzard Entertainment in 2012. The current iteration of the game has so much content and has undergone so many changes that it’s a true testament to the popularity of this IP and its devoted fanbase. Diablo 3 is also notable for having released with the “Auction House,” a major feature that was later removed from the game based on community feedback.
Today, the game itself is a fine-tuned RPG that's accessible to beginners, but also rewarding enough to bring long-term fans back to the game, again and again. Other extremely popular games like Fortnite, Apex Legends, and Clash of Clans are further examples of how LiveOps is utilized by publishers to update games with new content and bring longevity to a title. At the same time, these entities must be careful not to upset the balance of the core gameplay.
Clearly, the industry has moved away from the days when LiveOps was a purely developer-focused flow, separated from players, though both sides have always been intrinsically linked. In general, the health and success of a game depends on the active engagement of its players, but the true impact of community influence has only been emphasized in recent years. Now, some games live or die on the happiness of their communities, and the key to that is player input, especially for games that take the early release route.
Players want only the best for a game that they love, and contributing to its live iteration and improvement has, for them, become an important element of LiveOps. Players appreciate seeing developer communications on public channels, like when roadmaps are shared for games like Monster Hunter and Dauntless. They also feel heard when they can give suggestions and feedback that have a direct impact on a game, as in dev streams, play sessions, and AMAs (short for Ask Me Anything, a live question-and-answer format).
Over time, repeated trends of feedback allow a developer to know what their players really enjoy, like regular seasonal events (such as snow in GTA Online or Fortnite festive competitions), among others.
Getting players’ thoughts and ideas also helps with crucial bug reporting. This forms a key part of a healthy feedback loop that involves reciprocation between developers, their games, and their players.
Any game can include LiveOps in its lifecycle. However, some games are more suited for it than others. Games that are small, story-driven, or only have campaign modes tend to limit LiveOps to bug fixes, small balance patches, and occasional updates with new content. Games that are more open-ended and created with long-term player retention in mind tend to have robust LiveOps pipelines.
LiveOps is far more prevalent on mobile platforms where the competition is cutthroat. Most games and apps are released for free, so the only way for developers to make money is via ads, in-app purchases, and enticing users to repeatedly come back to the game to maximize revenue via subscriptions. Providing frequent updates with new content and addressing player concerns gives developers a better chance to retain and monetize users long-term. This monetization model has leaked out of mobile and onto other platforms.
From a community viewpoint, some games may benefit from a “public” LiveOps process more than others, like multiplayer titles and open-world games featuring regular content updates. A game with an extremely busy roadmap can really take advantage of open communications with a player community. Utilizing effective feedback loops to gather player insight and deliver transparent changes that promote player listening builds longer-term rewards and advocacy.
On the other hand, a game that has minimal updates (small fixes, tweaks, and changes that are not significant) stretched over a very long period of time can leave players waiting too long, leading to disinterest and disengagement. This can dishearten a community, especially if they’ve been over-promised features that are under-delivered, leading to a negative impact on a community’s health and retention.
If a game is a candidate for LiveOps integration, it’s important to put that consideration into the early planning process. The development roadmap needs to account for LiveOps’s specific requirements before the game is released, or it invites problems further down the line.
With community feedback being a more nascent component of LiveOps in the games industry, it’s important for developers to be aware of all the technical challenges that can be experienced in the LiveOps ecosystem. These include bug fixes, which need to be thoroughly tested before going live, since introducing an incomplete patch can not only cause further technical issues but can also anger the player base; new features, which are exciting and fun but have the potential to break existing features if poorly designed; platform requirements, which can change seemingly arbitrarily; and advertisement SDK integration, which is a major source of revenue for developers, so multiple ad SDKs or ad aggregators are often integrated, which can be a complex issue if not properly planned.
Other technical aspects also play roles in guiding product decisions and affecting roadmap updates:
Analytics: Only a small portion of the game community actively provides valuable feedback, so this method of insight is unreliable. When community feedback is given, it typically lacks enough detail to be actionable. For reliable assessment, developers integrate tools into games that track their every state and are stored on servers (passive feedback). By analyzing this data, developers can understand the pulse of the player base, which helps them make future decisions. This is probably the most commonly used tool in games that focus on LiveOps.
Crash analytics: No matter how well engineered a game is, game crashes cannot be avoided. To track crashes, developers integrate pieces of code into games that log the crashes onto remote servers so that they can be analyzed and fixed in later updates.
Player segmentation: This is an important tool used by developers to target a specific group of players. For example: if a certain game feature only needs to be shown to players from a specific region, this can be done by integrating a segmentation tool. In another example, if a proposed new feature is very experimental, then developers can release it only to a small group of people and qualify their reaction through analytics. Based on the result, they can either decide to go ahead with the full release or make changes as necessary.
A/B testing: This is an important tool in a developer’s arsenal when one option needs to be tested over another, or even for multiple options. This complements player segmentation. As an example: if developers have implemented two equally good themes for Christmas but are unsure which one is better for release, then each theme can go to either player base exclusively. Based on which one receives the most positive feedback (analyzed through analytics), developers can choose which theme to go with.
Server-side configurations: Ideally, developers want to release or test new features or changes as quickly as they can. But the process of platform submission (Apple’s iOS App Store, the Google Play Store, Steam, etc.) and getting a new game client approved takes an arbitrarily long time. To avoid this, developers include tools in games that modify the gameplay experience after downloading a small configuration file from the server. The same game client can behave differently based on the data in the configuration file. This helps developers make small, or even large changes to the gaming experience without having to do a platform re-submission. This configuration file can be downloaded in every launch of the game client or at a set interval.
It’s easy to see the value of LiveOps for stakeholders: keeping a game fresh with always-updated content both re-engages existing players and attracts new players. This gives developers the best chance to maximize ROI.
But with this also comes a responsibility for the developers and publishers not to abuse the system. It’s not enough simply to keep players on the hook with the promise of more content; that content should be exciting enough to make players want to keep coming back. From a community perspective, the playing space should also feel safe and welcoming. Developers can accomplish this by monitoring and remediating hackers, griefers who prey on their fellow players, and those who want to game the system in their own favor. It’s also considered good practice for developers to listen to players via social media and active forums to gauge sentiment, both good and bad. In this respect, a community’s expectations of smooth and meaningful LiveOps can be high if there are opportunities for direct contribution to a game’s features and iterations.
It's a feedback loop: An update gets released; community interaction lets the developers know how the update has been received; developers take community feedback into consideration in the next release; and the cycle continues. Ideally, if executed properly, this is a healthy symbiotic relationship that satisfies both parties and lengthens the life of a game.
Involving a community in the LiveOps process can mean organic, authentic communication between developers and an engaged, helpful, and smart player base that wants the best for its favorite game. It can lead to focused testing on features and items to ensure that what’s built works for the community. Overall, it can help ensure that the game will be there for the long-term, which is ultimately the goal for any publisher.
LiveOps is now an entrenched practice in the video game industry. It is a powerful tool for developers to support their live games and delight their player communities. If not handled properly, however, LiveOps can also alienate a player base, leading to negative feedback and users leaving for other games. Regardless of a game’s community, LiveOps needs to be planned carefully at the very beginning of the design process to avoid errors and roadblocks down the road. LiveOps has changed the way developers and publishers think about video games as products, giving titles a much longer lifespan, and therefore longer-lasting opportunities for returns on investment.