What sort of data should be sent for mouse-based movement in a multiplayer game?

Question

I'm new to the Multiplayer Rodeo here so please bear with me...

I am just getting started and I'm trying to figure out how to deal with movement. I've looked at the question Best way to implement mouse-based movement in MMOG which gives me a pretty good idea, but I'm still struggling with what kind of data should be sent to the server.

If a player is on position [x:0, y:0] and I click with the mouse on [x:40, y:40] to start movement, what information should I send to the server? Should I calculate the position based on velocity on client side and just send the expected location? Or should I send current location and velocity and direction? When the server is updating the clients on the players' whereabouts, should the position be sent only, and the clients expected to interpolate/predict movement, or can the direction sent from the client (instead of just coordinates) be used.

My concern(or confusion) is regarding the ping/lag frequency of data update and use of a predictive algorithm, as I'd like the movement to be smooth even with a high latency, and prevent ability to cheat(though that's not the top priority).

Answer 1

You are starting to ask very important and complicated questions. First some general wisdom... In order to reduce the load on the server you should do as much as possible on the client. And in order to eliminate cheating, you should do as much on the server. As you see, these are diametrically opposite, and you will be in a constant conflict between these two rules.

So, going by the first rule, you should calculate everything on the client, and only send results to the server. This will produce smooth gameplay, as the lag is eliminated, and your server will be able to support many more players. Down side is, people will hack your code, and make their characters fast, powerful and all seeing.

Going with the second rule, server will receive only the intention of the command, and will calculate everything, verify if the motion can be attempted etc. This will be fair to all players, and you will be free to enforce rule for maximum enjoyment. Down side is that client will see results only when the server calculates them and sends the data back. Lag galore, and the server will be hard pressed to support 100's, but probably 10's of players. (unless you are doing a card game)

So, you will need to find middle ground. One possible way is for client to send the intention of command to the server, then itself calculate the move and start the motion, the server will calculate the motion as well and send the result back. The client should be coded so that server results always override its own, that way whenever server updates the move client 'snaps back' to the server state. This way client performance will be smooth, the game will be fair as it is checked by the server, and the only side effect is that user will see a temporary 'glitch' when server sends an update which differs from clients own precalculated position. These glitches will depend heavily on quality of prediction in your code.

You still have a down side that the server will do a lot of work. Depending how far you want to go, you can reduce server load by actually using client calculated results, and verifying some percentage of the moves, basically testing if you trust the clients results.

Answer 2

There are a few options, but probably the "standard" approach would be:

• As soon as you detect the mouse click, transmit the command to the server (a message equivalent to "move to 40,40")
• Give some immediate visual feedback (e.g. an animation at the clicked-on point)
• Wait for the server to process the move command and return a confirmation of the movement
• Perform animation based on the confirmed movement back from the server

The more advanced option is to have the client start animating the movement using a predictive algorithm as soon as the click is made, typically by replicating the logic that would be used by the server. This however causes two big complications:

• You need to reconcile potential differences when you finally get communications back from the server. e.g. it might turn out that the move was actually impossible (e.g. someone else cast a "freeze" spell on you a millisecond before) and you therefore need to snap the animation back to the frozen position.
• There are timing issues if you start the movement on the client before the movement actually starts at the server. What is the "definitive" time? Typically you want to treat the server timings as authoritative, but then the client is probably constantly running a small amount ahead in terms of animation.