Play an adventure game
in Real-Life

 

Date
2003-08-27

Version
2.4

Author
Jeroen van de Merwe

 
 

 

Masterprogam of Mediatechnology, Leiden Institute of Advanced Computer Science, Leiden University

1.   Abstract

For my graduation project, I built a game engine that runs on a Personal Digital Assistant (PDA). Interfaced with a Global Positioning System (GPS)-device and a game description file, a gamer can play an Adventure on and off the streets using his/her physical presence to control the game character.

First a game description had to be loaded into the game engine. Then the game starts. It begins at a certain starting position. From that point on, the gamer finds himself inside an Adventure Game. It could be the gamer gets a voicemail message containing a hint or the gamer has to be in the city center within 40 minutes. In that last case, the gamer has to go to that location in order to receive a next hint or assignment.

Every location in the game is described in a game file. That file contains all the information needed to run the game. Every location and every inventory object is defined.

Every time the gamer is moving, the GPS-device gives the game engine new information about the whereabouts of the gamer. When the gamer is in a known location, the game engine checks the conditions where the gamer is in and then decides to take action or not. An action could be the next assignment or a new hint for the current assignment.

To complete the whole assignment the gamer has to go to various locations throughout an area and hopefully had the feeling to be part of the Adventure Game.

This article describes a platform for a new way of gaming; physically play an Adventure Game with a virtual game character.


2.   Introduction

The project described in this paper was carried out as a graduation assignment for the Masters program of Mediatechnology. The goal for the project was to create something that involved:

2.1.  The Concept

Starting off with the project we formulated a few basic initial thoughts.

Together with the idea from the motion picture The Game [i] , the following concept was formulated:

Develop a real-life adventure game, where the gamer physically has to follow a storyline in the real world surrounding him. For this purpose the gamer has a kind of terminal that leads him through the game. The terminal runs the storyline, handles the communication with the 'physical' world and reports to the user on the progress made throughout the game.

To achieve this goal an outfit is created which holds the GPS-device and a mobile computer that runs the game. The gamer gets an overall assignment. This assignment can contain both virtual and physical concepts. For example the gamer can be a gun-carrying mobster and also receive information about a real-world building that he is passing during the game.

During the game the gamer gets various hints and new (sub) assignments through various media. For example the gamer can get a telephone call that tells him to go to a hotel in another city. The gamer than has to physically go to that place in order to receive a new assignment or hint. Through use of the GPS (Global Positioning System) module, it is verified that the gamer accomplishes this task. When the game is running over multiple days, the gamer can also receive messages or (fake) phone calls at a certain time when at home.

In short this idea for a Real-life Adventure Game is using multiple media to inform and direct the gamer through an adventure game in the real world. Hopefully the gamer experiences the game all around him/her.


2.2.  Project Goals

Right after the concept was formulated, we wanted to be able to play more than the one game with it. We wanted to make it more universal, to reuse the technical parts. The idea was to split the project in a file that described the game to be played and software to interpret that game file.

The next goals were set for the project:


3.   Technical overview

3.1.  Hardware

The gamer is equipped with a PDA, which runs the game engine. Therefore the PDA had to be capable of linking with a GPS and playing sounds to simulate phone-conversations or to give the gamer hints. Obviously there has to be a development environment available for the PDA

All of these criteria where found in the
Compaq 3800 series. That PDA runs the Pocket PC 2002 operating system. For this O.S. there is a development environment on the Microsoft Website (see references).
 

The GPS-device that is used in this project is the Garmin Etrex. To connect the Etrex directly to the iPaq PDA there isn't a standard cable available, but all parts needed to assemble such a cable are readily available in stores or can easily be assembled. This makes the developed gaming system usable by anyone and not just a lab-experiment. Both devices are handheld devices, making it fully portable, which is important when playing the game.

To be able to reuse this technology, we decided to not make one game that can be played, but to split the project in a game language and a game parser. This way it's possible to create additional games with the same hardware and the project is more universal. When a gamer has the technical components he can install the game engine and setup a game himself.
To accomplish this, we had to have a game describing language and parsing software.

3.2.  Game language

