Designing an Engine with Live Operations in Mind

This week I went to MIGS and went to a talk that touched on the subject of games as live operations. A live operation or live-ops, refers to games that have already been released and the game is now being treated as a service. The idea is that you release the most viable version of your product, or put another way your 'base' product first. Then whenever you want to add a feature, you do a quick and dirty implementation, test it with your customer base, take the feedback from the tests and either add support for it, improve it and test again, or chuck it out the window. The focus of the talk was actually about how to use metrics and player feedback to change your game design, and also focused on community management in regards to live-ops.

For this blog, I would like to focus on how I might go about actually designing an engine with live-ops in mind.

Flexibility

When it comes to live-ops the development team has to be flexible and open to change. This is no different when it comes to the game engine itself. As I mentioned before the initial product that is released is relatively lightweight. It usually only includes core game features. Once the game is released the team starts collecting data, analyzes it and then based on the analysis new feature requests or changes are added to current or near-future plans. Even without metrics being collected from players, the team itself may want to add or test new features,

This means that the engine has to be built in such a way that designers can implement and test features quickly. In other words, the engine has to be modular. This can be achieved through a scripting engine, and implementing all game features using script. This would effectively allow designers to implement new features, alleviates pressure from the programmers themselves to implement and test features, and this also means that for players, updating their games doesn't take excessive amounts of time since script files are extremely small.

If the test version of features prove to be successful, the team could write better more optimized script, or if the features is important enough to be a core of the game, they could add it to the engine itself.

Metrics Collection

Metrics collection is extremely important when it comes to live-ops. As a developer you want to know what your players are doing, when they are doing it, and how often they are doing it. All this information is then used to improve your product. But this isn't done automatically obviously, it has to be integrated into the engine itself.

I thought about how I would collect the data for a while. The main thing I made note of while brainstorming was that while we might want to collect all the data related to what players are doing, when and how often they are doing it, we don't necessarily need all of it. Nevertheless, I am assuming everyone is uncertain about everything and so we want to collect everything.

The second thing I made note of was that even if we limited our metrics collection to select features, we'd still have the problem of reading it, because in the end it's all just numbers. So organization of the data collected is also important.

Flexibility + Metrics Collection: How to Manage Both

A word that constantly comes up here is data. It's all about the data. This made me think about MMOs and how data is stored on servers and players use a client to access (pushing input, pulling output) the data on those servers.

Basically, the best thing to do if you want to maintain flexibility and perform effective metrics collection, is to have your game related data stored on a server.

Processes for collecting data at a high level using a server:

1. Player opens game client
2. Client checks for updates and pulls.
3. Player plays the game.
4. If the player is in an area flagged for metrics collection, the server should know and begin collecting data.
• For example, let's say we want to know if players are entering certain dungeons or levels, we'd simply log every time they actually enter the level. If we wanted to know how long they take to play through the level, we'd log the time they enter the level and log the time they' leave the level.
5. The collected data is stored on the server, at which point designers would have their own client that pulls the data. The client would be able to take all the data and present it in a readable form for designers to analyze and interpret.

In terms of the processes for pushing new features or updates for players:

1. Designer has feature they want to test.
• New level, new item, new mechanic
2. Designer has their own client which can simply push these small updates to a test server (an exact copy of the live server) where they will test their update to see if it breaks the game.
3. Designer's new feature has been tested and is now pushed to the live server.
4. Player plays the game and data is collected.

As far as I can tell most the of the game engine design principles we have already learned are applicable to designing an engine for live-ops. The major difference is that your game has to be online in some way or form to maintain the level of speed necessary when it comes to updating a game.