Docstoc
EXCLUSIVE OFFER FOR DOCSTOC USERS
Try the all-new QuickBooks Online for FREE.  No credit card required.

Pervasive Treasure Hunt

Document Sample
Pervasive Treasure Hunt Powered By Docstoc
					                                                                    2006:007 HIP



BACHELOR'S THESIS


Pervasive Treasure Hunt




              Daniel Gjörwell
             Simon Johansson




             Luleå University of Technology

             BSc Programmes in Engineering

                      Skellefteå Campus


    2006:007 HIP - ISSN: 1404-5494 - ISRN: LTU-HIP-EX--06/007--SE
Foreword
The cell phone market has exploded during the last five years with a billion users
worldwide. As the market grows, so does the demand for games for these mobile
platforms. As of today, most games have not utilized the concepts that are usually
associated with mobile systems, namely the ability to play at any time, and anywhere in
the world. Pervasive Treasure Hunt is an attempt to change this.

The prototype game produced and this thesis is the culmination of the studies performed by us
(Daniel and Simon) at the Computer Gaming Studies program. We would like to take the
opportunity to thank all of those who have helped us during our three years as students at Luleå
University of Technology, Institution of Skellefteå and also to give a very special thanks to all the
teachers without whom this degree wouldn’t have become a reality.

Daniel Gjörwell and Simon Johansson
Abstract
Our work has been centered on creating a game that would be playable at anytime and
anywhere with the players being the ones that drives the game forward. The pervasive
aspects of the game would then become a source for study by the customer.

This paper will first offer some information about the nature of pervasive games and how
they can be used to enlarge the usability of mobile game platforms. We will then describe
the finished product and a few ideas that can be incorporated into the game in order to
further enhance the gaming experience. We will then have a short discussion of our results
and experiences while developing the game.
Table of Contents
Foreword
Abstract

Table of Contents .................................................................................................................... 1
1    Introduction.....................................................................................................................2
  1.1    Placement independence .........................................................................................2
  1.2    Playtime Independence............................................................................................2
  1.3    Player driven gameplay ............................................................................................2
  1.4    Combining the aspects .............................................................................................3
  1.5    Purpose of this thesis ...............................................................................................3
  1.6    The future of Pervasive Games ................................................................................3
2 Pervasive Treasure Hunt – Introduction ........................................................................4
  2.1    Game concepts..........................................................................................................4
  2.2    System Requirements .............................................................................................. 5
  2.3    PTH and Pervasive Games .......................................................................................6
3 System Design.................................................................................................................. 7
  3.1    System Architecture ................................................................................................. 7
  3.2    Server........................................................................................................................ 7
  3.3    Client........................................................................................................................11
  3.4    Database ................................................................................................................. 14
4 Communications............................................................................................................ 15
  4.1    Messaging ............................................................................................................... 15
  4.2    GPS to Client .......................................................................................................... 17
  4.3    Client to Server ....................................................................................................... 17
  4.4    Server to Client ....................................................................................................... 18
5 Future enhancements .................................................................................................... 18
  5.1    Items ....................................................................................................................... 18
  5.2    Upgrades................................................................................................................. 18
  5.3    Internet community ............................................................................................... 19
6 Discussion ...................................................................................................................... 19
7 Conclusion ..................................................................................................................... 19
8 References...................................................................................................................... 19




                                                                    1
1     Introduction
The field of study known as Pervasive Games is a fairly new one. The reason for this is
mainly due to a lack of required hardware. It is only in the last few years that platforms
with sufficient properties have arrived on the market. But we are transgressing, as the first
thing to discuss is the nature of pervasive games and how they can be incorporated into
the current gaming community.

Pervasive Games are associated with three dominating properties: Placement
independence, Playtime Independence and Player driven game play. We will in this
introduction give you, the reader a sense of each of these properties.

1.1    Position independence
The first cornerstone of a pervasive game is the concept of position independence,
meaning that the player of the game should be able to access the game independently of
his own location in the physical (or “real”) world.

