我有一个客户机/服务器架构来实现，所有的状态变化发送给函数，验证和广播到所有连接的客户端。 这工作相当好，但系统没有比赛截至目前的客户实例之间保持同步。
如果碰巧是在服务器和特定客户端之间5秒的延迟，然后他就这样离开了他的比赛状态不同步的客户休息5秒后收到的状态变化。 我一直在寻找实现客户端之间的同步系统不同的方式，但没有发现多少至今。
我是新的网络编程，并没有那么天真的以为我可以创造一个工作系统的自己，而不专的时间严重金额它。 我一直有想法，但是，是保持某种时间体系，使每个状态的改变将被连接到在游戏中特定的时间戳。 当客户端接收的状态改变这种方式，它究竟会在游戏中发生改变的哪个时期都知道，并会反过来能够为滞后相关。 这种方法的问题是，在这些n秒落后的游戏会继续在客户端，因此客户将有及时回滚到更新的状态变化，这肯定会导致混乱。
于是我找了专题报告的讨论，解决它的主题或算法。 也许是我整个的多人游戏系统是如何工作的设计是有缺陷的，在这个意义上，除非从服务器接收观念客户端的游戏实例不应该更新？ 现在客户只需更新自己的游戏循环假设，任何国家都没有改变。
这种基本的方法被称为东西航位推算和关于它的相当不错的文章可以在这里找到。 基本上它是哪里的实体位置将在猜测服务器更新之间的次预测算法。
有迹象表明，建立在这个概念更先进的方法，但它是一个很好的起点。
同样的这是如何在源引擎处理（Valve的引擎第一半条命游戏）可以发现说明这里的原理基本上是相同的-直到服务器告诉你，否则使用预测算法来沿着移动实体预期路径 - 但这篇文章处理上试图更深入地拍这个东西有效果。
我已经在这个领域找到了最好的资源是由Valve软件这两篇文章：
绝不会有保证跨实时多视点的完美同步的方式 - 物理定律使它不可能。 如果太阳现在爆炸了，你怎么能保证在半人马座阿尔法星观察家认为超新星的同时，我们会在地球上？ 信息需要时间去旅行。
因此，你的选择是要么模型延迟准确的一切，可以从浏览器的不同而不同浏览器（这是你所拥有的目前），或无延迟他们不准确建模和广泛的跨观众同步（这是预测/航位推算/推断来在）。 像即时战略游戏的放缓往往走第一条路，更快的游戏走第二条路线。
特别是，你永远不应该认为它需要时间去旅行将是恒定的。 这意味着，仅仅是发送启动和停止的消息移动的实体模型下永远不会足够了。 您需要发送的实际状况定期更新（通常几次游戏速度就更快一秒），以便收件人可以在其预测和插值纠错。
你最好的选择是从未来发变回客户端，从而到达客户在时间上它为不具有滞后问题，其他客户的相同点。
如果客户端看到的事件在服务器喂他的速度，这是正常的方式做到这一点（我已经在网上Ultima，KalOnline和魔兽世界的一点点的协议工作），那么这个瞬息5个secounds延迟发生只想让他一下子收到这5个secounds事件，看看那些逝去的真快或接近瞬间事件，其他玩家会看到他“走”的真快一短距离，如果他的输出延迟了。 之后，一切都恢复正常流动。 其实，除了图形和物理正常化，我看不出有什么特殊需求，使其正常同步，它只是同步本身。
如果你曾经在两个近玩电脑Valve游戏你会发现自己不那么在意，如“你在那里去世的确切地点”或“在那里你尸体GIBS flyed为”小细节。 这一切都取决于客户端，完全受延迟，但是这是无关紧要的。
毕竟，落后的玩家必须接受他们的条件，或关闭他们该死的电驴。
