Effectively moving players around the network

Question

I am making a Java game using Slick2D and using Kryonet for a multiplayer game. When a player presses W, A, S, or D, they move, and the PlayerMovePacket object is sent over the network (via UDP) to the server. The server then sends this to other clients who establish a local copy of this player’s position according to the information inside the package.

Here is the code for PlayerMovePacket:

public class PlayerMovePacket { public Vector2f pos; public int clientID; public PlayerMovePacket() { pos = new Vector2f(0, 0); clientID = -1; } public PlayerMovePacket(Vector2f v, int id) { pos = v; clientID = id; } } 

By doing this, clients / server are overloaded from too many messages and fail. The only other option that I see is that I will send the player’s position only every few milliseconds. However, customers will not have the most recent player position most of the time, and movement will be erratic

Any ideas on how I can stop server overload?

Answer 1

Add a threshold value, is it really important that you send motion data for every small move?

Another approach is to combine it every couple of milliseconds, as suggested. If the player has moved 3 times (or 3 actions), you can combine this movement into one package and save yourself some network input-output. Actually, it depends on the game and what your consistency guarantees are. In most cases, sending data every 25-50 ms is acceptable, since you cannot perceive the changes in any case.

@jussi also mentioned that you can try to predict movement on the client side and simply compensate every time a new package of player’s position is accepted, which is also acceptable and used quite widely. I would caution when trying to make it very difficult, as it can make the game even more nervous or laggy, but simple straight paths will work just fine. You can see examples of this in many games, where you see that people who are disconnected sometimes run in place or run into objects in the game until the server finds out that they are really disconnected, and such things are acceptable, because you need high enough thresholds do not cause server failures on the client.

Answer 2

I suppose you could send positions every couple of milliseconds and make some kind of prediction on the client side to make it less nervous.