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

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


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

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


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

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

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

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

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

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

业原火Bug的成因

先说结论,这个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告诉服务端可以进行结算,然后玩家可以得到相应的奖励。

Bug具体分析

《阴阳师》的玩家拿到了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副本按钮数据包减低发包间隔进行发包处理。

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

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

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

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

整合以上的判断:

点了副本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测试的工作本身就是尽量规避游戏可能的风险,希望所有游戏公司都能够重视这一环节。

热门相关:傅少心尖宠:娇妻,有点甜!   总裁,我要离婚   相爱恨晚   相爱恨晚   相爱恨晚