游戏开发团队并非蚂蚁协作（随记）：在各种“外部攻击”下保护自己的工具

0. 接手工具

在我加入项目的早期，我接手了一个工具，这个工具做的事情很简单：
对于一个模型资源，比如说一个树资源，从多个角度拍摄出图片保存下来。

熟悉相关技术的同学肯定知道这个叫“Billboards”，这个可以作为模型的最末级LOD。这样，在模型距离很远时，原先复杂的几何体网格就可以替换为只有一面的图片，这样就以相对低廉的渲染成本达到在这样远距离下与原始模型不会相差太多的效果。

这个Billboards工具并没有牵扯什么高深的技术，完全是一些简单逻辑的组合：创建模型，设置相机，拍摄并保存图片，外加应对边界情况的一些处理。我费了几天的时间完全研究透彻了工具逻辑，并且修了其中的BUG并做了一些优化。虽然中间有波折，但是最后还是顺利收工，美术得以继续使用工具。

可当时我并没有意识到，那并不是“收工”，而是“开始”。因为我已经变成了这个工具的“维护者”。这不仅意味着对于这个工具的新的需求我要做，还意味着另外一种情况：有可能你最近没有对工具有任何相关的改动，但是工具就是突然坏了，这时候你只能从头开始调查。我将这种情况视为“外部攻击”，尽管攻击者肯定不是故意的。

这种被“外部攻击”的情况其实相当常见，绝不仅发生在我今天聊的这个工具上。只是因为最近这个工具时隔多日又出现了问题，才让我有想法翻一翻我的聊天记录，回顾下这个工具到底遭受到过多少次的“外部攻击”。

攻击1. 部分树的图片拍摄不完全

美术反映：有一些树拍摄的图片正常，但是有些树，拍出的图片显示不完整，看起来树的有部分超出了画面范围。

经过调查，这些有异常的树，其实是包围盒设置的不正确——包围盒没有包围住实际的模型。而工具在放置用于拍摄的模型的时候是通过包围盒数据来计算的，这样最后拍出的树就会有部分超出了拍摄范围。

这次攻击，可以说是源于美术资产的不规范，但自此之后美术已经会留意包围盒设置了，所以也没有再发生过类似的事情。

攻击2. 拍摄出来的树叶受风场影响

美术反映：他们发现最近拍出来的树叶都受风场影响出现了偏移。

而解决方式就是在工具中配合材质做些处理，让工具在拍摄图片的时候关闭风场效果。

这次攻击，来源于做风场效果的同学并未考虑这个树还会拍Billboard图片。但是，这也很难在一开始就考虑到，毕竟项目中的模块众多，没有人能了解所有不属于自己的模块的。

值得一提的是，风场效果对Billboard工具的“攻击”在之后还有一次。应该是风场的实现方式当时又变化了。

攻击3. 应对变色功能

美术反映：现在树叶新增加了变色功能，即增加了用于额外控制树叶颜色的参数到树叶材质中，但是这个变色参数在Billboard工具中无法生效。

这个问题不好解决，因为工具在放置模型的时候，所用的组件就不支持变色参数。 我不得不对工具进行了不小程度的修改，改变了组件以及相应的接口，并加入了对变色功能的考虑。

攻击4. 应对自发光功能

美术反映：对于一些新的拥有自发光效果的树，工具拍出的图片相比原始模型来说暗了很多。

经过调查，自发光通道的数据确实没有在工具拍图的时候加入计算，最终我修改了工具拍图相关渲染的shader来解决。

攻击5. 拍图崩溃

美术反映：最近一使用工具拍图就会触发崩溃。

我通过崩溃堆栈，找到了相关的程序员。这位程序对这个堆栈也很诧异，因为正常情况不会出现这个问题。但可能是Billboard工具拍摄时候的渲染流程不同于正常渲染流程，所以才暴露出问题。最后通过加强代码的安全性来解决了。

攻击6. 拍出来没有数据

美术反映：最近几个月都没用这个工具，但是今天发现这个工具已经拍不出来数据了。

我调查发现，之前为了应对变色功能，我将工具所用的模型组件换了一个，而现在这个组件也失效了，必须要用这个组件的“变种”，用编程术语来说是这个“基类”组件的“子类”组件。而且，这个基类组件不是只在BillBoard工具中失效，而是在任何情况下都会失效。

一般来说，“子类”都比“基类”拓展了某些方面的能力，也有更多引入问题的可能，所以不太会出现“基类”是坏的，反而“子类”是好的。所以现在的情况毫无疑问是个异常问题。但可惜，我了解后发现这个问题出现已经很久了，只是因为目前在我们项目中除了BillBoard工具外已经没有地方使用这个“基类”，所以才没人想去修它。现在过了这么久，要追查从哪次提交开始变坏的犹如大海捞针，要查只能从渲染底层上开始查，而在当前我们项目这样紧凑的开发环境下，这种没有引起实际问题的错误显然不会有人发起修复。

因此，我只能被迫将BillBoard工具中的组件也换成了这个“子类”组件。而这又引发了一些新的问题，我也只能继续解决。

感想

其实上面的攻击并非是所有的，其他的要么是影响比较小，要么是聊天记录没有找全所以忘记了当时的情况，总之都没有留下太深印象，所以就不提了。

我感到，在这样一个大型团队中，我们每个人的开发都和其他人的开发紧密相连。就拿我维护的这个BillBoard工具来说，虽然这个工具里的逻辑我都清楚，然而要让这个工具成功运行起来，所牵扯到的逻辑是由很多其他人维护的：

• 工具运行在引擎编辑器中，而引擎编辑器是由大家维护的。
• 工具拍图时用的渲染逻辑，是由一批专业的渲染程序员维护的。
• 工具拍图的对象，每个树资源，模型是由美术维护的，材质是由TA维护的。

由于项目中每个人的开发大多都和别人有关联，所以这种受到“外部攻击”的情况十分常见。大家在碰到这种情况时都很苦恼，但是要想杜绝这种情况恐怕很难。