Hitchers: Designing for Cellular Positioning Adam Drozd1, Steve Benford1, Nick Tandavanitj2, Michael Wright1, and Alan Chamberlain1 1
The Mixed Reality Laboratory, University of Nottingham, Nottingham, NG8 1BB, UK {asd, sdb, maw, azc}@cs.nott.ac.uk 2 Blast Theory, Unit 4, Level 5 South, New England House, New England Street, Brighton, BN1 4GH, UK
[email protected]
Abstract. Hitchers is a game for mobile phones that exploits cellular positioning to support location-based play. Players create digital hitch hikers, giving them names, destinations and questions to ask other players, and then drop them into their current phone cell. Players then search their current cell for hitchers, pick them up, answer their questions, carry them to new locations and drop them again, providing location-labels as hint to where they can be found. In this way, hitchers pass from player to player, phone to phone and cell to cell, gathering information and encouraging players to label cells with meaningful place names. A formative study of Hitchers played by 47 players over 4 months shows how the seams in cellular positioning, including varying cell size, density and overlap, affected the experience. Building on previous discussions of designing for uncertainty and seamful design, we consider five ways of dealing with these seams: removing, hiding, managing, revealing and exploiting them. This leads us to propose the mechanism of a dynamic search focus, to explore new visualization tools for cellular data, and to reconsider the general relationship between ‘virtual’ and ‘physical’ worlds in location-based games. Keywords: Mobile games, cellular positioning, ubiquitous computing, seamful design.
1 Introduction Location-based games in which game-play responds to a player’s location represent one of the most promising commercial applications of ubiquitous computing. Previous location-based gaming projects have translated existing online computer games to a physical setting (e.g., AR Quake [13] and Human Pacman [7]); have used digital technologies to enhance or coordinate physical challenges (e.g., The Go Game [12] and Mogi Mogi [10]); have demonstrated new forms of collaboration across physical and virtual spaces (e.g., Can You See Me Now? [5] and Uncle Roy All Around You [3]); and have enabled players to explore and exploit the usually invisible seams in the ubiquitous infrastructure (e.g., Treasure [1] and Feeding Yoshii [2]). From a research perspective, games such as these provide an ideal way of engaging users in trials of emerging technologies and studying how they experience different aspects of ubiquitous computing when deployed ‘in the wild’, leading to new design sensitivities, guidelines and technical innovations. P. Dourish and A. Friday (Eds.): Ubicomp 2006, LNCS 4206, pp. 279 – 296, 2006. © Springer-Verlag Berlin Heidelberg 2006
280
A. Drozd et al.
In this paper, we introduce a location-based game called Hitchers that is targeted at mobile phones and that is intended to provide experience with the use of cellular positioning (especially approaches where phones look up their own current mobile phone cell-ID) to create location based experiences. We present a formative study of Hitchers that shows how the seams in cellular positioning and communications affected the experience, leading us to propose new mechanisms, tools and approaches for designing location-based games for mobile phones.
2 Cellular Positioning for Mobile Phones While the Global Positioning System (GPS) has been a popular positioning technology for supporting early location-based games for PDAs, it is currently not widely available on mobile phones in some countries. Rather, mobile phones come with their own positioning system, that of cellular positioning, in which a phone can be positioned relative to one or more mobile phone masts. There are two general approaches to cellular positioning. The first relies on operator or aggregator services that use information available from the operators’ networks to estimate the location of a phone which is then reported back to an application as a georeferenced location; in most cases the latitude and longitude of the mobile device along with an associated estimate of error. The second is for the phone itself to look up and use its own current cell-ID, the identifier of the mast/antenna to which it is currently connected, which is currently possible on some handsets (most notably on Nokia Series 60). There are advantages and disadvantages to each approach. Operator and aggregator services potentially offer a greater degree of precision and accuracy as operators can triangulate relative signal strengths across multiple masts for which they know precise geographical locations. Conversely, while looking up one’s own mobile phone cell-ID may deliver less precise information (as it only uses information about one mast) and may even not even deliver a geo-referenced position (unless someone has found out and published the location of the mast), it does confer some potentially useful advantages. It is free to look up your own cell-ID, whereas operators and aggregators charge for each look up which can become expensive in an ongoing mobile game. Furthermore, the look up occurs on the player’s own phone, not in the network, and so it is possible to control how location information is released to other players and game servers, with implications for maintaining privacy. A more detailed account of the potential benefits and limitations of using cell-ID for location can be found in [16]. In this paper, we focus on the second approach, a phone looking up its own cell-ID, introducing a game that exploits this without the need for georeferenced locations.
3 Introducing Hitchers Hitchers is a location-based game for mobile phones that utilises GPRS networking and positioning using the cell-IDs from the players’ phones to create an experience based around the metaphor of digital hitch-hiking.
Hitchers: Designing for Cellular Positioning
281
In Hitchers, initially the world is empty but as the game is played the streets fill with characters who are trying to hitch-hike their way across the city or up and down the country. They have been created and released into the wild by their owners and are trying to find their way home, reach a specific destination, carry out a mission, or just share a journey with a stranger. Players log into the game, giving their username and Personal Identification Number (PIN). They can then create new hitchers, giving each a name, a destination that it is trying to reach, and a question that it will ask each player it encounters (Figure 1).
Choose a name …
destination …
and question
Fig. 1. Creating a hitcher, giving it a name, destination and question
Once created, the player can ‘drop off’ their new hitcher, releasing it into the world to begin its journey. Metaphorically, the hitcher is now removed from their phone and waits in their current location for other players to come by and give it a ride. Whenever a player drops a hitcher they are prompted with the question “Where are we now?” which encourages them to enter a text label describing their current location in the physical world, building on the interesting idea of encouraging players to label the places that they associate with cell-IDs as described in [14]. Players can search their current location for any hitchers that may want a ride, seeing two lists of available hitchers: new acquaintances that they have never met before and old friends who they have previously encountered (Figure 2). They can pick up a hitcher in which case it appears to jump onto their phone and will no longer be available to other players until they drop it off again. When a player picks up a hitcher they see its name, destination and question. They can choose to answer the question with a short text response. They can also drop off the hitcher again whenever they like, possibly after carrying it with them to a new location, perhaps one that it closer to its ultimate destination. In this way, hitchers make their way from phone to phone, player to player and place to place, trying to reach their destination and gathering answers to their question as they go. In the current version of the game, a hitcher can only ride with one player at a time and each player can only carry one hitcher at a time.
282
A. Drozd et al.
Search …
pick up …
… answer
Fig. 2. Searching for, picking up and answering a hitcher
If there are no hitchers in their current location then the player may be told ‘There are no hitchers here”. However, sometimes the game is able to return a hint as to other nearby locations where they might be found in the form of “There are no hitchers here. Some were recently seen at ”, encouraging the player to journey to another place in order to continue their search and find a hitcher that needs a ride. Finally, the Hitchers website allows players to look up information about any hitcher that they have encountered and also the Hitchers they themselves have created and released. They can view where it has been, who it has met, the answers that it has collected, and can continue to follow its progress as the game continues. Figure 3 shows part of a webpage for a player who has encountered 177 hitchers thus far, listing the names of encountered hitchers on the left and the details (answers and places dropped) for the currently selected hitcher on the right. Thus, the website provides global information about the status and movement of Hitchers and the reward for picking up a Hitcher is to access both its past and future information. 3.1 Implementing Hitchers Hitchers employs a standard client-server architecture (Figure 4). The client runs on a player’s mobile phone, which is currently any of the Nokia Series 60 phones, and consists of two parts, the Place Lab cell-ID server that has supported a variety of context-aware projects for mobile phones, to enable the phone to report its current cell-ID [9] and a J2ME application that provides the client user interface, client side logic and the networking connection to the server. In Hitchers, the player’s current location is therefore mapped onto the current cell-ID. The server component of the system runs on a standard web server with PHP and MySQL extensions. PHP is used to script the logic on the server with MySQL being used for persistent storage. As most mobile phone networks do not provide mobile phones with routable IP addresses, all communications requests, which are in essence RPC calls, must be initiated from the client side. These RPC calls are sent from the client to the server over HTTP using POST requests, with the parameters being passed within the data of the POST request. The reply is then used to update the state of the client application
Hitchers: Designing for Cellular Positioning
283
Fig. 3. Exploring Hitching history via the online web interface
J2ME gui client
GPRS connection
Apache / PHP scripts
MySQL DB
placelab Mobile Client
Server
Fig. 4. The Hitchers architecture
on the phone which persists between sessions, including when the phone is switched off and on again. Consequently, the Hitchers client application only sends data to the server as a result of player initiated interactions (logging on and off, searching, creating, picking up, answering and dropping hitchers) and the server never initiates contact with the client. This also ensures that the player is directly in control of expenditure on GPRS data transfer at all times, which we believe to be a particularly important factor in mobile phone based games where players pay according to the volume of data transferred and where some players may have tightly restricted budgets (e.g., younger players who are often on ‘pay as you go’ contracts). Information about Hitchers including their name, question, current location (cellID) and status (available to be picked up, or currently associated by a given player) is
284
A. Drozd et al.
stored in the database along with the history of all previous answers and locations. Each player action results in a query to the database which is indexed by a combination of the player-ID, their current cell-ID and the hitcher-ID. The effects of these interactions are implemented by setting the values of the appropriate attributes for the row that represents this hitcher in the database. For example, dropping a hitcher involves changing its status attribute to be ‘available’ and updating its current cell-ID attribute. In addition to the information that is directly required for the current operation, the client also uploads a list of the most recently observed cell-IDs for this player whenever they interact with the game. This chain of adjacent cell-IDs is then stored by the server which, over the course of the game, gradually builds up a connected graph of mapped cell-IDs. The nodes of this graph represent all of the cell-IDs that all players have collectively visited and its arcs show the direct transitions that were observed between them. By direct transitions we mean whenever a player’s phone made a transition from one cell-ID to another without disconnecting in between. If a player leaves one cell-ID, either by quitting the game, switching off their phone, or losing network connectivity, to reappear at a new cell-ID sometime later, then no direct transition is recorded between the two cell-IDs. This graph structure can be queried by the system to establish adjacency relationships between cell-IDs in order to generate ‘hitcher hints’. Whenever a player searches for hitchers in their current location, the server sees if there are any in the database that are associated with their current cell-ID and whose status is ‘available’. If so, it returns their details to the player. However, if there are no available hitchers in the player’s current cell, the server uses the graph to identify any adjacent cells to the current cell that do contain available hitchers. It then chooses one of these (at random) and returns one of its location labels (also at random) to the user as a hint that tells them where they might go to find hitchers, using the phrase: “There are no Hitchers here. Some were recently seen at “” as noted previously. This phrasing carefully implies that the hitchers may no longer be at this location when the player reaches it We decided to initially opt for random choices so as to maximize player’s knowledge of different locations and labels in the game. 3.2 Hitchers as a Framework for Different Games and as a Basis for Formative Study Although we have described Hitchers as a game, it is currently more of a framework from which a variety of games might be created. As it stands, Hitchers currently has no specific goal, scoring mechanisms or game play beyond creating hitchers, moving them around the world and answering their questions. However, we envisage that it would be relatively straightforward to extend the rules of Hitchers to support a variety of games. Players might be rewarded for helping hitchers towards their destinations and answering their questions; they might be able to collect and carry multiple hitchers; hitchers might be given richer and more autonomous behaviors in terms of dialogue with users, the need for attention (perhaps requiring Tamagotchi style tending), deciding when to jump onto and off of players’ phones, and even the ability to fight or breed among themselves. Such features could support a variety of games such as
Hitchers: Designing for Cellular Positioning
285
hitcher ‘balloon races’, missions, battling hitchers, territorial games, virus simulations and others. This said, for the purposes of this paper, even this basic version of Hitchers is sufficient for us to be able to study the use cellular positioning to achieve locationspecific play. We therefore now turn our attention to a formative study of Hitchers.
4 A Formative Study of Hitchers Our formative study unfolded in two stages, an initial period of intense testing and software refinement over two months mostly involving members of the development team and other members of our research laboratory, followed by a broader deployment to players outside of our organization over about two months. This second main phase involved 47 players who were recruited from research teams across the UK and Sweden working in the area of ubiquitous computing, mobile games and also educational technologies, enabling us to draw on a strong base of expert opinion. We begin with a discussion of how our initial period of intensive testing revealed key seams in the underlying cellular positioning system, before then turning our attention to how players experienced the game, including these seams. 4.1 Testing the Seams in Cellular Positioning Throughout the trial, members of the development team played intensively at many different times and locations and on different forms of transportation with the specific intention of testing the potential impact of the underling cellular positioning mechanism on the game. Subsequent discussions of their experiences, backed up by inspection of system logs, raised a variety of issues concerning the use of cellular positioning, building on previous research in this area [11] [15]. Variable cell size and density – as one would expect, when compared to technologies such as GPS, positioning on raw cell-ID alone is relatively imprecise. From a player’s point of view, cells appear to vary in size from a few hundred meters up to kilometers. While many factors might potentially affect apparent cell size, one highly significant factor is the density of mobile phone masts, which tend to be more densely distributed in urban environments and more sparsely distributed in rural ones. One implication of this observation is that successfully playing Hitchers requires significant mobility on behalf of players. As we shall see below, this is not a game that works well around a single building or campus, but rather requires movement across a city or better, between cities as this produces clearly noticeable differences in locations and hitchers. A second implication is that Hitchers themselves may behave in a more fine grained way (i.e., be associated with more specific locations) in built-up urban environments compared to rural ones. Overlapping cells and cell flipping – mobile phone cells frequently overlap. It is often possible to see several cells from a given place and the system logs showed that a mobile phone would often rapidly flip back and forth between several different cells, sometimes as frequently as once every few seconds. This can occur for several reasons, including variations in signal strength due to interference, passing objects or subtle changes in the player’s position as well as due to congestion in the network.
286
A. Drozd et al.
As we shall report below, cell flipping could have two noticeable effects on the experience. First, it could cause hitchers to mysteriously disappear and reappear again. A player might drop a hitcher in one cell, then flip to a nearby one (without changing location), search for it and not see it, then flip back, search again and now see it again, giving the impression that hitchers jump around of their own accord. Second, it could cause the hints mechanism to tell the player to try looking for hitchers in their current location. In this case, the player would drop the hitcher, giving a location label. They would then flip to an adjacent cell (without physically moving) and search for hitchers. If none were found, the hints mechanism would look in adjacent cells for labels to return as hints, and might possibly choose the player’s previous cell and the label that they had just supplied – which would refer to where they were still standing. Multiple networks and roaming – there may be multiple mobile phone networks available at a given location. Players playing on one network will see a quite different set of cell-IDs to players on another. Put another way, each physical location may be associated with a different set of cell IDs (and hence a different set of hitchers) for each network. However, hitchers may move between networks as players roam, either explicitly or automatically switching networks. One player reported an unexpected and involuntary case of roaming: their phone was out of coverage on their home network when they dropped a Hitcher. In the meantime it had connected to another network, even though the player had no contract to roam there, so that the player could access emergency services if needed (networks may have an agreement with regard to being able to access emergency services). Consequently, they dropped a hitcher on a ‘foreign’ network as a result of being out of coverage on their home network. Network reconfiguration – the underlying infrastructure of mobile phone masts is itself not static. Masts may be added to the network, removed and their identifiers may be altered. One player reported playing Hitchers at a major music festival at which a temporary mobile phone mast had been erected. That cell ID – and presumably the hitchers that were left with it – has since disappeared, although perhaps it (and they) will reappear again elsewhere in the future, maybe even at the same festival next year. Cell elasticity when playing at speed – testing also showed that the experience of Hitchers appears to vary according to the speed of the player. Quite often we have tried to drop Hitchers precisely at stations or junctions when moving through them on an outward journey. On the return journey however, they have not been found at the stations, but rather some distance beyond them (as seen from the return direction). This effect makes sense if we consider the possible apparent elasticity of cells as illustrated by figure 5. Phones may tend to stay connected to their current cell until circumstances force them to disconnect. Imagine a station is overlapped by cells A and B. On the outward journey the train comes from cell A, is at cell A while passing the station when the player drops the Hitcher, then connects to cell B shortly afterwards. On the return journey they begin connected to B and remain in B as they pass through the station, only connecting to A – where they dropped the Hitcher – sometime afterwards. Verifying the consistency and causes of this effect requires further experimentation. However, at a more general level, it is broadly consistent with experiences from other location-based games. For example, players of a WiFi-based game called Feeding Yoshi that involved connecting to different WiFi access points reported
Hitchers: Designing for Cellular Positioning
287
difficulties due to rapidly passing through WiFi zones when trying to play in cars [2]. At the other extreme, players of a pedestrian game called Savannah experienced difficulties when they would suddenly stop to access location-based content while using a positioning system that had been tuned to operate smoothly for moving objects (a GPS system employing dead-reckoning) [4]. From the point of view of Hitchers, it would appear that while transportation systems offer powerful opportunities pervasive games (as we see later), they may also introduce new challenges in terms of the relationship between rapid movement and the operation of positioning and communications systems. More generally, it would therefore appear that there are complex interactions between player speed and positioning systems that require further exploration. Outward journey
cell B
cell A
Return journey
Point of cell transfer
cell B
cell A
station Fig. 5. Apparent cell elasticity when playing at speed
These various characteristics of cellular positioning in relation to coverage and how the mobile device establishes its connection to the network can be characterized as ‘seams’, the places in which technologies are stitched together to create an experience that are often intended to be transparent to the player, but that sometimes be revealed with unusual effects [6]. In this case, seams arise from the stitching together of multiple mobile phone cells to create multiple mobile phone networks. Ideally again from the our point of view of using cell-IDs for positioning, multiple cells and possibly even multiple networks would be seamlessly stitched together so that a mobile phone could roam between them, unaware of the underlying technical infrastructure. In practice, this is not always the case. Rather, mobile phone cells are not seamlessly stitched together, but instead overlap, vary in size and density, and on occasion leave gaps in coverage. This generally, except in the case of coverage does not affect the users when using the mobile as a phone, however when the cell-IDs are used directly as a positioning technology is does then affect users in the way the game behaves.
288
A. Drozd et al.
4.2 Feedback from Players Our 47 players created 409 hitchers, gave 364 answers to questions, dropped hitchers with a corresponding location label 1211 times, and searched for hitchers 2623 times. They passed through 3119 unique cell-Ds spread over 6 countries, mostly in the UK (2,484 unique cell-IDs), followed by Sweden (475),Belgium (112), Germany (24), Italy (16) and France (8). 381 unique cells-IDs were labeled by 1211 supplied labels. 17 of our 47 players responded to a short email questionnaire that probed their opinions as to a range of issues, of which the relevant ones for this particular paper were: whether they had enjoyed hitchers and how they would improve it; where and when did they prefer to play; how did they chose to answer the question “where are we now?”; and did they notice anything strange about the behavior of hitchers. Overall, players were evenly split between those who had enjoyed hitchers and those who had not. Those who enjoyed the experience appreciated the novelty of the idea, trying to associate hitchers with their owners, and seeing their own hitchers moved or answered. Those who did not enjoy it expressed frustrations that there were not enough players or hitchers in the areas in which they played, and that there were insufficient alerts to maintain their interest, suggesting that the game experience could become too sparse when only a few people were playing. Some players had experienced technical difficulties during the game (especially those who borrowed phones from us and so had to learn a new phone interface). Suggested improvements included being able to upload and download photographs (from several players), being able to carry several hitchers, having a rating system for hitchers, having ‘rare’ hitchers, and being able to add to hitcher stories. In terms of preferred times and places for playing, work was mentioned frequently and home much less so. However, there were frequent references to railway stations, underground metro systems, buses and cars. Transportation systems appeared to be popular because there was often downtime when players were bored and looking for something to do. One observed: “usually at railway stations, or on trains, because I got fed up with whatever I was reading!” and another noted: “On trains and buses. While waiting for transport. Because I had slivers of down time.” However, stations may also have been good destinations because they were obvious drop off and pick up points for hitchers. The Stockholm metro system was particularly notable as each underground station offered good connectivity and players would often commute back and forth. As one player noted: “there were trails of Hitchers in just about all subway stations I visited in Stockholm so it worked really well there.” On the whole, players did not greatly notice odd hitcher movements and behaviors with the exception of some who observed that they experienced difficulty with “finding hitchers again after they'd been put down” and several who did mention problems establishing connectivity. One player noted problems with the hints mechanism sometimes referring them to their current location as discussed above. One player observed that: “The accuracy of location was much too poor for the way everyone was trying to play (they were dropping a hitcher off at a location on campus and having it ask to be taken to different locations on campus). I imagine that given a bit of time, other players would have realised they could not play locally and would have sent hitchers on longer trips.” We return to these issues in greater detail below.
Hitchers: Designing for Cellular Positioning
289
Players adopted a range of strategies when answering the question “where are we now?” when dropping off a hitcher. The largest grouping claimed to give honest geographical descriptions of locations, for example: “I tried to give general descriptions of where I was”, “nearest station”, “I answered it as truthfully as I could (geographically)” and “honestly because I thought it would be interesting to other players”. However, one player was more deliberately evasive for privacy reasons: “Not to give away directly where the location was. I just don’t like people to know where I was exactly”. A few players mixed strategies: “Mostly pragmatically, like at stations naming the station but sometimes atmospherically if I was in the mood or cryptically if I thought it would make it more intriguing for someone finding a specific Hitcher”. Finally, one observed that it could be difficult to choose names when moving: “On the train I said ‘on the train’ as I had no idea where I was – that’s a problem”.
5 Designing for the Seams in Cellular Positioning Within this paper we are regarding a seam as divergence within a system between the state of the system the players are meant to see and the state of the system in reality. These seams are caused by there being multiple parts to a system (the phone masts / mobile cells in this case) that are being experienced as a whole by the players. It should be noted that we are mainly looking at the seams generated when using these masts (and hence the cell-IDs) as the basis of a positioning system and not the mobile network as such, although as we will see the coverage of the mobile network does play a part in generating seams. The question then becomes how seams impact on the user’s experience and what the designer or indeed the user can do about this? Previous research has suggested various strategies for dealing with the uncertainties caused by the seams in ubiquitous technologies [5]: remove them by improving or carefully deploying the technologies; hide them by designing experiences that are robust to the characteristics of seams; manage them by designing an experience that adapts to seams; reveal them to users and designers so that they are aware of the presence and effects of seams, enabling them to adapt their own behaviors; and finally, exploit them, requiring users to actively seek them out as part of the experience. We now consider each strategy in relation to the design of Hitchers and potentially other pervasive experiences. 5.1 Removing the Seams from Hitchers It may be possible for operators to remove some of the seams from the cellular network, for example by providing greater network coverage; ever getting closer to 100%,and also by providing more consistent and accurate positioning services that draw on knowledge of a mobile phone’s relationship to many masts, as indeed they already do to some extent in operator positioning services. However, operator positioning services do not currently fit the style of game play Hitchers is based upon, mainly due to the financial costs involved with operator services. Cell handovers will however be an inevitable part of using cellular positioning in the way Hitchers does and this is discussed below in the section regarding managing seams.
290
A. Drozd et al.
5.2 Hiding the Seams in Hitchers Although these various seams became apparent during our extensive testing of Hitchers, feedback from our players suggests that they often went unnoticed in the course of everyday play. We propose that this may be because the design of Hitchers is reasonably effective at hiding the worst effects of these seams. Users are on the whole, not exposed to location information (the cell-IDs in this case) other than through the sense of searching or dropping ‘here’ and through hints from the system that Hitchers may be at a nearby named place. In particular, there is no game map that tries to suggest to users where they are at any given moment in time. Even though hints do refer to places, they are careful to suggest only that Hitchers have recently been seen at this place – not that they would necessarily be found there now. Furthermore, there is the general idea in the concept of the game that Hitchers can move about, for example as other players pick them up, or possibly even of their own accord. Hitchers are therefore somewhat elusive and one would not always expect to find then where one left them, which may go some way to hiding seams such as variable sized and overlapping cells. In short, we suggest that Hitchers is reasonably – though not entirely – accommodating to the seams when using cell-ID positioning. 5.3 Managing the Seams in Hitchers However, there are clearly times when seams do reveal themselves, including three of the effects that we described above: cell flipping causing hitchers to disappear and reappear; cell flipping causing the hints mechanism to return hints that refer to the player’s current location; and problems caused by the apparently elastic effect of cell positioning when players are moving at speed. We propose that a single mechanism – an adaptive search focus – could be introduced to help the game manage these effects. In the current game, the search focus is set to only look in the current cell. In contrast, in a very early test version we had experimented with a broader search focus that looked in the current cell, its immediate neighbours and their immediate neighbours (a search depth of 2 in the cell graph that is built up during the game). However, this had proved to be too broad in densely mapped areas leading to players seeing the same hitchers even after moving several kilometers. An adaptive search focus is then a mechanism that adapts the depth of searching to suit the player’s current situation. For example: •
•
•
On detecting cell flipping (rapid oscillation between several cells) the search focus would extend to cover all of them (effectively treating them as a single cell while flipping continued). This might mitigate the problems with hitchers disappearing and reappearing and returning hints to the current location. On guessing that the player was moving at speed, for example by logging a continuous linear sequence of cells, the search focus might be extended to cover the current cell and its neighbors, potentially mitigating some of the effects of cell elasticity as noted previously. Extending and shrinking the search focus might also help manage the effects of sparse player density that frustrated some of our players. In an area shared
Hitchers: Designing for Cellular Positioning
291
by many players the game would build up a dense map of local cells which would be highly interconnected. In this case, the search focus might be reduced to just the current cell providing maximum differentiation between different locations so that the game would respond to relatively small changes in position. In an area with few players, there would be a much less densely connected mapping of cells, in which case it might make sense to extend the search radius. We propose that this mechanism of an adaptive search focus could provide a useful way of managing the effects of seams. However, it does require that the designer (for pre-programmed adaptation) or system (for automated and dynamic adaptation) can spot situations in which the focus needs to be adapted, i.e., when cell flipping is occurring, when players are moving rapidly or when players are in dense or sparse areas of the game. This brings us to the next strategy – revealing seams. 5.4 Revealing the Seams in Hitchers Our fourth strategy involves revealing the seams in the underlying positioning infrastructure (the cell-IDs in this case) so that designers (and potentially players) can reason about their presence and effects and can adapt the experience accordingly. With this in mind, we have begun to develop new tools that help humans visualize the behavior of the cellular positioning system. The first of these is the tool shown in figure 6 that visualizes the cell data that is mapped and labeled by players. The visualization takes the form of a connected graph whose nodes represent unique cell-IDs and whose arcs represent direct transitions between pairs of cell-IDs that have been recorded by players during the game. This graph is visualized using a well known force-directed placement algorithm [8] that is implemented in the Java JGraph library [16]. Consequently, this is an abstract graph and the relative positions if the nodes bear no relation to geographical directions in the physical world. Users can interact with this visualization in the following ways: • Using the controls top-left, they can select the dataset to be visualized, filtering it by country and network. • They can zoom in and out and pan across the visualization to inspect different patterns of cell trails, for example identifying tightly clustered areas. • They can query individual cells in order to inspect their location labels. • They can use the controls bottom-left to select all cells that have been labeled with a given text substring. These cells are then highlighted with a bold border and separate sub-graphs displaying only these cells and cells that connect them are displayed in the separate mini-visualization bottom-right. • They can query the graph for information about Hitchers including showing the current location of a Hitcher as well as the Hitchers currently associated with a given cell. The size and shading of the nodes in the graph can also be dynamically configured using the controls middle-left to show the number of hitchers currently in a cell and the number dropped in this cell over time.
292
A. Drozd et al.
Main visualization
Node color & size mapping
Select country and network
Central Stockholm Train journey to Uppsala
Kista
Sub-graph and list of selected nodes
Select nodes that match a given label
Fig. 6. The Hitchers cell-data visualization tool
We propose that visualizations such as this can help designers deal with the seams in cellular positioning as well as establish potential mappings between clusters of mapped cells and user-meaningful places and activities. For example, Figure 6 shows all data that was gathered from our trial by all players across all networks in Sweden. The figure reveals some distinctive dense clusters of cells as well as some long thin trials of cells that connect them. By inspecting the player-given labels for these cells, we have been able to assign likely physical locations to some of the key clusters (we have labeled two of the larger ones – the towns of Stockholm and Kista – in the figure). We have also been able to determine that the long trails of cells correspond to train and car journeys. By filtering and zooming we are able to explore these further. For example, the bottom-right of figure 6 shows a sub-graph of all cells that have been labeled with the word ‘station’ along with intervening cells that connect these. Figure 7 shows a series of views of a region of the graph that are highlighted according to three different location labels. The leftmost image highlights cells that have
Hitchers: Designing for Cellular Positioning
293
been labeled ‘Kista’ the middle image cells labeled ‘SICS’ (The Swedish Institute of Computer Science) and the right image cells labeled ‘ICE’ (Interactive Computing Environments lab), suggesting that ICE is a place within SICS which is a place within Kista. Images such as this may enable us to reason about the relationship between players’ activities, places that are meaningful to them and potentially overlapping mobile phone cells. We anticipate that they could be especially useful to designers, as they can provide information about how to design a pervasive experience that adapts to the distinctive characteristics of cellular positioning. For example: •
•
•
We know from our player feedback, that transportation systems are good places to play. A tool such as this can help a designer identify which mobile phone cells are likely to be encountered on a journey via train, bus or car and to author specific hotspots or location triggers accordingly. For example, we can identify likely sequences of cells encountered when traveling on the Stockholm subway and author appropriate content for these. These visualizations also help designers identify clusters of cells that are associated with other kinds of player meaningful places (our data shows players labeling supermarkets, schools, places of work, their homes, restaurants and bars) which again can inform the design of hotspots and triggers. We have already proposed the idea of an adaptive search focus in the previous section. This visualization might help designers configure such a mechanism, for example, identifying sequences of cells that are associated with journeys (for which we want a wider focus) versus those that appear to be associated with more dense regions of play (for which we want a narrower focus).
Consequently, we suggest that visualizations such as might potentially form the basis of new design and authoring tools that reveal information captured from an experience so as to help designers refine that experience or potentially author new ones.
Fig. 7. Highlighting cells that players have labeled ‘Kista’ (left), ‘SICS’ (middle) and ‘ICE’ (right) by being shaded. Is ICE a place within SICS which in turn, is within Kista.
294
A. Drozd et al.
5.5 Exploiting Seams in Hitchers Our final strategy focuses on how we might exploit these seams to create new kinds of experience. A distinctive and interesting feature Hitchers is the way in which it generates a virtual game board as it is played. At the beginning of a game, Hitchers has no knowledge of places that are meaningful to players or of how they map to mobile phone cells. However, as the game unfolds it constructs a continually changing map of interconnected cells and corresponding place labels. These can be thought of as a game board across which pieces – players and Hitchers in our case – can move. This perspective opens up intriguing new possibilities for designing games in which part of the experience is to map the infrastructure or perhaps to strategically change the map that has been generated thus far. For example, we could design games in which players acquire, defend, maintain or capture territory by mapping and labeling cells. Game mechanics might range from simply acquiring cells by being the first player to encounter them, through to more complex moves in which already mapped cells can be captured, for example by finding a new route through the physical world that encircles them or connects them in a new way. This idea of being able to make new connections between new cells – forging shorter paths through the cell map by working out a new route through the physical world – could also offer players advantage in terms of transporting objects around the game board. For example, a skillful player would be able to reason about potential new connections between cells that appeared to be widely separated on the graph but perhaps shared some common or nearby place labels in the physical world. Perhaps this could be assisted by virtual maps based on the kinds of visualizations that we showed above? This kind of game mechanic would essentially be exploiting the imprecise nature of the mapping of places in the physical world to cells, encouraging players to reason about how different cells overlap with different places and potentially with each other. Skillful players might even be able to exploit deeper knowledge of the operation of mobile phone networks, for example realizing that at times of high congestion their phone may connect to more distant masts than usual, which might offer them a form of power-up – a virtual teleport – in a game. At a more general level still, what we are proposing here is a reconsideration of the relationship between physical and virtual worlds in pervasive games. Most pervasive games to date have sought to establish a homogenous mapping between the physical environment of the players and virtual world of digital content, most often by directly overlapping the virtual on the physical so that movement in the latter drives movement in the former (e.g., Human Pacman [7], Can You See Me Now? [5], Savannah [4]), although often with only limited success due to the effects of underlying seams. Conversely, we are proposing designing for a much more ‘slippery’ and dynamic relationship between the physical and the virtual world in which a virtual game board is more loosely mapped to the physical world, and in which relationships between the two evolve and change according the behavior of underlying networks and positioning systems. We propose that such mappings, of which we see glimpses in our current visualizations, provide a further example of ‘seamful design’ in which experiences exploit the seams in the underlying technological infrastructure [6].
Hitchers: Designing for Cellular Positioning
295
6 Summary In summary, our study of Hitchers has revealed issues concerning the seams in cellular positioning on mobile phones. We have seen that cells vary in size and density, overlap, appear and disappear as the network evolves, and even behave elastically at speed. We have then discussed five different design strategies in relation to these seams: removing, hiding, managing, revealing and exploiting them. Player feedback suggests that the design of Hitchers is reasonably effective at hiding these seams for much of the time. That said, our discussions of other strategies have led us to propose three new techniques that might enable other experiences to adapt to seams, including employing an adaptive search focus; using visualization tools to understand the underlying seams and the relationship between mobile phone cells and meaningful places and activities; and finally, the idea of developing new kinds of games in which the goal is to map and explore a continually evolving virtual game board. Our future plans involve a more systematic and deeper meaning of these seams, in terms of their characteristics, impact on player experience, and approaches to design.
Acknowledgements We gratefully acknowledge the support of IPerG, the European Project on Pervasive Gaming, project FP6-004457 under the European Commission's IST Programme (www.pervasive-gaming.org). We are also grateful for additional support from the Equator Interdisciplinary Research Collaboration which has been funded by the UK’s Engineering and Physical Sciences Research Council (www.equator.ac.uk).
References 1. Barkhuus, L., Chalmers, M., Tennent, P., Hall, M., Bell, M., Sherwood, S. and Brown, B. (2005) “Picking pockets on the lawn”. UbiComp ’05, Tokyo: Springer. 2. Bell, M., Chalmers, M., Barkhuus, L., Hall, M., Sherwood, S., Brown, B., et al, Interweaving Mobile Games With Everyday Life, Proc CHI 2006, Montreal, Canada, April 2006, ACM. 3. Benford, S. et al. (2004) The error of our ways: the experience of self-reported position in a location-based game, UbiComp ‘04, pp. 70-87, Springer. 4. Benford, S. et al. (2005a) Life on the edge: supporting collaboration in location-based experiences, Proceedings of ACM CHI ’05, pp. 721-730. 5. Benford, S. et al. (2006) Can You See Me Now?, ACM Transactions on Computer-Human Interaction, Vol. 13, No. 1, March 2006, Article 4. 6. Chalmers, M., And Galani, A., Seamful Interweaving: Heterogeneity in the Theory and Design of Interactive Systems, ACM DIS 2004, pp. 243-252, August 2004. 7. Cheok, A., Goh, K., Farbiz, F., Fong, S., Teo, S., Li, Y., Yang, X., Human Pacman: A Mobile, Wide-Area Entertainment System Based On Physical, Social And Ubiquitous Computing, Personal And Ubiquitous Computing, 8 (2), 71-81, May 2004, SpringerVerlag, ISSN 1617-4909.
296
A. Drozd et al.
8. Fruchterman, M. J. & Reingold, E.M., Graph Drawing by Force-directed Placement, Software - Practice and Experience. vol 21, number 11, 1129-1164,1991. 9. Hightower, J., Consolvo, S., LaMarca, A., Smith, I., & Hughes, J., Learning and Recognizing the Places We Go, Ubicomp 2005, Tokyo, Japan. September 2005. 10. Joffe, B. (2005) Mogi: Location and Presence in a Pervasive Community Game, Proc. Ubicomp Workshop on Ubiquitous Gaming and Entertainment. 11. Laasonen, K. Raento, M. Toivonen, H., Adaptive On-Device Location Recognition, Lecture Notes in Computer Science, 3001, 287-304, 2004. 12. McGonigal, J., A Real Little Game: The Performance of Belief in Pervasive Play, Digital Games Research Associaton (DiGRA) "Level Up" Conference Proceedings. Utrecht, November 2003,. 13. Piekarski, W. And Thomas, B. 2002. ARQuake: The Outdoors Augmented Reality System. Communications Of The ACM, 45 (1), 36–38. 14. Smith, I., et al. Social Disclosure of Place: From Location Technology to Communication Practices. Pervasive Computing. 2005. Munich, Germany: Springer. 15. Trevisani E. & Vitaletti A (2004) Cell-id location technique, limits and benefits. Proc. IEEE Workshop on Mobile Computing Systems and Applications. 16. www.jgraph.com, Java JGraph Library (verified April 2006)