Making a game independent of user position has been a factor in the game industry ever
since the release of the Game&Watch systems from Nintendo but has only recently been
more thoroughly explored with game platforms like the Nokia N-gage and the Sony PSP
that has just been released. These two platforms utilize several forms of communications
to achieve platform independence, most notable the more direct form of platform to
platform using Bluetooth and the indirect form using GPRS.

1.2 Playtime Independence
The ability to play a game at any time during the day is another important aspect of
pervasive games. Games that utilize this concept are almost always addressed on mobile
platforms due to the placement independence seen in most games. Therefore, one might
argue that these two abilities, the placement and playtime independence are tightly
coupled on current mobile platforms.

1.3 Player driven gameplay
The third aspect of pervasive games is probably the least
explored in the market today. It is a concept based on that the
player drives the game forward by manipulating the game
environment and potentially other players (in a multiplayer-
environment). This concept has been very strong in recent
                                                                    Star Wars Galaxies™
years, especially on the PC where Massive Multiplayer Online
(MMO) games have become extremely popular. Games such as
Star Wars Galaxies – An Empire Divided by LucasArts Ltd.
and World of Warcraft by Blizzard Entertainment, have
thousands of players every month.


                                              2                     World of Warcraft™
In player driven games the idea is that the player herself creates the content (both in terms
of game objects and game experiences). By doing so, the player will get a stronger
relationship with the game as she can actually see the effect of her actions. This bond
between the player and her game session will be a strong incentive to continuous playing
of the game.

1.4 Combining the aspects
Currently, only a few games have attempted to combine the three aspects into a true
pervasive game. But as mobile platforms become increasingly powerful and common, the
market for pervasive games will probably grow by leaps and bounds.

1.5   Purpose of this thesis
The purpose of the work performed was to create a simple yet fully functional prototype of
a pervasive game. It was requested by Kalle Jegers at the Umeå University in order to
provide him with a base for conducting computer-human interface studies and
evaluations.

1.6 The future of Pervasive Games
Currently, Pervasive games exist mainly within the research community. But efforts to
take the game style into the commercial world have been made.




                                              3
2 Pervasive Treasure Hunt – Introduction
The game that we are producing is called Pervasive Treasure Hunt (PTH). It is a small
game that is meant to be played on a Symbian® OS SmartPhone using a GPS receiver and
relying on Bluetooth and GPRS for communication.

The game is about locating and placing virtual “treasures” in the physical world using your
cell phone. By placing and picking up treasures, the player gains ranking points (RP) that
are then used to determine a global ranking list of all players. The player that holds the
first position on the ranking list (has most points) is the “Perfect Treasure Hunter”.

2.1 Game concept
As already stated, the game is about placing and picking up virtual treasures. The more
treasures you pick up the more points will you receive. But there is more to it than that
actually. As you play the game you earn yourself placement points (PP) that you can use to
actually place treasures of your own. These treasures works like a double edged sword as
they can both benefit and hurt your chances of becoming the “Perfect Treasure Hunter”.

So how do you go about playing the game? Well, let us start by examining the concept of a
treasure and the way it ties in with the points system.

2.1.1 Treasure
A treasure is not a real object but exists only in the game. It is associated with a value and
a “placer” (the one that actually put the object into the game in the first place). The value is
the number of ranking points that a person will receive when the object is picked up.

The longer a treasure exists in the game world, the more of its original value will be lost to
an eventual “picker” (the player that picks up the object) and more of it instead allocated
to the placer. Thus, a player can benefit from both placing and picking up objects.

If a treasure exists in the game for so long that all points would be allocated to the placer
and none to the picker, the treasure is in fact lost to both players along with all points.
The trick is therefore to hide a treasure well enough so that is isn’t found immediately but
still easy enough to be found before the time limit expires.

2.1.2 Ranking points
The ranking list is entirely based upon how many ranking points that a player possess.
Ranking points has no further use than to indicate who is “winning” the game.

2.1.3 Placement points
In order to place treasure of her own, the player must have placement points (PP). These
placement points are the foundation for the value of the treasure that is placed.




                                                4
