Formal properties of distributed database sensor networks

Serious Gaming
Peter Waggett * , Helen Bowyer * , Steven Poltrock # , Mark Handel # and Katia Sycara %
*IBM, Emerging Technology Services, Hursley Park, MP137, Winchester, Hants. SO21 2JN, UK;
# PO Box 3707 MC 7L-49, Seattle, WA 98124, USA;
%
Katia Sycara, Robotics Institute, Carnegie Mellon University, 5000 Forbes Ave. Pittsburgh, PA, USA.
Abstract- A team that is actively collaborating
generates and exchanges information in a manner
that is often highly context dependent. Whilst the
information is meaningful to human team members,
it would generally be meaningless to a software
agent that does not share the context. The purpose
of our research is to investigate ways of
dynamically determining potentially meaningful
properties of the events and information flow
patterns in a collaborative networked team. A
specific focus is the way in which the interpretation
of the information exchange is aided by utilizing
existing information about the individuals involved
in the collaboration. This task also investigates how
software agents can use the same information to
determine their role in the collaborative task.
I. RESEARCH SUMMARY
This research is based on monitoring the
collaboration of teams using Metaverse
environments. The use of a Metaverse
environment as a research vehicle can extend the
concept to a richer environment including spatial
information.
There are several reasons why we are pursuing
this option. The first reason is familiarity,
especially in the context of combatants in future
conflicts. The field of computer gaming has risen
to near equal status with the film and music
industries in terms of revenue, customers, and
employees (Kirriemuir, 2002). Indeed,
Jayakanthan (2002) likens the influence of the
computer gaming industry on youth today to the
influence of music, religion, and politics in
previous decades.
are linked [1]. Multiplayer games are built
around the same concept of electronically linking
participants and displaying them together in the
same virtual space. Virtual teams in both
network centric warfare and multiplayer games
create shared situational awareness through the
sharing of information and through goal-directed
collaboration. They also cut across hierarchical
lines by empowering and expecting
knowledgeable entities to “collaborate with one
another to achieve a degree of selfsynchronization”
[1].
For these reasons we believe that the established
use of Computer games in military training and
education outlined in [2] can rapidly and easily
be extended into military collaborative research.
An existing IBM framework for studying instant
messaging will be extended to facilitate the use
of text analysis and data mining techniques
(associations and sequential pattern analysis) to
identify the common threads and topics of
conversation and the information flow structures
that emerge within a collaborating team. This
framework will then be further expanded to
include monitoring of communication in a
Metaverse environment. Using the derived
patterns of information flow, the task will
investigate whether coherency of communication
patterns can be used to increase shared
understanding between human and software
agents.
The second reason is the close affinity of
Network centric warfare (NCW) and multiplayer
computer games. NCW describes an
environment where “geographically or
hierarchically dispersed, knowledgeable entities”

II. METAVERSE LANDSCAPE
The Metaverse concept emerged in the early
1990’s (e.g. Stephenson, 1992). The idea that
simulated environments become completely
immersive and compelling (and therefore a good
simulation of real life) has become more
practical as graphical fidelity and modeling tools
have delivered more faithful renditions. However,
each metaverse system is a compromise between
three distinct and conflicting dimensions detailed
in Figure 1.
the perspective of their use in our planned
research and may not be appropriate evaluations
for other uses. For example, a major issue with
America’s Army is associated with the licensing
conditions that may be less onerous for some
other applications.
Collaborative
Capabilities
Command
and
Conquer
Second
Life
Battlefield America’s
2 Army
M H H H
Collaboration
Fidelity of
Simulation
M L H H
Visual
Appeal
Model
Accuracy
Ease of
Instrumentation
M H H L
Figure 1 Metaverse constructs
The highest degree of object fidelity is achieved
by CAD/CAM modelling tools, but these are
difficult software packages to learn and use.
Commercial games provide high levels of visual
appeal, usability and playability. Collaborative,
social network packages (e.g. Second Life)
provide a high degree of collaboration but have
limited capabilities to model objects and poor
visual appeal.
To provide a simulation environment that will
help us answer our research questions we have
been looking for a game environment that
combines acceptable visual appeal with a good
collaboration framework. Model accuracy must
be good but may not need to be spectacular.
Tactical
Simulations
Strategic
Simulation
Table 1 Relative game ratings
M M H H
H L M M
Figure 2 provides representative screen shots for
the games.
Command and Conquer
America’s Army
We conducted a short-listing process across all
the candidate systems identified to reduce the
total down to a final group of the four best
matched games for the detailed evaluation.
The final four games were:
Battlefield 2
Second Life
Command and Conquer: Generals
America’s Army
Battlefield 2
Second Life
Our evaluations of each game on five criteria are
listed in Table 1. The games were evaluated from
Figure 2. Screen shots of the games
On the basis of the evaluation we decided to
pursue the Battlefield 2 game as our highest
priority. The following modifications have been
implemented.

