Taleblazer: Using Ibeacons for Indoor Location-Based Augmented Reality

TaleBlazer: Using iBeacons for Indoor Location-Based Augmented Reality Games by Ellen Yongin Finch Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degree of Master of Engineering in Electrical Engineering and Computer Science at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY June 2015

c Ellen Yongin Finch, MMXV. All rights reserved. The author hereby grants to MIT permission to reproduce and to distribute publicly paper and electronic copies of this thesis document in whole or in part in any medium now known or hereafter created.

Author...... Department of Electrical Engineering and Computer Science May 18, 2015

Certified by...... Professor Eric Klopfer Director, MIT Teacher Education Program Thesis Supervisor

Accepted by...... Professor Albert R. Meyer Chairman, Masters of Engineering Thesis Committee 2 TaleBlazer: Using iBeacons for Indoor Location-Based Augmented Reality Games by Ellen Yongin Finch

Submitted to the Department of Electrical Engineering and Computer Science on May 18, 2015, in partial fulfillment of the requirements for the degree of Master of Engineering in Electrical Engineering and Computer Science

Abstract TaleBlazer is a platform for creating and playing location-based educational augmented reality games. This thesis describes the design and implementation of new indoor location-based functionality in TaleBlazer, based on the use of iBeacon technology. It describes how the new functionality can be used in indoor location-based games, and presents results from a pilot indoor game conducted with the Harvard Museum of Natural History.

Thesis Supervisor: Professor Eric Klopfer Title: Director, MIT Teacher Education Program

3 4 Acknowledgments

I’d like to thank Eric Klopfer, Judy Perry, and Lisa Stump for giving me the oppor- tunity to work on this project. It’s been an experience unlike any of my others at MIT, and I greatly appreciate having gotten to learn so much about something so far from my specialty. I’d like to thank Judy Perry, Lisa Stump, and Arielle Ascrizzi for their help in designing and implementing the indoor functionality, and especially for all their hard work in developing such a wonderful pilot game for us to test my work with. I’d like to thank the rest of the TaleBlazer team for the good company while working on this project, and wish Bobby Fortanely the best of luck with his ambitious plans for continuing the indoor work. Finally, I’d like to thank my family and friends, because as trite as the phrase is, it is also strictly and literally true that I wouldn’t be where I am without their support.

5 6 Contents

1 Introduction 15 1.1 Motivations ...... 16 1.2 Research Question ...... 16 1.3 Chapter Summary ...... 17

2 Background 19 2.1 TaleBlazer ...... 19 2.1.1 TaleBlazer Gameplay ...... 19 2.1.2 TaleBlazer Platform Structure ...... 21 2.1.3 Using TaleBlazer ...... 21 2.2 Previous Indoor Games ...... 22 2.2.1 Outbreak @ the Institute ...... 22 2.2.2 Mystery at the Museum ...... 22

3 Indoor Navigation 25 3.1 Determining Design Goals ...... 25 3.1.1 Partnership with HMNH ...... 27 3.2 Approaches Considered ...... 28 3.2.1 QR Codes, Dead Reckoning, and WiFi Positioning ...... 28 3.2.2 Indoor Google Maps ...... 30 3.3 Approach Selected: Bluetooth Beacons ...... 31 3.3.1 Introduction to Beacons ...... 32 3.3.2 Advantages of Beacons ...... 33

7 3.3.3 Drawbacks of Beacons ...... 33

4 Implementation 35 4.1 Preliminary Testing ...... 35 4.2 Design Decisions ...... 36 4.3 Software Changes ...... 37 4.3.1 Game Creation ...... 38 4.3.2 Gameplay ...... 40 4.3.3 BLE Support Check ...... 42

5 Pilot with HMNH 45 5.1 Game Design ...... 45 5.1.1 Game Overview ...... 46 5.1.2 Game Mechanics ...... 49 5.2 Pre-pilot tests ...... 50 5.2.1 First pre-pilot test ...... 50 5.2.2 Second pre-pilot test ...... 51 5.3 Pilot Results ...... 52 5.3.1 Observation ...... 53 5.3.2 Post-game Survey ...... 54 5.3.3 Focus Group ...... 55 5.3.4 Pilot Conclusions ...... 57

6 Future Work 59 6.1 Editor Usability Improvements ...... 59 6.2 Adding Android Support ...... 61 6.3 Further Tests ...... 62 6.4 Using Beacons for Real-Time Player Positioning ...... 63

7 Conclusion 65

A Mobile Device Battery Drain Tests 67

8 B Research Instruments 69 B.1 Observation Protocol ...... 70 B.2 Post-game Survey ...... 71 B.3 Focus Group Questions ...... 73

9 10 List of Figures

2-1 Outdoor game example ...... 20

3-1 Bluetooth beacons ...... 31

4-1 Beacons tab in TaleBlazer editor ...... 39 4-2 Beacon agent bump settings in TaleBlazer editor ...... 39 4-3 Agent beacon settings in TaleBlazer editor ...... 40 4-4 Agent ordering example ...... 41 4-5 Android beacons not supported message ...... 43 4-6 iOS beacons not supported message ...... 44 4-7 iOS prompt to turn on Bluetooth ...... 44

5-1 Super Survivor biome assignment screen ...... 46 5-2 Super Survivor trait selection screen ...... 47 5-3 Super Survivor trait feedback screens ...... 48 5-4 Super Survivor end screens ...... 48 5-5 Super Survivor directions screens ...... 49 5-6 Players lean in to closely examine animals ...... 53

11 12 List of Tables

3.1 Indoor Navigation Goals ...... 27

4.1 Purchased Beacons ...... 36

5.1 Post-game Survey Results for Family Questions ...... 54 5.2 Post-game Survey Results for Adult Questions ...... 55 5.3 Post-game Survey Results for Child Questions ...... 55

A.1 Battery Drain Test Results ...... 67

13 14 Chapter 1

Introduction

TaleBlazer is a platform for creating and playing location-based educational augmented reality (AR) games on Android and iOS devices, created by MIT’s Scheller Teacher Education Program (STEP) Lab. TaleBlazer is intended to help informal learning spaces provide enhanced educational experiences which leverage real-world locations. The goal of TaleBlazer games is to engage players with the physical space they are visiting, making them look more closely at and think more deeply about exhibits or other aspects of their surroundings.

The current version of TaleBlazer supports both indoor and outdoor gameplay. However, because TaleBlazer’s source of location information is GPS, when players are indoors, the app cannot passively detect their locations. Thus, indoor TaleBlazer gameplay has limited functionality compared to outdoor TaleBlazer gameplay. This thesis will describe the design and implementation of extended indoor functionality for TaleBlazer. It will describe background research on different approaches to indoor positioning, explain the approach selected and how it was integrated into TaleBlazer, and present the results of a pilot game run at the Harvard Museum of Natural History (HMNH) with the help of the museum staff.

15 1.1 Motivations

TaleBlazer games provide a structured learning experience within the engaging frame- work of a location-based AR game. In outdoor TaleBlazer regions, a player interacts with game elements, referred to as agents, by approaching their GPS locations. For example, at a zoo, a character agent could be located next to the lion enclosure; when the player walks by the lions, the app detects that their GPS coordinates have reached the area where the character is located, and causes the character to come up on the screen. Because GPS does not work inside buildings, the indoor mode of TaleBlazer needs to provide some other way to interact with agents. The current solution is to allow players to tap on agents to interact with them. If the game designer wants to ensure that the player has reached the proper location, they can secure agents by using a password the player can only obtain at the physical location of the agent, such as a word on a poster at that location. Both of these approaches require more work from the player than passive location sensing does, and the password-free approach runs the risk that players will tap through the game without visiting any of the exhibits. Ideally, indoor TaleBlazer games would be able to provide similar location-based functionality to outdoor TaleBlazer games. This goal is of particular importance because many informal learning spaces are entirely indoors, and so can use only the indoor functionality of TaleBlazer in any games they might create. Providing a more fully-featured indoor mode would thus greatly increase the utility of TaleBlazer for many of its intended users, as well as broadening TaleBlazer’s audience to include indoor locations which would not consider using TaleBlazer without this functionality.

1.2 Research Question

In designing the new indoor functionality, our goal was to enable TaleBlazer to be used for creating a location-based experience indoors, while remaining feasible for typical educational institutions given their logistical and other practical constraints.

16 Constraints include cost of implementation, visual impact of any new technology used for indoor positioning, and visitor experience. A TaleBlazer game should have high learnability and usability, because learning the platform should not be a distraction from playing the game and learning about the space. To help guide our work on the new functionality, we decided to partner with museum staff at the Harvard Museum of Natural History with the goal of producing a pilot indoor TaleBlazer game. The question my work sought to answer was, could TaleBlazer be modified to create indoor location-based games while meeting these constraints and goals in a typical informal learning institution such as HMNH?

