GeoGames: Vigorous Outdoor Electronic Games BasedOn Geocast Messaging

Robert J. HallAT&T Labs Research

Florham Park, NJ, 07922, USAhall@research.att.com

ABSTRACTTraditional electronic games offer many unique advantagesmaking them attractive to a large segment of the popula-tion; however, their potential drawbacks are raising concernas well. Being tied to a central console or Internet connec-tion means physical movement may be limited and artificial,and game playing is usually limited to being indoors. Thesemay lead to negative health effects, such as poor physicalconditioning, repetitive stress injuries, and cognitive or so-cial deficits in children. GeoGames are electronic games im-plemented in a distributed peer-to-peer architecture usinga scalable ad hoc geocast protocol to implement inter-playermessaging. This design provides a low overhead messageaddressing primitive that is natural for this style of gaming.It allows us to design games for vigorous outdoor play any-where, including rural venues lacking network infrastructureand crowded venues such as campuses, stadiums, and down-town streets. This paper describes the GeoGames Archi-tecture (GGA), examples of implemented GeoGames, andevaluates GGA’s strengths and limitations.

Categories and Subject DescriptorsD.2.11 [Software Architectures]: Domain-specific archi-tectures; J.7 [Computers in Other Systems]: Consumerproducts

General TermsGeoGame Architecture

Keywordsgeocast, game, ad hoc, networking

1. INTRODUCTIONTraditional electronic games (e-games) offer many unique

advantages making them attractive to a large segment ofthe population. In particular, they offer virtual constructs,

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.FDG ’10 Monterey, CA, USACopyright 200X ACM X-XXXXX-XX-X/XX/XX ...$10.00.

like weapons, creatures, and structures, that interact withavatars in a virtual world to stimulate the imagination andchallenge players intellectually. The Internet allows playamong people scattered over the entire world, when thegame design and circumstances allow it. Such constructsand connectivity are not generally possible in older and al-ternative game technologies.

The allure of e-games, however, also leads to disadvan-tages, some potentially serious. Being tied architecturallyto a central console or Internet connection means physicalmovement may be limited and artificial. Furthermore, gameplaying is usually limited to being indoors. These inherentarchitectural features may lead to negative health effects forhuman players. Habitual strongly-limited physical move-ment for long periods of time can lead to poor physical con-ditioning. This in turn leads to a host of medical problems,including obesity, heart disease, and diabetes. Unnatural orartificial game control movement can lead to repetitive stressinjuries. Indoor play, while likely not in itself harmful, mayunduly substitute for outdoor play which, it is believed, maybe necessary for normal physical, cognitive, and social de-velopment in children.

Therefore, it seems a worthy goal to seek e-games thatrequire vigorous physical activity outdoors as an integralpart of the game and an indispensible element of the fun ofplay. Such games would provide the benefits of outdoor playwhile still incorporating the unique advantages and fun ofe-games, including virtual elements. We term this style ofgame a GeoGame, since geography is an integral part of thegame, taking place as it does partly in the real world.

The present paper makes the following novel contribu-tions. It first presents a novel GeoGame Architecture (GGA)that supports implementation of GeoGames on location-aware handheld computing devices. Critical to this archi-tecture is the use of a scalable ad hoc wireless geocast proto-col for inter-device network communications. Next, the pa-per illustrates GeoGaming and the GGA by describing twoGeoGames, iTESS and iTron, that have been implementedusing the GGA in a prototype running on iPhones. Thisillustration will describe key GeoGame design patterns. Fi-nally, the paper will evaluate GeoGames and the GGA bothby discussing how well they achieve overall goals as well asby comparing the work to related game architectures andother projects.

2. THE GEOGAME ARCHITECTUREThe chief obstacles to GeoGaming are the need for inter-

player communication and the need to obtain, power, con-

figure, and operate a central game server. When playingoutdoors, especially in rural venues like summer camp, apark, or even a large back yard, it is often the case that noInternet coverage exists; when playing in crowded venues,like campuses, stadiums, or downtown streets, even if In-ternet coverage exists it may not support a large numberof devices executing data-intensive applications. In thesescenarios, inter-player communication, particularly at highscale, is impossible or impractical. Given our desire for highphysical activity and outdoor styles of play, powering andcabling a game console is impractical, and inadequate com-munication support implies one cannot depend on all devicesbeing capable of reaching a cloud-resident game server.

The GGA is based on the following architectural ideasthat address these problems.

• Game control is assumed to be peer-to-peer and dis-tributed among handheld devices carried by players,

• Inter-device communication is based primarily on ascalable ad hoc wireless geocast protocol.

• When long distance network support is available, anoptional extension to the GGA supports a tiered geo-cast protocol that allows efficient play over long dis-tances.

