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 opportunity 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
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Research Question
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
1.3
Chapter Summary
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2 Background
2.1
2.2
19
TaleBlazer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.1.1
TaleBlazer Gameplay . . . . . . . . . . . . . . . . . . . . . . .
19
2.1.2
TaleBlazer Platform Structure . . . . . . . . . . . . . . . . . .
21
2.1.3
Using TaleBlazer
. . . . . . . . . . . . . . . . . . . . . . . . .
21
Previous Indoor Games . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.2.1
Outbreak @ the Institute . . . . . . . . . . . . . . . . . . . . .
22
2.2.2
Mystery at the Museum
22
. . . . . . . . . . . . . . . . . . . . .
3 Indoor Navigation
3.1
Determining Design Goals
3.3
25
. . . . . . . . . . . . . . . . . . . . . . . .
25
Partnership with HMNH . . . . . . . . . . . . . . . . . . . . .
27
Approaches Considered . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2.1
QR Codes, Dead Reckoning, and WiFi Positioning
. . . . . .
28
3.2.2
Indoor Google Maps
. . . . . . . . . . . . . . . . . . . . . . .
30
3.1.1
3.2
16
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
. . . . . . . . . . . . . . . . . . . . . .
4 Implementation
33
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
. . . . . . . . . . . . . . . . . . . . . . .
5 Pilot with HMNH
5.1
5.2
5.3
Game Design
42
45
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.1.1
Game Overview . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.1.2
Game Mechanics
. . . . . . . . . . . . . . . . . . . . . . . . .
49
Pre-pilot tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.2.1
First pre-pilot test
50
5.2.2
Second pre-pilot test
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
51
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
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
11
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
53
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 framework 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 locationbased 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 au-
dience 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 on the
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 Science 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 of the
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 frustrate or confuse players. Because encouraging visitors to make detailed observations
is such a common goal, many partners desired a positioning system that could pinpoint 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 tappable 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 a major
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 of providing
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 6meter 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, so there
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 me across
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 used to give
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 TaleBlazer, 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 Titanium’s functionality to include additional features from a particular operating system.
Modules can be created by Appcelerator or by third-party developers. Although Titanium 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 triangulating 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 points in
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 set which
reading should trigger an agent.
4.3
Software Changes
The first step in adding beacons to TaleBlazer was enabling beacons to be added to
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 the beacon’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 agent ribbon
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 the BLE
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. Unfortunately, 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 complication 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 this game
because it uses beacons and this device can’t communicate with beacons.” (Figure 46). 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 and re-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 an animal
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-1 shows
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 a specific
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 to the
landmark animal, finds the landmark animal, and is directed to find the three choice
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 be in
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 of the
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 had two
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 and thus due
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 subsequent 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, and that
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 a movingdot 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 view more
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.
improvements for the usability of the editor have already been planned.
Some
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 nonworking 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.
60
Alternatively, the
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 use of
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 inTaleBlazer 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 alternative 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. A test
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 with many
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 likely that
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
Coding/Definitions of Fields:
Adult 2:YES / NO
HELD DEVICE? ALL / SOME / NONE
Child 1:YES / NO
HELD DEVICE? ALL / SOME / NONE
Child 2:YES / NO
HELD DEVICE? ALL / SOME / NONE
LOCATION:
MOL
Mollusk/Tutorial
AFR
Africa
NA
North America
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: ________________ Time Location
Child #1
END TIME: _____________________
Adult #1
Child #1
Adult #1
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
NOTES
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
with these exhibits at HMNH?
VERY
SOMEWHAT
NOT AT ALL
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
with these exhibits at HMNH?
VERY
SOMEWHAT
NOT AT ALL
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
hold the mobile device?
8. Typically, this child uses a smartphone or
tablet…
9. Before today’s visit, how familiar was this child
with these exhibits at HMNH?
ALL OF
THE TIME
SOME OF THE
TIME
NONE OF THE
TIME
OFTEN
OCCASIONALLY
NEVER
VERY
SOMEWHAT
NOT AT ALL
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
hold the mobile device?
13. Typically, this child uses a smartphone or
tablet…
14. Before today’s visit, how familiar was this child
with these exhibits at HMNH?
71
ALL OF
THE TIME
SOME OF THE
TIME
NONE OF THE
TIME
OFTEN
OCCASIONALLY
NEVER
VERY
SOMEWHAT
NOT AT ALL
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…
16. Overall, I would say that this game’s length
was…
17. Overall, I would say that this game’s difficulty
was…
18. I’d want to replay ‘Super Survivor’ in a
different climate (e.g., desert, tundra,
rainforest)…
iPHONE
iPAD
TOO SHORT
JUST RIGHT
TOO LONG
TOO EASY
JUST RIGHT
TOO HARD
RIGHT NOW
DURING
ANOTHER
VISIT
NEVER
C. Please tell us how much you AGREE or DISAGREE with each item.
STRONGLY
DISAGREE
Circle one response per line.
STRONGLY
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
throughout the game.
1
2
3
4
5
D. A few questions just for ADULTS:
STRONGLY
DISAGREE
Circle one response per line.
22. I felt this was a meaningful activity.
23. This was a fun way for kids and grownups
to spend time together.
24. This activity made me think about museum
exhibits in new ways.
25. I would recommend this activity to other
visitors.
26. This was a fun way to visit the museum &
look at exhibits.
27. I enjoyed finding the real objects in the
exhibits.
28. I would want to play a game like this again.
STRONGLY
AGREE
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
E. And a few final questions for KIDS:
STRONGLY
DISAGREE
Circle one response per line.
29. I liked the story (trying to help an animal survive
in a climate).
30. This was a fun way to visit the museum & look
at exhibits.
STRONGLY
AGREE
1
2
3
4
5
1
2
3
4
5
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
https://github.com/jamesfalkner/
[1] liferay-android-beacons.
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.
https://developer.apple.com/ibeacon/
Getting-Started-with-iBeacon.pdf. Accessed: 2015-04-26.
[3] Getting
Started
with
iBeacon.
[4] Google I/O 2013 - The Next Frontier: Indoor Maps.
com/watch?v=oLOUXNEcAJk.
[5] TiBeacons.
https://www.youtube.
Accessed: 2015-04-26.
https://github.com/jbeuckm/TiBeacons.
Accessed: 2015-05-30.
Version used was 0.9.2.
[6] Eric
Klopfer,
Steinkuehler.
Judy
Perry,
Kurt
Squire,
Ming-Fong
Jan,
and
Constance
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: Authentic Applied Science with Networked Augmented Realities.
Journal of Science
Education and Technology, 16(1):31–45, February 2007.
[11] TaleBlazer for Research.
#research.
http://taleblazer.org/about/taleblazer\_for\
Accessed: 2015-04-18.
75