Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce stuttering when sending ships over the network #16

Open
nitzel opened this issue Apr 19, 2019 · 0 comments
Open

Reduce stuttering when sending ships over the network #16

nitzel opened this issue Apr 19, 2019 · 0 comments

Comments

@nitzel
Copy link
Owner

nitzel commented Apr 19, 2019

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.
nitzel added a commit that referenced this issue Apr 20, 2019
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant