COMP4002/GAM Games

Multiplayer - Communication

Communication / Netcode

• Real time simulation

•  Updating the game state in response to input

• Must be synchronised between players

• Networks are always subject to delays and latency (“lag”)

• “Round-trip time”

•  Time for an input to be sent and to receive a response

•  How to be responsive?

•  Bandwidth - Each client needs to synchronise a complex model every loop

•  Limited

•  How to be efficient?

•  Reliability - Packets get lost or delayed or arrive out of order

•  Inevitable

•  How to respond?

Lag / Consistency / “Desynchronisation"

•  Network delays lead to desynchronisation

•   Game states of players no longer match

•   Logical inconsistencies on divergence

• Consider p2p / non-authoritative

1.       Blue sees Red move across the screen into their crosshairs

2.       Blue shoots Red with perfect timing on their screen.

3.       Blue’s game generates a shoot event, and sends the data to Red

4.       Blue’s game locally processes the shoot event, and confirms a hit, and shows Red as dead.

5.       In Red’s game, Red continues to move. Red’s game then   receives the shoot event, and processes the event. Blue’s gun no longer lines up with Red, and the shot is a miss.

6.       Red is alive in their game, but dead in Blue’s game.

Implementation Fundamentals

• Supports efficient replication Extrapolating= ? Server related with?  Authority

•  The communication of state or events to a remote peer

•  Replicating an object causes it to appear to be created and updated on a remote peer

•  Transfer sufficient data to reflect changes to the local object remotely

•  Replication is the application layer of the networking stack

• Authority

•  One entity has the canonical game state

•  Manage permission to update the persistent state of an object

•  The game server is authoritative over dealing damage

•  Can resolve inconsistencies, is trusted

• Prediction

•  Extrapolating the current properties of an entity based on historical authoritative data local guesses about the future

•  To support responsiveness

•  The opposite of authoritative

Common Approaches

•  Trade off speed and reliability

•  Reliable transport (TCP)

•   Requires high bandwidth or simple networked state

•   High-game tolerance to latency

•  Unreliable/datagram transport (UDP)

•   Fast and frequent

•   Can afford to lose some

•  Communication paradigms

•  Lockstep

•  Bandwidth reduction

•   Deterministic client-side replication

•   Snapshots and deltas

•  Prediction

•   Entity Interpolation

•   Dead-Reckoning

•   Client Authority Prediction

•  Server-Side Lag Compensation

•   Rolback

Lockstep

•  Lockstep

•  Ensure synchronisation

•   Both (all) clients are processing the same frame. at the same time

•   Clients are “locked in step”

•   Handling the same input

•  Tolerate delays

•   Every client waits for all of the data to arrive

•   Updates limited to the delay of the slowest client

•  Lockstep with input delay

•  Input data is scheduled to be processed in a future frame.

•   Based on the network latency

•  As long as input arrives before the schedule run time, the game is synchronized and there is no   wait time

• Local input is delayed artificially

•   E.g. 100ms to see “effect” of input

Deterministic Client-Side Replication

• Each client has its own local replica of the model to use

• One/the server remains the authority on what is happening

• Is deterministic

•  Can reliably reproduce the same game state from the same inputs

•  Includes logic regarding how the simulation should evolve

• Local replica

• Receives regular snapshots of the server model

•  UDP (fast, but unreliable @~20Hz)

• Tell the server what we wish to perform, so the server can update the canonical model

•  The server is authoritative

•  Further changes are cascaded to the client

Snapshots and Deltas

• What does the server need to tell the client?

• What does the client already know?

• Optimise replication communication

•  Only tell the client what has changed

(delta), rather than send the full model snapshot

•   Reduce frequency of snapshots

•   {t=1, x { 0, 5 }, y { 5, 5 }}, {t=2, x { 0, 5 }, y { 10, 10 }}

•   {t=1, x { 0, 5 }, y { 5, 5 }}, {t=2, y { 10, 10 }}

•  Send full snapshot after a network delay so that the client gets back in sync

The player has pressed fire

The player has pressed fire Play the fire animation

Spawn the projectile

Simulate the motion of the projectile

Entity Interpolation

• Between updates use the local replica of the model to calculate the current state

•  Receive regular updates from the server

•  20Hz

•   1) Position of all objects at time t

•   2) Position of all objects at time t+50ms

•   3) Position of all objects at time t+100ms

•

…

•  Much slower than our rendering loop frequency

•   Objects would “jump” between snapshots

•  Interpolate between past and current snapshots

•  When 2 is received

•  Calculate intermediate positions between 1,2

•   1) Position of all objects at time t

•   2) Position of all objects at time t+50ms

•    Move object to t+5

•    Move object to t+10 … render smooth motion at 200fps

Dead Reckoning / Opponent Predication

• Interpolate / predict motion into the future using linear physics

•  Moving objects are likely to continue to move

•  Static objects are likely to continue being static

•  Inputs are likely to be the same (including null inputs)

•  Make guesses about future states when appropriate

•    Including opponents

•   Optimistic consistency

Game breaking

Modeling consequences if the player is wrong ?

•  Client is responsible for frame-to-frame movement simulation and rendering

•  Game critical events are comparatively infrequent

• 100Hz vs ? (how often do you pick something up / shoot?)

•  X is moving at speed Y with direction Z, so move it a bit in direction Z

•  Server is responsible for the bigger picture, the context and the consequences

•  Don’t predict significant events, wait for authoritative model

•  Player A has picked up the gold, B hasn’t

•  A has fired a gun and hit B

Client Authority Prediction

•  The player pressed forwards

•  Round trip time

•   Client->Server->Server Game Loop->Client

•   Significant latency for “twitching”

•   onLive

•  Assume that we will be given authority

•  That our local model will match future server model

•  Send the command to the server controller

•  Start moving immediately

•  Rewind if we got it wrong

•  Generally, most commands will be accepted as the model should be largely in sync

•  …the game feels more responsive than the network allows

•  Atomic movements smoother than 20Hz network rate

Server-side Lag Compensation

•  The server maintains …

•   A stack of snapshots

•    Remember where everything was up to a second ago

•   Current round-trip-time for all the clients

•   Time for a packet to travel from client->server->client

• Predict game states while waiting for input

•   Assume players have not changed their inputs

• Rollback

•   When a new command is received, estimate when it was sent rather than when it was received

•   Use the historical snapshot of the model to work out what the client state was at this time …the command is executed hopefully as if there was no lag

•   Often prioritising shooter rather than shootee, or highest latency player

•   Re-simulate subsequent frames

•   “ Rubberbanding ” or teleporting as the first state is unwound

•   Shooting around corners

•  Separate visual from state effect

•   Show a visual hit but don’t apply the damage immediately (might be rolled back)

•   Mixture of deliberate input delay and prediction