Network Prediction Problem

Started by
4 comments, last by SmG 22 years, 4 months ago
Hi, I''m having a big problem with my network code. I made it using winsock and UDP. The problem is the prediction. I have a dedicated server and then i connect to it. now each player sends a packet with his position, velocity and the keys pressed on his keyboard 5 times per second. Then the server sends packets with the positions of every player to the clients, but on the clients the other players jump around. I have some different smoothing algorithms and the work fine, but sometimes the player jumps back and forward, as if a packet with an older position arrived later because of lag. to avoid this i gave serial numbers to the packet, but the problem is still there. I think its because of the server side prediction of client movements and when the client sends his new position to the server it is wrong and the updated position is send to the clients wich causes the player to jump back. But what i dont understand is, that even if i leave the controls the player, wich should move on with his last velocity, this effect occours. both, the client and the server, share the same physic and movement funtions, so there should be the same movement on the server and the client... hope anyone had a similar problem (and solved it) :D
Advertisement
The broadcast packet needs a client originator ID and a ''tick'' counter. That way when the client recieves a broadcast it can look the client originator and get the last tick recieved, if the packet has a tick that is smaller, discard it. When ever a client sends it''s packet to the server it increments the tick. The server will follow the same process of discarding older ticks.

Generally a client will keep the position and vector of each other client and update the other players automatyically using the last packet information. That way the clients can be ''disconected'' from each other for a few moments, and still have their positions ''predicted'' on other client machines. Whenever a broadcast is recieved just update the positional and vector data. This may cause a ''jump'' but this cannot be avoided.



D.V.

Carpe Diem
D.V.Carpe Diem
What your seeing is artifact of the network latency. Lag has 2 components the average time traveled for a packet and it''s standard deviation from that average ping.

The stdv (standard deviation) measures the dispersion of the pings. The smaller the stdv the more consisent the lag and given a simple packet timming scheme, you wont see much jumping, like what you sometimes see.

However when stdv is high (50% of ping), you will see this jumping motion. Discarding old packets won''t fix it becuase it''s not old packets causing the problem. Your using the latest packets but they are arriving +/- stdv. Which if large and your entites moving fast enough could result in a noticable disparity with the given packet position and your entites current position.

To solve this use a network timming algorithim such as NTP. Look on www.codewhore.com for a good description. Once you have a global timmer, you can project the packets info into the current time of your client and use that. The accuracy of that projection will be limited by NTPs accuracy which is about 10 ms. So unless your entites are moving extremely fast, it should be dead on.

Once that is solved you can work on optimizing packet size and handling packet loss.

Good Luck!

-ddn


Ok, i have now switched off all smoothing and client-side prediction functions, inceased the packet frequency to 30 times per second and even left the movement to the server prediction,so the client only sends his keys to the server, he moves the player and sends his postion back to the client. I''ve done this to see the exact predicted data the server sends to the clients and i think the problem is the predicted movement. even if its the same function the movement is different than what the client would behave like.
i have a function wich modifies the speed of players with a factor to receive the same movement on a slow system as on a fast PC. the dedicated server is much faster than the client, because he doesn''t have to draw the world or react to player input, so the speed of a player is reduced to a very small value and i think this is too small for the float data type. because of this the player on the server moves only in 90°.

i have spend much time in the prediction and smoothing algorithms and i have found a way to reduce the effects of lag to a very high amount. even with a ping of 500 the other players do not see any lag. if i found out how to solve this problem i will perhaps write something about my method, because i don''t know if anyone has tried this before.

i hope at least something was understandable

[img]http://www.stu-clan.net/render/smgfull.jpg[/img]
yeah its really a problem of the float precision. because the dedicated server is MUCH faster than the clients, the ''grid'' in wich the players move is much smaller. the precision of the float data type is not capable of such a small amount of differences in velocities. the only way how i can avoid this problem is to increase the size of this ''grid'' and slow down the server prediction speed.

ok, ich changed a server prediction frame to at least 10ms and now the gameplay is smooth as silk , even with all smoothing functions off with 30 packets per second over LAN.


And thx for your help

This topic is closed to new replies.

Advertisement