【游戏杂谈】修bug与优化的难度到底有多大？

在开始这个问题之前，首先要感谢一波苹果的App Store，虽然它有一个雁过拔毛的30%苹果税（但考虑到国内应用商店联盟对渠道服抽取50%的狠税，似乎又算不了什么），但它也成功地逼迫各个游戏开发商做好自己的项目管理，不至于像各种国产App一样，往用户的手机里塞一堆屎山。（BV1SK4y1u7Vj）

而且，尽管App Store针对的只是苹果生态的用户，但作为开发商在开发游戏的时候不可能单独开发两个版本，只能是开发一个跨平台通用的版本，然后通用——现在的游戏引擎基本是跨平台的，ARM和X86的天堑都能跨越给你看，更别说同为ARM架构，同为Unix内核了，游戏引擎面对这种情况的处理简直是家常便饭了。（iOS系统的底层内核是Unix，安卓是跑在Linux上的java虚拟机，而Linux的内核也是Unix，因此这两个系统之间的兼容性问题并没有大多数人想象中的那么明显）

说了那么多，苹果的App Store对游戏领域软件生态最大的贡献是什么呢？

禁止热更新程序本体，所有涉及程序本体的更新，必须提交完整的应用程序包给App Store审查，过审之后才允许更新，热更新只允许更新贴图文件之类的与程序运行无直接关联的内容。（这也是国产App流氓的地方，它的程序本体是一个浏览器，你更新不更新，都基本不妨碍它新功能的推送）

这就意味着，一个游戏开发商在发布客户端的时候，必须清理包内冗余过期的文件和内容，同时也必须经过三番四次的测试，确保包体不会出bug，至少不能出恶性bug，用户的体验提升了，而且，因为每次都强制更新的包体，也意味着用户长期使用之后，客户端的占用不会像各种国产功能性App一样，占据不合理的四五倍甚至更多的储存空间。

但稳定性提升自然是有代价的，首先就是各个功能的测试，开发商会更加谨慎，优化不敢轻易去做，必须要经过长时间的测试确保其稳定性后，才可能在下一次大更中实装。bug的修复不会特别及时，除非是恶性bug，否则都不会立即修复，一些普通bug或者轻微bug，往往要拖很久才会修复，甚至忘记修复。

为了应对这一限制，大部分游戏开发商都会采用比较现代化的编程思路，也即是将程序设计的逻辑层与数据层进行分离，让数据层不需要存储在客户端的本体之中，而是单纯以数据存在，而数据部分，App Store是允许热更的。

减少程序本体包含的部分，可以大幅度降低修复bug的难度，开发者只需要抽象出一个个模板与标签，实际开发时，再由数值策划选择对应的标签填数值即可，数值策划的锅不用程序来背。（2021年了，不会还有谁以为数值策划可以不懂写代码吧，平面画师都要开始学3D建模了）

以明日方舟为例，美术音乐素材和文案这些都属于数据层，干员技能效果的数值部分（标蓝的部分）和文字描述部分都属于数据层，而数据层的bug是可以热更修复的。

比如之前熔泉的bug，就是数值部分写错了标签，导致逻辑层无法正确读取，继而无法生效技能特效，这种问题只要发现了（也可以是玩家发现的），就可以通过闪断热更来解决。（其实闪断只是为了强制你去安装更新，原神的热更就不需要闪断，只是在涉及不同版本之间交互的时候才会强制你去重新登录游戏更新）

讲完了App Store对更新的影响之后，我们再来谈谈bug与优化项的等级，以及内容从提出到实装需要经历的流程。

BUG这东西，根据影响力大致可以将其分为四类：恶性bug、严重bug、普通bug，轻微bug

优化调整项大致也是如此，我就不单独列词条了。

恶性bug：不立即修复就会对游戏的口碑或者收入造成严重影响的问题。

严重bug：不修复的话，必然会影响玩家的实际体验，继而影响游戏的口碑与收入。

普通bug：不修复的话，会对玩家造成一定的影响，但在玩家可以忍受的范围内。

轻微bug：是个问题，但对玩家的体验基本没什么影响。

恶性bug基本不可能出现到正式端里，负责测试的会将所有可能出现恶性bug的地方都进行测试一遍确保没有问题，因为恶性bug带来的损失是很大的，尤其要确保逻辑层不存在恶性bug，一般的恶性bug也很少会由数据层的问题带来。

一般来说，会导致恶性bug的错误都在人正常的脑回路里，恶性bug流入正式客户端的可能性很小，但也不能完全排除，这就是测试服存在的必要性，测试玩家只要不是纯种傻子，都不可能瞒报恶性bug，而且测试服人相对较少，开发团队监控起来也相对简单，就算玩家刻意瞒报，测试人员也往往能发现数据的异常，但严重bug一类的就不好说了。

明日方舟也出过恶性bug，腐蚀气体+隐匿术师这个bug就是典型恶性bug，因为玩家要获取当日的轮替合约奖励，就必须要选择对应词条，而对应词条导向了一个彻底无解的结果。

所有让玩家必定无法完成官方指定游戏内容的bug都算恶性bug。

但因为在危机合约这个模式的开发中，进行了逻辑层与数据层的分割，词条选择这部分属于数据层，因此可以通过热更来解决，算是不幸之中的万幸了。

严重bug大概是正式端里级别最高的bug了，一般来说，是主要销售产品的实际表现严重不符合描述效果，不过这种类型算严重bug还是恶性bug主要取决于游戏类型，如果是单机为主的游戏，那就只算严重bug，如果是联机为主的，那就是恶性bug了。

严重bug大部分都是逻辑层的bug，一般是测试方案设计不够完善导致的，不过大部分对玩家非有利性的这类bug，都可以在测试服被筛出来，至于测试服都没有的游戏，只能指望测试团队够强大了。

夕的技能实现问题就是典型的严重bug，而且是属于逻辑层的bug，必须要大更才能解决，但因为级别不算太高，这种情况下，官方只要给出承诺，消除其对营收的影响的话，就可以押后处理方案的实装，节省大更计划。

当然，也有熔泉bug这种在skill_table.json文件里写错属性标签这种愚蠢的数据层bug的存在，一般来说只要排查出来都会秒修或者在最近的一次热更里集中修复，毕竟热更补偿和大更补偿不是一个级别的，难度也没那么高。

麦哲伦当初的“保密模块”bug，尽管会引发客户端卡死，但因为麦哲伦本身并不是玩家的唯一选择，只是相当于在游戏地图内ban掉了麦哲伦这个干员而已，因此只属于严重bug，而不会上升到恶性bug的层次。尽管其表现相当恶性，但在经过引导之后可以暂时规避的，最高只属于严重层次。

而普通bug，发现难度高，实际影响相对不高，因此官方修复这类bug是否积极，主要取决于开发团队的组织管理能力，也就是什么时候将这部分内容给加到开发计划中，并进行调整与测试。

普通bug大多存在于开发者的思维盲区里，这类bug很多时候都很难被人发现，因而实际影响非常有限，这类bug是否能够得到修复，取决于其复现难度和对游戏实际影响的大小。

这里必须明确一点，bug的发现难度和复现难度并不存在相关性，一个很难发现的bug，可能拥有非常低的复现难度，比如通过对buff堆栈的操作，删除掉余烬强制撤退的标签来实现永续黄昏等一系列相关操作，就属于发现难，复现易的bug。

想要发现这个bug并构建出bug原理，首先你必须要先发现这个现象（这是大多数这类bug发现的难点所在），其次你要试出大致的复现方法（此时的复现难度还是非常高），然后你得有一定的计算机常识去猜测这一复现方式的原理（堆栈操作大学计算机学吗？好像只是了解吧，更何况很多人这课都是水过去的吧）。得出原理之后，这一bug的复现难度基本为0。

而这类bug的影响非常大，所以比较容易上官方的开发计划。

而明日方舟发现这类问题的主要途径是什么呢？主要通过海猫的B站关注列表（雾），现在他设隐藏了，以前可以看到他关注了泥萌都是托——这是看bug的，还有小狼XF、魔法目录ZC——这是看攻略反馈的（都开服没多久就几十万粉丝的作业up，谁没被关注谁尴尬，毕竟从少前出来的，该记的仇还是要记的），还有哈老板——这是看二创的。

