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, 2013

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

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

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 ................................................................................................... 10 Code Documentation .................................................................................................................... 11 Half-Sync/ Half-Async ................................................................................................................ 11 Message Queues ....................................................................................................................... 11 Reactor Pattern ......................................................................................................................... 12 Pipe and Filter ........................................................................................................................... 12 Model View Controller .............................................................................................................. 12 Project Results .............................................................................................................................. 13 Concepts and Technologies Learned ............................................................................................ 14 Future Work .................................................................................................................................. 15 Conclusion ..................................................................................................................................... 15 Appendices.................................................................................................................................... 15 Submission Contents ................................................................................................................. 15 Required Tools........................................................................................................................... 15 Project Setup ............................................................................................................................. 16 References ...................................................................................................................................... 1 Page 4

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 birds 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 players perspective, so that only nearby obstacles can be

Page 5

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 Javas Swing components. There is no input for the PC, as everyone controls the game from their own Android device.

Page 6

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

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

Figure 3 - Diagram of Network Connectivity

Page 9

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 PlayerLobbyEvent Arguments string playerID int actionType Description Sent when a player performs some action that would change either their state in the Lobby or the Lobby itself. PlayerGameEvent string playerID int actionType GameLoadEvent float spaceSizeRatio float spacePlayerRatio int levelWidth int levelHeight Wall[] walls 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 String IP Int port boolean register

Sent when a lobby registers or unregisters

GetLobbyEvent

String playerID String IP Int port

Request for registered lobbies

ReturnLobbyEvent

ArrayList<ConnectionInfo> Contains the set of lobbies that are registered

Figure 4 - Table Displaying the Messaging Protocol

Page 10

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

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

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 wasnt 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

This project managed to be a moderate success, but I felt as though I didnt 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

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 isnt 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

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

References

[1] "Architecture and Design of Dependable Systems TIARDIPOSA2: Half-Sync / Half-Async Archictectural Pattern," Aarhus University, 2012. [Online]. Available: http://kurser.iha.dk/ee-ict-master/tiardi/Slides/ARDI5-POSA2-HalfSyncHalfAsync.pdf. [Accessed 7 February 2013]. [2] "Oracle Technology Network Downloads," [Online]. Available: http://www.oracle.com/technetwork/java/javase/downloads/index.html. [3] "Android Devoppers Website," [Online]. Available: http://developer.android.com/sdk/index.html. [4] "RabbitMQ Downloads," [Online]. Available: http://www.rabbitmq.com/download.html.

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 ..................................................................... 10 Figure 5 - DIagram of Half-Sync/Half-Async pattern .................................................................... 11

Page 2

Page 3