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 –

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 –≈ 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)