1.3 Chapter Summary

Chapter 2 provides background on the TaleBlazer platform and related indoor location- based work done by the STEP Lab. Chapter 3 discusses the goals of TaleBlazer’s indoor navigation and explains the selection of iBeacons as the approach. Chapter 4 details the implementation of the new indoor functionality. Chapter 5 describes the HMNH pilot game and presents the results of the pilot. Chapter 6 suggests possible future work on TaleBlazer’s indoor functionality. Chapter 7 concludes.

17 18 Chapter 2

Background

The MIT STEP lab has been working on educational AR games for more than a decade [11], although TaleBlazer itself is only a few years old. The new indoor functionality work on TaleBlazer builds off of both the existing functionality of TaleBlazer and previous indoor AR games run by the lab.

2.1 TaleBlazer

TaleBlazer is a platform for creating and playing location-based AR games. As such, its target audience includes both game creators and game players. The target audience of game creators is primarily children and non-technical curriculum writers, so the game creation software is designed to be simple for a non-technical audience to understand and use. The target audience of game players includes both children playing games they have created, and visitors to sites using a TaleBlazer game as an educational activity. The complexity of a game is determined by the game’s creator.

2.1.1 TaleBlazer Gameplay

TaleBlazer gameplay is based on interaction with agents, which represent objects such as characters or items in the game. Interacting with an agent is referred to as bumping the agent.

19 Figure 2-1: Outdoor game example

In an outdoor game region, as the player walks around the real location, their position is tracked by GPS and displayed as a moving dot on the game map. When the player is detected to have reached an agent’s location, they bump the agent, causing the agent’s “bump script” to execute whatever behavior the game designer has specified for this event. Figure 2-1 shows an example outdoor game; the circle icon represents the player and will move as the player moves, while the triangle icon represents an agent and is fixed in place. In an indoor game, the player’s position is not shown on the map and the player bumps agents by tapping their icons on the map. As described above, depending on the design of the game, tapping can either be all that is needed to interact with an agent or the player may be required to enter a password to demonstrate that they are in fact at the correct location.

20 2.1.2 TaleBlazer Platform Structure

The TaleBlazer platform consists of five parts: a mobile app for playing games, an online editor for creating games, a website that hosts the editor and stores account and game data, a multiplayer server, and an analytics server. The work in this thesis involved modifications to the mobile app, the editor, and the website. The TaleBlazer mobile app is built in Appcelerator Titanium, a platform that allows a single JavaScript codebase to be compiled into both an iOS and an Android app. The editor is a web application written in JavaScript with an HTML/CSS front-end, and the website’s back-end is PHP/MySQL.

2.1.3 Using TaleBlazer

The first step in creating a TaleBlazer game is registering for an account onthe TaleBlazer website. Using this account, a game designer can sign on to the TaleBlazer website and create games. To create a game, the game designer opens the TaleBlazer editor on the website and selects a region to be the map for their game. They then add agents to the game by placing them on the map. For an outdoor game, the software automatically calculates the GPS coordinates of the agents based on their location on the map. For an indoor game, the designer simply marks a region as indoors, in which case the mobile app will not attempt to locate the agents using GPS. The game designer can easily create scripts for agent interaction using the blocks-based scripting provided in the editor. When the game is saved, it is stored on the TaleBlazer server and can be downloaded and played.

To play a TaleBlazer game, a user installs the TaleBlazer mobile app and then uses the app to download the particular game file from the TaleBlazer server. There are many different ways to download TaleBlazer games. If a user has a game code, they can enter it to download that game. If they are near a partner location, the app will suggest the featured game for that location. If they have their own TaleBlazer account, they can log in and download any games they have created.

21 2.2 Previous Indoor Games

The STEP lab has conducted two major indoor AR games in the past, Outbreak @ the Institute and Mystery at the Museum. Both games used room-level indoor positioning to provide location-based functionality. Mystery at the Museum also provided close interactions with particular museum exhibits.

2.2.1 Outbreak @ the Institute

Outbreak @ the Institute was an indoor AR game conducted on campus at MIT in 2004 [9]. The game scenario was an outbreak of bird flu on campus; both game characters and the players themselves could fall ill from exposure to sick characters or players. The players’ goal, in their roles as doctors, field technicians, or public health officials, was to contain the outbreak as well as possible. The game was played using WiFi signal strength for indoor positioning. The game mechanics supported by the indoor positioning were using or acquiring items if in the same room as them, and being at risk of becoming infected if in the same room as an infected person [10]. The mechanics were based only on what rooms players were in because the WiFi positioning could only locate players to the precision of what room they were in, not where in the room they were, but this precision was sufficient for the purposes of the game.

2.2.2 Mystery at the Museum

Mystery at the Museum was an indoor AR game conducted at the Museum of Sci- ence Boston in 2003 [8]. In design, this game was more similar to a TaleBlazer game than Outbreak @ the Institute, because inspecting and interacting with the physical contents of the rooms was relevant to the gameplay. This game’s storyline involved recovering a stolen artifact and apprehending the thieves who had stolen it. The gameplay consisted of both room-level interactions, such as interacting with characters and collecting clues, and close interactions with specific exhibits. Like Outbreak @ the Institute, Mystery at the Museum used WiFi signal strength

22 for room-level positioning. For the close interactions, items were tagged with infrared tags that the players could scan with their mobile devices [6]. Although Mystery at the Museum was a successful game, setting up the infrastructure to support the indoor location components was difficult, requiring manual placement and mapping ofthe tags and the use of non-adjacent rooms to avoid bleed-over in the WiFi positioning. These difficulties made using a similar approach for other indoor games impractical.

23 24 Chapter 3

Indoor Navigation

There are two components to navigation in TaleBlazer: wayfinding, which is important for guiding the player between agents, and positioning, which is important for determining that the player has reached an agent’s location. In outdoor TaleBlazer, GPS serves both functions as it both provides the moving dot on the map that helps the player locate themself, and enables the mobile app to determine when the player should bump an agent. Approaches to indoor navigation can either handle wayfinding and positioning separately, or handle both with the same technology.

3.1 Determining Design Goals

To help determine the goals of TaleBlazer’s indoor navigation, I conducted interviews with TaleBlazer partners who have worked on indoor and outdoor TaleBlazer games, as well as with HMNH, our partner for the indoor project. These partners included both educational institutions focused on creating games for visitors to play and an after school program focused on having children create and play their own TaleBlazer games. The interviews took the form of general questions on their goals for indoor TaleBlazer games and specific questions about potential approaches to the indoor navigation problem. The common goal these partners had for their TaleBlazer games was getting players to spend more time making detailed observations of specific objects, rather than

25 rushing through a space and only glancing at everything. For the educational institutions, creating engaging activities to help bring visitors back for return visits was also a major goal.

Everyone interviewed found that simply supplying directions had served well for wayfinding in existing indoor TaleBlazer games. In a case where the game involved working to find specific objects, so that detailed directions could not be given, giving a general description and general location had worked well. Replacing the directions approach with a moving dot on a map was appealing to the partners, but most had concerns about the level of precision possible since poor execution would likely frus- trate or confuse players. Because encouraging visitors to make detailed observations is such a common goal, many partners desired a positioning system that could pin- point individual objects. Suggested levels of accuracy included “within a few feet” and “within inches,” although some said they could work with gallery-level precision. One partner noted that an overly fine-grained position sensor could be frustrating for players, if they were unable to bump an agent because they had to be within inches of it.

While many partners found that using password protected agents or simply tap- pable agents had worked well for past indoor games, all of them were very enthusiastic about the idea of a passive location sensing system like the outdoor GPS location. Having the mobile application sense the player’s location was noted as one of the most engaging aspects of TaleBlazer, so passive location sensing would add a lot of value for indoor games.

A commonly mentioned concern was the visibility of any physical infrastructure required for indoor navigation. Many partners are not in a position to easily post visible codes or pieces of technology around a space, because of the nature of the displays or the rules of the institution or both. Additionally, some partners were concerned about ensuring that people would actually take the time to think about their actions in the game, instead of running around to find everything included in the game. Having the indoor positioning infrastructure be readily visible could be a disadvantage, leading players to take more of a scavenger-hunt approach, even

26 for games not designed as scavenger hunts. However, it was also noted that having objects clearly marked as in-game could be useful in some cases. Although cost was not raised as a concern by most of the partners, the potential financial cost of an indoor navigation system requiring new technology is also amajor concern. Because TaleBlazer is meant to be usable by a broad range of users, keeping game implementation costs down is a priority for the project. Thus, requiring expensive additional technology for indoor games should be avoided. In a similar vein, another important priority is keeping game creation simple. There should not be much overhead in setting up an indoor TaleBlazer game compared to an outdoor TaleBlazer game, both in terms of physical setup of infrastructure and any extra software configuration required. Table 3.1 summarizes the goals for TaleBlazer’s indoor navigation.

