Presentation on theme: "Colyseus: A Distributed Architecture for Online Multiplayer Games"— Presentation transcript:
1Colyseus: A Distributed Architecture for Online Multiplayer Games Ashwin Bharambe, Jeffrey Pang, and Srinivasan SeshanCarnegie Mellon University
2Online First-Person Shooters Multiplayer architecture for multiplayer first-person shoot games.low latency requiredweakly consistent state tolerablespatial contiguity allows pre-fetchingTraditionally this is done with a client-server modelleads to bottleneckscan only sustain user numbers in the dozens
3Colyseus Single-copy replication model maintains consistency by serializing updatesmirrors existing server modelcuts latency (reading from local copy), but sacrifices consistency in game-wide stateDHT lookup for object queriesboth random and range-query DHTs implementedrange-query DHT works well since object queries will always be in contiguous spatial regionsDHT query delay overcome by anticipating which objects will be needed soon and pre-loading them
4Replica ManagerFollows Tunable Availability and Consistency Tradeoffs (TACT) modeldepending on specific game characteristics, developers can select either more availability or consistency - consistency lowers availability (increases lag), availability lowers conistency.synchronizes replicas to primarychanges are delta-encoded, sent to primary, then distributed serially to all replicaswhen a node becomes interested in a replica (i.e. the player is near that object), it registers with the primary and receives updates directly (decoupled discovery/synchronization)creates new replicasdeletes replicas that are no longer neededfast moving objects (missiles) use a special case attachment so that they are automatically sent to nodes that request the object they are attached to (the person who fired the missile)
5Range-Queriable DHT adjacent nodes responsible for adjacent keys both standard random DHT and rangeDHT implemented with Mercuryadjacent nodes responsible for adjacent keysplayer x,y coordinates used as key, then game can request other objects that are near the player from adjacent nodespredictions based on current player motion can be used to pre-load upcoming objectswith a known average DHT lookup time, the prediction can be tweaked so that objects finish loading about when they are needed
7Evaluation Experimental Setup Modified Quake II to work with Colyseus Emulab used to simulate virtual serversno link capacity constraint, but ties end-to-end latency to measured samplesartificially dilate time to counter slow virtual serversmodel game based on density statistics for a quake III map ( Zipf distribution)Modified Quake II to work with ColyseusMercury rangeDHTvariable size bounding box corresponding to visible objects for a character used as area-of-interestclient/server messaging remains intact so unmodified engines could connect to any of the p2p nodes as if it were a serverCustom map w/ bots for workloadEmulab testbed
9DiscussionColyseus enables multiplayer first-person-shooter games to handle hundreds of players, instead of dozenssince FPS games have very high demands for low latency and consistency, extending this architecture to other game types, like role playing games, is very feasibleadaptation of commercial Quake II shows that this is feasible for other games in a production environmentthis method opens up many possibilities for cheating (a node could be modified to request objects that it shouldn’t ‘see’, for instance), but more work could be done to address those threats.
10Related Work Real-time strategy (command & conquer) parallel simulation often used, since consistency is very importantoften limited to less than 10 playersOnline role playing (world of warcraft, second-life)cell basedcentralized server or server clusterDistributed Virtual Reality Environmentssimilar goals to Colyseus, but specificnot catering to common game applications
11Issueswhy not just evaluate actual gameplay? (custom map, all bots seems a little suspect)synchronization decoupling seems to introduce a bottleneck. It’s still better than a server model since a primary replica might be the only one on a node, but the node still has to handle all traffic for that replicahow are node failures (player logs off) handled?how do you handle updates on objects in a view that is already inconsistent, especially since the node cannot know if it’s view is consistent.