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

Consider supporting other kinds of synchronization strategies #4

Open
ErnWong opened this issue Jun 9, 2021 · 3 comments
Open

Consider supporting other kinds of synchronization strategies #4

ErnWong opened this issue Jun 9, 2021 · 3 comments
Labels
enhancement New feature or request

Comments

@ErnWong
Copy link
Owner

ErnWong commented Jun 9, 2021

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
Copy link
Owner Author

ErnWong commented Jun 9, 2021

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.

@ValorZard
Copy link

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/

@ErnWong
Copy link
Owner Author

ErnWong commented Jun 10, 2021

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

@ErnWong ErnWong added the enhancement New feature or request label Oct 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants