Comp 4905 Honors Project - Multi-Screen Online Multiplayer Game for an Android Device

7/28/2019 Comp 4905 Honors Project - Multi-Screen Online Multiplayer Game for an Android Device

1/19

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


2/19

Page 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 theuse 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 tocreate 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.


3/19

Page 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 acquiredduring 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.


4/19

Page 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 ................................................................................................... 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


5/19

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


6/19

Page 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 betweeneveryone 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.


7/19

Page 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


8/19

Page 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.


9/19

Page 9

Figure 3 - Diagram of Network Connectivity


10/19

Page 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 string playerID

int actionType

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

Sent when a player performs an action in the

Game.

GameLoadEvent float spaceSizeRatio

float spacePlayerRatio

int levelWidth

int levelHeight

Wall[] walls

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 Contains the set of lobbies that are registered

Figure 4 - Table Displaying the Messaging Protocol


11/19

Page 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.


12/19

Page 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.


13/19

Page 13

When changes are made to the model, it will notify the Observer and the correct changes to

the interface will be made.

Project ResultsWhat 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


14/19

Page 14

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


15/19

Page 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

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.


16/19

Page 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.


17/19

1

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.


18/19

Page 2

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
http://c/Users/Nick/Downloads/Nick2.docx%23_Toc354178730http://c/Users/Nick/Downloads/Nick2.docx%23_Toc354178730http://c/Users/Nick/Downloads/Nick2.docx%23_Toc354178730


19/19

Page 3

Documents

Comp 4905 Honors Project - Multi-Screen Online Multiplayer Game for an Android Device