让我们做简单的事情，我们有一个客户端绘制的云，以及发送命令以移动云的服务器。假设客户端 1 以 60 fps 运行，客户端 2 以 30 fps 运行，我们希望云过渡平稳。
第一个问题 - 服务器与客户端有不同的 fps，如果每次发送移动命令，它将更快地开始发送垃圾邮件命令，然后客户端将绘制。
可能的解决方案 1 - 客户端在完成帧后发送“我想要更新”命令。
可能的解决方案 2 - 服务器每 x ms 发送一次移动云命令，但云不会顺利移动。可与解决方案 3 结合使用。
可能的解决方案 3 - 服务器发送 - “以速度 x 开始移动云”和“改变“云方向”而不是“将云移动到 x”。但问题再次是在屏幕边缘检查更改云目录的内容，然后触发速度更快云实际上是在客户端绘制的。
客户端 2 的绘制速度也比客户端 1 慢 2 倍，如何补偿呢？
如何以基本方式将服务器逻辑与客户端绘制同步？
如果可以的话，解决方案 3 听起来是迄今为止最好的解决方案。您的所有其他解决方案都过于冗长：它们需要客户端和服务器之间非常频繁的通信，除非服务器和客户端之间具有非常好的网络连接，否则过于频繁。
如果您的云移动都足够简单，可以将它们作为矢量发送给客户端，以便客户端可以在接收新指令（新的起始位置和矢量）之前沿着一个矢量移动云很长一段时间（许多帧） ) 从服务器，那么你绝对应该这样做。如果您的云移动不像简单的向量那么容易表示，那么您可以选择更复杂的模型（例如添加指令以随时间变换向量）并将模型的参数发送给客户端。
如果云是更大世界的一部分，并且客户端跟踪世界上的时间，那么来自服务器的每组指令都应该包含一个时间戳，表示模型中的初始条件有效的时间。
至于您关于如何补偿客户端 2 的绘图速度比客户端 1 慢两倍的问题，您需要让您的世界时钟在两个客户端上以一致的速率滴答作响。此速率无需与任一客户端上的屏幕刷新率有任何关系。