Table 3.1: Indoor Navigation Goals

1) passive location sensing 2) no overly visible infrastructure 3) fine-grained location sensing 4) low cost 5) easy to set up

3.1.1 Partnership with HMNH

In order to test indoor TaleBlazer in an authentic environment, we decided to partner with the Harvard Museum of Natural History to develop both the new indoor functionality and a pilot game for end user testing. Because of the partnership, HMNH’s goals for TaleBlazer’s indoor navigation were given particular weight in the design process. The partnership also led us to focus on developing a polished pilot game and collecting end user data, rather than focusing on experimenting with the technology. HMNH uses a fairly traditional approach to exhibits, primarily consisting of specimens in glass cases. Because of this exhibit design, HMNH’s existing visitor activities are focused on getting visitors to look closely at exhibits and make detailed observa-

27 tions. HMNH’s goals for an indoor TaleBlazer game are the same as for their existing activities. They would like to get visitors to look more closely at exhibits and draw connections between exhibits, while having fun and hopefully deciding to return for a second visit. The goal of getting visitors to spend more time looking at and thinking about specific exhibits instead of looking at everything quickly is particularly important to the museum. HMNH was less concerned with the visibility of infrastructure than some of our other partners. Although visible codes were rejected, small pieces of (sometimes visible) technology were considered acceptable. They were willing to work with whatever level of precision we could offer, although they required some degree of passive location sensing to make using TaleBlazer seem worth the effort to them. With no passive location sensing, they felt they could do as well with the paper activities they already had. Ease of setup was not mentioned as a concern, likely because they knew that they would be working closely with TaleBlazer staff to implement their game.

3.2 Approaches Considered

Indoor navigation is an active research area, so there are many approaches available for consideration. In this section, I will discuss various approaches that were considered for use in TaleBlazer, and explain the benefits and drawbacks of each.

3.2.1 QR Codes, Dead Reckoning, and WiFi Positioning

QR codes, dead reckoning, and WiFi positioning were all considered briefly. The primary benefit of these approaches is that they are low cost and capable ofproviding a high level of accuracy in position. QR codes are square barcodes that can be scanned by a smartphone. A major benefit of using QR codes for positioning would have been ease of configuration. TaleBlazer would generate a code for each agent, and then the game designer could simply print out the codes and place them appropriately. QR codes would provide good precision, because players would need to be close enough to scan the code, and

28 the codes could be printed at various sizes to be more or less easy to find. This approach was largely rejected because of the difficulty partners said they would have in getting permission to post something so visible and unattractive. Additionally, this approach would not really provide much more functionality than the existing password-protected agents because it uses essentially the same idea of verifying indoor positions.

Dead reckoning refers to using a device’s accelerometer and compass to determine a user’s position. A dead reckoning approach calculates a user’s movement away from a known starting position based on the motion of the device. Dead reckoning has been shown to be able to track a user with only 6% error from the path walked in a test run, and could potentially be used not only to locate the player but also to provide a continuous moving-dot display of their position [2]. The dead reckoning approach was discarded because it requires training of models to achieve its high level of accuracy. The accuracy is also heavily dependent on a highly accurate starting position, which could be difficult to ensure in a TaleBlazer game. There is also a possibility of variation in accuracy between devices, because of differences in hardware.

WiFi positioning, which uses detected strengths of WiFi signals to triangulate a user’s position, is a popular idea in indoor navigation. This form of indoor positioning was in fact used in both previous indoor games run by the STEP Lab, though in those games it was only able to determine what room a player was in and not their position within the room. In more recent years, WiFi positioning has been used to create highly accurate indoor positioning systems with a 1.5-meter level of precision, which could be useful for TaleBlazer [7]. Unfortunately, WiFi positioning requires a great deal of setup, because the position calculation is based off of a table of “fingerprints” of WiFi signal strengths at various known locations, which requires someone to collect that data. Also, inconveniently for TaleBlazer, this approach works best when there are many different WiFi access points available around an area. For a small museum with a single WiFi network and few routers, WiFi positioning is unlikely to offer the level of accuracy researchers have accomplished on college campuses.

29 3.2.2 Indoor Google Maps

Indoor Google Maps uses a combination of WiFi positioning, GPS, and sensor data for indoor navigation [4]. The intended functionality of Indoor Google Maps is to provide the same sort of navigation that Google Maps already provides for outdoor areas, with a moving dot displaying the user’s current position on the map. This technology was a strong contender for use as a component of TaleBlazer’s indoor navigation solution. We theorized that if Indoor Google Maps could supply the 6- meter accuracy they claimed [4], it would be quite simple to integrate the Indoor Maps API into TaleBlazer, which already uses the standard Google Maps API. Although 6 meters is not precise enough for TaleBlazer’s indoor positioning goals, because at that distance in a typical museum a player would not necessarily be in visual range of specific artifacts, this approach seemed like a promising solution for wayfinding which could be supplemented with some other approach for positioning. A drawback of this approach was that getting an indoor space on Indoor Google Maps requires submitting floorplans to Google and working with them to map the space, sothere could be a slow turnaround on actually getting an indoor map.

To determine the viability of using Indoor Google Maps in TaleBlazer, I visited various locations offering Indoor Maps to see what the user experience was like.My initial test, in the spring of 2014, was a visit to the Smithsonian Museum of Natural History in DC. This museum seemed like a fair example of a space that an indoor TaleBlazer game might be played in. Unfortunately, the indoor positioning was not successful. For most of the test, the phone I had at the time (an HTC Inspire running Android) either incorrectly placed me outside, or placed me indoors but on the wrong floor of the building. The user dot appeared in the correct room and tracked meacross it only once.

Because technology progresses so rapidly, we hoped that Indoor Google Maps might improve in accuracy by the time I would be implementing the indoor functionality, so we continued this investigation in the fall. During the fall semester, we contacted Google employees who worked on Indoor Maps to ask for a good example

30 of Indoor Maps in the Boston metropolitan area. At their suggestion, we visited the Boston Public Library. Unfortunately, even on a new HTC One Android phone and an iPhone 6, this location had the same problems as the Smithsonian in level of accuracy. Although there remains a possibility that the locations we visited were simply poorly mapped, we concluded that the technology was not yet mature enough for use in TaleBlazer. However, it continues to be a possibility for future versions of TaleBlazer’s indoor navigation.

3.3 Approach Selected: Bluetooth Beacons

The approach we decided to use was Bluetooth beacons, also known as iBeacons after the Apple specification that they follow. In this thesis, I will be referring to them simply as beacons. Figure 3-1 shows some examples of beacons, specifically the models that we purchased for testing. From left to right, the brands are Estimote, kontakt.io, GeLo, and PassKit.

Figure 3-1: Bluetooth beacons

31 3.3.1 Introduction to Beacons

Beacons are small Bluetooth devices that use a technology called Bluetooth Low Energy (BLE) and regularly broadcast packets in the iBeacon format. iBeacon packets contain the beacon’s identifying information and the power level at which the beacon is transmitting. By comparing the advertised power level with the received signal strength of the packet, a mobile device can approximately calculate its distance from a beacon.

The iOS and Android operating systems both provide libraries for determining three proximity levels based on signal strength: immediate, near, and far. According to Apple, immediate is “physically very close to the beacon. Very likely being held directly up to the beacon,” near is 1-3 meters with a clear line of sight, and far is given when the device is not confident enough in the accuracy of the reading to claim immediate or near [3].

Beacons vary in size from just over the size of a quarter to the size of a deck of cards. The variability in sizing is somewhat tied to choice of batteries: a beacon can run on a coin cell and be quite small, or run on easier to replace AA batteries and be much larger. USB beacons also exist, although in a museum space they would likely be difficult to place, because they require a computer or at least a power outlet and adapter. USB beacons do however have the advantage of not requiring batteries, eliminating both the hassle of replacing batteries and concerns about beacons dying unexpectedly. The advertised battery life for beacons ranges from 6 months to over 5 years; it is difficult to gauge how long any given beacon will actually last, because they are such a new product that no one has had beacons for long enough to verify the battery life claims. However, it seems reasonable to expect that beacons will achieve at least half their advertised battery life, and possibly more. Some companies are also introducing the ability to put beacons to sleep during non-business hours, which could lead to significant improvements in beacon battery life. Beacons range in price from small stickers for $10 each to rugged outdoor beacons for $35 each, with most options around $20-30.

32 3.3.2 Advantages of Beacons

