《阴阳师》业原火BUG是怎样产生的？

《阴阳师》在2017年的元旦活动一波未平一波又起，在沸沸扬扬的姑获鸟特典皮肤金鸾鹤羽逐渐走向平息的同时，业原火副本bug再次将这款游戏推上了风口浪尖。

在2017年元旦的活动中，《阴阳师》增加了一个新副本，玩家在挑战普通御魂副本时，有机会获得挑战凭证道具「贪念之卷」、「嗔念之卷」、「痴念之卷」。通过消耗该类型道具即可召唤「业原火」进行挑战，将获得非常丰厚的御魂奖励，其中包括三个全新御魂。

御魂是《阴阳师》游戏后期的重要组成部分，很大程度上决定了不同玩家在最重要的PVP活动“斗技”的实力，一般而言玩家在游戏中获得一个好的六星御魂需要付出大量的金钱，而想要获得业原火副本的御魂也并非易事，三种挑战凭证道具的掉落率很低，而要挑战的BOSS业原火也是很大的挑战。但是一些玩家发现了一个Bug,只要玩家有足够的体力，不需要挑战凭证道具就可以通过御魂1层的难度值获得业原火的御魂奖励。这个Bug逐渐流传，于是很多玩家利用这个漏洞获得了大量丰厚的御魂奖励。

在2天之后，《阴阳师》运营团队才发现这个Bug并迅速修复，但是已在大量玩家之中引起巨大的波澜，而运营团队对使用Bug的玩家的处理方式也让玩家的不满继续酝酿，网易最终是否能将这个危机消弭于无形还不得而知。不过在这里，我们邀请到了一名资深游戏QA（Quality Assurance），和大家一起了解这个Bug可能的成因，以及常见的应对与解决办法。

以下部分为受邀者的分析，根据其要求匿名发布。

注：因为游戏开发所使用的引擎和具体的实现技术不同，Bug产生的原因和具体解决办法可能有差别，也许未必具有指导意义。本文仅从程序逻辑的角度进行分析，欢迎各位开发者一起探讨。

业原火Bu：级别定义为A  -A类当日需修复

该Bug可以在很短时间内产生大量的御魂，严重影响了专注PVP的后期玩家的体验，损害了付出了大量金钱和精力玩家的利益。目前问题已经被网易修复。

修复建议：当日停机修复解决，一般会做回档处理和奖励活动拉升数据。本次问题从出现到解决历时2天多，应通过下文所说的舆情和用户反馈提早解决问题，此类问题的级别估计之前被估低了。

先说结论，这个Bug产生的原因是程序设计时的逻辑出现问题而产生，接下来的部分会做重点阐述，而原本应该在QA测试阶段发现的问题没有被发现的原因可能是QA遗漏了更新的协议消息拆分验证或是没有仔细测试，导致出现了这么严重的运营事故。

那么我们来说Bug产生的原因，不过要理解这个问题需要一些基本的计算机知识，这里只能做简单介绍。为方便阐述，下文中的 C（client）代表客户端，S（sever）代表服务端，A副本代表目标副本业原火；B副本代表实际副本御魂1层

网络游戏内逻辑行为是需要通过端对端通信来实现，C->S  C->C  S->C 几种传递消息的方式。大体是由客户端C创建命令发送到服务端S，服务端S响应这些命令并按照约定的顺序，应答客户端C的通信。有些逻辑是纯客户端的，有些逻辑由客户端开始，任意一端结尾的，根据不同类型的协议组合成联合体来实现。

上面提到的约定的顺序可以理解成约定顺序由事件触发，正常而言顺序是这样的：

[场景1 请求副本]->[场景2 响应副本请求] 同时并行会加载进度条和[消息请求列表]

[场景1 通关 战斗数据C –>S] 验证通过-> [场景2服务端判断]->胜负判断 [场景3 S等待接收消息]-> 结算（奖励和次数）

消息分段处理，场景3需要C->S告诉服务端可以进行结算，然后玩家可以得到相应的奖励。

《阴阳师》的玩家拿到了1张门票，前往目标A副本

点击进入A副本时， 正常消息请求过程，请求副本入口有了延迟，快速切换进入另外1个副本B，B副本是一个比较容易刷的副本，副本c->s时会请求副本id（而《阴阳师》这里也没有标记），B副本进入掉落了一开始请求的A副本掉落，没有扣除体力。

这个bug可能引发了几层的问题逻辑问题，结果就是大家看到的：通过打其他副本获取了目标副本的产出。

客户端层面：操作延迟只是诱因，关键还是这个逻辑如何处理

根据问题描述，发现GUI是一张图，1个按钮是不会单独写初始化判断，如果不是1个GUI，可以通过enterScene的方式去判断。

打了B副本掉落继承A副本。按场景来分，到了前面说的场景2，切换点击B副本，前端已经收到了Atitle等信息和奖励协议，这个已经显示出来了。随后进度条进入了B副本，客户端又发了当前副本的ID，B副本不要门票，服务器没扣门票

建议检查方式是弱网链接+插桩print打印日志，确保进入哪个和最后结尾是哪个，复现问题也可以截取点击B副本按钮数据包减低发包间隔进行发包处理。

修复建议是客户端在请求副本加载loading时锁键处理来降低风险。

数据结构层面：配置表检查，程序会读取副本ID那列取对应副本编号，副本掉落配置和副本信息同表或者以活动表形式拆出来。实际评估对本次bug影响很小。

如果《阴阳师》活动副本处理方式是C->S发起请求副本后，S申请1个活动副本形式，假设活动副本逻辑被打断了，这部分可能性很小。

服务端层面：服务端会根据配置读对应的副本ID，服务端可以判断是否有这个副本 ，没有的话给出！map找不到副本 和副本类型错误，这次《阴阳师》出现的的问题都是1个副本类型，这里需要依赖客户端告诉服务端信息的，手游这样处理也没有错。

用户点了A副本后，再点B副本，服务端开启了两个线程同时处理，等轮到A去验证进入条件的时候，发现条件满足了，没有消耗。等到通关场景，A和B线程都收到C->S通关了，然后A副本去执行发奖励，并标记奖励发了，由于客户端层进入时读取了另外的场景，消耗走的是副本B。

修复建议是客户端主动发来的消息字段，无论是遇到C->S副本ID在消息结构体内中断时，还是C以第一次发给S的为准，并且服务器在副本结算时做校效。

 

当出现异常时，是否应该考虑清除副本状态，通过1条消息去通知客户端扣除相应消耗道具。

整合以上的判断：

点了副本A和再点副本B，服务端开启了两个线程同时处理，等轮到A去验证进入条件的时候，发现条件满足了，没有消耗，等到通关场景，A和B都会收到通知服务器通关了，然后副本A去执行发奖励，并标记奖励发了，刚才场景进入时读取了另外的场景，客户端自己演了一组相声

C->S 我要打高级副本（标记）

S->C 来吧

C->C 请求数据等

C->S 我要打低级副本 -->无法标记了

S->C 来吧  --->修改为 S->C ...（不理会）多次后跳出

进入副本（这里有很多层）

C->C 我们自己打，等会叫S你

C->C 继续自己玩自己

副本结算-胜利

C->S 打完了，S在吗？

S->C 在在

C->S 奖励拿来

C->C 界面点点点

C->S 就是刚才说的高级副本

C->S 就是刚才说的低级副本 -->已经拒绝了

S->C 好的高级副本，接着奖励，么么哒

网易应该也有舆情日志系统，虽然这次的问题主要还是逻辑问题导致，但是通过对数据的监控也可以及时发现异常，将可能发生的问题及时解决，而不会像这次这样快3天才发现和解决。建议有一些人力条件的公司 遇到一个产量比较高的活动，需要对关键数据做舆情日志，因为单纯依赖某个货币去控制的风险需要规避。

监控数据类型：

记录单位时间内  获得御魂的数据流

记录活动->产生门票数量

门票消耗记录 -> 这些都会去影响对目标副本id产生的战斗次数

以上就是对《阴阳师》的业原火Bug的分析，实际上“业原火”这个副本名称也是一个Bug，应该叫做 “丛原火”。丛原火在京都出现的一种鬼火妖怪，据说他生前是在壬生寺偷盗香火钱和灯油的一个名叫宗源的僧侣，在死后受到佛的惩罚，所以化作了鬼火。至于为什么被《阴阳师》的策划看成业原火… 

鸟山石燕《画図百鬼夜行》中的丛原火

在业原火Bug之后，《阴阳师》今天又爆出了一个所谓的8级雪女被修改的Bug，实际上能被修改的原因是近年来包括《阴阳师》在内的很多手游很多内容放在客户端处理，比如战斗数据，所以可以通过修改内存加解资源的方式增加技能伤害（修改这2者缺一不可），也可以通过直接发胜利消息让副本直接通关，这需要服务端那边对于不是正确按约定顺序的消息，全部做拒绝处理。

所以即便你修改了，到结算的逻辑验证环节也是通不过的，以网易开发的经验来说，这种很初级的错误应该不会犯。所以如果没有人能给出正常结算的视频，那么都无法说这是一个Bug，毕竟现在很多手游现在都是把一些数据放在客户端运算的，然后把结果发回服务端进行验证，主要确保这个环节不出问题即可。

最后，感谢大家阅读上面的枯燥分析，也希望业内质量带来的问题越来越少。QA测试的工作本身就是尽量规避游戏可能的风险，希望所有游戏公司都能够重视这一环节。