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

[Network] Improve network model #31

Open
SirLynix opened this issue Sep 5, 2024 · 0 comments
Open

[Network] Improve network model #31

SirLynix opened this issue Sep 5, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@SirLynix
Copy link
Member

SirLynix commented Sep 5, 2024

Currently, the network model works as follows:

  1. Each player sends their inputs at the network tickrate to the server
  2. Player inputs are stored in a per-player input queue
  3. On each tick, the server processes the first input in each player's queue to simulate physics and player actions, then removes it from the queue
  4. After ticking, the server sends the position of all entities to all players.

Player inputs are made of key state (forward/backward/etc.) along with pitch/yaw changes. The server has full authority on everything.

The client performs interpolation on all entities except its own controlled player, and performs client-side prediction on camera (which remains under server authority).

While this model provides a solid foundation, it has some limitations:

  • Since the client doesn't yet predict movement, there's an input lag on it:
    • This can be fixed by predicting movement, however this means a lot of physics entities have to be predicted as well (we could predict all physics entities but this may be heavy).
  • Input packets can be lost and that can causes rollbacks, to mitigate this, each input packet could include previous inputs (redundancy), since booleans are very small (and for pitch/yaw, send the difference relative to the last acknowledged input packet)
  • Currently, the server enqueues inputs without maintaining a specific queue length, which can cause problems like "ghost inputs" (players enqueuing inputs faster than the server is able to process them may cause a very large input delay). There are two ways to handle this:
    • Downstream throttle: allow the server to consume inputs faster or slower depending on how many inputs are sitting in the stack (by either merging or repeating inputs), This is easy to implement but causes prediction errors on the client.
    • Upstream throttle: The server instructs the client to skip a tick if there are too many inputs or to process an additional tick if there are too few. This method is more complex to implement.
@SirLynix SirLynix added the enhancement New feature or request label Sep 5, 2024
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

1 participant