Beacons have several advantages for a platform like TaleBlazer. They are easily repositioned and reused in different games. They are easier to set up than most other possible approaches, because they require no calibration. A game designer can simply enter the IDs of their beacons in Taleblazer and place the beacons around their space, and immediately be able to detect when a player is within immediate, near, or far range of those points. Compare this easy setup to WiFi fingerprinting, which requires taking measurements of WiFi signal at every area in the game. Beacons are also much less obtrusive than the other easy-to-set-up approach, QR codes, because they do not need to be visible to the player to be detected by the player’s mobile device. In terms of gameplay functionality, beacons are particularly promising because they offer passive location sensing and multiple levels of precision. As mentioned above, the passive location sensing of outdoor TaleBlazer games is considered one of the most engaging aspects of the games. Being able to bump agents without requiring user action in the UI is a major plus for TaleBlazer’s indoor functionality. The multiple levels of precision are useful because they can support different game mechanics. An immediate trigger could be set for a game where finding a specific small item among other small items was important, whereas a near trigger could be used for finding a specific large item in a gallery. Far triggers could be usedtogive hints or warn users they were moving too far away from a game area.

3.3.3 Drawbacks of Beacons

Although beacons have many advantages as an indoor navigation approach for Tale- Blazer, they also have some drawbacks. Since BLE is a new technology, only newer smartphones feature the option to listen for beacons. However, we feel that because progress in smartphones is so rapid, in the near future most smartphone users will have BLE-enabled phones. Similarly, the cost of purchasing beacons is a concern that we hope will be mitigated with time as beacons become more common and inexpensive. Although at the current prices, beacons are too expensive to be practical for

33 TaleBlazer’s non-professional target audience, this barrier will hopefully be removed in the future.

34 Chapter 4

Implementation

The implementation of the indoor functionality had three distinct phases. The first phase was conducting simple feasibility tests with the beacons. The second phase was deciding what exact functionality the beacons would provide. The final phase was the implementation of the chosen functionality in the TaleBlazer software.

4.1 Preliminary Testing

We purchased an assortment of beacons from various companies, selected based on their different sizes, price points, and claimed battery life. Most of our purchased beacons were also waterproof, which is of minor interest, as it might become relevant if someone were to want to use the beacon functionality in an outdoor game or even for an indoor use such as a game in a humid greenhouse. Table 4.1 summarizes our beacon purchases. The first round of basic feasibility testing consisted of simply detecting the beacons in a Titanium app. Although iBeacon functionality is provided by both the iOS and Android operating systems, it is not directly supported by Titanium’s core libraries. Instead, it is necessary to use what Titanium calls modules, libraries extending Tita- nium’s functionality to include additional features from a particular operating system. Modules can be created by Appcelerator or by third-party developers. Although Ti- tanium does not supply iBeacon modules, both Android and iOS third-party iBeacon

35 Table 4.1: Purchased Beacons

Type Estimote beacon kontakt.io GeLo Passkit GemTot Price $99/3 $135/5 $35 each $25/2 Battery life 3 years 6 months 2 years N/A Power source Single-use battery CR2477 battery AA batteries USB Size 5.3 x 3.5 cm 5.5 x 5.5 cm 8.7 x 4 cm 1.8 x 1.3 cm Waterproof Yes Yes Yes No

modules are available for use: liferay-android-beacons for Android [1] and TiBeacons for iOS [5]. We were thus able to use iBeacon functionality without needing to develop our own modules. After creating a Titanium app that could detect the beacons, the next step was checking what distances were reported as immediate, near, and far. I found that on my Android device, an HTC One smartphone, the distance at which the readings switched from immediate to near was generally around 3 feet, but varied from 14 inches to 56 inches, while far was hardly ever detected by my phone. On iOS devices, I found that getting an immediate reading tended to require the device to be held closer to the beacon than with the Android, and sometimes also for a longer period of time before it would register. The major discrepancy between iOS and Android was the outer boundary of near readings in open space, which on Android devices was sometimes far out as 75 feet, while the iOS devices needed to be within 25 feet to get a near reading. Since our primary concern was close interaction, which we envisioned as using the immediate reading, we decided that these levels of precision were good enough to go forward with.

4.2 Design Decisions

Once we had determined that using beacons for indoor positioning would be feasible, we had to decide how precisely to integrate them into TaleBlazer. The first major decision was whether to use the beacons only for positioning, in the form of point

36 interactions, or to try to use them for both wayfinding and positioning by triangulat- ing the player’s position and creating a moving-dot positioning system like the one provided by GPS. We decided to use beacons for point interactions because that is the use they are designed for. Additionally, I expect that Indoor Google Maps will become viable in the near future, and preferred to focus on an approach that could be supplemented by the use of Indoor Google Maps rather than being replaced by it. Once we had decided to use point interactions, we had to decide how beacons would be linked to agents. Our initial thought was that a beacon could be the location of a single agent, allowing a simple one-to-one association between them. However, we soon realized that that would be impractical, in large part because beacons, though relatively inexpensive, are not so cheap that it is reasonable to require a game designer to use one beacon for each agent in their game. It is not uncommon for even small TaleBlazer games to have 20 agents. Also, in some TaleBlazer games, it may be useful to have two different agents appear at the same location at different pointsin the game. Because of these considerations, we decided to allow each beacon to be associated with multiple agents. Our third decision was whether and how to use the immediate, near, and far readings. Initially, I had thought we would only use the immediate reading as a trigger, because I had been focused on enabling close interactions, which are a major strength of the beacons. However, we realized that for our pilot version of the software we could learn more by allowing agents to be set to trigger at any of the readings and testing the different behaviors, so we decided to allow the game designer to setwhich reading should trigger an agent.

4.3 Software Changes

The first step in adding beacons to TaleBlazer was enabling beacons to beaddedto a game, by adding beacons to the game file format and adding beacon configuration functionality to the editor. The next step was adding beacon sensing to the mobile app so that the beacons could be used for gameplay. The final change was adding a

37 check for beacon support, so that players can avoid downloading a game with beacons if their device does not support the beacon functionality.

4.3.1 Game Creation

A beacon is identified by a three-part ID, which takes the form of a 128-bit UUID, a 16-bit major, and a 16-bit minor. The UUID is generally shared by all beacons created by the same manufacturer, while the major/minor pair uniquely identifies the beacon within the set of beacons created by that manufacturer. In order to use beacons, a game must contain a list of beacon IDs, so the very first step of implementation was adding a list of beacons to the game file format. To help game creators keep track of their beacons, a beacon in TaleBlazer also has a nickname field, which can be used to store a description of the beacon’s physical location. Once beacons were included in the game file format, the next step was adding the user interface for configuring beacons to the editor. This step was done very simply, with a focus on enabling a pilot in the mobile app as quickly as possible. As such, the usability and learnability of this editor feature was not given much thought, and improving the UI is high on the list of future priorities (see Section 6.1). To configure beacons, there is a new “beacons” tab, analogous to the already existing “agents” tab (Figure 4-1). The beacons’ identifying fields– UUID, major, minor, and nickname– can all be entered on this tab. This tab also contains the bump settings for beacon agents, an overall control for the behavior of agents triggered by beacons separate from the overall settings for the behavior of agents triggered in the standard way (Figure 4-2). On the agents tab, the agents now have the option to be triggered by a beacon (Figure 4-3). With the “bump this agent via a beacon” option selected, the game designer can select which beacon to trigger on, and whether to trigger on immediate, near, or far.

38 Figure 4-1: Beacons tab in TaleBlazer editor

Figure 4-2: Beacon agent bump settings in TaleBlazer editor

39 Figure 4-3: Agent beacon settings in TaleBlazer editor

To configure a beacon in a game, the game designer first needs to find thebeacon’s identifying information. In the current implementation, they will need to use software provided by the beacon manufacturer to collect this information, and then enter it into the beacons tab by hand. Once the beacon has been entered, it will appear as an option in the dropdown list of beacons when “bump this agent via a beacon” is selected for an agent, and the game designer can proceed to select the range reading which should trigger an agent bump. When all the beacons and agents have been configured and the game has been saved, the game is ready to be downloaded and played in the mobile app.

4.3.2 Gameplay

The changes for gameplay were straightforward. As mentioned above, there are existing Android and iOS modules for using beacons in Titanium, which were used in the feasibility testing stage. To access beacons from within TaleBlazer, these modules simply needed to be integrated into the TaleBlazer app. Listening for beacons has two modes: monitoring and ranging. Monitoring tracks when a device moves in and out of range of hearing a beacon, while ranging produces the immediate, near and far readings which are used in TaleBlazer. An app can listen for individual beacons by UUID, major and minor, or for all beacons with the same

40 Figure 4-4: Agent ordering example

UUID and major, or for all beacons with the same UUID. For simplicity’s sake, since a TaleBlazer game file stores beacons as individual entities and does not know about shared UUIDs or majors, TaleBlazer turns on ranging for each beacon in the game separately using all three ID fields.

When an app enables ranging for a particular beacon, the mobile device listens for iBeacon packets containing that beacon’s identifying information. When it receives such a packet, it compares the received signal strength of the packet against the power level advertised in the packet, and uses that comparison to estimate the distance to the beacon. The estimated distance is then translated into an immediate, near, or far reading which is passed to the app.

TaleBlazer keeps track of the most recent reading it has heard for each beacon in the game. When the app checks to see if any agents should be bumped, it runs through the list of agents, and for each beacon agent compares the trigger setting to the stored reading for the corresponding beacon. Agents are bumped if the stored reading is within the range of the trigger, so a near agent triggers on both immediate and near readings, and a far agent triggers on all readings. The check for agent bumps was initially implemented on a timer, but for better responsiveness the code was changed to run the check as soon as the reading for a beacon changes.

The order in which agents trigger is the order in which they appear in the game file, which is the same as the order of the agents as displayed in the agentribbon in the editor. Figure 4-4 gives an example of agent ordering in the editor. In this example, all the agents are associated with the same beacon, but set to trigger at

41 different ranges. If the player were in immediate range of the beacon associated with these agents, the game on the left would display the immediate agent, then the near agent, then the far agent, while the game on the right would display the far agent, then the near agent, then the immediate agent. After this functionality was implemented, I conducted some simple battery life tests to determine how much ranging for beacons drains a mobile device’s battery. I found that a game with 3 beacons was no different in battery drain from a game with no beacons, while a game with 9 beacons only reduced the total battery life of the device by 15%. For more details on the results, see Appendix A.

4.3.3 BLE Support Check

The check for BLE support is designed to give the user meaningful feedback before they try to play a game that will not work on their device. The check provides a graceful failure mode for devices which do not have BLE enabled; for devices with BLE support, it serves as a check to ensure that Bluetooth is turned on. To support this check, we first added a beacon flag to the backend. TaleBlazer game information is downloaded in two steps. First, the app downloads a small amount of basic information on the game, such as its name and file size. This information is displayed to the user before they confirm that they want to download the game. With the beacon flag added to this information, TaleBlazer can run theBLE check when the user asks to download a game with beacons, and let them know that they cannot play the game without downloading the game file. Running the check at this stage also means that the check can be run only for games that actually use the beacon functionality, and not inconvenience users who only play games without beacons. The check itself is provided by the Titanium modules for handling beacons, which both include a function to check if the device the app is running on has BLE. Unfor- tunately, the platforms provide different levels of detail in the result of the check. On both platforms, the check can only pass if Bluetooth is currently on, but on Android the check has only a single failure type. Thus, an app cannot tell if the check failed

42 Figure 4-5: Android beacons not supported message because Bluetooth was off or because BLE was unsupported. However, this compli- cation is not currently relevant, because for reasons which will be explained in section 5.2, we decided to drop the Android functionality from this version of TaleBlazer Indoor. On Android devices, regardless of whether the device has BLE support, the BLE check result screen displays “Sorry, you can’t play this game because it uses beacons and TaleBlazer does not support beacons on Android at this time.” (Figure 4-5). On iOS devices, the check can determine that BLE is not supported even with Bluetooth off, in which case the check result screen displays “Sorry, you can’t play thisgame because it uses beacons and this device can’t communicate with beacons.” (Figure 4- 6). If the device does have BLE but Bluetooth is off, the BLE check will find that Bluetooth is off and TaleBlazer will prompt the user to turn Bluetooth on andre-run the check (Figure 4-7).

43 Figure 4-6: iOS beacons not supported message

Figure 4-7: iOS prompt to turn on Bluetooth

44 Chapter 5

Pilot with HMNH

In order to test the new indoor functionality, we conducted a pilot game with HMNH. The game, Super Survivor, was designed for 6 to 10 year olds to play with their parents in about half an hour.

5.1 Game Design

As mentioned above, HMNH uses a traditional approach to exhibits, consisting mainly of specimens in glass cases. Many of the exhibits are arranged by some classification, such as ungulate mammals, instead of in dioramas, and most of the exhibits are non-interactive and cannot be touched by visitors. Because of these constraints, HMNH’s existing visitor activities focus on having visitors make close observations of exhibits. A benefit they hope to derive from using TaleBlazer is the ability to provide an overarching story to guide the activity, instead of simply directing visitors to look at various exhibits. We worked closely with Arielle Ascrizzi, a member of the Digital Initiatives staff at the museum, to design our pilot game, Super Survivor. The target age group for Super Survivor was tweens between 6 and 10 years old, because HMNH would like to have more draw for that demographic. Like HMNH’s other activities, the goal of the game was to make visitors make close observations of particular specimens.

45 5.1.1 Game Overview

Super Survivor is set in HMNH’s Africa, New England Forests, and Great Mammal Hall animal exhibit halls, and teaches players about various adaptations animals can make to survive in different environments. The goal of the game is to design ananimal that would be able to survive in one of three biomes– the rainforest, the tundra, or the desert– which the player is randomly assigned at the beginning of the game. The biome assignment screen includes some basic information about the biome, to help players figure out what traits might be useful in that environment. Figure 5-1shows the tundra assignment screen.

Figure 5-1: Super Survivor biome assignment screen

46 Figure 5-2: Super Survivor trait selection screen

The player designs their animal by selecting traits from animals in the exhibit halls. For each of four traits– size, body covering, teeth, and feet– the player is sent to look at three different neighboring animals and select which animal they would like to mimic for that particular trait. For example, for size the player can select between the size of a moose, of a sheep, and of a mouse deer, while for feet the player can select jumping feet like a wallaby, digging feet like a wombat, or webbed feet like a platypus. Figure 5-2 shows the feet selection screen. As players make their decisions, they receive feedback on how well an animal with their chosen adaptation would survive in their assigned environment. Based on feedback from our pre-pilot testing (see Section 5.2.2), the final pilot game also included the option to go back and make a different choice of adaptation (Figure 5-3). Pre-pilot feedback also led to the inclusion of a star rating at the end of the game, which let the player know how well they did on a 3-point scale (Figure 5-4).

47 Figure 5-3: Super Survivor trait feedback screens

Figure 5-4: Super Survivor end screens

48 Figure 5-5: Super Survivor directions screens

5.1.2 Game Mechanics

Super Survivor’s game interaction model was heavily influenced by the arrangement of HMNH’s display cases. Because most exhibits are behind glass, we decided it would be difficult to support the very close interaction model of tagging aspecific animal in a case with a beacon and requiring the player to bring their device close that animal. Additionally, we did not have enough beacons to tag all twelve animals in the game. It was also unclear how we could effectively direct players to find the animals in the close-interaction approach, because finding them by only their name seemed too difficult, while displaying a picture would remove the need to physically find the animal to examine it. Our solution was to direct players to look for a familiar “landmark” animal in the vicinity of the three animals the player could select from for each trait. This direction takes the form of an icon on the map and an image of the animal to look for (Figure 5-5). Instead of requiring the players to get very close to the landmark

49 animal, the game considers them close enough when they stand near that animal, thus avoiding the difficulty of placing the beacon extremely close to the landmark animal or any of the selectable animals. The flow of the game is that a player selects a trait to choose, is directed tothe landmark animal, finds the landmark animal, and is directed to find the threechoice animals nearby and then make a decision. For example, when the player selects “choose your feet,” they are directed to look for a koala; when they reach the koala, they are prompted to look nearby for a wallaby, a platypus, and a wombat, and then choose which animal’s feet they would like to have, with the option to change that choice based on the feedback provided by the game.

5.2 Pre-pilot tests

In order to have as smooth a run of the pilot game as possible, we conducted multiple rounds of testing before the pilot. Our first test was conducted with only TaleBlazer staff and Arielle, and simply checked the behavior of the beacon triggers. Our second test was conducted with members of the museum staff, and consisted of having them play through the first complete version of the game.

5.2.1 First pre-pilot test

This test was our first experiment with the beacons placed as they would bein the game, with some beacons inside cases and behind glass. This test had a very significant result, which was that we determined that the discrepancy between iOS and Android was too extreme to continue using the beacons in the same way across both platforms. In particular, from our preliminary testing in the lab, we had thought that the approximately 3-foot radius of the immediate reading on Android was shared with iOS, and so used that as our main proximity check, while near was used to give intermediate directions. In practice, with the glass cases attenuating the signal, the iOS devices had to be held within a foot of the beacon to get an immediate reading, while the Android devices continued to register immediate within 3 feet of the

50 beacon. More jarringly, the near reading registered at very inconsistent distances on the different Android devices, and sometimes as far away as halfway across a different room. The iOS devices were much more consistent, giving immediate readings within approximately half a meter, near within 3 meters, and far within 20 meters of the beacon. Based on these results, we decided that it was not practical to present the same game on both platforms, because the user experience would be so different. Because the iOS devices were consistent with each other, we decided to use only iOS devices for the pilot. In the future, hopefully newer iterations of Android BLE support will allow beacons to be used on Android without requiring calibration of the distances for the readings, which is currently the only possible solution to the discrepancy. Based on the distances we measured for the iOS range readings, we decided that our planned game flow could implemented using the near and far triggers instead ofthe immediate and near triggers. In order to also test the immediate trigger, because the close interaction that provides could be useful in a TaleBlazer game, we added a new game component in which leaning close to the beacon triggered a “fun fact” popup.

5.2.2 Second pre-pilot test

Our second pre-pilot test was a play-through with members of the museum staff. This test was intended primarily to find any problems with the game flow. We hadtwo main game-design takeaways from this test: that the game would be improved by adding the option to redo the choices after making them, and that the immediate trigger fun facts were not well integrated into the game. However, although the immediate trigger component of the game stood out as a late addition that did not mesh with the flow of this particular game, no one had been confused by the mechanic of leaning in to trigger the popup. Thus, we concluded that the mechanic worked, but since the gameplay was not well served by our use of it we removed the fun facts from the game. As mentioned above, we added the requested option to redo the choices, which we expected would improve the educational value of the game by allowing players to learn from their mistakes if they made a poor choice of adaptation.

51 Another simple game mechanic change that was requested and implemented for the pilot was the star rating at the end of the game. Another major result of this test was the experience of losing a beacon. For this test, the beacons were simply placed where they would be for the game, with no signage indicating that the beacons were supposed to be in those locations. As a result, one of the beacons was picked up by a visitor and returned to the gift shop. The disappearance of the beacon was discovered when some of the testers complained that they had been in the correct location for a long time without having the game register that they were there. When we investigated, we found that the game had not detected their location because the beacon was gone. This event raises some concerns about using beacons in a real game. It may be unlikely that this would occur in a real game, as in a real game the beacons would be secured to their locations. However, it will likely be important to place the beacons as out-of-reach as possible, and provide some indication that they belong where they are and should not be moved by visitors.

5.3 Pilot Results

We conducted our pilot test with nine families who visited the museum on a Saturday. Most of these families were recruited for the pilot by an email from the museum, but some were recruited from the regular museum visitors to fill in for families who failed to show up. Among the nine families, we had seven groups with one adult and two groups with two adults. We had one family with three children, four families with two children, and four families with one child. The children’s ages ranged from 6 to 12, with an average age of 8 and a half. The game was played in families, with one device per family. The devices were iPads and iPhones provided by TaleBlazer and museum staff, because the indoor version of TaleBlazer was a test build andthusdue to the constraints of the Apple development environment could not be easily installed on the participants’ personal devices. In order to determine how successful the game was, we followed an observation protocol while the families played the game, administered a post-game survey, and

52 Figure 5-6: Players lean in to closely examine animals conducted a focus group with the families after each run. The observation protocol, post-game survey, and focus group questions are given in Appendix B. We conducted three separate runs in order to have an observer for each family. The amount of time each family took to complete the game ranged from 11 minutes to 31 minutes; the average duration was 20 minutes.

5.3.1 Observation

Our observation data showed that the children were for the most part highly engaged by the game. Only two children were observed to be off-task, one of whom was visibly not feeling well during the game. Three of the children spent a fair amount of time on what we considered related tasks, looking at exhibits but not focusing on the game. The others were on-task for the vast majority of the game. The adults frequently took an active role in playing the game, reading the text to the children and discussing the choices with them. In observing the gameplay, we were particularly pleased to note that the players were looking very closely at the exhibits- many players bent down to the ground to get a closer look at an animal’s teeth or feet (Figure 5-6). One potential issue that was noticed during the observation was that the location-

53 based aspect of the game was not obvious. Although game events were triggered by proximity to the beacons, the UI may have prevented players from noticing that this was the case. Many players left the agent with the picture of the landmark animal open to help them find it. TaleBlazer requires the open agent to be closed before the next agent can be bumped, leading some players to think that it was the action of pressing the OK button, which closed the agent and allowed the next agent to be bumped, that let the game know that they had arrived at the correct location.

5.3.2 Post-game Survey

On our post-game survey, we received very positive feedback. All of the participants said that they would like to play the game again, either immediately or on a subse- quent visit to the museum. Most reported that the game was a good level of difficulty. There was some disagreement about the length of the game, with results split between too short and just right. The remainder of the survey used a 5-point Likert scale for questions such as was the technology intuitive, was the game fun, etc. The survey contained questions for the entire family, questions for the adults, and questions for the children. For all of our questions, the average rating was at least 4, with many above 4.5. Our lowest individual response was a 1 for “the technology was intuitive,” but that seemed to be because the family’s father had a strong dislike for some of the UI style elements, and not anything fundamental to the technology. Discounting that response, the average for that question was 4.4. Table 5.1 gives the results of the questions for the families, Table 5.2 gives the results of the questions for the adults, and Table 5.3 gives the results of the questions for the children.

Table 5.1: Post-game Survey Results for Family Questions

It was easy to start playing the game. 4.3 The technology was intuitive 4 (4.4) I felt like I knew what I was supposed to be doing throughout the game. 4.4

54 Table 5.2: Post-game Survey Results for Adult Questions

I felt this was a meaningful activity 4.4 This was a fun way for kids and grownups to spend time together 4.8 This activity made me think about museum exhibits in new ways 4.6 I would recommend this activity to other visitors. 4.6 This was a fun way to visit the museum and look at exhibits 4.4 I enjoyed finding the real objects in the exhibits 4.9 I would want to play a game like this again 4.9

Table 5.3: Post-game Survey Results for Child Questions

This was a fun way to visit the museum and look at exhibits 4.8 I enjoyed finding the real objects in the exhibits 4.6 I would want to play a game like this again 4.8 I liked the story 4.6

Overall, the results from our post-game survey showed that all the participants enjoyed playing the game, did not struggle with the technology, and found playing the game to be a good way to use part of a visit to the museum.

5.3.3 Focus Group

The focus group also provided positive feedback. As they reported in the surveys, most of the families enjoyed playing the game and found the structure of the game entertaining and educational. All the players agreed that they would like to see the game offered at the museum, that they would like to replay the game, andthat they would recommend the game to families within the target age range. While one family commented that the game felt disjointed and their child could not remember the storyline, they still said that they would replay the game and recommend it to others. The parents found that playing the game was a good way to spend time with children in the target age range; they thought that children younger than the suggested range would have trouble with the reading, and children much older than the suggested range would likely be bored. Some parents commented that the game

55 helped them have a discussion with their child rather than simply looking at the animals with them. Many participants mentioned that they enjoyed being made to look more closely at the exhibits, which they felt they would not have done otherwise.

With regards to the indoor navigation technology, no one had trouble with the beacon triggers, but some participants suggested improvements on the wayfinding. The suggested improvements included offering more directions in the larger room, offering a “getting warmer/getting colder” indication of proximity, and using amoving- dot indicator of position. However, in general, the consensus was that any difficulty in finding the animals was probably a good thing, as it caused players to viewmore of the exhibit. With respect to the beacon triggers, one family had an agent trigger while facing away from the animal they were supposed to be looking for, but they did not find that to be confusing. While some players, as mentioned above, thought that they had had to press OK to let the game know they had found the animal, others said that they thought the game had sensed their location and that this feature was cool.

There were some concerns about the game aspect causing the children to rush through the exhibits. Multiple families mentioned that they felt compelled to hurry on and complete the next task, rather than linger in a room and look at the other parts of the exhibit that were not included in the game. However, some families noted that this was a problem they usually experienced at museums, and the game did not make it worse. Most agreed that a simple game modification would likely make them slow down and look at the other exhibits. The suggested modifications were simply adding text to suggest looking around the room and moving on when ready, or adding a progress bar to convey how much more time they could expect to spend in the game. The players also agreed with the suggestion that if they had not been being observed, they would have been more likely to take extra time to look around even without these modifications. Overall, although rushing through the game was a common concern, the consensus was that it would be fairly easy to mitigate this concern.

When ideas for changes to the game were solicited, the most common change

56 suggested, aside from allowing the player to pick the biome their animal would live in and ending the game with a picture of their hybrid animal, was adding more content to the game. Even the players who had said the length of the game was just right showed enthusiasm for adding more exhibits. Wanting more content is good in terms of how much the players liked the game, but a potential concern in that the current setup requires a beacon per exhibit visited, and so expanding the game is limited by how many beacons the museum can afford to use. However, inasmuch as the game was designed to take 20 minutes and on average took that much time, and half the players reported that it was a good length, it can be concluded that not adding many more exhibits to the game would not be detrimental to the game’s success.

5.3.4 Pilot Conclusions

Overall, the results of our pilot test showed that beacon-based indoor functionality in TaleBlazer can be used to create a very successful educational AR game in a museum like HMNH. Super Survivor was clearly successful in achieving the goal set out for it of having players look more closely at exhibits and take time to make observations about those exhibits. A particular highlight of the focus group discussion was that multiple players specifically noted that the game was enjoyable because it made them make close observations, and that they liked the way the game seemed to sense where you were automatically. The beacon location technology was unobtrusive and succeeded in passively detecting the players’ locations and pushing information to them at appropriate times. In fact, the beacons were so unobtrusive that during our pre-pilot testing, one participant even said, “I don’t know why you even need the beacons.” Given the success of the pilot, TaleBlazer is planning to release a version with the new indoor functionality for public use, and HMNH will work with us to publish Super Survivor and use it as one of their visitor activities.

57 58 Chapter 6

Future Work

Although the pilot game was a great success, there is still plenty of work to be done to improve TaleBlazer’s indoor functionality. Currently, beacon configuration in the editor is more difficult than creating a TaleBlazer game ought to be.Some improvements for the usability of the editor have already been planned. Adding support for the beacon functionality on Android is another important next step, because TaleBlazer is meant to be a cross-platform application. Further testing of beacon-enabled games will give more information on the success of the various game mechanics possible with beacons. Finally and most ambitiously, an approach using the beacons for real-time player positioning can be investigated for viability.

6.1 Editor Usability Improvements

In the current version of the beacon-enabled editor, users have to enter the IDs (UUID, major, and minor) of their beacons by hand. This requirement is particularly problematic for the UUIDs, which are 32 hexadecimal digits long. We will provide a list of manufacturer UUIDs that users can copy and paste from, but this is not an ideal solution, both because it requires the list to be maintained somewhere obvious to users and because users may choose to purchase beacons from a company that is not included in the list. Furthermore, while the UUID for a manufacturer can be discovered online, the major and minor values of a beacon can only be found through

59 the inclusion of that information in the beacon shipment or, more commonly, by using a mobile device to listen to each beacon in turn. Finding major and minor values at this point needs to be done using an app other than TaleBlazer, which cannot listen for generic beacons and display their information.

A very significant improvement in the usability of TaleBlazer’s indoor game creation tools would be adding beacon-scanning ability to the TaleBlazer mobile app. The plan is to offer a new tab for “beacon scanning” to users logged in to their game creation accounts in the mobile app. On this tab, a user would see the IDs of any beacons the device currently hears, ordered by proximity to the device; proximity ordering is necessary because the user must be able to associate the ID information with an individual physical beacon. The user could then enter nicknames and location information for their beacons (for example, “beacon A” and “in the Mammal Hall by the koala”) and upload the beacon information to the server, where the beacons would then be available for use in their games through a selection palette.

Another useful addition would be a “beacon checking” tab in the mobile app, which would help the game designer check that their beacons are still working. Like the scanning tab, this tab would only be available to game designers who are currently logged in. The functionality of this tab would be to display the beacons associated with the game designer’s account. The game designer would then walk around their space, visiting the locations of each of the beacons, and the app would give some visual indicator when it heard from each beacon. If all the beacons are working properly, they should all be detected by the app. If the app fails to detect a beacon, the game designer knows that something is wrong and can check on that beacon. This functionality would assist greatly in the upkeep of beacon-enabled TaleBlazer games, because detecting when a beacon no longer has power or is missing and replacing it promptly is necessary to keep the game running correctly.

These modifications would also include some form of support for replacing non- working beacons. This could take the form of an “upload as replacement beacon” option on the scanning tab, which would allow a user to select a beacon existing in their account to overwrite with a new beacon’s ID information. Alternatively, the

60 checking tab could present a “replace beacon by scanning new beacon” option for beacons that it does not pick up in its scan. This approach would require the user to let the app know that the scan is over, so that it can differentiate beacons not found from beacons yet to be found, but might be simpler to understand because acting on the results of the scan would happen in the same place as the scan itself.

6.2 Adding Android Support

While limiting the pilot implementation of the indoor functionality to iOS devices greatly simplified the work needed for the pilot game, eventually this functionality should be provided on both iOS and Android. Luckily, the discrepancy between the platforms is likely to be reduced with time, because both platforms intend to provide the same beacon functionality, with the specifications set by Apple. As the useof beacon technology becomes more common, then, newer iterations of Android beacon support will hopefully become more compatible with the standard set by iOS, allowing TaleBlazer to simply use the range readings provided by each operating system.

In the meantime, a possible solution to the discrepancy might be providing an in- TaleBlazer range calculator for Android. While iOS does not allow apps to directly access the information needed to calculate a range reading, Android does. It might be possible to develop an algorithm for calculating range readings on Android that would give readings more similar to those provided by iOS. This could involve either using different distance constants to define immediate, near, and far readings, or performing a different calculation to find the approximate distance, or both.

The real-time player positioning approach discussed below could provide an alter- native solution to this problem, in which all location information is calculated based on the relative signal strengths of different beacons heard by a single device.

61 6.3 Further Tests

The Super Survivor game provided a good test of the near and far triggers, and a small test of the immediate trigger, which was removed for the actual pilot run because it was not well integrated into the flow of the game. Although we are confident that the immediate trigger would work as desired, conducting a pilot test with a game including the immediate trigger would be a good confirmation of that belief. The immediate trigger would most likely be useful for very close interaction with exhibits; for example, in a botanical garden one could place a beacon by a specific plant and require players to get very close to that plant to verify that they have found it. Running a game with this functionality would help us determine if the immediate trigger is in fact precise enough for this use or if adjustments to either the game design or the implementation of the trigger will be necessary. In a similar vein, other tests of possible beacon-based game mechanics could be run, such as a game in which players do not seek out specific objects tagged with beacons, but are spontaneously directed to take actions as they approach beacons of which they are unaware.

Another useful test would be a game involving a greater number of beacons. In Super Survivor, we used only five beacons, one for each station and a tutorial. Atest with more beacons would not only be useful as a gameplay test, but also as a test for the editor. This test would help us determine if the way TaleBlazer allows the game designer to organize their beacons is clear enough that they will not become confused when trying to keep track of a dozen or more beacons. The test could also reveal undiscovered issues with the back-end implementation of beacon tracking; it might be the case that TaleBlazer should not track all beacons in a game at once, but instead should turn tracking on and off for sets of beacons as players progress through the game, in order to preserve the device’s battery. Although tracking 9 beacons at once had only a small effect on the battery, it could be the case that a game withmany more beacons would have a much more significant effect.

62 6.4 Using Beacons for Real-Time Player Positioning

A third area for future work is using beacons to triangulate the player’s position in real time. The player’s position could then displayed as a moving dot on the map, as with GPS positioning. If this approach turns out to be able to provide precise enough indoor positioning, it could be useful for wayfinding in museums with larger spaces than HMNH. Being able to have agents located at points in space other than at beacon locations would also be useful, particularly for the game development process in which the game designer might want to change the placement of agents or add more agents to the game without needing to modify the arrangement of the beacons. Because this approach involves calculating position based on the relative signal strengths of multiple beacons heard by a single device, instead of comparing a single beacon signal to standard values, it could also potentially solve the problem of the discrepancies between the two platforms. This follow up area of research is actively being pursued by the TaleBlazer team.

63 64 Chapter 7

Conclusion

TaleBlazer is a mature platform for creating and playing location-based AR games. With the implementation of the new indoor functionality, TaleBlazer becomes more valuable to a wide range of users with primarily indoor spaces, a significant subset of TaleBlazer’s target audience of informal educational spaces. The success of the pilot game at HMNH demonstrates that the beacon-based approach can be used to create very effective indoor TaleBlazer games. In the future, further work with beacons will hopefully lead to the development of even more intuitive and engaging indoor functionality in TaleBlazer.

65 66 Appendix A

Mobile Device Battery Drain Tests

Table A.1: Battery Drain Test Results

Baseline- no GPS, no Bluetooth 3 beacons 9 beacons 1 hour 92 92 92 2 hours 81 80 77 3 hours 69 69 64 4 hours 57 57 50 5 hours 45 44 35 6 hours 32 33 20 7 hours 20 20 5 8 hours 8 8 –

Shutdown 8:33, 513 minutes 8:35, 515 minutes 7:16, 436 minutes

