暴雪正在从技术角度深入研究如何创建第二次安其拉开门系列活动。 他们研究了一些历史，第一个是从以前的香草版本中学到了什么，他们如何使用自动工具和压力测试来使第二个版本（重现）尽可能地正常工作，这是经典/原始代码本身的局限性， 大门的最初打开，以及GM如何跟随他们生活并即时实施解决方案，还有更多！


如果你对幕后工作有点兴趣的话，那你就可以看看魔兽世界历史上最大的事件之一，以及它是如何改进和处理的。



与我们一起在幕后进行深入探究，以重现《魔兽世界》最具标志性的事件之一，即安其拉开门事件。

 

安其拉在我们（幕后）这边的情况。本月早些时候，魔兽世界怀旧服中最令人期待的事件之一就是实况直播-安其拉战争努力。整个怀旧服服务器-部落和联盟的强强联合-聚集在一起，贡献了资源来打开大门并解锁安其拉团队副本。当“流沙之战”于2006年首次（也是唯一一次）发生时，来自每个服务器的成千上万的玩家将其飞过或骑马到希利苏斯参加或目睹了混乱。参与人数超出了开发团队的想象，简单地说，我们还没有做好准备。服务器很快变得超载，许多玩家陷入了（无法）登录的情况，断开连接并试图在12小时内重新上线的循环中，而我们的工程师则忙于解决修补程序问题并使玩家重新连接。在活动期间我们确实设法稳定了服务器，并吸取了很多教训，但我们看到了做得更好的机会。十五年后，我们准备通过专注于服务器优化以消除延迟并消除服务器崩溃来为《魔兽世界》重现魔兽世界史上最史诗般的时刻之一，同时在希利苏斯托管的玩家数量是上一届的两倍。该活动于2006年首次亮相。


在本文中，我们将介绍如何使用自动工具和压力测试来确定断点和手工优化解决方案，以及如何在软件中提出解决方案，从而重新创建这个备受期待的事件硬件无法解决的问题，以及我们如何在服务器崩溃次数有限的情况下策划全球性事件，同时保留了原版魔兽世界怀旧服的游戏体验。


再现流沙的第二次战争


在接近如何设计此事件的方式时，我们牢记三个具体目标：防止连接崩溃，增加预期的区域玩家限制，并确定在将玩家移动到希利苏斯之外之前可以容忍多少延迟。在深入了解如何实现服务器性能最大化之前，必须了解我们正在处理的约束：魔兽世界怀旧服代码库的局限性，人口管理解决方案的工作方式以及它们如何影响游戏玩法。


阿努比萨斯入侵艾泽拉斯

超出了界限


现版本的《魔兽世界》建立在15年前发布的原始代码库的基础上。自游戏发布以来，我们已经开发出了更现代的方式来处理艾泽拉斯战役中的大量玩家，尤其是分层。分层使魔兽的服务器可以容纳比2006年更多的游戏玩家。在艾泽拉斯战役中，一旦玩家人数达到上限，我们就通过复制区域（例如赞达拉）来使用它们来管理服务器的玩家负载一定的门槛。这可以通过在区域的不同版本中分散玩家来消除延迟问题，因为玩家不断地向服务器发送大量数据包以准确确定其动作和拼写，因此玩家互动是CPU占用最大的时间。


此外，分层可缓解过渡到玩家人数超过阈值的新区域时可能遇到的潜在延迟卡顿问题。听起来很简单，但有一个要注意的地方：魔兽世界怀旧服经过精心设计，可以忠实地重现原始的1.12游戏数据，其中包括保留其游戏玩法。


在极少数情况下，分层会导致你的猎物，例如一个敌方玩家或NPC，在进入一个新的区域时消失。保留分层将意味着失去那些追逐玩家和npc跨越区域边界的怀旧游戏时光。因此，现在我们需要提出一种不干扰原始游戏玩法的解决方案，同时还允许我们在服务器上吸引更多玩家，而不会迫使玩家遭受无法玩的延迟。


为了解决这个问题，我们选择使用分层（整个区域（例如东部王国）的副本）来管理玩家人数和延迟问题，这样玩家就可以再一次跨区域风筝世界BOSS，并在一个区域内跨越边界追追敌玩家，而不会有被重新分配到一个区域的风险不同的分层。


但是，将分层设计为非永久解决方案。因为最初的1.12版本既没有使用分片技术也没有使用分层技术，所以我们向玩家承诺，我们只会在魔兽世界怀旧服发布时使用分层，并随着时间的推移逐步淘汰，因为它们在世界各地的分布更加均匀。在一些情况下，由于活跃玩家的数量惊人的高（例如北美的Faerina），我们仍然使用分层，但是自从游戏发布以来，我们已经减少了这些活跃服务器中的分层数量。


随着15年的积累，安其拉战争是魔兽世界经典中最值得期待的事件之一，我们期望它在一个区域拥有最多的玩家，在游戏发布时，在起始区域之外而无需进行分层管理。如果没有分层技术或人口分割技术，我们必须迅速地获得创造性。


手工制作的难忘经历


我们开始寻找一个非分层和碎片人口解决方案，通过产生无客户端—自动化玩家（机器人）—并指示他们模仿真实玩家可能做的事情，如施法、战斗NPC和在该区域移动。这让我们可以在同一个区域内对数千名玩家进行交互时的表现进行快照。在运行这些模拟之后，我们组织志愿者进行压力测试，这样我们就可以捕捉到真实的玩家行为，并观察他们之间的比较。这为我们提供了某些断点的指示，以及在高玩家数下，服务器的哪些代码段遇到的问题最多。


服务器帧时间度量被仔细检查，以确定它们离导致服务器无响应（也称为卡死）有多近。下一步是分析影响服务器性能的因素，这样我们就可以开始将这个巨大的任务分解成可理解的目标。我们面临的是一个多项式问题，这意味着我们不能用更快的硬件来解决它因为硬件并不是指数上更好的。


取而代之的是，我们必须通过刻意选择哪些数据应该传达给玩家以及传达的频率来手工优化。为了说明这个难题，我们假设有20个玩家在一个圆圈中跳跃。服务器通过数据包（数据可交付物）将每个玩家的操作转发给其他19个玩家。在这个20人组中，服务器处理380个数据包（总共20个播放器*19个收件人=380个数据包）。当更多的玩家在区域内做同样的动作时，这个问题就更加复杂了。如果我们将我们的示例增加到500个玩家，那么将从服务器发送249500个数据包。如果我们再次将我们的示例增加到1500个玩家，那么将向服务器发送2248500个数据包。根据玩家的操作，每秒发送多个数据包请记住上面的例子只说明一个动作。


发送到服务器的数据包越多，服务器必须处理单个玩家的处理时间，然后再处理其他玩家的操作。当这个问题复杂化时，服务器开始接近卡死。在魔兽世界经典游戏中，我们每个领域的玩家数量比2006年的时候要多得多，所以我们的期望是我们能容纳比以前更多的玩家。


魔兽世界怀旧服开发者的幕后工作 重现安其拉开门事件的幕后工作（一） 未完待续...