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

More documents

Recommendations

Info

}// init gamegame ->init(device , timer , eventMgr);// set up AI (optional)GameAI* = new SimpleAI();ai->init(game , timer , eventMgr);Finally, the main event processing loop provided by the timer component is started:timer ->run();The run() method blocks until the game is aborted. When it returns, all game objects are cleaned upand the program exits.An alternate network engine can be used simply by instantiating another implementation. For instance,the client-server network for the group network engine is set up using the following two lines:GroupNetwork* network = new CUSPClientServerNet(localPort , serverAddr);NetworkEngine* networkEngine = new GroupNetworkEngine(network);4.3.2 GUI-less SetupIf the game is to be run without a 3D rendered GUI, two minor changes are necessary. Most importantly,IrrlichtDev has to be instructed to omit the setup of 3D rendering by setting the second parameter ofits constructor to false:IrrlichtDev* device = new IrrlichtDev(eventMgr , false);Second, it is advisable to use the GameTimer implementation for the BubbleStorm/CUSP library to getrid of the busy-wait main loop. Of course, this only works if CUSP is used as the transport protocol.GameTimer* timer = new BSTimer();4.3.3 Further ConfigurationSome further configuration settings for various components are stored in config.h. Currently these areprimarily the locations of media files (3D models and textures) for the rendering engine.4.4 SimulationTo run the game in the BubbleStorm/CUSP simulator, it is not built as an executable but as a staticlibrary to be linked to the simulator. The library is built without main.cpp but instead with simnode.cppcontaining the entry point for the game. Instead of a main() function, there is void startNode(constchar* peerAddr, const char* gatewayAddr).The startNode() function initializes a single node game instance in a way very similar to the mainfunction of the standalone game version. The two function parameters specify the peer addresses for connectingto the virtual peer-to-peer network. peerAddr specifies the peer to connect to, and gatewayAddroptionally specifies a gateway node that helps with the connection to the peer if that peer is behind aNAT in the simulated network. In the simulator, addresses are not IP addresses but just node IDs. Butas long as the application does not expect a particular addres format, the CUSP simulator keeps thedifferences to real networking completely transparent to the application.62 4.4 Simulation
Thus, the network initialization code can be exactly the same as in real networking mode, with theonly difference that blocking operations are not allowed. The only case in which this currently mattersis the process of connecting to the network which is executed using NetworkEngine::connectSync()for convenience reasons in the standalone game example above. For use with the simulator it is necessaryto use the non-blocking version NetworkEngine::connectAsync() (which can also be used instandalone mode). Any operation that needs to be executed after a successful connect has to be movedto connectAsync()’s callback function. The corresponding C++ code (simnode.cpp) is included in appendixA.1.4.4.1 Simulator ConfigurationThe startNode() function is not invoked directly by the simulator environment. Instead, there is someStandard ML code that configures the simulator and calls startNode() imported from the C++ library.The code that connects the game with the simulator (simulator.mlb) is listed in A.2. Additionally there isthe file setup.sml which configures the different simulator components, including:Simulated networking. The simulated UDP networking component replaces the real networking usingsockets. A CUSP transport instance is created on top of the simulated UDP network.Scenario and node creation. The scenario, i.e., the number and distribution of the nodes including theirconnection properties, is loaded from a SQLite 2 database. A node factory automatically createsnodes corresponding to the scenario configuration.Logging facilities. The simulator’s logging facilities allow for a detailed logging that may be post-processedfor evaluation. For instance, the logging output could be written to an SQL database where it ispossible to query for certain events.A detailed documentation on the simulator is beyond the scope of this work.sources 3 for more information.Refer to the CUSP4.5 UsageThis section briefly explains how the software project related to this work, planetp4v2, can be built andexecuted.4.5.1 RequirementsThe project was developed and tested using Linux. Although the required tools and libraries are alsoavailable for Windows and Mac OS X, it is recommended to use Linux as this guide does not cover theother operating systems.Irrlichthttp://irrlicht.sourceforge.net/The project depends on Irrlicht version 1.5. The Irrlicht SDK is available for Windows and Linux and asa separate Mac OS X version.2 http://www.sqlite.org/3 http://www.dvs.tu-darmstadt.de/research/cusp/4 Implementation 63
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 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 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

Create successful ePaper yourself

Delete template?

Save as template?