A player earns placement points whenever he picks up treasures and the new points will be
put in a stockpile containing previously earned placement points. As a treasure is placed, a
random number of placement points will be subtracted from the player’s PP stack. This
number will become the value of the placed treasure. Please note that it is not possible to
place treasure if you have no PP.

It is also very dangerous stockpiling PP. Each update the server makes, it randomizes
among all registered users and picks one. That selected user will have as many RP
removed as he has PP in his stockpile. This has been added to the game design in order to
prevent all players from just stockpiling PP and thus never place any treasures themselves.

2.1.4 Locating treasures
The main task in PTH is to locate and pick up treasures. To accomplish this, the game
supplies the user with the ability to scan her surroundings for objects. These objects can be
treasures that can be picked up, treasures placed by the player herself, messages or other
players.

By submitting the player’s location in the real world to the game server (see 3.1) the game
will be able to display the objects in relation to the user’s position.

2.1.5 Picking up treasures
When a pick-able treasure has been located, the next task for the player is to position
herself as close to that treasure as possible. As the player gets within a certain range from
the treasure, it will be picked up upon the next scan that the player does. The points will
then be rewarded to the placer and the picker as mentioned in section 2.1.1.

2.1.6 Placing treasures
A player may place any number of treasures as long as she has enough PP to do so. But as
treasures need a lot of PP to become valuable, the player’s may find that having a few
valuable treasures may be better than a lot of cheap ones.

As the game is primarily player driven, the placing of treasures is up to the player’s
themselves. However, in case of a shortage of treasures in the game, the game itself may
add treasures into the game to keep up the hunt.

2.1.7 “Winning” the game
PTH is an open-ended game meaning that is has no real end. Instead it is a continuous
struggle for the players to reach the top notch position on the ranking list.

2.1.8 “Losing” the game
PTH cannot be lost. A player may play the game forever if he so desires.

2.2 System Requirements
The following requirements must be met in order to play Pervasive Treasure Hunt:



                                               5
   •   A Symbian OS operated SmartPhone (preferably the Sony Ericsson P800 or P900)
       with Bluetooth and GPRS support.
   •   A GPS receiver with Bluetooth support.
   •   A valid GPRS account with a service provider.
   •   Being able to connect to a server running the PTH server program.

2.3 PTH and Pervasive Games
2.3.1 Initial analysis of the game concepts
As we began the analysis of the game concepts, several things became clear. First, we
wanted the concepts of PTH to be simple to implement but also easy to modify at a later
date.
We also needed it to conform to the pervasive concepts. We spent the first two weeks
examining the concepts and determining how we should plan the project in order to
successfully achieve all the functionality that we planned. In the end, only minor changes
to the game concept was needed which was a nice surprise for us as it is not very often
your game design is suitable right from the beginning.

2.3.2 Conformity to pervasive concepts
PTH conforms surprisingly well to the pervasive concepts described in section 1. As we
analyzed the game concept and made the design of the game, we were constantly trying to
ensure that all the principles of a pervasive game would be included in one form or the
other. Our efforts in this early stage of development enabled us to improve the concept of
PTH and make it more closely follow the pervasive concepts.

PTH has the following pervasive properties:
  • It is a multiplayer game in that any number of players can play the game
     simultaneously.
  • It is placement independent in that the player can log on to the server from
     anywhere within the game area (the game area is defined on the server, in the form
     of a rectangular area in which players may perform actions).
  • It is time independent in that the player may log on and play at any time.
  • It integrates the physical world with the virtual world as you move around in the
     physical to find virtual treasures.

2.3.3 Disparities between pervasive concepts and PTH
Even though PTH tries to adhere to all the principles of a pervasive game, several
limitations due to the time constrains were introduced.

Firstly, PTH has no direct inter-client communications, something that is by most
standards a basic requirement of a true multiplayer game.
Secondly, PTH has a very limited customer range, since it has quite specific software and
hardware requirements. As we designed the game, we did acknowledge this as a problem
but had no possibility to improve on that issue.



                                             6
