Implementation of a Peer-to-Peer Multiplayer Game with ... - DVS

DHT’s key space. A comparison of the two DHTs shows that the range-queriable DHT has a slightlyhigher latency but a lower bandwidth consumption than the traditional DHT. Additionally, the formerhas a better load balancing.The discovery latency is reduced using the spatial and temporal properties of the game. Players (usually)move more or less constantly within the game world. Using this property, Colyseus automaticallyexpands the area of interest towards the direction of movement, performing speculative pre-fetching ofobjects. The amount of expansion depends on the player’s velocity, always pre-fetching for a certainamount of time. This amount of time is a parameter which needs to be adjusted to be high enough tohave an acceptable view consistency but not too high to avoid a lot of unnecessary pre-fetching (e.g.,caused by the player changing direction). For further optimization, Colyseus implements a local subscriptioncache to avoid too frequent subscription updates and an optional aggregation filter mergingoverlapping subscriptions. Furthermore, not only the subscriptions but also the publications are storedin the DHT for a certain time. This allows for immediate responses to new subscriptions without a delaytill the next publication, also making longer publication intervals possible.Implementation and EvaluationFor evaluation with a real game, Quake II was modified to use Colyseus. Alternatively, unmodified QuakeII clients may connect to the distributed servers so that the system may either be used as a full peer-topeergame or using a distributed server community. The Quake II objects are sent using field-wise diffs,resulting in an average diff size of 145 bytes. The original Quake II server-client messages have anaverage size of only 22 bytes.In small scales, the generated traffic with colyseus is higher than the traffic for simple broadcasting.But with an increasing number of nodes, Colyseus quickly outperforms broadcasting, and the traffic loadof each node is an order of magnitude lower than the server’s load in client-server mode. The analysisof view consistency shows that half the replicas take less than 100ms to update and only 1% takes morethan 400ms. Of the 23 remote replicas a node requires in average for a 40-player game, it has thecomplete set in about 40% of the time. After waiting up to 100ms for a replica, 60% of the replicas areavailable in avarage, and waiting up to 400ms increases the proportion of available replicas to 80%.DiscussionColyseus focuses on object management for fast first person shooter games, introducing techniques compensatingthe problem of relatively slow DHT operations. Performing optimistic updates, it also aimsfor low delays, providing only weak consistency. As the system relies on spatial and temporal locality,e.g., for its prefetching mechanisms, it is only suitable for games where players have a limited range ofperception and interaction. Real-time strategy games (RTS), for instance, usually require the player tosee large parts of the game map, in which case Colyseus’ mechanisms will not work.For first person shoothers though, Colyseus shows a good performance. Being able to run in full peerto-peermode or as a cluster of distributed servers, the system is flexible for different purposes. Theevaluation using a modification of an existing game can be taken seriously, but lacks a user study.2.3.4 DonnybrookDonnybrook [3] was published by Bharambe et al. in 2008, and thus may be seen as Colyseus’ successor.But in fact, it has a different focus. While Colyseus deals with object management, Donnybrook concentrateson player update management. It continues the optimization of the players’ interests, trying22 2.3 Peer-to-Peer Gaming