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

More documents

Recommendations

Info

eset callback may be called synchronously. An example case illustrating the problem can be found insection 5.3.The C/C++ bindings of the CUSP API rely on MLton’s foreign function interface which is not supportedby other Standard ML compilers. Hence it cannot be built with any other compiler, generally limiting theportability. But since the current implementation of CUSP depends on a few features that are exclusivelyprovided by MLton, it is non-portable anyway, thus there would be no effective benefit portable bindings.70 4.6 CUSP Bindings
5 EvaluationThe evaluation part starts with game protocol measurements comparing the client-server to the peerto-peernetwork implementation. Section two evaluates the performance of the game implementationconcerning computational and memory requirements, with the focus on simulation scalability. A qualitativeevaluation on the usability of CUSP for C++ applications finalizes this chapter.5.1 Networking MeasurementsThe game engine can be run on both real and simulated networks without modification. The currentimplementation enables easy switching between a real and a simulated network for the networking modulesusing CUSP. Though, for a detailed analysis on the quality of the different network implementations,an important tool is still missing: the (distributed) collection of protocol quality data. Protocol qualitydata includes information about the game world view consistency between different players and changepropagation delays. More about this topic can be found in the future work section (6.1). The followingmeasurements are thus limited to the locally measurable traffic.This section presents the network traffic measurements for client-server and peer-to-peer mode. Sincetwo client-server versions (TCP and CUSP) have the same messaging model, only the CUSP version ismeasured as the representative client-server implementation for measurements. The scenario for thepeer-to-peer measurements is run in the CUSP simulator on a single machine. The client-server versiondoes not run in the simulator (because it partially uses blocking network operations), so the scenariouses discrete instances connected over loopback on a powerful machine (16 processors, 64GB RAM). Inboth cases the available network bandwidth is practically unlimited and the latency is negligible, thus itis assumed that they do not influence the measurements.In each run, there is a constant number of bots, all joining initially (in the first second of the game)and staying until the end of the simulation. The number of players is varied between runs. Becauseof the simple bot behavior, all players remain within each other’s vision range. Especially with a growingnumber of players remaining in a limited space, it can be observed that all bots are firing almostcontinuously as there is almost always a target nearby. Concerning the generated load, the scenariocan be seen as a worst-case scenario. The traffic numbers are averaged over 30 seconds gameplay andthree clients/peers. In a second measurement round players join continuously every two seconds andthe traffic of one single node is measured over time.5.1.1 Client-ServerDue to design limitations, the server of the client-server version does not reliably support more thanaround 35 concurrent players on the machine used for the measurements (4x4 core AMD Opteron 8356,2.3GHz, 64GB RAM; but the single-threaded server only uses one core). This is partly because the clientserverimplementation misses some common optimizations like compact (binary) messages, messageaggregation, or multithreading. So interpretation of the measurements should not be focused on absolutevalues, but on trends. And the peer-to-peer version also lacks some optimization, that’s why thiscomparison seems acceptable.Table 5.1 and figures 5.1 and 5.2 show the generated traffic depending on the number of players ofclient and server respectively. The clients’ outgoing bandwidth is almost constant because the clientssend their updates only to the server. Slight variations come from their irregular activities, particularly5 Evaluation 71
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 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?