To be able to play a game, the parts of a game should be known to the game engine. Therefore a game is defined in a game language file.

To have full control over all things that the game engine has to be capable of, we designed our own game description language. We looked at some existing examples of game scripting languages, but they didn't meet our needs (see references). Based on every possible scenario that we wanted the game engine to be running, we made a list of things that needed to be in the game description:

These choices involved, writing a parser in the game engine to read the game file. It is a lot of work to write a parser, but when implemented, it's easier to change something in the game file structure and the parser than when you use a standard format like XML.
On the other hand, using XML offers a lot of compatibility for interfacing with other systems or platforms. But all things considered, we chose the new language.

The following is a brief example of a game file:

name = "Giving an example game file"
sound = main.wav

<inventory>
    <object>
        id = keycard
        image = keycard.bmp
        sound = keycard.wav
        available = 0
   </object>
   <object>
        id = cellphone
        image = cellphone.bmp
        sound = cellphone.wav
        available = 1
    </object>
</inventory>

<location>
        id = atHome
        name = Your workingroom
        image = homeroom.bmp
        sound = homeroom.wav
        gpsLat = 4250.5589
        gpsLong = 3221.5546
        radius = 10
</location>

<question>
   id = givTelNr
   ask = Give the telephone number
   type = open
   answer = 0703325536
</question>

<conditions>
   <if>
       object = keycard, available:0
   <then>
       object = keycard, available:1
   <else>
       message = You already have a keycard!!
   </if>

   <if>
      location = atHome
      question = giveTelNr
   <then>
      message = Your calling credits are updated!
</conditions>

The variables at the top of the file are initialization variables. These describe the name of the game, the start sound, etc. After that, the inventory is defined.

Between the <inventory> and </inventory> brackets are the separate objects. Each object that is going to be in the game should be defined in this section of the game file.  An object is described by its id, name, image, sound, value, what the object contains (for instance money or credits) and availability (0 – not available or 1 – available).

After the inventory is defined the locations are defined by the <location> and </location> brackets. A location is described by its id, name, image, sound and its GPS-coordinates. When the GPS-device is very accurate with the coordinates (see paragraph 3.4) the gamer has to be exactly on that position. To be a little more flexible, a radius can be defined to a location. The gamer than has to be in the radius of the given coordinates instead of being almost exactly on that position.

Finally, the <conditions>. These describe all the conditions the gamer has to meet to advance within the game. For instance, when a gamer enters a location he has to have a keycard or cell phone. Otherwise the game engine does not continue to the next assignment or hint. The gamer has to return to a previous location to obtain the required object. Also the conditions describe a time limit that is on a location. The gamer, for instance, has to be at a location before a certain timeslot or should enter the location within 50 minutes after arriving at the previous location.
The gamer could also be asked a question as a condition. In this example the gamer has to give the correct telephone number which is on a keycard. When the gamer gives the correct answer, the game continues. Otherwise the gamer has to go and look for the correct number.
There are two types of questions: open and multiple-choice. These are defined by type (open or mc). If it is a mc question, three additional fields are defined: aw1, aw2 and aw3. These are the possible answers that the gamer can give. The correct answer is in the answer field (mc: 1, 2 or 3).

In the conditions, it's also possible to check values of inventory objects. When an object has a value, a wallet for instance, that value can be checked by using operators like "<" and ">". Using these, it's possible to check if the wallet contains more than 20 dollars for instance.

There is also a possibility to setup time restrictions. The gamer can be faced with a condition that he has to be on the next location within 30 minutes for example. If he isn't he might be missing a clue or has to follow another route to be able to complete the assignment. Other time restrictions are timer and time. With timer it's possible to give a hint or next assignment after xx minutes of arriving at the location. Time simply defines an action that has to be executed when time and the actual time are the same.

Then there is a possibility to loose an inventory object. If you are for example in a city where there's a lot of crime, there is a chance you could loose your cell phone for instance. The odd that this could is defined in the game file by random.

With all these elements, a game is described and now has to be loaded into the game engine together with the mentioned image and sound files.


3.3.  Game engine

