从开发者角度的游戏体验心态阐述

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

基于开发者角度的游戏体验心态

基于开发者角度的游戏体验心态

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

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

如果进一步梳理则大致在:

范例1,注重游戏进程的逻辑

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

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

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

范例2,数值和数据控

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

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

范例3,校验偏执症

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

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

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

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

范例4,细节层面的考究者

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

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

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

范例5,勤快的书记员

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

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

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

范畴6,马甲控和重复测试

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

和一般的玩家玩第二遍就会腻死完全不一样的热情是,开发者有两个差异化的能力:

一个是重复体验,不存在BUG的情况下体验游戏的流程(需要确保这个流程是开发者可控的);存在BUG的情况下校验问题的修正程度(问题是否得到修正,这个问题是否诱发了其他问题的发生)。并且这种重复还可能是不间断地数据重置,从新开始,有时候一个场景就要重复进出N次才算结束。

一个是马甲控,意图相对明显,第一种情况是校验不同等级的帐号在实际游戏中可能存在的战力和资源差异,特别是从纯粹策划角度推算出来的数值是不是存在偏差;第二种情况是杜绝帐号之间可能存在的利益输送问题,特别是以马甲出现的大小号是否存在以馈赠或者不均衡交易导致的资源单向堆积而破坏游戏玩家平衡的问题。

本文为游戏邦/gamerboom.com原创