我希望我的游戏完全是服务器端。意思是，客户端只发送他们的击键。然后，他们从服务器获得更改对象位置的更新。然后客户端每帧渲染一切。
这是一款2D游戏
我在考虑这样的事情： 使用Box2D计算中间帧，不要试图预测服务器实际上在哪里。
ServerPos - ＆gt; ClientPos - ＆gt; ServerPos - ＆gt; ...
如果在某个时间我们没有得到一个数据包（丢弃或什么），那么我们只是模拟客户端上的下一帧。我们的想法是避免服务器总是纠正我们的立场。我们希望客户端填充中间内容，但不要尝试预测服务器的位置。
我们希望不惜一切代价避免将玩家向相反的方向移动，因为客户端过度模拟，因此我们可以将结果向量乘以0.98这样的标量，这意味着客户端会比服务器略慢，并且会有所帮助确保顺利过渡到服务器位置。
由于
答案 0 :(得分：6)
只是一个想法，但我认为你可能会忘记网络延迟。
假设您确实每秒发送数据60次以响应客户端发送的内容。比您的最大延迟时间1 second / 60 = 17ms。这对于任何互联网连接都是一个问题，因为您的应用程序必然会引入一些延迟。所以...如果你想要这样的东西工作，你必须有一个缓冲窗口来捕捉这个延迟。这将使其感觉不那么敏感。
有一个原因是大多数在线游戏都有一些预测算法，以防万一连接丢失/停止。
我认为这个想法很好，但在实践中它可能效果不好。
答案 1 :(得分：2)
这将只能在LAN上工作，或者在某些低跳服务器到客户端连接上异常工作。尝试TRACERT到一些公共服务器 - 这是一个例子：
C:\Users\mosh>tracert -d -w 3000 www.google.com
Tracing route to www.l.google.com [209.85.149.104]
over a maximum of 30 hops:
1 46 ms 99 ms 99 ms 192.168.1.1
2 * * * Request timed out.
3 10 ms 9 ms 10 ms 172.29.16.133
4 10 ms 9 ms 10 ms 195.29.110.230
5 41 ms 41 ms 95 ms 80.81.193.108
6 46 ms 47 ms 127 ms 209.85.255.176
7 49 ms 47 ms 47 ms 216.239.48.11
8 47 ms 47 ms 47 ms 216.239.48.5
9 54 ms 53 ms 54 ms 209.85.254.21
10 51 ms 42 ms 40 ms 209.85.149.104
Trace complete.
服务器和客户端之间的每个路由器都会增加几毫秒，并且取决于17毫秒（一帧）的延迟会使游戏无法使用。
答案 2 :(得分：1)
没有
如果您控制服务器端的所有内容，网络延迟将使游戏无法播放。您只需要查看已经执行此操作的游戏，例如LaTale。输入延迟太可怕了。
答案 3 :(得分：1)
你不能这样做，因为你不知道击键到达服务器需要多长时间。并且考虑到物理会随着时间的推移而改变对象的状态，这种不可预测的时序方面意味着您无法保证服务器的表示将继续与客户端匹配。一方必须具有权威性 - 另一方必须预测，等待或两者兼而有之。
答案 4 :(得分：0)
尽可能少地同步。每秒60次太多而且没必要。对于局域网，sycn每100ms就足够了;对于WAN，每200ms一次是正常情况。
而且，你正在制作哪种游戏？对于不同的游戏，政策是非常不同的。您可能需要为游戏自定义同步政策。