light cycles galore building a multi-server multiplayer game architecture by per lohmann

Light Cycles Galore

Building a Multi-Server Multiplayer Game Architecture

By

Per Lohmann

Light Cycles the game• Inspired by the movie Tron• Similar to the game Snake• Players drive around in a world controlling a

Light Cycle• Each Light Cycle leave a tail after it

Early design decisions• Game is 2D• Moves are either Up, Down, Left or Right• World split into zones of fixed sizes• Each zone is handled by a server• No loading screen between zone transitions• Visibility into other zones

System architecture

Master server consequences• Single point of failure/limitation

– Can be a bottleneck

• Single point of connection– Easy server setup– Client connection is simplified

Implementation• Master server project

– WinForm application

• Server project– WinForm application

• Game Client project– XNA 2.0

• Common project– Containing shared objects and enums (mostly

concerning network communication)

Representing the world (server)• Zones are rectangular

– Size set by the master server– Layout set by the master server– References to nearest eight world directions

• North, Northeast, East, Southeast etc.

– Represented as a two dimensional array• Each element represents a player id• Id = 0 is reserved for empty space• Id = 1 is reserved for walls

Collision detection• Collision detection in constant time O(k)

– Lookup in array at a specified position

Representing the world (Client)• “Unlimited” size of game world• No loading between zones• Visibility into other zones• Not practical with an array representation• List of list of tiles (tiles are equivalent to player

id’s)– Do not use structs when using lists in C#!

Representing the world (Client)

Client view• Clients view is larger than the actual viewed part

on the screen– Buffer area allowing the client to receive view updates

before they are visible (buffer = one seconds movement)

Game state communication• Client sends information when performing an

action• Server sends information when updates about

players view occur

• Dead reckoning / Client side prediction– http://www.gamasutra.com/features/19970919/aronson_01.htm

Zone transitions• Two types of server states

– Active server– Passive server

• When clients view enters another servers area the active server informs the client to connect to a passive server

• Client sends commands to all “registered” servers

• Receives updates respectively– Will not work in a FPS game– Would work in World of Warcraft

Architecture scalability• Currently Master server uses TCP

– One TCP connection per server– One TCP connection per client– ≈ 60.000 free ports

• Server / client communication uses UDP– No real restrictions except bandwidth and server

resources

The end

Questions?

Server “crash”• Detecting server “crashes”

– TCP connection to Master server gets torn down– Any servers without zones get assigned that zone– All data from zone is lost but “world” continues– MS could inform players of server crash (currently it

does not)

Transmitting data TCP• TCP (Reliable, Connection oriented, etc.)

– Encode/decode using built in binary converter– TCP is stream based and not message based– Multiple encoded objects received– TCP wrapper object appending object length

Transmitting data UDP• UDP (unreliable)

– Uses pure unreliable UDP– Encode/decode using own implementations– Highly efficient– Byte shifting– Could be done more easily using C (memcpy)