RTS 客户端-服务器网络

Stone Monarch 从一开始就支持多人游戏,但随着时间的推移,网络模型经历了多次迭代。我最初基于这篇著名的帝国时代文章实现了点对点锁步模型。

点对点锁定步骤有一些众所周知的问题。点对点方面使玩家很难相互连接,并增加了每个新玩家的网络负载。锁定步骤方面很容易出现棘手的错误,导致玩家之间的游戏状态不同步。我当前的架构引入了服务器,并且还放宽了锁步的一些确定性要求。它仍然使用“回合”的锁步概念来确保每个客户端运行相同的模拟,并且在没有收到所有玩家的命令的情况下不会继续进行。

客户端-服务器锁定步骤

RTS 客户端-服务器网络_第1张图片

锁步转弯示例

游戏分为一系列固定持续时间的“回合”。游戏开始时的第一步是确定 1 回合的长度。这是通过测量消息从每个客户端到服务器的往返时间来完成的。服务器选择最长的时间作为回合长度。在游戏过程中,可以根据观察到的网络性能调整回合长度。

每当玩家想要执行某个操作时,请求的操作就会立即发送到服务器。服务器聚合它收到的所有操作,直到到达下一个回合边界。此时,服务器向所有客户端发送轮次消息,其中包含未来 1 轮要执行的操作。当客户准备好执行下一个回合时,他们应该已经收到模拟回合所需的所有信息。

在上面的示例中,转弯长度已设置为 100ms。服务器在第 1 轮期间接收操作,并在第 2 轮开始时发送包含第 3 轮操作的轮次消息。该消息应及时到达客户端,以便客户端执行第 3 轮。

处理延误

RTS 客户端-服务器网络_第2张图片

客户端延迟

如果其中一个客户端在准备好执行该轮次时没有收到轮次消息,则它必须暂停模拟,直到收到来自服务器的轮次。一旦它收到回合,它就可以立即开始再次执行。此时客户端将稍微落后于服务器的模拟,因此更有可能及时接收轮流。然而,玩家的命令发出和执行之间的延迟将会增加。

RTS 客户端-服务器网络_第3张图片

服务器端延迟

为了防止客户端远远落后于服务器的模拟(并遭受高命令延迟),服务器可以尝试检测到这一点并暂停其自己的模拟。为此,客户端可以在发送到服务器的每个操作中包含当前游戏时间。然后服务器将该时间与自己模拟中的当前游戏时间进行比较。如果差异大于 1 圈的长度(或任何任意长度),服务器可以暂停以允许客户端赶上。如果任何其他客户端在模拟中进一步领先,这可能会导致它们也暂停,直到所有客户端彼此更加同步。

在我最初的实现中,我使每次暂停的长度等于 1 圈的长度,这似乎是合乎逻辑的,可以防止客户在模拟中向前或向后滑动。然而,当前的方法极大地减少了暂停发生时的持续时间。通常,玩家甚至不会注意到它们。现在可以允许慢速客户端稍微落后于其他客户端,理论上他们可能处于劣势,因为他们的操作将需要更长的时间来执行。然而,这可以被服务器限制,所以我总是可以调整它以找到合适的平衡。

调整转弯长度

如果服务器观察到太多的暂停,它可以通过在轮次消息中包含新的轮次长度来增加轮次长度。所有客户在开始执行新回合时都将应用此规则。这将同等地增加所有玩家的命令延迟。

相反,如果服务器在一段时间内没有观察到任何暂停,它可以减少回合长度,从而为所有玩家提供更低的命令延迟。

非确定性事件

在传统的锁步网络中,每回合仅发出玩家命令,其余模拟预计将在客户端之间确定性地进行。然而,某些游戏逻辑很难保持确定性,尤其是在 Unity 中,游戏引擎不提供任何此类保证。

在这种情况下,我确保非确定性游戏逻辑仅执行一次,并将结果作为其自己的操作以及玩家请求的操作一起发布。

例如,假设玩家攻击了一枚炸弹,导致其爆炸。玩家发出所有客户端执行的攻击动作。在炸弹爆炸的地方,需要检查周围区域,看看哪些单位会被击中。这是使用不确定的 Unity API 完成的。因此,只有一个客户端(可能是拥有炸弹的客户端)将进行此模拟并将结果(应该受到伤害的单位列表)作为新操作发送到服务器。通过这种方式,每个客户端的模拟仍然是相同的

如果存在作弊问题,服务器可以代替客户端来计算这些操作。这将要求服务器运行与客户端相同的模拟。这是我正在努力的方向,尽管目前客户仍然做出一些不确定的决定。

这种方法的优点是,仅当某些特定的游戏逻辑预计是不确定的时才需要发送额外的数据。任何确定性的事情(例如村民继续收集直到他们的资源已满)都不会使用任何额外的网络资源。它也比重写 Unity 功能以使其具有确定性更容易实现,尤其是在物理方面。

缺点是,如果我错了,认为某些事情是确定性的,但事实并非如此,它仍然会导致游戏不同步。

你可能感兴趣的:(服务器,网络,运维)