这是 (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 (他们的部署体系更古老一些)

项目和资源管理

  • 守望先锋团队使用 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,但他们更关心精彩的点子,而不是只想着堆一摞高科技。
  • 所有的团队都在往移动上靠,炉石之后更是如此。玩家在移动设备上玩的呼声很高,团队内部也是如此。
  • (对应聘者) 有一个完整的游戏项目经验,对你的简历无疑具有很高的价值。对学习本身的热情和技能多样性同样很重要。

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


Gu Lu
[2016-07-03]


Comments
Write a Comment

Tags

随笔   游戏开发   Programming   C/C++   优化   Unity   C++   知乎   游戏设计   比特币   Unity3D   区块链   软件开发   Bitcoin   引擎设计   系统架构   Production   idtech   中国文化   加密货币   项目管理   游戏评论   资源管理   资源流水线   效率   道德经   网络   方法论   模板编程   Blockchain   Lua   Blockchain Computing   Oculus   GDC   渲染   VR   PerfAssist   Unity MemoryProfiler   BCH   经济学   信息过载   行业报告   字体   Productivity   图形   网络编程   Dice   协程   EMC   Premake   测试   中间件   Game Engine   新手引导   区块链游戏   Methodology   CI   命令行解析   goroutine   ndk   Ethereum   nanomsg   自动化   Scripting   摘录   Debugging   同步技术   cppcon   C++模板   DOOM3   技术评估   Unity GC   C++11   学习方法   Surface Pro 3   Engine Evaluation   CRT   文化   笔记   golang   图形编程   多线程   ETH   Bitcoin Cash   cppcon14   Bitcoin SV   Visual Studio   Unity Coroutine   跨语言可变参数列表   团队协作   货币   Deployment   Visual Assist   工程改进   Michael Abrash   exp   开放世界   量子计算   域名   虚拟现实   系统重构   slua   遮挡剔除   完美转发   协作式调度   Modern C++   类型推导   Memory Debugging   个人成长   小故事   BTC   暴雪   产品   历史   错误处理   Unity Profiler   MOD  

知识共享许可协议
本作品由Gu Lu创作,采用知识共享Attribution-NonCommercial-NoDerivatives 4.0 国际许可协议进行许可。