Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

SmG

Network Prediction Problem

This topic is 6150 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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


Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!