开发者谈《Replica Island》游戏测试系统设置

　　本文摘自《游戏开发者杂志》（Game Developer magazine）2010年9月期刊，作者是Android游戏开发者Chris Pruett，他在文中详细地描述了自己如何以低成本手段，快速创建针对手机游戏《小绿人历险记》（Replica Island）的有效测试记录系统的方法。

　　游戏开发者看别人玩自己创造的作品，这种体验和自个儿每天接触这款游戏的感觉明显不同。因为你每天都在玩同一款游戏，就会在无意识中形成一套驾轻就熟的特定玩法，只有把游戏交给新手，你才有可能发现它的动画设置、操作提示、间歇性漏洞等问题都在此时被放大了，自己和他人的游戏体验根本就是两码事。

　　无论你自己优化了多少回，修补了多少个漏洞，但由于你已经形成了特定的玩法，而且对这款游戏内容了如指掌，所以很容易忽视其他玩家可能遇到的问题。这也正是玩法测试对打造一款优秀游戏极其关键的原因所在。如果想获得更多玩法测试信息，你就得善于从中收集相关数据，并进行有效分析。下文是我在这种操作上的一些心得。

　　简单的玩法测试

　　我初涉这一行时主要编写Game Boy Advance游戏，当时我们的测试很简单，就是把附近的一些孩子叫进来，人手发放一个特制的GBA，这个掌上游戏机系统与VCR相连接，这样孩子们玩一会儿游戏后，我们就能倒带查看他们的游戏过程，可以马上找出那些具有直接影响作用的漏洞。

　　但我们并没有留意到，这种方法并不能反映这玩家在游戏中受困的原因。只有当一定数量的目标用户都栽倒在特定环节时，大家才会意识到这款游戏有些地方需要修改。就这样，我们靠一帮小孩的多次配合，以及通过VCR的反复观察，极大地完善了游戏设计。

　　现在我是一名Android手机游戏开发者及支持者，第一款Android作品就是《小绿人历险记》，它也是一款side-scroller风格的游戏，和我十年前制作的GBA游戏并没太大区别。不同的是，我已经不再给游戏工作室打工了，仅靠一个美工的协助，在闲暇时间一个人开发了《小绿人历险记》。

　　而且我也已经不再找那些孩子测试游戏了，如果非如此不可的话，我也会找一些更年长的目标用户来执行测试。但是问题又来了，要输出玩家在手机上试玩游戏的测试信息，可真不是一桩易事。唯一的办法就是站在他们背后看，但这种举动多少有点唐突，而且也会影响玩家的游戏体验。

　　面对这种情况，我一个独立手机游戏开发者究竟能怎么办？在快完成《小绿人历险记》的时候，我才意识到自己对它到底好不好玩实在没有把握。这款游戏是在闭门造车的情况下完成的，只有让更多人试试效果，我才有信心向世人推广它。

　　我尝试的第一套方案就是用户2048/">问卷调查。我将游戏投放到了一个内部网站，并向用户发送了一封电子邮件，邀请他们试玩游戏并提供反馈意见。我甚至专门创建了一个反馈论坛，上面有针对这款游戏的一些提问。

　　但这种方法真是彻头彻尾的失败，虽然有许多人下载了游戏，可是只有极少数（不到1%）人愿意搭理仅有五道题的调查问卷；而这些提交了调查问卷的用户，也并没有提供什么具有参考价值的信息，我无从判断这款游戏是否难度太大，究竟是玩家控制系统、关卡设计、益智设计，还是入门引导中的哪一个环节出现了问题。

　　向他人取经

　　遭遇这次挫折之后，我想起了Naughty Dog工作室针对《Crash Bandicoot》原版本开发的玩家反馈系统。这个系统可以将玩家在游戏过程中的相关统计资料保存在记忆卡里，开发者可以在离线状态下对数据进行整理，查看玩家在哪个游戏环节耗时最长，哪个区域的玩家死亡率最高。

