作者：Ian Schreiber

如何衡量游戏乐趣？

假设你将在游戏中设置一些度量指标，以便你能够更好地进行数据分析并保持游戏的平衡。那么你真正需要衡量的内容到底是什么？通常人们会从两个角度出发。一些人会记录下任何能想到的内容，执行的是先记下再思考的方法。这些人认为比起仅收集一些重要信息，发现不足后再重做测试，他们宁愿先收集更多信息。（请点击此处阅读本系列第1、3篇）

还有一些人认为“记录下任何内容”从理论上讲并没有错，但是实际上，面对如此堆积着的外部信息，如果你真的要找到一些有用的信息，那还真的如大海捞针般困难了；并且更糟糕的是，所有的这些收集信息中可能根本就不存在与你所要找的内容相关的信息。基于这种思维，你将会先思考自己在下一次游戏测试时需要哪些内容，适度衡量，如此便不会在后来的执行过程中感到迷茫了。

所以你应该明确自己到底适合哪种方法。

我认为做出不同选择主要取决于你所拥有的资源。如果你是和几个朋友一起在Flash上制作一款小型的商业游戏，你可能没有太多时间进行广泛的数据挖掘，所以你最好能够尽快找到那些对自己有用的信息，而如果后来出现了一些问题要求你使用未收集到的信息进行解决，那么你便可以在游戏中添加更多参数度量指标。而如果你是在一家拥有许多精算统计学家的大公司，这些统计学家每天的工作便是寻找任何相关数据，那么你就可以省去数据收集这项繁琐的工作，并将更多精力和时间投入于其它任务中。

Acquisition(from playerize)

你需要衡量哪些特定内容？

不管是“只收集我们需要的”还是“尽可能收集所有信息”，这两种方法都不属于真正的游戏设计。有时候你需要真正明确自己需要衡量的到底是什么。

就像游戏设计本身，度量指标也是一个二阶问题。你想从游戏中挖掘出的大多数问题其实并不能直接通过测量而得，而应该尽可能地找出那些重要的内容，并对此进行衡量。

例子：乐趣难以衡量

让我们以单人Flash游戏为例。你总是想知道一款游戏是否有趣，但是我们却很难直接衡量游戏的乐趣。而与乐趣相关并且你能够测量的内容是什么？即玩家是否持续长时间游戏，是否坚持到游戏最后并获得了许多成就，是否多次回到游戏中继续游戏（特别是尽管他们“失败”了也仍然继续重新游戏）等等，这些都是你可以衡量的内容。但是你也需要记住，这些并不是绝对相关内容；因为玩家重新回到游戏中可能基于多种原因，如你设置了庄稼枯萎机制以惩罚未重返游戏的玩家等。但是至少我们可以肯定，玩家愿意继续游戏肯定是有原因的，而对于我们来说这些原因便是需要挖掘的重要信息。更重要的是，如果很多玩家同时在游戏的在某一时刻停止并未再次回到游戏中，那么你就要思考是否这部分游戏内容不够有趣或者为何玩家会在此终止游戏（游戏邦注：如果玩家“终止”游戏的位置是在游戏末尾，有可能是因为他们感受到了游戏的乐趣，并最终获胜，但是游戏却未有其它吸引力能够让他们重新挑战。所有的这些都需要视情形而定。）

玩家的使用模式使也很重要，因为不论他们是否选择游戏，玩游戏的频率怎以及游戏时间长度等都是与他们对游戏的满意程度有关。在那些要求玩家在固定时间后回返的游戏中，我们经常能够看到月活跃独立用户（Monthly Active Uniques，简称MAU）以及日活跃独立用户（Daily Active Uniques，简称DAU）这两个术语。“活跃”是个很重要的定义，因为如此你能够避免将那些已经不玩游戏的僵尸用户帐号也计算在内。“独立”这一词也很重要，因为我们并不能把每天登录10次《FarmVille》的独立用户算作10个用户。而这时候你可能会认为月和日的算法的同等的，只要将以日计算的数值乘以30就可以获得以月计算的数值，但是实际上从用户流失率角度来看，这两个数值是完全不同的概念。所以如果你能够明确区分MAU与DAU，你便能够清晰地看到游戏中有多少新玩家以及多少回头玩家。

举个例子来说，你拥有一款用户粘性较强的游戏，但是只有较低的用户基础，也就是只有100来名的玩家，但是所有的玩家每天至少都会登录游戏一次。这时候你的游戏MAU就是100，而平均的DAU也是100，所以游戏的MAU/DAU就是1。再假设如果你的游戏玩家玩了一次游戏后便不会再回到游戏中，但是你拥有强大的市场营销策略，所以每天都能够吸引100名新玩家，但是他们也是玩了一次游戏后不会再回头的那种类型。这时候你的平均DAU也仍然是100，但是MAU却变成了3000，所以MAU/DAU比值是30。所以MAU/DAU的变化幅度将在1至28，30或31之间浮动（这里的数值取决于每月天数的变化）。

注意：许多度量指标（如Facebook所提供的），便是使用不同方法去计算各种数据，所以一般情况看来，每一套数据的衡量标准其实是不同的。举个例子来说，我曾经看过一个网站罗列出了100款拥有“最糟糕”MAU/DAU比值的应用，但是说实话这些数据却不应该出现在一起，因为它们可能是来自不同媒体基于不同标准而得出的衡量结果。有些人以百分比，即平均数计算一天中玩家的登录数，而这个数值能够从最低点的3.33%（即每天有1/30的月活跃玩家登录游戏）延伸到100%（即所有的月活跃用户玩家每天都会登录游戏）。这是通过DAU/MAU（而不是MAU/DAU）比值乘以100而获得的百分比。所以当你在任何分析网站上看到这些数值，都要先明确他们的计算方法，以便你不会盲目地将不同层面的内容进行比较。

为什么我们需要了解这些数值？首先，如果一款游戏拥有较高的玩家回头率，那就说明它是一款好游戏。其次，这也意味着你能够从游戏中获得收益，因为你每天都能够让相同的人在游戏中驻足——就像是经营实体店时，如果顾客一次流连于橱窗外并未购买任何东西，那就算了，而如果同一位顾客每天都会来看同一样商品，那么最终他便有可能花钱买下这件商品。

游戏邦注：原文发表于2011年3月19日，所涉事件和数据均以当时为准。

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

Metrics (Part II)

Posted by Sande

In Part I, game designer Ian Schreiber outlines the debate between metrics-driven design and the more touchy-feely intuition-based design. In Part II, he explains the difficulties with trying to measure the “fun” in your game.

How much to measure?

Suppose you want to take some metrics in your game so you can go back and do statistical analysis to improve your game balance. What metrics do you actually take – that is, what exactly do you measure?There are two schools of thought that I’ve seen. One is to record anything and everything you can think of, log it all, mine it later. The idea is that you’d rather collect too much information and not use it, than to not collect a piece of critical info and then have to re-do all your tests.

Another school of thought is that “record everything” is fine in theory, but in practice you either have this overwhelming amount of extraneous information from which you’re supposed to find this needle in a haystack of something useful, or potentially worse, you mine the heck out of this data mountain to the point where you’re finding all kinds of correlations and relationships that don’t actually exist. By this way of thinking, instead you should figure out ahead of time what you’re going to need for your next playtest, measure that and only that, and that way you don’t get confused when you look at the wrong stuff in the wrong way later on.

Again, think about where you stand on the issue.

Personally, I think a lot depends on what resources you have. If it’s you and a few friends making a small commercial game in Flash, you probably don’t have time to do much in the way of intensive data mining, so you’re better off just figuring out the useful information you need ahead of time, and add more metrics later if a new question occurs to you that requires some

data you aren’t tracking yet. If you’re at a large company with an army of actuarial statisticians with nothing better to do than find data correlations all day, then sure, go nuts with data collection and you’ll probably find all kinds of interesting things you’d never have thought of otherwise.

What specific things do you measure?

That’s all fine and good, but whether you say “just get what we need” or “collect everything we can,” neither of those is an actual design. At some point you need to specify what, exactly, you need to measure.

Like game design itself, metrics is a second-order problem. Most of the things that you want to know about your game, you can’t actually measure directly, so instead you have to figure out some kind of thing that you can measure that correlates strongly with what you’re actually trying to learn.