3 System Design
The original concept of PTH was first expressed by Simon Johansson in the autumn of
2004. After that, the design has seen quite a few modifications and additions even though
the basic game concepts remain mostly intact.

3.1 System Architecture
It was clear from the start that in order to create a massive multiplayer game the system
would have to be based on server-client architecture with the clients being the actual
phones used by the players.
The server would be a PC machine with access to an IP-address to which the client would
connect using GPRS.




                                   System Architecture



3.2 Server
The server is the manager of all the clients that have connected to it and it responds to the
clients’ actions. It focus is on stability and is as such guaranteed not to “go down” in case of
invalid requests by a client.

The server also handles the changes to and updating of the database containing all the
game data.




                                                7
3.2.1 Analysis
We began this project without guidelines on how the customer wanted the product to
actually function in the final version. We knew that we needed to have massive multiplayer
support but we were given no instructions on how to achieve this. We decided to use a PC
based server as the centre of the application. This meant that the server must have several
features like being able to respond to many requests from clients almost immediately,
being able to organize data (which we did by using a database as storage unit) and also to
be very robust so that it could handle unexpected situations.

With these premises we set out to analyze just how to achieve these features. The message
system had to be simple so that we could treat all messages in the same way. This meant
using message codes and fixed data lengths. In regards to the use of a database we choose
Microsoft Jet 4.0 (Access) due to that we both had some knowledge of it and that Delphi
had excellent support for accessing such a system. Regarding the robustness we believed
that the most problems would come from database errors (and it soon proved to be like
that), but as database errors in Delphi is not critical we realized that the server would not
have any major issues when it came to reliability.

All in all, the analysis phase of the server was quite short and straightforward, which
enabled us to move on to the design phase almost directly.

3.2.2 Design
The design of the Server was influenced heavily by the way that Delphi manages its source
code. Without going into detail, the Server suffers from being somewhat bloated both in
size and functionality.

In order for the Server to be stable, we utilized many of the components that are provided
by the Delphi SDK. Especially the GUI relies heavily on those provided components but
also the communications and the database access.

3.2.2.1.      Class design
The classes used in the Server where developed partly in the design phase and partly in the
implementation phase. This approach was necessary as we had very little experience in
how to build an application of this type. Therefore, the most basic functionality was
outlined in the design phase and then the class was finalized in the implementation phase.

Here follows a schematic view of the final server design (purely GUI related functionality
has been excluded for clarity).




                                               8
          pthServer
-_clients : TList                                             TPTHClient
-GameArea : record
                                                      #_user : TPTHUser
-Options : record
                                                      #_login : string
+ShutDown()                                           #_password : string
+StartUp()                                            #_socket
+Log()                                                #_loggedOn : bool
+SaveLog()
                                                      +Create()
+Connect()                                     *      +Destroy()
+Disconnect()
+FindClient()
+FindClient()                1
+Clients()                                                    TPTHUser
+KickClient()                                         #_login : string
+AddUser()                                            #_pwd : string
+RemoveUser()                                  *      #_pp : int
+FindUser()                                           #_rp : int
+DeleteUser()                                         #_ranking : int
+AttemptLogin()                                       +GetSocket()
+ProcessMessage()                                     +SetSocket()
+SendMessage()                                        +Create()
+HandleError()                                        +Destroy()
+HandleRegistration()
+HandleScan()                1
+HandleTreasurePlacement()
+HandleRankingRequest()
+UpdateServerTime()
+SaveDB()
+PickupTreasure()
+RandomizeTreasure()
+AddTreasure()
+AddMessage()
+CountActiveTreasures()
+GetNearbyTreasures()
+GetNearbyMessages()         1
+CheckForTreasurePickup()
+GetNearbyPlayers()
+UpdateTreasures()
+RandomizeMessage()                                       *
+CountActiveMessages()
+GetNearbyMessages()
+CheckForMessagePickup()                             TPTHObjectTypes
+ReadIni()
                                                    +placedBy : string