　　依靠这个系统提供的数据，Naughty Dog重新修改了游戏“事故频发”区域的设置，也调整了游戏的动态难度调节系统。Naughty Dog设计这个系统的有趣理念之一就是，无论如何都要防止游戏玩家过早败下阵来。他们的终极目标是清除导致玩家无故被卡，不能动弹的漏洞。

　　我觉得这是一个很酷的主意，但不确定它在手机平台上是不是同样可行。我问了周围一些人，打听目前的大型游戏是怎么执行测试操作的，发现有许多公司都已经有一些不同的测试方法。但有些人告诉我，虽然他们可以搜集到很多信息，但要从中分析出有助于改进游戏设计的数据却非常困难。

　　还有一些工作室使用的是可以再现玩家闯关过程的分析工具，甚至可以统计出玩家最喜欢的武器、最难战胜的敌人、可视性最强的地图区位等资料。这种搜集用户试玩信息的系统，适用于多种类型的游戏，但如果要从中获取有价值的信息，这些游戏工作室还得花费大量时间创建可以分析数据的工具。

　　由此可见，搜集数据并不难，难的是获取有价值的信息。

　　这种情况听起来很让人沮丧，因为我的目标就是让游戏测试工具越简单越好。但我还是决定先用一些关键的参数，试试这种记录系统究竟是否可行。当时我的Android手机没有记忆卡，但可以稳定连接互联网。所以我想，也许可以先让系统将玩家的重要活动记录下来，发送到一个服务器，然后再由服务器输出玩家的测试信息。我希望能用最简单的系统，获得最多的玩家信息。

　　推出初级版测试系统

　　我编写的这个活动记录系统很简单，只有三个内容：一、在游戏运行过程中搜索玩家活动情况，并将其发送到服务器的控制流；二、服务器本身；三、负责分析服务器所记录数据的工具。

　　在这三者中，“服务器”最为关键。我用php脚本编写了一个服务器，大约30行的代码，可以搜集针对HTTP发送的调查内容，将结果编写到mysql数据库中。调查内容十分简单，仅包括：活动名称、关卡名称、XY坐标定位、版本代码、用户访问名、时间标识。这些数据都会根据字段，逐条记录到数据库；这些数据处理也是通过PHP来完成（但从长远来看，这是个失误的决策），只有在必要的时候，才会加载一个特殊的仪表板页面。

　　我最先开始测试的是玩家死亡率和闯关级别。每当一名玩家死亡或者闯过一关时，系统都会把这些活动记录到服务器。通过这些数据，我就可以观察出玩家闯哪一关时耗时最长，哪一个环节阵亡的人员最多，哪一个难关居然轻易被攻破。

　　通过这些数据，我还可以统计出某一关卡上的死亡率，每名玩家的平均死亡次数。

　　这个系统的空间定位功能，还能帮助我判断玩家的死因，知道他们哪一次是死于敌人之手，哪一回是因陷阱而丧命。事实证明，游戏首次植入这个活动记录系统后的效果出奇理想。

　　在这个初级版记录系统的帮助下，我又推出了一个游戏升级版本，继续观察相关数据，很快又发现了新问题：有一些关卡无人过关，玩家几乎立即毙命；玩家在另外一些环节中经常被卡长达数小时（表明这个关卡设计很失败，因为按原来的设计，玩家只需要5分钟就能过关）。有了这些数据资料，我就很清楚哪些关卡的修改工作量最大。

　　但仅仅找出问题关卡是远远不够的，有时候我还是不知道它们的问题出在哪里。

　　所以我又使用同样的数据，编写了可以监测玩家死亡位置的工具，这样我就可以通过关卡设计层看到玩家死亡率或存活率最高的区域，这个工具的初级版本是以点状分布图来显示死亡人数，后来玩家死亡率大幅上升时，我就改用热地图来显示玩家死亡分布（见下图）。

　　游戏设计失误

　　我推出的提高玩家闯关级别、死亡监测热地图的工具，很快就取得了立杆见影的效果。比如说，我可以从中发现大量玩家在某个关卡都死于第一个敌人之手，但并不是因为这个敌人太难对付，而是因为敌人的临空而降实在让他们措手不及，无法防范——玩家所在区位的天花板太低了，他们看不到敌人出现的方向。

　　另外我还发现，原先那个简单的动态难度调整系统本身就需要改进和调整。经过又一轮死亡潮后，我让这个系统悄悄地提高了玩家的存活率和飞行能力，然后再观察数据发现，我其实早该这么做了。

　　我还对游戏关卡的几何设计进行了大幅度的改动。我看到有不少关卡死亡率极低，仅仅是因为玩家在地图中迷路了。于是我就对道路进行了重新设置，让它更加清晰明了；有时候甚至彻底抛弃整个关卡，设计一个全新的环节。

　　最大的问题在于游戏中的陷阱设置。《小绿人历险记》中有许多需要玩家跃过的陷阱，但游戏虚拟人物的主要代步方式并非跳跃，而是飞行。

　　游戏主人公——绿色Android机器人的脚上有一个火箭飞行器，它原先的移动方式是：在地面上时要先酝酿动力，然后一飞冲天，再借助这种动力以及飞行器的力量，盘旋飞行。但火箭飞行器的能量消耗得很快，所以机器人着陆时要补充能量。我决定将它调整为，玩家飞升的时候，可以利用这种能量飞向遥远的平台，或者向敌人发动准确无误的攻击。

　　这种调整取得了良好的效果，但是我再看玩家测试数据时，又发现许多人扎堆死在无底洞中，甚至还有人会掉进极小的洞穴；死于陷阱的玩家人数仍然是居高不下，玩家的跳跃能力并没有提高。

　　获得这种信息后，我重新审视了游戏关卡设计，并发现了一些新问题。最根本的原因是，玩家看不到自己必须跃过的陷阱。首先，游戏界面中没有任何关于死亡陷阱的危险提示，而我设置的台阶又总是太高，玩家无法判断哪些坑会让自己跌到更低的级别，哪个坑会将引向万劫不复的深渊。

　　其次，也是最关键的一点，游戏中的摄像头运行效果并不理想，不能保证地面的可视性，当玩家向空中飞跃时，游戏界面就滚动到了屏幕顶端，导致他们无法看清路面状况，不知从何处着陆。

　　《Super Mario Bros》这款经典游戏的界面几乎从不采用垂直滚动方式，它有一整套严格复杂的标准，规定在哪些特定情况下，摄像机位可以上下移动。因为《小绿人历险记》中有飞行功能设置，所以我不得不支持界面垂直滚动方式。为了改变这种现象，我又开发了一个更智能的摄像头，只有在玩家快要离开可视范围时，游戏界面才会垂直滚动。

　　经过这些变更，我又向玩家推出了又一个游戏更新版本，并和上一个版本的测试结果进行了对比。结果非常乐观，玩家死亡率已经大幅下降，闯关所耗时长也在正常范畴之类，因陷阱而阵亡的人数大量减少了。

　　正式发布游戏

　　在我的测试团队的帮助下，我对这款游戏进行了一轮又一轮的更新和调整，最后才决定正式向市场投放游戏，但仍然保留了原来的测试系统，因为我想看看系统从在线用户所搜集到的情况，与测试团队所反映的数据究竟有多大差别。

　　当然，任何一款手机应用向服务器发送数据时，最好都要让用户知情。《小绿人历险记》刚发布时，首先会在游戏界面出现一个欢迎信息，并告知用户：为了完善这款游戏设计，他们在玩游戏过程中形成的匿名数据，将发送到一个服务器以便开发者了解情况，如果他们不想参与调查，可以直接关闭菜单中的系统记录选项。

　　看来这种方法才是最佳解决方案：它是开源代码，任何人都可以打开数据包查看其中内容（我保证这些数据不会锁定某一个特定的用户或手机ID），而且用户有权退出这项调查。

　　从Android Market上的游戏安装数量来看，选择退出调查的用户还不到20%，也就是说大部分用户都愿意参与系统追踪调查。

　　我也因此搜集到了海量的数据，超过了1400万个数据点（截止本文撰稿，该游戏的用户大约120万人）。

　　如此庞大的信息量很快就撑破了我的数据处理工具，之后还有许多工具都因此而瘫痪。我只好截取前1万3000名玩家的活动资料进行分析，这些玩家的综合数据与小规模测试团队的信息非常接近，这表明测试团队的调查结果也适用于大规模的用户群体。

　　记录系统的局限性

这个活动记录系统并非无所不能，它的设计仍然有一些不足和缺陷。

　　用PHP来编写服务器是个很不错的选择，但如果拿它来处理数据就完全不可行了。我原先的想法是，通过一个网页仪表板处理数据，但数据流量加大时，PHP就完全无法招架了。另外，PHP对硬件内存和运行速度的要求很高，我常常因为这些局限性而浪费了不少时间。当游戏用户超过2万人时，大部分基于PHP开发的工具全部罢工。

　　通过PHP编写的Bitmap处理程序尤其要命，我用PHP制作了所有的热地图，实际上我应该编写一些可以在本地运行，而不是仅限于网络服务器的程序。在PHP GD界面中，我发现了很多漏洞，为了处理程序我又不得不缩小关卡设计层的图像。

　　现在我又用Python和ImageMaick重新编写了这项工具，效果非常理想。我在《游戏开发者杂志》的官方网站上公布了实现这项操作的代码，如果各位有兴趣可以上去看看。

　　最后要提的是，虽然这个系统所提供的数据可以让我了解玩家死因，闯关时长等信息，但我并不能找到那些不会导致死亡，但会限制玩家游戏体验的活动死角。因为这个系统没办捕捉到这些信息，我的一些关键性关卡设计也出现了不少问题，最严重的例子就是，玩家无故被卡在某个环节中，大家都不知道要怎么脱身，最后只好放弃闯关。

　　我的系统并不能反映这种现象，我也是自己听到玩家抱怨，才得知了这一情况。所以我要说的就是，这种自动活动记录系统虽然超级好用，但并不能准确反映整个游戏的全貌。从我自己的经历来看，这个系统在查找问题关卡的布局上很管用，但却不能明确指出游戏的具体设计失误。

　　总结：

　　至于今后要开发的游戏，我当然还会植入这种自动记录系统来观察用户体验效果。除了死亡区域，我还会增加针对不同死法的监测，这样才能知道玩家是怎么赢掉游戏任务的；另外，从游戏的实际情况出发，我认为增加一项玩家死前的区位历史记录也很有必要，这样可以追踪该玩家的游戏路径。

　　不过，编写这种系统关键还是要让它尽量简化；另外搜集到充分的数据并非大功告成，只有开发出可处理数据的工具才能算是完成任务。所以我开发下一款游戏时，有可能继续用这种记录系统和数据存储解决方案，但会集中大部分精力编写行之有效的数据分析工具。

　　如果服务器可以读取个人玩家的活动记录，那这个系统也一定适用于大规模的玩家群体，它可记录的数据类型应该是多种多样，只是我们暂时还没有想到。它并不是一个完美的玩法测试系统，但至少可以长期提供有价值的反馈信息。

　　通过这个极其简单的系统开发过程，我对游戏的关卡设计、用户的游戏习惯有了更深入的了解，也因此极大优化了游戏。唯一的遗憾就是，我真后悔自己早些时候的游戏没有采用这个系统，因为它适用于任何平台、任何类型的游戏。

#p#副标题#e#