游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

手机游戏的游戏玩法与IAP的标准参数(二)

发布时间:2015-01-27 17:07:47 Tags:,,,,

作者:Andy Savage

在本文中我们将通过分析去衡量并完善《Ancient Blocks》的游戏玩法。

衡量游戏玩法

显然游戏玩法是一款手机游戏成功的关键要素。如果你的游戏玩法很普通,那么图像或声音优不优秀都不重要了。

不同类型的游戏具有不同的游戏玩法细节。就像《Ancient Blocks》是一款基于关卡的益智游戏,所以我们在此所收集的参数也会反映出这点。如果你要遵循这系列内容去完善自己的游戏,你可能就需要做对参数做出相应的调整。

游戏平衡

游戏平衡非常重要。如果你的游戏太过简单,玩家便很容易感到无聊。而如果你的游戏太过复杂,玩家便会受挫并彻底离开游戏。我们想要同时避免这两种情况。

对于《Ancient Blocks》,我们将记录的最初游戏玩法参数是:

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

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

未完成一个关卡便离开的玩家比例。

一名玩家在通过关卡后重玩这个关卡的次数。

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

玩家使用多少道具去通过每个关卡。

玩家需要消除多少组块才能通过每个关卡。

玩家需要触发多少次组块爆炸才能通过每个关卡。

执行

我们所列举的游戏很简单,我们可以从3个行动中获得许多有用的数据:Gameplay.Start—-当玩家开始游戏的一个新关卡时,Gameplay.Finish—-当玩家完成一个关卡时(这也是玩家是否通过关卡的行动),以及Gameplay.PowerUp—-当玩家在挑战关卡的同时使用游戏中一个特殊道具(游戏邦注:炸弹,颜色移动或放慢速度等)时。

行动

属性

Gameplay.start

关卡—-玩家挑战的是第几个关卡(如关卡7)。

难度—-玩家当前所挑战的关卡的难度设置。

Gameplay.Finish

关卡—-玩家挑战的是第几个关卡(如关卡7)。

难度—-玩家当前所挑战的关卡的难度设置。

持续时间—-玩家完成这个关卡所需要的时间(按秒计算)。

成功—-玩家是否成功通过了这个关卡。

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

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

发射—-玩家在这个关卡中触动了多少次发射(即匹配一序列的组块)。

Gameplay .PowerUp

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

关卡—-玩家挑战的是第几个关卡(如关卡7)。

难度—-玩家当前所挑战的关卡的难度设置。

之后—-玩家在使用道具后花了多少时间完成这个关卡(按秒计算)。

分析

基于上述的三种行动,我们能够对玩家行为和游戏平衡进行一系列深入的分析。

早前的玩家进程

玩家最初的游戏体验将越过教程渗透到前几个关卡中。开发者必须重视这一点。进程率能够告诉我们前几个关卡是否平衡以及玩家是否真的理解教授他们如何游戏的教程。

在《Ancient Blocks》中,每个关卡所需要的时间都较短,所以我们可以通过前10个关卡去分析最初的游戏进程。为了做到这点,我们可以创造描述用户在前10个关卡(或者更多)的旅程的转换漏斗。漏斗需要10个步骤,每个步骤都是关于早前的每个关卡。我们需要分析的是Gameplay.Finish这一行动,因为它代表的是完成一个关卡。

每个步骤都需要一个过滤器。第一个过滤器需要安置在关卡标识中,以此将步骤过滤到正确的关卡中,而第二个过滤器需要安置在成功属性中,并只包含通过的关卡。我们并不想在进程属性中包含失败的尝试。

funnel(from gamedev)

funnel(from gamedev)

所有游戏都会随着关卡的提升而出现自然的掉落率,因为并非所有玩家都想要在游戏中不断前进。有些人并不喜欢玩你的游戏—-我们都具有不同的追求,这也不是什么坏事。然而如果特定的关卡经历了比我们所预料到的更高的掉落率,或比起之前的关卡出现了突然的掉落,那便意味着这些关卡失去了平衡。可能那个关卡太复杂了,缺少乐趣或者玩家不能理解他们需要做什么才能前进。

关卡完成率

玩家进程并不能呈现出整体画面。玩家可能在完成一个关卡前玩了多次这个关卡,而转换漏斗并不能呈现出这一点。我们需要着眼于玩家玩每个关卡几次以及真正成功完成关卡几次。

让我们着眼于《Ancient Blocks》的第三个关卡。我们可以查询玩家玩了这个关卡多少次并将其分解为成功与失败两种结果。我们可以再次使用Gameplay.Finish行动,并使用过滤器去呈现第三个关卡。这一次我们将使用成功属性去呈现成功率。

level3(from gamedev)

level3(from gamedev)

基于《Ancient Blocks》的设计规格,第三个关卡的成功率是75%。如果你看到上面的结果,就说明关卡有点复杂了,虽然不是太过复杂。这时候稍微调整关卡参数能够帮我们轻松实现目标。

中止的游戏

衡量早前游戏玩法的一个有用标准便是比较开始一个关卡但却未真正完成它的玩家数量—-也就是在中途关掉了应用。这是教程关卡后非常有用的衡量方式。如果玩家只是退出游戏,那有可能是他们不喜欢游戏或者在游戏中受挫了。

我们可以使用较短的转换漏斗进行进行判断。即使用Gameplay.Start行动,之前文章中提到的教程步骤行动以及Gameplay.Finish行动。

aborted sessions(from gamedev)

aborted sessions(from gamedev)

上述结果显示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.

Attached Image: EarlyGameplayFunnel.png

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.

Attached Image: GameExample-Gameplay-Level3-PieChart.png

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.

Attached Image: AbortedSessions.png

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

 


上一篇:

下一篇: