GD-5 is reserved for LiveOps. Not all games enter this phase, but if your game functions with a ‘games as a service’ or ‘free-to-play’ model it most definitely will. Contrary to GD-4s which, although ongoing, do have an endpoint, GD-5s are open ended; there are games that last years and decades via live ops.

It is important to note, that this doesn’t apply to DLC, expansion packs or sequels; as these all end when shipped, all of these can be treated as a smaller project in their own right (with their own GD1-4). Instead, the GD-5 is tailored for games that have a continous stream of events, mechanics and content that is meant to never run out.

Feature briefs and detailed design documents

Various meetings and presentations 🙂

1. Define KPIs
2. Define target audience
3. Define assumptions
4. Come up with several potential game options
5. Feature Brief
6. Detailed Design
7. Playtests
8. Analyze results

Define KPI targets

To establish the success of a game during Live Ops, we first we need to make sure we decide how we will measure it. This is why the first step is to define what Key Performance Indicators (KPIs) we’ll be targeting. Some example KPIs are: downloads, retention on day 1, tutorial completion, interactions with a specific mechanic, etc.. Which one we’re targeting can depend on a lot of factors: from the age of the project, the genre of the game, the overall marketing strategy etc… The definition of the KPIs to target does not usually fall on designers, but the design solutions we apply vary wildly based on them, so it’s super important we know what they are and they whole team agrees on it.

Define target audience

It mind sound odd to define a target audience at this stage in development, but the target for Live Ops is subtly different that for the overall game. You see, as players play your game, they also change and go through their own journey [See the Player Journey tool for more info]. A player that is just starting the game, is not the same as a player who has finished all the content and these are different from a player who’ve been playing it for 5 years. When making a system for Live Ops, you’re not targeting your whole player base, but only a subset of them, it is important to define them.

Ideally you would have as much information as possible about the type of audience you’re targeting, including all their demographic and psychographic data, however in practice this might be hard to come by. At the end of the day, even a shallow definition of your target is better than none at all.

Define assumptions

Just like we do during GD-1 and at the top of feature briefs, once we’ve defined our goal and audience, we need to define our assumptions. However, instead of being assumptions about the project in general, these are mainly assumptions about player behaviour. Critically, once the game is live, we’re able to make polls and experiments to validate these assumptions. As you write down your assumptions, check if there’s an easy way to validate these before moving forward. It’s not always possible (many times the team doesn’t have the resources to do so), but if you can go for it.

Come up with several potential game options

Also taking a page from the GD-1s, there are always multiple ways to approach a KPI challenge. Make a series of concept slides. Share these with the team leads and make sure everyone buys in on the idea moving forward.

Feature Brief

Once everyone has agreed on a concept, move forward with a feature brief. As in the previous steps, we want to identify potential Risks in the design and take measures to de-risk them. The important part of a feature brief is to give every discipline enough information for them to get an understanding of the shape of the module and its Cone of Uncertainty.

Detailed Design

While the team is working on the implementation, designers use that time to dig deeper into the nitty-gritty. Balance Sheets, Character Specs become very common during this step. An important note is that, for live games, you want to create your documentation in such a way that it is easy to read, modify and add to; with the sheets modelling how any change will affect different parts of the game’s system. In all likelihood you will come back to these sheets in a few months, and having them organized and modifiable will save you days of headaches.

Playtest

Once the first versions of the new system are implemented, it is time to playtest them. Playtest can be tricky when working on Live Ops, as many times, these are designed for players that know the game well and have been playing for a few months. Fortunately, with a live game, we can get data from our testers directly. There are multiple strategies around this; for example geography constrained testing (where you only release the new mechanic to certain countries), rolling updates (where you roll out the changes slowly, for example to 5% of the game population), or using secondary marketplaces (releasing first in itch.io, before Steam).

Regardless of the method you use, however, there are a few things you need to take into account:

• Do technical tests to make sure you trust your data collection. Do small scale experiments in controlled environments (maybe just your team, friends and familly) to make sure that the data you collect is correct.
• Gather live data on your KPI well before you launch the new game mechanic. You want to make sure you have a very solid baseline; you want to smooth out seasonal peaks or other factors that can move what the baseline is.
• When launching your test, try to have an A/B test; this is where you keep a comparable portion of the population without the change. This will help you see what the true effect of the KPI change is, as both populations will be playing in the same timespan.

Analyze results

Once the change is live, Design will work with other disciplines (like Data Analysis and Engineering) to see if the KPI goal has been reached. Most of the time it will not, and we’ll have to re-assess our assumptions and iterate on the design. Frequently, this is a challenge of inches, slowly altering the KPIs until we’re happy with them. Be sure to communicate freqently with the other disciplines; don’t just tell them what needs to be measured, but the impetus behind it. This will help them understand how to analyze the data they have access to and give you the best answers

And that’s the final stage of the Deliberate Game Design Process. Not that complicated right? The biggest challenge is in learning which tool to use and when. DGD relies on different frameworks from all sorts of fields and they all have their pros and their cons. To learn more about the tools, explore our tool section: