Hello.
I’m having a bit of trouble with synchronizing client and server. In football game I’m working on, ball when kicked is very fast. I send 20 msgs / sec with (among other game data) ball position, speed, height and so on. When client receives the message he updates ball data instantly and uses dead reckoning until next update (which is’t very hard since it’s just position, direction and speed). Whole thing works, but isn’t visually very nice. Ball keeps jiggleing as every update corrects it a little, and when player kicks the ball on client ball is teleported a bit infront of him since update that came put ball there, and there was no way to anticipate the kick.
I have a idea how to fix this, not to update ball data to absolute position every time but just to make it go more in right (real) direction and find compromise between smoothness and correct data that way. Are there better ways? Can anyone recommend a tutorial or a book on this matter? Thank you.
Synchronisiation across a network is a pain, any information you send is out of date by the time any other client recieves it. I have a similar issue.
One solution I came up with is as follows.
Pick one object to be a time sync server. I’m in a client/server environment, so for me, it’s just the server. Then periodically, get each client to send it a message, the client records when it sent it. The server responds with it’s own time. The client then records when it recieved the responce. Using when it sent the request, and when it got the responce it knows the round trip time, and adds 1/2 of it to the server time (the server sent the responce that long ago) and notes an offset, so it knows the difference between the server clock, and it’s clock.
Each position update the client sends, it send it with a timestamp adjusted to reflect the server clock at that time.
Recieving clients then know resonably accuratly when that position was correct, again adjusting for server time, it knows how long ago that was, and interpolates the known positions. The data model predicts where the ball will be at some point in the future, based off the known location in the past. The graphics model knows where the ball was last rendered, and where it’s predicted to be, and moves the ball in that direction.
You don’t end up with a 100% accurate view of the world, but you end up with a reasonable one, and one that looks smooth too.
HTH
Endolf
Hm, after kicking the ball, its trajectory is completely determined until something else happens. So why do you send 20 messages/sec with information everybody could know anyway?
With your approach you are really begging for latency issues and thats what you get.
If you are going like that, you have to improve your smoothing. Never realize a position received from the network. Use timestamps (and a synchronized clock) and treat incoming information as a hint to correct the current path. Remember that all messages from the network come out of the past!
First of all I’m sorry, I taked some pause from this project (so I didn’t tried anything in meantime), I’ll get back to it soon.
20 msg/sec is a must since players are moving also, and rapidly. I could bring it down to 10 msg/sec but then mistakes from dead reckoning calc. are not acceptable by my standards. Anyway number of msg/sec isn’t a big deal, I can adjust it later.
Huh? How do I “beg for latency issues”? Ball is moved by dead reckoning calculations made by client until new message arrives.
Thank you for your advices, both of you.
Before I tried to send ball info message just when status of ball has changed, like it bounced or somebody took it. It wasn’t at all what I expected as ball started bouncing from nothing on client, where it should have bounced on a wall just like on server. It like bounced 50 pixels before it should. Yeah I know I don’t have a synchronized clock, but when looking at speed of ball 50 pix feels way too much even if max delay could be 53ms (50ms interval between messages and 3 ms travel time).
I hope It will all be better when I synchronize clocks. First I want to make ball go smooth and nice with sending 20 msg/sec data about it, and then send data only when ball trajectory is changed.
One thing I’m really courious is how to display kick of the ball on client, since when ball is kicked it takes some time for message to travel to clients and then client ball is teleported a bit in front of player. I guess when ball is kicked I should instantly send a message about it, and when client receives the message he could drasticly speed up the ball first few frames until it gets to synchronized position.
I’ve figured out that I could get back on the project sometime in near future… anyone has a link to a simple tutorial about synchronizing clocks between server and client? I know basic theory, but it would be so much easier to see a small “real” example first.
Google: “vector clocks”
FlyingGuns has a simple clock synchronization. Around here:
http://drts.cvs.sourceforge.net/drts/projects/headquarter/core/java/de/hardcode/hq/time/
Unless I misunderstood, all that gives you is the relative order of events, not clock synchronisation though.
Endolf