现在他关注了谁不清楚，但很明显，bug的修复和几个专注于整活bug的up主的更新有一定的相关性——除非bug真的恶性到挤爆了鹰角的客服。

鹰角修复的这类bug，有一个影响很深远的（我也翻过车的），但大部分人可能根本不关心的，就是帧对齐的问题，这个修改在2019年12月24日就实装了，但在2020年10月8日才由花见花开大佬得出确切的解释。

在更新前，所有小数帧数都会进一位处理，更新后，对于动画长度略微超标的部分动作，则增加了一个强制刷新间隔的操作，实现了一定程度上的四舍五入，但早期粗暴的测试只得出了四舍五入的结论，并不能解释部分异常间隔的问题，直到后面“减速力场”重新研究逻辑，暴力翻代码才发现了动作等待机制这一个特殊的设定。

这类问题对玩家有没有明显影响？有。因为动作等待机制，火山15帧一颗变为16帧一颗，技能期比理论值少了1/15的伤害。

玩家是否对此有很大意见？没有，玩家习惯了。

而鹰角增加四舍五入的机制去修改这个帧进一的问题，单纯是有一些攻速太快的干员伤害丢失过于离谱，引起了他们的注意不得不改而已，这个问题比较早期，反应的玩家基数大，所以得到了解决。

而火山在当时普遍认为伤害溢出，没多少人去追究这方面的问题，加上后来内容越出越多，等玩家开始追究这方面问题的时候，已经积攒不出足够的影响力去让官方做出改变了。

而最后的轻微bug，大概就是错别字一类的问题了，这类问题一般都是数据层的问题，短期内玩家压力比较大基本都是秒修的。

简单来说，不同级别的bug，决定了官方应对态度的不同。

恶性bug只要不是傻子都不会不立刻修复，只不过这种bug很少出现在正式服。

严重bug会根据修复成本，决定是立刻修复还是先安抚等大更，对于于玩家有利但破坏平衡性的逻辑层内容，一般都是选择下一个版本大更的时候修复。

普通bug的修复纯粹看玩家反馈的压力，以及官方获取信息的渠道。

轻微bug嘛……纯看开发团队的心情了。

从bug的处理来看，也不难发现，大致的思路对于优化也是适用的，但优化和bug有一个很大的区别在于，绝大多数的优化都必须与逻辑层相关，这也导致了成熟游戏的开发团队对于优化非常不积极。

很多人从2019年要求到2021年的一键领取任务，在功能上对应普通需求的优化——毕竟之前很少有玩家因为这一点而退游。

但只要涉及逻辑层的修改，不论改动的多少，整个流程是一步都不能少，除了要修改代码之外，还必须进行反复的测试，确保不会引发新的恶性bug。

你或许会说，写个for循环级别的代码会有什么恶性bug？

如果你只写一个for循环，那小学生都能做到（取决于地区，部分地区直接教，部分要信息学竞赛的才会教，非自学前提下最低三年级就可以做到）。

但问题在于游戏开发是使用游戏引擎的，而游戏引擎是个黑箱，很可能会在你思维盲区的地方出一些奇奇怪怪的bug。

稍微做点常识科普吧：

0.8在十进制下是有限小数，但二进制下不是，因为：

0.8＝8×10^-1

0.8＝1×2^-1+1×2^-2+1×2^-5……=(0.11001……)2

0.8无法表示为系数为0或1的2的整数次幂之和，所以在二进制里，0.8是个无限小数。

这类问题可以在一些劣质计算器上见到，通过除法计算得出小数之后再反向做乘法得不出原来的数，这就是十进制和二进制转换之间奇奇怪怪的问题。

计算机存储小数，在精度需求不高的时候，一般采用浮点数来解决，单精度浮点数中用于储存有效数字的位数为22位，二进制下22位无符号二进制数的表示范围也不过只有大约400w左右，也就是十进制下的有效数字位数可以说相当有限，考虑到二进制小数的特殊情况（因为2进制的舍入机制，转换后可能只有前3~4位是有效数字），实际精度还会受到一定的影响，因此有效位数会更少。

明日方舟的“减速力场”bug，就是单精度浮点数精度不够导致的bug。

明日方舟每30帧长度为1秒，每一帧的长度应该为0.03333333……秒，但在计算机里，不专门写一个对有理数的储存方式，是无法在二进制储存下保存这个数字的有理数属性的，而在获取帧间隔的时候，游戏引擎使用的是当前时间减去已进行时间轴的方式，这导致在一定范围上会出现帧间隔发生差异的问题。

作为游戏开发者而言，游戏引擎是一个黑箱，我只需要知道我这么做能得到什么就行，而不用去管为什么能行，这大幅度降低了开发的门槛，但也导致了大量的思维盲区的出现。

这个帧长度计算机制的问题，结合另外一个为了避免叠攻击bug而存在的容错机制结合，就导致了原本不需要等待的攻击动画在特定时间阶段里需要进行强制冷却，进而导致了攻击间隔会在特定时长和攻速下变长的问题。

作为一个开发人员，是不需要理解引擎功能的实现方式的，这也导致了这样的问题开发人员压根就没想过——除非真的遇到了，而且像这次一样被人挖出了原理，否则基本上这类问题就连开发人员也无能为力。

那有小天才就问了，单精度浮点数22位的尾数精度不够，那就上有51位尾数的双精度浮点数啊。

不好意思，绝大多数网络游戏（包括手机游戏）为了多设备兼容性，都是32位的。而双精度，只有64位环境下才默认支持，国内很多网络游戏的实际开发环境就像大多数人的计算机课本一样，都是过时的版本，比如都2021年了，不还是有大把用虚幻3开发32位网络游戏的公司吗。

而优化功能，哪怕优化部分的代码再简单，代入到整个系统里，可能产生的连锁反应就不是程序员能够控制的了，因此哪怕再简单的优化，比如这次的增加一键领取功能，也必须经过反复的测试，而且原本越成熟稳定的功能，越是需要如此，谁也不敢承担加装了一键领取功能之后，领取完成之后因为迷之bug而出现崩溃的后果与责任。

加装简单功能进行优化是没什么难度的，但测试环节就不一定，尤其是这个每日任务系统没有我们看上去的那么简单，逻辑层上，它是允许通过数据层增减任务的，这就导致了每日任务系统的测试要比一般人想象中复杂不少。

而游戏开发团队中，测试人员的精力是有限的，因此，一项优化能否实现，主要取决于开发计划的安排，如果在开发计划中，这个项目被列为不重要，那么这个优化就无法实现。

对于优化项目来说，只需要记住一点就可以了：

几乎所有优化项目，不管简单到只是加一个一键领取，还是复杂到修改整个UI，都基本上会涉及到逻辑层的修改，这种修改必须经过严格的测试才能正式发布，因此其实际实装难度有一个并不算低的下限，达成这个下限的成本很可能比不优化带来的损失要高，这才导致了功能层面的优化往往都很拖沓。

一款游戏的bug修复及时与否，主要取决于程序员的能力和负反馈机制，得益于被App Store倒逼出来的分层式程序设计，大部分程序员都是合格的，合格的公司，这类消息的反馈机制也很及时。

但一款游戏的功能优化是否得民心，则主要取决于开发组制定的开发计划，这是因为再简单的优化也必须经过测试，而测试资源是有限的，头铁不开测试服的公司更是如此。而开发计划制定得是否合理，主要取决于官方采纳玩家意见的通道是否通畅。

如果官方过于自信，只采纳头部创作者的观点，和比较大的节奏，那么一些很重要，但实际上对数据影响不明显的优化，可能优先级就不高了。

因为必须要明确一点就是，头部内容创作者往往会考虑和官方的关系，大部分情况下都会挑游戏好的方面来讲，而很少会反馈功能不合理这类需要优化的软性问题，这就导致了一些实际体验影响很明显，但又不实际影响数据的优化项目会成为大版本集中优化的漏网之鱼，但正是这种漏网之鱼最容易在玩家群体之间发酵，继而导致玩家负面情绪的发生或者导火索，而最后调查的结果却和这个实际原因无关，直到最后爆一颗大雷。

不过个人来说有一个建议，对于那种你觉得有必要存在但官方又不提供的功能与优化，不妨将开发组往钱眼子里套一下，得出一个能自洽的说法，能显著降低对功能的期望值，或许不能解决什么别的问题，至少能让自己找到一个发泄渠道，过得舒服一点。