1v1 real-time game - UDP - resending player's lost position packets

Networking & Multiplayer
#1

Hello. I’ve read http://gabrielgambetta.com/fpm2.html && http://gafferongames.com/networking-for-game-programmers/reliability-and-flow-control/

p-pos = player’s position
#edit - i’m using Kryonet if this helps

I know, that there is a lot of knowledge in above links, but I still don’t understand how this flow-control should work. My problem was that some of the p-pos packets were lost, that’s how my character was moving from x==0 to x==2 (by two steps per tick on the opponent’s phone). That’s ‘normal’ with UDP. Guys on stack.gamedev gave me these links, to make the ‘packetflow’ more ‘reliable’. So - my problem is here that I don’t understand how it should work. I know that I just need to put a ‘sequenceNumber’ into each packet and increment it. On the server I need to check which packet was delivered last and ‘compare’ them???

The second thing is that this is a solution for one move right? Let’s see:

  • User inputs ‘move right’ into the Client
  • Client sends the request to the server ‘can i move right’ and ‘moves by one without confirmation’ cause it’s smart
  • Server allows him to move
  • while checking he reads client’s sequenceNumber and compares it with the current sequenceNumber on the server. If received is bigger than current, we allow to move (or something like that)

The point is here. If we move on the phone by 30 steps (step by step, but fast, we run) we send 30 packets, and let’s say that 14th packet is lost. What happens? It was explained in a second link, that we should send a bytearray with ‘30 positions’ or something, which I don’t get too (or we should save 30 last positions).

If there is anyone that could explain, how this should work, I would be very grateful. I know that this is hard but I can’t use TCP for this kind of game. And I just want to learn it - I just need a point, how it should look like in 5-10 steps.

Thank you.

#2

You should probably not send positions but direction and speed, so you only need to send packages when the direction of the movement changes. If you send these packets using sequence numbers, you can detect a missing packet on the server, but you may need to give the missing packet some time to arrive out of order.

If the package is really missing, you can ask the client for a new “baseline” packet, meaning the current position, speed and direction, so the server can catch up. It might also be a good idea for the client to proactively send these packets from time to time to get a “keyframe” reset, from wich the server should interpolate the position based on speed and direction updates.

You might also need to simulate collisions on the server as well as on all clients independently and blend the simulation with the packet updates to not have players stuck in obstacles and such.

All-in-all this is pretty hard stuff to get right…

#3

If it’s only 1v1, there’s no need for an authoritative server; take the simple route and make it deterministic lockstep between equal peers.
Much simpler to implement and lower bandwidth requirements, though less flexible if the scope of your project changes.

#4

Thank you very much for your answers.

Abuse, I’m so happy to hear that there is no need for an authoritative server. I thought the same. This is a small mobile game, but I don’t know if that simple way will be enough, cause I will implement fighting, knockbacks and collisions.

Could you tell me, what do you mean by ‘making deterministic lockstep between equal peers’ ? Should I just not predict the movement like it was proposed in above links and focus on a real-time packets sending? If yes, how these ‘lost packets’ should be handled (I mean, the ‘more than one step’ moves on the opponent phones)? Should I just make collisions/fighting/animations like:

  • Client (request) - can I jump?
  • Server (response) - yes/no
  • Client - make a jump packet, update position packet, update animation packet

I’m grateful that finally professional programmers are helping… :slight_smile:

#5

Be advised that if both peers are behind NATs, such as when playing at their homes with WLAN behind routers, having no public IP server becomes an issue since it is very likely that neither of them will be able to connect to each other. Yes, there are hole punching techniques, but they don’t work with all NATs.
Though I don’t know how much of an issue this is with UMTS, but I am quite certain that mobile phones will also not have an internet-accessible IP address when logged into a base station, but the base station plays proxy. In which case no unsolicited packet can reach them from the internet.
To solve this you always need a third party (server) with a public IP that in the best case simply does the IP/port negotiation between the two peers (if their NATs allow this) or in the worst case has to tunnel-through the whole communication.

#6

Oh my god, I misunderstood! Abuse by peers meant making the server locally right? It’s not possible. I have my own dedicated server and I need to place the server there. It runs the queueing, all of the gamerooms etc. And here we come to the start - it seems that I need to make the ‘flow-control’, cause physically I don’t see another way for everything running smoothly and in a real time on both devices…