This article continues on from my previous article (Part 1).
In this article we will be looking at using analytics to measure and improve gameplay for our example game "Ancient Blocks". As before, the example game featured in this article is available on the App Store if you want to see the game in full.
The reports shown in this series were produced using Calq, but you could use an alternative action based analytics service or even build these metrics in-house. This series is designed to cover "What to measure" rather than "How to measure it".
Gameplay is obviously a critical component in the success of a mobile game. It won't matter how great the artwork or soundtrack is if the gameplay isn't awesome too.
Drilling down into the gameplay specifics will vary between games of different genres. Our example game, Ancient Blocks, is a level-based puzzle game and the metrics that are collected here will reflect that. If you are following this series for your own games then you will need to adjust the metrics accordingly.
It's imperative that a game is well balanced. If it's too easy then players will get bored. If it's too hard then players will get frustrated and may quit playing entirely. We want to avoid both scenarios.
For Ancient Blocks the initial gameplay metrics we are going to record are:
The example game is reasonably simple and we can get a lot of useful data from just 3 actions: Gameplay.Start for when a player starts a new level of our game, Gameplay.Finish for when a user finishes playing a level (the same action for whether they passed or failed), and Gameplay.PowerUp for when a player uses one of Ancient Blocks' special power-ups (bomb, colour remove, or slow down) whilst playing a level.
With just the 3 actions defined above it is possible to do a range of in-depth analysis on player behaviour and game balance.
A player's initial experience of a game extends beyond the tutorial to the first few levels. It is critical to get this right. Progress rate is a great indicator of whether or not the first levels are balanced, and whether players really understood the tutorial that showed them how to play (tutorial metrics were covered in the previous article).
For Ancient Blocks the time taken on each level is reasonably short and so we are going to analyse initial progression through the first 10 levels. To do this we can create a conversion funnel that describes the user journey through these first 10 levels (or more if we wanted). The funnel will need 10 steps, one for each of the early levels. The action to be analysed is Gameplay.Finish as this represents finishing a level.
Each step will need a filter. The first filter needs to be on the level Id to filter the step to the correct level, and a second filter on the Success property to only include level play that passed. We don't want to include failed attempts at a level in our progression stats.
All games will have a natural rate of drop off as levels increase since not all players will want to progress further into the game. Some people just won't enjoy playing your game - we are all different in what we look for and that's no bad thing. However, if certain levels are experiencing a significantly larger drop off than we expect, or a sudden drop compared to the level before, then those levels are good candidates to be rebalanced. It could be that the level is too hard, it could be less enjoyable, or it could be that the player doesn't understand what they need to do to progress.
Player progression doesn't provide the entire picture. A level might be played many times before it is actually completed and a conversion funnel doesn't show this. We need to look at how many times each level is being played compared to how many times it is actually completed successfully.
As an example, let's look at Ancient Block's 3rd level. We can query the number of times the level has been played and break it down into successes and failures. We do this using the Gameplay.Finish action again, and apply a filter to only show the 3rd level. This time we group the results by the Success property to display the success rate.
The design spec for Ancient Blocks has a 75% success rate target for the 3rd level. As you can see from the results above it's slightly too hard, though not by much. A little tweaking of level parameters could get us on target reasonably easily.
An incredibly useful metric for measuring early gameplay is comparing the number of people that start a level but don't actually finish it - i.e. closed the application (pressed the home button etc). This is especially useful to measure straight after the tutorial level. If players are just quitting then they either don't like the game, or they are getting frustrated.
We can use a short conversion funnel to measure this. By using the Gameplay.Start action, the Tutorial Step action from the previous article (so we can include only people who finished the tutorial already), and the Gameplay.Finish action.
The results above show that 64.9% of players (which is the result between the 2nd and 3rd step in the funnel) that actually finished the tutorial went on to also finish the level. This means 35.1% of players quit the game in that gap. This number is much higher than we would expect, and represents a lot of lost players. This is a critical metric for the Ancient Blocks designers to iterate on and improve.
Part 3 of the series will continue by looking at increasing revenue by optimising the user journey for in-app purchases (IAPs).
In this article we will be looking at using analytics to measure and improve gameplay for our example game "Ancient Blocks". As before, the example game featured in this article is available on the App Store if you want to see the game in full.
The reports shown in this series were produced using Calq, but you could use an alternative action based analytics service or even build these metrics in-house. This series is designed to cover "What to measure" rather than "How to measure it".
Measuring gameplay
Gameplay is obviously a critical component in the success of a mobile game. It won't matter how great the artwork or soundtrack is if the gameplay isn't awesome too.
Drilling down into the gameplay specifics will vary between games of different genres. Our example game, Ancient Blocks, is a level-based puzzle game and the metrics that are collected here will reflect that. If you are following this series for your own games then you will need to adjust the metrics accordingly.
Game balance
It's imperative that a game is well balanced. If it's too easy then players will get bored. If it's too hard then players will get frustrated and may quit playing entirely. We want to avoid both scenarios.
For Ancient Blocks the initial gameplay metrics we are going to record are:
- The percentage of players who finish the first level.
- The percentage of players who finish the first 5 levels.
- The percentage of players that quit without finishing a level.
- The number of times a player replays a level before passing the level.
- The average time spent playing each level.
- The number of "power ups" that a player uses to pass each level.
- The number of blocks a player swipes to pass each level.
- The number of launches (block explosions) that a player triggers to pass each level.
Implementation
The example game is reasonably simple and we can get a lot of useful data from just 3 actions: Gameplay.Start for when a player starts a new level of our game, Gameplay.Finish for when a user finishes playing a level (the same action for whether they passed or failed), and Gameplay.PowerUp for when a player uses one of Ancient Blocks' special power-ups (bomb, colour remove, or slow down) whilst playing a level.
| Action | Properties |
|---|---|
| Gameplay.Start |
|
| Gameplay.Finish |
|
| Gameplay.PowerUp |
|
Analysis
With just the 3 actions defined above it is possible to do a range of in-depth analysis on player behaviour and game balance.
Early player progression
A player's initial experience of a game extends beyond the tutorial to the first few levels. It is critical to get this right. Progress rate is a great indicator of whether or not the first levels are balanced, and whether players really understood the tutorial that showed them how to play (tutorial metrics were covered in the previous article).
For Ancient Blocks the time taken on each level is reasonably short and so we are going to analyse initial progression through the first 10 levels. To do this we can create a conversion funnel that describes the user journey through these first 10 levels (or more if we wanted). The funnel will need 10 steps, one for each of the early levels. The action to be analysed is Gameplay.Finish as this represents finishing a level.
Each step will need a filter. The first filter needs to be on the level Id to filter the step to the correct level, and a second filter on the Success property to only include level play that passed. We don't want to include failed attempts at a level in our progression stats.
All games will have a natural rate of drop off as levels increase since not all players will want to progress further into the game. Some people just won't enjoy playing your game - we are all different in what we look for and that's no bad thing. However, if certain levels are experiencing a significantly larger drop off than we expect, or a sudden drop compared to the level before, then those levels are good candidates to be rebalanced. It could be that the level is too hard, it could be less enjoyable, or it could be that the player doesn't understand what they need to do to progress.
Level completion rates
Player progression doesn't provide the entire picture. A level might be played many times before it is actually completed and a conversion funnel doesn't show this. We need to look at how many times each level is being played compared to how many times it is actually completed successfully.
As an example, let's look at Ancient Block's 3rd level. We can query the number of times the level has been played and break it down into successes and failures. We do this using the Gameplay.Finish action again, and apply a filter to only show the 3rd level. This time we group the results by the Success property to display the success rate.
The design spec for Ancient Blocks has a 75% success rate target for the 3rd level. As you can see from the results above it's slightly too hard, though not by much. A little tweaking of level parameters could get us on target reasonably easily.
Aborted sessions
An incredibly useful metric for measuring early gameplay is comparing the number of people that start a level but don't actually finish it - i.e. closed the application (pressed the home button etc). This is especially useful to measure straight after the tutorial level. If players are just quitting then they either don't like the game, or they are getting frustrated.
We can use a short conversion funnel to measure this. By using the Gameplay.Start action, the Tutorial Step action from the previous article (so we can include only people who finished the tutorial already), and the Gameplay.Finish action.
The results above show that 64.9% of players (which is the result between the 2nd and 3rd step in the funnel) that actually finished the tutorial went on to also finish the level. This means 35.1% of players quit the game in that gap. This number is much higher than we would expect, and represents a lot of lost players. This is a critical metric for the Ancient Blocks designers to iterate on and improve.
Part 3 of the series will continue by looking at increasing revenue by optimising the user journey for in-app purchases (IAPs).