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

More documents

Recommendations

Info

Table 5.3: Computation time and memory requirements for a simulation (peer-to-peer mode)# Players Memory (MB) Runtime 30s (s) Time dilatation2 175 3.4 8.7383 185 4.8 6.2504 196 6.4 4.6886 216 9.9 3.0308 235 14.7 2.03612 276 29.1 1.03116 324 50.1 0.59924 429 118.4 0.25332 558 224.8 0.13348 865 620.7 0.04864 1,250 1,302.6 0.02396 2,352 3,931.5 0.008128 3,822 8,113.4 0.004The measurements presented here are only a starting point and for gaining first impressions. Moreextensive tests require further work concerning1. improved gameplay modes and more realistic player behavior,2. further optimized networking systems that are really trying to get the most out of limited bandwidth,and3. tools that allow for a deeper and more detailed analysis of the game events and generated traffic.These three items should also allow for measurements of protocol quality, i.e., how well the networkprotocols perform with delays and limited bandwidth.5.2 Performance MeasurementsEspecially for the simulation of large systems, the simulation performance and memory requirementsare of major concern. This section discusses measurements of runtime and memory consumption of apeer-to-peer network simulation with a varying number of players. The scenario is the same as describedin 5.1. The simulation run time is measured for a 30 second simulated game. One bot is equipped with arendered viewport. To save memory, no textures are loaded except for the viewport instance. The ship’stextures are completely omitted even in the viewport instance.All performance measurements are run under a 64-bit Linux (2.6.30, x86_64) on a system with anAMD Athlon 64 X2 4600+ at 2,4GHz and 6GB RAM. Since the simulator is single-threaded, only onecore of the CPU is used. As a comparison, a single-player standalone instance (with all textures loaded)of the game requires around 210MB of RAM. The Standard ML part of the program is garbage collected,thus the memory requirements vary over time. But the measurements have shown that these variationsare less than 10%. Measured run times include loading of resources, setting up the game and connectingto the network for each instance. The simulation time dilatation is calculated by dividing 30 seconds(simulated time) divided by the simulation run time (wall time). Thus it is the factor indicating howmuch faster (or slower) the simulation runs relative to real time.Table 5.3 and figures 5.8 and 5.9 show the results. Both memory consumption and computationtime show about a quadratic growth. Reason for that is the above mentioned clustering of players in a78 5.2 Performance Measurements
900080007000600050004000Mem (MB)Runtime 30s (s)30002000100000 20 40 60 80 100 120 140Figure 5.8: Computation time and memory requirements for a simulation depending on the number ofplayers10.0001.0000.100Time dilatation0.0100.0011 10 100 1000Figure 5.9: Simulation time dilatation depending on the number of players5 Evaluation 79
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 62 and 63: Table 4.2: Message types used by th
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 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?