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

More documents

Recommendations

Info

Table 4.2: Message types used by the peer-to-peer network engineType Type ID DescriptionPOSITION 0x01 Position update.INTRODUCE 0x04 Introduces a new player that has entered the targetplayer’s vision range.SENSOR_REQUEST 0x08 Sensor node request. Tells the destination node tobecome sensor node for the sender.SENSOR_SUGGEST 0x09 Suggests a node as new sensor node for a particularsector.FIRE_BULLET 0x81 Indicates a fired missile.IHITYOU 0x82 The destination player is hit by a missile from thesending player.IDIED 0x83 The sending player’s ship explodes.MessagesThe peer-to-peer protocol has a binary message format reducing the required bandwidth and processingpower compared to the ASCII messages of the client-server version. But position update messages containmore fields, allowing for a basic dead reckoning. Besides position and rotation, update messagesalso contain the velocities of position and rotation. According to these values, the remote player’s shipsare animated in the time period between two update messages, resulting in a much smoother and moreprecise ship movement. Each message has a 4 byte header including two 16 bit fields specifying the size(in bytes) and type type of the message. All message types are listed in table 4.2.POSITION messages are sent regularly (every 100 milliseconds) to all known peers for which at leastone of the following conditions is met (assume A is the sender and B is the potential receiver):1. B is in A’s vision range.2. A is in B’s vision range. (Position update messages contain a field specifying the sender’s (current)vision range.)3. B is in A’s sensor node list.4. A is sensor node for B.Position update messages have a total size of 64 bytes, containing the following information:• 3-dimensional position (12 bytes)• 3-dimensional rotation (12 bytes)• 3-dimensional direction of translatory motion (12 bytes)• 3-dimensional direction of rotatory motion (12 bytes)• Velocity of translatory motion (4 bytes)• Velocity of rotatory motion (4 bytes)• Vision radius (4 bytes)60 4.2 Network Models
Both message types INTRODUCE and SENSOR_SUGGEST have a variable length body each containingtwo null-terminated ASCII strings. The first string is the hexadecimal representation of the introduced/-suggested peer, the second is its address. In fact, both message types are currently handled the sameway. The receiver first contacts the referred peer (if not already known) to receive the position. Afterthat, it decides whether the peer is a sensor node candidate or already in the vision range. If none of thetwo conditions are met, the connection becomes idle and is shut down after the timeout of five seconds.The SENSOR_REQUEST message carries only one field indicating the number of the sector which thereceiver is requested to become sensor node for. FIRE_BULLET, IHITYOU and IDIED are similar to theirclient-server correspondents. FIRE_BULLET carries the position, direction and velocity of the bullet.IHITYOU does not have any body fields since messages of this type are sent directly between the twoinvolved peers. IDIED does not have any body fields either but is, like FIRE_BULLET, sent to all knownpeers.Since CUSP is a reliable transport protocol, it is unnecessary to send acknowledge messages for theoverlay operations. The connection management is kept pretty simple. Connections are kept open aslong as messages are received from the corresponding peer. All connections are regularly (once persecond) checked for the timestamp of the last received message. If no message has been received withinthe timeout interval (5 seconds) on a particular connection, that connection is immediately closed. Thismechanism works because the conditions for sending position update messages are symmetric. As longas node A is interested in the position of player B, it keeps sending position updates to that player. Whenthe arrival of position update messages from B ceases, A can assume that B either has crashed or is notinterested in A’s updates anymore.4.3 Main ProgramThe previous sections described the various components and depicted the interaction between the components.This section briefly explains how the main program composes the components.4.3.1 Standalone GameThe standalone game application’s entry point is defined in main.cpp. The main() function first processespossible command line parameters which are currently the only way for setting runtime parameters.Available parameters are listed in section 4.5.3. Many more variations are currently only possible viasource code modification; a good starting point is config.h (see below).The game is set up by instantiating the components and connecting them via their initializer methods.The following C++ code extract is a simplified (but working) version:// create core componentsEventManager* eventMgr = new EventManager();IrrlichtDev* device = new IrrlichtDev(eventMgr , true);ImplGameInstance* game = new ImplGameInstance ();GameTimer* timer = new IrrlichtTimer(device);// set up the networkNetworkEngine* networkEngine = new P2NetworkEngine(localPort , serverAddr);networkEngine ->init(timer , eventMgr , game);networkEngine ->configureUser(device ->getDevice ());if (!networkEngine ->connectSync()) {printf("Connect failed!\n");return EXIT_FAILURE;4 Implementation 61
Page 1 and 2:
Implementation of aPeer-to-Peer Mul
Page 3:
AbstractMassively multiplayer onlin
Page 7 and 8:
Contents1 Introduction 71.1 Planet
Page 9 and 10:
1 IntroductionIn the recent years,
Page 11 and 12: Figure 1.2: Screenshot of the origi
Page 13: Avatar is the virtual representatio
Page 16 and 17: scenarios with millions of users, t
Page 18 and 19: ArchitectureCensus operates in epoc
Page 20 and 21: administrative data. For short gami
Page 22 and 23: 2.3.2 HydraHydra [5] is a peer-to-p
Page 24 and 25: DHT’s key space. A comparison of
Page 26 and 27: the sender). Interest sets limit th
Page 28 and 29: EvaluationVON is evaluated in a sim
Page 30 and 31: 2.4.1 Low-Latency Information Disse
Page 32 and 33: 2.4.3 Object Synchronization and Ga
Page 34 and 35: API IntroductionThis section briefl
Page 36 and 37: The EndPoint class provides two mai
Page 39 and 40: 3 ConceptThis work’s implementati
Page 41 and 42: A solution could be using a mix of
Page 43 and 44: closing connections immediately is
Page 45: game instance. startNode() takes a
Page 48 and 49: Figure 4.1: Game Component Dependen
Page 50 and 51: Figure 4.2: In-game status message
Page 52 and 53: lock other tasks, resulting in a fa
Page 54 and 55: AvatarAn abstract representation of
Page 56 and 57: Figure 4.4: The network engine’s
Page 58 and 59: Figure 4.6: AI motion prediction wi
Page 60 and 61: MessageTable 4.1: Message types use
Page 64 and 65: }// init gamegame ->init(device , t
Page 66 and 67: Irrlicht for Linux requires a few a
Page 68 and 69: ExamplesRunning the program without
Page 70 and 71: 4.6.2 Implementation ConcernsUnlike
Page 72 and 73: eset callback may be called synchro
Page 74 and 75: Table 5.1: Client-server traffic de
Page 76 and 77: 700006000050000Traffic (bytes/s)400
Page 78 and 79: 1000000900000800000700000Traffic (b
Page 80 and 81: Table 5.3: Computation time and mem
Page 82 and 83: Table 5.4: Computation time and mem
Page 85 and 86: 6 ConclusionThe core task of this w
Page 87: New game features and improvements
Page 90 and 91: AIprintf("Init AI...\n");ctx ->ai->
Page 93 and 94: Bibliography[1] E. J. Berglund and
Page 95: [32] Ion Stoica, Robert Morris, Dav
show all

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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?