Implement (initial) player synchronization

[Hasan-Jawaheri]

Functional requirements:

• Server is ultimate source of truth
• Players play on their own, send their motion to server
• Players receive other players' motion in the past in a separate logical timeline and replays it with some delay
• Small incremental corrections to player motion as it skews away from server

[Hasan-Jawaheri]

Use this as a reference: https://gafferongames.com/post/state_synchronization/

[Hasan-Jawaheri]

General idea (some details can be found in above link):

• RemoteControlledAI performs all receiving functionality:
  • Receives Input + State
  • Snaps physics to state
  • Applies smoothing visually only (error is deviation from sent state, recalculated on every reception, and is gradually applied every frame to reduce)
  • Sets inputs on AI so simulation can extrapolation behavior
• PlayerAI inherits from RemoteControlledAI
  • Player will also adhere to what the server is saying (so server is the source of truth)
  • PlayerAI might need special handling for state reception because player is always ahead of where server thinks he is.
  • One idea is to keep history of state and times, then know how long ago the state from server was, and calculate error as deviation at that time and apply that error (hard on physics, soft on visual)
  • PlayerAI will send inputs to server
• On the simulation side, we will need to
  • Receive player inputs (special packet) and apply to corresponding unit
  • Send all players all state updates of all units (can optimize later)
  • Simulation DOES NOT accept input + state update type (no one can tell the server what state to use) so RemoteControlledAIs on the server (player units) will not have their state controlled by players. But the simulation will accept input update types which it will apply on the RemoteControlledAI of the sending player which will make the server simulate player's input
• For each player unit, the AI will be PlayerAI on the player's side and RemoteControlledAI on server and other players/clients
• For each NPC, the AI will be RemoteControlledAI for all players/clients and will be any special AI on server side
• NPC AIs on server side inherit from RTBAI and have input state but don't do any networking activity
  • NPC AIs' input and state is transferred to players via regular simulation syncing

Details about sending/receiving input, sending/receiving state, compressing/optimizing packets and error calculation/application can be found in the article https://gafferongames.com/post/state_synchronization/

[Hasan-Jawaheri]

• [x] Remove "player thinks his id is 0" bs (tell player his id in handshake)
• [x] Install networking hooks at a higher level on server side and distribute to cells
• • Cells will have ONE virtual method to respond to all packets going to it
• • Distribution is based on which cell the sender is in
• [x] Game cell will forward updates to simulation which will either handle or forward to GameStateSyncBackend
• [x] GameStateSyncBackend will receive player inputs and build the inputs buffer in the network callback
• [x] GameStateSyncBackend will replay the buffer in Update at a constant pace
• • Same rate as sender is trying, offset by some buffer time (200ms?)
• • "replay" means set input on player
• • Will keep a map of all players mapped to their input buffers
• [x] GameStateSyncBackend will periodically send all clients the game state updates
• • updates are for all units (including player's own), to be optimized later
• [x] On client side, player immediately replays updates received for each unit
  • Snap physics for now (visual smoothing can be done later)

[Hasan-Jawaheri]

Optimizations checklist:

• [x] Buffer states on client side
  • Make a class to allow generic buffering (to use on client and server side)
• [ ] Fix input sequence overflow problem
  • Use nextSequenceNumber as anchor to know how to move sequence modulo size
• [x] Have a concept of logical time for each player to determine the time at which they sent updates
  • First packet will have no reference so can be played immediately
  • Times will be relative to previous input, player can send "milliseconds since previous input" parameter
  • If set to short_max, this means its too old and we assume it is "first packet" again
• [x] Add time buffer on replaying inputs on server side, using relative times player sends
• [ ] Add visual smoothing
• [ ] Special handling for PlayerAI handling RemoteControlledAI's state updates (because updates are received for past state, we should keep an error from past state and correct that rather than snapping)
• [ ] Optimize packet size and add compression to increase allowed bandwidth
• [ ] Optimize when to send what to who from server side (can't send all updates every time)

[Hasan-Jawaheri]

Motion is very jittery on client side because the framerate is highly varying. On server side, simulation runs at fixed 30 FPS and it is much smoother. This issue should allow running physics at a fixed step rate: https://github.com/Hasan-Jawaheri/Wasabi/issues/44 and needs to be implemented before this can be done