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

2.4.1 Low-Latency Information DisseminationOne of the most specific requirements for fast-paced peer-to-peer multiplayer games is a low-latency informationpropagation to interested receivers (interest management [24]). The most important interestfactor is locality (closeness in the game world), as the games discussed here are games in which playershave a very limited vision range (and thus area of interest) compared to the size of the game world.Examples of those games are first person shooters or role-playing games. This does not apply to e.g.,real-time strategy games where the player is able to see large parts of the game world. The typical informationthat is to be disseminated quickly are position updates. While most other information exchangeis only necessary within small groups (mostly 2 players) interacting with each other, there may be otherinformation that everyone around is interested in. But assuming a simplistic game, position updates aresufficient, and other types of information can be handled the same way.The probably most obvious (and in fact most common) approach is spatial multicast, i.e., informationis multicast to all participants within a certain range in the game world. There have been approachesusing IP multicast for NVEs [22, 11], but they have shown to be practically infeasible because of basicallytwo problems. First, the spatial structure needs to be mapped to multicast groups which are inflexibleand only available in very limited numbers. Second, and more importantly, IP multicast is not widelysupported in the Internet, limiting the area of application to small networks. Instead, all recent approachesdo application layer multicast which is flexible and less network-dependent. But they have thedownside of being less (upstream) bandwidth efficient.The easiest way of doing spatial multicast is through a server. The server collects all (position update)messages from the players, assigns each update to those players that are interested according to theinterest management rules, and sends them to the the corresponding players in an aggregated form.This has the advantage that the players have minimal bandwidth requirements as they only have to sendtheir updates to one server and receive perfectly customized and aggregated data. The downside, ofcourse, are the server requirements. The server does not necessarily need to be one central dedicatedserver; instead in a peer-to-peer game, for each region a server may be elected among the peers. But inany case, the server has to cope with a high load, needing to communicate with all players (in its region)and performing interest management.To avoid bottlenecks at machines managing the whole region, several approaches completely decentralizethe position update dissemination. Position updates usually account for a large part (if not largest)of the traffic in multiplayer games. Thus, other types of information may still be managed by central instances(see below). Decentralized approaches usually do not rely on fixed regions. Although this optionis also available using generic application layer multicast techniques [2, 10], e.g., with one multicastgroup per region, dynamic approaches have several advantages. First, using regions with a continuousgame world, there is always the necessity of (smooth) region crossing and visibility across regions. Onesolution for these problems would be having overlapping regions or multiple interleaved region grids,so that the player is always member of (at least) two multicast groups. Second, statically sized regionsmay become overloaded in crowded places. Smaller regions allow for a higher player density but causehigher overhead due to more frequent region switches.In the unstructured approaches (i.e., those without fixed regions), each node keeps a neighbor list ofnearby nodes. Typically, every node is in direct contact with all nodes in its vision range (and/or nodes inwhose vision range it is; this is the same in simple cases with equally sized and undirected vision ranges).The challenge for these approaches is to quickly and efficiently detect new neighbors approaching thevision range. Late detections will cause other players (or generally objects) to suddenly appear in thevision of a player who will certainly be annoyed about that happening.The techniques for neighbor detection vary between the different approaches. VON builds voronoidiagrams to find the boundary neighbors who are responsible for introducing approaching nodes. pSenseuses sensing nodes which are neighbors outside the vision range pointing like antennas in differentdirections. In Donnybrook instead, low fidelity updates are cast to all nodes in the game (for large game28 2.4 Design Space for Peer-to-Peer Games