作者：Andy Savage

在本文中我们将着眼于使用分析学原理去衡量并完善我们所列举的《Ancient Blocks》的游戏玩法。就像之前所提到的，你可以在App Store上找到这款游戏。

本系列文章的报告是使用Calq，你也可以使用其它服务或自己创造这些参数。这系列文章是致力于分析“测量什么内容”而不是“如何进行测量”。

衡量你的游戏玩法

显然，游戏玩法是手机游戏成功的重要元素。如果游戏玩法一点都不有趣的话，不管图像或音效多么出色，你的游戏也是一无是处。

不同类型游戏的游戏玩法也不同。就像我们所列举的《Ancient Blocks》是一款基于关卡的益智游戏，所以我们在此所收集的参数也是基于此。如果你要遵循本文去调整自己的游戏，你可能需要相对应地调整一些参数。

游戏平衡

游戏平衡非常重要。如果游戏太过简单的话玩家便很容易感到无聊。而如果游戏太过复杂的话玩家便会受挫并彻底退出游戏。我们应该避开这两种情况。

对于《Ancient Blocks》，我们将记录的最初游戏参数是：

完成第一个关卡的玩家比例。

完成前五个关卡的玩家比例。

未完成任何关卡便退出游戏的玩家比例。

玩家在通过一个关卡前重新玩这个关卡的次数。

玩家玩每个关卡平均花费的时间。

玩家通过每个关卡所使用的道具数量。

玩家为了通过每个关卡所移动的砖块数量。

玩家为了通过每个关卡所触发的砖块爆炸次数。

执行

这款游戏非常简单，我们可以通过3个行动获得许多有用的数据：Gameplay.Start指玩家开始游戏的一个新关卡。Gameplay.Finish指玩家完成一个关卡（不管他们是成功还是失败），Gameplay.PowerUp指玩家在玩一个关卡时使用《Ancient Blocks》的一个特殊道具（游戏邦注：炸弹，颜色移动或放慢速度）。

Gameplay.Start

关卡—-玩家玩的关卡数（如第七个关卡）。

难度—-玩家当前玩的关卡的难度设定。

Gameplay.Finish

关卡—-玩家玩的关卡数（如第七个关卡）。

难度—-玩家当前玩的关卡的难度设定。

持续时间—-玩家完成这个关卡的时间（以秒为单位）。

成功—-玩家是否通过关卡，还是被打败了。

道具—-玩家使用一种特殊道具的次数。

砖块—-玩家在这个关卡中移动了多少砖块。

发射—-玩家在这个关卡中触发的发射（匹配一系列砖块）数。

Gameplay.PowerUp

Id—-玩家所使用的道具的数字Id。

关卡—-玩家玩的关卡数（如第七个关卡）。

难度—-玩家当前玩的关卡的难度设定。

之后—-当玩家使用了一种道具时他们在关卡中待了多长时间（以秒为单位）。

分析

基于上述的三个行动，我们能够更深入地分析玩家的行为和游戏平衡。

早前的玩家进程

玩家最初的体验不仅是关于教程，还可能延伸到前几个关卡中。进程率是关于前几个关卡是否平衡的重要指标，不管玩家是否真的理解那个告诉他们如何游戏的教程。

在《Ancient Blocks》中，玩家完成每个关卡所需要花费的时间较短，所以我们将透过前10个关卡分析玩家最初的进程。为了做到这点，我们可以创造一个对话漏斗去描述玩家在前10个关卡中的旅程。该漏斗需要10个步骤，即针对于这前10个关卡。我们将分析的行动是Gameplay.Finish，它代表完成一个关卡。

每个步骤都需要一个过滤器。第一个过滤器需要关卡Id去过滤步骤到正确的关卡上，而成功属性中的第二个过滤器只需要包含通过的关卡便可。我们并不需要在进程统计中包含失败的尝试。

所有的游戏都将随着关卡的增加而伴随着自然的下降速度，因为并非所有玩家都想要进入更深层的游戏中。有些人并不想玩你的游戏—-我们的追求都不同，这也不是什么坏事。然而如果某些关卡拥有高出我们期待的掉落速度，或者比起前面的关卡拥有突然掉落的设置，那么这些关卡便有可能导致游戏的失衡。如果关卡太难的话便会失去乐趣，或者玩家有可能不能理解自己为何要不断前进。

关卡完成率

玩家进程并不能呈现成体概况。玩家可能会在完成关卡前多次尝试这个关卡，而转换率并不会告诉你这一情况。我们需要着眼于玩家玩每个关卡的次数以及真正成功完成这项关卡的次数的比较。

举个例子来说吧，让我们着眼于《Ancient Block》的第三个关卡。我们可以着眼于玩家玩这一关卡的次数并将其分解为成功与失败两个部分。我们将再次使用Gameplay.Finish行动，并使用过滤器去呈现第三个关卡。这一次我们将通过成功属性去呈现成功率并划分结果。

基于《Ancient Blocks》的设计规格，第三个关卡拥有75%的成功率。就像你所看到的结果那样，这有点困难，虽然也不是太过困难。适当转变关卡参数能够帮助我们更轻松地实现目标。

中止回合

衡量早前游戏玩法的一个有帮助的参数是比较开始一个关卡的玩家数量，而不是完成这个关卡的玩家数量。这对于在教程关卡结束后进行衡量非常有帮助。如果玩家只是退出游戏，那么可能是因为他们不喜欢游戏，或者在哪个地方受挫了。

我们可以使用较短的对话漏斗对此进行衡量。即使用Gameplay .Start行动，之前文章提到的教程步骤行动（如此我们便可以只瞄准那些已经完成了教程的玩家）以及Gameplay.Finish行动。

上述所呈现的结果是64.9%（这是漏斗中第二和第三步之间的结果）真正完成了教程的玩家继续完成了关卡。这意味着有35.1%的玩家退出了游戏。这一数值高于我们的预期，即表示游戏失去了许多玩家。这也是帮助《Ancient Blocks》设计师做出进一步完善的重要参数。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转功，如需转载请联系：游戏邦）

Standard Gameplay and IAP Metrics for Mobile Games (Part 2)

By Andy Savage

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.

Attached Image: GameStrip.jpg

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

Level – The number of the level being played (e.g. level 7).

Difficulty – The current difficulty setting of the level being played.

Gameplay.Finish

Level – The number of the level being played (e.g. level 7).

Difficulty – The current difficulty setting of the level being played.

Duration – The duration (in seconds) the player took to finish this level.

Success – Whether or not the user passed the level (true) or if they were defeated (false).

PowerUps – The number of times a special power-up ability was used.

Blocks – The number of blocks the player moved during this level.

Launches – The number of times a player triggered a launch (matched a sequence of blocks) during this level.

Gameplay.PowerUp

Id – The numeric id of the power-up that was used.

Level – The number of the level being played (e.g. level 7).

Difficulty – The current difficulty setting of the level being played.

After – The amount of time (in seconds) into the level the user was when they used a power-up.

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).(source:gamedev）