How do I keep 1v1 player positions consistent over UDP on Kryonet?

Question

I have a server which is simple:

When two connections comes in, it opens a game room, pass their connections to it and runs a thread with a gameloop. (Everything is running on Kryonet)

So... I made the movement, it works on TCP and UDP, but it has to be done via UDP, cause it will be a real-time game, there is no place for a lag. After switching updating positions to UDP, as we all know, some of the packets are lost. Sometimes the server is loosing some packets and it doesn't send them to the second client - that's why the opponent seems to move by 2x, not by x (it happens only sometimes).

My question is: How this kind of things should be implemented? How everything should be handled, I mean - sending states (walking, running), positions etc that there is no visible lagg? Should I send the packets more often? I heard once, that the server should also save player's positions and send it back to him and his opponent (to avoid cheating and laggs). I know how to implement these things, but I don't know how should it look like in a real-time fighting game.

If there is any experienced programmer, that could give me an advice, I would be grateful.

Answer 1

You will always run the risk of losing packets and having latency - you need to hide this from the player while trying to give reliable gameplay. If the data being sent is small you can simply send the current frame and the last 32 frames of data in a single packet. Mark each frame with a sequence number before you send it. On the receiving end the peer only consumes those pieces of data it has not yet seen. In this way you get some data redundancy. On the receiving end, you will also want a buffer to delay processing this data to help smooth out the 'jitter' of the latency. Latency is never constant, and you don't want to be processing the data exactly as it arrives or you might have block waiting for the next piece. Instead you want to artificially delay the data once received to give your peer more time to receive late packets.

There are a lot of other options here - you could use a snapshot system with delta compression (Gaffer covers a lot of this here and it is an excellent read: http://gafferongames.com/networked-physics/introduction-to-networked-physics/) and extrapolation to help guess where people are going to be. There are a lot of details to explore.