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

6 ConclusionThe core task of this work was the development of a simple client-server and, more importantly, a peerto-peernetwork engine for the game Planet π4. Surrounding that topic, a set of other tasks was tackled,all of them providing support for the core networking topic.The completely reworked network architecture of Planet π4 now allows for a simple replacement ofthe network engine. Two rather opposite networking approaches, a group-based client-server systemand an unstructured peer-to-peer system, were both successfully applied to that architecture, proving itsflexibility. The network system is fully pluggable, thus it is even possible to select/switch the networkengine at runtime.Other parts of the game were also made exchangeable. Most importantly, the main loop can bereplaced, particularly allowing to run the complete game in an discrete-event simulator. This unites thetwo basically contradicting approaches of the busy loop that games usually run and the event basedsimulator’s main loop that is not under control of the application which is running in the simulator. Fordecoupling the various game components, the internal eventing infrastructure was extended and is nowused as the central communication point between components.Since all current and future networking models have to be evaluated, there is the need for workloadgeneration. The most obvious way of workload generation is just letting human players play the game.But that is too time-consuming in many cases, especially for large numbers of players. Thus, an AIcomponent was developed, providing a bot player that plays the game according to simple rules. Thesimple bots do not generate a completely realistic workload, but the nonstop best-effort activity generatesmore workload in average than a human player would do, so it can be seen as a worst-case scenario.Being the first customer of CUSP, important feedback was provided, especially in CUSP’s late developmentand testing phase. Particularly the peer-to-peer networking implementation represents a typicaluse case that CUSP aims at. Also, the development and evaluation of the C++ bindings for CUSP are animportant contribution, since only a small fraction of applications which may potentially use CUSP arewritten in Standard ML. The C++ API is thus assumingly to become more relevant for external applicationsthan the original Standard ML API. The evaluation has shown that CUSP is a powerful and reliableprotocol but introduces some challenges particularly for the C++ programmer.Three variants of networking code were implemented and evaluated. While the two client-serverversions are similar in their functionality and primarily comparing the applicability of TCP and CUSP, thepeer-to-peer version introduces a new concept. The CUSP client-server and peer-to-peer implementationswere evaluated concerning scalability with a focus on the traffic requirements. Although the absolutevalues are likely to change with further protocol optimization, the trends are definitely meaningful.Those show that the client-server version is strongly limited by the server capabilities. The generatedtraffic grows quadratic with the number of players. This behavior can also be observed in the peer-topeerversion, but on a lower level. And, more importantly, the peer traffic (almost) only depends on thenumber of players in the vision range; all players outside the vision range do not affect the peer at allexcept for the maximum of eight sensor nodes. Thus, the pSense implementation has shown to be inprinciple qualified for massively multiplayer games of any size as long as the player density is rather low.The peer-to-peer version of the game is able to run in the CUSP simulator, allowing for a simplifiedand more deterministic analysis on certain aspects. The number of players is bounded by the availablememory and CPU power (or time constraints). Up to 128 players were successfully simulated; 4GB ofRAM, the typical memory configuration of today’s desktop PCs, is enough for that. Nevertheless, it isdesirable to optimize further for simulation performance in order to achieve greater player numbers andstill acceptable simulation times.6 Conclusion 83