今年我有幸在现场经历了所有的工程师访谈，两场综合访谈，一场魔兽世界，都是QA性质。
因为都在三楼的副会场，所以在楼下主会场忙碌的媒体往往不会顾及这里，感觉不分享出来可能就没人分享了。
我主要是节选了个人觉得很有趣的内容，如果mmo出了完整的文字稿会视情况添加更多内容，若有出入还请谅解。
主要感受就是相比去年第一次弄的小型工程师访谈，今年2+1三场要豪华了很多，但是废话也多了很多。
第二日
Q：星际和风暴使用的技术为何如此相似？
A：星际的引擎一开始就是个面向数据的引擎，因此很适合开发不同风格的地图模式。风暴的雏形-暴雪全明星的起源就是一个星际组员工的闲暇项目。然后大家被吸引了，为此专门分了个小组，代码库也专门开了一个分支，但是有许多功能性代码依然是通用并且同步更新的。风暴目前也是类似的状态，即使看起来风格已经大不一样，但是背地里他们依然有很多代码是共享的，还有专门的GUI工具来转移需要共享的代码。
Q：WoW的数据真的很多，你们是怎么维护的？
A：讲真，真的很多。光是7.1的更新就导致了超过1000个表的更新，尤其是法术相关的表。有一个内部表格有超过两亿五千万行数据，有的时候想查这个表找些东西真是挺不容易的。内部开发的统一工具-WoW Editor经常要和数据库交互，操作起来会让人觉得WoW是这个数据库的图形化管理工具，而不是一个单独的游戏。
德拉诺的时候，他们引入了NGDP数据传输系统，在设计这个系统时，他们需要生成目前游戏里每一个文件的列表(内部文件，而非文件夹下的那种压缩大文件)，光是为了做这个文件追踪系统就花了2年。新系统允许他们对于非常细微的内容进行改动(比如单个文件)，也让HotFix的灵活性大大提高了。
Q：暗黑工程师要怎么解决大秘境fishing(就是看到大秘境地图不好或者怪物刷新不好就放弃)的问题？
A：这个问题有两个方面。他们首先检查了怪物的刷新机制。每个怪物对于进度的贡献取决于怪物的基础经验值，所以当前基于个数/区域密度的刷新系统是有很多问题的。新的系统会基于经验值密度，即保证每个区域里刷新的怪物的总体经验值，即对进度的贡献是近似的。
然而还有一个问题就是精英怪必须单独考虑。比如我们可以在一个区域刷很多的小骷髅，但是精英骷髅不可能也刷很多组(因为词缀导致的难度并不好预测)，所以玩家如果看到这种情况依然会想离开。解决办法就是把精英怪的刷新独立在普通怪的刷新之外。这些修改在下周的PTR里就能体验到。
Q：守望引擎的优化？
A：守望使用了全新的引擎。从一开始，工程师就把所有平台都纳入了考量。游戏开发后期的工作主要都是引擎优化，使用了各种性能分析工具来评估CPU和GPU的表现。GPU的优化相对比较难，比如工程师有一次花了一天想去优化一个玻璃着色引擎，结果到最后一点提升都没有，因为GPU的调度器非常复杂，难以预测。
一个比较成功的功能就是渲染级别，尤其是主机上的动态渲染级别，能够根据场景复杂度实时调整，最终达到比较稳定的60fps。
Q：暴雪动画部门都怎么做那些渲染的？
A：动画渲染一直都是个很复杂的工作。在星际2的第一个CG里，泰凯斯所处的场景所使用的三角形，比当时整个wow所使用的三角形都要多。一开始动画部门只有15-20人，后来慢慢地涨到了200多人。人多之后，可以有更多的人去负责专属的内容，比如动画师，比如粒子渲染，比如光照效果。
但是人多之后一个问题就是协作。某个部门发现的bug，可能要回溯到整条流水线上好几个部门之前才能找到解决方案，这样的流程是非常繁杂低效的。他们为此开发了一个工具叫做Aurora，把所有动画部门的数据集中到一起，并且提供了一个统一的交互接口。它本身底层是个C艹的属性管理系统，叠加了一层Python来整合商业以及部门结构的逻辑。夺魂之镰的CG就是这个系统管理之下的产物，效果很不错。
Q：如何解决科技债(即早期的开发没有预见性，导致后面开发越来越难)？
A：写个条子标记这是一个科技债，然后丢到一边忘记它！
好吧，认真说。很多时候设计师请求的东西，过几个月很可能就不需要了，同样的有的时候设计好的代码，可能要过很久才会得到利用。比如要塞相关的代码，在4.3末期就已经写好了，但是一直没找到使用的机会。因此只能说尽量提高设计的灵活性来预防。
另外一方面，对于内部代码的优化，往往不会被其他部门的人所感知，算是low-impact的项目，因此并不会作为重点目标。目前在做的一个就是在代码提交过程中使用了各种代码质量检查的工具，每次代码提交你都会看到整体质量下降或者上升了多少，然后督促码农去尽可能提高自己的代码质量。
回到条子上，他们的确花了很多时间去修复各种条子，也就是表单所反馈的因为老代码导致的问题。
Q：有没有什么我们不知道的严重bug是发布之后才发现的？
A：有也不告诉你(笑)。只能说他们为了避免这些问题进行了各种努力。Hotfix系统的进化，更简单的代码逻辑，复杂的QA测试流程，更灵活的发布日程，数据库级别的质量控制(避免奇怪格式的数据的插入)，自动化等等。比如守望的一个自动化办法就是生成大量机器人(堡垒！)去地图里的每一个角落用一切可能的方式和地图疯狂地互动。
Q：聊聊服务器的架构？
A：他们有在密切关注类似Docker这一类比较新的解决方案。目前是混合云，由他们内部的私有云和AWS组成。AWS主要是为了美国以外的用户服务，提供数据传输一类的服务。最近也在开始尝试一些整合了AI的软件缺陷检测方案。
设计哲学来说的话，一开始各个大组(魔兽，战网，星际等)之间基本没有沟通，都是各自为战。几年前新的CTO提出了”One Blizzard“这个概念，强调了各个组之间的原生态协作，结果就是本来很多难解的问题和其他组沟通之后迎刃而解。比如风暴组提出来的新文件系统CASC现在已经推广到了所有游戏上。
Q：你们都是如何提升游戏表现(fps)的？
A：守望有用各种内部和外部的性能评估工具，检测各种参数，比如cpu/线程的利用状态，内存的使用效率等等。
这里还有一个轶事。美工开发模型的时候，都是以实际大小为准。比如一个石头消耗几百个多边形的话，一个高山可能就是几十万个多边形了。有一次某个QA在测试新场景的fps时，发现在一个桌子附近fps总会暴降，完全不知道为啥。最后他们发现那个桌子上的一个盆栽的树居然有数以万计的多边形：某个美工把一个海加尔树那么大的大树缩小了几百倍直接放到了盆栽里。结果引擎依然认为它需要把这十来万的多边形都渲染在这个小小的盆里，你懂的，可费劲儿了。
Q：星际的观战模式？
A：星际的服务器是状态锁定+同步的模型。服务器和客户端时刻交换大量的最新命令，以此模拟/同步最新的游戏状态。观战者想要看到最新状态，就需要拿到游戏开始到现在的所有命令并且模拟最新状态，只能说这里面有很多挑战。
Q：WoW的数据是怎么存储和分析的？
A：魔兽一开始的文件系统叫做Big File Folder(谷歌的GFS的梗)，用不同的文件夹来存放不同的数据内容。为了不用每次都复制大量重复内容才能更新游戏，他们特地开发了专门的文件夹管理系统。目前是内容关联的文件追踪系统，存放了对应到内容的哈希值。在发布新内容时，这个系统让数据索引时间得到了大幅度的降低。数据库系统也是内部开发的工具。
游戏的统计数据定期会发送给BI(商业智能)团队，并且定期地得到分析团队的结果。开发者们就可以用这些分析来辅助决策。
Q：哪个方向的team人最多？？
A：WOW组最多的人是gameplay组(游戏机制)，这个组需要开发大量的游戏内部的新功能，每一个都需要可观的开发投入。战网也是个人很多的组，因为维护面向几千万玩家的平台和大量功能。守望里人最多的组也是gameplay组。
Q：工程师部门的性别比例？？
A：80%男性，20%女性，目前的目标之一就是招到更多女工程师。
Q：给学生党一些进玻璃渣的经验？
A：保证课业的基础上，尽可能完成一些独立的项目(不过没人指望你solo个魔兽)，是真真正正地完成一个项目，哪怕是俄罗斯方块也好。这个过程中需要的代码设计，系统设计，测试，debug能力都是暴雪所看重的。Unity相关的经验也是非常好的。
第一日
魔兽世界从一开始就有使用大量的隐形追踪目标来辅助触发各种事件。[隐形小兔子]就是一个著名的例子。比如在早期的远古海滩，战场的开始并不是你看到的倒计时。而是船上以及码头各自放置了一个隐形的对立npc，他们接近彼此后会开始读条攻击对方，以此来开始战场。类似的还有奥拉基尔的身边有几百个隐形漩涡，一旦玩家撞进其中一个，就会触发一些相关事件。随着代码的改进，工程师们会尽可能不去使用这些有风险的手段，但是时至今日也依然有很多机制是依靠隐形追踪目标来触发的。
军团再临开服之前，设计师说为什么不通过一个酷炫的任务然后啪地一下把玩家传送到破碎群岛呢。结果工程师在各种实验之后发现现有的服务器模型无法承担，进而开发了新的动态切片技术来实时调整各个服务器的均衡能力。结果便是史上最顺滑的开服体验。
背包的问题在去年已经有过类似回答。2016年的今天，默认背包系统最大的问题依然是如何保证各种写死的逻辑能够适应到新版本的代码，然后有这些时间一整个新补丁都做好了，想想还是算了吧。
在你的人物被跨服时，客户端会访问服务器重新请求一批应该显示在你视野里的目标，并且取消之前的显示目标。但是在最新地图上使用这种技术依然出现了很多不同步的状况，导致你的跨服体验不是很好，这一部分依然在优化。
同样的，在德拉诺开服时，出现了很多副本未找到的问题。这是因为负载均衡逻辑没有分配足够的服务器给你所属的副本群，而且你所在的副本群恰好最近不是负载很高的类型。他们在优化了负载均衡逻辑之后问题就少很多了。
Hotfix能做到的事情与日俱增是他们的目标之一。即使现在已经可以用hotfix来增加新天赋也没有到他们满意的程度。最终的目标是让所有的非静态资源都能通过hotfix来进行修改。
水上坐骑有时无法工作是和碰撞模型有关的，尤其是玩家从水下移动到水面的过程。本来的碰撞模型非常粗糙，所以会出现侏儒明明在浮着却消耗氧气条，或者是人在猛犸坐骑上被认定是浮空这样的问题。为了应对这些，玩家在坐骑上的碰撞模型并不是简单的玩家模型+坐骑模型+一定位移，而是有一套算法在计算最终的碰撞模型来触发环境效果。这个目前依然不够完善。
早期的反外挂系统之一是不断检测客户端告诉服务器的玩家移动速度，以及玩家实际的坐标变动。如果两者差距过大，服务器就会认为这个玩家在非法状态，并且尝试把他重新定位到合理的位置。然而这个系统却经常把合法的玩家重置到奇怪的地方，更麻烦的是要debug这个非常麻烦因为难以知道玩家在什么状态下触发了这个bug。
之前有玩家问为什么不用神器能量或者其他奖励代替目前的安慰奖金币，[蓝贴回复]说是因为目前的roll系统是mop时代做的，只能从boss的掉落表或者金币里选择一个。然而工程师表示这个并没有技术门槛，而是设计师觉得”不可行“。类似的”不可行“的事还有不少，但是往往群众会先怀疑程序员，而不是设计师。注：设计师在最近的访谈里已经表示这种安慰奖只是侮辱人，会进行修改。
炉石的卡牌逻辑都是在服务器端，客户端做的只是请求服务器下一步应该显示什么样的结果。因此对于卡牌的修改是非常方便的，比如产生随机法术这种逻辑，在服务器那边也不会需要用很复杂的脚本就能写出来。
炉石服务器端的脚本语言最近被用C艹重构过一次，并不是为了运行效率，而是为了降低使用的复杂度。
炉石早期的移动开发人员本来都不是游戏开发，而是其他组的各种移动应用和服务开发人员组成的。
守望先锋里判断玩家的战斗力并且寻找队友的逻辑，一开始只是很简单看你的击杀，然后为了照顾其他类型的英雄增加了越来越多的逻辑。一开始也只是很简单的快照值，并不是总看你的动态表现，但是慢慢也在改善。
blizzcon的售票系统牵扯到了很多分布式系统设计的挑战(分布式消息队列，公平性，负载均衡等)，最后的解决方案反而非常简单粗暴。服务器只维护当前剩余票数和当前在购买页面的人数这两个值的一致性，同一时间里只有一小部分用户可以真的访问购买页面，其他人都只能转圈。(然而如何公平地选择这一批用户，似乎他们并没有很好地解决)
暴雪的程序员对于一些细微内容的添加与否有很大的影响力。比如他们可以觉得某个角色很coooool，反馈给设计师，然后设计师很可能就会说”为什么不加进去试试呢？”。当然不太合理的请求还是会被设计师拒绝的。
译者：墮落的猴子
