You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a client sends a moving ship to a new location the client will see the ship stutter because of the network delay:
For RTT/2 the ship continues straight on.
The packet arrives at the server. The server changes the ships direction and broadcasts that change.
Clients: For RTT/2 the ship travels in the old direction. Server: For RTT/2 the ship travels in the new direction.
Packet with new location and direction arrives at the clients. Their location is now up to RTT * velocity off from where the ship should be - and the ship jumps.
Possible solutions:
For the client issueing the command we could improve the stuttering by sending the ship locally to location + RTT/2*velocity + RTT/2*expected_veloctiy_from_server so that it'll arrive at the location that the server broadcasts when the broadcast arrives at t=RTT.
The server could attach a timestamp of now + max(client1_RTT, client2_RTT, ...)/2 to the command and trigger the move of the ship when that time is reached. The clients do the same. That'll probably lead to lag experience by the command issueing client as it'll take at least RTT before the ship changes direction. In the current scenario the command is only issued with a delay of RTT/2.
The text was updated successfully, but these errors were encountered:
…latency and perceived stutter. Client also doesn't send it's own ships to the new location but instead waits for confirmation from the server. That way both clients should a) nearly always see the same and b) the ships dont jump backwards so much.
When a client sends a moving ship to a new location the client will see the ship stutter because of the network delay:
RTT/2
the ship continues straight on.RTT/2
the ship travels in the old direction. Server: ForRTT/2
the ship travels in the new direction.RTT * velocity
off from where the ship should be - and the ship jumps.Possible solutions:
location + RTT/2*velocity + RTT/2*expected_veloctiy_from_server
so that it'll arrive at the location that the server broadcasts when the broadcast arrives att=RTT
.now + max(client1_RTT, client2_RTT, ...)/2
to the command and trigger the move of the ship when that time is reached. The clients do the same. That'll probably lead tolag
experience by the command issueing client as it'll take at leastRTT
before the ship changes direction. In the current scenario the command is only issued with a delay ofRTT/2
.The text was updated successfully, but these errors were encountered: