Multi-Screen Online Multiplayer Game for an Android Device

Transcription

1 COMP 4905 Honours Project Multi-Screen Online Multiplayer Game for an Android Device Author: Nicholas Tierney Supervised by: Dr. Tony White School of Computer Science Carleton University Ottawa, Canada April 18,

2 Abstract The goal of this project is to create a multiplayer game that uses both a computer screen and an Android device to convey information to its players. The main focus will be producing software that will provide a zero-configuration networking experience to the user, through the use of service discovery. The local area network service discovery will be handled by the Bonjour library, and the remote through a simple name server registration setup. Messaging will be handled by the RabbitMQ library with JSON being used for serialization. The game will use OpenGL ES 1.1 for Android and the whole project will be programmed in Java. With the imminent release of the Wii-U and the rising popularity of smart televisions, we will soon see a rise in the number of multi-screen applications being released. It is for this reason that I have chosen to create an application of the sort for my project. A few problems arise when creating a multi-screen application, due to the involvement of multiple devices. The first problem is discovery of devices and the second is communication between said devices. With this project, I hope to provide an implementation of such an application by using a combination of pre-existing technologies. From this project I hope to acquire a better understanding of the technologies required in order to develop both locally and remotely distributed applications, and to learn how to create an application that requires very little configuration in order to begin the communication between devices. In addition to this, I want to apply my knowledge of DirectX in order to learn how to implement games with OpenGL on a handheld device. Page 2

3 Acknowledgement There are a few people at this point that I would like to recognize, for making some of contribution to this project. First of all, I would like to thank Dr. Tony White for his patience and help starting me off on the right track, and for the interest in these subjects that I acquired during his Comp 4104 class. I would also like to thank my family, for their motivation along the way and my friends, for allowing me to ignore them for a while. Page 3

4 Table of Contents Abstract... 2 Acknowledgement... 3 Game Description... 5 Introduction... 5 Game Rules and Player Interaction... 5 Graphics and Input... 5 Service Discovery Description... 7 Messaging Protocol Description Code Documentation Half-Sync/ Half-Async Message Queues Reactor Pattern Pipe and Filter Model View Controller Project Results Concepts and Technologies Learned Future Work Conclusion Appendices Submission Contents Required Tools Project Setup References... 1 Page 4

5 List of Figures... 2 Game Description Introduction The given name for the game that users will experience is Maze Racer, where players navigate their way through a maze simultaneously in pursuit of a goal. The maze in focus will be randomly generated at the start of each session, and only through the clever use of both visual outputs will a player succeed. Each player with their own android device will have their own view of the three dimensional world from a first person perspective and a two dimensional shared view of the world from a bird s eye view. This game has been created to show how older, simpler games can be designed from a newer perspective. The main goal of this game is to show how having a personalized perspective for each player can affect the mechanics of a Game Rules and Player Interaction At the beginning of each game, players are placed into a randomly generated maze. A single golden star will be placed inside of the level, and players must race to be the first to acquire it. When the golden star is taken by a player, a new one will randomly spawn in the maze and the process will restart however, players will not revert to their starting places. In order to win the game, a single player must be the first to collect five golden stars. Graphics and Input Having two screens to work with allows for a certain amount of creativity that would not normally be feasible. By designing different graphical viewpoints, both representing the same world, on each screen, new mechanics that rely on this can be implemented. The game on the Android client is rendered entirely in 3-D; it uses a mobile version OpenGL to do this. The maze is viewed from the player s perspective, so that only nearby obstacles can be Page 5

6 viewed. When using the Android client, a player can move around the world by sliding their finger on the screen in the direction they wish to go. Figure 1 - View of Game on Android Device Players will get an eagles-view of the maze from the PC Client, as the screen is shared between everyone in the game. The game on the PC is rendered in 2-D, using Java s Swing components. There is no input for the PC, as everyone controls the game from their own Android device. Page 6

7 Figure 2 - View of Game on PC Service Discovery Description There are two primary forms of service discovery that occur in this project. The first type of discovery happens between handheld devices running the Android client (MSPhoneClient) and computers running the Java client (MSPCClient) within the local network. The second type of discovery is between different computers running different instances of the game lobby over a wide area network (WAN). The two types of discovery are implemented in completely different ways, since multicasting a service over a WAN is not practical (or potentially possible.) When searching for services on a local network the advantage lies in the ability to multicast messages over the network, which is possible due to the limited amount of devices. Multicast service discovery is such a powerful tool over a local network, since any device that is part of the network can find or broadcast a service to any other device a feature such as this would not be possible over a WAN due to the sheer number of devices that exist. The advantage of multicasting is taken advantage of through the use of ZeroConfig service discovery. Bonjour, an implementation of such a service, is used in order to detect which Lobbies are active on PCs nearby from Android devices that are running the client. The second type of service discovery happens over a wide area network, when lobbies are searching for hosting lobbies to join. Since we cannot take advantage of ZeroConfig service Page 7

8 discovery over a WAN, another scheme must be used which in this case is a simple name server setup. Lobbies that are hosting games will register themselves with an external static server, adding them to a list with all of the other lobbies that are hosting a game as well. When a lobby is created, it will do two things. The first thing that the lobby will do is to broadcast its service over the local network using the Bonjour library, allowing phones on the local network to find it. The next thing a lobby will do is register itself with the static name server over the WAN, allowing other lobbies to discover itself. Page 8

9 Figure 3 - Diagram of Network Connectivity Page 9

10 Messaging Protocol Description Compatibility can be an important feature of a piece of software, as it can increase the total number of users that can use it. By implementing the messaging protocol entirely with JSON, or JavaScript Object Notation, it can be compatible with a large number of end users. Each message is a JSON object with the arguments that are described in the following table. Event Name Arguments Description PlayerLobbyEvent PlayerGameEvent GameLoadEvent string playerid int actiontype string playerid int actiontype float spacesizeratio float spaceplayerratio int levelwidth int levelheight Wall[] walls Sent when a player performs some action that would change either their state in the Lobby or the Lobby itself. Sent when a player performs an action in the Game. Contains data relevant to the layout of components that make up a Level. GameStatusEvent Int actiontype Sent when the state of the Game has changed. RegisterLobbyEvent String playerid Sent when a lobby registers or unregisters String IP Int port boolean register GetLobbyEvent String playerid Request for registered lobbies String IP Int port ReturnLobbyEvent ArrayList<ConnectionInfo> Contains the set of lobbies that are registered Figure 4 - Table Displaying the Messaging Protocol Page 10

11 Code Documentation Several patterns of code design were used in the creation of this project; this section will give an overview of these concepts and then show how they are used in combination. Half-Sync/ Half-Async This half-sync / half-async pattern decouples asynchronous and synchronous service processing in concurrent systems. [1] This structure is used in order to allow asynchronous messaging to interact with the rest of the program, a synchronous service. In order to combine these two layers, a third queuing layer is necessary to provide a way to control the flow of both incoming and outgoing messages. Figure 5 - DIagram of Half-Sync/Half-Async pattern Message Queues The messaging of the program is entirely handled through implementation of message queues, specifically RabbitMQ. Message queues provide a necessary service that simplifies the structure of how messages are sent between clients and allows this to become an asynchronous process. A consumer/producer pattern is the underlying structure of message queues. After creating a queue, a producer will add to it and a consumer will remove this allows messages to be passed from one client to another in an asynchronous fashion. Page 11

12 Reactor Pattern The reactor design pattern allows for asynchronous messages to be dispatched to the program model in a synchronous format. It also provides a way to determine which event handlers will be used in conjunction with which event types. Event handlers are loaded upon start time through class reflection, determined by the names given in a configuration file. The reactor will follow a continuous cycle after it has been initialized in one or possibly more threads; each thread will remove an event from the incoming queue, determine the event handler that is associated with that event and then carry out the action that is specified in the handler. Pipe and Filter When an event is transported from one client to another, it does so in a fashion that allows for both security and compatibility. In order to allow for compatibility, events must be converted into a format that stays consistent with as many clients and middleware as possible. This compatibility is achieved through the pipe and filter method by passing an event through multiple stages of encoding. When a message is received, it will begin in a byte format and get converted into a String. After we have the event in a String format, it is reorganized back into a JSONObject that will contain all of the header information and the event itself. The final step of this process is to infer the type from the header to create the event object from the arguments inside of the JSONObject. Model View Controller In order to maintain a graphical user interface with relevant data that may not match up directly with the model, the MVC architecture is used in this project. This architecture is used specifically in the PC client, and to a lesser degree on the Android client. By maintaining a correct model of the data on its own, without combination of interface into the design, a proper structure is easier to maintain. The same is true about the interface, since it is not integrated into the model, there can be a more accurate representation of structure. Since the view is not integrated into the structure of the model, there must be a way for it to detect when changes have been made- a problem solved by following the Observer pattern as well. Page 12

13 When changes are made to the model, it will notify the Observer and the correct changes to the interface will be made. Project Results What I accomplished with this project is less than I had wanted to, but for the most part I have learned what I have wanted to. My implementation of the project did not quite come through with the success that I had hoped, I managed to get ZeroConfig networking implemented fully as well as learning how to use JSON for message protocols and RabbitMQ message queues for communication. The combination of these technologies allowed me to create a working game lobby, but I wasn t actually able to get the game working. I was able to fully implement the ZeroConf networking, Android clients can discover PC clients and join lobbies as well as the game. Once they are in the game they can change their ready state. Figure 6 - Android Client Options Screen Page 13

14 This project managed to be a moderate success, but I felt as though I didn t get as much done that I would have liked to. When I started this project, I had several goals that I wanted to accomplish. The first thing that I wished to learn was how to develop an Android application, which I now have a further grasp on. I have learned how to make some basic applications including lists and buttons, as well as including OpenGL. I discovered the difficult process of testing applications for Android on a PC, that it is almost necessary to have a physical device when building your application. Figure 7 - PC Client Lobby Screen I wanted to learn how to create a program in OpenGL, which I found that I had quite enough success with. I managed to implement the basic levels of my game inside using OpenGL, but was not able to spend much time polishing or completing what I had wanted to even though I had learned how it had worked. Concepts and Technologies Learned The technologies that I learned very much about while doing this project are ZeroConfig networking, android app development and JSON. ZeroConfig was a really important thing to Page 14

15 learn about, as it can simplify so many applications that I can think about developing. JSON is also a helpful tool, as it is being used everywhere; it really changed how I think about messaging across different clients. Future Work In the future, there is still some work to be done to getting my project to a finished state. There isn t much left when it comes down to it, but there is still more work to be done on game mechanics as well as finishing the protocol for the actual game. I would like to make it so that the name server registration works properly, it is only a few steps from being complete and once that is finished, multiple lobbies can connect and games can actually be played across the web. Conclusion The most important thing that I learned from this project is to not take more than I can handle. I feel that I decided to do too many things, and many parts were nearly implemented but it just did not mesh together properly taking away from the experience. I learned that I would like to spend more of my time in the future learning about networking, and how it can be used in order to make tasks while working easier. Appendices Submission Contents The zip file that is included with this report contains the following eclipse projects: MSAndroidClient the client that is run on Android devices MSPCClient the client for game lobbies that is run on the PC MSServer the name server that lobbies use for registration Required Tools Several tools are required in order to properly run this software. Page 15

16 Java SDK 1.7 is required for the PC Clients, and 1.6 for Android devices[2] Android SDK with API level 16 or higher[3] ADB Plugin for Eclipse[3] RabbitMQ server version 3.0.4[4] Erlang AMQP client library protocol version 0-9-1[4] Project Setup In order to run this project, the three project folders must be imported into the IDE. To run the PC Client, the PCClient class must be run normally from inside of Eclipse. Any android client that is to be launched must have an actual device connected to the computer, in order to take advantage of the ZeroConf networking. For the first time running an android client, the main activity must be run from Eclipse. Page 16

17 References [1] "Architecture and Design of Dependable Systems TIARDIPOSA2: Half-Sync / Half-Async Archictectural Pattern," Aarhus University, [Online]. Available: [Accessed 7 February 2013]. [2] "Oracle Technology Network Downloads," [Online]. Available: [3] "Android Devoppers Website," [Online]. Available: [4] "RabbitMQ Downloads," [Online]. Available: 1

18 List of Figures Figure 1 - View of Game on Android Device... 6 Figure 2 - View of Game on PC... 7 Figure 3 - Diagram of Network Connectivity... 9 Figure 4 - Table Displaying the Messaging Protocol Figure 5 - DIagram of Half-Sync/Half-Async pattern Page 2

19 Page 3