Multi-Player Game Architecture on the Internet

Weidong Shi Georgia Institute of Technology 2000

Multi-Player Game --- Motivation

It is interesting. It is hard and challenging. Some difficulties are,

lack technology to achieve global synchronization long network latency high packet loss rate inconsistency of state view among participants

Multi-Player Game --- Term

Entity Participant Player Entity Server

Player 2 control control Player 1 Entities

Network
Entities

Participant A

Participant B

Multi-Player Game --- Motivation

Why do we care about synchronization and consistency?

Entity2

Synchronization preserves temporal and causal relationships among events happening at geographically distributed sites. Entity 1 shoots at entity 2 Entity1 Participant A at time 100ms. The message travels 50ms to Participant B reach entity 2 and 100ms to reach entity 3.
Entity3

Participant C

Entity 2 shoots at entity 3 at time 90ms. The message travels 70ms to reach entity1 and 40ms to reach entity 1.

Wild Wild West

Who is dead?

Multi-Player Game --- Related Work

Distributed Computing and Simulation

DIS Standard (IEEE distributed interactive simulation) HAL

Games

MiMaze (a simple multi-player game based on IP/UDP/RTP protocol stack on the Mbone)

Multi-Player Game --- Related Work

Client-server Architecture

Advantage It is easy to achieve consistency. Each participant can have the same state view by receiving the same data from the server.

Participant Participant

Participant

Disadvantage Server may become bottleneck. Nobody can play if server crashes. Participants are treated as dumb terminals.

Participants send actions to the server and the server sends updated entity states back for display.

Multi-Player Game --- Related Work

Fully Distributed Architecture

Participant

Advantage It is easy to scale. No server bottleneck.

Participant

Disadvantage
Participant

Synchronization and consistency.

Participant

Participants talk with each other directly (not through the server). Entity states are updated in distributed places.

Multi-Player Game --- Proposed Work

Three Observations

High reliability and strong consistency are not required for continuous entity states.

Continuous entity states are transmitted repeatedly. Only the most recent ones matter. No retransmission of lost entity states (similar to real time audio/video). Require global reference to resolve conflict of state update. However, global reference does not have to reside in a centralized place.

Continuous game play should not be disrupted by player joining and leaving.

Multi-Player Game --- Proposed Work

High speed LAN, multicast Master server Connection Servers 1 TCP TCP UDP UDP 3 4 UDP UDP 2 TCP TCP TCP

Each entity has a owner. Only the owner of an entity can change its state. Every other participant updates the entity state by receiving information from its owner (subscribe and publish).

Entity server running entities automatically by using AI engine

A new player joins in a session by contacting the master server. The master server finds a less busy server for the new participant to connect.
The new participant connects with the server. The server transfer game state and entity control to the new participant. Participant sends interacting events to the involved participant via unreliable unicast. Participant sends state updates of local entities to other participants via unreliable unicast or multicast.

Only participants (entity server is a special kind of participant) own entities.

Master server performs session management. Connection server assigns entity control to a participant. It is also responsible for reassigning entities after their owner leaves a session.

Multi-Player Game --- Proposed Work

Dead reckoning Dead reckoning reduces traffic and deals with loss of continuous entity state messages. The technique computes an entitys state based on its most recently received state.

Multi-Player Game --- Proposed Work

Latency tolerance Latency tolerance is used to hide network delay. A fixed amount of delay is added to participants action.
Issue stop command at 200ms

Participant

300ms 330ms

transmission

Participant
Issue stop command at 230ms A fixed delay 100ms is added to every action. Assume that max one way transmission time + process overhead < 100ms

Multi-Player Game --- Proposed Work

Dynamic entity subscribe and publish

3

P1
1 4 2

P3

P4
P2
1 P3 subscribes to some entity controlled by P1.

P2 sends an interaction event involving entity controlled by P1.

P1 updates entity state based on the received interaction event.

P1 sends new entity state to other subscribers.