crystalorb icon indicating copy to clipboard operation
crystalorb copied to clipboard

Consider supporting other kinds of synchronization strategies

Open ErnWong opened this issue 3 years ago • 3 comments

For example, to reduce jerking movement and teleportation so that shooter games can be somewhat playable, it might be nice to display other players in the past (i.e. only render them at positions that have been confirmed by the server), potentially at the expense of lower performance or higher memory footprint.

Some initial exploratory work has started on the abstract-simulator branch (which may be renamed or deleted by the time you're reading this, but don't worry, I'll link to the corresponding PR when it's available).

ErnWong avatar Jun 09 '21 13:06 ErnWong

So far, I can think of the following matrix of different "strategies" for the client:

Past Future
Simulated Delayed Predictive
Not Simulated Interpolative Extrapolative

The "strategy" currently implemented in the client (contained in the horribly named ClientWorldSimulations struct) is the Predictive strategy.

Not sure if the Extrapolative is actually useful since it probably can't react to user's input immediately (but at least it crudely estimates where, say, enemies are located, allowing the player to take a somewhat accurate action. However, this one probably suffers from the most amount of jerk and teleportation).

In addition to these core strategies, we can combine some of them for an enhanced player experience. In particular, one could combine Predictive and Delayed, or Predictive and Interpolative, where we use Predictive for the current player and props while we use Interpolative/Delayed for other players. It will be useful for the server to also get the corresponding display states that the client sees at any timestamp so that the server can validate hit commands correctly. There are two ways the server can handle this:

  • The server can use the exact same strategies as the client to get the exact world state that the client sees. This seems to be inefficient. Moreover, we can't guarantee that the same strategy will lead to the same results, since the strategies are not deterministic: It depends on the timing of the arrival of server snapshots, and some server snapshots could get dropped in the network.
  • A better approach might be for the server to only care about whether the client sees the Future and/or the Past. Perhaps, by default, it cares about both, and let the server command validation function to use or ignore them, but if we want the game to be fully optimised, we should allow the ability to enable only the ones we need. As for actually getting the Future and Past states, the server can either: (1) run two world simulations, or (2) run one world simulation and keep a circular buffer of the old world states. It depends if we want to be memory-hungry or CPU-hungry.

ErnWong avatar Jun 09 '21 23:06 ErnWong

Have you taken a look at how GGPO/Backroll does their synchronization? It's a peer to peer system but It might be cool if you could support it somehow. https://github.com/pond3r/ggpo https://github.com/HouraiTeahouse/backroll-rs/

ValorZard avatar Jun 10 '21 21:06 ValorZard

I haven't yet, but I'll definitely read up on them when I get time for sure. Thanks for the links!

ErnWong avatar Jun 10 '21 22:06 ErnWong