+AttemptLogoff()
                                                    +placedWhen : string
                                                    +active : bool
                                                    +pos : record
                                                    +id : int




                                 TPTHTreasure
                                                                          TPTHMessage
                                 +value : int
                                                                         +message : string
                                 +remaining : int




                                    9
As can be seen, the Server class is quite large, mainly because it is responsible for handling
all the requests that the clients are making. We had planned to divide the class into several
smaller classes but due to time restraints this proved too hard.

3.2.2.1.1.    TPTHServer Class
The TPTHServer class is the main class of the entire application. It serves as the interface
with which the clients communicate their messages. The TPTHServer class also is
responsible for answering the messages and to communicate and update the database.

In its heart is the list of connected clients (maintained as a list of TPTHClients). We will
return to this list shortly.
As we designed the server class, we opted for the use of Delphi’s RTTI capabilities. That is,
we determine the server state by examining the class type of the messages we receive and
send. This makes the server take up a little more memory but simplifies a lot of the code
base.

3.2.2.1.2. TPTHClient Class
The client class holds basic information about the connected client. This was one of the
classes that remained virtually unchanged throughout the project even though some
things like the login and password was later moved to the TPTHUser class.

The client class is used in the server’s list of connected clients. We use one entry in the list
for each client that has connected and we remove that client only if it disconnects (or is
kicked by the server). Therefore, each TPTHClient object is able to decide if a message
received by the server was sent by that object’s associated client. We need this information
in order to properly update the Database as well as knowing where to send replies.

3.2.2.1.3. TPTHUser Class
The TPTHUser class was added because we needed something to hold user data that was
not associated with the client connection. For instance, as we retrieve data from the
Database, we need to store it somehow (as it is multiple entries and we don’t want to
access the Database more than necessary as it is quite slow). Also, we need to attach a user
to the TPTHClient class once a client has logged on to the game by providing a valid login
name and password.

The TPTHUser class proved very handy and efficient and was used frequently throughout
the message system.

3.2.2.1.4. TPTHObjectType Class and subclasses
The TPTHObjectType class and its subclasses were added quite late in the project even if
their inclusion had been discussed in the analysis phase. The reason for this was that we
thought we could manage it just by using the data from the Database. But as with the
TPTHUser class, we realized that it became to unwieldy and not very modular if we didn’t
include some help classes. So we created the TPTHObjectType base class and their
subclasses, the TPTHTreasure class and the TPTHMessage class.



                                                10
The main function for these classes is simply to store the values retrieved from the
database (e.g the values of a treasure). These are later used to modify and update the
Database as well as sending information back to the clients.

3.2.3 Implementation methods and techniques
The server has been written entirely in Borland™ Delphi 7.0 using the Object Pascal
programming language. The choice of Object Pascal was deliberate as it provided the team
with a good set of components that were ready to be used immediately.

3.2.4 Known issues
The following issues are not addressed in this version of the server:
   1. The game area definitions in the ini-file must be stated in Swedish notation when it
       comes to the decimal point (use comma instead of point).
   2. The game area definitions in the server tab window must be stated in Swedish
       notation when it comes to the decimal point (use comma instead of point).
   3. The deactivating and activating of treasures from within the server is broken. We
       have found no explanation to why. If you need to reset a treasure you must use
       Microsoft Access.
   4. We would like to have only the currently logged on clients displayed in the User tab
       but currently this does not work. Instead, you can see the status of the user (logged
       on or not) in a checkbox.

3.3 Client
The client is the link between the player and the game data residing on the server. The
client has a shell with an interface that the player can use to perform the actions provided
in the game (such as placing a treasure). It also controls sound effects and graphics.

But at the core, it is still the communications link to the server that is the most important.

