WebSockets performance

Question

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?

Answer 1

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

Answer 2

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:

1. Receive inputs from players
2. Update game state
3. Distribute game state changes to players

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.