我正在制作客户端服务器MMO风格的游戏。到目前为止，我已经建立了框架，以便服务器和客户端相互交互以提供状态更新。服务器维护游戏状态并定期计算下一个状态，然后每隔一段时间（每n毫秒）将其发送给所有客户端。用户可以在客户端查看此新状态并做出反应。然后，将这些操作发送回服务器进行处理，并发送给下一次更新。

明显的问题是这些更新在服务器和客户端之间传播需要花费时间。如果客户端采取行动攻击敌人，则在更新返回到服务器之前，服务器很有可能已将游戏状态推进到足够远的程度，以使敌人不再位于同一地点且不在范围内。

为了解决这个问题，我一直在努力提出一个好的解决方案。我看了看下面的内容，它对某些（但不完全）有所帮助：Mutli
Player游戏同步。我已经得出的结论是，我不仅可以传输游戏的当前状态，还可以传输其他信息，例如方向（或AI运动的目标位置）和速度。由此，在客户端，我拥有了“猜测”所需要的部分内容，即通过将游戏状态前进至未来的毫秒，可以了解实际状态（如服务器所看到的）。

问题是确定状态进展的时间，因为这将取决于服务器和客户端之间的延迟时间，这可能会有很大的不同。另外，我应该将游戏状态提升到客户端查看时的当前状态（即仅考虑更新到达客户端所花费的时间），还是应该进行得足够远，以便在发送响应时返回到服务器，届时它将是正确的状态（用于往返旅程的帐户）。

有什么建议？

重申：

1）计算发送和接收之间的时间量的最佳方法是什么？

2）我是否应该使客户端状态进展得足够远，以至于可以计入整个往返行程，或者仅仅是从服务器获取数据到客户端所花费的时间？

编辑：到目前为止我想出了什么

由于我已经在客户端和服务器之间来回传送了许多数据包，因此，如果需要，我不想添加该流量。当前，客户端将状态更新包（UDP）发送到服务器约150毫秒（仅当发生更改时），然后由服务器接收并处理它们。当前，服务器未发送对这些数据包的响应。

首先，我将让客户尝试估计他们的延迟时间。我会将其默认设置为50到100毫秒。我提议服务器（每个客户端）大约每2秒立即响应这些数据包之一，并在特殊的定时更新数据包中发回数据包索引。如果客户端收到定时数据包，它将使用索引来计算该数据包的发送时间，然后使用数据包之间的时间作为新的延迟时间。

这样可以使客户端合理地保持最新状态，而不会有过多的网络流量。

听起来可以接受，还是有更好的方法？这仍然不能回答第二个问题。