订阅程序员杂志RSS CSDN首页> 程序员杂志

以开发者角度看其游戏体验心态

发表于2014-06-25 10:30| 次阅读| 来源《程序员》| 0 条评论| 作者郑金条

摘要:开发者回到自己开发的游戏中体验,大多不是为了寻找游戏的乐趣,而在于重复印证游戏设定是否顺畅。之前深思熟虑的环节会在游戏的体验中在脑海中呈现出来,一种潜藏的责任感逼迫开发者边体验,边与最初的想法比照。

最近,我就开发者能否用纯粹玩家的心态,来体验自己制作的游戏这一问题,与不同的设计者做了相对深入的探讨,大部分集中在:一个对游戏逻辑(比如接下来要展开怎样的进程;在哪个环节会出现什么动态,或执行什么操作会有多少相应的游戏反馈)了如指掌的制作者,在面对已知的游戏时究竟所持的是什么心态。是假装一无所知,好奇地寻觅潜藏在游戏各个角落的功能设置并将它激活为一种当刻的愉悦(或许还能因为游戏还原到一个自如运行的场景中,不同的元素相互碰撞而衍生出了很多开发者在设计制作时根本没留意到的新鲜乐趣来);还是用无所不能的“上帝视角”苛刻地审阅每一个游戏的进程是否真的能够如预期设置的那般完美地再现出来(尽管事实上,因为游戏的制作涉及到多方位的协同,必然在步调上存在不一致的现象,而导致最终的结果有一定妥协,不一定真存在100%的制作还原度),抑或是存在各种亟待调整的瑕疵。

事实上,我的看法更倾向于:开发者在体验自己设定的游戏时,基本很难再从探索游戏的进程行为中体验到如玩家那般的乐趣(玩家乐趣很大一部分来自于未知进程的实现,比如新打开的副本是什么样的场景,而自己要面对的Boss是什么角色等。当然也有例外,比如在重复体验游戏时,按照技巧和经验能最大程度优化游戏的完美操作程度,而获取到更至臻的乐趣),而是来自于开发执行之前的方案推演和开发前期的原型设计,这两个环节是否存在能触动开发者的乐趣发现,差不多就能决定该项产品能否最终获得开发支持——前者(方案推演)需要从产品的独立定位和独特体验,进行双重论证以获取必要的研发经费和团队的理念协同支持。换句话说,开发者大多在方案阶段就全面向自己的搭档完整地展示游戏的潜在乐趣,并用图文或肢体语言将这种乐趣轮廓式地勾勒出来,以便从一开始就能获得价值认同(虽然很多产品的立项大半没有经历过这个阶段的论证,可能只是大体地知道一个含糊的方向就开始参与到细节研发中,以致很多参与人员即便到游戏的完成阶段也说不清楚自己做的到底是什么样的游戏,比如有哪些让人印象深刻的环节等);后者(原型设计)更是需要最为直观地向整个开发团队立体地演示出该款游戏最为核心的独特体验应该是什么样子,而这样的体验是否能惊艳到玩家(比如区别于其他游戏的进程方式,和其他游戏相似的操作行为是否有更进一步的深度优化),并从反向进一步验证方案设定的可行性和具体能执行的程度(如果原型设计并不能满足开发者对游戏设定的最基本要求,即使勉强开发也不一定就能获得好的结果,还不如再逆推回到方案重新寻找可以替代甚至更优越的方式)。

这两者差不多是玩家关注不到,而开发者必需优先考量的层面。如果游戏存在乐趣也必然是开发者先于玩家进行设定,再落实到具体可操作的范畴,而不是类似玩家那样在游戏的进程中去逐步挖掘和感受游戏释放出来的乐趣。基于这种比照,开发者的这种游戏再体验就和玩家的行为存在了本质的区别:开发者是游戏方案的设定者和游戏乐趣的实现者,先于游戏存在,就需要预设和描摹出这种乐趣和可行性,开发者的再体验就是确保和验证这些设定好的乐趣的实现程度和再优化的角度(这种体验允许各种不合理的存在,并通过各种测试开发得到完善的结果);玩家是游戏乐趣的体验者,只是按照游戏设定的逻辑依次感受游戏赋予玩家的美好时光,并且大部分的愉悦就来自于对这些依次展开但对自己是新鲜元素的游戏内容(这种体验不允许丝毫障碍的存在,任何大的瑕疵都可能影响玩家的体验情绪和导致玩家的不满而离开)。

如果进一步梳理则大致可得到以下结论。

注重游戏进程的逻辑

