Real Time UDP position packets (and states) strategy Client-Server-Client

Hello everyone!

I am creating a real-time game over UDP protocol. My server is written in Java, using Kryonet lib, and client is working on Android. I need an advice from experienced game-programmers, cause this is not that simple as I thought.

This game has to be a real-time game, which means that I need to move my character on opponent’s phone immediately. To do that, I need to implement a system, which will send UDP packets with my position and current state (walking, jumping - just for loading graphics), but I need to handle lags, smoothness etc.

My first idea was:


We have a sequence number which will increase with every packet ‘packed’.
In a gameloop we take current coordinates (X,Y), our state (for ex. running_right) and a current ‘ClientSequenceNumber’ and pack these values into one object.
Next, we add this object to a list of ‘32 previous packets’ and SEND THE LIST TO THE SERVER.

Here comes the problem number one. If we lose 1 list, 3 lists, 30 lists, we’re good, cause we will have previous positions in the next incoming list, BUT
if we lose more than 32 lists, we’re stuck cause for example:

Let’s say that we’ve lost 40 lists…
On the client we have a list with sequence numbers: 100 - 132.
On the server we have ‘current server’s sequence number’ == 60.
Okay, of course we can just process 100-132, but it will move the character from for ex. x = 30 to x = 90, which is unacceptable.
So we need to implement some ‘confirmation system’ or something, which will resend packets.

I thought about a solution, but I don’t know if it’s good:
When we create a list of 32 packets, we can store it in a ‘history’ on the client
When server uses that list, it sends an info to client ‘you can delete that list, it’s done’.
But we have to resend these old lists all the time, to keep things smooth, which is probably wrong, cause we’re resending not only normal lists, but also history lists LOL.
Here comes one big trouble and I totally don’t know how to think about it.

I read some gafferongames websites, but it still does not give an answer.
If there is someone that could help, handled these problems in the past, I would be grateful for help and understanding.
I just need a confirmation, if my idea is good, or totally wrong and I should implement 1v1 UDP in totally another way.

Well, read it again

read this:

watch this:

read this:

Based on your post I can’t even figure out what kind of system you’re trying to implement. How about you tell us about your game and what you’re trying to do (how many clients, how real time etc) and come with more specific question that we can help with.

All you have to do is when you receive a list is just send confirmation back that you got that list. As the sender keep sending that list until you get confirmation from the receiver, once you get confirmation then stop sending that list.

As far as what happens if you don’t have enough info to continue, you have to pause the game and try to reconnect/wait for those packets there isn’t a way around that. There are ways to fake it with predication(which can only do so much) but it’s far easier to just say “trying to reconnect”.

Thank you guys for your replies.


For now, I try to create only movement and jumping, Im preparing the whole system for further implementations like combat etc.

I need to make sure, that the system that I will write will be stable and reliable.

It is a simple 1v1 movement. When I move on my phone, opponent on his phone sees that I move. When I jump, I jump on his phone too.

I need to handle laggs, packet drops etc, that’s why I need to implement on my own way.

thedanisaur - thank you very much. Unfortunately, I can’t make it ‘reconnecting’ cause in my opinion, it’s not professional. An easier option is not an option :frowning:

When we block the buffer, resend and wait for confirmation, the character is stuck. I need to make it smarter, predict the movement. When lagg comes, of course, it comes, I will just take the character back, but on opponents phone, it can’t move. Server must be authoritative and ‘let’ the move be ‘made’.