To create software that can load and execute a game file, we used the embedded tools from Microsoft with Embedded Visual Basic (eVB). This version of Visual Basic is a simplified version of Visual Basic 6. There a few differences in usage that where important to the development:

Globally, the engine (RALF) works as follows. First a game file is loaded. The file is parsed to have the inventory, locations and conditions installed in memory. When that is done, the starting point is loaded. This is the place where the gamer begins his/her game. The engine reads the actual GPS-position and stores that with the start position. When the gamer is instructed to go back to the starting position, this is where the gamer has to go back to.
After that, the GPS-device pushes new GPS-coordinates into the game engine every second. Each time this happens, the current GPS-position is compared to the coordinates of all the defined locations.

 

 

 

When a match is found, the system loads that location and begins to check the conditions that are applicable for that particular location. First there is a time-check, has the gamer entered the location before a certain time or is the location reached within the set number of minutes. When that condition is met, the object conditions are checked. Does the gamer have a cell phone or does an object contain a certain value. If those conditions also are met, a question is asked to the gamer – if one defined. When the question is answered correctly the actions that are defined are executed. This can be a next hint or the next assignment.

If one of the conditions are not met, the else actions are executed. This could mean a message saying the gamer has to go back to get an object or receives a secondary assignment leading to a secondary storyline.

 

 

During the game, the gamer can acquire new inventory objects or loose them. To see what he has and how much it contains there is an inventory screen. This shows every object that is in his possession.

Other screens are:

 

 

3.4.  GPS protocol

Photo courtesy U.S. Department of Defense

Global Positioning System is a system that is developed by the American Ministry of Defense. The system consists of 24 satellites, which are orbiting the earth at an altitude of 19.000 kilometers.

These satellites are transmitting a signal, which contains time (UTC) together with the location at which the satellite is positioned in relation to earth. The receiver needs al least three signals to be able to locate the position on the surface. With an optional fourth signal, it's possible to calculate height.

Depending on the weather conditions, the Etrex GPS-receiver can be accurate up to 15 meters. Inside buildings it's hard to pickup any signal from the satellites, so it's not possible to play a game inside a building.

When connected to the PDA, the GPS-device produces new GPS-data every second. This is by a standard format that was designed by the The National Marine Electronics Association (NMEA). This standard is the called the NMEA 0183 data protocol.

The following table shows the interpretation of the example:

$GPRMC, 092204.999,A,4250.5589,S,14718.5084,E,0.00,89.68,211200,,*25

Field

Example

Comments

Sentence ID

$GPRMC

 

UTC Time

092204.999

hhmmss.sss

Status

A

A = Valid, V = Invalid

Latitude

4250.5589

ddmm.mmmm

N/S Indicator

S

N = North, S = South

Longitude

14718.5084

dddmm.mmmm

E/W Indicator

E

E = East, W = West

Speed over ground

0.00

Knots

Course over ground

0.00

Degrees

UTC Date

211200

DDMMYY

Magnetic variation

 

Degrees

Magnetic variation

 

E = East, W = West

Checksum

*25

 

Terminator

CR/LF

 

4.   Similar Ideas

How does this project relate to similar projects and research carried out elsewhere? After an extensive search on the internet we have found the following projects to be related with ours some way or another.

4.1.  Spirit

Back in 1997 a group of students at the Uppsala University did a project with the name Spirit. The goal of this project was to build a location aware information system. The system is able to feed information to a person on foot in a city environment.

The system was built using portable modules and a central server. The portable equipment consists of a GPS-device, a PDA and two cell phones. One cell phone is used for the data communication and the other is used for audio communication. All of the portable modules are connected to the central server.

Then the GPS-device communicates his position every time to the central server. The server then associates available information sources with the real-world objects near to the user and presents that information to the user as speech. Extra information is given to the user through the PDA by images.

To demonstrate this system, the students have implemented an Adventure Game. In this game two contestants have to search for clues to solve a puzzle. The contestants sometimes have to be at different locations to solve the puzzle. The Spirit project is described on http://www.csd.uu.se/projects/spirit97/