对于开发者而言,任何的游戏系统、功能点、界面布局、弹框层次、游戏的资源布局、进阶属性、可能存在的掉落概率、游戏数值、副本顺序、战斗效果等因素都必然了然于胸。基于这种熟悉度,所有之前深思熟虑过的环节都会在游戏的体验进程中先后在脑海中呈现出来,逼迫开发者边体验边比照。一种潜藏的责任感往往能渗透到每一次的点击行为,直到这种游戏行为慢慢演变为一种校验举动。

于是,开发者就很在意那些弹出的文字框次序是否符合设定,文字陈述是否清晰,是否存在错别字;弹窗的颜色配比是否符合场景效果,字体是否放置得当;界面的按钮是否醒目,每次点击是否响应自如;功能系统生成时是否刚好匹配游戏的进程需求;客户端和服务端通信和数值衔接是否顺畅;玩家的资源和数值设定在游戏的深入发展中是否合理;游戏是否存在频繁的卡顿行为;预先设定的道具的掉落概率是否存在问题;游戏的美术图层是否存在设置叠加问题;战斗的打击感是否到位;游戏的每次加载时间是否会超过玩家的容忍度;玩家能不能接受基于内容不足设定的一些人为障碍(比如拉长游戏时间或使用重复行为);游戏的AI表现是否能尽如人意;玩家能否逐步适应游戏的难度设置;游戏的关卡和副本设置是否有让玩家探索的欲望,诸如此类。

对于开发者而言,这些进程是经过自己推演和预设的,如果重复回到自己所熟悉的场景,就必然坚持所有内容都要对号入座,才觉得这种体验是完满的。而一旦稍有差异,基本上浑身上下就只剩下“再把这些内容矫正回先前设定”的冲动了。

数值和数据控

随着游戏设置中的各种奖励数值和进阶数值泛滥化(这里的“泛滥”指的是数值出现太频繁,这些数值单次出现时对游戏整体效能的影响微乎其微。现在玩家基本上是程序化地完成这个展示动作,紧接着再完成一个收集动作而已。玩家基本不关心单次出现的1000个金币真的有什么价值,事实上这些金币本身也真的没什么价值),很少有玩家会去关注具体数值的出现对资源增减的变化,大半都是伴随着一个点击行为就过去了。只有开发者才会对这些细微数值的变化敏感。这背后必然意味着:需要验证前端的数值运算和服务端的等值反馈是否准确或是否即时。在游戏数值化(基本靠数值的变动来表现玩家资源或战力的差异)的当今,每一次数值的记录都左右着玩家在进程中的游戏体验(特别是一些关键位置的数值变动,比如完成一次大战役和执行一次小任务在数值层面就需要拉开差距)。而如果一旦数值出现记录失误,可能玩家会忽略,而开发者则必须追根溯源地寻找到问题的症结才算迈过一个门槛。

与单次行为相对应的是数值的可控性设计。很多设计者有多种看起来完美的计算公式,一下子就梳理了整个生命周期的数值布局,但实际上比单次计算更严重的是:要么数值不能兼顾长周期,导致游戏进程中数值累积量不断失控,最后玩家间游戏既不可能平衡,而单个玩家面对自己大额度的资源数值又手足无措;要么数值设定完全公式化,没有权衡到游戏进程中因为玩家的深度参与和一些事件性的变化,可能致使原本合理的公式化计算偏离需求,最大化地迷惑了设计者本身,原以为完美无缺的环节成为游戏最糟的瓶颈。

校验偏执症

这几乎是一种本能的反应,开发者在游戏体验中的每一个行为都在追求操作正确,这种正确性的诉求可能又包括三个方面。

其一,整体的游戏进程是否和当时方案的设定相吻合,因为开发者本身的沟通问题或开发者对技术相关能力的偏好,有些预设的内容在执行层面被置换为其他的替代方式,或压缩了使用范畴,或直接取消了部分有实现难度的内容。事实上,很多功能系统最后实现的部分都是偏离预案后的妥协结果。

其二,游戏的执行进程是否存在体验障碍,影响了玩家的直接游戏感受,诸如卡顿是否太厉害、视觉效果是否让人失望、功能响应是否有障碍、界面设置和弹出是否符合用户的逻辑习惯、用户是否觉得数值所得不满意(如图1所示)。大部分玩家都是情绪派,任何糟糕的体验都可能导致一个用户的流失。


图1  Pixelmator测试Flapcraft游戏技能

其三,多次验证那些在方案推演和原型设计过程中被认可的功能系统是否如预想中的那般。这包括:第一,这些系统和整体的游戏搭配的协调度,是突兀地单独游离成为一个环节,还是成为游戏整体的有机部分(我们看过的很多游戏的一些功能点都是附属的,基本缺乏整体感);第二,在整体的游戏环境下,单个系统的执行有趣性是否和预想的相当,或作为一个整个的衔接环节让游戏更有趣,还是沦为一个重复执行的枯燥体验;第三,与市面上现成的游戏相比照,从侧面验证类似的设计在玩家群体中是否有足够的竞争力(比如匹配用户需求的创新点或相似玩法具有深度优化层面)。

