个人帮企业做网站,网站是怎么做的,德保县建设局的网站,好的做问卷调查的网站好Stone Monarch 从一开始就支持多人游戏#xff0c;但随着时间的推移#xff0c;网络模型经历了多次迭代。我最初基于这篇著名的帝国时代文章实现了点对点锁步模型。
点对点锁定步骤有一些众所周知的问题。点对点方面使玩家很难相互连接#xff0c;并增加了每个新玩家的网络…Stone Monarch 从一开始就支持多人游戏但随着时间的推移网络模型经历了多次迭代。我最初基于这篇著名的帝国时代文章实现了点对点锁步模型。
点对点锁定步骤有一些众所周知的问题。点对点方面使玩家很难相互连接并增加了每个新玩家的网络负载。锁定步骤方面很容易出现棘手的错误导致玩家之间的游戏状态不同步。我当前的架构引入了服务器并且还放宽了锁步的一些确定性要求。它仍然使用“回合”的锁步概念来确保每个客户端运行相同的模拟并且在没有收到所有玩家的命令的情况下不会继续进行。
客户端-服务器锁定步骤 锁步转弯示例
游戏分为一系列固定持续时间的“回合”。游戏开始时的第一步是确定 1 回合的长度。这是通过测量消息从每个客户端到服务器的往返时间来完成的。服务器选择最长的时间作为回合长度。在游戏过程中可以根据观察到的网络性能调整回合长度。
每当玩家想要执行某个操作时请求的操作就会立即发送到服务器。服务器聚合它收到的所有操作直到到达下一个回合边界。此时服务器向所有客户端发送轮次消息其中包含未来 1 轮要执行的操作。当客户准备好执行下一个回合时他们应该已经收到模拟回合所需的所有信息。
在上面的示例中转弯长度已设置为 100ms。服务器在第 1 轮期间接收操作并在第 2 轮开始时发送包含第 3 轮操作的轮次消息。该消息应及时到达客户端以便客户端执行第 3 轮。
处理延误 客户端延迟
如果其中一个客户端在准备好执行该轮次时没有收到轮次消息则它必须暂停模拟直到收到来自服务器的轮次。一旦它收到回合它就可以立即开始再次执行。此时客户端将稍微落后于服务器的模拟因此更有可能及时接收轮流。然而玩家的命令发出和执行之间的延迟将会增加。 服务器端延迟
为了防止客户端远远落后于服务器的模拟并遭受高命令延迟服务器可以尝试检测到这一点并暂停其自己的模拟。为此客户端可以在发送到服务器的每个操作中包含当前游戏时间。然后服务器将该时间与自己模拟中的当前游戏时间进行比较。如果差异大于 1 圈的长度或任何任意长度服务器可以暂停以允许客户端赶上。如果任何其他客户端在模拟中进一步领先这可能会导致它们也暂停直到所有客户端彼此更加同步。
在我最初的实现中我使每次暂停的长度等于 1 圈的长度这似乎是合乎逻辑的可以防止客户在模拟中向前或向后滑动。然而当前的方法极大地减少了暂停发生时的持续时间。通常玩家甚至不会注意到它们。现在可以允许慢速客户端稍微落后于其他客户端理论上他们可能处于劣势因为他们的操作将需要更长的时间来执行。然而这可以被服务器限制所以我总是可以调整它以找到合适的平衡。
调整转弯长度
如果服务器观察到太多的暂停它可以通过在轮次消息中包含新的轮次长度来增加轮次长度。所有客户在开始执行新回合时都将应用此规则。这将同等地增加所有玩家的命令延迟。
相反如果服务器在一段时间内没有观察到任何暂停它可以减少回合长度从而为所有玩家提供更低的命令延迟。
非确定性事件
在传统的锁步网络中每回合仅发出玩家命令其余模拟预计将在客户端之间确定性地进行。然而某些游戏逻辑很难保持确定性尤其是在 Unity 中游戏引擎不提供任何此类保证。
在这种情况下我确保非确定性游戏逻辑仅执行一次并将结果作为其自己的操作以及玩家请求的操作一起发布。
例如假设玩家攻击了一枚炸弹导致其爆炸。玩家发出所有客户端执行的攻击动作。在炸弹爆炸的地方需要检查周围区域看看哪些单位会被击中。这是使用不确定的 Unity API 完成的。因此只有一个客户端可能是拥有炸弹的客户端将进行此模拟并将结果应该受到伤害的单位列表作为新操作发送到服务器。通过这种方式每个客户端的模拟仍然是相同的
如果存在作弊问题服务器可以代替客户端来计算这些操作。这将要求服务器运行与客户端相同的模拟。这是我正在努力的方向尽管目前客户仍然做出一些不确定的决定。
这种方法的优点是仅当某些特定的游戏逻辑预计是不确定的时才需要发送额外的数据。任何确定性的事情例如村民继续收集直到他们的资源已满都不会使用任何额外的网络资源。它也比重写 Unity 功能以使其具有确定性更容易实现尤其是在物理方面。
缺点是如果我错了认为某些事情是确定性的但事实并非如此它仍然会导致游戏不同步。
