我最爱的时间膨胀系列终於翻译第一篇了 其实在这篇之前还有一整个系列CCP为了改善大会战延迟，做了哪些努力的开发日志，希 望有一天能全部看到 时间膨胀已经在今年一月实装了，一直到今天为止，凡是有实际参与战斗的绝大部分都是 好评，也有相关的开发日志讨论几场大会战的时间膨胀数据，时间膨胀更是在Burn Jita时 让大家都能玩的很愉快(除了那些被爆船的) 英文 http://community.eveonline.com/devblog.asp?a=blog&nbid=2307 简体 http://eve.tiancity.com/homepage/article/2012/05/22/35417.html 以下是简体转繁体 ============================================================================= 【开发日志】关於时间膨胀（Time Dilation或简称TiDi） 作者：CCP Veritas 译者：CCP Albo 常言说，与卡机延迟之间的战争我们是一定赢不了的，因为玩家总是可以叫更多的舰 船来。这个说法从根本上看是正确的，而正视这个事实也对Gridlock小组的工作有重要的 意义。除了之前的一些优化工作之外，我们还想着手解决战斗时卡装备的问题，这样当服 务器不堪重负时，它也能比较合理地去应对。这就是本篇开发日志要讲的内容。不过，在 理解我们的做法之前，你先要明白我们目前的处境。现在，当服务器负载过高时，它并没 有明确的机制去解决这一问题，负责常规操作的机制只是按照它自己的步调前行。游戏中 某些有趣的现象正是出於这个原因。不过在进一步阐述这个问题之前，我需要先对一些术 语做出定义。 小任务(tasklet)，调度程序(scheduler)和让步(yielding) 基本上来讲，EVE的服务器运行着一系列的任务——可能是对客户端命令的回应，也 可能是维持着装备（不止装备，几乎所有的内容）的正常状态。它们被称为小任务——你 不需要知道为什麽这麽叫。但只要我们使用电脑，在特定某一时间内就只能运行一个小任 务，而且我们需要一种软件来决定运行哪个小任务，这个就叫做调度程序。 调度程序分为不同的形式，负责EVE中的小任务运行的那种很简单，是一种循环合作 式多任务调度程序。「循环」意思是每一个小任务都有机会运行，直到所有的小任务都运 行了一遍为止，没有优先级，没有特殊待遇，非常公平不是吗，谁都有机会。合作式多任 务意思是每个小任务在执行过程中都不会受到来自外部的干扰，它会一直运行下去直到运 行完毕，或是走一种特殊的步骤，发出信号给调度程序，表明它希望让其它小任务现在来 运行。这後一种情况就叫做让步。 所以这个系统就像这个样子： http://cdn1.eveonline.com/community/devblog/2011/simple_scheduler.png 你可能会自言自语「为什麽有小任务会让步呢？」这个……如果它们很自私的话，它 们当然不会让步，而是会把自己的一切全部搞定之後再把机会让给别的——往往也是不那 麽重要的任务。不过这样做并不好，因为独享CPU资源可不是个好主意。正因为如此，当 我们在编写可能会用比较长的时间来执行的程序时，我们会在合适的地方添加让步指令， 这样它和别的程序之间就能和谐共处了。 小任务会做出让步的另一个常见原因就是，它可能在等待来自其它地方——比如数据 库的指令输入。一直停在那里等待返回指令并没有任何意义，我们可以让别的任务先来， 而我们继续在一旁等待。（嗯没错，这个就是基於I/O完成指令的暂停状态。） 好吧夥计，那你怎麽处理它们呢？ 非常抱歉，下面我要涉及一些计算机科学方面的专业内容了，它会解释清楚小任务在 高负载下的主要运行方式。当服务器负载过高时，它在让步之後至少5秒钟才会开始下一 个流程，这就导致任务无论是否顺利执行，都会花费非常长的时间才能完成，因为它一直 在等待执行的流程。爆船就是个很好的例子——它会多次访问数据库，所以频繁地进行让 步，这就把整个完成时间拖得很长。同样地，装备的运算流程有时会非常滞後，因为处理 它们的小任务会在进行100毫秒的执行之後做出让步。 上面说了那麽多都是为了下面这句做铺垫： EVE的服务器应该将小任务等待执行时的队列时间降至最短——降到零最好。 这就是时间膨胀的意义所在。 要想在维持服务器正常运行的情况下实现这一目标，我们的选择并不多。基本上可以 归结为两点：降低负载或是提高运算能力。 Gridlock小组花了很多时间，试图通过优化的方式达到降低负载的目的。我们可以， 而且也很有可能继续为此而努力，而且也已经搞定了这方面的一些简单工作。使用多线程 是提高运算能力的一种方法，它可以提高每秒钟的处理能力，但其实并没有人们想像的那 麽多。总有一天我们可以实现，但是现阶段它所需的工作量要远大於实际收益。 调节负载现在看来是势在必行了，因为我们已经完成了一大堆简单的优化工作。我们 已经制定了几个不同的可行方案，最为大多数人认可的一个方案，是将Destiny——我们 的物理模拟器——进行升级，这样当过载时它的每秒物理解析度将会降低。这样做可以帮 助我们减少实际的模拟工作量，不过只能降低5%-10%的负载，所以也不怎麽划算。 另一个普遍的观点是延长装备的循环时间，相应地提升效率与消耗。这样我们会有更 多的自由空间，但是会极大地改变游戏的设计，改变的程度取决於负载的高低，这样可不 行。现有的卡装备现象已经会改变游戏机制，所以为了不让事情变得更糟，我们不予考虑 这种方法。 不过谢天谢地，我们终於找到了一种在不改变游戏设计的前提下有效控制负载的方法 ：将时间的流逝放缓。大型会战中很大一部分负载与时间计算有关——装备激活、物理模 拟、飞行及跃迁等——这些都是在一定的时间内完成的，所以将时间分割开来将会相应地 按比例降低他们的负载消耗。因此，我们的方法是将游戏时间放慢，尽量减少小任务执行 时的等待时间，而当负载回归常态时，再将时间恢复正常。这个过程的执行将是动态的， 并且有较细的档位划分，比如说，如果负载较轻的话，我们完全可以将时间调到正常的 98%来运行。 好吧，那麽在大型战斗中它的表现如何？ 以下是我对它在大型会战（比如1600人）中的表现的预想。当敌人的舰队跃迁进来时 ，服务器负载一下子变得很高（跃迁来去和放出无人机这类行为非常占用资源），於是游 戏内的时钟也大大放缓，只有正常的5%左右。当这些运算都处理完毕後，服务器将允许时 间恢复到正常的30%，这个时候战斗打响了。我们要面对1600个同时发生的战斗行为，他 们的处理请求将迅速而平等地由服务器进行处理，只不过要花费比平时长三倍的时间。玩 家们将会感受到舰船界面中装备循环变慢了，爆炸的动画也变慢了。伴随着一阵烟花，舰 船减少到1200艘了，那麽我估计时间将恢复到正常的60%。这时候一方的指挥官觉得大势 已去，呼叫撤退。跃迁是很占资源的，所以随着舰船的离开，时间又大大变慢，到了正常 的10%。最後战斗结束了，失败者也逃掉了，服务器负载变得很低，所以时间就恢复正常 了。 当然这里面还有些很棘手的设计问题，比如说计时器遭遇时间膨胀会怎样。我觉得大 多数情况下这个问题容易解决——如果增强模式计时器也能够被膨胀的话，那麽玩家就可 以在增强模式快结束的时候进行移动，这和我们的设计初衷相悖，所以增强模式计时器是 不可以随着时间膨胀的。而另一方面，护盾的回充是持续性的，在战斗中具有重要意义， 所以它必须要随时间膨胀而膨胀。基本原则就是，如果某件事情是偏重於现实中的时间的 ，那麽它就不可以被膨胀。如果你觉得哪些情况不应该牵涉到时间膨胀，请在官方论坛中 留言。 合理预期！ 时间膨胀并不是万能的。有些负载和时间毫无关联，所以我们不能处理规模不确定的 战斗。我今天提到的应该已经涵盖了所有的常见情况。不过，我觉得我们应该为时间膨胀 设定一个硬性的限制。在某个星系中出现0.1%的时间流速毫无意义，因为时间几乎静止， 你什麽都干不了。我不知道这个临界值将是多少——具体的还要等看看今後的部署效果再 说。如果实际战斗中总是会突破这个临界值的限制，那我们就又回到现在这种服务器无响 应而且时不时抽风的状态了。一切等待时间检验吧。 这篇日志很长，而且谈论的是一项试验性的内容。时间膨胀这个想法我早已有之，但 直到今天也没有实际上投入太多的工作。我们去年八月做过一个试验品来测试游戏是否能 够处理得了膨胀的时间，之後直到今天再无建树。我在全球玩家聚会上得到了大量的积极 反馈，再加上星际管理委员会（CSM）将此作为他们最强烈的愿望，这些都激励了我，让 我觉得是时候将其推出了。这可是一项大工程，所以2011年夏天你们就不要想看到它了。 一切顺利的话，在秋季上线还是有希望的。 太长了，总结一下吧 时间膨胀的作用是将时间放慢，这样服务器就有足够的时间来处理你的请求。我们将 会开始着手进行这项工作，如果一切顺利，它将在一段时间後与玩家见面。 原文http://community.eveonline.com/devblog.asp?a=blog&nbid=2307 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 220.130.245.45 ※ art1:转录至看板 C_Chat 05/22 10:43 ※ 编辑: art1 来自: 220.130.245.45 (05/22 10:46) ※ art1:转录至看板 C_Chat 01/29 10:36