Master Thesis Towards Peer-to-Peer Games: XP2Pilot Jean-Luc Geering [email protected] Dept. of Computer Science Swiss Federal Institute of Technology (ETH) Zurich Summer 2007 Prof. Dr. Roger Wattenhofer Distributed Computing Group Advisors: Stefan Schmid, Thomas Locher Abstract A game is both an interesting and a complex application. Having a shared state makes it a challenging undertaking to develop it in a peer-to-peer setting. XP2Pilot is an implementation of such a game. It is a fully decentralized version of XPilot-NG, built on top of Pulsar. Acknowledgments First of all, I would like to thank Prof. Dr. Wattenhofer for giving me the opportunity to work on this most interesting and challenging project. During this truly unique experience, I benefitted not only on a technical but also on a personal level. Stefan Schmid and Thomas Locher, my faithful advisors, thank you for not breaking my e-bike when you took it for a ride. Special thanks to Remo Meier who allowed me to use Pulsar and was always quick to respond to my numerous questions.1 Cordial thanks to the open-source communities. They make the world a better place. At least the virtual one. To the Swiss taxpayers, thank you for financing my education. Keep up the good work, the SFITZ2 is such an awesome institution. To the TIK, thank you for lending me Funghi. He was a good companion who never let me down during the six months we spent together. I wished all laptops would behave like he did. To the Swiss Federal Railways, thank you for letting me feed Funghi on your trains. We could spend even more time working together. Thanks to my family, friends and fellow students for playing my game when it was neither finished nor fun. Thanks, Jean-Paul W¨urth.Your nonsense full of meaning helped me in a crucial mo- ment. To all those who pretended listening to me when I was complaining - I hope we can still be friends. Let's not forget all the brave readers of this report: Thank you and good luck! 1Yes, I know, I should have read the documentation first. 2Aka EPFZ aka ETHZ. 2 Contents 1 Introduction 5 1.1 Common Uses of Peer-to-Peer . 5 1.1.1 File Sharing . 5 1.1.2 Multimedia Live Streaming . 5 1.1.3 Distributed Hash Tables . 6 1.2 Peer-to-Peer and Games . 6 2 Components 7 2.1 Game . 7 2.2 Network: Peer-to-Peer Overlay . 7 3 Architecture and Design 9 3.1 The Game . 9 3.2 From XPilot-NG to XP2Pilot ........................ 10 3.3 Network Layer . 11 3.4 Game Engine . 11 3.4.1 Server Role . 11 3.4.2 Registrar Role . 12 3.4.3 Client Role . 12 3.5 The Pieces and their State . 12 3.6 Network Dynamics . 13 3.6.1 Piece Subscriptions . 14 3.6.2 Piece Transfer States . 15 3.7 Network States . 17 3.8 Player Management . 18 3.9 A Final Comment . 19 4 Implementation 21 4.1 Spring . 21 4.2 The ch.dongxi.xpilot.game.* classes . 21 4.3 The ch.dongxi.xpilot.legacy.* classes . 21 4.3.1 The ch.dongxi.xpilot.legacy.map package . 22 4.3.2 The ch.dongxi.xpilot.legacy.net.packet package . 22 4.4 The ch.dongxi.xpilot.net.* classes . 22 4.5 The ch.dongxi.xpilot.p2p.* classes . 22 4.5.1 The ch.dongxi.xpilot.legacy.p2p.message package . 23 4.6 The ch.dongxi.xpilot.pulsar.* classes . 23 4.7 The ch.dongxi.xpilot.tasks.* classes . 24 4.8 The ch.dongxi.xpilot.view.* classes . 24 4.9 The ch.dongxi.xpilot.world.* classes . 25 4.10 Threads . 25 5 Conclusion 27 3 Chapter 1 Introduction There are many peer-to-peer applications, but most of them do not have a shared state. On the other hand, games have to deal with player interaction, i.e. a shared state. Would it not be interesting to store and manipulate a shared state in a not only distributed but also fully decentralized system, in other words, build a peer-to-peer game? 1.1 Common Uses of Peer-to-Peer 1.1.1 File Sharing The most prominent use of peer-to-peer technology nowadays is file sharing. The Gnutella network is one example of an early successful application, and today Bit- torrent [1] is the dominant file sharing protocol. The characteristics of file sharing are that the content is static, i.e. the file being shared does not change,1 there are no timing constrains, and the goal is to transmit information from one to many other nodes. If we only look at the information that has been sent after the transfer is complete, it is equivalent to one server sending the same content to many clients.2 1.1.2 Multimedia Live Streaming The new trend in peer-to-peer computing is to replace a streaming server with a peer- to-peer distribution scheme. In Switzerland Zattoo3 is already a popular live video streaming system, although it does not deliver very good quality. Joost is a service by the makers of Kazaa and Skype. Pulsar [2], is a new peer-to-peer based protocol which promises good performance. We find some of the same characteristics in streaming as in file sharing: the goal is to distribute content from one server to many clients in an efficient and robust way. If we consider each frame of a video stream separately, the content is also static, but small and with a short life-span. But contrarily to file sharing there are timing constrains. The frames have to be delivered in order and on time. A delay of a few seconds is acceptable, but certainly a few hours or days like we know it from file sharing applications, is out of question. 1In case it does change, it will be shared as a new file. 2Of course it is far more efficient, and even if the first node goes offline the data keeps spreading. 3http://www.zattoo.com 5 1.1.3 Distributed Hash Tables A distributed hash table (DHT) is a fully decentralized system for storing, looking up and retrieving key-value pairs. Important features include scaling to a large number of nodes, fast message routing and good performance and resilience under churn. Well known examples of DHTs are CAN [3], Chord [4] and Pastry [5]. A DHT consists of a keyspace, i.e. the set of allowed keys, for example the 16 bytes bit strings, and a keyspace partitioning scheme describing how to split ownership among participating nodes. To illustrate this, let us consider a circular keyspace. Each node has its own ID that serves as a key or, if it is not in the right format, can be hashed into a key. This ID defines its position on the circle. The node owns and is responsible for all the keys between its ID and the ID of the next node on the circle. The nodes connect to neighbours and arrange themselves in an overlay network. The different protocols define to which and to how many neighbours a node has to connect. This determines how fast a protocol can route messages, how well it scales and handles churn. The data stored in a DHT is also static. Direct modification of the values is not possible. To update a value, a new value is inserted with an identical key, to replace the old one. 1.2 Peer-to-Peer and Games Games are an interesting application for peer-to-peer computing. While a shared state and player interactions need to be taken care of (i.e., the content is not static), absolute correctness and consistency do not have to be guaranteed (a game is no banking soft- ware). As long as they do not trouble the user too often, errors can be tolerated. In order for a game to be easily distributed, locality of interest is essential [6]. A peer-to- peer game where every node needs to know about everything is certainly feasible, but it would not benefit of most advantages of a distributed system. Depending on the game, a node's visibility can be limited without influencing the user experience, e.g. any 2D war game with limited screen size and fog of war.4 On the contrary, it would be absurd to play chess seeing only a quarter of the board at the time. There are also timing constrains to be considered when implementing a game, as the user expects a fast feedback for his actions. In this sense, a game might be even more sensitive to delays than a live streaming application. Any game will have its share of cheaters, and so will peer-to-peer ones. The architecture of the system should include anti-cheating mechanisms whenever possible, and make it hard to cheat when it cannot be prevented. 4 [7] further reduced the amount of data transmited by defining focus sets. 6 Chapter 2 Components 2.1 Game Instead of writing a new game from scratch, we chose a existing open-source client-server game. Two multiplayer games, both realtime, were considered: Quake 3 is a first person shooter and has been used many times for research (e.g., [7], [8]). Its engine is freely available, but some components still have to be bought to actually run the game. The game is also fairly complex, has advanced graphics and dead reckoning. XPilot (Fig. 2.1) is an Asteroids-like 2D multiplayer game, where items can be collected to enhance the offense or defense characteristics of the player's ship.