0
\$\begingroup\$

When the client clicks it spawns a unit on the client-side which moves in a predetermined path, it also emits an event to the server which indicates that the client has spawned a unit. Once received the server then spawns a unit and updates it.

Both the client and server's update loop occurs 60 times a second, every 5 iterations the server emits the new state to the client which is then applied.

This works fine for very low ping however when the ping increases the unit that is spawned moves for a while and then snaps back to the position it was spawned (because the server has only just received the event and emitted the new state).

What are the ways I can deal with this?

\$\endgroup\$
0
\$\begingroup\$

For something like this, it's useful to use an authoritative server model.

When your client spawns an entity - they don't. They're requesting that the server spawn an entity.

That entity doesn't become real until the server says so. Once you get a response back from the server saying "entity X spawned at time Y moving along path Z" you can realize that entity and match it perfectly with this and future messages from the server, without any conflict between your local simulation and a delayed version from the server.

Now this just leaves the problem of how to fill the milliseconds between the request and the response. If you just do nothing, the game looks laggy - the player doesn't know if the game "heard" their input, and might spam the button or yell at the screen for it to react.

So, we provide immediate feedback on the client - say a flashy "summoning" visual and sound effect that shows their input has been accepted and acted upon (and can help hide a "pop" of the unit appearing out of nowhere). Make this effect or animation long enough to cover a typical round-trip-time, and the player won't perceive a delay between their command and the action taking place, and you get smooth, consistent behaviour from there.

The visual effect should be something you can fast-forward or play while the unit is already in motion on other clients, since from their perspective, the command to summon the unit and the appearance of the unit in motion arrive in the same message from the server.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.