III. PLANNING PROGRAM
A significant element of the proposed research
questions will be associated with how well (or
otherwise) teams are able to plan and re-plan
during an exercise and how well they can follow
the plans. We require a planning program for
Battlefield 2 with specific requirements. The
basis of this program is the planning program
produced by Foolish Entertainment. This
program can be used by the teams before and
during the exercise to produce an action plan.
This outputs an image at the end of the session as
well as having assigned job roles to the squad
members. We can capture these images for later
comparison with actual actions and routes.
FEATURES OF THE PLANNING PROGRAM INCLUDE:
• Extremely easy too use. It is possible to create
detailed tactical plans within minutes.
• There is a wide selection of tools for creating
tactics.
• The tool provides great overview images of the
12 official maps in Battlefield 2.
• It can be connected with up to 16 teammates on
a dedicated or listen server.
• Custom made pictures can be added with the
Custom Map Wizard
• Squads can be created and managed before
starting the game
An initial idea of one use of the collected data is
to plot the location data onto an image of the
plan to see how closely the team followed their
plan.
Figure 4. Individual Plan
IV. CAPTURING INFORMATION
We have enhanced pre-existing MQTT broker
systems to receive messages passed out of
Battlefield 2. As Battlefield 2 can run python
scripts, this provided the framework to link
together the two technologies. A class was
created in python to publish and subscribe to the
broker. This provided the technology to publish
messages out of Battlefield to be used in a
variety of other programs. This bridge is the
basis of our data capture system.
Information within Battlefield 2 can be accessed
via a series of events that are triggered during
game play. Because the events are triggered
within the server, we can add scripts to the server
machine that record all players’ information
without accessing their computers. These events
cover a wide variety of situations within the
game. The initial set of information that will be
collected is documented below, although this is
by no means a complete list. For the later
experiments this list will be extended to track a
wider range of events. Because all this
information is exported to our Messaging Broker,
different analyses can be carried out on different
data sets by simply subscribing to different data
sets.
V. CURRENT EVENT’S CAPTURED
Figure 3. Planning Information Interface
LOCATION AND ROTATION OF PLAYERS.
It is possible to track the location and orientation
of users’ avatars - at a fixed time interval that
can be modified to enable us to provide

information at a rate dependent on the needs of
the experiment.
physicalObject.getPosition() &
physicalObject.getRotation()
This tracking can be processed for all users
currently playing on the server using the
following code.
for p in bf2.playerManager.getPlayers():
person = p.getVehicle()
position = person.getPosition()
rotation = person.getRotation()
broker_publish("Name:%s Position:%s
Rotation:$s"%(p.getName(), position, rotation),
"/battlefield2/pos/%s"%(p.getName()))
Position coordinates are specified by a threeelement
tuple, (X, Y, Z).
These coordinates spell out a position along
three axes:
The X value tells how far east or west an
object is; moving further east causes X to
increase, moving further west causes it to
decrease.
The Y value tells your altitude; as you go
higher, Y increases.
The Z value tells how far north or south
an object is; moving further north causes
Z to increase, moving further south
causes it to decrease.
In BattleField 2 the origin of the coordinate
system (0, 0) is at the point in the very center of
the map. Each unit in the coordinate system
equals approximately 1 meter in the game world.
Rotational orientation (attitude) is specified by
another three-element tuple, (A, P, R). A
("azimuth", also known as "yaw") gives rotation
from due north going clockwise (if A is positive)
or counter-clockwise (if A is negative), (or, the
amount our viewpoint is rotated around a vertical
axis passing through our viewpoint) measured in
degrees:
P ("pitch") tells how much we're tilting down
compared to horizontal, (or, the amount tilted up
or down along the axis passing through our
viewpoint from left to right) measured in degrees:
P=0 means horizontal
P=45 means tilting down halfway
between horizontal and vertical
P=90 means looking straight down
P=-45 means tilting up halfway between
horizontal and vertical
P=-90 means looking straight up
R ("roll") is the amount that the viewpoint has
rolled around an axis passing from the back of
our viewpoint through the front of the viewpoint,
measured in degrees:
R=0 means no roll
R=45 means viewpoint is rolled counterclockwise
by 45 degrees
R=-45 means viewpoint is rolled
clockwise by 45 degrees
CHAT MESSAGES.
ChatMessage(playerId, text, channel, flags)
Channel is "Squad", "Team", ,"Global",
"ServerTeamMessage" or
"ServerMessage".
Text is the text of the message sent,
prefixed by
"HUD_TEXT_CHAT_TEAM" or
"HUD_TEXT_CHAT_SQUAD" if the
message is sent to the Team or Squad
channel; there is no prefix if it is sent to
the Global channel.
PlayerId is -1 for all server messages.
If the player sending the message is dead,
their message is also prefixed by
HUD_CHAT_DEADPREFIX. (Strings
such as HUD_TEXT_CHAT_TEAM,
HUD_CHAT_DEADPREFIX, and so on,
are used as keys by the game engine to
match and replace with localized text.)
A=0 means due north
A=90 means due east
A=180 means due south
A=270 means due west

