Skip to main content
GameDev.net gamedev.net
🔒 Locked

Dealing with High Lag and Packet Loss

Started by FallenDarkScythe Feb 8, 2012 at 10:48 AM 4 replies 2.1k views
Original Post
FallenDarkScythe
FallenDarkScythe
[color=#111111][font=Helvetica, Arial, sans-serif]

Hi, im making some tests about player syncronization in a fps game.[/font]
[color=#111111][font=Helvetica, Arial, sans-serif]

I ve recently learned that xboxLA games are expected to be played with a max ping of 200 and a max loss ratio of %10(a bit high i think?). So i started with the general approach and send movement commands to server, get the correction from server, get back in time and fix etc. I failed to do it properly by sending velocities and tried to send delta position values. And also i gave sequence numbers to my action recordings instead of timestamps. It worked perfect even with 300-400 ping values. But when it comes to packet loss everyting went down. To deal with both i tried sending key press values instead of direct position changes. It handled packet loss very well, it prevents speedhack etc. and also saves a lot of bandwidth but this time it seems impossible to sync with servers player position. Server runs at different speed, client is different and latency values change over time so if i press a button for 1 seconds it may last 1.2 seconds on server. So im planning to turn back to the previous approach and find a way to handle packet loss or anyone have an idea if it can be done properly by sending only key press values.[/font]

[color=#111111][font=Helvetica, Arial, sans-serif]

Thanks in advance.[/font]

rip-off
rip-off
Have you read the articles linked in Question 12 of the forum FAQ about how real games handled these issues?
blog | twitter
FallenDarkScythe
FallenDarkScythe
thank you, i'll read it.
I have read the valve's documents and I have succesfully implemented entity interpolation/extrapolation. The issue is about the player prediction. In a scenrio where the movement algorithm is deterministic, lets say the user preses W and immidiately starts moving on the client and after 100ms starts moving on the server. After 1 second the user releases the W key and because of network glitches the server receives this command after 250 ms. So the servers movement took 1.15 seconds which is more than the player actually moved on the client. The server is authorative so this is fixed later but causes a snapping. I can overcome this by sending velocity or position changes but i am not sure if it is doable by only sending key commands.
hplus0603
hplus0603
You need to timestamp each event by game tick. Additionally, you should pack the last N keypresses into each update message. If you use run-length encoding, that will likely not take up much more space than just sending one keypress.
enum Bool { True, False, FileNotFound };
FallenDarkScythe
FallenDarkScythe
i am sending 10-15 commands per second but between this 66-100ms i can freely change my orientation but the server will only receive the orientation at the time of sending. so this leads to some difference between client and server while making a move with changing directions. i came to a conclusion for myself that this wont be properly solved with sending key commands, i understand now that both epic and valve is doing this without sending key press/release commands.
hplus0603
hplus0603
To be consistent, you need to use a fixed physics update rate. Then, you need to have the simulation inputs available for each physics update tick. If you send packets more seldom than you tick physics, then each packet needs to include data for more than one physics tick. If you send lossy packets, then it's usually a good idea to "double" or "triple" up the number of ticks you include in a packet to the server, so that if one packet is lost, you will still have data for all time steps when the next packet arrives.
enum Bool { True, False, FileNotFound };

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.