The rest of this section describes these ideas in detail. Keydesign patterns useful in this architecture are defined andillustrated in Section 3.

2.1 Distributed ControlTypically, each player carries a single handheld device,

such as a location aware smart phone. GeoGames are in-tended to be portable and playable by children as well asadults, so we do not wish to require that someone carry alaptop or other console device in addition to their handheld.Beyond device considerations, however, we avoid as well dis-tinguished roles for devices, such as a central controller resi-dent on one player’s handheld, except under controlled con-ditions (such as game setup). This is because, in such adesign, whenever any player loses network contact with thedistinguished device, his game play would have to stop untilconnection were reestablished. In GeoGames, players movequickly around the terrain, so periods of disconnection areunavoidable and must be designed for in the game.

Thus, GeoGames must be controlled in a distributed fash-ion. In addition to the advantages above (no extra devicesand no stoppages of play due to connectivity outages), thisbrings limitations which will be discussed in Section 4.4.

2.2 Scalable Ad Hoc GeocastIn ad hoc networking[7, 4], packets are relayed peer-to-

peer between devices, without relying on dedicated routersor access points. This is appropriate for GeoGaming, sincewe wish to play outdoors and potentially in rural locationslacking network infrastructure. However, GGA cannot im-plement just any ad hoc architecture; clustered architec-tures, where distinguished nodes are dynamically elected toserve as routers, are inappropriate to game play. Playersmove around quickly and, in many games, purposely try toevade one another. Thus, any clusterhead node that hideswill lose connectivity to other player nodes, so any such thatdepend on the hidden clusterhead will stop working. As dis-cussed above, we need to avoid such dependence on distin-guished nodes.

Figure 1: Geocast ad hoc propagation

Clustering is primarily designed to facilitate IP routing,but a key observation is that GeoGame messages are mostnaturally addressed geographically. For example, a messagesimulating a projectile should be delivered to all devices inor near the effect area of the weapon, whether or not thesender knows the identities or IP addresses of those de-vices. A query message mediating simulated surveillancevideo should be delivered to all devices within the area “vis-ible” to the simulated camera. And a player’s game statemessage (e.g. notifying of a state change) should be sent toall devices in the game area.

For GeoGames, therefore, we can support geographic ad-dressing and avoid the need for IP routing. Geocast[4] isa protocol supporting sending a message to all devices cur-rently occupying a specified region in space, termed the geo-cast region. The sender includes a description of the geocastregion in the header of the packet, and the protocol arrangesto deliver it to the appropriate devices, if any.

There are many ways to implement geocast [5, 11, 6, 4].Each way has different advantages and drawbacks, but asurvey is beyond the scope of this paper (but see [2] for sucha survey). In the implemented prototypes discussed below,I have chosen the scalable ad hoc geocast protocol of Halland Auzins [4]. Its advantages include high scalability anda completely distributed design that has no distinguisheddevices. Justifying its claims of scalability are beyond thescope of this paper, but covered in [4] and [2], and summa-rized in Section 4.3.

Briefly, it operates as follows. The originator of a geocastpacket transmits it via a simple broadcast to all devices inrange. Each device hearing the packet then decides whetherto re-transmit it. This decision is based upon heuristic rulesoperating on packet statistics it obtains by listening to alltransmissions on the wireless medium. In this way, a sub-set of the devices present will retransmit the packet. Thedirectionality of packet flow is controlled through forward-ing zones that are defined for each packet type relative tothe positions of sender and geocast region. The heuristicsinclude count-based (ensuring a minimum number of re-transmissions in an area), distance based (transmitting ifthe node is far from all previous senders), and hill-climbingbased (transmitting if the node is closer to the center of thegeocast region than all previous senders heard). See [4, 2]

for details.Figure 1 illustrates this. Node B is the sender and he

wishes to get the message to all devices within the heavycircle. B broadcasts transmission 1, which is heard by Aand C. A does not retransmit, because it is outside of theelliptical forwarding zone. C retransmits, sending broadcast2. This is heard by D and E, one of whom also retransmits.

This design achieves flooding of the geocast region butwithout the high cost of other flooding algorithms. In stud-ies, with the given heuristic mix, we see approximately con-stant scaling of transmissions per geocast with node density.That is, adding nodes to an area (roughly) does not increasethe number of retransmissions.

2.3 GGA Extension: Tiered NetworkingUsing distributed control and scalable ad hoc geocast, it

is possible to implement many novel GeoGames. However,even though we must avoid requiring Internet connectiv-ity, it is a clear advantage to be able to exploit such if itis available. This would allow, for example, a GeoGameplayed with some players in one city and others in a distantcity across the country. For example, one half of a virtualvolleyball court could be mapped out on the ground in Cal-ifornia while the other half is in New York, with a simulatedball “hit” back and forth via the Internet, if both fields arewithin coverage of a wireless hotspot.

For this purpose, we extend the GGA with tiered networksupport. That is, in addition to participating locally in an adhoc network using the geocast protocol, some devices mayhave a connection to one or more other networks, say via a3G connection to the Internet or to a short range bluetoothnetwork. Hall and Auzins[4] describe a tiered geocast proto-col that supports geocasting in such structured networks.

Tiered geocast works as follows. Each logical network tierbehaves independently using a geocast implementation mostappropriate to its characteristics. For example, Figure 2 il-lustrates how this could work when some devices have 3Gconnections to fixed-location Internet routers. The shortrange tier is symbolized by the lower parallelogram, whilethe long range tier is the upper (light green) parallelogram,implemented over the Internet. The blue dots are devices;when two dots are connected by a vertical line, it denotesone device that has a 3G connection to a router in the Inter-net. In the figure, a sender (1) transmits a geocast destinedto the heavy red circle on the right. This is heard by node2, who both retransmits in the short range (ad hoc) tier andalso sends the packet to a georouter in the cloud. Since thelong range tier consists of fixed-location servers, it can usegeorouters that have databases mapping locations to IP ad-dresses. In this case, it finds the node in its databse closestto the geocast region and sends the packet to it (transmis-sion 2b). This node, also having an interface to the shortrange tier in its local area, retransmits on the short rangetier (transmission 3). Finally, another device hearing 3 re-transmits to all nodes in the geocast region (4).

This extension is termed the long range extension (LRE).Note that while its use requires long range capable devicesto be present, not all devices need be so. For example, it isenough for one member of the volleyball team to have a 3G-capable smart phone, while the other players on the sameteam have merely ad hoc WiFi capable devices.

2.4 Other Architectural Features

Figure 2: Tiered geocast propagation

While distributed control, scalable ad hoc geocast, andtiered geocast are the major new components, it is obvi-ous that any practical application framework implementingGGA should provide other supporting components. For ex-ample, GeoGames typically have user interfaces based atleast partially on maps with overlaid graphics to representpositions, effect areas, etc. There is also a clear need to sup-port mathematical calculations, including spherical trigonom-etry (e.g. lat/long and distance along Earth surface), com-putational geometry (segment intersection, ray tracing, lineof sight), and Physics simulation (trajectories, time-of-flight).The prototype GGA implementation described below incor-porates these and others; a full description is deferred to aforthcoming full version of this paper.

3. TWO GEOGAMESTo illustrate the capabilities of the GGA, we describe here

two GeoGame designs. While far from exhausting the spaceof interesting GeoGames, they do illustrate a significant coreof design patterns, as well as hinting at the potential ofGeoGaming to achieve our high level goals.

3.1 iTESSiTESS, based loosely on military training systems [8], can

be thought of as hide-and-seek with simulated weapons andsurveillance devices. (TESS is an acronym for Tactical En-gagement Simulation System.) In principle, the play area isthe entire world, but in practice, iTESS is played in an areacovered by one or more map displays. The goal of the gameis to survive the longest.

Players target each other with artillery by tapping a mapdisplay on the handheld and pressing the Fire button. Op-ponents’ positions are not displayed on the handheld by de-fault. If one sees the other person directly (i.e. in the realworld), one can try to point on the map and target by rel-ative position to landmarks; however, that is difficult to doaccurately. iTESS also provides each player an UnmannedAerial Vehicle (UAV) simulation for surveillance. iTESSUAVs are simulated small radio-controlled airplanes hav-ing look-down video cameras. They move slowly, and theirlook-down area is relatively limited (50 meter radius). Theuser commands their course using taps on the map displayto set waypoints. Once the UAV locates an opponent, thelocation is painted as a red dot on the user’s map display,allowing accurate targeting.

Figure 3 shows a screen shot from the iTESS implemen-

Figure 3: iTESS game situation display

tation illustrating these elements. Here, the blue dot is theposition of the player holding this device. His UAV is in-dicated in light green: the line shows its recent course, thecircle shows its look-down area. It has flown over one oppo-nent (upper red dot) and then over another on its way to thecommanded waypoint in the lower right. The blue shadedcircle over the upper red dot shows that this player has tar-geted that opponent and a shell is in flight. The targetingreticle (black circle with crosshair) containing the other op-ponent shows that this player is about to fire at the otheropponent.

Once an artillery shot is fired, there is a delay simulatingthe fact that artillery shells take many seconds to reach theirtarget. During this time, players near the target area havered circles painted on their displays warning of the incom-ing round, simulating having radar to detect in-flight shells.Two such are shown in Figure 3 indicating two in-flight shotsthat will narrowly miss the player. If a player can run out ofthe effect circle in time, the round will miss. Thus, iTESScan provide a strong incentive for vigorous physical activityin addition to the stealthy movement over terrain at othertimes.

Note that iTESS is designed and implemented so thata single player can play on multiple map displays concur-rently. Of course, his position will only appear on one ata time (unless they overlap geographically), but he can useindependent UAVs on the maps to search for opponents andtarget them with fire. If the LRE is in use, then these mapscan be across town or across the world from each other.

GeoGame Design Patterns in iTESS. iTESS shots illus-trate perhaps the most basic design pattern. DP1: To sim-ulate a projectile (weapon round, ball, whatever), one sendsa geocast to an area covering all devices that might be af-fected by the impact of the projectile. The devices computea suitable desired flight time and after that time has passed

Figure 4: Seven player iTron.

since the launch time (present in the geocast packet), im-pact/arrival effects are carried out. In iTESS, we geocast toan area 3 times as large as the 20 meter effect radius of thesimulated shell. This accounts both for nodes in the effectarea and for those immediately outside it that move into itduring the 12 second flight time. If we expect players touse vehicles, scooters, bicycles, etc, we may wish to enlargethis geocast region (via pregame configuration) to accountfor faster movement.

iTESS UAVs illustrate a two-message GGA design pat-tern. DP2: To simulate a geographic query and response,geocast a query message to the area of surveillance; any de-vices in the area receiving the query message geocast a re-sponse message to a circle around the position of the queryoriginator. The size of that circle should be large enough toaccount for largest possible movement of the originator dur-ing the (brief) query-response latency time (a few secondsat most).

iTESS scoring illustrates another design pattern. DP3:fully distributed scoring can be implemented by having eachdevice judge its own damage based on incoming shots and itsown position over time; it then advertises its score (or game-over status) periodically via geocast to the game area. Al-ternatives to DP3 include having the shooter keep track ofwhom it hits, or a distinguished device doing so for all nodes.The advantage of DP3 is that as soon as a node should bedisabled by taking fire, it can do so, keeping it from spuri-ously sending shots that may unfairly affect other players.The delays involved in alternative scoring approaches leaveopen the possibility of such unfairness.

3.2 iTroniTron is based on one of the old Tron video games and a

family of related games (such as Snake). The idea is thatplayers’ positions are depicted on a map display. A virtual

game stadium is declared and players within it can join.Once the game starts, as players move, they leave a “tail” ofsolid virtual wall behind them. The object is to survive thelongest without crashing into a wall. Players are compelledto move at a minimum speed or else their tail catches upand hits them. In a team variant, players on the same teamcan move through their type of wall but not the opponents’.

iTron is played with the human players supplying themovement by running or walking. The location-aware hand-held measures position in real time. Its display shows themap, opponents’ positions, and walls as they are built. Ob-viously, this requires vigorous physical activity. In fact, themore vigorous, the better are one’s chances of winning; acommon strategy is to surround one’s opponents in as smallan area as possible. To do this, one needs to outrun them.

Figure 4 shows a screen shot from the implementationdepicting a seven player instance of iTron. It can be playedon any size map, though at larger scales it becomes difficultto see what is going on when players are close together. Ofcourse, iTron need not necessarily be played on foot: playerscould skate, ride bikes or, as in the movie, ride motorcycles(lightcycles, actually). Faster movement will make largermaps easier to use. Any player may declare a stadium andgame start time by tapping and dragging between oppositecorners of the rectangle on the map and then tapping Join.Declared games appear on other players’ displays, allowingthem to join by “tapping in” using the Join button.

The devices periodically (e.g. once per 2 seconds) takeposition fixes using the built-in location framework of thelocation aware smartphone. After each new fix, the devicecomputes whether the latest tail segment crosses any othersegment (either its own tail, an opponent’s tail, or a stadiumwall). If it computes that an intersection has occurred, itmoves to the game-over state and broadcasts its final dura-tion in-game. The winner is the unit lasting longest.

GeoGame Design Patterns in iTron. iTron game statemessages illustrate DP4: to keep all units updated on sharedgame state, periodically geocast the portion of the statemeasured/tracked by the device to the area of the gamewhere devices affected by it may be; devices in the samegame (defined uniquely by originator ID and game starttime) receive and update their own representation of theopponents’ state, taking action as necessary on the new in-formation. In iTron, these game state messages include thegame definition information (lat/long of southwest corner,width, height, originator’s ID, and game start time) andthe player’s current game state (declaring, playing, game-over) and its tail segments. Tail segments are represented inCartesian meter offsets based at the player’s current lat/longposition. In the prototype, the maximum tail size is 100 seg-ments; this is adjustable, but it is desirable to keep the totalstate message small enough to fit within one network frame.

