You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each player sends their inputs at the network tickrate to the server
Player inputs are stored in a per-player input queue
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
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.
The text was updated successfully, but these errors were encountered:
Currently, the network model works as follows:
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:
The text was updated successfully, but these errors were encountered: