Live Operations, or LiveOps, in mobile games refer to delivering “games as a service”, including but not limited to new content, promotions, and events, often delivered without client releases. When developing new features, however, we often focus on the problem we are trying to solve right now. This article focuses on LiveOps in the early design phase instead.
Why should you care about LiveOps?
An average puzzle game player plays 3 games at a time. According to the same report, main reasons to stop playing puzzle games are slow progress and boredom. Now, fighting boredom is not easy — what’s boring for me isn’t necessarily boring for you — but one thing that helps in any case is a variety of content in the game, be that events, sales, limited time promotions or other features.
Public data about LiveOps effects is highly limited, but here is a screenshot from a free report by Liquid & Grit (source) highlighting the events vs revenue in Disney Magic Kingdoms. As you can see, the events — which sometimes have increased downloads — boost revenues consistently.
When is a good time to think about LiveOps?
Thinking about a feature’s effect on LiveOps is often postponed until the feature is already implemented and live; which leads to refactoring and other major changes to feature architecture (be that art structure, code, or configurations). If we must choose between those changes and something else more tangible for the player, which can affect the metrics and/or player experience, we are likely to prioritise the latter.
Instead, prevent this situation by thinking about the LiveOps opportunities before the design is finalised — this will allow coders and artists (+potential LiveOps team) to think about the implications of LiveOps on this particular feature implementation.
Here’s my shortlist of “what should every feature take into account in terms of LiveOps”:
- Can we make sure that the feature is updatable without a client release? This allows the game team to react to live data such as stability of the app, lower trending numbers, or potential bugs and misconfigurations.
- In my mind, the ideal scenario would be where artists could change the event theme without code support (and new themes could go live without client release). Therefore, before the feature is live, we should make sure that it easily supports reskins, multiple segment configurations, and easy changes & testing thereof.
- Can the feature be schedulable? This way, it’s added into the “tool box” of LiveOps and can be used to increase event/feature variety for players
- Can the feature be safely disabled? Just as a precaution :)
- How can we personalise the feature? Personalisation does not equal discrimination: I see it more as a thought on how could the feature’s configuration satisfy both most and least active users?
- What are we going to AB test? Launch a feature as an AB test whenever possible, with one group of users receiving the feature and another not. This will allow us to see the metric change and evaluate the performance of the feature. I am quite passionate about AB test roadmaps, so each feature could have one with planned tests & configuration changes.
- What events can we have around the feature? Something that would improve player experience with the feature, as well as increase engagement & monetization.
Let’s take a look at Lily’s Garden’s ROCKET RUCKUS event and the LiveOps opportunities around it. (That is not to say that at the moment these LiveOps elements already exist, it’s just an example to make it easier for myself).
The event has the following flow:
- Player starts the event
- Player plays a level
- Player wins a level => Player keeps the score => Score accumulates => Player can submit the score to leaderboard, or continue playing & accumulating score
- Player loses a level => ALL score accumulated to this point is lost
Calendar based refresh
The event runs every week or so, so users will inevitably get used to it. One easy remedy is to reskin the event, thus changing the theme & visuals. In order to achieve this, the implementation of the event should support easy reskin, including tools for artists, convenient structure and no need for code support during the reskin.
A few reskin ideas off the top of my head:
- 4th of July event around fireworks (can also be reused for other US specific days, e.g. Labour day)
- Mother’s day event with a more flowery- spring-y theme
- Lunar New Year with a moon and sky theme
Events around the feature
When designing the feature, I usually try to think about what kind of promotions could help player engage with the feature more. For example, multiplying score/offering higher score in return for higher effort is one of my favourites (e.g., harder levels give greater rewards).
For sake of measurement, “improved engagement” KPIs could mean anything from increase in levels played, to the player achieving a higher score in the competition compared to past attempts.
A few examples could include:
- Limited time double win — a temporary score multiplier for winning
- Alternatively, only apply double win on hard & super hard levels to increase pressure on the first time win
- Shorter, more attainable personal targets (e.g., if a player’s typical score is around 100 rockets at best, add a milestone reward at 80 & 110 rockets, and above)
- A relevant win streak at the same time (for example, in this case, the win streak would give pre-level power-ups which is quite typical for puzzle games with boosters)
Similarly to engagement promotions, purchase promotions revolve around the feature, helping the player progress faster through real money purchases. This isn’t to say that the event should only be winnable via purchase.
A few examples for the Ruckus tournament:
- Add limited time double win to purchasable bundles — a reward for real money purchase (this does improve life of a payer but does not make event unwinnable for non-payers). For example, one hour of double win active after a $5+ purchase.
- For non-payers, allow watching an ad to get a better win streak start OR even retain the score. This is a dangerous one as ads might easily cannibalise the main source of sink — extra moves in order to win a level.
Thinking about LiveOps isn’t easy but doing it earlier makes things more future-proof, and sets a good precedent for all upcoming features. I hope my checklist is at least somewhat useful to somebody else. It’s not comprehensive as many things will depend on the game you work on, but it provides a good start to build on.
If you would like to share your thoughts, feel free to join me in Clubhouse this Friday (27.05.2021) to discuss the article’s topic. https://www.clubhouse.com/event/xp4LRG8Y