6.1 Future WorkAs pointed out in several places throughout this document, there is a lot <strong>of</strong> continuing work that canbe done in the different <strong>to</strong>pics addressed <strong>with</strong>in this work. Those include several aspects <strong>of</strong> the gamelike gameplay modes, particularly for large numbers <strong>of</strong> players, further improvements in the networkingimplementations, and evaluation and simulation <strong>to</strong>ols.Currently, the game Planet π4 has only a simple deathmatch gameplay mode. This mode is feasiblefor some testing and demonstration <strong>of</strong> networking models, and can be played by a simple bot implementation.But in order <strong>to</strong> generate workloads conforming <strong>to</strong> those <strong>of</strong> real games, it is necessary <strong>to</strong>develop gameplay modes that resemble those <strong>of</strong> popular online games. This is not only important forthe representativeness <strong>of</strong> the workload itself but also generated opportunities for collecting experienceby letting possibly large numbers <strong>of</strong> human players play the game. And that is only feasible if the gameis attractive <strong>to</strong> the players.Instead <strong>of</strong> a deathmatch <strong>with</strong> everyone fighting against each other, the players could be assigned <strong>to</strong>teams which have <strong>to</strong> compete. An example <strong>of</strong> a common gameplay mode is capture-the-flag (CTF) whereeach team tries <strong>to</strong> steal a flag from the base <strong>of</strong> the other team while protecting its own flag. For a largernumber <strong>of</strong> players it is necessary <strong>to</strong> develop more sophisticated gameplay modes because simple modeslike CTF scale only <strong>to</strong> a certain number <strong>of</strong> players/teams. The common model in role-playing games(MMORPGs) is <strong>to</strong> provide quests that small groups <strong>of</strong> players solve <strong>to</strong>gether, while the massive number<strong>of</strong> players forms a society (economic and social) but is not directly involved in most <strong>of</strong> the game activities<strong>of</strong> a single player. For shooter games like Planet π4, there are no massively multiplayer gameplay modesyet, thus they still need <strong>to</strong> be developed.For supporting attractive gameplay modes, Planet π4 also needs <strong>to</strong> be equipped <strong>with</strong> a bunch <strong>of</strong> basicfeatures that are still missing at the moment. One <strong>of</strong> them is a collision detection among spaceships andthe terrain. The terrain needs <strong>to</strong> be expanded and enriched <strong>with</strong> 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. <strong>Game</strong> objects can be used e.g., for mutable terrain features (breakable parts,doors, etc.) and objects directly related <strong>to</strong> the gameplay (the flag in CTF). The whole <strong>to</strong>pic <strong>of</strong> 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 <strong>to</strong> be improved. But the particular strategies that need <strong>to</strong> be implementeddepend on the focused gameplay modes. Another approach for workload generation would be therecording <strong>of</strong> traces <strong>of</strong> games played by humans and replaying the games in simulation runs. But italways has <strong>to</strong> be concerned that the properties <strong>of</strong> different network engines also influence the game,feeding back <strong>to</strong> the players’ behaviors. Thus it may not be feasible <strong>to</strong> just replay the same game forcomparing network implementations.Further improvements are achievable in the game’ s<strong>of</strong>tware architecture. This work made importantsteps <strong>to</strong>wards a low-coupled and flexible s<strong>of</strong>tware system. But there are still some remains <strong>of</strong> code thatrequires special handling, reducing replaceability and extensibility. One example is the Avatar/Spaceshipconstruct that at some point needs <strong>to</strong> waive abstraction. Those improvements have <strong>to</strong> go hand in and<strong>with</strong> the design <strong>of</strong> 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 <strong>of</strong> modelling shooting. If further interactionsbetween players are introduced, it may become desirable <strong>to</strong> design a general purpose mechanism thatmay (reliably) handle various types <strong>of</strong> interaction.84 6.1 Future Work
New game features and improvements <strong>of</strong> the game mechanics do <strong>of</strong> course have an effect on thenetwork engine requirements. Especially new features like an object model introduce completely newchallenges for peer-<strong>to</strong>-peer network engines. pSense only manages the players’ avatars but does nothandle other types <strong>of</strong> game objects. General-purpose overlays (DHTs or unstructured systems like BubbleS<strong>to</strong>rm)appear <strong>to</strong> be an appropriate base for distributed game object management, as shown byseveral approaches dealing <strong>with</strong> that <strong>to</strong>pic (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 <strong>to</strong> compare different approaches particularly <strong>of</strong> peer-<strong>to</strong>-peer systems forgames, there is task <strong>of</strong> implementing further <strong>of</strong> these approaches. Some alternatives have already beenpublished, but <strong>with</strong> the experience gained from the Planet π4 implementation it is likely that new approachescan be developed. And even the existing implementation <strong>of</strong> pSense may be further improved,e.g., by extending the sensor node mechanism <strong>to</strong> the 3D space, possibly applying the suggested schemebased on pla<strong>to</strong>nic solids.For the purpose <strong>of</strong> simulation particularly <strong>of</strong> large systems, it is desirable <strong>to</strong> optimize the game furtherfor low resource usage in simulation mode. The omission <strong>of</strong> texture loading already saves a significantamount <strong>of</strong> memory. But still, the whole Irrlicht engine is working even if no visual output is rendered.Being an integral part <strong>of</strong> the game mechanics, the Irrlicht engine cannot be simply removed. But theremay be solutions making a better trade<strong>of</strong>f between the required infrastructure and resource consumptionin simulation mode. The simula<strong>to</strong>r itself should also be further improved <strong>to</strong> support more scenarios andfurther logging and tracing capabilities for a more detailed analysis. But that is an extra <strong>to</strong>pic and notdiscussed here in more detail.An important <strong>to</strong>ol that should be developed for evaluation purposes is a mechanism for measuringpro<strong>to</strong>col quality. Abstractly, the pro<strong>to</strong>col quality is a measure for the differences in the game worldstates on different participating nodes. The most important source <strong>of</strong> (temporary) discrepancies <strong>of</strong>game 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 <strong>of</strong> themeasurements are affected by the same latencies. The whole situation is much easier when the systemis run in a simula<strong>to</strong>r; there may be simply a global component collecting all necessary information fromthe simulated nodes. But the simulation runs have <strong>to</strong> be validated by real-world experiments, thus adistributed mechanism for measuring pro<strong>to</strong>col quality in real networks would be a highly valuable <strong>to</strong>ol.Finally, distributing the game in a large scale and letting several thousands <strong>of</strong> players play over theinternet, possibly gathering information about the pro<strong>to</strong>col quality and player experiences, will greatlyexpand the knowledge about peer-<strong>to</strong>-peer massively multiplayer gaming.6 Conclusion 85