This idea is very similar to the current project. Only the starting points are different. They start from a more information based point of view, whereas our project originated in the idea to create a Real-life Adventure Game.
Also the Spirit variant to the Adventure Game cannot be played by a single person. The power of the RALF project is that the gamer can play an Adventure Game and depends on nobody to be able to complete the game, because the game is running on the PDA and doesn't need a server, making it very portable and easy to play.

4.2.  GeoVector – Play Doom on the streets

We also found this similar - more recent - development. The article to follow is quoted from a New Zealand website [ii]

Japanese mobile phone users could be taking to the streets early next year to play shoot-it-up computer game Doom – thanks to technology developed in New Zealand.

GeoVector develops location-based services – using pointing technology. This lets people get information about objects, such as buildings, simply by pointing a mobile phone at them.

Pointing a phone at a movie theatre could, for example, prompt information about what films it was showing to be displayed on screen, along with viewing times and ticket prices.

Another application under development would let people point their phones to see if friends – with similarly equipped mobiles – were nearby.

Using this technology they are planning to create Real-life Doom. This new technology …

… lets mobile phone users battle it out with one another on the streets, using their phones to zap opponents and the screens on their mobiles to view the Doom environment.

To be able to give the information to the user who points to the building or statue, the information is stored somewhere. That part is similar to the RALF project. RALF is able to link information to the current position of the gamer and provides the gamer with it. The only difference is that the data is on the PDA itself and not, like this project, on a central server somewhere.

4.3.  GPSter – Waypoint Sharing

Then we recently heard about this project: GPSter. The basic idea of this project is to leave messages, images, audio, video or other links at a specific GPS-location for the next person who comes to that place.

The idea behind it is that everybody, in the near future, has access to mobile internet. When he comes to a location, it’s possible there is a message or some audio for him to read or listen to. It's also possible to leave something behind for the next person. All this information is stored on a central server in a database. The database is accessed through a unified format and also provides a link to already existing waypoint databases like geoURL (http://www.geourl.org).

This idea has the most similarities of the three ideas mentioned in this chapter. The RALF game-engine also works with waypoint data and accesses the data only when the gamer is on the defined waypoint. The only difference is, just like the previous idea, that the data is located on the engine running device instead of a central server.

4.4.  Overall

I think these three examples, with the RALF project, illustrate where the development is going in the future. It will spark a whole new kind of game types and a whole new game atmosphere.


5.   RALF in the future …

Having done this project and the current realization, there are things to be done in the future to create a bigger and better application:


6.   Acknowledgements

I'd like to put my thanks out to:

  1. Masterprogram of Mediatechnology, Leiden Institute of Advanced Computer Science, Leiden University
    for providing the location for Mediatechnology, at which I spent a lot of great times during the various courses

 

 

Contact information:


7.   References

7.1.  Books

Pocket PC, Handheld Pc –
Developers Guide with Microsoft eMbedded Visual Basic
Grattan, Nick
Prentice Hall PTR, 2002
ISBN 0-13-065077-3


Teach Yourself Visual Basic in 24 hours
Perry, Greg
Hettihewa, Sanjaya
Sams Publishing, 1998
ISBN 0-672-31533-5


Visual Basic Programmer's Guide to Serial Communications, 3rd Edition
Grier, Richard
Mabry, 2003
ISBN 1-890422-27-4

7.2.  Internet links

Handheld development, Using the eVB COMM control
http://www.devbuzz.com/content/zinc_evb_comm_control_pg1.asp
Knechtges, David
deVBuzz.com Inc., 2000-2001


Handheld development, eVB Treeview control and ImageList control
http://www.devbuzz.com/content/zinc_addNode_TreeView_Imagelist_pg1.asp
Mitchell, Carole
deVBuzz.com Inc., 2002-2003


Guidelines for Developing Successful Games
http://www.gamasutra.com/php-bin/login.php3?from=/features/20010815/shelley_01.htm
Shelley, Bruce
gamasutra.com, 2001


Playing a Wav-file tutorial
http://www.justppc.com/evb6.shtml
Saeed, Omar
justppc.com, 2001


Implementing a Non-Linear Story
http://www.gamedev.net/reference/articles/article244.asp
Howland, Geoff
Gamedev.net, 1999