细节层面的考究者

举一个典型的例子,近一年《Clash of Clans》类的游戏大为盛行,但又都必然面对一个问题:“防建同体”玩法最大的顾虑是,游戏的执行后期界面中的游戏素材堆积失控,特别是一些动态构造,既让玩家应接不暇,也同样给系统带来了无尽的负荷压力(与之相对,在网页游戏中,开发者所着力追求的同一个场景的火爆场面同样也存在着这个问题,当同一个界面有无数个人物在跑动时,对玩家的计算机就提出了更高的配置才能适应游戏需求不至于卡顿),玩家可以追求各种华丽的效果,而开发者则需要兼顾这些效果是否会干扰玩家的正常体验。

当然也包括开发层面常遇到的问题:在电脑正常配置和平均网络加载数值的情况下,就需要考虑游戏内容的加载时长是否超出了玩家的忍耐限度。而各种NPC的加载是否存在滞缓的情况,甚至在玩家的博弈状态下延时问题又会给玩家带来哪些困扰,大面积特效的使用是否会让玩家的体验不够流畅,AI的表现是不是会让玩家觉得不够给力,游戏的数值设置是不是足够均衡。

基本上最容易惹怒玩家的,就是开发者必须关注的核心细节,我们常看到的玩家吐槽中,很大比例都和上述几个层面相关。

勤奋的书记员

我曾做过一款游戏的测试,仅仅关于问题的陈述和截图就将近1000页Word文档。和纯粹体验游戏的玩家不同,开发者必须不放过任何一个优化游戏的问题记录。不管问题再小,出现的概率再低,都可能成为一个游戏自我完善的困扰。

于是,开发者所做的记录可能细致到:陈述问题本身并截图以做印证;还原游戏当时执行操作的相关步骤;当时捕捉到的关联代码;玩家的网络问题;玩家其他不合适的操作行为;问题本身可能重复出现的概率(如果概率很大就算功德圆满;如果概率一般甚至只出现过一次,这个问题就会成为一个等待处理的搁置嫌疑,留下一个悬而未决的尾巴)。

当然,并不是所有的记录问题都能得到妥善的处置,比如有些问题超出了开发者的能力范围就基本会成为大问号,直到玩家都公开抱怨也无能为力(大部分都和技术瓶颈有关)。

马甲控和重复测试

从开发者的角度所做的体验很多不是基于寻找游戏的乐趣(这部分我们在前文论述过,开发者的乐趣在方案推演和原型设计上,如果这两个部分不能感知到乐趣,就基本没有再研发的必要了),而在于重复印证游戏的逻辑设定是否顺畅。差不多此时,开发者的眼里都只有Bug,如果一次体验没找到Bug,都可能会怀疑是自己玩得不够好或玩得不对。

与一般的玩家“玩第二遍就会腻”完全不一样的热情是,开发者有两个差异化的能力。第一个是重复体验,在不存在Bug的情况下体验游戏的流程(需要确保这个流程是开发者可控的);存在Bug的情况下校验问题的修正程度(问题是否得到修正,这个问题是否诱导了其他问题的发生)。并且这种重复还可能是不间断地数据重置,重新开始,有时一个场景就要重复进出N次才算结束。第二个是马甲控,意图相对明显,第一种情况是校验不同等级的账号在实际游戏中可能存在的战力和资源差异,特别是从纯粹策划的角度,推算出来的数值是不是存在偏差;第二种情况是杜绝账号之间可能存在的利益输送问题,特别是以马甲出现的大小号是否存在以馈赠或不均衡交易导致的资源单向堆积,而破坏游戏玩家平衡的问题。

作者郑金条,游戏邦负责人,游戏邦主要关注和解析国内外社交游戏和手机游戏领域,并定期做深度行业阐述。

0
0

近期活动

更多

2015中国大数据技术大会

为了更好帮助企业深入了解国内外最新大数据技术,掌握更多行业大数据实践经验,进一步推进大数据技术创新、行业应用和人才培养,2015年12月10-12日,由中国计算机学会(CCF)主办,CCF大数据专家委员会承办,中国科学院计算技术研究所、北京中科天玑科技有限公司及CSDN共同协办的2015中国大数据技术大会(Big Data Technology Conference 2015,BDTC 2015)将在北京新云南皇冠假日酒店隆重举办。

微博关注

程序员移动端订阅下载

相关热门文章