3.3.1 Analysis
With past experiences with both Symbian OS (Series 60) and slight experience with the
UIQ-layer over Symbian 7.1 on Simon’s side, this project seemed like a reasonable one.
Something that we personally had no experience with on handheld devices however was
the Communications bit of this project. With our almost non-existent knowledge on GRPS
(General Radio Packet Service) we thought that this might actually be quite a hassle.
Luckily for us it was way simpler that we had expected. GPRS is TCP/IP –based, and that
we had some experience with. Since we had dealt with the logic and graphics part of the
Symbian OS before, and had learned that IP- communication isn’t that difficult, we felt
confident enough to move on to the design phase.

3.3.2 Design
Most of the core classes of the client were designed before the implementation phase. We
decided that we wanted a wrapper for our game CGame, a CModel and CView class that
separates data and logic from the Visual parts of the application. A recycled graphics
engine from a previous project would power the CView class. The CModel class will handle


                                               11
everything else, including TCP-communication, all logic that has nothing to do with
visuals, Bluetooth communication etc.

3.3.2.1.       Class Design
Here is a UML Diagram of the most important parts of the Client. To show all classes used
in the client would be unnecessary and would not give any further insight of the
development process.




3.3.2.1.1.    CGame Class
The CGame class is basically a wrapper for the whole game. All communication from the
phone UI etc. travels through the CGame class and then further into the game. The CGame
class also houses the 2 biggest classes of the application; The CModel and CView classes.



                                             12
3.3.2.1.2. CView Class
The CView class handles most of the graphics in the game. An exception is the 2 Textboxes
on the titlescreen which are standard UI components and they are being handled by the
AppView class. Also some dialogues etc. are exceptions as well since the UI takes care of
those automatically.
The core of the CView class is the graphics engine (CGengine), which is basically just a
wrapper for the CDirectScreenAccess class. Direct Screen Access (DSA) is primarily used
by games who wish to use the whole screen of the device or applications that wish to get a
higher framerate. The CGengine class was not written from scratch for this project, but
rather salvaged from another Symbian Project that Simon has completed in the past.
(Although some improvements were done)
The CView class holds all the Bitmaps that are used within the game (CFbsBitmap). These
are being rendered by the engine.
The Draw -function of CView is to a large part a simple state-machine. We use an
enumerator to determine what state we are in, and the CView –class renders the
appropriate images for that state.

3.3.2.1.3. CModel Class
This is the largest and most important class in the game. This class holds functions for all
the actions you can make in the game, like Scanning and Accessing the Ranking Screen for
instance. This class also holds the TGameState variable that tells us what state the game is
in at a given time. The CModel class also houses the TCPManager class, which handles all
TCP/IP communication. A large part of the CModel class is the TCPReceiveCallback –
function, which is the function that is called by the TCPManager whenever a message is
received from the Server. The CModel class checks what type of message it is and acts
accordingly. This is done through a state machine.

3.3.2.1.4. TCPManager Class
The TCPManager is a wrapper class for the underlying TCPSender and TCPReceiver
classes. There’s not much code in this class, mostly calls to those two classes and a
callback-function to the owner class, in this case our CModel class.

3.3.2.1.5. TCPSender Class
As the name implies, the sender handles all outgoing TCP communication from the client.
It also handles the DNS- resolving of the server hostname and establishment of the
connection. This class uses TCP/IP sockets for communication, as does the receiver. The
socket functions Connect and Send are both asynchronous calls, so the TCPSender class is
derived from an Active Object. The responses from the CActiveScheduler are handled in a
simple state-machine.

3.3.2.1.6. TCPReceiver Class
This class handles all the incoming TCP – traffic. Any traffic will trigger a callback function
to be called in the Observer of this class. The Observer is the TCPMangager, which will
pass the callback on to the CModel class. The CModel -class will then extract the




                                               13
information from the Receive buffer, determine what kind of Message we received, and act
accordingly, as mentioned earlier.

3.3.2.1.7. CBlueGPSClientSession Class
This class is the interface to the BlueGPSServer DLL that handles communication with the
Bluetooth GPS receiver. An instance of this class resides in the UI class of the application,
where a timer is used to fetch GPS –Information once every second. The timer simply calls
GetGPSInfo once a connection has been established to do this. The discovery and
connection of the Bluetooth unit is made through a standardized Bluetooth Discovery –
dialog.

