网络游戏？
我希望我的游戏完全是服务器端的。这意味着，客户端只发送他们的击键。然后，他们会从服务器获得已更改对象位置的更新。然后客户端渲染每一帧的所有内容。
这是一个 2D 游戏，
我正在考虑这样的事情： 使用 Box2D 计算中间帧，并且不要尝试预测服务器实际上将在哪里。
服务器位置->客户位置 ->服务器位置-> ...
如果到了某个时间我们还没有收到数据包（丢弃或其他东西），那么我们只是在客户端上模拟下一帧。这个想法是为了避免服务器总是纠正我们的位置。我们希望客户端填充中间内容，但不要尝试预测服务器将在哪里。
我们希望不惜一切代价避免由于客户端过度模拟而使玩家向相反方向移动，因此我们可以将所得向量乘以 0.98 这样的标量，这意味着客户端会比服务器稍微慢一些，并有助于确保平滑过渡到服务器位置。
谢谢
I want my game to be entirely server side. Meaning, the client only sends their keystrokes. They then are given updates of the changed objects' positions from the server. The client then renders everything each frame.
This is a 2D game
I was thinking of something like this:
calculate the inbetween frame using Box2D, and do not try to predict where the server is in fact going to be.
ServerPos -> ClientPos -> ServerPos -> ...
If by a certain time we have not gotten a packet (dropped or something) then we just simulate the next frame on client. The idea is to avoid the server always correcting our position. We want the client to fill the inbetweens but not try to predict where the server is going to be.
We want to avoid at all costs moving the player in the opposite direction because the client over simulated, so we could multiply the resultant vector by a scalar like 0.98 which would mean the client would be slightly slower than the server and would help ensure a smooth transition to the server position.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
只是一个想法，但我认为您可能忘记了网络延迟。
假设您确实每秒发送 60 次数据以响应客户端发送的内容。最大延迟可能是
1 秒/60 = 17ms。这对于任何互联网连接来说都是一个问题，因为您的应用程序也必然会引入一些延迟。所以......如果你想要这样的东西工作，你必须有一个小缓冲窗口来捕获这种延迟。这会让人感觉反应迟钝。大多数在线游戏都有一些预测算法，以防连接稍微下降/停顿，这是有原因的。
我觉得这个想法很好，但实际上可能效果不太好。
Just a thought, but I think you might be forgetting network latency.
Assuming you're really sending the data 60 times per second in response to something the client sends. Than your maximum latency can be
1 second / 60 = 17ms. That will be a problem for just about any internet connection since your application is bound to introduce some latency aswell. So... if you want something like this to work, you'll have to have a little buffer window to catch this delay. And that will make it feel less responsive.There's a reason that most online games have some prediction algorithms in place just in case the connection drops/stalls a bit.
I think the idea is nice, but in practice it probably won't work that well.
这只能在 LAN 上工作，或者在某些低跳服务器到客户端连接上特别有效。尝试对某些公共服务器进行 TRACERT - 这是一个示例：
服务器和客户端之间的每个路由器都会增加几毫秒，并且根据 17 毫秒（一帧）的延迟将使游戏无法使用。
That will and can work only on LAN, or exceptionally on some low-hop server-to-client connections. Try TRACERT to some public server - here is an example:
Every router you have between your server and your clients will add few milliseconds and depending on the 17ms (one frame) delay would make the game unusable.
不可以
。如果您控制服务器端的所有内容，网络延迟将使游戏几乎无法玩。您只需要查看已经执行此操作的游戏，例如 LaTale。输入延迟太可怕了。
No.
Network latency will make the game neigh unplayable if you control everything server-side. You need only to look at a game that already does this, like LaTale. The input delay is horrible.
你不能这样做，因为你不知道击键需要多长时间才能到达服务器。考虑到物理现象会随着时间的推移而改变对象的状态，不可预测的时间方面意味着您无法保证服务器的表示将继续与客户端的表示相匹配。一方必须具有权威性——另一方必须预测、等待，或两者兼而有之。
You can't do it this way because you don't know how long it will take for the keystrokes to reach the server. And given that physics changes the state of objects over time, that unpredictable timing aspect means you can't guarantee that the server's representation will continue to match the client's. One side has to be authoritative - the other has to predict, wait, or both.
尽可能少地同步。每秒 60 次太多了，没有必要。对于 LAN，每 100ms sycn 一次就足够了；对于 WAN，每 200 毫秒一次是正常情况。
而且，您正在制作哪种游戏？对于不同的游戏，该政策有很大不同。您可能需要为您的游戏自定义同步策略。
Sync as few as possible. 60 times per second is too much and not necessary. For LAN, sycn once per 100ms is enough; for WAN, once per 200ms is a normal case.
And, which kind of game are you making? The policy is very different for different games. You may need to customize a sync policy for your game.