暴雪游戏开发趣闻：工程师绝不轻易说“NO”

GameRes​游资网授权发布 文 /顾露

暴雪，对无数游戏开发者来说是一个可以“朝圣”的地方，暴雪出品的游戏让全球的千万粉丝翘首以盼。暴雪游戏是怎么开发出来了？估计很多人都很好奇。

这是​Blizzcon 2015 Engineer​ing Community Amphithe​ater Discussi​on​的部分内容，挑了重点，简单记录了一下。

设计和工程

风暴英雄的数据驱动做得很好 (因此设计自由度很大)。在这样灵活度的支持下，设计师在 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 document​ation) 比如有 17 个名叫 teleport 的各不相同的函数用来传送~~ 对写插件的人来说挺痛的对吧，对内部开发者更痛。

暴雪的绝大多数团队都是做 Code Review 的，而且积极使用现代的 C++ 特性来改善代码的可读性，尤其是考虑到暴雪产品的超长生命期。

如果对同一个问题有一个快速方案和一个正确方案，团队往往会选择后者 (即使会花更多的时间) 回头修那些设计糟糕的系统非常痛苦。

是努力尝试理解当前的逻辑，还是试着重写那些“看起来有点乱”的逻辑，这经常会是一个问题。一个好的标准是，即使是老代码，只要有清晰并明确定义的方式去扩展，那么就是“好的”代码，不必大动干戈。

常用的方案往往过于通用，不总是能解决暴雪在开发游戏时面对的问题。暴雪的团队总是会试着跳出给定工具的限制，限制他们的往往是他们自己的设计。

最初的 WOW 开发者在背包里用了数组，数组的起始部分是装备，接着是背包里的道具，再后面是后来加的银行。这些不同的数据的位置通过一系列算术运算来定位，而且相关的代码充满了硬编码。这些情况最直接的后果是背包没法很方便地扩充。大伙都忙着做功能，到后来已经修不动了。这就是固定尺寸背包的由来。

VTune 和一些内部工具被用于性能分析。性能回归是自动化的：比如“在某个地图放上 10 个英雄混战”，每个成功的 build 之后都自动运行并比较性能情况，这样性能上一旦有啥异动能第一时间捕获。做优化时，重要的是取舍：优化的能力，时间，可维护性，优化后新增的限制等等。大量的优化时间被用于与美术沟通，简化碰撞体。

Battle.​Net 以一致的方式 (最小公分母) 对待所有暴雪的游戏。比如如果战网决定增加好友数量，需要所有的游戏都打好对应的补丁，支持新的数量之后才能进行

已经在运营的游戏有大量的静态数据，所以补丁和更新往往意味着多地间大量的数据复制。使用 live test 确保基本的正常。服务器组需要以特定的顺序开启和关闭，尤其是 WOW / Battle.​Net (他们的部署体系更古老一些)

项目和资源管理

• 守望先锋团队使用 Perforce 管理代码和资源
• Battle.​net 使用 Git/​Jenkins
• WOW 服务器团队使用 SVN (但正在逐步迁移到 Git)
• Team 1 使用 Git/​Perforce/​Jenkins
  

(暴雪的团队代号)

• Team 1 - SC2 and Heroes
• Team 2 - WoW
• Team 3 - Diablo
• Team 4 - Overwatch
• Team 5 - Hearthst​one
  

WOW 团队主体没有使用太多的敏捷开发，但一些小团队正在开始做 scrum。暴雪不太在意一致性，在项目管理上团队都有自己的自由度。

其它

WOW 团队正在研究 DX12 等新技术，不过现阶段还没啥好说的。

在暴雪有很多人体验 VR，但他们更关心精彩的点子，而不是只想着堆一摞高科技。

所有的团队都在往移动上靠，炉石之后更是如此。玩家在移动设备上玩的呼声很高，团队内部也是如此。

(对应聘者) 有一个完整的游戏项目经验，对你的简历无疑具有很高的价值。对学习本身的热情和技能多样性同样很重要。

相关阅读：丧失游戏市场控制力 暴雪是如何走下王座的