Game Design: The Essence of Computer Games
http://www.lupinegames.com/articles/essgames.htm
Howland, Geoff
lupinegames.com


7.3.  Other Game describing languages

QuestML
http://questml.com


AXE's Quest, using Adventure Scripting Language (ASL) 3.11
http://www.axeuk.com/quest

 

7.4.  Develop environment

eMbedded Visual Tools Downloads and Samples
http://msdn.microsoft.com/vstudio/device/embedded/download.aspx

7.5.  Similar Ideas

Spirit
http://www.csd.uu.se/projects/spirit97/


GeoVector

article on Stuff >> Infotech
http://stuff.co.nz/stuff/0,2106,2547152a28,00.html

Pressinfo from GeoVector
http://www.geovector.com/press/pocketdoom.html


GPSter
http://www.gpster.nl

 


8.   Appendix I: A sample story line

This is the sample storyline that I made for the presentation on august 28th:

There are a few diplomas that are lost for the graduation ceremony on Friday. They seem to be on the parking lot. You have to find them and bring them to Martine.

This is the code to make the story work with the engine:

'made by Jeroen van de Merwe, august 27, 2003
title = Verloren bullen!
message = Er schijnen een aantal bullen voor de uitreiking morgen op het parkeerterrein te liggen ...\n\nGa die bullen zoeken.
log = Game started ...
startpoint = huygens

<inventory>
   <object>
     id = map
     name = Verloren Bullen
     image = bullen.bmp
     available = 0
   </object>
</inventory>

<location>
  id = huygens
  name = Huygenslab
  image = huygens.bmp
  gpsLat = 5210.1270
  gpsLong = 00427.4880
  radius = 100
  message = Je bent nu in het Huygens laboratorium. Ga de bullen zoeken ...
  log = In het Huygenslab
</location>

<location>
  id = liacs
  name = Liacs
  image = liacs.bmp
  gpsLat = 5210.1750
  gpsLong = 00427.4360
  radius = 150
  message = Je bent aangekomen bij het LIACS gebouw, vraag aan de balie naar de bewuste persoon
  log = Bij het LIACS
</location>

<location>
  id = bus
  name = Bushalte
  image = bus.bmp
  gpsLat = 5210.2170
  gpsLong = 00427.5150
  radius = 100
  message = Bij het bushokje, ben je nog op tijd?
  log = Bij het bushokje
</location>

<location>
  id = parking
  name = Parkeerterrein
  image = parking.bmp
  gpsLat = 5210.1860
  gpsLong = 00427.4780
  radius = 100
  message = Op het parkeerterrein, kan je de bullen vinden?
  log = Op het parkeerterrein
</location>

<question>
  id = vraagNaam
  location = liacs
  ask = Naar wie bent U op zoek?
  answer = Martine
  type = open
</question>

<conditions>
  <if>
    location = parking
    object = bullen, available:0
  <then>
    object = bullen, available:1
    message = Je hebt de verloren bullen gevonden, breng ze nu naar Martine in het LIACS gebouw.
    log = bullen gevonden
    runcount = 1
  </if>

  <if>
    location = liacs
    object = bullen, available:1
    question = vraagNaam
  <then>
    message = Martine is net weg, ze ging de bus richting het Centraal Station halen.
    log = Martine is net weg
    runcount = 1
  <else>
    message = Persoon is hier niet bekend
    log = Persoon niet bekend
  </if>

  <if>
    location = bus
    object = bullen, available:1
    maxtime = 5
    prevlocation = liacs
  <then>
    message = Je hebt het op tijd gered, Martine heeft nu alle bullen voor morgen.
    log = gehaald, spel afgelopen
    runcount = 1
  <else>
    message = Je bent niet op tijd, Martine is al met de bus weg. Neem de bullen nu zelf maar mee morgen
    log = niet gehaald, bullen zelf meenemen
    runcount = 1
  </if>
</conditions>


[i] IMDb.com movie database tagline: "Wealthy financier Nicholas Van Orton gets a strange birthday present from wayward brother Conrad: a live-action game that consumes his life."

[ii] http://stuff.co.nz/stuff/0,2106,2547152a28,00.html