![]() ![]() If lag increases or there's packet loss, things might get choppy, but it's trivial to catch up, essentially just waiting for the next update. The other clients will just try to stay in sync to the host, trying to estimate or approximate the expected value. The host will now perform all important game logic, like hit detection, AI controls, inventory handling, etc. If you don't have a dedicated server, elect one participating client to become the host (this can be transferred if the need arises to). The good news is that you probably don't need that much accuracy.Īs mentioned, this is impossible, so I'd try another approach: The second is trickier and may be theoretically impossible to solve (though I can't remember the proof right now). The first you can reduce the effects of by performing the measurement several times and taking a median reading. This can't guarantee synchronisation because the time taken to send a message across the internet varies, and because it can be different in each direction. Client 2 will get the message about 4ms later, but will wait 4ms less before starting the game. So you send out a message to Client 1 saying "start the game in 50ms" and send one to Client 2 saying "start the game in 46ms".You do the same for Client 2 and get a response 28ms later - so the transmission time there is likely to be about 14ms.You guess that it takes roughly 10ms to get a message to client 1. You send a message to Client 1 and get a response back 20ms later.Luckily, in practice you can come close, which is how things like NTP work.įor example, better than just sending a message out to 3 clients saying "start now", you can exchange a couple of ping messages beforehand to measure the time it takes to get a message to the client, and when you send the start message, instead of "start now" say "start in X milliseconds" and adjust X for the different times taken for a message to arrive. Steven's comment is right: this is theoretically impossible to do. ![]()
0 Comments
Leave a Reply. |