The question is about how to make all players to move right the same pos in all machines. There is always a little time when messages are on their way. Some messages take longer time that others. The result is that cars (yes, its 3d-racing sim) seem to be jumping a little forw and backw. They should move smoothly. Currently I use linear interpolation, I'll make it better ie three point interpolation. But thats not the question of interpolation. I added a counter alue to my message to ignore messages that arrive too late (message should have higher counter value than messages alrteady arrived). It doesn't still move smoothly. What are good ways to make caars move smoothly and identical positions in all machines? How is it in commericial games? I thought something like this: I include a clock value to messages. Then when message arrives to other player, it calcs the delta between the messages clock value and system clock (msecs). this delta is used every time used to calc average delta. So I know the average delta between every two pairs of players and the current messages delta, so I can do more precice timing (I know how much later or earlier the message arrived comparing to the average value). Implementing that together with three point interpolation should I have quite a good result? What do you think? Edited by - stefu on April 26, 2001 6:04:52 AM

Most games use some form of timmer syncronization scheme. Some use avg round trip latency, some use NTP, some use heart beat method, etc..

Simple method, have the server send you its time every say 1/sec. When you recive that time you set that to be your local time, which all calcuation and packets are processed too. Of course inbetween the ticks, your clock goes forward as normal. Problems with this is its very senestive to line condtion, loss and latency.

Another method, you send a ping packet with your time, the server responds with its time and the clients time (which was sent with the packet, you''ll need this). The client recives this find its round trip latency, and find the current server time best it can. Usually just assume the server is 1/2 round trip latency away. So servers time + 1/2 round trip latency is your new clock time. Its alittle better than method 1, in that it takes into account your latency to determine the servers time. It has pretty much the same problems as the first, loss and latency effects it alot.

Third method, do exactly the same thing as method 2 but keep a record of pings. Perform some statstical analysis on the list, and use the best 20% pings to calcuate the server time at that moment. This give you more robustness in terms of loss and latency, and higher accuracy too.

Now you have somewhat syncrhonzied timmers. You can use this to improve your client side interperlation/extrapalation calcuations, perform retroactive commands, etc..

Good Luck

-ddn

I was thinking of al kind of methods, but the third is what I was looking for. Thank you very much!