iTron also illustrates DP5: in order to arrange for play-ers to setup and agree on a common game definition witha defined start time, geocast game forming messages to ageocast region covering the declared stadium and the imme-diate surroundings. We include surroundings so that otherplayers may see the game and move into the stadium to join.Note that iTron games are declared with an absolute starttime, so that all players will start at the same time, assum-ing their clocks are synchronized. (We assume reasonablygood clock synchronization here, within 2 seconds, as thisis relatively easy to enforce.) This avoids the need for some

more complex game start handshake, which might be diffi-cult to implement if players move away from each other anddrop out of mutual contact.

Note that iTron also instantiates DP3 for scoring, in thateach device scores itself and reports game-over for its playerby geocasting result messages.

4. EVALUATIONThis section discusses scaling studies, the prototype, and

experience related to the GeoGame Architecture and Ge-oGaming.

4.1 The PrototypeiTESS and iTron are implemented together as separate

modes of an application (app) for the iPhone 3G, using≈ 8000 lines of Objective-C code. Geocast is implemented(according to the principles of [4, 2]) using UDP broadcastsover WiFi. The prototype app also implements a GeoTextInbox mode which displays text messages received by thedevice via geocast. This is where scoring and game overmessages are read. It also supports player-to-player messag-ing, such as taunting or collaboration.

While the prototype is largely successful, it has a fewquirks stemming from restrictions imposed on conformingapplications by Apple. First, it does not seem to be possi-ble to achieve true ad hoc networking using iPhones alone.Instead, to set this up, one needs to create an ad hoc net-work using, for example, a Macbook laptop; one then selectsthis network with each iPhone. One can then shutdown thelaptop and put it away and the iPhones will continue tocommunicate with each other in this way indefinitely. Thissituation is likely to be fixed when devices implement theWiFi Direct standard [9], which is a forthcoming standardfrom the WiFi Alliance for ad hoc WiFi.

Second, the iPhone’s location system requires connectionto 3G towers to operate at all. This is disappointing, asmany cheap commercial GPS receivers exist that could pro-vide location without it. For example, the OneTESS system[8] (discussed below) player units had onboard GPS unitsachieving sub-10-meter accuracy without any infrastructuresupport. The 3G dependency is a limitation of the currentiPhone system that can and likely will be eliminated in fu-ture devices.

Third, Apple prohibits conforming apps from altering net-work stack code, so the geocast implementation is not asefficient as possible. Hall [2] and Hall and Auzins[4] dis-cuss the efficiency of late cancellation, which is a techniquerequiring simple code alterations at the MAC layer. Thisefficiency difference is not noticeable at small scale trials,but likely will become important for normal larger scale us-age. This coding may be easier in more open smart phonearchitectures like the Android OS[1].

4.2 Preliminary Experience and FeedbackI have organized several trials of both iTESS and iTron

with 2 or 3 players per game. In some games, all players wereadults; in others some of the players were teenage boys. Foreach game, I used the process described above to setup adhoc networking among the iPhones and then put away thelaptop. For some runs, a second laptop was also attachedto the ad hoc network and used to passively collect packettraffic for later analysis. In one run, I used laptops connectedvia the Internet to play iTESS using the GGA LRE, with

a handheld device in each of two locations that were notwithin WiFi contact. All runs were successful in executingthe games and generally functioning as intended.

High level goals. Users found the games playable and re-ported them to be fun. iTESS was easy to start playing, withno observable difficulty in catching on to game play, thoughdeveloping strategies took a bit longer. On the other hand,for some, iTron was initially difficult to play, but with prac-tice players learned to dynamically map from the display tothe real world in order to improve wall avoidance.

iTESS and iTron both did involve players in vigorousphysical activity. iTESS led to walking and running overterrain to alternately hide and stalk opponents, as well asflat out running when a player was targeted by a shot. (Theyhad to run ≈ 30 meters in less than 10 seconds to reliablyavoid the shot.) iTron was even more strenuous. Players jogthrough most of the game, but as players near each other,they typically sprint to try to cut others off from the largerareas.

As stated above, the games were played using ad hocWiFi networking, that is, not within coverage of any WiFihotspots, and with the network setup initially using the lap-top which was then turned off. Also as stated, however, wehad to play within 3G coverage so the Apple location frame-work functioned. The 3G network was not used for any otherpurpose, so the trial did demonstrate ad hoc operation.

The teenage trial users proposed several innovative ideas,including playing iTESS using a scooter or bike (makingtargeting harder and escape easier), playing iTESS at night(a cool variant making UAVs even more important), andwearing the iPhone in the wristband (less awkward).

Thus, in summary, both iTESS and iTron achieved thehigh level GeoGame goals of being fun and naturally incent-ing players to engage in vigorous physical activity. It alsodemonstrated the most important aspect of playing outsideof Internet connectivity, since the 3G coverage was used onlyfor location and not to contact a game server in the cloud.Of course, sample sizes in the initial trials are small, so theseresults must be viewed as preliminary.

Other observations. There were a few problems foundthat are worth commenting on. The iPhone location frame-work is typically accurate only to around 9-17 meters. Inpractice, this means that location fixes are somewhat in-consistent with respect to the real world movement of theplayer. In iTESS, this can mean that one is hit by a shoteven though it seems subjectively that one actually did runfast enough. While this occurred infrequently in the trials, itis easily fixed by adjusting the effect area radius of the shots.Also, users would run faster to compensate. The effect iniTron is that it is possible for the device to judge a crashwhen none occurred. For example, if two players run side-by-side 1 meter apart, fairly soon one will crash. Playersquickly learn to compensate for this by leaving more spacebetween themselves and walls. This compensation “halo”was only a few meters (much less than the 9-17 meter inac-curacy estimates above), so it was not detrimental to gameplay.

Another problem we noticed stems primarily from 802.11physical properties. Operating at 2.4 GHz, WiFi is espe-cially vulnerable to line of sight obstacles and Fresnel zonelosses due to ground skimming angles. When a player runsdown a hill or around a large building, the device will likelystart to miss packets transmitted from up the hill or the

other side of the building. Geocast largely compensates forsuch losses through controlled redundancy, but we still expe-rience lost packets. In iTESS, this can result, for example,in a missed shot that should have been a hit. It can alsoaffect the UAV semantics, but since the UAV queries arerepeated at a high rate (about 1 per second) it is much lessnoticeable. This problem does not seriously damage playa-bility. First, our trials were under near worst case conditionsfor this problem, having only 2 or 3 players; as the numberof players (hence devices) present increases, packet loss willdecrease dramatically, because there will be more opportu-nity for relaying. Second, network connectivity becomes aplanning element in the play as well, once players under-stand what is going on. Thus, rather than just locatingone’s opponent, one can also try to seize favorable transmis-sion angles to better ensure the shot will reach him. Theeffect on iTron is much lower, because each status messagecontains a full state description of the player, and they aretransmitted twice per second. If one or a few are missed,the state will be recovered immediately when the playersget back in contact. When they are out of contact, theytend to be far apart, so frequent updates are less important.Also, it was observed in iTron only when the stadium wasrelatively large; in small flat areas, packet losses were notnoticeable.

4.3 Scaling StudiesThe geocast protocol has been studied in three papers,

[2, 3, 4]. It has been shown in simulation to achieve veryhigh reliability on scenarios up to 1290 devices[4] in denselayouts. The critical metric for scalability is transmissionsper geocast, that is, the number of transmissions of copies ofa particular geocast packet. One usually studies this metricin scenarios where all devices can receive transmissions fromeach other. The key result from this work is that this metricincreases very slowly or not at all, depending on the detailsof the scenario. This behavior has been found in simulation[4, 2], and a field trial involving 60 units[3] of a differentgeocast-based system showed this same scaling behavior aswell. Thus, we believe the geocast protocol will scale to hun-dreds or thousands of units based on the evidence availableso far.

The numerical value of the metric differs between simula-tion and built prototypes, because modeling cannot captureall details of real world systems. In all trials and studies ofthe iPhone prototypes, for given particular (preferred) pa-rameter settings, we have measured this metric between 4and 5 transmissions per geocast. This is consistent with thevalues measured in prior studies.

GeoGame scalability depends not only on the protocol it-self, but on how it is used. In iTESS, geocasts are veryinfrequent, except that UAVs send query messages once persecond and each unit in the UAV look-down area will re-spond to each query. Thus, the pathological worst casewould be if every unit were in the UAV look-down area forevery other unit, which would lead to n(n − 1) geocasts,leading to kn(n−1) total transmissions per second, where kis the value of transmissions per geocast for the implementa-tion. However, such a game would not last long, since every-one would immediately fire, causing either end of game orplayers scattering out of the area. In either case, the trans-mission rate would quickly drop to linear in number of nodes(or lower). The typical case would be each node operating

a UAV but tending not to get responses most of the time.This leads to a linear number of transmissions per second.

In iTron, devices simply geocast 2 game state messages persecond. The typical cost of this will be 2kn transmissionsper second, again linear.

4.4 LimitationsRunning and dodging while looking at the device display,

as well as while trying to perform user interface gestures,adds a new dexterity challenge to physical games. Learningto do this can, obviously, be part of the fun, but it is chal-lenging to keep it from being a burden with negative impacton the game experience, such as when tripping over a rockand breaking one’s iPhone in the fall. Thus, it is likely thatgames requiring complex screen-focused user interaction riskbeing less successful as GeoGames. To address this concern,the iPhone can be worn in a wristband (as suggested bya trial user) with a plastic transparent pouch like the onesquarterbacks use for play lists. This keeps the iPhone saferbut limits somewhat user interaction. It is better for iTron(which has no user input gestures once play starts) than foriTESS.

