Synchronization Issues
Author
I have a persistent world and it works pretty well. The biggest problem is the client getting off by 1 coordinate from where the server has him represented. Once this happens, its more than likely for the client to get off by even more.
Currently, the client sends a message to the server saying, "Moving left" or "Moving right", etc, because it is a tile based game. Also, there is no restrictions on when the player can move server side, just client side (for now).
My question is, what is the best way of combatting this? I have a 'sync-check' message sent out every X seconds from server to client to make sure the client is in the right spot, but that doesn't seem to make it too nice and it seems like a bandaid rather than an actual solution.
Some ideas I've considered:
1. Have the client tell the server the location he is moving too, and the server will move him there. Obviously there will be checks for if the position is too far from where he actually is.
2. Have the server immediately respond to every move saying the location of where the player is (this seems like a waste of bandwith because of the entirely new packet being made).
3. Let players bounce around for extra fun! (just kidding)
Any help/suggestions are appreciated :)
How can the server and client be off? If the client is using a reliable system of networking (TCP) then the server will get every command in order and perform it. Unless like 2 players aren't allowed to be on the same square and they are cutting each other off in a race then it doesn't seem possible (When the client is doing the collision checking).
I hope you are debugging this. Hit a key watch what the server does. Hit another key and make sure they correspond.
I hope you are debugging this. Hit a key watch what the server does. Hit another key and make sure they correspond.
Like Sirisian said, if you implemented it correctly, the client will "eventually" catch up to the server. Clearly, they will never be perfectly synchronized due to latency, but the problem sounds like your implementation. You either have a very bad design for your movement, or worst case scenario, your networking implementation is faulty.
My guess is that you are doing something along the lines of the client moves, then tells the server it moved. If this is the case, you have to allow the server to tell the client "No! Bad client! That is wrong, and you must move back to X,Y!" The most simple implementation would be to send a move request to the server, then if the server approves, notifies everyone (including the requester) that you moved. The downside to this is the delay between pressing the move button and moving. A more desirable, almost as simple method is to move and tell the server (not request) that you moved. You can not move again until the server gives you an "OK" that your movement was successful and valid, or a "No soup for you!" and forces you back to the previous location. You can not move until you get the response from the server. This still retains the synchronization, movement is instant, but things may get jumpy when the client and server disagree, and you will have to wait for a reply from the server.
These are very basic techniques, and neither are very great (though will suffice for a slower-paced game). But the point is that you need to implement some form of correction since it sounds like you have none.
My guess is that you are doing something along the lines of the client moves, then tells the server it moved. If this is the case, you have to allow the server to tell the client "No! Bad client! That is wrong, and you must move back to X,Y!" The most simple implementation would be to send a move request to the server, then if the server approves, notifies everyone (including the requester) that you moved. The downside to this is the delay between pressing the move button and moving. A more desirable, almost as simple method is to move and tell the server (not request) that you moved. You can not move again until the server gives you an "OK" that your movement was successful and valid, or a "No soup for you!" and forces you back to the previous location. You can not move until you get the response from the server. This still retains the synchronization, movement is instant, but things may get jumpy when the client and server disagree, and you will have to wait for a reply from the server.
These are very basic techniques, and neither are very great (though will suffice for a slower-paced game). But the point is that you need to implement some form of correction since it sounds like you have none.
Author
Thanks a bunch for the tips.
I think the problem comes from (I cannot replicate it) the player moving multiple times with NPCs walking in and out of their path. When the player moves on server side, sometimes the NPC is in the square, preventing him from moving to it, but on the client side, the player moved past the square. Moving in the same direction will amplify the disparity since the server will still prevent him from moving.
I think the 2nd idea Spodi suggested will work best.
Thanks!
I think the problem comes from (I cannot replicate it) the player moving multiple times with NPCs walking in and out of their path. When the player moves on server side, sometimes the NPC is in the square, preventing him from moving to it, but on the client side, the player moved past the square. Moving in the same direction will amplify the disparity since the server will still prevent him from moving.
I think the 2nd idea Spodi suggested will work best.
Thanks!
If I understand your explanation correctly...
1. Your client tells the server that the avatar is moving left.
2. Then the client just moves the avatar left in its copy of the world.
3. The server then uses the "moving left" message to move the client to a new position in its copy of the same world.
Is your game client/server so that you can have multiple clients? If you answer yes then that just makes the following recommendation even stronger because you don't want your clients getting out of sync with each other and because you are going to have to send out position updates to 1 or more other clients anyway.
1. Have your client send a request to the server to move the avatar to a new position (using either absolute coordinates or move direction) and then go ahead and start moving that direction (this is prediction on the client's part because the server is the ultimate authority on where the avatar can move).
2. Have the server evaluate the move and send out an update that says where the client is each "tick" until the avatar has arrived at its destination based on the movement request (either the avatar is in the same position because there is no alternate pathing, it is going around because you allow it to calculate an alternate path when it is blocked, or it is in the predicted position along the initial path).
3. If the client receives an update with a position that indicates anything different from where the client's avatar is currently then the client's avatar must be moved to that new position because the server is the ultimate authority, not the client.
Obeying the server may cause "jumps" once in a while if your server calculates a different path from the client's prediction. "Jumps" aren't good and you want to fix them but at least they keep your game synchronized.
4. If you get "jumps" then figure out why and either fix them or smooth them out. Perhaps "jumps" are caused because the pathing algorithm on the server is different from the one on the client. Hopefully it is the same code. Perhaps, even if it is the same code, the server and client are getting different numbers because of floating point math? Maybe the server has more or different information about the path (NPC or another player wandered into it?) that the client did not have when it first calculated the new position(s). If so then the server has to send out an update as soon as the path changes and the client has to obey the update.
1. Your client tells the server that the avatar is moving left.
2. Then the client just moves the avatar left in its copy of the world.
3. The server then uses the "moving left" message to move the client to a new position in its copy of the same world.
Is your game client/server so that you can have multiple clients? If you answer yes then that just makes the following recommendation even stronger because you don't want your clients getting out of sync with each other and because you are going to have to send out position updates to 1 or more other clients anyway.
1. Have your client send a request to the server to move the avatar to a new position (using either absolute coordinates or move direction) and then go ahead and start moving that direction (this is prediction on the client's part because the server is the ultimate authority on where the avatar can move).
2. Have the server evaluate the move and send out an update that says where the client is each "tick" until the avatar has arrived at its destination based on the movement request (either the avatar is in the same position because there is no alternate pathing, it is going around because you allow it to calculate an alternate path when it is blocked, or it is in the predicted position along the initial path).
3. If the client receives an update with a position that indicates anything different from where the client's avatar is currently then the client's avatar must be moved to that new position because the server is the ultimate authority, not the client.
Obeying the server may cause "jumps" once in a while if your server calculates a different path from the client's prediction. "Jumps" aren't good and you want to fix them but at least they keep your game synchronized.
4. If you get "jumps" then figure out why and either fix them or smooth them out. Perhaps "jumps" are caused because the pathing algorithm on the server is different from the one on the client. Hopefully it is the same code. Perhaps, even if it is the same code, the server and client are getting different numbers because of floating point math? Maybe the server has more or different information about the path (NPC or another player wandered into it?) that the client did not have when it first calculated the new position(s). If so then the server has to send out an update as soon as the path changes and the client has to obey the update.
Hi
I would simply send a new absolute position to the client each time server for one reason or another moves the character. Only then would client update the character location on the screen. If this causes too slow response time to the user you can "cheat" and move the character as soon as the user clicks movement button and verify the location when server sends the updated absolute location. As said it may cause the character first move forward and then jump back if an obstacle is in between. Unless your client can also evaluate these collisions and is perfectly in synchronization with the server it is not theoretically possible to avoid completely these corrective movements on collision situations.
regards,
Tommi
I would simply send a new absolute position to the client each time server for one reason or another moves the character. Only then would client update the character location on the screen. If this causes too slow response time to the user you can "cheat" and move the character as soon as the user clicks movement button and verify the location when server sends the updated absolute location. As said it may cause the character first move forward and then jump back if an obstacle is in between. Unless your client can also evaluate these collisions and is perfectly in synchronization with the server it is not theoretically possible to avoid completely these corrective movements on collision situations.
regards,
Tommi
Yeah, I'd also recommend using absolute positions if possible. Worst case scenario, you're looking at 8 bytes for the position, though you are very likely using maps that can fit in the range of a byte or short.
Author
I implemented this and it seems to be working MUCH better if not perfect. Thank you all.
As for the 'jumping' i just made a semi smooth transition as the character kinda slides back.
As for the 'jumping' i just made a semi smooth transition as the character kinda slides back.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
