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

sensor node request messages to all nodes in the sensor node list, returning new sensor node suggestions.For each section, the nearest node outside the vision range is chosen as the new sensor node.When joining the network, the new node connects to some arbitrary node that is already in the network.That node provides information about nodes closer to the new node via a sensor node request.The new node then repeatedly sends sensor node requests, and its position updates are forwarded bythe sensor nodes, so that the node finally finds all of the neighbors in its vision range.EvaluationSystem quality is measured using the following protocol quality model: PositionAge(p, q) is defined asthe time (in rounds) between player q sending his position update to p and p receiving the update.Within the interaction range (defined by the game application), the protocol quality function PQ(p, q)between the players p and q equals the position age function. Outside the interaction range but withindist(p,q)−IR(1−vision range, it is defined as PositionAge(p, q) ) V R−IR , where dist(p, q) is the distance between thenodes. V R and IR are vision and interaction range. Outside the vision range it is set to 0. The protocolquality PQ(p) for node p is the sum of PQ(p, q i ), and finally the total protocol PQ quality is defined asthe average over all PQ(p i ).For evaluation, the system is run in a simulated network with up to 600 players. The default gameworld size is set to 1000x1000 with a relatively large vision and interaction range with radii of 200 and50 respectively. The node’s outbound bandwith is limited to 5KB per round. The experiments show thatthe protocol quality does not depend on the total number of players but just on the density (to be moreprecise: the average numbers of players in the vision range). With 100 players, PQ is almost 1, which isthe optimal value. Client/server solutions have a PQ around 1.4 as all messages have to pass the serverand thus require at least two hops. Increasing numbers of players in the vision range require (linearly)increasing bandwith; a limitation of the latter reduces protocol quality. But even with 50 players in thevision range, pSense is still slightly better than client/server.DiscussionpSense is a system based on locality (in the game world) that works completely decentralized. There isno global authority required and all peers have the same responsibilities. The evaluation results showan excellent performace as long as the game world does not get too crowded. As many games have asmall number of important places of interest, this could though be a problem. One could think abouttechniques for dynamically decreasing the vision range (like VON) and/or trying to focus on importantneighbors (like Donnybrook).pSense only considers players and does not provide a solution for handling other game objects. Althoughin principle objects can be handled in a similar fashion as players, there are still synchronizationissues. The authors argue that synchronization and conflict resolution can be handled by a central serveras this is necessary rather infrequently. However, this is may not be a satisfying solution.2.4 Design Space for Peer-to-Peer GamesThis section concludes the related work section for peer-to-peer gaming by assigning the presentedsolutions to the different problem categories low-latency information dissemination, network maintenance,object management, and security. Clearly, not all presented approaches provide solutions for every topic.Thus, a complete system needs to adopt parts of various of these approaches.2 Related Work 27