Pervasive Treasure Hunt

(1)

2006:007 HIP

B A C H E L O R ' S T H E S I S

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

(2)

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

(3)

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.

(4)

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.

Star Wars Galaxies™

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

World of Warcraft™

2

(6)

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.

(7)

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

(8)

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:

(9)

• 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

(10)

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.

(11)

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

(12)

+ShutDown() +StartUp() +Log() +SaveLog() +Connect() +Disconnect() +FindClient() +FindClient() +Clients() +KickClient() +AddUser() +RemoveUser() +FindUser() +DeleteUser() +AttemptLogin() +ProcessMessage() +SendMessage() +HandleError() +HandleRegistration() +HandleScan()

+HandleTreasurePlacement() +HandleRankingRequest() +UpdateServerTime() +SaveDB()

+PickupTreasure() +RandomizeTreasure() +AddTreasure() +AddMessage() +CountActiveTreasures() +GetNearbyTreasures() +GetNearbyMessages() +CheckForTreasurePickup() +GetNearbyPlayers() +UpdateTreasures() +RandomizeMessage() +CountActiveMessages() +GetNearbyMessages() +CheckForMessagePickup() +ReadIni()

+AttemptLogoff() -_clients : TList -GameArea : record -Options : record

pthServer

+Create() +Destroy()

#_user : TPTHUser

#_login : string

#_password : string

#_socket

#_loggedOn : bool TPTHClient

+GetSocket() +SetSocket() +Create() +Destroy()

#_login : string

#_pwd : string

#_pp : int

#_rp : int

#_ranking : int TPTHUser

+placedBy : string +placedWhen : string +active : bool +pos : record +id : int

TPTHObjectTypes

+value : int +remaining : int

TPTHTreasure

+message : string TPTHMessage 1

*

1

*

1

*

(13)

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

(14)

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

(15)

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

(16)

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

(17)

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

(18)

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.

(19)

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

(20)

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

(21)

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

(22)

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/

(23)

[4] BlueGPS - a Bluetooth GPS Sample Application

http://developer.sonyericsson.com/site/global/techsupport/tipstrickscode/symbian/p_bl uegps.jsp

Pervasive Treasure Hunt

B A C H E L O R ' S T H E S I S