WebSocket 性能
我正在考虑实现一个HTML5 mmog，其中涉及一个快速运行的对象。玩家通过射击不断改变该物体的方向。我想到了WebSockets等(socket.io)和canvas。
我认为方向变化的计算必须在客户端和服务器端完成，然后同步 - 服务器是主控以避免作弊。
我担心的是，无论服务器有多快，延迟都会导致滞后，从而终止同步。
有没有好的办法解决这个难题呢？如何实现如此大量数据的实时同步，其中所有信息对于不错过方向变化至关重要。所有玩家都需要立即获得移动物体的新方向，以免破坏游戏玩法。
我认为这个问题已经在现有的网络游戏中得到解决。
有什么想法吗？
I'm thinking about implementing a HTML5 mmog where there is a fast running object involved. Players constantly alter the direction of that object by shooting at it. I thought about WebSockets etc. (socket.io) and canvas.
I reckon that the calculation of the direction change has to be done client- AND serverside and then synchronized - with the server being master to avoid cheating.
My worries are that regardless of how fast the server is, latency will cause lag and therefore kill synchronization.
Is there a good way of solving this puzzle? How to achieve real time syncronization of this amount of data where all info is critical to not miss a direction change. All players need to get the new direction of the moving object without delay to not corrupt the gameplay.
I assume this problem has been solved in existing mmogs.
Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在这种情况下，您可以做的最好的事情是尝试预测客户端的运动（航位推算），然后在必要时使用来自服务器的数据纠正位置/速度。
例如，假设快速奔跑的物体以 5 的速度从左向右移动穿过屏幕，玩家向它射击，它改变方向，因此它现在以 5 的速度在屏幕上向上移动（90 度转弯） ）。
客户端应用程序的更新频率可能远高于从服务器获取数据的频率（例如客户端每秒 60 次更新，每秒从服务器接收 10 个数据包）。假设在服务器更新到来之前，对象实时改变了方向，还剩 5 帧。在客户端，对象将继续沿着其当前轨迹移动，直到它从服务器接收到它改变方向的更新（即，当它没有从服务器接收数据时，它不会停止），此时，客户端将纠正对象的位置和速度。
您如何进行校正将决定动画看起来有多跳跃。您可以立即将其移动到正确的位置，从而引起一点跳跃，但立即给出正确的位置，或者您可以改变它的速度，使其平滑过渡到该位置，不会引起跳跃，但具有修正期间位置稍有不准确。
您总会遇到一些情况，这些修正最终会变得相当大（例如，某人的连接非常糟糕、丢包、极高的延迟等）。这时你就会遇到人们通常所说的网络游戏滞后的疯狂异常，比如当一个物体跳过很长的距离或移动得非常快以“赶上”它应该在的位置时。没有办法始终保持 100% 同步。您所能做的就是对事物应该在哪里进行真正的猜测。
这里有一些更详细的文章，祝你好运！
http://gmc.yoyogames.com/index.php?showtopic=415538
http://www.gamasutra.com/view/feature/3230/dead_reckoning_latency_hiding_for_.php
The best thing you can do in these kinds of situations is to try and predict the movement client-side (dead reckoning), and then correct the position/velocity with data from the server if/when necessary.
For example, say your fast running object is moving left to right across the screen at a speed of 5, and a player shoots at it and it changes direction so it is now moving upwards on the screen at that speed of 5 (90 degree turn).
The client-side app will probably be updating far more frequently than it is getting data from the server (e.g. 60 updates per second client-side, and 10 packets per second received from the server). Let's say that, in real time, the object changed direction with 5 frames left to go before the server update will come. On the client-side, the object will continue to move along its current trajectory until it receives the update from the server that it changed direction (i.e. it doesn't just stop when it's not receiving data from the server), at which point, the client will correct the position and velocity of the object.
How you do the correction will determine how jumpy the animation will look. You could just zap it to the correct position instantly, thus causing a little jump but instantly giving the correct position, or you could change it's velocity in such a way that it moves in a smooth transition to that position, causing no jump, but having a slightly inaccurate position during the mean-time of the correction.
You'll always have some situations where these corrections will end up being pretty big (e.g. someone has a really bad connection, dropped packets, sky-high latency, etc.). That's when you get the crazy anomalies people usually refer to as lag in online games, like when an object skips large distances or moves really fast to "catch up" to where it should be. There's just no way to be 100% in sync all the time. All you can do is make really good guesses as to where things should be.
Here are some articles with more detail, good luck!
http://gmc.yoyogames.com/index.php?showtopic=415538
http://www.gamasutra.com/view/feature/3230/dead_reckoning_latency_hiding_for_.php
服务器是同步所有事件的正确位置。您不希望每个玩家将其输入数据发送给其他“n”个玩家，因为这会创建太多的通信路径。
服务器将获取玩家数据并确定移动物体的新轨迹，然后将更新发送给每个玩家。这可以以固定的虚拟游戏时间单位来完成，我将其称为“刻度”。
从服务器的角度来看，这会为您提供如下循环：
您将需要处理诸如在一定时间内未收到玩家输入的情况（例如，也许会忽略该帧的该玩家）。
在客户端，当您等待服务器发送的下一个游戏更新时，您可以继续沿着之前的轨迹移动对象，随着时间的推移渲染帧。
当从服务器收到当前游戏更新的更新时，必须应用新的游戏状态。
如果对象的新真实位置非常接近您推断的位置，您可以设置新位置并在下一帧渲染它。
如果新位置距离推断位置“很远”，那么您需要决定是立即将对象扭曲到目的地还是进行某种加速或线性运动以在短时间内将其移动到那里。
The server is the right place to synchronize all your events. You don't want each player sending its input data to the other "n" players as it creates too many communication paths.
The server will take the player data and determine the new trajectory of the moving object and then send updates to each player. This can be done in fixed units of virtual game time, which I will call "ticks".
From the server point of view this gives you a loop like the following:
You will need to deal with cases such as not receiving input from players within a certain amount of time (e.g., maybe ignore that player for that frame).
On the client side, while you are waiting for the next game tick update from the server, you can keep moving the object along its previous trajectory, rendering frames as time passes.
When an update is received from the server for the current game tick, the new game state must be applied.
If the object's new real position is very close to the position you've extrapolated, you can just set the new position and render it next frame.
If the new position is "far" from the extrapolated position, then you need to decide whether to warp the object instantly to the destination or do some sort of accelerated or linear motion to move it there over a short period of time.