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

2.4.3 Object Synchronization and Game Logic ExecutionAs any real (and not completely simplistic) computer game has objects with associated state that canbe manipulated, there is obviously the need for supporting them in massively multiplayer online games.The challenge in distributed multiplayer games is to synchronize the objects so that each player has a(sufficiently) consistent view and all his actions on these objects have the expected consequences. Thisis particularly difficult to achieve when two players manipulate an object concurrently. Game objects arebasically everything in the game world that is not directly related to a single player and that is not partof the immutable terrain.Immutable parts of the game are usually installed (and if necessary updated) together with the gameand do not require any synchronization; all participants agree based on identical data. The player’savatar (typically including its properties and direct belongings) is treated separately and not the sameway as other game objects because it constantly belongs to one player (and thus one node in the network)and is always controlled from there. Each avatar has a dedicated node (i.e., the corresponding player’snode) that is naturally responsible for serializing all operations.Some types of objects, most commonly any type of NPC (non-player character), have think functionsassociated that (regularly) execute some piece of code which automatically makes these take some action,for instance moving around in the game world. But the think functions may also be much simpler,possibly just causing some slow resource regeneration. These functions must be executed somewhere;the decision on which node(s) a particular think function is to be executed is closely related to thedecision whose nodes are responsible for managing object modifications.Basically, it has to be decided which consistency mechanisms are to be applied to the objects. Pessimisticmodels (e.g., locking objects for modification) is not feasible for distributed realtime gamesmostly of two reasons. First, in realtime games, it is not possible to wait possibly several seconds whenevermodifying an object. And second, as the system consists of unreliable nodes connected over theInternet, locks may not be correctly released in some cases. Necessary timeouts would cause even morewaiting for object manipulation or just reading the current state.Thus, there is the need for optimistic consistency. In most cases it is not necessary to have strict consistency,but the game logic must then be prepared for handling some inconsistency properly. Colyseushas an optimistic consistency model in which all updates are tentative until approved by the node responsiblefor the primary copy. The responsible node serializes all modifications and rejects conflictingchanges. Of course, with Internet-typical latencies, the player will eventually notice when an object thathe manipulated is reverted after a few seconds. The game logic will not always be able to compensateand hide these effects from the player.The common approach for object consistency is to serialize changes on one node that is chosen tobe the owner of the particular object. In SimMud there is a coordinator node for each object, andColyseus has nodes holding the primary copy which is the reference object, i.e., everyone eventually hasto synchronize to that object. This approach makes the serialization relatively easy as it is done locally onone node. But it also entails a reliability issue, since a failure of the one node responsible for a particularobject will result in a loss of its state.Data loss can be prevented by having certain nodes keeping backup copies that are always synchronizedwith the primary copy. Ideally, one of the nodes holding a backup copy can immediately take overwhen the failure of the node holding the primary copy is detected.One approach of selecting the nodes responsible for a particular object is based on regions. Eachregion has one coordinator node who is responsible for all objects in that region. Another possibility is tohave one coordinator for all objects of a particular type. Better load balancing is achieved by assigningan ID to each object and giving each node the responsibility for a certain range.All approaches that cover game object management use a DHT for manging responsibilities. AlthoughDHTs have the previously described weaknesses, especially concerning latencies, they appear to be themost feasible solution so far. Timing concerns can be answered by pre-fetching object copies before they30 2.4 Design Space for Peer-to-Peer Games