The combination of distributed control and dynamic net-work topology, where nodes can sometimes drop out of net-work contact with others, is less powerful functionally thancentralized control with constant connectivity. This is be-cause of time lags in updating state information that multi-ple devices depend upon. For example, suppose a game hada“power-up”treasure that, if found and picked up, increasedthe health of a player. Moreover, assume that once picked upit cannot be picked up by any other players. Suppose player1, while out of network contact with player 2, picks it upand then moves away. Later, player 2’s device, not havingreceived any messages from player 1, believes the power-upis still available, so picks it up. Now game semantics is vi-olated, as player 2 may be able to use the added health tosurvive long enough to damage player 3. If the power-up se-mantics (disappearing after player 1 picked it up) had beenobserved, then player 2’s health would have expired beforeplayer 3 was damaged. A central architecture could enforcethis semantics, but the distributed architecture is vulnerableto this sort of problem, which must be consciously avoidedin game design.

User interface design is a challenge, as the only view on thevirtual world is via the small handheld’s screen. In iTron,for example, the user must mentally translate the virtualconstructs into spatial knowledge, such as whether to turnleft or right to avoid an obstacle. Adding an augmentedreality (AR) display that draws the walls on top of the realtime video camera feed would help, but the game would stillrequire running while looking at the device, and the viewwould be limited in angle and resolution.

In both iTESS and iTron, as the map display covers moreterritory, it is harder to see scaled features; and yet a scalabledisplay (e.g. by implementing the well known pinch andspread gestures) would then require the user to do fine screenmanipulations while running and possibly with cold fingers.Work remains to be done on improving this aspect.

4.5 Related WorkThe geocast protocol used in this work is a variant of the

Classic Geocast protocol of [4]. The latter was developedto support the OneTESS military training instrumentation

system[8]. In OneTESS, soldiers wear small 802.11+GPSenabled computing devices, termed player units. They alsocarry and operate instrumented weapons and systems. To-gether the OneTESS components simulate weapon firingsand damage during realistic training exercises. OneTESS isdesigned to be operated in battlefield venues and conditions,necessitating both the ad hoc design of geocast and its fa-vorable scaling (training exercises can involve thousands ofsoldiers). A critical requirement of OneTESS was high re-alism and fidelity to real time performance of the systemsbeing simulated. iTESS, which is also thematically a mili-tary weapon simulation, differs from OneTESS signicantly,due to being designed for fun and playability as the over-riding requirement. Thus, OneTESS does not have UAVsimulations commandable by all players, because militaryUAVs are not operated in that way. iTESS’s artillery sim-ulation is uniform and very easy to target/fire compared totrue weapons, which OneTESS simulates. Also, detectingincoming shells, as is provided in iTESS, is not available tosoldiers in OneTESS, because this capability does not existin this form in the real world. Similarly, it is acceptablefor iTESS players to plan for network connectivity as partof strategy, whereas this would violate the training require-ments of OneTESS. iTron is, of course, completely unrelatedto the military system and context.

Other military game systems include laser tag and paint-ball. These technologies are not GeoGames, because theycannot include virtual elements like UAV simulations anddynamically built walls. Of course, laser tag players couldcarry iTESS handhelds to create an enhanced iTESS Ge-oGame.

Most electronic games use the central server architecture,where game logic is controlled by a single central compu-tational process, whether it resides on a game console or aserver in the Internet. As discussed, this architecture is themost functionally powerful and capable of the most complexsemantics. However, maintenance of communication links toplayers at all times severely restricts the physical actions inwhich players can take part. The GeoGame architecture haslimitations due to its distribution and to the fact that play-ers are not always in contact with each other, but iTESSand iTron hint at a broad range of interesting games areimplementable in GGA.

There are two alternatives to geocast-based communica-tions that naturally support GeoGaming style of play. Broad-cast based games use simple broadcasts (i.e., without re-transmission) among players, either over WiFi, bluetooth,infrared, or another medium. The advantage of this archi-tecture is that such games tend to be highly scalable, inthat the transmissions per broadcast metric is identically 1.They are also playable away from Internet connectivity aswell. Simple broadcast is actually a (non-preferred) param-eter instance of the geocast framework. Such games workwell in small clear areas. However, this architecture is unus-able for true GeoGames like iTESS or iTron in larger naturalareas. Broadcasts are too unreliable to implement playablegame semantics. For example, if iTESS were implementedusing broadcast, no player could ever shoot at another unlessstanding in line of sight and close enough. This would revealhis presence and the opponent could immediately target himback. By contrast, geocast allows relaying of shots aroundobstacles and over distances longer than radio range of oneunit, which allows hiding. In [4], geocast is shown to signifi-

