转载

暴雪游戏开发趣闻 (若干则)

这是 (Youtube) Blizzcon 2015 Engineering Community Amphitheater Discussion 的部分内容。挑了重点，简单记录了一下。

设计和工程

风暴英雄的数据驱动做得很好 (因此设计自由度很大)。在这样灵活度的支持下，设计师在 Blizzcon 上想搞个大新闻：两个不同的玩家可以控制同一个英雄。程序员们一听都慌了，后来想了想，搞定了。
工程师们不会随便说“这不行”，要想让设计师们尽情发挥就不该随便说 No ——尤其是你要是不给弄，设计师们分分钟自给自足把自己的需求给实现了(掩面)。有张图 (此处应有图) 上画的是，一个垃圾桶上放了个插着电的熨斗，熨斗上放了咖啡壶，咖啡壶里装着意大利面。duang, 搞定，意大利面做成了~
守望先锋有 “strike team” 内含来自不同部门的 n 个人 (Gameplay/Engine/Designer/Animator/FX Artist) 在一起配合完成一个功能 (通常是某个特定的英雄，如 Hanzo) 这些人一起配合，把一个特性打造到极致。(下一条紧接着说的是 —— 即使这样，D.Va 还是很难搞，花了 n 个月 —— There are two types of heroes in Overwatch: D.Va and not D.Va.)

从工程师的角度，寻找并解决设计师的痛点很重要 (就像产品经理找用户的痛点那样) 要是设计师随便开个对话框都有 128 个复选框等着他们的话，根本就不会有啥好心情去为玩家创造优质体验了。所以工程师需要尽可能地把无关的细节隐藏起来。
工程师和设计师的目标是互补的：设计师的目标是“让尽可能多的玩家获得最好的体验”，工程师的目标是“尽量不要让任何人有糟糕的体验” (这两个互补的目标能够让他们考虑和覆盖尽可能多的边界情况，带来更好的体验)
解决设计问题的时候，他们考虑的最多的不是解决方案，而是对玩家实际体验的影响。

对 WOW 的服务器团队来说，如果开源代码能解决问题的话，他们会用的。在客户端的声明中能看到大量被使用的开源许可证。他们倾向于不要重复造轮子。
服务器上的 Lua 引擎在经年累月的各种新增需求轮番轰炸下已经有点不堪重负了 (worse than not having documentation) 比如有 17 个名叫 teleport 的各不相同的函数用来传送~~ 对写插件的人来说挺痛的对吧，对内部开发者更痛。

暴雪的绝大多数团队都是做 Code Review 的，而且积极使用现代的 C++ 特性来改善代码的可读性，尤其是考虑到暴雪产品的超长生命期。
如果对同一个问题有一个快速方案和一个正确方案，团队往往会选择后者 (即使会花更多的时间) 回头修那些设计糟糕的系统非常痛苦。
是努力尝试理解当前的逻辑，还是试着重写那些“看起来有点乱”的逻辑，这经常会是一个问题。一个好的标准是，即使是老代码，只要有清晰并明确定义的方式去扩展，那么就是“好的”代码，不必大动干戈。
常用的方案往往过于通用，不总是能解决暴雪在开发游戏时面对的问题。暴雪的团队总是会试着跳出给定工具的限制，限制他们的往往是他们自己的设计。

最初的 WOW 开发者在背包里用了数组，数组的起始部分是装备，接着是背包里的道具，再后面是后来加的银行。这些不同的数据的位置通过一系列算术运算来定位，而且相关的代码充满了硬编码。这些情况最直接的后果是背包没法很方便地扩充。大伙都忙着做功能，到后来已经修不动了。这就是固定尺寸背包的由来。
VTune 和一些内部工具被用于性能分析。性能回归是自动化的：比如“在某个地图放上 10 个英雄混战”，每个成功的 build 之后都自动运行并比较性能情况，这样性能上一旦有啥异动能第一时间捕获。做优化时，重要的是取舍：优化的能力，时间，可维护性，优化后新增的限制等等。大量的优化时间被用于与美术沟通，简化碰撞体。

Battle.Net 以一致的方式 (最小公分母) 对待所有暴雪的游戏。比如如果战网决定增加好友数量，需要所有的游戏都打好对应的补丁，支持新的数量之后才能进行
已经在运营的游戏有大量的静态数据，所以补丁和更新往往意味着多地间大量的数据复制。使用 live test 确保基本的正常。服务器组需要以特定的顺序开启和关闭，尤其是 WOW / Battle.Net (他们的部署体系更古老一些)