1
\$\begingroup\$

I have a game that I am implementing a lockstep system for multiplayer on an RTS game. Now the server sends update packets at a higher frequency than the clients with new data.

What I'm stuck on understanding about lockstep systems is how does this tie in with the movement of the units. Should I only move the objects when a new update packet is received?

\$\endgroup\$
6
  • \$\begingroup\$ Are we talking rendering (eg. animation) or updating (do you have that distinction)? and are we talking client or server? Or is this P2P? \$\endgroup\$
    – Theraot
    Commented Sep 21, 2019 at 21:19
  • \$\begingroup\$ Rendering and this is for the client. \$\endgroup\$
    – Sammi3
    Commented Sep 21, 2019 at 22:13
  • 1
    \$\begingroup\$ What was your first plan or guess as to how to handle movement on the client? What do you find unsatisfactory about that approach? Identify a specific problem and we'll tend to be much more accurate in helping you solve it. \$\endgroup\$
    – DMGregory ♦
    Commented Sep 22, 2019 at 0:07
  • \$\begingroup\$ I added information on what I attempted and the problem that I encountered. Thanks \$\endgroup\$
    – Sammi3
    Commented Sep 22, 2019 at 9:47
  • \$\begingroup\$ Did you use the same latency value on every client (eg clients broadcasted their latency and everyone used the worst one) or each clients latency? Is your simulation deterministic? You'll have to elaborate more \$\endgroup\$
    – Bartimaeus
    Commented Sep 24, 2019 at 23:13

1 Answer 1

Reset to default
1
\$\begingroup\$

This answer is under the assumption of an authoritative server.

Should I only move the objects when a new update packet is received?

When the user issues an order, the client can start moving the objects, while the order is sent to the server. However, when the update comes from the server, you must synchronize the position to what the server says.

So, no, you are not obligated to only move objects when an update is received. However, that doesn't mean that you have to move objects without an update either. For intance, you have the objects change their animation, and play audio cues that indicate that the client registered the input... and then only move the objects when the update is received.

With that said, for a real time strategy game, you want to relay high level orders. For instance, instead of sending the position of a unit every update, just send its destination. If the client can do the same pathfinding than the server, it will result in the same path, and it is less network traffic.

There might be, of course, instances where the client simulation predicts the update from the server wrong. For example, assuming the client is kept in the dark about the state of whole map (the fog of war exists at network level※), if there is an obstacle that the client is unaware of, the client could pick a different path than the server... well, why would the unit be avoiding an obstacle that it should be unware of? Have the server do pathfinding ignoring anything controlled by other players that is not behind fog of war, so that it picks the path the client would pick.

※: Which is a good thing, because it means that snooping (intercepting) the network communication will not allow to get information of what happens outside of fog of war. And also, it is less network traffic.

You might be interesting in searching about "client-side prediction", "synced state" and "lag compensation".

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .