理解设计师们的压力所在，并且帮助他们解决这些压力是非常关键的。比如你让一个设计师对着有128个选项的对话框，他们就会忘记本来想设计的那些酷炫玩意儿，然后开始纠结LEAVE_WORLD_CANCELS和ENTER_WORD_CANCELS两者有什么区别这种鬼东西。(如果玩家不在“世界”，他们到底跑哪里去了?)
守望先锋组的组成非常有趣，一大群不同背景和分工的人聚到一起来制作新的内容。通常这都是指一个新英雄。制作半藏的小组就包含了一个游戏性工程师，引擎程序猿，设计师，动画师还有特效美工。当然还有总是很忙碌的音声部门。大家一起努力做出最好的游戏体验，互相提供反馈，然后小组一起提供反馈，最后从其他暴雪员工以及beta玩家那里得到更多反馈。这些都是通过让制作人员紧密合作才能达成的。
守望先锋有两类英雄，D.Va和其他。他们几个月之前开始设计她，完全没想到接下来几个月都花在了她身上。(程序bug频繁，详见下条)
工程师们觉得设计师迟早会想要一个你可以发射出去然后随意控制的火箭一样的东西，所以他们提前写好了相关的代码。狂鼠就是这些代码的应用结果(狂鼠的大是一个你可以控制方向的车轮)，实际游戏表现让他们觉得不用再改什么了。结果D.Va狠狠地打了他们的脸。各种bug接踵而至，比如你脱离机甲之后(自爆大招)，机甲还可以提供占点或者护送进度，或者朝着最后的方向持续移动。又比如你脱离机甲之后，镜头会被重置到(0,0,0)这个坐标，导致你什么都看不到。
工程师和设计师的目标是相辅相成的。设计师想让最多的玩家得到最棒的体验，工程师是保证没有人会得到糟糕的体验。这就需要去考虑所有可能的情况，让代码尽可能地去应对这些情况。
隐藏在线状态这个功能迟迟不来，也是因为老代码。想要让这个功能和游戏内容保持一致并不简单。技术上来说不难，但是比如说，你的朋友隐藏了在线状态但是他在游戏里就站在你前面的话?隐藏在线状态，对我们来说，应该说是“我想去偷偷撸一把D3，而不是和基友们去刷马桶”这样的东西，但是当你们都站在AH的时候。
制作组有用许多行业标准工具，比如VTune，也有一些内部开发的分析工具。他们写了很多自动测试，比如把10个英雄放在一个单线地图上对战，然后评估每个版本下英雄的表现。英雄修改是很频繁的，所以这个工具只是让你了解一个大概趋势，还有避免一些破坏性的错误。
守望先锋也用了类似的分析工具。
优化代码总是有各种各样的代价的。优化所需的知识，优化所需的时间，优化后代码的可维护性，还有解决方案所导致的工程师和内容组的额外限制。
工程师们在持续进行大量的优化，也包括比如和美工交流以减少碰撞判定复杂度这种方式。身体模型上并没有单纯的平面，所以需要很多优化来提高性能。
在解决一些设计问题的时候，他们会优先考虑要去创造的这个形象本身，而不是关注于解决方案。他们的思考重心是到底要提供一种怎样的游戏体验。
@kurtismcc说他以前高频交易公司干活的时候，在一个哈希函数上节省了120纳秒，把小伙伴们都吓坏了。这可是很屌的噢。
制作组花了很多时间来尝试用读取表格内的静态数据的办法提高4-5倍性能。然后他们在德拉诺上线时发现，想要在成千上万个副本里找到需要关闭的副本，必须得去一个链表(linked list)里逐个搜索(Java的GC?)。以前的某人觉得哈希表的做法太耗时，于是用了链表。(可能因为副本添加的操作非常频繁，哈希表的碰撞策略再好也会消耗很多时间)
工程师团队已经写了五六个分析工具来供不同小组使用。
暴雪一直都想让游戏的可玩状态更持久稳定(即减少维护或者离线时间)。工程设计对他们来说不是打开服务器拍拍屁股走人，而是尽可能得实现“三九”状态(就是99.9%时间在线，高可用)。他们内部一直在努力实现高可用，尤其是魔兽。但是当前在用的WoW架构是比较陈旧的，战网也有很多陈旧的架构。最近的一次更新里，他们以一小时patch为目标，最后美服花了1小时45分，欧服花了53分钟。接下来会越来越快，最终的目标是无离线/关机，类似hotfix那样直接hot-patch。
游戏里有很多重要的静态数据。所以补丁当天，这些数据只能以非常低效的方式搬运来搬运去。他们在尝试改善这个情况。维护的一大部分时间都是在低效地推送新代码，二进制文件以及数据到远程数据中心。然后他们还要做live测试(即在正式服上测试)，因为目前的内部测试环境并不能很好地模拟正式服。服务器的关闭和启动都有一定的顺序要求(联系到上面所说的不同服务器负责不同部分)。内部的测试环境会被用来测试尽可能多的内容，但是这些都要在正式服再做一遍，然后祈祷没有遗漏掉什么状况。
暴雪内部有很多VR(虚拟现实)的爱好者。不过设计的重点是好玩的游戏方式，而不是单纯加个酷炫的技术而没有配套的游戏内容。如果能有一个VR相关的好点子，他们一定会去尝试。如果VR能提升游戏的浸入式效果那就最棒了。
守望先锋组用Perforce在做版本控制，还有一个专门用于美术资源的版本控制软件。
战网的代码是用Git维护的，然后用Jenkins做集成。
WoW的服务器端代码用SVN维护，最近在考虑把代码复用率高的部分转移到Git上。
Team 1(星际组)用Git，Perforce和Jenkins。
UI组通常通过阅读源代码来理解函数的作用，偶尔也会用WowPedia来帮忙。服务器端的Lua代码有一些文档可读，客户端这边就少很多了。
服务器端的Lua引擎要比没文档更糟糕，因为它总在不停地主动添加一些新代码来给予设计师们更多灵活性。结果就是你面对着17个叫做teleport的函数，而不知道哪个才是你要的。如果插件开发者就会困惑的话，内部开发者只会更糟。
WoW组没有使用很多敏捷开发。有些小组在逐渐尝试这些。暴雪各组之间的一致性(开发方式)并不是很强。
WoW组早就意识到，一旦补丁或者数据跑到CDN上，就会被各种网站挖得一干二净。他们在讨论使用新的CDN系统时，考虑把所有的数据都加密起来，以保持神秘感。但是加密所有数据就会导致你无法直接patch，而是要去重新下载数据，于是这个完全加密的想法被弃用了。
暴雪游戏的量级经常会导致看起来人畜无害的决策后来反咬你一口。他们起先让玩家可以/who来查询在线玩家，结果玩家们的这个操作消耗了大量的服务器资源。实际上服务器85%的时间都花在了响应这个查询上，因为同时在线的玩家真的很多很多。这是一个典型的N平方问题(即处理单位加倍但是处理时间变成4倍，增长速度不是线性而是平方)。
Team 1 - 星际和风暴，Team 2 - WoW，Team 3 - 暗黑， Team 4 - 守望先锋， Team 5 -炉石。(注意守望的组号比炉石低，说明这个组的组建甚至在炉石之前，也就是前身Titan)
所有小组都想做更多移动端的东西。炉石的成功证明暴雪在移动端也很能打。很多人想要手机要塞，制作组有意识到，也想弄一个出来。
解决方案有廉价的也有正确的，然后他们尽可能追求正确的，哪怕耗时更久。你不希望之后再跑回来修修补补那些短平快的烂代码。(出现了好几次的话题。。。)
暴雪的大部分组都会做code review(代码审核)，并且利用C++的新特性来提高代码的可读性。可读性和可维护性式目前开发的重点(言下之意以前的代码。。。)。产品的寿命都会很长，所以这两者非常重要(言下之意当年就没想到。。。)。
守望先锋的beta测试玩家来自各种各样地区。这让工程师们可以观察不同网络环境下的程序表现。blzcon上有一名来自智利的玩家，他说在智利玩守望的体验很不错。工程师们甚至尝试过用手机信号来玩，还挺不错的。
周末beta活动很适合用来撑爆服务器并且发现隐藏bug。D3的周末beta让我们发现了一个bug，会导致大量新游戏开启请求都发给某一个刚从崩溃中复原的服务器，因为系统认为这个服务器目前没有负载(实际上是有的)。
如果开源技术能解决问题的话，他们就会积极去使用。没有必要重新造**。所以在法律相关文档里你能看到很多开源**的内容。
当然，现有的**未必都是好用的**。他们经常会碰到现有技术无法很好解决的问题。此时他们都更倾向于开发出自己的技术以及适应这些技术导致的限制，而不是去适应别人的技术所导致的限制。
