本文继续记录一点自己查找定位 Bug 过程中的思考
游戏功能开发往往涉及协作,最有代表性的可能就是 客户端 和 服务器 之间的功能联调了,有时候特性比较大的时候,各个部分的流程功能点还会被进一步拆分,以进一步增加协作粒度.
之前有块游戏功能比较大也比较急,功能拆分时为了迎合不合理的开发周期,拆分的非常粗糙,大概的思路就是把相关功能点拆分出来分配给各位同学,然后总的开发周期就取最长的那个功能点的开发时间.
很显然,这种评估整体开发周期的方法是非常不靠谱的,我们暂且不论单个功能开发点本身可能存在的迭代反复问题,单就完全忽略各个功能点之间的串联成本就能知道这个评估方法的不合理了.
不过在此我不想过多吐槽这个项目的管理问题,只是想记录一下由于疏忽串联沟通而引起的一个游戏 Bug.
总的来说问题可以概括成这样 :
我们小组负责实现了很多定制化的 Actor(游戏基于 UE5)功能,每个功能我们小组内部都经过了不少测试,相对而言功能本身还是比较稳定的,但是这些功能相关的 Actor 的创建,则是由另外一个小组负责的,由于之前与这个小组没有怎么合作过(这个小组属于另外一个部门),外加项目周期紧张,所以功能开发期间并没有深入对齐过接口,只知道对方抽象了一个蓝图类(蓝图类上挂了很多 ChildActorComponent 组件)用来处理 Actor 的生成问题,望文生义,自己便顺势脑补了以下的 Actor 生成流程 :
Server Spawn
BP(ChildActorComponent)
Functional Actor
上面流程看上去简单易懂,目测应该不会出现什么 Actor 生成相关的问题,可是等到后面实际跑完整功能流程的时候,却遇到了很多让人难以理解的现象:例如功能逻辑失效;Actor 生成异常 等等,不一而足 ...
但是上述问题在我们本地功能测试的时候(本地功能测试不走正式的生成流程)又都是正常的,没办法,最终还是得想办法来追踪调试,主要有两个思路:
- 添加调试日志以逐步追踪
- 本地完整测试以断点追踪
两个思路都实践了下,庆幸本地完整测试还是可行的,尽管相比本地功能测试慢了很多,但是比起添加调试日志的方式(基本就是 '调试日志 -> 打包测试' 循环)还是快了不少(从定位问题的整体周期来看),最终发现问题还是出在了 Actor 生成的环节上 :
原来,实际的 Actor 生成流程比我脑补的要复杂不少,之前我一直以为是蓝图上的 ChildActorComponent 组件负责完成了 Actor 生成功能(最多加一些在服务器上不创建装饰类 Actor 的逻辑),但实际上,蓝图上的 ChildActorComponent 组件只充当了配置作用,实际的生成是服务器通过额外代码完成,其中做了很多自定义的处理,总体流程大概是这样:
Generate Config
Effect Type
Other Type
Local Spawn
Server Spawn
BP(ChildActorComponent)
Spawn Logic
Sync To Client
Server Spawn Logic
Functional Actor
知道了原因,之前提到的很多问题也就可以解释和修正了,只是如何修正 Bug 从来都不是最重要的,如何'预防' Bug 才是.
在此我们暂且不去讨论上述生成 Actor 的实现方式是否正确,仅仅就着 Bug 起因来说一下,很显然,问题的原因还是出在流程接口没有对齐上,简单来说就是缺乏串联沟通,之前我们为了赶工期之类的原因而忽略了这部分的成本,但最终我们还是逃不脱为此支付代价的命运 ...