Game Networking
- Stepping the game state: advancing the state by one tick
- Prediction: given the state of an entity in the past, predict the state of an entity at a later point in time. Prediction can be done e.g. by:
- extrapolating the entity's properties (e.g.
xandy) by using a simple projection (e.g.pos' = pos + v*deltaTime) - generate a predicted state by stepping the state received from the server until it reaches your client's "present"
- extrapolating the entity's properties (e.g.
On the client, when sending an input, instead of waiting for confirmation by the server, apply it directly to the game state and let it affect things.
- Problem: when sending bursts of updates that affect the same properties, the confirmations / new state from the server overwrites the effects of any inputs that hadn't been seen by the server at the point that the confirmation / new state was generated. Solution: use Server Reconciliation.
When receiving state updates for your entities, re-simulate your game using the new "truth" / authoritative server state as a starting point. This can mean:
- predict the present state of your player by re-simulating the time passed between the received server state and your client's present. (this typically means re-applying any inputs not taken into account / seen by the server when it generated the last state you've received, either by
- applying non-time dependent updates to the state for each input sent and not acknowledged
- stepping the server state until your "present" (and your inputs are taken into account every time you step the state, since you've stored your sent inputs, and know at which point in time/"turn" you've produced them)
- predict the state of the other entities
You can choose whose entities' state you predict, and by how much (as to limit the amount of correction they can suffer)
More info: http://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html
Ping calculation: record timestamp, send ping, receive pong, calculate time since ping was sent (roundtrip time), and divide it by 2 to approximate the ping (one-way delay, ping).
Clock syncing: when calculating ping, server includes its clock value inside the pong message. Upon receiving the pong message, the client can calculate the approximate current server clock value with the sum of the timestamp included in the message and the approximated ping value. Then it can calculate the approximate difference/delta between the server clock and its own clock. This difference can be applied to any server timestamp to obtain its equivalent value for its own clock.
Extrapolation / dead-reckoning: project entities into the present by extrapolating their last known data, or simulating the time passed since the last update. (Ping)
Lockstep: deterministic simulation that is run on all clients, synced by broadcasting user input only (no need for sending state). Only advances when has turn action for all players. (anti-cheat: commits)
- Needs reliability. But by default, the other wait if your turn action hasn’t been received
Asynchronous lockstep (deterministic simulation with rollback): doesn’t wait to receive turn actions, goes on. When receives turn action for past turn, goes back to that turn, saves action, resimulates til present.
- Sending turn actions to the the server needs reliability
- Only needs reliability from server-> client in case we are synced through turn actions; if using states, no need for reliability, since we can afford to lose them
Client-side authority movement: player directly tells server the position of their character. 0 latency player movement. Lots of cheating. Server can limit the scope of the actions to mitigate damage/hacking. Collisions can be problematic.
http://dasilvacont.in/multiplayer-online-game-development-course/