Play
an adventure game |
||
Date Version Author |
||
|
Masterprogam of Mediatechnology, Leiden Institute of Advanced Computer Science, Leiden University |
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.
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:
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.
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:
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.
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.
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:
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 |
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.
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.
We also found this similar - more recent - development. The article to follow
is quoted from a
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.
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.
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.
Having done this project and the current realization, there are things to be done in the future to create a bigger and better application:
I'd like to put my thanks out to:
Contact information:
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
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
QuestML
http://questml.com
AXE's Quest, using Adventure Scripting Language (ASL) 3.11
http://www.axeuk.com/quest
eMbedded Visual Tools Downloads and Samples
http://msdn.microsoft.com/vstudio/device/embedded/download.aspx
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
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