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

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

发布时间:2010-12-21 17:19:08 Tags:,,,

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

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

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

Replica Island

Replica Island

简单的玩法测试

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

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

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

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

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

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

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

Replica Island

Replica Island

向他人取经

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

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

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

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

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

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

Replica Island

Replica Island

推出初级版测试系统

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

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

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

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

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

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

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

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

heatmap

heatmap

游戏设计失误

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

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

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

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

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

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

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

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

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

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

Replica Island

Replica Island

正式发布游戏

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

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

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

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

我也因此搜集到了海量的数据,超过了1400万个数据点(游戏邦注:截止本文撰稿,该游戏的用户大约120万人)。

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

Replica Island

Replica Island

测试效果很理想

我对《小绿人历险记》的这个活动记录系统非常满意,因为它的开发非常省心省力,几乎不需要投入什么成本(服务器后端的开销比申请一个Xbox Live帐号还便宜),而且只需要调查两项活动内容,我就能快速有效地找到游戏玩家的事故多发地带。更重要的是,我通过搜集这些数据,还能和不同测试版本的统计结果进行对比,很容易就可以看出设计调整的效果如何。

使用PHP和MySQL作为服务器后端的编写语言也是一个很正确的选择,活动记录只是一些很零碎的程序,任何一种语言都能顺利执行这个操作,但有了PHP,整个服务器不需要30分钟就能完成所有的数据整合。

通过一个独立控制流来记录玩家的游戏活动,也是一个很积极的对策。我不希望有任何一个UI阻挡HTTP的调查请求界面,所以将网络通信内容移到了这个独立控制流。我一开始非常担心成本支出的问题,但事实证明,这种成本支出实在是微乎其微,我甚至懒得将它列到财务报表中。

最后,保持整个记录系统的简洁性也真是一个智举。我之前也有想过很多种备选的活动记录内容,但对《小绿人历险记》来说,追踪玩家死亡和闯关情况就已经足够了。越多统计资料意味着数据处理将更为复杂繁琐,甚至难以提炼出有效的反馈信息。我现在对控制这种自动记录系统已经有经验了,所以将来可能会增加一些调查参数,当然刚起步时还是首选比较简单的记录系统,这一点是不会有错的。

Replica Island

Replica Island

记录系统的局限性

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

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

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

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

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

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

总结:

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

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

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

通过这个极其简单的系统开发过程,我对游戏的关卡设计、用户的游戏习惯有了更深入的了解,也因此极大优化了游戏。唯一的遗憾就是,我真后悔自己早些时候的游戏没有采用这个系统,因为它适用于任何平台、任何类型的游戏。(本文为游戏邦/gamerboom.com编译,转载请注明来源:游戏邦)

Hot Failure: Tuning Gameplay With Simple Player Metrics

[In this article taken from Game Developer magazine's September 2010 issue, Google game developer advocate Chris Pruett describes how he quickly and cheaply implemented useful metrics into his