ukoehb/bevy_girk

Framework for instanced multiplayer games in Bevy.

bevy_girk's Issues

Client input status tracking

Simple client input status-tracking framework. This can be used to implement client-side prediction for slow-paced games.

• Design overview

  • Client inputs are FIFO over a reliable channel.
  • If a client input fails, subsequent client inputs will rejected until the client has acked all pending inputs. The client has to 'catch up' to the server before inputs can be applied again.
    • This facilitates input rollback in case of dependent inputs (e.g. in a resource-based game where inputs build off each other).
  • Client inputs can be Accepted or Rejected. Clients may specify custom behavior to run based on the result.
    • We can detect if Premapped entities failed to spawn on the server and automatically despawn them, so this cleanup does not need to be included in on-reject handlers.

• Client tracked input

  • Player makes input.
  • Client creates predicted effect of the input. Each tracked input should have 'on accept' and 'on reject' logic.
    • ex: pre-move a unit on a board
    • ex: pre-spawn a predicted entity
    • ex: make button have 'loading' indicator
  • If last-acked tracker index is Rejected and != current input index, immediately reject the input.
    • We do this to expedite client catch-up.
  • Client sends input to server.
    • input index
    • last-acked input index
    • input contents (including premapped entities)
  • Client tracks the input status.
    • input index
    • last-acked input index
    • last-acked status (Accepted/Rejected)

• Server input tracking alignment

  • Input index tracker entity

    • { { last-received input index, Accepted/Rejected }, last-accepted input index } (replicated)

  • Input received from client.

  • Apply or reject input.

    • reject if index <= last-received input index for this client
    • reject if last-acked input index < last-received input from this client if last-received was rejected
      • This is the important synchronization detail. We continue rejecting inputs until the client catches up to our rejections (i.e. sends an input with last-acked equal to last-received).
    • reject if invalid according to app code

  • Update input index tracker entity for this player.

• Client input status management

  • On index tracker entity mutation

    • for each pending input
      • if tracker last-received index <= last-acked index: log an error
      • if tracker last-received = Rejected

        •  if tracker last-accepted index >= pending input index: accept the input
          

        • else if tracker last-received index > last-acked index: reject the input
      • if tracker = Accepted
        • if tracker last-received index >= pending input index: accept the input

  • Unwinding notes

    • If a premapped entity does not have the Replication component after the input that spawned it has been applied, then the entity should be despawned. This can be done automatically with a system if input indices are added to premapped entities as a marker component.

• Problems

  • Replicon component changes are only eventually consistent. This means index tracker entity mutations can lag behind or ahead-of input effects, potentially creating a disconnect between replicated effects and the effects of on-accept handlers (and on-accept handlers erroneously may run before the effects are present).
    • Solution 1: Add option to replicon to fully synchronize updates. However this won't synchronize replicated entities and custom events.
    • Solution 2: Expect users of the prediction API to account for delayed or early arrival of updates when inputs are accepted.
  • As soon as a client catches up to the server, the next input can be sent successfully. This means it is possible a player cannot react to their most recent input failure before their current input is processed.
    • Solution: Add configurable delay between last server-reported failure and when the next input can be applied.
      • let this delay be configurable by the player?