cantly outperform broadcast in reliability while incurring anacceptable added transmission cost.

Another possible architecture alternative would use sim-ple flooding instead of geocast. Simple flooding is a protocolwhere every unit retransmits every packet once. This scalesfundamentally worse than geocast: for example, whereasgeocast-based iTron costs 2kn transmissions per second, iTronbased on simple flooding would cost 2n(n−1) transmissionsper second. In games involving a few tens of players, or inan area in which several games played concurrently such asin a tournament, flooding would swamp an 802.11 network.The same study [4] showed that geocast outperforms simpleflooding in both reliability and scalability for scenarios ofrealistic scale.

The Nintendo Wii game system[10] provides innovativecontrollers incorporating various novel sensors, such as ac-celerometers, that allow realistic simulation of many tra-ditional athletic games and fitness activities. Such gamesclearly address one of the two high level goals of GeoGam-ing, that of encouraging fitness in gamers. However, playersare still restricted to the immediate area in front of the con-sole and television during play, which is typically indoorsand of very small area. Such restrictions do not satisfy thesecond high level goal of GeoGaming, that of encouragingoutdoor play in order to gain the developmental and socialbenefits believed to flow from it. Moreover, while many fit-ness activities are possible using the Wii, simple running,jumping, hiding, and other core gross motor functions can-not be naturally incorporated. In particular, iTESS andiTron are not possible in the forms defined here. The Wiicapabilities offer unique advantages as well, however, suchas accuracy in detecting accelerations and orientations. Ibelieve that GeoGames on handhelds can be improved bymelding the technologies pioneered by Wii with the GGA toallow still more GeoGame user interface and gestural designcapabilities.

5. CONCLUSIONGeoGames are electronic games designed to be played out-

doors, incorporating vigorous physical activity, having thehigh level goal of improving the health and developmentof gamers, especially young people. This paper has pre-sented the GeoGame Architecture, which is based on threekey ideas: distributed control, communication via scalablead hoc geocast, and an optional long range extension basedon Tiered Geocast. I then defined two novel GeoGames,iTESS and iTron, and described five basic design patternsof GeoGaming (DP1-5) that are instantiated within thesegames’ implementations. Finally, GeoGaming and the GGAhave been initially evaluated in several ways.

• The scalability of the geocast protocol has been studiedand proven in simulation and then these results wereconfirmed through field trials, both in other systems(OneTESS) and through a new prototype code baseimplementing iTESS and iTron on iPhones.

• The games were prototyped and then small trials wererun using both adult and teenage boy testers. Initialfeedback was very positive, even though a number ofquirks and minor issues were encountered, most arti-facts of technology limitations imposed by the iPhone.None of these issues substantially interfered either withthe fun or playability of the games.

• The GGA was compared briefly with three alternativearchitectures, showing that none of them is capableof achieving the high level goals of GeoGaming at arealistic scale.

These positive initial results support pursuing further de-velopment of GeoGames and the GGA, and point the wayto technology improvements in supporting devices and soft-ware.

6. REFERENCES[1] Android official website. www.android.com.

[2] R. J. Hall. An improved geocast for mobile ad hocnetworks. Under review; available from authorhall@research.att.com.

[3] R. J. Hall. Forensic system verification. In Proceedingsof the 17th IEEE International RequirementsEngineering Conference. IEEE, 2009.

[4] R. J. Hall and J. Auzins. A tiered geocast protocol forlong range mobile ad hoc networking. In Proceedings ofthe 2006 IEEE Military Communications Conf., 2006.

[5] M. Heissenbuttel, T. Braun, T. Bernoulli, andM. Walchli. Blr: Beacon-less routing algorithm formobile ad-hoc networks. Elsevier’s ComputerCommunications Journal, 27, 2003.

[6] B. Karp and H. Kung. Gpsr: Greedy perimeterstateless routing for wireless networks. In Proc.Mobicom 2000. ACM, 2000.

[7] C. S. R. Murthy and B. S. Manoj. Ad Hoc WirelessNetworks: Architectures and Protocols. Prentice Hall,2004.

[8] www.peostri.army.mil/PRODUCTS/ONETESS/.

[9] Wifi alliance 14 october 2009 press release. www.wi-fi.org/news_articles.php?f=media_news&news_id=909.

[10] Wii at nintendo. www.nintendo.com/wii.

[11] M. B. Yassein, M. Ould-Khaoua, andS. Papanastasiou. On the performance of probabilisticflooding in mobile ad hoc networks. In Proc. 11th Intl.Conf. on Parallel and Distributed Systems –Workshops, 2005.