Example: measuring fun

Let’s take an example. In a single-player Flash game, you might want to know if the game is fun or not, but there’s no way to measure fun. What correlates with fun, that you can measure?

One thing might be if players continue to play for a long time, or if they spend enough time playing to finish the game and unlock all the achievements, or if they come back to play multiple sessions (especially if they replay even after they’ve “won”), and these are all things you can measure. Now, keep in mind this isn’t a perfect correlation; players might be coming back to your game for some other reason, like if you’ve put in a crop-withering mechanic that punishes them if they don’t return, or something. But at least we can assume that if a player keeps playing, there’s probably at least some reason, and that is useful information. More to the point, if lots of players stop playing your game at a certain point and don’t come back, that tells us that point in the game is probably not enjoyable and may be driving players away. (Or if the point where they stopped playing was the end, maybe they found it incredibly enjoyable but they beat the game and now they’re done, and you didn’t give a reason to continue playing after that. So it all depends on when.)

Player usage patterns are a big deal, because whether people play, how often they play, and how long they play are (hopefully) correlated with how much they like the game. For games that require players to come back on a regular basis (like your typical Facebook game), the two buzzwords you hear a lot are Monthly Active Uniques and Daily Active Uniques (MAU and DAU). The “Active” part of that is important, because it makes sure you don’t overinflate your numbers by counting a bunch of old, dormant accounts belonging to people who stopped playing. The “Unique” part is also important, since one obsessive guy who checks FarmVille ten times a day doesn’t mean he counts as ten users. Now, normally you’d think Monthly and Daily should be equivalent, just multiply Daily by 30 or so to get Monthly, but in reality the two will be different based on how quickly your players burn out (that is, how much overlap there is between different sets of daily users). So if you divide MAU/DAU, that tells you something about how many of your players are new and how many are repeat customers.

For example, suppose you have a really sticky game with a small player base, so you only have 100 players, but those players all log in at least once per day. Here your MAU is going to be 100, and your average DAU is also going to be 100, so your MAU/DAU is 1. Now, suppose instead that you have a game that people play once and never again, but your marketing is good, so you get 100 new players every day but they never come back. Here your average DAU is still going to be 100, but your MAU is around 3000, so your MAU/DAU is about 30 in this case. So that’s the range, MAU/DAU goes between 1 (for a game where every player is extremely loyal) to 28, 30 or 31 depending on the month (representing a game where no one ever plays more than once).

A word of warning: a lot of metrics, like the ones Facebook provides, might use different ways of computing these numbers so that one set of numbers isn’t comparable to another. For example, I saw one website that listed the “worst” MAU/DAU ratio in the top 100 applications as 33-point-something, which should be flatly impossible, so clearly the numbers somewhere are being messed with (maybe they took the Dailies from a different range of dates than the Monthlies or something). And then some people compute this as a %, meaning on average, what percentage of your player pool logs in on a given day, which should range from a minimum of about 3.33% (1/30 of your monthly players logging in each day) to 100% (all of your monthly players log in every single day). This is computed by taking DAU/MAU (instead of MAU/DAU) and multiplying by 100 to get a percentage. So if you see any numbers like this from analytics websites, make sure you’re clear on how they’re computing the numbers so you’re not comparing apples to oranges.

Why is it important to know this number? For one thing, if a lot of your players keep coming back, it probably means you’ve got a good game. For another, it means you’re more likely to make money on the game, because you’ve got the same people stopping by every day… sort of like how if you operate a brick-and-mortar storefront, an individual who just drops in to window-shop may not buy anything, but if that same individual comes in and is “just looking” every single day, they’re probably going to buy something from you eventually.

[This article is an excerpt from Level 8: Metrics and Statistics, part of Ian Schreiber's course on game balance called Game Balance Concepts.]

Ian Schreiber has been making games professionally since 2000, first as a programmer and then as a game designer. He currently teaches game design classes for Savannah College of Art and

Design and Columbus State Community College. He has worked on five shipped games and hundreds of shipped students. You can learn more about Ian at his blog, Teaching Game Design. （source:gamedesignaspect）