EVE星战前夜中的关于时间膨胀

常说只要卡了就不会赢，因为玩家们总是成群作战，人多就卡。的确是这样，接受这样的事实对于我们Team Gridlock很重要。除了优化之外，我们也着手处理了战斗时卡装备的问题，当服务器过载时，将会有一个合适的方法来处理这样的问题。这就是这篇博客所述内容。但是要明白在什么情况下，才会进行这样的处理。目前服务器过载时，并没有特定的机制去解决卡的问题。因为这些机制在驱动着一些基本的操作。某些有趣的行为来自于服务器卡（手动操炮？），但是在我深入探讨这个问题之前，需要定义一些名词。

Tasklets, Schedulers and Yielding的定义

EVE服务器上运行着一套进程，它们会对来自客户端或某个维持模块状态进程的数据包（基本上所有）进行响应。它们被称为小任务（tasklets），原因我们不必细知。但只要我们使用电脑，那么只有小任务（tasklets）能够在任何给定的时间运行。某种软件会决定需要哪种小任务（tasklets）。这就是调度程序（Schedulers）。

有很多种不同方式的调度程序（Schedulers）。EVE采用的是一种很简单的循环合作多任务处理方式。“循环”简而言之就是在所有小任务（tasklets）都获得机会之前，每个小任务（tasklets）都会有机会。没有优先级也没特殊处理，这样非常公平；每个小任务（tasklets）都能轮到。“合作多任务处理”的意思是没有小任务（tasklets）会在执行进程中被外部中断。小任务（tasklets）将会一直运行到处理结束，或者运行特殊例行程序（发出信号给调度程序（Schedulers），让其他小任务（tasklets）去处理。这就是结果（yielding）。

 

也许你要问：“小任务（tasklets）为什么要结果？”如果它们不结束，那么它们就会一根筋死磕同一任务。 这样的方式的并不好，线程独占CPU资源，其它线程就得不到响应。因此，当我们在写系统代码时，预计操作可能会花去很长时间，所以我们设定结束（yield），这样调节比较好。

另一个需要结果（yield）的原因是小任务（tasklets）是否在等待来自其他机器的输入，比如数据库。坐在那里不断询问“反馈回来了吗？”是没有意义的，等待的时候，我们能够让其他小任务（tasklets）运行，(这是I/O上的中止信号，不需要详知)

怎么处理这些呢？

抱歉，但下面我会写一些关于计算机科学的东西，来解释清楚小任务（tasklets）在高负载下的主要运行方式。当服务器过载时，yield后至少需要5秒钟才会轮到其他小任务（tasklets）去处理。这就导致运行既不完美也费时。爆船就是一个很好的例子，期间反馈给数据库很多轮数据，导致结束（yield）非常多，造成了空结构还不爆船。同样的，通过设定100毫秒结束（yield），模组能够大大提高运行速率。

上述内容为以下内容服务：

EVE的服务器将会通过这样一种方式来使小任务（tasklets）队列的理论时间降至为0。时间膨胀的目的即在此。为了服务器的良好运行，需要两点：减少负载、提高运算能力。

Gridlock已在优化减少负载方面花费很多时间。我们将会继续这样做，但我们已经解决了这方面的很多简单问题。我们同时进行提高运算能力的工作，虽然提高了每秒的运算速度，但是远远没有大多数人认为的那么多。当然，某日我们定会攻克，但有现在仍有其他更重要的工作需要去完成。

控制负载是势在必行，因为我们已经完成了一堆简单优化。我们已经制定了很多不同的计划。大部分人都跳过考虑物理模拟。当过载时，每秒物理模拟处理将会降低。但这样只能降低5～10%的负载，所以并不是很划算。

另一个普遍观点是增加模块循环时间提高效力。这样我们会有更多的自由处理空间，但是这样的话会大大改变游戏的设计，改变程度决定于负载的多少。实在是不怎么样的选择。改变游戏机制不予考虑。

谢天谢地，最终我们找到了调节负载的好方法，而且不改变游戏的设计，那就是时间流速放缓。当大型会战时，大部分负载与时间模块、物理模拟、飞行、跃迁相关，时间的膨胀将会按比例的降低负载。这个方法就是减缓游戏时钟，使小任务（tasklets）列队尽可能短，当负载消除时，时间将会恢复到正常水平。这将会在合适的范围内动态调节；如果因为轻微负载的话，时间会减缓至98%。

 

大型会战呢？

& N: [) F) ~. w/ Y$ @

以下是我对1600人会战的预想。当准备进攻时，舰队跳入，千次跳跃与无人机海等会使服务器极端过载，这时游戏时间减缓到正常的5%（仅举例）。当处理完成跳跃后，时间将会恢复到服务器允许的30%，此时发生遭遇战。1600人战斗的数据将平等的传输给服务器，但是需要花费平常的3倍时间去处理。玩家会感觉到装备循环周期变慢，爆船动画也变慢了...随着蛋打鸡飞，只剩下1200人，这时将会恢复到60%。一方指挥觉得大势已去，决定撤退。飞离时跃迁的负载也很大，所以时间再次减缓至正常的10%。随着战斗的终结，失败一方溃败，在低负载的情况下，时间恢复到正常。当然会有些小设计，比如时间膨胀计时器之类的。这些设计起来都很简单，就像增强计时。 当增强快结束时，时间膨胀计时器提供给玩家移除膨胀的功能。所以，增强计时并不会因为时间膨胀而膨胀。盾修是持续性的，并且对于战斗来说很非常重要，所以盾修周期会随时间膨胀而膨胀。膨胀的规则就是如果一件事情基于现实时间的，那么它就不会被膨胀。.如果认为某些设定不适合膨胀请在此帖留言。

预计公布时间

时间膨胀并不能解决一切问题。某些负载并不和时间关联，所以我们并不能确定会战的具体规模。我们今天讨论的基本上包含了全部的情况。我们将会对时间膨胀的程度做一个严格的限制，0.1%时间流速毫无意义，因为时间几乎是静止的。我不知道膨胀界限在哪，具体还需实操。如果战斗频繁的出现0.1%极限，那么还不如用现在的小霸王。如此之多的文字谈论了一个超概念性的时间膨胀。这个点子在我的雷达上停留了太长时间，但是不是所有都已经安排上日程。八月将会制作一个原型去试验游戏是否可以进行时间膨胀。玩家聚会上我已经得到了大量正面的反馈，而且CSM反应强烈.。这是相当大的一个工程，所以夏天之前就不要指望了。顺利的话秋天

太长不想看？看这里！

时间膨胀减缓时间，这样服务器就能够承受大型会战而不卡...我们将在不久后开始，如果顺利的话，很快就能面世。