ecause a player has died, or because a
player has picked up a different kit.
PLAYERS SCORE
PlayerScore(playerObject, difference)
Difference is change to player's score
(positive or negative)
PLAYER SPAWNS/DIES
PlayerSpawn(playerObject, SoldierObject)
Occurs when a player spawns, and
associates a playerObject "spirit" with a
soldierObject "body".
PlayerDeath(playerObject, soldierObject)
This event occurs when a player is
decisively dead, and cannot be revived;
they will only return to the game by
respawning.
SoldierObject is the soldier "body"
(which is now discarded) for the
playerObject "spirit" (which will persist
through the next spawn).
USER CONNECTS/DISCONNECTS
PlayerConnect(playerObject) fires when a
player connects to the game.
PlayerDisconnect(playerObject) Player
has disconnected from the server.
VI. DATA AND TEXT ANALYSIS TOOLS
Figure 5. Scenario and Captured text file illustrating captured
text and positions
ENTERING AND EXITING A VEHICLE
EnterVehicle(playerObject,
vehicleObject[, freeSoldier])
Player represented by playerObject has
entered the vehicle represented by
vehicleObject. "freeSoldier" is 1 if the
player is a passenger of the vehicle and is
able to use weapons/objects of his kit.
ExitVehicle(playerObject, vehicleObject)
Player has exited a vehicle.
PLAYERS KIT
PickupKit(playerObject, kitObject)
Player has picked up a kit. This occurs
both when a player physically picks up a
kit, as well as when a player spawns.
DropKit(playerObject, kitObject) Player
has dropped a kit; can occur either
We are continuing to extend and enhance the
analysis tools available for the captured chat and
textual information required for this work.
Details of these tools and the analysis of data
from the experiments will be provided as a part
of the presentation
VII. VALIDITY OF THE PROPOSED SIMULTIONS
As outlined in the introduction, we were
challenged by the tasks associated with the
selection, modification and deployment of the
proposed simulation environment and the
timescale needed to plan and run intensive
experiments. To ensure that we will be able to
achieve the planned progress we concentrated on
running a series of demonstrations for a range of
IBM staff with relevant military or gaming
experience. The purpose of these experiments
and the demonstrations was to validate our
proposed research against their experience and
knowledge.

The initial reports have been promising and
confirm that we are now capturing sufficient and
complete information sets to allow for a good
post mission analysis as well as highlighting
areas of deficiency in planning and execution.
The gaming community rates the game engine
and construction very highly (a point that is
validated by user reviews of the game published
on web sites). The IBM staff with military
experience observed that the game provided a
good simulation, but they criticized some
specific details. For example, the positions in
which weapons are held and some aspects of
troop deployment are nation specific and not
correctly rendered. As a follow up exercise we
studied a range of other games with the
reviewers and found that Battlefield 2 was no
worse than these alternatives In addition, the
rendering of the game on a flat screen and with
poor audible clues were obviously areas that
would cause the simulation to suffer compared to
a fully immersive environment. However the
conclusion from both camps was that simulation
would provide a valid challenge to a military
community and that the information sources we
are collecting would provide the basis for post
mission analysis to address the research
questions.
[3] Jayakanthan, R. (2002). Application of computer
games in the field of education. The Electronic
Library, 20(2), 98-102.
[4] Kirriemuir, J. (2002, February). Video gaming,
education and digital learning technologies. D-Lib,
8(2). Retrieved April 10, 2004, from
http://www.dlib.org/dlib/february02/kirriemuir/02
kirriemuir.html
The target environment we have developed will
be used to understand how we can capture,
interpret, and represent the mission, objectives,
plans, activities, and communication of a team in
a way that supports communication between
humans and agents. This will be undertaken by a
series of experiments over the summer of 2007.
Results from the data collected and analysed
during the Summer of 2007 will be reported in
the presentation.
REFERENCES
[1] Alberts, A., Gartska, J., & Stein, F. (1999).
Network centric warfare: Developing and
leveraging information superiority (pp. 5-6).
Washington, D.C.: C4ISR Cooperative Research
Program, Department of Defense, 1999.
[2] Bonk and Dennen (2005). Massive Multiplayer
Online Gaming: A Research Framework for
Military Training and Education – Advanced
Distributed Learning Iniative.