The tests were conducted on an iPad with TaleBlazer open in indoor mode (no GPS) and the screen set to never turn off. For the baseline test, Bluetooth was also turned off. As most TaleBlazer games are less than an hour long, it seems likelythat for most users playing a beacon-enabled game would not see a noticeably different battery drain from users playing a game without beacons in it. Even if a user were to have a beacon-enabled game open for longer than an hour, the difference in battery drain remains very slight, and the increased battery drain is well within acceptable limits.

67 68 Appendix B

Research Instruments

This appendix gives the observation protocol (Section B.1), post-game survey (Section B.2), and focus group questions (Section B.3) that were used during the pilot test at HMNH.

69 B.1 Observation Protocol

START TIME: ______END TIME: ______

Observer's Name ______GROUP CODE #: ______

Adult 1:YES / NO HELD DEVICE? ALL / SOME / NONE Adult 2:YES / NO Coding/Definitions of Fields: HELD DEVICE? ALL / SOME / NONE LOCATION: Child 1:YES / NO MOL Mollusk/Tutorial HELD DEVICE? ALL / SOME / NONE AFR Africa Child 2:YES / NO NA North America HELD DEVICE? ALL / SOME / NONE MAM Mammals

ENGAGEMENT (KIDS): ON On-task (look, navigating, discussing game) Related Related task (ex: looking at other objects in case) OFF Off Task (anything else)

ENGAGEMENT (ADULTS): ACT Actively playing (parent facilitates or plays game with child e.g., locates objects, navigates, reads text on screen) OBS Observing (parent quietly watches without actively involving him/herself in activity) DIS Disengaged (parent neither observes nor participates, can be off-task)

START TIME: ______END TIME: ______

Time Location Child #1 Adult #1 Child #1 Adult #1 NOTES 0:30 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

1:00 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

1:30 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

2:00 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

2:30 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

3:00 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

3:30 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

4:00 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

4:30 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

5:00 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

5:30 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

6:00 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

6:30 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

7:00 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

7:30 MOL NA AFR MAM YES REL NO ACT OBS OFF YES REL NO ACT OBS OFF

70 B.2 Post-game Survey

HMNH/MIT Spring Pilot - Post-Activity Survey Code: ______

Thank you for participating in our pilot study. Your responses will help us learn how to make interesting new types of museum experiences. A. Please tell us about yourselves!

Participating Parent/Adult #1 (Please circle one per row) 1. Adult’s relationship to child MOM DAD OTHER 2. Before today’s visit, how familiar were YOU VERY SOMEWHAT NOT AT ALL with these exhibits at HMNH?

Participating Parent/Adult #2 (Please circle one per row) (*if applicable) 3. Adult’s relationship to child MOM DAD OTHER 4. Before today’s visit, how familiar were YOU VERY SOMEWHAT NOT AT ALL with these exhibits at HMNH?

Participating Child #1 (Please circle or fill in one response per row) 5. Child’s Age ? 6. Child’s Gender ? 7. During today’s game, how much did this child ALL OF SOME OF THE NONE OF THE hold the mobile device? THE TIME TIME TIME 8. Typically, this child uses a smartphone or OFTEN OCCASIONALLY NEVER tablet… 9. Before today’s visit, how familiar was this child VERY SOMEWHAT NOT AT ALL with these exhibits at HMNH?

Participating Child #2 (Circle/fill in one response per row) (*if applicable) 10.Child’s Age ? 11.Child’s Gender ? 12.During today’s game, how much did this child ALL OF SOME OF THE NONE OF THE hold the mobile device? THE TIME TIME TIME 13.Typically, this child uses a smartphone or OFTEN OCCASIONALLY NEVER tablet… 14.Before today’s visit, how familiar was this child VERY SOMEWHAT NOT AT ALL with these exhibits at HMNH?

71 HMNH/MIT Spring Pilot - Post-Activity Survey Code: ______B. Now, tell us about your experiences today playing the game. Circle one response per line. 15.During this game, we used an… iPHONE iPAD 16.Overall, I would say that this game’s length TOO SHORT JUST RIGHT TOO LONG was… 17.Overall, I would say that this game’s difficulty TOO EASY JUST RIGHT TOO HARD was… 18.I’d want to replay ‘Super Survivor’ in a DURING different climate (e.g., desert, tundra, RIGHT NOW ANOTHER NEVER rainforest)… VISIT

C. Please tell us how much you AGREE or DISAGREE with each item. STRONGLY STRONGLY Circle one response per line. DISAGREE AGREE 19.It was easy to start playing the game. 1 2 3 4 5 20.The technology was intuitive to use. 1 2 3 4 5 21.I felt like I knew what I was supposed to be doing 1 2 3 4 5 throughout the game.

D. A few questions just for ADULTS: STRONGLY STRONGLY Circle one response per line. DISAGREE AGREE 22.I felt this was a meaningful activity. 1 2 3 4 5 23.This was a fun way for kids and grownups 1 2 3 4 5 to spend time together. 24.This activity made me think about museum 1 2 3 4 5 exhibits in new ways. 25.I would recommend this activity to other 1 2 3 4 5 visitors. 26.This was a fun way to visit the museum & 1 2 3 4 5 look at exhibits. 27.I enjoyed finding the real objects in the 1 2 3 4 5 exhibits. 28.I would want to play a game like this again. 1 2 3 4 5

E. And a few final questions for KIDS: STRONGLY STRONGLY Circle one response per line. DISAGREE AGREE 29.I liked the story (trying to help an animal survive 1 2 3 4 5 in a climate). 30.This was a fun way to visit the museum & look 1 2 3 4 5 at exhibits. 31.I enjoyed finding the real objects in the exhibits. 1 2 3 4 5

32.I would want to play a game like this again. 1 2 3 4 5

72 B.3 Focus Group Questions

Focus Group Discussion Guide

Thank you for participating. Again, there are no right or wrong answers. You also do not need to agree with each other. I’m interested in hearing each of your thoughts and opinions.

(Questions are listed in order. Note that we may run out of time to ask all questions.)

 Tell me what you thought about the game.  Specifically, which were the best parts? o PROBE: looking at exhibits with a purpose? o PROBE: answering questions/making choices? o PROBE: collaborating as a family?  Now, tell me about anything you disliked in today’s game. What were your least favorite parts? o PROBE: frustrations with technology? o PROBE: Confusion about goals/tasks? o PROBE: Confusion about navigation?  Thinking about when you were walking around the exhibits, you were asked to look at a specific exhibit to make a choice. (give example from game). When you got those instructions, how easy or hard was it to figure out where you were supposed to look? (PROBE: were you ever too far away or in the wrong spot)  Along similar lines, thinking about when you were asked to lean close to trigger a beacon, how easy or hard was it to trigger those beacons. (PROBE: Did it take too long?)  I’m guessing you probably haven’t done anything quite like this before. How difficult was it to understand how to play the game?  Was this something you’d like to see offered in the museum? why or why not?  Anything else?

73 74 Bibliography

[1] liferay-android-beacons. https://github.com/jamesfalkner/ liferay-android-beacons. Accessed: 2015-05-30. Version used was 0.2.

[2] Amnon Dekel and Elad Schiller. DRec: Exploring Indoor Navigation with an Un-Augmented Smart Phone. In Proc. MobileHCI 2010, 2010.

[3] Getting Started with iBeacon. https://developer.apple.com/ibeacon/ Getting-Started-with-iBeacon.pdf. Accessed: 2015-04-26.

[4] Google I/O 2013 - The Next Frontier: Indoor Maps. https://www.youtube. com/watch?v=oLOUXNEcAJk. Accessed: 2015-04-26.

[5] TiBeacons. https://github.com/jbeuckm/TiBeacons. Accessed: 2015-05-30. Version used was 0.9.2.

[6] Eric Klopfer, Judy Perry, Kurt Squire, Ming-Fong Jan, and Constance Steinkuehler. Mystery at the Museum - A Collaborative Game for Museum Education. In Proc. CSCL 2005, 2005.

[7] Eladio Martin, Oriol Vinyals, Gerald Friedland, and Ruzena Bajcsy. Precise Indoor Localization Using Smart Phones. In Proc. MM 2010, 2010.

[8] Mystery at the Museum. http://education.mit.edu/ar/matm.html. Ac- cessed: 2015-04-18.

[9] Outbreak @ MIT. http://education.mit.edu/ar/oatmit.html. Accessed: 2015-04-18.

[10] Eric Rosenbaum, Eric Klopfer, and Judy Perry. On Location Learning: Authen- tic Applied Science with Networked Augmented Realities. Journal of Science Education and Technology, 16(1):31–45, February 2007.

[11] TaleBlazer for Research. http://taleblazer.org/about/taleblazer\_for\ #research. Accessed: 2015-04-18.