Location-based gaming
– Be aware, everywhere! –
Wouter Wiegmans
Bachelor Thesis Telematics, University of Twente, Enschede, The Netherlands
Supervisors:
Dr. ir. Johan Koolwaaij (Telematica Instituut) Ir. Martin Wibbels (Telematica Instituut) Dr. ir. Aart van Halteren (Universiteit Twente)
Enschede, The Netherlands January, 2005 Wouter Wiegmans Location-based Gaming
- 2 -
Wouter Wiegmans Location-based Gaming
Abstract Context-awareness is the ability of computing devices or applications to detect and sense, interpret and respond to aspects of a user's local environment and the computing devices themselves. When the concept of context-awareness is applied to mobile gaming, the real and virtual world can dissolve in each other, and the gaming application can become aware of the physical location of the player to which it can respond.
Context-awareness adds a completely new dimension to mobile gaming; enhancing the overall mobile gaming experience. Therefore, context-aware services provide a great opportunity for improving existing, and developing new mobile games.
This thesis presents the results of the actual development of a location-based game, preceded by and funded on an intensive literature study in the area of location-based gaming.
- 3 -
Wouter Wiegmans Location-based Gaming
- 4 -
Wouter Wiegmans Location-based Gaming
Table of contents 1. Introduction...... 9 1.1. Motivation...... 9 1.2. Objectives...... 9 1.3. Approach...... 9 1.4. Structure...... 9
2. Context Awareness in mobile gaming ...... 11 2.1. What is context ...... 11 2.2. Context Awareness ...... 11 2.3. Contextual information: Location...... 12 2.4. Sensing the context: Location ...... 13 2.5. Mobile gaming...... 14 2.6. Location-based Gaming...... 14
3. WASP & Mobile Life...... 17 3.1. WASP...... 17 3.2. MobiLife...... 21
4. Current work ...... 24 4.1. Introduction ...... 24 4.2. Location-based Games...... 24 4.3. Comparison...... 28 4.4. Location-based platforms...... 29
5. Game Concept ...... 32 5.1. Requirements...... 32 5.2. The Game Concept ...... 32 5.3. Playing the Game...... 33 5.4. Locality ...... 34 5.5. Groups...... 35 5.6. The competition ...... 35 5.7. Future work ...... 36
6. The Game Architecture...... 38 6.1. Other Game Architectures ...... 38 6.2. The Pop Star Game Architecture ...... 39
7. Implementation...... 50 7.1. Building a game world on the real world...... 50 7.2. Building the actual game...... 53 7.3. Database structure ...... 56 7.4. The game running ...... 57
8. Evaluation ...... 62 8.1. Requirements...... 62 8.2. Functionality...... 62 8.3. Conclusion ...... 63
9. Conclusions & Future work ...... 64 9.1. Conclusions...... 64 9.2. Future work ...... 64
10. References ...... 67
- 5 -
Wouter Wiegmans Location-based Gaming
- 6 -
Wouter Wiegmans Location-based Gaming
Preface One could say that this thesis presents the results of my bachelor assignment on location-based gaming. Although this is true, as you will find out while reading it, I would say not all the results are included in this thesis. Of course, all the technical details are covered, but only few is written about the personal results of this assignment.
In my opinion, being a student means the personal results of an assignment are as important as the technical results. I would like to thank the Telematica Instituut for giving me the opportunity to do my bachelor assignment at the Telematica Instituut and thereby allowing me to learn, not only within the area of my study Telematics, but also about myself as a person, and about the daily life within a research-focused environment as the Telematica Instituut.
I would especially like to thank my supervisors; Johan Koolwaaij, Martin Wibbels and Aart van Halteren for their support during the assignment. I enjoyed our (two)weekly meetings and appreciated your remarks and suggestions. Moreover, I would like to thank all the employees at the Telematica Instituut for contributing to an open, friendly and cooperative working environment.
Looking back, I am certain that doing my bachelor assignment at the Telematica Instituut was the right decision. I hope you will feel the same.
Enschede, 22nd of January 2005.
Wouter Wiegmans
- 7 -
Wouter Wiegmans Location-based Gaming
- 8 -
Wouter Wiegmans Location-based Gaming
1. Introduction Context awareness is the ability of computing devices or applications to detect and sense, interpret and respond to aspects of a user's local environment and the computing devices themselves. When this concept is applied to mobile gaming, aspects of the user’s environment can be brought into the game; the gaming application becomes aware of the physical location of the player to which it can respond. When alliances between players can be formed, players will have access to different levels of context information, e.g. opponents can only see the user’s location when they are within range, whereas allies have access to his location from anywhere and also to his status, mood, tactics et cetera.
This chapter presents an introduction into the assignment on location-based gaming, which led to this thesis. The motivation, objectives, research questions and approach are discussed below.
1.1. Motivation A lot of research on context-aware services is available and currently in progress. Every so often, research should be translated in practice. Moreover applying technologies in practice often provides new insights for future research.
The Univerisity of Twente and the Telematica Instituut are both active in the research on context- aware services. Using the results of the WASP project, lining up to both the European MobiLife project and the Freeband Awareness project (which continues with the WASP results), this assignment has performed the function of applying research into practice and providing new, interesting insights for future research.
1.2. Objectives The focus of the assignment will be on context providing (location), context exchange and group aspects in a mobile gaming setting. The goal is to design a mobile gaming application that uses the player’s physical location and alliances to enhance the gaming experience. The application will use appropriate generic components from the WASP platform whenever possible.
1.3. Approach A straightforward approach is taken in this assignment. The actual implementation of the location- based game is preceded by a literature study on location-based gaming and the design and development of a game concept. In general the approach is as follows: 1. Literature study (2 weeks) 2. Design of the gaming concept and functionality (2 weeks) 3. Choice of appropriate devices, location providers, et cetera (1 week) 4. Choice and set-up of a development environment for mobile applications (1 week) 5. Build a demonstrator version to be tested by the target group (2,5 months) 6. Report and presentation (2 weeks)
1.4. Structure The remainder of this thesis is structured as follows:
Literature Study Chapter 2 presents the concept of context-awareness and applies it to mobile gaming. Chapter 3 presents related Telematica Ínstituut and University of Twente projects. Chapter 4 discusses location-based games currently (or in the past) available.
Gaming Concept Development Chapter 5 presents the concept of the location-based game developed for this assignment. Chapter 6 proposes an architecture for the implementation of the gaming concept.
- 9 -
Wouter Wiegmans Location-based Gaming
Implementation & Evaluation Chapter 7 discusses the implementation of the gaming concept. Chapter 8 evaluates the prototype against the concept.
Conclusions & Future work Chapter 9 presents the conclusions and future work possibilities based on the thesis.
- 10 -
Wouter Wiegmans Location-based Gaming
2. Context Awareness in mobile gaming This chapter presents the basic concepts of Context Awareness in mobile gaming. Before context-awareness can be applied to mobile gaming, a clear and shared understanding of the different concepts has to be established.
This chapter consists of three parts. The first four paragraphs present the concepts context and context-awareness. Section 2.5 presents the Mobile Gaming concept. In section 2.6 the different concepts are combined into the key concept in this report: Location-based gaming.
2.1. What is context Although a lot of research is done in the area of context-aware computing, there is very little consensus on the exact definition of context. Several different definitions have been put forward in literature. In this report a generic definition of the term context, developed by Dey and Abowd [1], will be used:
Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and application themselves.
This definition of context is the general definition of context that was used in context(-aware) research by the Telematica Instituut. It was used in the development of the WASP services platform [2] and is present in the state-of-the-art of context-aware services [3].
2.2. Context Awareness Context-aware computing deals with the ability of computer systems to be aware of the context to deliver improved services. This differs from traditional computer systems. These systems ignore contextual information. Their output is based only on the explicit input to the application (see Figure 2.1: Traditional applications, extracted from [3]).
Figure 2.1: Traditional applications
Context-aware computer systems not only base their output on explicit input, but also make use of knowledge of context (implicit input), gathered from the applications’ environment. This is represented graphically in Figure 2.2: Context-aware applications, extracted from [4].
- 11 -
Wouter Wiegmans Location-based Gaming
Figure 2.2: Context-aware applications
Context-aware computing can be divided into two categories: using context and adapting to context [3].
An example of the first category is an application that displays the distance of the car of the user to other objects. This function can for example be added to the board computer of a car. It does not adapt to the context, but uses the context to deliver relevant information to the user (for example when the user is parking or taking over another car on the highway) and thereby enhances the service delivered to the user of the board computer.
An example of the second category is an application that beeps when the distance of the car of the user to other objects becomes too small. Based on contextual knowledge the computer system informs the user when his car is bound to collide with other objects given the current speed. The service adapts itself to the context.
Both categories have to be covered by one definition, as both categories are aware of their context. Therefore a general definition of Dey and Abowd [1] is used:
A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task.
This definition is also used within the Telematica Instituut. It was for example used in the development of the WASP services platform [2] and was presented in the state-of-the-art of Context-aware services [3].
2.3. Contextual information: Location Although different definitions of context and context-awareness exist, there are some simple forms of contextual information that designers do agree upon [1]. One of them, location, is relevant in this research.
Location is the contextual factor that is currently used most in context-aware applications [3]. A key aspect in such context-aware applications is how the location information relates to the actions performed by these applications. For example, if someone is in New York, he is not interested in the weather forecast for Amsterdam and if someone is at work, he does not want to be disturbed by phone calls from friends, but as soon as he leaves work, he wants to be informed who called.
- 12 -
Wouter Wiegmans Location-based Gaming
Adding location information (implicit input) to an application creates a new class of services. Not only, it offers opportunities to improve current applications, it also allows new applications to be developed.
However, to improve current or develop new applications, one should look into the complexity of adding location information to applications. Different location formats and different types of location determination exist, all with their own strengths and weaknesses [3].
2.4. Sensing the context: Location Different formats for representing location exist [3]: ? Global: using latitude and longitude ? Referenced: using a point of reference (for example a central building) ? Named: using the name of a location (for example a street name)
One of the challenges lies in the interrelation between these formats. For example, if a user wants to know where he is, he does not want to know the latitude & longitude pair of his location (derived from his GPS handset), but he wants to know the name of the street he is in. The global format (latitude & longitude) should be converted to a named format (the street name).
Different types of location determination exist. Only positioning techniques that are widely available, for example using cell phones and GPS, are discussed.
Positioning techniques are based on determining the position of a mobile device of the user. These techniques rely on positioning technology in the mobile network, positioning technology in the handset or on a combination of both. Each technology has its characteristics including complexity, costs of implementation and accuracy of determination [3].
The most basic positioning technique in a mobile phone network is to use the current cell of the user. It relies mainly on the technology of the network. A network is able to identify the cell surrounding a base station in which the user is located. This technique can be further improved using timing or angle-of-signal techniques. Still, the accuracy is rather low, at most, in an optimal environment about 200m [3][12][13].
The second positioning technique in a mobile phone network is based on both the technology in the handset and technology in the network. E-OTD (Enhanced Observed Time Difference) is a technique that calculates the position of a mobile device using signals from three base stations. A LMU (Location Management Unit) should be available in the device to determine the location [3][12].
The third technique relies mainly on the technology in the handset. Assisted GPS (Global Positioning System) uses the signals from satellites together with the mobile phone network to determine the location. The exclusive use of GPS is possible too, although this requires better signals from positioning satellites and takes more time to position. The accuracy of these methods is about 5-30m [3][13]. Assisted GPS requires major investments from both the network operator and the user.
The three positioning techniques described are the most common ones in mobile networks. It was not the intention to give a complete overview of positioning techniques. Using a mobile network is not the only way for positioning users. Another class of positioning techniques is based on wireless LAN (or short range radio in general). Instead of looking at mobile network base stations and cell phones, this class of techniques uses wireless LAN access points and mobile devices with wireless LAN access (for example a laptop or PDA). As this class (and other classes) requires a network of access points that is not as widely available as the mobile phone network it is not discussed in this report.
- 13 -
Wouter Wiegmans Location-based Gaming
2.5. Mobile gaming In this report the following definition for mobile gaming will be used:
Playing computer games on a mobile device
The prospects for mobile gaming are good. Although some differences exist in the expected growth in revenues (and in the definition of mobile gaming used), all analysts notice the emerging mobile gaming market. A recent (October 2004) report by media research consultancy Screen Digest predicts that the global mobile gaming download market will be a big industry by the end of 2004 (€ 880m) increasing to € 5,25 billion in 2010 [5]. The Wireless Communications Winning and Losing in Mobile Games predicts worldwide revenues from mobile games of nearly 2 billion dollars in 2006 [7]. And according to a Yankee Group analysis the market for mobile gaming will be worth $1.2 billion by the year 2006 for US operators [6].
These prospects all predict a considerable growth of the mobile gaming industry. These predictions were based on different research results or initiatives. Motorola predicts for example that by 2005, wireless services will hold 32% of the entertainment market (from 8% in 2000) [8]. Furthermore, in 2001, Motorola, (former) Ericcson, Nokia and Siemens joined forces and combined their resources and knowledge on mobile gaming in the Mobile Games Interoperability Forum [9]. This forum, together with nearly 200 companies, joint forces in the Open Mobile Alliance [10]. The MGI Forum intended to create specifications to allow producers to produce and deploy mobile games over multiple platforms [9]. The OMA also pursues interoperability, but does not focus on only games. Finally, a survey by Nokia indicated that nearly 50% of the people asked like to play games when waiting [11].
2.6. Location-based Gaming Location-based gaming is the adding of the location aspect of context-awareness to mobile gaming. To sum up the relevant definitions of context, context-awarenes and mobile gaming:
Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and application themselves.
A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task.
Mobile Gaming is playing computer games on a mobile device
The following definition for Location-based gaming will be used in this report:
Using the location of the mobile device as an aspect in mobile gaming to enhance the mobile gaming experience.
This definition allows different kinds of location-based games. To be able to categorize the location-based games presented in chapter 4, the different kinds of games are addressed here.
Some location-based games are ubiquitous games. Ubiquitous games are games that are situated and played in a real environment of which the game play is augmented by computational services to enhance and leverage the overall gaming experience [14]. Not all location-based games are ubiquitous. Location-based gaming is therefore not the same as ubiquitous gaming.
Key in location-based gaming is the use of the location of the user as an aspect in the game.
Key in ubiquitous gaming is taking functionalities of ubiquitous computing and applying them to computer games [9].
- 14 -
Wouter Wiegmans Location-based Gaming
Some location-based games are pervasive games. Pervasive games are games that surround the player, 24 hours a day, everywhere he goes [43]. Not all location-based games are pervasive as some require fixed game arenas and fixed playing hours.
Some location-based games provide an augmented reality: a combination of both real world and virtual reality components, but again not all location-based games do.
Finally a division between games can be made on some technical aspects like the positioning technique used and the game arena (is the game available in a relatively small, pre-defined game arena, or in a complete city or even on a complete mobile network).
For examples of location-based games see chapter 4.
- 15 -
Wouter Wiegmans Location-based Gaming
- 16 -
Wouter Wiegmans Location-based Gaming
3. WASP & Mobile Life The assignment presented in this report is related to two research projects of the Telematica Instituut; WASP and MobiLife.
The WASP (Web Architectures for Services Platforms) project proposed a web services based framework to facilitate and speed-up the development of context-aware integrated mobile speech and data applications [16]. The WASP project is completed (duration August 2002 – April 2004). This project is described in section 3.1.
The strategic goal of the MobiLife Project is “to bring advances in mobile applications and services within the reach of users in their everyday life by innovating and deploying new applications and services based on the evolving capabilities of 3G systems and beyond” [17]. The MobiLife project recently was launched (duration September 2004 – December 2006) [18]. This project is described in section 3.2.
3.1. WASP The WASP project is cooperation between the Telematica Instituut, the University of Twente and Ericsson. It was completed in April 2004 and the results included the WASP services platform. In this assignment a location-based game will be developed. The WASP services platform could prove useful in building this context-aware mobile application. This project can verify the claim that the WASP services platform facilitates and speeds up the development of context-aware applications.
Section 3.1.1 introduces the WASP services platform. Section 3.1.2 describes the architecture of the WASP services platform. Section 3.1.3 presents an example of an applying WASP in real life. Section 3.1.4, finally, addresses the link between WASP and this research.
3.1.1. The WASP services platform The goal of the WASP project was to create a supporting platform for mobile context-aware applications [19]. This platform (or framework) had to be based on web services. A web service is a software application, whose interfaces are defined, described and discovered using XML based standards and that supports direct interactions with other software applications using XML based messages via internet-based protocols [21].
The WASP services platform was developed with the assumption in mind that the creation of usable and feasible mobile applications will largely depend on the availability of flexible service frameworks, in particular when context-awareness application are to be developed [20]. Foundation for this assumption can be found in literature, in The Anatomy of Context-Aware Application Harter states that a services framework is required to deliver value-added services on top of existing low-granular services and knowledge sources [22].
To speed up the service creation process the services framework had to support the whole service lifecycle including definition, implementation and deployment [20]. In the WASP services platform, different modular services are provided to developers. Some of those services offer functionality, other (context) information and knowledge. All to speed up of the creation of mobile applications. The WASP services platform also provides an easy way for providers of services to offer and manage their services. Users of services are provided with an easy way for searching, finding and purchasing services. Finally, the use of web services enables services to utilize the intelligence of the mobile network.
The WASP services framework is developed to be transparent, dynamic and platform- independent and is highly tailored towards convenience for developers [20]. Moreover, the WASP
- 17 -
Wouter Wiegmans Location-based Gaming
services framework also offers an application platform that dynamically connects the users with information and services that are relevant to him.
3.1.2. The WASP architecture The overall architecture of the WASP platform is shown in figure 3.1, extracted from [23].
Figure 3.1 – Overall overview of WASP architecture
In this architecture four main groups can be distinguished: Service requestors, Service providers, Context providers and the WASP platform. These four groups collaborate in the provisioning of context-aware services [23].
Three components can be distinguished in this architecture: third party services, the WASP platform and Context-aware applications.
Third party services Third party services are (web) services offered by parties other than the WASP platform. Different third party services are distinguished [23]:
- 18 -
Wouter Wiegmans Location-based Gaming
3G Network Services Mobile operators offer services on the mobile network that provide network access capabilities; for example user identification, charging, call setup, messaging et cetera. These services (network capabilities) are accessible through web services.
Business Services (offered by Service Providers) Business Services Providers offer content and services for applications build on the WASP platform. For example a hotel reservation service offers the content (information about hotels and their reservations) for a mobile application.
Context Services (offered by Context Providers) The context of a user is provided to the WASP platform by Context Providers. Furthermore, they can give a user’s information like a personal shopping list or personal schedule. Also, information that is not relevant to one user in particular (but to a group of users) can also be provided by these services. In some cases context information is provided by 3G Network Services. For example, the location of a user can be provided by the mobile operator, by means of a 3G Network Service, when the location of the cell phone of the user is used to determine the location of the user. The location providing services currently available in the WASP platform are: 1. Adding a GPS receiver to each mobile device; 2. Mobile network (operator) based location providing (using network cell identifier); 3. Simulating the location; 4. Mobile network based location providing without intervention of a network operator (see WASP and this assignment).
The WASP Platform The WASP platform consists of different components together forming the system environment for context-aware applications. These different components are [23][24]:
The request dispatcher The request dispatcher is responsible for forwarding requests from the user to the 3G network. This allows users to switch transparently between different network operators or use different messaging services.
The notification manager This component provides functionality for applications to subscribe to and receive notifications when the context of a particular user changes. For example if a user moves, his location will change. The notification manager will notify the application of this change in location. This allows the application to provide context-aware services.
The context manager The context manager is responsible for retrieving information about the user’s context by contacting appropriate context providers. Therefore it should aggregate the context or derive new context using domain specific rules (for example the speed of a user can be determined using distance and time interval and using this speed and the location one can derive if the user is walking on a street or driving through a street). The context manager is also responsible to update the notification manager on changes in the context.
The service registry This component functions as a repository containing information (service descriptions) about the services provided by the third party and context services. This enables searching for required and/or relevant services.
The matchmaker The matchmaker uses the services registry to discover the service that matches the request from an application. The results of such a discovery are forwarded to the context-aware application.
- 19 -
Wouter Wiegmans Location-based Gaming
The matchmaker forms, together with the service registry, the service discovery mechanism in the WASP platform.
The Context-aware Application The WASP platform offers a framework supporting the creation of mobile, context-aware applications. WASP supports the creation in the sense that the applications can be positioned on top of the WASP platform and make use of the capabilities of the platform [23].
Within the context-aware application, different components can be distinguished [23]:
The interaction manager The interaction manager functions as the bridge between the user and the application. The user interacts with the application using this interaction manager. Examples of these interactions are: service request, network switch request, call setup et cetera.
The service retrieval & personalization This component is responsible for forwarding discovery requests to (and receiving the result from) the platform (the matchmaker). Moreover, the service retrieval component is also responsible for applying a personalization step defined in the personalization component [25] (e.g. score/sort the results based on predefined and/or historical defined user interest).
3.1.3. WASP in practice The WASP services platform was completed in April 2004. Different applications have been developed using the WASP platform as a framework. One of the context-aware applications that is deployed on top of the WASP platform is “Tourist Compass” [24]. It was developed in the WASP project to experience using the WASP platform from both a developer and a user point of view, but also to research how users feel about applications that uses context information to enhance the provided service. The developers stated that context-awareness provides added value in certain cases, but they also warned that caution should be taken when developing context-aware applications, as people are unfamiliar with this (improved) level of intelligence in applications.
In the development of the WASP platform, several challenges were not explored by the design, including security and privacy, scalability and performance, and charging. This means that the WASP platform still needs to be completed to be used commercially, on a large scale and in public networks [2].
3.1.4. WASP and this assignment The WASP platform was developed by several parties, including the Telematica Instituut. This platform should facilitate the development of the location-based game. This will show if the WASP platform is capable of reaching its goals. And secondly, it could also point out some flaws in the WASP platform, thereby allowing improvement of the WASP platform.
Moreover, the WASP platform was recently extended with a positioning technique that retrieves the current network cell on the mobile device itself. Without any intervention of a mobile operator, the location of a mobile device can be determined. This mapping is made possible by actual, on- location, linking of network cell identifiers to coordinates of a GPS receiver. However, this positioning technique was never really used in practice. The location-based game will therefore contribute to the WASP platform by determining the usability of this positioning technique in its current state.
- 20 -
Wouter Wiegmans Location-based Gaming
3.2. MobiLife MobiLife is another project in which the Telematica Instituut takes part. Section 3.2.1 introduces the project. Section 3.2.2 describes the importance of context-awareness in this project and section 3.2.3 relates this project to this assignment.
3.2.1. Project Summary The MobiLife project and the WASP project are completely different projects in terms of size, scope and parties involved. The WASP project was a national project of about 20 months with three participants (the Telematica Instituut, the University of Twente and Ericsson) working together to develop a services platform. MobiLife, however, is a European project, consisting of two phases of 28 months, of which the first just started (September 2004). MobiLife, coordinated by Nokia, will be carried out by 22 organizations from 9 EU countries. Besides Nokia and the Telematica Instituut, other participants are for example Ericsson, Alcatel, Hewlett Packard, Motorola, Siemens and DoCoMo [18]. MobiLife results will contain more than ‘just’ a services framework.
As stated in the introduction of this chapter, the strategic goal of the MobiLife Project is “to bring advances in mobile applications and services within the reach of users in their everyday life by innovating and deploying new applications and services based on the evolving capabilities of 3G systems and beyond” [17].
The MobiLife project also formulated a research challenge: “to address problematics related to different end-user devices, available networks, interaction modes, applications and services”. MobiLife states that future environments, caused by ICT convergence, give new possibilities, but also new challenges due to increasing heterogeneity, user needs and expectations [17].
MobiLife is built around three main Focus Areas [17]:
Self-awareness This focus area provides support for the automatic configuration of devices, services and local connectivity in the user’s local environment. Moreover, it enables automatic and multi-modal interfaces that enhance the user experience and minimize the active user effort needed in managing the local environment.
Group-awareness This area includes context and presence support to enable individuals to relate to, share, and interact with each other and common artifacts. Novel privacy and trust models are addressed to provide the users with trustworthy services and applications.
World-awareness World-awareness offers automatic support for seamless access to and delivery of services across different domains that enable individuals to retain the accustomed use of their services, as they move between different environments and infrastructures.
3.2.2. Context-awareness in MobiLife Within the MobiLife project, standards to describe users and groups more accurately will be developed. By taking many aspects of the social life and the users’ environment into account a more accurate description can be reached. Therefore context-awareness is a major building block in MobiLife [17].
3.2.3. MobiLife and this assignment MobiLife started only recently. This assignment is lined up with MobiLife by adding the requirements of group forming and suitability for demonstration purposes. The first requirement relates to the Group-awareness area of MobiLife. The second requirement relates to the
- 21 -
Wouter Wiegmans Location-based Gaming
possibility of the game developed to function as an example of context-awareness and Group- awareness in practice.
- 22 -
Wouter Wiegmans Location-based Gaming
- 23 -
Wouter Wiegmans Location-based Gaming
4. Current work
4.1. Introduction This chapter presents an overview of current work on location-based gaming. Different location- based games will be described in section 4.2. A comparison between the different games is made in section 4.3. Section 4.4 provides some information on location-based platforms that are used to develop or provide location-based games.
4.2. Location-based Games In July 2004 a list of location-based games was published in Bauwelt, a German architecture magazine [26]. This list is used as a starting point for the description of current work on location- based gaming and is completed by location-based games found on the Internet and in literature.
Single player location-based games, and games that do not map the physical location of the player to a certain virtual world are not included. In these cases the (research) findings are not relevant and therefore they are considered to be outside the scope of this research.
The given overview of location-based games is rather extensive. The paragraph can be skipped without damage to the overall understanding of this thesis.
Pac-Manhattan [27] Pac-Manhattan places the original game of Pac-man on the streets of New York City. It was developed to explore what happens when a computer-game is placed in ‘real world’. A player (Pac-man) runs around the streets to collect all the virtual dots on the streets, while being chased by 4 human ghosts. During the game, each players is linked (by cell phone contact) with an operator who has an overview of the complete game map.
Pac-Manhattan could be considered as a location-based game according to the definition, but does require intervention of humans to update the location of the players. All players on the street tell their operator at each intersection where they are. The operator then updates the software. The developers gave two reasons for not using GPS. First GPS does not work well in an urban environment, second the GPS equipment was too expensive. Other positioning techniques are not discussed.
I Like Frank in Adelaide [29] According to the authors the first ‘3G mixed reality game’ (in March 2004), I Like Frank in Adelaide is a game in which online players from all over the world and players on the streets of Adelaide, Australia, cooperate to search for ‘Frank’. Only limited information about ‘I Like Frank’ is available. No information about positioning mechanisms, why it was developed and the findings of the game could be found, although user positioning was probably achieved by the messages exchanged between the street player and the player on the Internet
Pirates! [28] The Pirates! Project, by Nokia Research Centre and PLAY, was developed to explore some future directions of computer game design and game play, and to demonstrate novel gaming concepts and implementations. The players’ location is used to create an enhanced game experience regaining some of the social aspects of traditional game play in a computer game. While players roam the real world, they are virtually sailing a ship on the ocean. Game objectives include solving different missions such as: finding treasures, trading and fighting battles.
Pirates! is a multi-player, computer game for handheld devices connected in a wireless local area network (WLAN) environment. In addition, each device is equipped with a custom-built sensor,
- 24 -
Wouter Wiegmans Location-based Gaming
which is used to infer the players’ relative proximity to each other, and to locations in the physical world.
Some preliminary user feedback is available. The majority of the players enjoyed the game play. Direct player-to-player contact was evaded because players always risked a Game Over. Some players expressed that they would have wanted to interact more with users, without a direct risk on a Game Over. Another remark was made about the sounds used to alert players of certain events. Sounds alone are not sufficient because they cannot be heard in a noisy environment [34].
CitiTag [30][31] CitiTag is a tag-game where the players are visible on a virtual map of the game area. It was developed to research social experiences and group play in public spaces, based on the awareness of other peoples’ presence, through the use of mobile technology. In CitiTag players roam a public space with a GPS- and WiFi-enabled handheld device to search for players of the opposite team that they can ‘tag’. The player can also get tagged himself if one of the opposite team gets too close to you. Once tagged, a player needs to find a friend to free him. Positioning of users is done using GPS. Results of a pilot trial were rather positive. Players enjoyed the game experience as a result of the presence awareness aspect in this game.
Undercover [32] In Undercover players (agents) try to locate and eliminate terrorists. Undercover is a location- based game developed for commercial exploitation. Undercover is a multi-player, location-based, action strategy game for mobile devices, which allows players to interact with other agents in distant cities or countries. Tasks and game objectives include locating terrorists and attacking the enemy with your choice of weaponry.
Undercover provides some group forming functionality. Agents can join in a group to all together attack an enemy. Undercover can be played by SMS or by JAVA (over GPRS). The costs from using SMS or GPRS are the total costs of playing Undercover. The mobile network operator should provide the game in order for its subscribers to play the game. Positioning is done using the cell id of the cell phone. Knowing that an agent is in a certain area is enough for playing Undercover.
Uncle Roy All Around You [33] In this game players on the street and online players cooperate in search of ‘Uncle Roy’. The last game of ‘Uncle Roy’ was played in June 2003. Only limited information about ‘Uncle Roy’ is available. No information about positioning mechanisms, why it was developed and the findings of the game could be found, although user positioning was probably achieved by the messages exchanged between the street player and the player on the Internet.
Street players used handheld devices to search for Uncle Roy, using a map of the city and incoming messages to move through the city. Online Players cruise through a virtual map of the same area, searching for Street Players to help them find a secret destination. Street players are able to help online players in retrieving postcards from secret locations, online players are able to help street players to look for ‘Uncle Roy’. This two-way dependence requires street and online players to team up.
Can You See Me Now? [36] Can You See Me Now? is a game that happens simultaneously online and on the streets. The game was designed to explore game experiences in which mobile participants collaborate with those who are online [35]. They focused especially on: ? The impact of GPS inaccuracy on the use of location as key component in the game play ? The significance of other sources of information, especially real-time audio ? Strategies used by participants to achieve successful collaboration ? How developers can respond to these issues and support these strategies
- 25 -
Wouter Wiegmans Location-based Gaming
In Can You See Me Now? up to twenty online players were chased across a certain city by three runners. The online players played in a virtual map of the city. The runners however, were moving through the actual city, connected to the game by a handheld device with GPS and WLAN. The runners were interconnected by an audio channel, which was also broadcasted to the online players.
Can You See Me Now? was developed for evaluation purposes. After evaluation, the overall impression was that the game was broadly successful. GPS was, as expected, quite inaccurate, especially in dense areas. This resulted in that runners were shown on the virtual map on different locations than their psychical locations, which also led to unfeasible jumps across the map when the GPS location was accurate again. The real-time audio heightened the tension for the online players (they heard the runners talk about them). It also provided some context information (runners talking about having to wait for traffic on the roads, or hearing the runners breathing heavily when running). This enabled the online players to come up with strategies. Two approaches to dealing with uncertainty were proposed; hiding the uncertainty so that users are not aware of the effects of the uncertainty and revealing the uncertainty to enable users to work with it [37].
Mogi, Item Hunt [38] Another commercially available location-based game is Mogi in which players move outside, pick- up virtual items through their mobile phone (when they are near enough) and trade with other players to complete collections (also when both players are near enough to each other). The goal of the game is to get maximum points by completing collections. The game is both accessible through the web and the mobile phone. Web players have a better overview of the virtual map, which enables them to help mobile players finding certain items.
All users have to pay a monthly fee to play the game. Moreover, playing the game will generate GPRS data transfer, which will also costs the player some money, although Mogi claims their game is very light. Two positioning techniques are available. GPS is recommended when players are hunting specific items, otherwise cell id positioning (free) is recommended. The game is currently available in Tokyo, Japan (since April 2003).
GunSlingers [39] GunSlingers is the next commercially exploited location-based game, this one in Singapore. GunSlingers is a multi-player network game where players move around, track and engage enemies within their vicinity. Positioning is done by the mobile network, thus based on cell id and triangulation, and therefore the game is only available to subscribers of one operator (SingTel). This way only a cell phone is sufficient to play. Any cell phone can be used as a SMS version is available (a JAVA version is available too for more advanced cell phones). Costs are made per SMS (SMS version) or a monthly fee (JAVA version). The players can log in to a website to buy equipment and weapons with the money they earned on their missions.
BattleMachine [41] BattleMachine is a commercially available game from a Danish company Unwiredfactory [40]. Players physically move around and battle for areas. Players themselves and the service operator can create unique battles in which other players can compete. It uses the mobile network to position the players and it is available through SMS and WAP and has a web interface. BattleMachine was played in Denmark and Germany.
TreasureMachine [42] TreasureMachine is another game from the Danish company Unwiredfactory [40]. In TreasureMachine players try to find a treasure. By clues the players are led to a predefined location where the treasure is hidden. It uses the mobile network to position the players and it is available through SMS and WAP and has a web interface. It is unknown if TreasureMachine has ever been available to or played by the public.
- 26 -
Wouter Wiegmans Location-based Gaming
BotFighters [44] In BotFighters players design a robot online and battle against others on the streets. It is a commercially available game, currently deployed by mobile operators in Sweden, Russia and China (also played in Finland and Ireland). BotFighters is an action game with a robot theme, and it takes place out on the streets in the real world. Players locate each other with their mobile phones, move physically to get within range and then duel by shooting at each other [45]. Mobile positioning is used to determine whether the users are close enough to get a good hit. This positioning is achieved through the mobile network (cell id), therefore only subscribers of the same mobile operator can play together. The game is played using SMS or JAVA/GPRS. Currently it generates over 1 million SMS per week.
Supafly [46] A location-based virtual soap opera where intrigues, gang conflicts and romance are the tools of the trade for becoming a virtual celebrity. Just like in BotFighters players start with creating their own character. In Supafly the character will grow and develop a unique personality. The game is location-based, the character will find nearby friends and possible even a date. This game is from the same company as BotFighters. Positioning is achieved through the mobile network (cell id), therefore only subscribers of the same mobile operator can play together. The game is played using SMS or JAVA/GPRS.
Geocaching [47] Geocaching is the most widespread location-based game, being available in more than 200 countries. It is location-based in the sense that players look for a hidden treasure using their GPS device and GPS coordinates. Everyone can start a hunt. They just have to hide a treasure, determine the coordinates and come up with a story or some clues.
Geocaching does not rely on game logic or on a mobile network. GPS is worldwide available and Geocaching only provides an online portal for Geocachers to get in contact with each other and to exchange information about the caches and their history.
Human Pacman [48] Human Pacman is another attempt to bring the traditional game of Pacman to the real world. It was developed to “bring the computer gaming experience to a new level of emotional and sensory gratification by embedding the natural physical world ubiquitously and seamlessly with a fantasy virtual playground”. In Human Pacman the pacman and ghosts are replaced by human players. Players are equipped with GPS devices and inertia sensors (to track players’ perspective). The cookies are virtual, but some objects from the traditional game have a tangible representation. All players are linked with a helper who supports them in roaming the virtual world.
Human Pacman is thoroughly evaluated [49]. Their findings indicate that users like the idea of Human Pacman as a whole. The tangible aspects (objects) and physical aspects (catching ghosts) of the game are really appreciated (especially the physical aspect). The size of the wearable computer should however be improved as should the accuracy of positioning (to collect the virtual cookies). Helpers are thought to make the game too complex. To explain this sentiment better, more specific research will be conducted.
Swordfish [50] Swordfish is said to be North America’s first GPS cell phone game. In Swordfish the world is a virtual ocean and cell phones are fishing rods. Swordfish is commercially available on the network of mobile operator Bell (Canada). Players scan for and locate virtual schools of swordfish. Players must move to where the fish are located. Then using their cell phone as a fishing rod, they try to hook and land the big ones, and compete with other players to make the national high score leader board. Swordfish uses A-GPS for positioning.
- 27 -
Wouter Wiegmans Location-based Gaming
Real Tournament [15] In Real Tournament two teams each try to capture as many monsters as possible in a predefined game arena (for example a park). Real Tournament was developed by the Mobile IPv6 Systems Research Lab. This lab tries to gain knowledge of the requirements of future mobile applications. In the case of Real Tournament the focus was on real-time interaction. Real Tournament is a multi-player location-based mobile game, which uses handheld computers, GPS devices, WLAN and electronic compasses (the GPS devices were used for positioning).
Results of trials showed that the users enjoyed the gaming experience and had no trouble relating the physical movement with virtual movement. The developers also noticed that players almost immediately wanted to shoot at each other (not only at monsters). This kind of direct interaction between players was not implemented. To provide some possible larger game arenas, GPRS was tested instead of WLAN, but as became clear, GPRS performance is insufficient for real-time gaming. The accuracy of GPS should also be improved.
Backseat Gaming [51] The Backseat Gaming project is aimed to explore how to make use of mobile properties for developing compelling and fun game experiences. In this project a prototype game was developed for use by a young car passenger while travelling, thus a highly mobile environment. The prototype was connected to a certain road where, while travelling over that road, the player is (virtually) guided by a dwarf through a dark forest inhabited with evil ghosts. A handheld device is used in combination with GPS (for positioning). Some initial results of the Backseat Gaming project show that young children (ages 5-10) differ in the way they appreciate different aspects of the game [52].
4.3. Comparison In the previous section a number of location-based games were discussed. In table 4.1 these location-based games are compared.
Research or Positioning Pervasive Ubiquitous Augmented Location-based game Game area commercial technique game game reality ly available Pac-Manhattan R By hand Fixed I Like Frank in R By talking Fixed Adelaide Pirates! R Proximity Fixed CitiTag R GPS Fixed Mobile Undercover C Cell ID Network Uncle Roy All Around R By talking Fixed You Can You See Me R GPS Fixed Now? Cell ID, Mobile Mogi, Item Hunt C GPS Network Mobile GunSlingers C Cell ID Network Mobile BattleMachine C Cell ID Network TreasureMachine C Cell ID Mobile
- 28 -
Wouter Wiegmans Location-based Gaming
Network Mobile BotFighters C Cell ID Network Mobile Supafly C Cell ID Network Geocaching C* GPS World Human Pacman R GPS Fixed Mobile Swordfish C A-GPS Network Real Tournament R GPS Fixed Backseat Gaming R GPS Fixed Table 4.1: Comparison of Location-based games * Geocaching is available for free.
Some remarks can be made based on this comparison. First, all commercially available location- based games are available on the mobile network of a mobile operator and use Cell ID or A-GPS for positioning purposes (Geocaching was excluded because it is not available on a commercial basis). An assumption can be made that when bringing a location-based game to a large market, using a mobile network is recommended. Second, all commercially available location-based games are pervasive. When exploiting a location-based game on a large scale, pervasive gaming is recommended. Third, all commercially available location-based games provide an augmented reality. Elements of the game world are brought into the real world by the game; the player’s reality is augmented by virtual elements. Finally, non of the commercially available games are ubiquitous games. These games did not rely on a lot of communicating devices in the environment enhancing the game experience, probably just because this is currently not feasible for a large-scale game.
4.4. Location-based platforms Many location-based games are built upon a platform supporting location-based gaming or, more general, context-awareness. In this assignment the WASP platform will be used. The WASP platform is not designed especially for the development of games. Moreover, not so many applications have already been developed using the platform, so it is not guaranteed it is error- free. By taking a look at a platform that was used in the development of location-based games, a better understanding of the requirements and possible additions to WASP can be reached.
Section 4.4.1 addresses a mobile game platform supporting location-based games, which was also used for some games that were addressed in section 4.2. Section 4.4.2 addresses a new development in location-based gaming; a game console that provides functionality for location- based gaming.
4.4.1. Software platforms In many games addressed in section 4.2 no (game) platform was used or no information about the (game) platform was available. When games were developed for research purposes a platform was not used because it just was not necessary to reach the objectives of the research; it does not matter how the game is developed, if it works, the research can be done. When games were developed for commercial purposes, there is little published about the platform used (if a platform was used), unless the platform itself is commercially available too. This is the case with the Matrix Game Platform.
The Matrix Game Platform (It’s Alive) [56] The location-based games BotFighters and Supafly were developed by It's Alive. It’s Alive is a game development studio focusing on pervasive games: massively multiplayer online games
- 29 -
Wouter Wiegmans Location-based Gaming
(MMOG) with the real world as game arena [55]. Both BotFighters and Supafly are played on mobile devices and are pervasive games.
The Matrix Game Platform is developed by It’s Alive and provides the platform on which BotFighters and Supafly where developed. The Matrix game platform is a Java™-based server platform designed especially for pervasive games. The main features of the Matrix Game Platform are: ? Designed for pervasive gaming. ? Rapid game development. ? Multi-device support. ? Support for location-based gaming.
Comparing with WASP some features are related. WASP was also created to speed up the development of applications, WASP supports multiple devices and it supports context-awareness (thus allowing location-based gaming). The Matrix Game Platform however is designed especially for pervasive gaming. The WASP platform is developed for all location-based, and even context- aware applications.
Rapid game development Matrix claims that the game developer should focus on the game logic, instead of being bothered by platform logic (application servers, databases, positioning protocols et cetera). Moreover, Matrix provides an existing data model designed for pervasive games (called the Game Repository). This data model can be used to very quickly develop pervasive games.
Multi-device support Pervasive games utilize in general multiple devices, most games are for example accessible through a mobile phone and a PC. Matrix has a plug-in architecture for adding support for new devices.
Location-based gaming Matrix supports different positioning techniques, including mobile networks techniques (for example using the cell id) and the GPS system. Matrix claims it is optimized for using location information in a resource- and cost-efficient manner, due to It’s Alive’s experience with location- based games.
Scalability and robustness Scalability is an aspect that was not addressed in the development of WASP. The Matrix Platform however is able to cope with thousands of players. Matrix is built on Enterprise Java™ technology with both J2SE and J2EE components. The platform runs on several servers. All subsystems can be duplicated for redundancy and/or higher performance.
Multi-language support Matrix supports multiple languages, even in one game, using XML technology. For each player the correct language (text and graphics) can be shown (when it is available in the platform).
Simple administration The platform and the games that run on it can be managed with a web-based administration tool. All configuration files are stored in a simple XML format.
Artificial Intelligence (AI) support Matrix supports the development of game characters controlled by Artificial Intelligence (IA). This allows computer-controlled characters to be placed in the game world to interact with each other and the player-controlled characters.
Events triggered by location and time
- 30 -
Wouter Wiegmans Location-based Gaming
In Matrix certain locations and/or times can be connected to certain events. For example, a new mission can be issued when a player pass a specific place at a specific time. This event triggering technique is claimed to be resource-efficient.
4.4.2. Hardware platform: Gizmondo [53] A remarkable platform is the Gizmondo system. This piece of hardware is the first game console, supporting location-based gaming.
The Gizmondo system, set to launch on October 29th in the UK, features a range of entertainment and communications features along with its game-playing abilities [54]. This new entry to the handheld console market is the first console that also provides functionality for location- based gaming.
The console has movie and music playback functions, can link in to the phone networks for SMS and MMS communications, features a high resolution digital camera and, in a world first for a games console, has GPS navigation functions.
The GPS system is used to offer unique location-based gameplay in some of the game titles for the system, as well as enable access to basic GPS functions.
Figure 4.1: Gizmondo system
- 31 -
Wouter Wiegmans Location-based Gaming
5. Game Concept This chapter presents the game concept developed within the context of the assignment. To provide some boundaries from which the game concept could be developed, a set of game requirements was established. These requirements are presented in section 5.1. The derived concept is described in section 5.2. Section 5.3 presents the game itself. The locality and group aspects of the concept are presented in section 5.4 and section 5.5 respectively. The competition aspect of the game is outlined in section 5.6. Finally, section 5.7 gives some possible directions for future extensions of the game.
5.1. Requirements To ensure that we develop a mobile game that really attracts young people to play it and it also suited to demonstrate the concept of context-awareness in a gaming domain, we have established the following requirements.
? Location-based, mobile game The game applies the concept of context-awareness to mobile gaming. The game should therefore be available on a mobile device and should use the location of the user in the game.
? Suitable for demonstration purposes The game should serve as an example of what is possible with the concept of context- awareness. To be suitable for demonstration purposes, the allowed (user) complexity of the game is limited.
? Pervasive Game (always on) Everyone with the right hardware should be able to play, without being dependent of friends or time. By developing a pervasive game, everyone can join and leave the game whenever he or she wants. No preliminary agreements need to be made to play the game.
? Gaming to fill dead time, but also challenging for 3 hours Although this requirements is more a challenge than a real requirement, it should be taken into account that the game should be fun when, for example, the user is sitting in a train, but also when a user decides to play a complete afternoon.
? Simple joining, open to everyone As was mentioned at an earlier requirement, everyone with the right hardware should be able to play. To prevent scaring off new players, it should be simple to join the game and getting to know it.
? Team play (groups/MobiLife) As the assignment is aligned to the MobiLife project, a group (forming) aspect has to be part of the game developed.
? Target group: (High School) Students (age 12-25) The game should be challenging to (high school) students (as the expected rate of adoption is relatively high in this segment).
5.2. The Game Concept Initially several, rather simple, concept directions where developed. Comparison to the requirements led to one direction being chosen for further development. This direction presented a game concept that is built on the success of the Tamagotchi Virtual Pet, while including aspects like locality and groups.
- 32 -
Wouter Wiegmans Location-based Gaming
In our concept, instead of Tamagotchi Virtual Pets, there are pop stars. The aspect of locality was mapped to a pop star touring through a certain virtual world. The group aspect was covered by the possibility to start or join a Record Label.
The choice for pop stars (touring and record labels) was made to relate to the target group, considering international successes of television shows like Idols and Pop stars: the Rivals.
5.3. Playing the Game Each player starts the game with a new pop star. This pop star is defined by three ‘first-level’ variables: ? Singing The singing variable indexes the singing qualities of the pop star;
? Dancing The dancing variable indexes the dancing qualities of the pop star;
? X-factor The X-factor variable indexes the X-factor of the pop star, a factor very known from the television show Idols which includes the appeal, image and attitude of the pop star.
These three ‘first-level’ variables describe how good a pop star performs; the higher the variables, the better the pop star will perform.
Next to the ‘first-level’ variables, some ‘second-level’ variables exist. These ‘second-level’ variables do not say anything about how a pop star will perform on stage, but represent the current status of the pop star indicating for example his health and his tiredness. In the game, the following variables are distinguished: ? Energy The energy variable shows if a pop star needs to sleep. A low value indicates tiredness.
? Health The health variable shows if a pop star needs medical care. A low value indicates illness.
? Food level The food level variable shows if a pop star needs to eat. A low value indicates hunger.
? Mood The mood variable shows how a pop star is feeling. This value depends on several aspects including recent performances, the popularity of the pop star, recent actions of the user et cetera.
Finally some external factors exist. These factors do influence the game, but cannot be controlled by the users. ? Time The game is persistent. A pop star will, for example, become tired if he/she does not sleep for a while. A timing variable will exist indicating virtual world time.
? Age The pop star will age over time. His aging process will have influence on his performance (the ‘first-level’ variables).
The game is built around six activities (including the ‘persistent’ activity) that have an influence on the pop star. The ‘persistent’ activity is always active. The five other activities are under control of the user.
- 33 -
Wouter Wiegmans Location-based Gaming
? ‘Persistent’ activity The game is persistent. The pop star will, for example, get tired if he/she does not sleep. This will happen while the user is playing the game, but also when the user is not playing the game. This requires the user to take care of his pop star at least once every certain period of time. The ‘persistent’ activity always occurs.
? Training Training is a rather complex activity in the sense that it consists of three different sub- activities o Training alone ? minigame The user can train his pop star by going into training mode. This will have some effect on the ‘first-level’ variables of the pop star. This method of training will consist of a minigame to be developed that has to be played by the user o Training alone ? distance The user can train his pop star by going into training mode and do some travelling. The ‘first-level’ variables of the pop star will improve because of this touring through the virtual world. More about the locality aspect of the game will follow in section 5.4 o Training together The third way a user can train his pop star is by going into training mode and train together with another pop star of the same record label. The ‘first-level’ variables of both pop stars will improve because of shared experiences. More about the groups aspect of the game will follow in section 5.5.
? Sleeping By going into sleeping mode, the pop star will be able to rest. This will improve his energy level over time (‘second-level’ variable).
? Nursing By going into nursing mode, the pop star will be treated against illnesses. This will improve his health level over time (‘second-level’ variable).
? Feeding By going into feeding mode, the pop star will be able to eat. This will improve his hunger level over time (‘second-level’ variable).
? Performing Performing is the second rather complex activity. Performing is done to gain popularity in a certain area (more about locality will follow). Different types of performances exist, each with their own demands on the ‘first-level’ variables. Performing results in that the pop stars are compared to one another determining their popularity. Performing has influence on the ‘first-level’ variables (the pop star is getting more experienced on each performance), but also on the ‘second-level’ variables like mood (positive or negative based on the result of the performance) and energy.
5.4. Locality The location of the user is mapped to a virtual world. The virtual world is divided into cells. Pop stars in the same cell are considered to be nearby. The game distinguishes different kinds of cells. Some types of performances will happen in certain cells more often than in other cells. Therefore the type of performance selection scheme is not purely random, but will be based on a certain logic. This allows a user to form a strategy.
For each cell the popularity of a pop star is maintained. This allows the generation of a ranking of pop stars for each cell.
- 34 -
Wouter Wiegmans Location-based Gaming
A user has access to the pop star’s current cell, and to the surrounding cells. Per cell the user has access to some cell statistics including a list of the pop stars currently in the specific cell, the most popular pop star in the cell and the single chart list.
5.5. Groups The groups requirement is mapped to the forming and joining of a record label. A pop star can decide to form or join a record label. The goal of a record label is to become the most popular record label in the virtual world. A record label is most popular if it has got the most cells in which one of the record label pop stars is most popular.
Another, more direct, advantage of joining a record label is the ability to train together with nearby pop stars of the same record label. This will improve both pop artists. Being able to join a record label allows the development of large, competing communities of users (and their pop artists) using different strategies trying to win the game. It does also allow a group of friends to join together in a record label and play against other record labels.
5.6. The competition A pop star can compete against other, nearby pop stars to gain popularity in a certain cell. Events are chosen (pseudo)randomly (it differs per cell). The game distinguishes different events: ? Recording a single This event simulates the recording and releasing a single of the pop star in a certain cell. The single is released into the local (within the current cell) pop charts. The ranking in these charts are based mainly on the ‘first-level’ singing variable, the current popularity, the mood of the pop star and a chance factor. The ranking of a single contributes to the popularity of the pop star in a certain cell. The ranking of a single will decay over time. The pop star can decide to release a single in a certain cell whenever he wants, but he can only have one single in the charts of a cell at a time, and the number of released singles (in total) is limited. This type of performance is time intensive. It does take a while to record and release a single. If it is technically feasible, a pop star should not leave the cell during this performance (if the pop star leaves anyway, the performance will be cancelled).
? Public appearance This event simulates a public appearance of a pop star. This could for example be a movie premiere, an appearance in a talk show or a concert. A good public appearance contributes to the popularity of a pop star in a certain cell. Different public appearances exist. Only popular pop stars will be for example be invited for movie premieres and as main act at a concert, less popular pop artists can show up in a morning talk show or as supporting act in a concert. The (positive) effect of a public appearance relies mainly on the ‘first-level’ variable: x-factor. This type of performance also takes some time, but less than recording a single. The pop star is kept informed of opportunities for public appearances.
? Duel A pop star is able to challenge another pop star. In this type of performance the pop star competes directly against another pop star. In a duel both pop stars are thought to perform a dance in front of a jury. The result of a duel relies mainly on the ‘first-level’ variable: dancing, although a chance factor, and the other skills do count. The winner of the duel shall experience a positive effect. The loser of the duel shall experience a negative effect. The impacts of these effects are also depending on the difference in skills between the two pop stars
- 35 -
Wouter Wiegmans Location-based Gaming
5.7. Future work In this section some directions for possible extension of the game concept are presented. These directions came up during meetings with employees of the Telematica Instituut and were thought to be worthwhile to write down.
? Using the voice recording capability of a mobile phone in the mobile game, the gaming experience will become more pop star like; ? Using the Bluetooth capability of a mobile phone, pop stars can detect each other when they are really near, allowing a new level of context-awareness; ? The popularity of a pop star in a certain cell is not only based on events in that cell but also on the popularity of the pop star in other, nearby cells; ? The effect on the popularity of an activity (public appearance, single release) in a certain cell is related to the number of pop stars in that cell on that specific time; ? A pop star can assign a home cell where activities as sleeping and nursing have more effect.
- 36 -
Wouter Wiegmans Location-based Gaming
- 37 -
Wouter Wiegmans Location-based Gaming
6. The Game Architecture In this chapter a game architecture for the pop star game will be developed. Before looking at the pop star game, a few other game architectures will be discussed. Some of the location-based games treated in section 4.2 provided a description of their game architecture. This can help to prevent overlooking important aspects in location-based games.
6.1. Other Game Architectures The Backseat Gaming Project [51] The game prototype developed in the Backseat Gaming Project was based on an architecture as given in figure 6.1 (extracted from [51]):
Figure 6.1: Backseat Gaming Architecture
The GPS receiver continuously sends positioning data and speed of all players to the game engine. This data is sent to and processed by a mapping thread, which compares it to information stored in a database and decides when the game engine should trigger each event. The database contains the following data: ? Type of event, real object’s latitude and longitude co-ordinates, radius of manipulative area ? Latitude & longitude co-ordinates, number and type of virtual objects located at a real object. ? Information about which local story belongs to which real object and its duration in seconds
The system typically proceeds trough 3 modes when the player passes a game location (when the location info is linked to information stored in the database). First, the local story is started (the player sees a movie on his mobile device). Second, an event is generated which requires the player to aim his device to a virtual object. Using the data from the Digital Compass the Game Engine knows if the user is aiming right. Finally, the score is updated according to the results of the player. The player receives feedback based on the results.
Pirates! [28] The architecture of the location-based game Pirates! is shown in figure 6.2 (extracted from [28]).
- 38 -
Wouter Wiegmans Location-based Gaming
Figure 6.2: The Pirates! architecture
The developers of Pirates! wanted to create a modular system (to enable reuse) that was flexible enough to modify graphics and game rules in real time during game play.
To allow communication between the different components the MEX communications interface [57]. The MEX communications interface is a TCP/IP wrapper that allows a high(er) level of abstraction for low-level socket communications.
The game server runs all the game code, maintains the game logic and keeps track of all on-line players. The game server makes backups of Player data periodically. The game server is connected to the clients through WLAN. The game server also runs a database (the File Server) with all graphics and sounds, available to the clients on request.
In Pirates! the game clients, mobile devices connected to the game server through WLAN and equipped with proximity sensors, are nothing more than simple graphic terminals, fully controlled by the game server.
Proximity sensors are tagged on the mobile devices and on physical locations. All sensors listen for other sensors. When a sensor on a mobile device detects another sensor a notification (through WLAN) is sent to the game server to decide on the (possible) events to happen. The sensors on the physical locations are not connected to the game server.
The login server is responsible for user management. To play a user has to create an account. The login server is also keeping, and continuously updating, a high score board based on the information of the game server.
6.2. The Pop Star Game Architecture In this section, the game architecture for the Pop Star game will be developed and presented. Some decisions will have to be made to be able to develop the prototype of the location-based game within this assignment. These decisions will each have their impacts on the results and therefore, based on the requirements, some priority scheduling will have to take place.
For the prototype, high priority will be given to context-awareness (using the physical location) and to the groups aspect of the location-based game. Less priority will for example be given to the game logic, the accuracy of positioning, bandwidth efficiency, visualisation and security.
In section 6.2.1 the development of the virtual world will be presented. Section 6.2.2 presents the actual game architecture.
- 39 -
Wouter Wiegmans Location-based Gaming
6.2.1. The virtual world The virtual world is divided into cells. Each cell is shaped like a regular hexagon. Each cell will have 6 neighbour cells. This is illustrated in figure 6.3.
Figure 6.3: Cell structure and neighbouring cells
If a player is at a certain moment in the dark shaded cell, all light shaded cells are considered to be its neighbours. If the position of the user is known, this location can be mapped to the virtual cell structured world, and the relevant cells can be determined.
To appeal to the target group, the game should be available on a cell phone, without any additional devices. Therefore, GPS will not be used, as this requires almost always an additional device. Positioning will have to be done using the Cell ID on the mobile network. To be able to test the location-based game in practice, without having to depend on a mobile operator, the WASP location providing service will be used (see section 3.1.4). Mobile operators do not provide a database, which maps Cell IDs to useful location information (for example latitude and longitude) for free. Within the WASP project a similar database is built based on using a cell phone and a GPS device. This way, a Cell ID (of a certain mobile operator) can be related to GPS location information. For the city of Enschede a quite high coverage is already available. By using the information in this database, the location of the player can be determined (within a certain range) using its Cell ID. This location can then be mapped to the cell structure. This database is available for all operators so the game will be available on all mobile phones, on each mobile network in Enschede.
However a number of possible problems exist, including that network cells are not shaped as hexagons, network cells do not all have the same coverage and network cells have a certain overlap. Moreover, different mobile operators all have their own mobile network, all with their own different sized and shaped network cells. An example of a possible mobile network (of only one operator) is given in figure 6.4. In this figure the network cells are all the same shape and have the same coverage, and are rather good aligned to the hexagon cells. Even with this ‘nice’ mobile network, the overlap between cells is rather large (the light shaded areas). When two players are next to each other in such an area, their cell phones could have different Cell IDs and therefore, the players will not be in the same cell in the virtual world.
- 40 -
Wouter Wiegmans Location-based Gaming
Figure 6.4: Network and hexagon cells
Figure 6.4 shows a mobile network structure, which fitted relatively good on the hexagonal cell structure. However, even if the network cells are all the same shape and have the same coverage, figure 6.5 shows a structure that will cause more location errors. Even though there is less overlap (the light shaded areas) between the network cells, two users that are next to each other can be positioned in two cells that are not even neighbours (for example in the black area).
Figure 6.5: Other shaped network cell structure
Figure 6.6 shows that the size of the hexagons should correspond to the coverage of the mobile network cells. When the hexagons are too small compared to the network cells, a Cell ID could be related with more hexagon cells resulting in a player being in multiple hexagon cells at the
- 41 -
Wouter Wiegmans Location-based Gaming
same time, or, if a Cell ID can only be related to one hexagon cell, some hexagon cells will not be reachable. When the hexagons are too large compared to the network cells, multiple Cell IDs would be related with one hexagon cell. This would mean that one has to travel a lot to change from cell (in the virtual world).
Figure 6.6: Too small and too large hexagons
For the prototype game that will be developed in this assignment the size of the hexagon will be chosen a bit smaller than the average network cell size. The assumption is made that this is small enough for a player to travel through some cells each day, and large enough to be covered by a network cell. Relating network cells to hexagons will be based on the centre of the network cell. A hexagon is linked to the network cells that have their centre in the hexagon. This will be enough to test experiences with location-based gaming, but could be a point of interest when the prototype is improved.
Furthermore, as the game will be suited for on all available mobile networks in Enschede, if one mobile network is aligned pretty well to the hexagons, another could be completely not. It should be interesting to see how users coop with possible side effects from this form of mobile positioning. How do people react to being physically near to each other, but virtually in different cells? Or what if some hexagon cells are not reachable for certain providers because the centres of the network cells all are in other hexagon cells?
6.2.2. System architecture Different components can be distinguished in the location-based game. Figure 6.7 presents a visualization of the system architecture.
- 42 -
Wouter Wiegmans Location-based Gaming
Figure 6.7: The Pop Star game system architecture.
The Client The client consists of 3 parts. A Cell ID application, a Time service, and a Game Client. Combining these into one application allows users having only to install one application to be able to play the game. Moreover, this way allows easy cooperation between the three parts.
Although bandwidth efficiency is not high prioritized, it was taken into account while developing the architecture. Therefore, to minimize data transfer, a lot of game logic is included in the client.
The Cell ID application The Cell ID of the cell phone is available on the cell phone itself. A special application is able to fetch this Cell ID to allow using it in the location-based game. This however imposes some constraints on the development of the application. As fetching the Cell ID is only possible with a Personal Java ‘Native Call’, Personal Java will have to be used to develop the game.
Time The time service is needed for enabling some game client functionality. It is controlled by the game engine. On every information update the time of the game client and the game engine are synchronized (the time of the game engine is used as guideline). The time services provides:
- 43 -
Wouter Wiegmans Location-based Gaming
? Current Time (when empty the game is in between rounds) ? End Time
The Game client The game client runs on the cell phone (next to the Cell ID application). The game client has several functions. First, it provides information to the user:
Pop Star Information: Name, Singing, Dancing, X-factor, Energy, Health, Hunger, Mood, Age.
External factors: Time (virtual time).
Record Label Information1: Name of Record Label, Members of Record Label2, Popularity statistics3. 1 Only if the Pop Star is member of a Record Label 2 Of each member the Name, Age, Singing, Dancing and X-factor is shown 3 The 5 most popular Record Labels and the place of the Record Label itself if it is not in the top 5
World Information: Pop Stars in current cell1, Pop stars in neighboring cells1, Popularity statistics in the current cell2, Popularity in other cells3, Charts in current cell, Relevant Charts4, 1 Of each Pop Star the Name, Age, Singing, Dancing, X-factor and Record Label is shown 2 The 5 most popular Pop Stars and the place of the Pop Star itself if it is not in the top 5 3 Popularity in other cells is only given if the Pop Star is one of the 5 most popular Pop Stars in that specific cell 4 Relevant charts are the charts in which a single of the pop star is listed
Second, the Game Client provides the user with a number of activities, based on the current state of the game: ? Training alone (possibly improved by traveling through some cells) ? Training together (if a fellow Record Label member is nearby and wants to train too) ? Sleeping (to improve energy level) ? Nursing (to improve health level) ? Feeding (to improve hunger level) ? Performing – Releasing a single ? Performing – Engage in a Public Appearance (if one is available in the current cell) ? Performing – Duel (if another Pop Star is nearby and wants to duel too) ? Requesting information update (updates all client-side information) ? Join or form a record label (if the player is not in one)
Some activities are completed on the cell phone itself and only little data is sent to the game engine, some activities explicitly require game engine functionality to complete. This differs per functionality and therefore each will be addressed:
Training alone is a mode the pop star can be in. The game client provides the user with a mini game that can be played to train the pop star. The game client also keeps track of the number of network cells the user passes while in this state. Both the mini game performance and the number of cells passed count for the training results. The game client calculates the results. Training has a negative effect on health, hunger and energy, and a positive effect on mood and the first-level variables. This kind of training has no minimum duration. This enables the user to train his pop star every time he has some time available. While in training mode the application cannot be turned off (this will end the training session).
Training together requires 2 players of the same record label, in the same virtual cell, that will be connected to each other. The game client updates the game server that the pop star wishes to
- 44 -
Wouter Wiegmans Location-based Gaming
train together. Now, the game client will check every 30 seconds to see if another fellow Record Label pop star also wants to train together (pushing information to a cell phone is not possible). If another pop star is found, they are linked to each other. Except for being linked with another pop star, this method of training is the same as training alone (so also a mini game and passing network cells). The client is informed when the other pop star ended the training session. The game client destroys and restores the connection with the game server every 10 minutes prevent staying in one network cell all the time. Training has a negative effect on health, hunger and energy, and a positive effect on mood and the first-level variables. This kind of training has a minimum duration of one hour, stopping the session (by one of the trainees) earlier will result in no positive effects (for both parties). Both pop stars have to be in the same cell when the training together is initiated, after that, this is not required anymore. While in training mode the application cannot be turned off (this will end the training session).
The activities sleeping, nursing and feeding are all a bit of the same. They all improve a second- level variable. While in one of these modes, the specific second-level variable will increase more than it decreases due to the persistent game effect. They all have a minimum duration. No communication with the game engine is necessary. The results are calculated locally.
The performing activity is divided into the three types of performances. Recording a single requires the user to stay in a certain virtual cell for the time it takes to record a single (a few hours). At the end of recording the single is released into the pop charts of the current cell. This is calculated by the game engine.
Public appearances are generated by the Public Appearance Management and communicated to the user through the game engine. A Pop Star can join a public appearance. The Pop Star should not leave the cell while waiting for the Public Appearance to start. Each Public Appearance has a predefined duration. At the end the game engine calculates the results and provides them to the pop stars.
Duels require the game engine to link 2 pop stars just like in the training together mode (although this time the pop stars cannot be member of the same record label). The duration is determined at random between certain limits (pretty short to encourage different users to come together and play against each other) and the results are calculated at the end by the game engine and provided to the pop star(s).
Each type of performance has a negative effect on health, hunger and energy and dependent of the results an effect on mood. Moreover, they also improve the popularity of the pop star in the cell the performance took place. This is part of the game engine functionality.
‘Requesting information update’ updates all pop star-relevant information on the game client and the game engine. Information is exchanged to synchronize all data.
By joining or forming a Record Label the user can select or create a Record Label in which his pop star will enter. The game engine provides the game client with a list of Record Labels of which the user can select one, or enter a new one. This is again communicated to the game engine.
Third, the Game Client is also responsible for a part of the persistent activity. The location-based game is a pervasive game. Due to the persistent activity a Pop Star gets tired over time, a single in a pop chart will not stay on the same place forever and the popularity of a Pop Star in a certain cell decreases if he did not visit it for a while. The persistent activity on the game client influences the variables in white (the grey variables are influenced by the game engine on the game server):
Increasing over time Decreasing over time Age Energy
- 45 -
Wouter Wiegmans Location-based Gaming
Singing1 Health Dancing1 Hunger X-factor1 Singing1 Single Charts2 Dancing1 Age X-factor1 Single Charts2 Popularity in a cell Mood Table 6.1: Persistent Activity GameClient 1 As the Pop Star ages, his first-level variables will increase at first (becoming more adult), but eventually decrease (getting old) 2 A single will rise in the charts in the first weeks, but will eventually exit the charts
The Mapping service The mapping service performs the mapping between real world (Cell ID) and virtual world (hexagon). The mapping between Cell IDs and hexagons is fixed; a database is available with the relations between Cell IDs and hexagons, so the mapping is a rather simple operation. The Mapping Service will be connected to the WASP mapping service (using web services).
The Game engine (Game server) Where the client is responsible for only one pop star and the functionality that is required for that one, the game engine is responsible for all pop stars and the functionality that is required for them all. In short, the game engine functionality includes data storage and inter-pop star related activities. Each part of the game engine functionality will be addressed:
Information update A pop star can, albeit automatically, request an information update. The game engine updates the player information1, retrieves relevant world information (based on the Cell ID), relevant Pop Star information and relevant public appearance possibilities and provides this to the client. The game engine stores when a Pop Star was in a cell for the last time. This value influences the popularity of the Pop Star in the cell. 1 If the IMEI number is unknown, the game engine assumes a new player has joined the game and a Pop Star is created. See: Create Pop Star
Create Pop Star When a player joins the game for the first time a new Pop Star will be created (‘born in the virtual world). Also when a new game round starts, all players should be provided with a new pop star. A pop star will be linked to a cell phone using the unique IMEI number of the cell phone. This does unable a user to switch cell phones, but restricts possible fraud of maintaining a pop star with more cell phones/users.
Form or Join Record Label A Pop Star can form or join a record label. For each Pop Star the game engine registers if he is part of a Record Label. If a Pop Star creates or joins a Record Label, the Game Engine updates the relevant data. Being member of a Record Label has a small positive effect on mood.
Performing Performances in a certain cell influences the popularity of the pop star in that cell. The exact results depend on the results of the performance. The completion of a performance is communicated to the game engine by the game client(s). The game engine determines the result of the performance. Relevant popularity indexes are updated. A single release has a long-term result (the single is in the charts for a certain period of time). A public appearance and a duel have results on shorter terms. If a performance is cancelled, it will have no effect on the popularity.
- 46 -
Wouter Wiegmans Location-based Gaming
Persistent Activity The location-based game is a pervasive game. Due to the persistent activity a Pop Star gets tired over time, a single in a pop chart will not stay on the same place forever and the popularity of a Pop Star in a certain cell decreases if he did not visit it for a while. The persistent activity on the game client influences the variables in white:
Increasing over time Decreasing over time Age Energy Singing1 Health Dancing1 Hunger X-factor1 Singing1 Single Charts2 Dancing1 X-factor1 Single Charts2 Popularity in a cell Mood Table 6.2: Persistent Activity GameServer 1 As the Pop Star ages, his first-level variables will increase at first (becoming more adult), but eventually decrease (getting old) 2 A single will rise in the charts in the first weeks, but will eventually exit the charts
Player Management Player Management is responsible for storing and organizing player data. It also provides a way to change the data. The following data is stored by Player Management (for each player): ? Unique User ID ? Name of Pop Star ? Singing ? Dancing ? X-factor ? Energy ? Hunger ? Health ? Mood ? Date created (Age can be determined using this information and the current time) ? Current cell ? Current activity (can be empty) ? Time done with activity (can be empty) ? Record label (can be empty)
World Management World Management is responsible for storing and organizing (virtual world) cell data. It also provides a way to change the data. The following data is stored by World Management (for each cell): ? Unique Hexagon ID ? Hexagon ID of neighbors (maximum of 6, less possible at the edges of the virtual world) ? Cell Type ? Popularity charts ? Single charts ? Public appearance opportunities ? History of performances
- 47 -
Wouter Wiegmans Location-based Gaming
? History of Pop Star visits
Group Management Group Management is responsible for storing and organizing Record Label data. It also provides a way to change the data. The following data is stored by Group Management (for each Record Label): ? Unique Group ID ? Name of Record Label ? Members of Record Label ? Popularity of Record Label
Public Appearance Management Public Appearance Management generates public appearance opportunities. The rate and type of these public appearances is influenced by the type of the cell. Each public appearance opportunity is described by: ? Unique Public Appearance ID ? Type of Public Appearance ? Time of Public Appearance ? Number of Pop Stars that can join Public Appearance ? Pop Stars that joined Public Appearance ? Results of Public Appearance (to be determined after Public Appearance) ? Duration of Public Appearance
Time The time service is responsible for adding the time dimension to the virtual world. The time function can be reset indicating a new game round. The time services provides: ? Current Time (when empty the game is in between rounds) ? End Time
- 48 -
Wouter Wiegmans Location-based Gaming
- 49 -
Wouter Wiegmans Location-based Gaming
7. Implementation This chapter covers the process of implementation of the location-based game. The implementation was divided into several subsections, starting with the parts thought to be the hardest to implement. Section 7.1 covers the first step in the implementation process, the mapping between the virtual game world and the real world. Section 7.2 covers the implementation of the location-based game itself. Section 7.3 covers the structure of the database behind the mapping application and the location based game. Section 7.4 presents a game scenario using screenshots of the prototype.
7.1. Building a game world on the real world
Figure 7.1: The Mapping Service
The part of the complete game architecture covered here is shown in figure 7.1.
As presented in chapter 6.2.1 the virtual world consists of a number of hexagons. The location- based aspect of the game will be realised with a mapping between the virtual world and the real world. The architecture of the mapping functionality is shown in figure 7.2.
- 50 -
Wouter Wiegmans Location-based Gaming
Figure 7.2: Architecture of Mapping service
The mapping process consists of several classes. The class GameAdminClient is responsible for a text based user interface. The GameAdminClient presents the user all options supported in the mapping process. No logic is included in the client, the responsibility is limited to allowing the user to initiate actions within other classes.
The class VWorld is responsible for building a virtual world. An algorithm was developed to build a world of virtual cells using GPS coordinates. The algorithm supports not only hexagons; triangles and squares are supported too. The algorithm calculates the center, and neighbors, of each virtual cell within the boundaries of a given square of GPS coordinates. Different cell sizes are supported to try out different virtual worlds.
The class CellDataRetriever retrieves, using webservices, data from the WASP CellStoreService. Using the data from the WASP CellStoreService a mapping can be performed between the real world and the virtual world. The data accessed by the CellStoreService includes a mapping between network cells and GPS coordinates.
The actual mapping between the virtual and real world is performed by the class Mapping. This class uses the data from the CellDataRetriever and the virtual world created by the VWorld class. The virtual cells are linked to the network cells using their GPS coordinates. A network cell is mapped to the virtual cell in which the most measurements of that network cell are made. If the location-based aspect of the location-based game seems to be inaccurate, another algorithm can be tried to perform the mapping between network cells and virtual cells.
MysqlHelper performs a bridging function between the mapping process and a MySQL database. All the data generated by the process, virtual worlds and mappings, should be saved into a database to allow for future analysis. This analysis function itself is also included in the MysqlHelper.
The class Cell enables a consistent and easy storage of virtual cells and of GPS coordinates.
7.1.1. Analysis of the game world To find an optimum in the size of the virtual cells and the total number of cells in the virtual world an analysis was done with different cell sizes within the area of the city of Enschede. Table 7.1 gives an overview of the virtual worlds analyzed.
- 51 -
Wouter Wiegmans Location-based Gaming
Cells not Average Total reachable by Unreachable number of Minimum number of network Cell size number the three cells after network cells per virtual cell per (radius) of virtual largest mapping cells per operator cells operators virtual cell together 0.0020 726 588 726 0.25 0.07 0.0030 320 209 319 0.57 0.15 0.0040 180 96 174 1.01 0.27 0.0050 108 48 97 1.68 0.45 0.0060 80 29 71 2.26 0.61 0.0070 60 21 46 3.02 0.82 0.0080 45 9 31 4.02 1.09 0.0090 35 10 22 5.17 1.40 0.0100 30 9 14 6.03 1.63 0.0110 22 4 9 8.23 2.23 0.0120 20 3 7 9.05 2.45 0.0130 18 5 7 10.06 2.72 0.0140 18 5 7 10.06 2.72 Table 7.1: Analysis of different mappings
It is clear that the first few mappings should be disregarded immediately. The cell size is too small and therefore too many virtual cells are unreachable. It is also clear that in the final few mappings a cell size increase does not decrease the number of unreachable cells anymore.
The fourth column shows how many virtual cells are not reachable for the three largest network operators together. A virtual cell is considered not reachable for the operators together if it is reachable by only one or two of those operators. The largest network operators are calculated based on the number of network cells available in the CellStoreService (within the limits of the city of Enschede). An operator is currently assumed to belong to the largest ones if more than 45 network cells are known in the database (for the city of Enschede).
For the initial test run of the location-based game a cell size of 0.0100 will be used. The number of (reachable) cells is expected not to be too small, the virtual world (of reachable cells) will be around 20 cells, and the differences between different network operators are not too large.
- 52 -
Wouter Wiegmans Location-based Gaming
7.2. Building the actual game
Figure 7.3: The Actual Game
The part of the complete game architecture covered here is shown in figure 7.3. During implementation the functional architecture as developed in chapter 6 was translated into a architecture built on java classes. This architecture is shown in figure 7.4.
- 53 -
Wouter Wiegmans Location-based Gaming
Figure 7.4: The actual game architecture
7.2.1. The GameClient The GameClient is built up from different classes. The class PopFrame is responsible for a graphical user interface, supported by three interface classes WorldCanvas, IndicatorCanvas, TextCanvas. The first, WorldCanvas, gives a graphical representation of the location of the pop star in the virtual world. It shows the current cell, cells nearby, and shows whether or not other pop stars (of the same record label) are nearby. The second, IndicatorCanvas, translates a numerical value (for example the value indicating the energy level of a pop star) to a graphical indicator bar. The third, TextCanvas, allows improved positioning of text values. The class PopFrame combines these three classes together with the functionality included in PopFrame to provide a complete user interface. The class is only responsible for the User Interface. It does not contain any game logic. The user interface is showed in section 7.4.
The class ClientLogic is the cornerstone of the GameClient. It is initiated by the user and is responsible for connecting all different objects within the GameClient with each other. Moreover, the class performs all client-side game logic, except for the persistent activity logic, for which it initiates a thread.
PersistentThread, initated by ClientLogic, takes care of the persistent activity logic of the client. It is responsible for giving an indication of the energy, health, mood and hunger level of the pop star and for giving the exact values of the dancing, singing and xfactor values. When initiated, the thread is aligned to the persistent activity of the server, to improve the indication of energy, health, mood and hunger values.
- 54 -
Wouter Wiegmans Location-based Gaming
The Communicator is responsible for the communication between the GameServer and the GameClient. All communication related logic is included in this class. It initiates the connection with the GameServer, and reconnects when the connection is broken.
7.2.2. The GameServer The GameServer should always be available during the game. The GameServer is capable of addressing multiple GameClients at the same time, although scalability was not considered during the development, so a high number of connected GameClients could affect performance. The GameServer is built up from the following classes.
Whereas the class ClientLogic was the cornerstone of the GameClient, the class GameServer is the cornerstone of the GameServer. It should be initiated by a (human) game manager and should run continuously. The GameServer allows GameClients to connect and initiates the persistent activity. Moreover, in the GameServer several configuration values are defined to allow flexibility within each game round.
The class ClientThread, is responsible for the communication between the GameClient and the GameServer. For each connected GameClient, a separate ClientThread is initiated. All communication related functionality is included in this class. When the connection is broken, the thread ends. When the GameClient reconnects, a new thread is initiated. For client specific activities, on connection, a Client object is created.
The Client class performs all client specific functionality, all initiated by the GameClient. The Client class only responds to incoming commands, and never initiates activities by itself. For each GameClient connected, a Client class is initiated.
Three activities, training together, dueling and public appearances, require pop stars to be connected to each other. When a pop star for example wants to train together, it should search for another pop star, in the same cell, of the same record label, that also wants to train together. When a pop star wants to duel, another pop star in the same cell have to be found, and when a pop star wants to take part in a public appearance, this should be administrated too. Therefore a LinkManager object is available, offering the functionality to link pop stars with each other.
The PersistentThread, initated by GameServer, takes care of the persistent activity logic of the server. It is responsible for giving the exact value of the energy, health, mood and hunger levels of all pop stars in the game. Moreover, it initiates the cleaning up of empty record labels and old link objects and it deletes pop stars that ‘died’.
Public appearances should not be specified by the (human) game manager, but should be generated at random. The PAManager is responsible for randomly, during the game round, generating public appearances.
SQLConn performs a bridging function between the GameServer and a MySQL database. All the game data is stored in a MySQL database. Moreover, the virtual world data, generated by the mapping process, is available in this MySQL database.
7.2.3. GameObjects & Exceptions The communication between the GameServer and GameClient(s) consist of sending GameObjects to each other. All communication is between the GameServer and a GameClient follows one of the following two formats.
Scenario 1 The GameClient sends a Command object to the GameServer. The GameServer does not reply to this Command.
- 55 -
Wouter Wiegmans Location-based Gaming
Scenario 2 The GameClient sends a Command object to the GameServer. The GameServer replies to this Command with a GameObject.
Table 7.1 gives an overview of the GameObjects available in this game.
GameObject Name Represents GameObject Abstract, serializable, class for GameObjects GameObjectException Exceptions generated by the GameServer Command Command from the GameClient to the GameServer Charts Current charts for a given virtual cell Config Current set of configuration values HisDuel Results of a given duel in the past HisList A list of history data (duels, public appearances or visits)* HisPA Results of a given public appearance in the past HisVisit A visit of a pop star to a virtual cell in the past* Link A connection between two or more pop stars PA A public appearance PAList The list of public appearances for a given virtual cell PopStar The pop star Popularity The popularity of a pop star in a given virtual cell RL A record label RLList A list of all available record labels Single A single World The ‘local’ world for a pop star (current cell & nearby cells) Table 7.1: GameObjects * Currently not used in the game
7.2.4. Location providing Some classes were used to determine the current network cell ID and the IMEI number of the mobile device. To be able to test and debug the game on a desktop environment, two simple simulator classes were developed, performing, in a very simple, but useful way, the functionality of the location providing classes. These simulation classes RPhone and NetworkInfo are included with the prototype.
7.3. Database structure A MySQL database is used to keep track of game data. The mapping application (see 7.1) stores the mapping between real world and the virtual world in the database. The location-based game uses the database to store for example pop stars, singles and public appearances, and uses the mapping in the game. In this section the structure of the database is discussed.
7.3.1. The Mapping process The mappings between real world and virtual world are stored in three tables, ‘mapinfo’, ‘mapping’ and ‘vworld’. In the table ‘mapinfo’ some general information about each mapping is stored (for example number of virtual cells, cellsize and number of neighbor-cells per cell). In
- 56 -
Wouter Wiegmans Location-based Gaming
‘vworld’ the actual virtual world is stored; virtual cell identifiers, and for each virtual cell, identifiers of their neighboring cells. The table ‘mapping’ consists the actual mapping between all network cells and virtual cells.
7.3.2. The Actual Game The location-based game uses the tables ‘mapping’ and ‘vworld’ generated by the mapping process. Moreover, the game uses some tables of its own to keep track of the gamedata. An overview of these tables is given in Table 7.2.
Table name Functionality lbg_group Store Record Labels lbg_historyduels Store history data of past Duels lbg_historypa Store history data of past Public Appearances lbg_historyvisits* Store history data of past Visits lbg_pa Store Public Appearances lbg_player Store PopStars lbg_single Store Singles Table 7.2: Tables of the location-based game * In current prototype not used
7.4. The game running Only the GameClient is equipped with a graphical user interface. The GameServer and the Mapping Application both run in a Command Prompt environment. This section shows some screenshots of a typical GameClient session.
The User starts the PopStar game. A GPRS connection has to be The User is unknown. A new established to retrieve game data. PopStar will be created.
- 57 -
Wouter Wiegmans Location-based Gaming
The virtual world is loaded. The The player wants to view the The just created PopStar is pretty PopStar is at the border of the statistics of his PopStar. healthy right now. virtual world. There are 2 other PopStars in this cell, both of no, or another record label than the players PopStar. No other PopStars are nearby.
The player looks at the available And after creation, he is member The player decides to launch a Record Labels, but decide to of the Record Label. single in the current cell. create one himself.
- 58 -
Wouter Wiegmans Location-based Gaming
After a while, his single is released The player requests the cell Another PopStar has joined his in the current cell. information and sees he is the record label. This is visible in the most popular PopStar. No Public virtual world. Appearance is yet available in this cell.
The PopStar refreshes his Cell Being a guest at a radio station. It The PopStar starts to duel against information window and sees a is tomorrow, so the PopStar another PopStar. Unfortunately he new Public Appearance. Let’s decides not to join this Public loses. Probably should he train check this one out. Appearance yet. some more.
- 59 -
Wouter Wiegmans Location-based Gaming
The player has to do some other work. He switches his PopStar to sleeping and exits the game. Figure 7.5: PopStar Game Session
- 60 -
Wouter Wiegmans Location-based Gaming
- 61 -
Wouter Wiegmans Location-based Gaming
8. Evaluation In this chapter, the prototype developed during this assignment is discussed. As was written in section 6.2 some decisions would have to be made considering what to include in the prototype and what to leave out. Section 8.1 discusses the prototype with respect to the requirements. Section 8.2 discusses the prototype with respect to the functionality included.
8.1. Requirements Table 8.1 recalls the requirements established in section 5.1 and reviews these requirements with the prototype.
Requirement Evaluation Location-based, mobile game Suitable for demonstration purposes Pervasive Game (always on) Gaming to fill dead time, but also Cannot judge due to insufficient information about challenging for 3 hours experiences with the prototype. Simple joining, open to everyone (Assumed, not thoroughly tested)
Team play (groups/Mobilife) Record Labels are included and working, although direct group interaction is limited. Target group: (High) School students Cannot judge, but concept was developed on existing TV- shows popular in the target group.
Table 8.1: Requirements evaluation
Table 8.1 shows that prototype complies with the gross of the requirements. Though, some additional testing is required to be able to provide an overall judgement with respect to the requirements.
8.2. Functionality
8.2.1. Game Objects All relevant objects of the location-based game are included. PopStars, Singles, Public Appearances, Record Labels, all are included in the location-based game. Moreover, the game provides already some functionality for possible future extension of the game.
Currently, duels and public appearances that took place in the past are stored in the database. Visits of a specific PopStar to a specific virtual cell are not. However, an object HisVisit is already available in the location-based game to allow quick implementation. An object HisList is also available, allowing for retrieving a list of history data (for example a list of all duels of a PopStar). Currently not used in the prototype, but the object is available.
For almost each object used in the game, a create, get from database, update in database and delete function is available. Not all these functions are currently used. For example, the update function for record labels is currently not used, although being able to change the name of a record label could be of interest to the players. Secondly, an improved gameServer, allowing viewing and modifying all data could also be an interesting option for improvement. For a great part object handling functionality is already included.
All java files are commented according to JavaDoc standards to allow good readability.
- 62 -
Wouter Wiegmans Location-based Gaming
8.2.2. Activities All activities mentioned in the concept are included in the game. However, some activities are included, but not as extensive as described in the concept. Sleeping, eating and nursing are included as described in the concept. Training alone does not provide a mini game. Just going into the training alone mode, will increase the first level variables. The complex activities, training together, releasing a single, dueling and public appearances are all included. However on the level of feedback to the player, some things could be improved. The establishment and processing of a link between two or more different PopStars (necessary for training together, dueling and public appearances) could be communicated in a better way to the player.
The calculation involved in different activities could also be improved. For example, a negative effect on mood when a duel is lost, and a increased decrease of the energy level while training together, can improve the gaming experience.
8.2.3. Locality The current cell ID of the player is mapped to a virtual cell ID. The game therefore is location- based. The virtual world currently used is divided into 30 virtual cells. During analysis it was already noticed that some virtual cells had a lot of network cells assigned to them, and some did not. The effect of this mapping is that some virtual cells are rather large. A refinement of the WASP database could improve the division of network cells over virtual cells. Improvement of the algorithm that assigns network cells to virtual cells could also improve the division.
8.2.4. Groups Groups are included by way of Record Labels. Members of the same record label have the possibility to train together (when they are in the same virtual cell) increasing the results of the training (in comparison with training alone). For each record label, the popularity can be calculated. Currently the popularity of record labels is shown in the overview of Record Labels when a PopStar wants to join one.
8.2.5. The User Interface The user interface could also be improved. The current user interface was developed to test location-based gaming, and enhanced to give it a bit of a gaming look and feel. However, no design of human – multimedia interaction science was applied in the development of the user interface.
8.2.6. GameServer & GameClient The GameServer does not provide a graphical user interface. Moreover, communication with gameClients is not without errors. Currently, on an error, the communication with the GameClient is broken, forcing the GameClient to restart the application. Both could be improved.
The GameClients error handling capability could be improved. Currently, most errors will require a restart of the GameClient.
8.3. Conclusion The essence of the concept is included in the prototype. The prototype is assumed to be useful for experiencing context-aware services in practice. However, there are a lot of possibilities to improve. Whereas this chapter directly looked to the prototype in relation to the concept, chapter 9 will reflect on the assignment as a whole and provide some more directions for future work.
- 63 -
Wouter Wiegmans Location-based Gaming
9. Conclusions & Future work This chapter presents the overall conclusions in section 9.1 and identifies directions for future work in section 9.2.
9.1. Conclusions As was stated in section 1.2 this assignment was focused on context providing (location), context exchange and group aspects in a mobile gaming setting. The goal was to design a mobile gaming application that uses the player’s physical location and alliances to enhance the gaming experience. The application would make use of appropriate generic components from the WASP platform whenever possible.
The development of the location-based game was preceded by an extensive literature study in the area of location-based gaming. This study is useful for anyone interested in location-based gaming. It describes location-based gaming on a scientific level, it presents the different technologies involved in location-based gaming and it addresses the international application of location-based gaming, both on commercial basis as for research purposes.
The development of the location-based game resulted in a gaming concept, a game architecture and an actual, working prototype of the location-based game. This prototype includes a client side application to run on the mobile devices of the players, a server side application to perform the game logic, and a server side application to create virtual worlds on real world data.
Unfortunately not much of WASP could be used in this assignment. WASP components seemed to generic to use within the location-based game. This assignment could therefore not make use of the full potential of the WASP platform and is therefore no test of the WASP platform.
As was already concluded in section 4.3 this prototype is the first location-based game, city wide (and potentially nation wide) available, that was developed for research purposes. Continuing in this direction, this research could really contribute to international research on location-based gaming.
The objective of this assignment was more on the level of exploratory research, than on causal inference research. No hypotheses were developed. However, new possibilities for future research were developed during this assignment (see section 9.2).
9.2. Future work Several directions for future work were already mentioned in earlier sections. This section will some additional directions, not already discussed in section 5.7 and in section 8.2.
9.2.1. Bandwidth efficiency versus consistency game data Communication over GPRS is rather expensive, so the amount of data exchanged between the GameClient and GameServer should be minimized. However, inconsistency between the GameServer and the GameClient introduces unreliable game play, so therefore every action should be communicated to the server.
The use of bandwidth can of course be improved by making the communication more efficient; communicating only the data necessary. However, research into the relation between game experience, bandwidth use and game consistency could further decrease the use of bandwidth while enhancing the game experience. One approach could be to allow a certain degree of inconsistency between the view on the game on the GameClient and the GameServer. The use of caching techniques and synchronization techniques should be studied further.
- 64 -
Wouter Wiegmans Location-based Gaming
9.2.2. Game Logic During the development of the prototype, the focus on the location-based aspect and the group aspect was bigger than the focus on the game logic. Furthermore, the game logic has not been tested completely and thoroughly. To be able to test context-aware services in real life, with the average guys/girls from the street, the game logic should not contain any flaws, as this will interfere with the context-aware experience.
In that case the suggestions mentioned in section 8.2, and factors like scalability and data efficiency should be improved to use the popstar game in a trial-like setting.
- 65 -
Wouter Wiegmans Location-based Gaming
- 66 -
Wouter Wiegmans Location-based Gaming
10. References [1] Dey, K., et al., A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications. Human-Computer Interaction Journal 16, 24 (2001), pp 97-166. [2] Dockhorn Costa, P., Towards a Services Platform for Context-Aware Applications. August 2003. [3] Pokraev, S. et al., Context-aware services, state-of-the-art. Telematica Instituut, 30 November 2003. [4] Leiberman, H. and Selker, T. (2000) Out of Context: Systems That Adapt to, and Learn from Context. IBM Systems Journal 39, 3&4 (2000), p. 617-632. [5] Hamilton F. and Stevenson, D. New Pricing Models Are Required To Kick-Start the European Wireless Gaming Market. Game Press, 28 October 2004. http://www.gamesindustry.biz/press_release.php?aid=5199 (last viewed on 26 January 2005) [6] Sega, AT&T Wireless Push Mobile Gaming. Wireless News Factor Press release, available via the Internet at http://www.wirelessnewsfactor.com/perl/story/19673.html. [7] Donelan, J., Mobile Gaming prepares for takeoff. Computer Graphics World, September 2004. [8] Game Research. http://www.game-research.com/wireless.asp asds alks lkjsa dkljsa lkja [9] Björk, S., et al., Special Issue on Ubiquitous Games. Personal and Ubiquitous Computing 6, 5-6, December 2002. [10] Open Mobile Alliance. http://www.openmobilealliance.org/about_OMA/index.html (last viewed on 26 January 2005). [11] Experiences using a dual wireless technology infrastructure to support ad-hoc multiplayer games / Ritter, H., Voigt, T., Tian, M. & Schiller, J. – In: Proceedings of the 2nd workshop on Network and system support for games, 2003 [12] Ericsson, Facts about positioning services Ericsson. http://www.ericsson.com/mobilityworld/sub/articles/other_articles/facts_about_positioning _services (last viewed on 26 January 2005) [13] Openwave, Overview of Location Technologies. 19 November 2002. [14] Björk, S., et al., Designing Ubiquitous Computing Games – A Report from a Workshop Exploring Ubiquitous Computing Entertainment. PLAY Studio, Interactive Institute Sweden, 2002 [15] Six in the city: introducing Real Tournament - a mobile IPv6 based context-aware multiplayer game / Mitchell, K. – In: Proceedings of the 2nd workshop on Network and system support for games, 2003 [16] WASP, Web Architectures for Services Platforms, http://wasp.freeband.nl. [17] MobiLife, Annex I – “Description of Work”. 1 September 2004. [18] MobiLife Press Release 01/2004. 8 September 2004 [19] P. Ebben et al., “Blueprint and design of the WASP application platform”, WASP/D2.2, December 2002 [20] Koolwaaij, J. and Strating, P., Service Frameworks for Mobile Context-aware Applications. Telematica Instituut, Date unknown. [21] W3C, “Web services”, http://www.w3c.org/2002/ws, Last viewed on 26 January 2005. [22] A. Harter et al., The Anatomy of a Context-Aware Application, Mobile Computing and Networking, 2002, http://www.uk.research.att.com/pub/docs/att/tr.19999.7.pdf [23] Broens, T., Context-aware, Ontology based, Semantic Service Discovery. University of Twente, July 2004. [24] Leiberman, H. and Selker, T. (2000) Out of Context: Systems That Adapt to, and Learn from Context. IBM Systems Journal 39, 3&4 (2000), p. 617-632. [25] M. van Setten et al.,”Context-Aware Recommendation in the Mobile Tourist Application Compass, 2004 [26] Computergames and Urban perception, 08 July 2004. http://www.we-make-money-not- art.com/archives/001653.php (Last viewed on 26 January 2005).
- 67 -
Wouter Wiegmans Location-based Gaming
[27] About PacManhatten, http://pacmanhattan.com/about.php (Last viewed on 26 January 2005). [28] Pirates! http://play.tii.se/projects/pirates/index.html (Last viewed on 26 January 2005). [29] I Like Frank In AdeLaide, Blast Theory, Press Release, March 2004. http://www.blasttheory.co.uk/frank/press/ILikeFrankinAdelaide.pdf (Last viewed on 26 January 2005). [30] CitiTag. http://cnm.open.ac.uk/projects/cititag (Last viewed on 26 January 2005). [31] Vogiazou, Y., et al., ‘You got Tagged!’: The city as a playground. May2004. http://kmi.open.ac.uk/publications/papers/kmi_tr_139.pdf (Last viewed on 26 January 2005). [32] UnderCover, http://www.playundercover.com/index.jsp (Last viewed on 26 January 2005). [33] Uncle Roy All Around you, http://www.uncleroyallaroundyou.co.uk (Last viewed on 26 January 2005). [34] Björk, S., et al., Pirates! Using the Physical World as a Game Board. PLAY Research Studio, Sweden, Date Unknown. [35] Flintham, M., et al., Where On-Line Meets On-The-Streets: Experiences With Mobile Mixed Reality Games. Date Unknown. [36] Can You See Me Know? http://www.blasttheory.co.uk/bt/work_cysmn.html (Last viewed on 26 January 2005). [37] Benford., S., et al., Coping with Uncertainty in a Location-Based Game. In: IEEE Pervasive Computing, vol.2, nr.3, p.34-41, 2003. [38] Mogi, http://www.mogimogi.com. (Last viewed on 26 January 2005). [39] GunSlingers2, http://guns.mikoishi.com (Last viewed on 26 January 2005). [40] Unwired Factory, http://www.unwiredfactory.com/products.asp (Last viewed on 26 January 2005). [41] BattleMachine, Unwired Factory. http://www.unwiredfactory.com/pdf_documents/BattleMachine.pdf, (Last viewed on 26 January 2005). [42] TreasureMachine, Unwired Factory, http://www.unwiredfactory.com/pdf_documents/TreasureMachine.pdf, (Last viewed on 26 January 2005). [43] It’s Alive, http://www.itsalive.com/page.asp?sa=0&id=1069 (Last viewed on 26 January 2005). [44] BotFighters, http://www.botfighters.com/, (Last viewed on 26 January 2005). [45] It’s Alive, http://www.itsalive.com/page.asp?id=1075 (Last viewed on 26 January 2005). [46] It’s Alive, http://www.itsalive.com/page.asp?id=1080 (Last viewed on 26 January 2005). [47] GeoCaching, http://www.geocaching.com, (Last viewed on 26 January 2005). [48] Source Network and System Support for Games, Proceedings of the 2nd workshop on Network and system support for games. Year of Publication: 2003 [49] Human Pacman: a mobile, wide-area entertainment system based on physical, social, and ubiquitous computing / Cheok, A.D., [et al.].- In: Personal and Ubiquitous Computing, vol. 8 Issue 2, 2004 [50] SwordFish, http://www.blisterent.com/swordfish/index.html, (Last viewed on 26 January 2005). [51] Backseat gaming: expolaration of mobile properties for fun / Brunnberg, L. - In: Conference on Human Factors in Computing Systems CHI '02 extended abstracts on Human factors in computing systems, 2002 [52] Brunnberg, L. and Juhlin, O., Motion and Spatiality in a Gaming Situation – Enhancing Mobile Computer Games with the Highway Experience. The Interactive Institute. Date Unknown. [53] GizMondo, http://www.gizmondo.com/ (Last viewed on 26 January 2005). [54] Fahey, R., Gizmondo announces UK launch on October 29, GameIndustry, 13 September 2004, http://www.gamesindustry.biz/content_page.php?aid=4393 (Last viewed on 26 January 2005).
- 68 -
Wouter Wiegmans Location-based Gaming
[55] It’s Alive, http://www.itsalive.com/page.asp?sa=0&id=1058 (Last viewed on 26 January 2005). [56] It’s Alive, http://www.itsalive.com/page.asp?id=1113 (Last viewed on 26 January 2005). [57] Lehikoinen, J., et al., MEX: A Distributed Software Architecture for Wearable Computers. Proceedings of the Third International Symposium on Wearable Computers, pp. 156-157, IEEE Press, 1999.
- 69 -