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

这是 (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.)

2016-07-03-blizzard

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

编码和优化

  • 对 WOW 的服务器团队来说,如果开源代码能解决问题的话,他们会用的。在客户端的声明中能看到大量被使用的开源许可证。他们倾向于不要重复造轮子。
  • 服务器上的 Lua 引擎在经年累月的各种新增需求轮番轰炸下已经有点不堪重负了 (worse than not having documentation) 比如有 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 – Hearthstone
  • WOW 团队主体没有使用太多的敏捷开发,但一些小团队正在开始做 scrum。暴雪不太在意一致性,在项目管理上团队都有自己的自由度。

其它

  • WOW 团队正在研究 DX12 等新技术,不过现阶段还没啥好说的。
  • 在暴雪有很多人体验 VR,但他们更关心精彩的点子,而不是只想着堆一摞高科技。
  • 所有的团队都在往移动上靠,炉石之后更是如此。玩家在移动设备上玩的呼声很高,团队内部也是如此。
  • (对应聘者) 有一个完整的游戏项目经验,对你的简历无疑具有很高的价值。对学习本身的热情和技能多样性同样很重要。

只是稍做了整理,看起来仍有点乱,见谅。

[完]

本文文字及图片出自 gulu-dev.com

余下全文(1/3)
分享这篇文章:

请关注我们:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注