On the Impact of Delay on Real-Time Multiplayer Games Authors: Lothar Pantel, Lars C. Wolf Presented by: Bryan Wong

Outline Introduction Multiplayer Games Experimental Evaluation Related Work Conclusions

Introduction Major problem of networked multiplayer games is caused by transmission delay A primary goal is to provide a global consistent state of the game One approach is to introduce a local presentation delay

Introduction Simulator-like games such as flight simulators, racing and sports games are most critical because they require smooth movements of the objects

Multiplayer Games Architectures: Server based with a dynamically based or central server Distributed scheme

Influence of Basic System Parameters Designer must decide which messages are transmitted reliably/unreliably

Delay The time between the generation of an event and the resulting update of the game state Important issue of how the system handles old state information and how large the difference between the real and expected positions of the players in a game may be due to the delay of messages

Experiments with Commercial Games Studied the delay-handling approaches used by two commercial games in two player mode Re-Volt Need-for-Speed Examine how commercial game developers handle the delay problem

Start Release Direct play assigns the role of coordinator to one of the two players This contains the release of the start Use the start countdown and start sound to detect correct synchronization

Start Process As soon as the vehicles begin to move, the first deviations in the positions of the cars can occur Identical vehicles, motors, etc. are selected to avoid acceleration differences Expected that both cars remain head to head

Simulated Start Cars are stopped in the course of the race and are aligned at the beginning of a straight path Both cars are accelerated simultaneously by one person using both keyboards Cars should remain side by side

Driving with Constant Speed Vehicles drive with same constant speed side by side An identical screen situation should be presented Occurs only if position consistency is maintained during the game

Collision Treatment Collision of game objects is detected through a polygon- collision Only a position difference of 0 of opposing vehicles will cause an identical, local evaluation of the polygon collision If position consistency is not sufficient, contradictory situations can occur

Observed Results Games provided very limited handling of delay Both provided a synchronized start release Start process was not handled correctly – the local car was always in leadership Both games failed tests 3,4 Neither game provided satisfying treatment of collisions

Experimental Evaluation of the Impact of Delay Inconsistent state brings several problems and can be confusing to the players One approach to enhance consistency is to delay the presentation of the actual game state How much delay is acceptable for users in real time games? Delay includes all communication, processing and buffering costs

Principle Setup Performed steps:

Implementation Implemented in an RC-Car simulation Driver does not use a cockpit view but a higher view allowing the user to view the whole area Virtual RC Racing implements the static delay scheme The feeling how the car reacts is influenced by the delay between steering and reaction

Experiments Purpose was to determine acceptable presentation delay 12 candidates performed experiments For each of the following graphs, three players were selected who were representatives for the following categories: Beginner, Average and Excellent driver Static presentation delay was increased in 50ms steps up to 500ms

Experiments Avg time per round in dependence on delay It becomes more difficult to control the car, requiring the driver to slow down Best time per round in dependence on delay Reflects the best possible value for the driver, under the given conditions Frequency of Leaving the Course

Results

View Dependance Delay value that can be tolerated by the participant depends on the camera perspective A cockpit view allows at least an additional 50ms of delay to be tolerated

Related Work MiMaze – distributed 3D Pacman game Consistency of the is improved by delaying the presentation of the events using buckets The whole game is 100ms in the past Players with >100ms delay cannot participate

Conclusions Delay of 50ms is uncritical for a racing game Delay of >100ms should be avoided Consider the racing game as a worst-case system For other games (first person shooter,…) a delay of 100ms may be acceptable For comparison, lip synchronization requirements for audio and video streams are [-80ms,80ms] Static delay schemes are not well suited for real-time multiplayer games