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

More documents

Recommendations

Info

6.1 Future WorkAs pointed out in several places throughout this document, there is a lot of continuing work that canbe done in the different topics addressed within this work. Those include several aspects of the gamelike gameplay modes, particularly for large numbers of players, further improvements in the networkingimplementations, and evaluation and simulation tools.Currently, the game Planet π4 has only a simple deathmatch gameplay mode. This mode is feasiblefor some testing and demonstration of networking models, and can be played by a simple bot implementation.But in order to generate workloads conforming to those of real games, it is necessary todevelop gameplay modes that resemble those of popular online games. This is not only important forthe representativeness of the workload itself but also generated opportunities for collecting experienceby letting possibly large numbers of human players play the game. And that is only feasible if the gameis attractive to the players.Instead of a deathmatch with everyone fighting against each other, the players could be assigned toteams which have to compete. An example of a common gameplay mode is capture-the-flag (CTF) whereeach team tries to steal a flag from the base of the other team while protecting its own flag. For a largernumber of players it is necessary to develop more sophisticated gameplay modes because simple modeslike CTF scale only to a certain number of players/teams. The common model in role-playing games(MMORPGs) is to provide quests that small groups of players solve together, while the massive numberof players forms a society (economic and social) but is not directly involved in most of the game activitiesof a single player. For shooter games like Planet π4, there are no massively multiplayer gameplay modesyet, thus they still need to be developed.For supporting attractive gameplay modes, Planet π4 also needs to be equipped with a bunch of basicfeatures that are still missing at the moment. One of them is a collision detection among spaceships andthe terrain. The terrain needs to be expanded and enriched with features that make it feel more like areal world and that support certain gameplay modes (e.g., team bases for CTF).A very impacting new feature would be a general-purpose object model which is required for almostevery new gameplay mode. Currently, the only information that is exchanged over the network is for theplayers’ ships and missiles. Game objects can be used e.g., for mutable terrain features (breakable parts,doors, etc.) and objects directly related to the gameplay (the flag in CTF). The whole topic of gameobjects filling the gap between the fixed terrain and the players’ avatars, as introduced from a technicalperspective in 2.4.3, is not covered yet.For supporting enhanced gameplay modes and generating more realistic workloads in simulations, theAI implementation should to be improved. But the particular strategies that need to be implementeddepend on the focused gameplay modes. Another approach for workload generation would be therecording of traces of games played by humans and replaying the games in simulation runs. But italways has to be concerned that the properties of different network engines also influence the game,feeding back to the players’ behaviors. Thus it may not be feasible to just replay the same game forcomparing network implementations.Further improvements are achievable in the game’ software architecture. This work made importantsteps towards a low-coupled and flexible software system. But there are still some remains of code thatrequires special handling, reducing replaceability and extensibility. One example is the Avatar/Spaceshipconstruct that at some point needs to waive abstraction. Those improvements have to go hand in andwith the design of new game features like those described above.Certain changes may also be necessary in the game mechanics concerning communication. The simpleIHITYOU/IDIED message scheme is unsafe against both cheating attacks and unreliable network transmission.The scheme is also very specific for the purpose of modelling shooting. If further interactionsbetween players are introduced, it may become desirable to design a general purpose mechanism thatmay (reliably) handle various types of interaction.84 6.1 Future Work
New game features and improvements of the game mechanics do of course have an effect on thenetwork engine requirements. Especially new features like an object model introduce completely newchallenges for peer-to-peer network engines. pSense only manages the players’ avatars but does nothandle other types of game objects. General-purpose overlays (DHTs or unstructured systems like BubbleStorm)appear to be an appropriate base for distributed game object management, as shown byseveral approaches dealing with that topic (see section 2.3). These overlays may not only provide objectmanagement capabilities but may also serve as a backup infrastructure for the network maintenance incases where the primary low-latency overlay fails.Of course, since the goal is to compare different approaches particularly of peer-to-peer systems forgames, there is task of implementing further of these approaches. Some alternatives have already beenpublished, but with the experience gained from the Planet π4 implementation it is likely that new approachescan be developed. And even the existing implementation of pSense may be further improved,e.g., by extending the sensor node mechanism to the 3D space, possibly applying the suggested schemebased on platonic solids.For the purpose of simulation particularly of large systems, it is desirable to optimize the game furtherfor low resource usage in simulation mode. The omission of texture loading already saves a significantamount of memory. But still, the whole Irrlicht engine is working even if no visual output is rendered.Being an integral part of the game mechanics, the Irrlicht engine cannot be simply removed. But theremay be solutions making a better tradeoff between the required infrastructure and resource consumptionin simulation mode. The simulator itself should also be further improved to support more scenarios andfurther logging and tracing capabilities for a more detailed analysis. But that is an extra topic and notdiscussed here in more detail.An important tool that should be developed for evaluation purposes is a mechanism for measuringprotocol quality. Abstractly, the protocol quality is a measure for the differences in the game worldstates on different participating nodes. The most important source of (temporary) discrepancies ofgame state between nodes are the network latencies. The challenge while measuring the discrepanciesin a distributed system is the fact that the communication channels used for synchronization of themeasurements are affected by the same latencies. The whole situation is much easier when the systemis run in a simulator; there may be simply a global component collecting all necessary information fromthe simulated nodes. But the simulation runs have to be validated by real-world experiments, thus adistributed mechanism for measuring protocol quality in real networks would be a highly valuable tool.Finally, distributing the game in a large scale and letting several thousands of players play over theinternet, possibly gathering information about the protocol quality and player experiences, will greatlyexpand the knowledge about peer-to-peer massively multiplayer gaming.6 Conclusion 85
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 80 and 81: Table 5.3: Computation time and mem
Page 82 and 83: Table 5.4: Computation time and mem
Page 85: 6 ConclusionThe core task of this w
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?