Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

What is the right way to tell the position of our local player to the server? Some documents say that it is better to send the inputs whenever they are produced. And some documents say the client sends its position in a fixed interval.

With the sending the inputs approach: What should I do if the player is holding down the direction keys? It means I need to send a package to the server in every frame. Isn't it too much? And there is also the rotation of the player from the mouse input. Here is an example:

http://www.gabrielgambetta.com/fpm_live.html

What about sending the position in fixed interval approach. It sends too few messages to the server. But it also reduces responsiveness.

So which way is better?

share|improve this question

2 Answers 2

up vote 14 down vote accepted

Simple answer: cheat or don't be that accurate!

If you've played some shooter online, you'll most likely have experienced the so called "rubber banding" if your connection to the server is bad.

This is caused by your client correcting your position from time to time.

Basically, what happens on the two sides:

  • The server will track your movement and send updates to the clients as expected. These don't always have to be full updates. Every x frames there could be a full update, all other frames you only send new velocity vectors (if there are any changes).

  • Your own client will allow you to move freely but will use the updates provided by the server to correct/adjust your position. This will ensure the game to feel responsive, even if you don't update the position frame by frame.

But how is input handled? Your client will send your position to the server "I moved there.". The server will verify this update (e.g. should you be able to move there that fast?) and if it's valid move you (or rejecting your update, resulting in "rubber banding").

So yes, your fixed interval approach will most likely work and be enough.

But even if you want to send input and handle movement on both sides, keep in mind that you don't have to send "button is still pressed". Instead, send one event when the button is pressed and another once the button is released.

share|improve this answer
3  
Yes i can track the press and release of the button. But what about mouse input? It is constantly changing. –  syloc May 8 at 7:19
5  
"Instead, send one event when the button is pressed and another once the button is released." - True, but there does need to be checks in place to make sure that the "on release" event is eventually forced, depending on the games' rules. For example, in Rainbow Six Vegas 2 multiplayer, a player can start firing his gun, and an (unfortunately common) bug causes the "stop firing" message to not sucessfully reach the server. This results in the gunshot audio remaining in an infinite loop for the rest of the match. Just one example to be wary of. youtu.be/GOQIbLCy7m8?t=9m10s –  Teifi May 8 at 12:44
    
@syloc: Just handle it client side and let the server determine whether the movement is valid/possible (to prevent stuff such as teleport hacks and similar). –  Mario May 8 at 16:00
    
@syloc Just set an interval for the mouse, but to save extra bandwidth still do client-side checking to see if it's changed. If there's a period of time with no mouse movement, you don't need to keep sending messages about it. –  agweber May 8 at 18:09
    
At one of my jobs, we had an engineer practically drive himself insane optimizing the spring behavior for missed position updates for dial-up (13 years ago). Now I see games with plenty of bandwidth and ridiculously low-latency suffering from this issue, seems the issue will never ago away or that people care a lot less about it these days. –  Andon M. Coleman May 9 at 22:30

If you haven't already, I suggest you to read these two deep but understandable articles : https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking and http://fabiensanglard.net/quake3/network.php.

These explain why it's advised to use 'fixed interval' packet sending. To be short, it's in fact mainly important for packets sent by the server.

Sending a packet has a fixed cost, and a network packet maximum size is about 1.5 KB. So if you have for example 16 players on your server, each frame when you calculate movement for a player, naive code could send a update packet to each player after each movement resolution, so 16*16 = 256 packets. If you have a framerate of 30, that's 7680 packets.

A better approach, is to create a buffer in each beginning of frame, concatenate in it your 16 calculated positions update, and then send them to your 16 players.

You now send only 480 packets by seconds for same results.

In the player-to-server case, that just means you should send, in the same packet a maximum of data, like; looked position, actions called this frame and so on.

About the second part of your question - the way I choose to reduce the lag sensation was to send this information to the server on each frame:

  • actual current position of player (used by server to check if server side and player side positions aren't too much desynchronized).

  • Estimated player position in 1 second : calculated by client: if the player doesn't change mouse direction and leaves the keyboard in its current state for 1 sec where will be the player? (we don't care about collisions) If the player isn't moving, then his estimated position in 1 second is its current position.

  • The position he look at.

Each time the server receives this information it updates the future position and looked position, and the player entity eventually moves toward its future position.

Players are never exactly synchronized, but input response is instant (most important for me) and I found predicted positions to be accurate enough for me.

share|improve this answer
    
"Players never are never exactly synchronized" I think it's also important to mention that the level of accuracy here depends on the actual game(play). For example, a classic MMO where you just click and select entities, won't need perfect accuracy for pretty much everything, but in a shooter good to perfect sync is essential. –  Mario May 8 at 16:04
    
Thing is, nobody in their right mind uses TCP for an FPS. They would rather deal with complicated re-sequencing and missed datagrams than incur the overhead of TCP. –  Andon M. Coleman May 9 at 22:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.