5 ms·

This covers dead-reckoning which is super interesting and tends to lead to designs where you "predict" things since that's easier to design for than reaction ba

This covers dead-reckoning which is super interesting and tends to lead to designs where you "predict" things since that's easier to design for than reaction based game models with latency. The other really common one is "lock step" where a common rng seed is shared and all player inputs are replicated. The game state then moves forward deterministically in "lock step" with all the players inputs. This is pretty common for RTS style games where a few inputs can drive thousands of units. Most also hash the game state and "resync" if a client is found to have diverged.

ggambetta 6y ago
The article isn't about dead reckoning. The "prediction" here is the client predicting its own movement based on its (stale) state of the world and its inputs; no dead reckoning here. For other entities, you get authoritative updates from the server at low frequencies, so you interpolate to get smooth movement, and you see them "in the past" in some sense; no dead reckoning here either. I've wrote about all this in extensive detail, including a live demo, here: https://gabrielgambetta.com/client-server-game-architecture.html https://gabrielgambetta.com/client-server-game-architecture.... (it is in fact the third "further reading" in the article).
- ramy_d 6y ago
  just wanted to say your networking articles (and demos!) are great and I have been pointing others to them since I first read them. Thank you!
  - ggambetta 6y ago
    You're welcome :) Glad to hear you've found my stuff useful.
- vvanders 6y ago
  I guess... I you really want to split semantics dead reckoning term[1] comes from predicting your self position(which the article talks about). Back when I was in games any sort of predictive interpolation was usually under the header of dead-reckoning. The big divergence for me was always prediction vs deterministic state at a fixed rate. [1] https://en.wikipedia.org/wiki/Dead_reckoning https://en.wikipedia.org/wiki/Dead_reckoning
  - ggambetta 6y ago
    Predicting your self position based on known inputs, not on extrapolating your current position based on velocity and acceleration. With FPS-like controls with no inertia, you can absolutely do CSP without a trace of dead reckoning.

ggambetta 6y ago

The article isn't about dead reckoning. The "prediction" here is the client predicting its own movement based on its (stale) state of the world and its inputs; no dead reckoning here. For other entities, you get authoritative updates from the server at low frequencies, so you interpolate to get smooth movement, and you see them "in the past" in some sense; no dead reckoning here either. I've wrote about all this in extensive detail, including a live demo, here: https://gabrielgambetta.com/client-server-game-architecture.html https://gabrielgambetta.com/client-server-game-architecture.... (it is in fact the third "further reading" in the article).

ramy_d 6y ago
just wanted to say your networking articles (and demos!) are great and I have been pointing others to them since I first read them. Thank you!
- ggambetta 6y ago
  You're welcome :) Glad to hear you've found my stuff useful.
vvanders 6y ago
I guess... I you really want to split semantics dead reckoning term[1] comes from predicting your self position(which the article talks about). Back when I was in games any sort of predictive interpolation was usually under the header of dead-reckoning. The big divergence for me was always prediction vs deterministic state at a fixed rate. [1] https://en.wikipedia.org/wiki/Dead_reckoning https://en.wikipedia.org/wiki/Dead_reckoning
- ggambetta 6y ago
  Predicting your self position based on known inputs, not on extrapolating your current position based on velocity and acceleration. With FPS-like controls with no inertia, you can absolutely do CSP without a trace of dead reckoning.