I have been working on a football game for 2 months and while I have found a semi decent solution to this, my ball has a problem. On high ping(175+) the ball can lag behind the player, due to me doing the ball physics on the server after getting player orientation from client, while setting network owner to the server. The first solution to this would be to have the ball physics done on client, but how would i achieve this while syncing the ball position to the other clients?
To clarify, I have tried doing client → server → client (Server just handles calculation of ball trajectory) but this is where their are inconsistencies with other clients.
You can’t really do much if a player has high ping. If you were to calculate the ball on the client with any ping higher that 100ms, the data packets would take too long to transfer. Whereas, if another client was waiting with 20ms ping, they’d have to wait a long time:
server (0ms) > client 1 (100ms) Server asks client 1 to calculate. Runservice.Heartbeat server (0ms) > client 2 (20ms) > server (40ms) client 2 waiting for an ball calculation. Runservice.Heartbeat server (0ms) > client 2 (20ms) > server (40ms) client 2 waiting for an ball calculation. Runservice.Heartbeat client 1 (100ms) > sever (200ms) client 1 finally calculates and sends back to server. Runservice.Heartbeat server (0ms) > client 2 (20ms) > server (40ms) client 2 waiting for an ball calculation. Runservice.Heartbeat server (0ms) > client 2 (20ms) > server (40ms)client 2 receives the update next tick. RunService.Heartbeat
This, of course, is a strong abstraction of what happens under the hood, but to summarise, the client 2 would have to wait 6+ ticks for the ball to update, which would cause visible lag.
A way you could attempt to fix this would be to try and make the ball a predictable entity on the client. What this means is, each client would try and predict where the ball will go next on their screen. A good example about this would be CS:GOs entity prediction: Prediction - Valve Developer Community
This in turn, would cause stutter if the code is written incorrectly, like not accounting for collision with other characters.
Not that I know of unfortunately, I’ll take a look and try to find something but I feel like you might have to take reference from other games off-platform.
Actually found a solution tonight for client → server → client with no jitter / lag. Also the way to check. So what youd have two balls, set network ownership before you send out to – 1 CLIENT – (since it will be replicated to all alr, you dont need to send to all clients, it will make the ball move weird), but before you send the actual values to be translated for client, send dummy values (all zeroes) and put a task.wait() before you send real values, so that there is no jitter for network ownership. It fixed the jitter for me. After that youd have to do sanity checks on every hit with a server ball, which should not be that hard, just make a server ball and have it do physics from server alone, by either just setting ball to nil in a stepped loop coroutine (my method, coroutine prolly not needed) or just set to nil every time you hit the client ball. Actually works pretty well, and the client always has fluid gameplay.