5
\$\begingroup\$

I understand how properly connected clients in a lockstep model deal with lag but what about the lagger? How does the lagger know that he or she is lagging? Should I continuously ping the central server?

Also, as the game follows the lockstep model, how does the lagger sync if he needs to? Should the desync be altogether prevented by fast pinging?

\$\endgroup\$
4
  • 2
    \$\begingroup\$ Some of these questions may help: 1 2 3 4 5 \$\endgroup\$
    – anon
    Commented Jan 8, 2015 at 2:24
  • \$\begingroup\$ Thanks for the response. Most of the questions weren't much help because they were centered around asynchronous networking models but I did gleam some insight from #3. I think to deal with determinism, I'll cache every recent frame.I still have the problem of letting the lagging player know he's lagging so he can reset back to a cached position. \$\endgroup\$
    – JPtheK9
    Commented Jan 8, 2015 at 2:51
  • \$\begingroup\$ Wait, do you mean lcokstep protocol? As in the protocol used to prevent look ahead cheating in online peer2peer games? If this is the case, the model has nothing to do with dealing with lag. It has to do with cheating by waiting for other player actions before you choose an action. What kind of game are you working on where this model is relevant and also how does that has anything to do with lag? You know you are lagging when you don't get frequent updates... You should be getting frequent updates if your connection is working, right? \$\endgroup\$
    – AturSams
    Commented Jan 9, 2015 at 18:53
  • \$\begingroup\$ The lockstep networking system I'm talking about can be found here: zoo.cs.yale.edu/classes/cs538/readings/papers/…. It's a system that involves syncing every client to have exactly the same games based on series of inputs that's popular for RTS games. I suppose it can prevent 'look ahead', or rather, it makes it pointless. The way a lockstep works is it sends an RPC every time someone makes a command and the game acts based on that command so no, there aren't necessarily frequent updates - only as needed. I found a solution that's caching up all data for past second. \$\endgroup\$
    – JPtheK9
    Commented Jan 9, 2015 at 19:19

1 Answer 1

Reset to default
4
\$\begingroup\$

You can safely throw out Ping from the board.

Lag compensating can work relying on just number of ticks for which commands were received (including NoCommand commands) and confirmed. Since the game is p2p (via server or not it does not matter), each client has number of packets from other clients queued for execution and confirmations of packets he sent.

Now in a lag-less situation each client has roughly the same number of commands/confirmations queued. If there are too many command queued ahead, client can adjust ticks duration to catch up with the plan and reduce the number planned ticks (or plan less commands ahead).

If there's a lag environment, even if one client is lagging, all will, since lag affects both commands received and confirmed. In such situation, clients will need to pause and wait for commands/confirmations to arrive, to fill up the queue. Once the queue is filled with at least one command/confirmation client can make another step. While at that, clients can send several NoCommand commands, to increase the queue length (which will compensate lag better, but make the game less responsive).

All of that can be managed through a server, in centralized manner, or individually. The system is self-balancing and that's the beauty of it.

\$\endgroup\$
6
  • \$\begingroup\$ Suppose I have two players named A and B connected directly together - no intermediate server. If A has sent commands to B and received commands from B, A can assume that its commands to B already arrived? That doesn't make sense to me - it seems to me that upload and download speeds are generally different. Plus if A was sending a lot more data than B was... wouldn't B take longer to receive data from A than A would from B? So it seems like they're not symmetrical - A could have all the data but wouldn't realize that B doesn't have all the data... right? \$\endgroup\$
    – ArtOfWarfare
    Commented Aug 20, 2015 at 12:51
  • \$\begingroup\$ If A has received commands from B, he can run his next frame regardless of whether B has received commands from A, as long as B eventually gets commands from A. Detecting that B does not eventually get commands from A can be done by having B not sending commands for the next frame if B has not received commands for this frame. By not sending data for the next frame, A will remain "stuck" because it does not get commands for the next frame, thus keeping everyone near the same frame. \$\endgroup\$
    – JPtheK9
    Commented Aug 20, 2015 at 13:18
  • \$\begingroup\$ @ArtOfWarfare: Don't forget about "commands received" confirmations ;-) \$\endgroup\$
    – Kromster
    Commented Aug 20, 2015 at 14:27
  • \$\begingroup\$ @JPtheK9 - Is that really how, IE, StarCraft does it? It seems to me that "near the same frame" isn't good enough - you can't have a competition where people are "near the same frame" because one player is able to see newer things that the other can't. Plus they have the potential to drift even further out of sync. \$\endgroup\$
    – ArtOfWarfare
    Commented Aug 20, 2015 at 14:44
  • \$\begingroup\$ Obviously competitions have conditions that reduce lag as much as possible. For the casual player, being several hundred milliseconds or so behind isn't a big deal. \$\endgroup\$
    – JPtheK9
    Commented Aug 21, 2015 at 2:36

You must log in to answer this question.

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