3.3.3 Implementation methods and techniques
The client has been written in C++ using Codewarrior for Symbian IDE. The choice of
using the C++ Symbian API instead of Java (J2ME ) is due to past experience using the
Symbian API.

3.3.4 Known issues
The following issues are not addressed in this version of the client:
   1. If a login attempt failed and the user then is inactive for more than five minutes, the
       game must be restarted due to socket failure.
   2. If the server closes the connection (kicks the client) the user must restart the game
       in order to reinitiate the socket.
   3. Sometimes, during application shutdown, the GPS session may shut down in an
       improper manner. It will generate an error message to the user but is harmless.

3.4 Database
In order to keep track of all the happenings in the game, we have decided to use a database
for storing, retrieving and changing data. This decision came quite natural as databases
are the logical choice when you wish to have both data security and data consistency. Also,
it provides us with a lot of tools (such as the Delphi ADO API and MS Access) for easy
modification of the data.

The database holds two tables, namely UserData and TreasureData. Each table consists of
information about the respective dataset (Users/Players, Treasures).

Currently, the database is stored in the Microsoft Access-format (MS Jet 4.0).
Only the server is allowed to change the data in the database. If for some reason, the server
is unable to correct a problem within the database, the administrator may access the
database using the appropriate software (e.g Microsoft Access).

3.4.1 User table
The user table is the storage location for all information regarding the different users. In
the Database it goes under the name of UserData. For every user, the database stores one
entry containing data about the user’s login name, password and current game status
(ranking points and so on).


                                              14
3.4.2 Treasure table
The TreasureData table contains information about all the treasures that have been placed
in the game world. It stores information about where the treasure is located, who placed it
and how much it is worth.


4 Communications
A successful communication protocol between the server and the client is the foundation
for a successful implementation of a massive multiplayer game such as PTH. It is essential
that data can be sent both ways without loss, and that both the server and the client knows
how to interpret the data and react to it.

In order to achieve this, we choose to implement a TCP/IP based system that relied on
secure messaging to perform actions and reactions. Due to the constraints offered both by
available bandwidth on the client side as well as the costs of data transfer to cell phones,
we opted to send as little information as possible at all times.

We will in the following subsections describe the protocols used in the communication in
PTH.

4.1 Messaging
The foundation of the communication system is the Message. A Message is a data
structure that contains a number of elements capable of being sent using GPRS.

There are three main sets of messages; Request, Response and Error.




                                              15
4.1.1 Request messages
First we have the requests messages, which are primarily used by the client to place
actions that are sent to the server for processing. The requests can be for a scan of the
surroundings, the placement of a treasure or simply to log in the player so that she can
begin to play the game.

4.1.2 Response messages
The other set of message type is the response messages. These are sent by the receiver of a
request (usually the server) back to the sender. The response message tells the sender if
the action requested was processed and may also provide additional information
depending on the type of response.

The reason for having response message is due the use of asynchronous calls on both the
client and server side. On a mobile phone the system resources are particularly scarce,
and the battery must be able to sustain the phone for many hours. Therefore, the system
must be build so that as little power is used in the applications as possible.


                                              16
In the Symbian OS this is accomplished using Active Objects (AO). These “objects” are
code sections that are only run when of an asynchronous call to a service provider (such as
a GPRS provider) completes. The concept is quite complicated but very efficient. The use
of AO is the reason that phone batteries can last for a week instead of only a few hours.
This design has a drawback though, as it calls for different game states to be entered
whenever a request has been sent. Then, in order to leave a state, we need to receive a
response message whenever a request has been processed by the server. This increases the
data sending overhead by roughly 5%.

4.1.3 Error messages
The last set of messages is the error message type. Error messages can be sent both from
the client and the server, although it is mostly seen as a special type of response on an
invalid client request.
The ability to handle invalid request in this way enabled us to better log and then analyze
problems that arose during the development. In the finished product the object is to have
the error messages reduced to an absolute minimum.

4.2 GPS to Client
Our GPS Bluetooth communication has its foundation in an “official” code-example from
the Sony Ericsson website [4]. This GPS-Server however needed to be modified slightly
since it didn’t work at all to begin with. The GPS-Server program fetches new GPS-Info
from the receiver every second or so.

4.2.1 Conversion Issues

4.3 Client to Server
The client relies on GPRS with the TCP/IP protocol for its communications with the
server. As previously mentioned, the client sends messages to the server and waits
asynchronously for a reply.

In order to locate the server, the clients have been supplied with a DNS address which they
resolve during run-time to get the server location. The DNS address is: pth.servegame.com




                                              17
                   Client-Server communications using GPRS


4.4 Server to Client
The server relies on an ordinary Internet connection and uses the TCP/IP protocol for
communicating with the clients. The server IP address should be coupled to the DNS of
www.pth.servegame.com in order for the clients to be able to connect to it.

The server sends packages synchronously to the client(s). This could mean that the server
gets unresponsive during heavy traffic. In the normal case though, this will not be
noticeable.

5 Future enhancements
During the development of PTH several ideas was rejected due to the time constraints of
the project. Here we have presented a few of those ideas as possible future enhancements.

5.1   Items
A treasure currently consists of only RP and PP but a future enhancement could be that a
treasure is a specific item (e.g a monkey or a banana) and that each item gives certain
bonuses. Perhaps collections (e.g having all types of fruits) could provide a player with
special powers. It is also plausible that treasures could become more interactive (like
moving around in the game world).

5.2 Upgrades
Throughout the project we have been discussing the addition of “upgrades”, that is, special
bonuses that could be granted or bought by players using their RP. An upgrade could be an
enlarged radar sweep radius or a faster scan sweep.




                                             18
5.3 Internet community
A possible enhancement is the adding of community support on an internet site. Such a
site could contain a forum and a display of the current standings/ranking list. Experience
has shown that an active Internet community prolongs the life cycle of a game
significantly.

6 Discussion
We had some problems with this project, as all projects do. One of the most annoying ones
was the emulator for Symbian, called EPOC32. The emulator on its own is really slow in
our opinion. This we already knew. What we didn’t know is that the emulator didn’t
support GPRS-communications. In order to achieve this, we had to find a Winsock -Plug-
In [1], which actually was released by Symbian.com, but was untested and unsupported.
This just isn’t very professional, is it? Well, that’s not too bad if the plug-in had delivered
what is should have; Stable TCP/IP –communication. This was not the case. Using the
slow emulator, which takes about a good 40 seconds before you have booted the device
and then launched you program, we had many problems with debugging the
communications bit. Most of the time, any attempt to communicate would just fail
completely. Most of the time would in our case, be about 4 out of 5 times. Due to this, the
client communication proved to be somewhat challenging and even frustrating at times,
but overall I think the difficulty level was acceptable.
I must say that I don’t think this project would have succeeded, not to this degree anyways,
if it had not been for the people on the forums of NewLC [3], a Symbian OS C++
developer portal.

7    Conclusion
The end result of the project was a successfully developed prototype for a Mobile
Massively Multiplayer Online Game with pervasive properties. Many bits and pieces came
together remarkably well in the last weeks of the project. The product is certainly playable,
and works pretty well so far. There has yet to be a large scale test though.

8 References
[1] Symbian.com – UIQ Winsock Plug-In
http://www.symbian.com/developer/downloads/tools.html#winsock

[2] Symbian OS v7.0 UIQ 2.1 SDK
http://developer.sonyericsson.com/site/global/docstools/symbian/p_symbian.jsp

[3] NewLC – A Symbian OS C++ developer portal
http://www.newlc.com/




                                               19
[4] BlueGPS - a Bluetooth GPS Sample Application
http://developer.sonyericsson.com/site/global/techsupport/tipstrickscode/symbian/p_bl
uegps.jsp




                                          20

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:7
posted:5/27/2012
language:
pages:23