Interactions Methods for Immersive Magic Systems in LARP throughAugmented Reality

Zach Laster

Helsinki November 21, 2013

Seminar Report

UNIVERSITY OF HELSINKIDepartment of Computer Science

Faculty of Science Department of Computer Science

Zach Laster

Interactions Methods for Immersive Magic Systems in LARP through Augmented Reality

Augmented Reality

Seminar Report November 21, 2013 10 pages + 0 appendices

game, augmented reality, interaction

Augmented Reality is not a new technology, but it is steadily becoming more prevalent and easier

to accomplish with modern devices. This opens up doors to new applications which have previously

been exceedingly di�cult or even impossible. As Augmented Reality continues to expand and the

technologies enabling it improve, more applications will be possible.

We attempt to produce a system which enables future applications to provide multiplayer game

experiences in the context of a magical game similar to live-action roleplay games. The goal is

to produce an interaction system to potentially enable playing an example game which is not

implemented. We thus build a well-performing networked prototype which allows each user to

draw points in real space which retain their positions with high precision, such that other users

may view the points.

Tiedekunta � Fakultet � Faculty Laitos � Institution � Department

Tekijä � Författare � Author

Työn nimi � Arbetets titel � Title

Oppiaine � Läroämne � Subject

Työn laji � Arbetets art � Level Aika � Datum � Month and year Sivumäärä � Sidoantal � Number of pages

Tiivistelmä � Referat � Abstract

Avainsanat � Nyckelord � Keywords

Säilytyspaikka � Förvaringsställe � Where deposited

Muita tietoja � övriga uppgifter � Additional information

HELSINGIN YLIOPISTO � HELSINGFORS UNIVERSITET � UNIVERSITY OF HELSINKI

ii

Contents

1 Introduction 1

2 Background 1

2.1 Augmented Reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.2 What is LARP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.3 Game Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.4 Diminished Reality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.5 Structure from Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 Prototype Design 3

3.1 Game Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2 Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.3 Application Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.3.1 Milestones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Speci�cation 6

5 Implementation 7

6 Evaluation 8

7 Conclusions 9

7.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

References 10

Appendices

A Device Positioning 0

1

1 Introduction

The intent of the project is to craft a system of tools to enable the casting of magic in afantasy roleplay game through the use of Augmented Reality (AR). The primary targetof this system is to support Augmented Reality applications for Live-Action Roleplay

(LARP)-style games. Such a game is played in real-time and is very much bound to thereal world. This implies several limits upon the allowable game mechanics, particularlywith movement of characters and the general lack of availability of real magic.

A signi�cant portion of the case study focuses on establishing what magical e�ects canbe accomplished and how. AR is able to produce the illusion of magic in many contexts,allowing us to create magical environments and game mechanics.

The primary focus of the project is to build a system with which the magical world canbe interacted with. Because of the real-time requirements of LARP games and the limitedinterface options available, interacting with the game world can be di�cult. The goal is to�nd a way which feels reasonably natural while still providing enough options and actionswithin the game world.

2 Background

In order to consider what possibilities exist for real-time game environments utilizing AR,we look at what has been and can be done with AR. Particularly, the technologies thatexist for creating magical e�ects or interacting with the environment.

2.1 Augmented Reality

AR is e�ectively a system of enhancing the real world with elements from a virtual space.Such elements can be, for example, positional indicators, such as the location of a building,or informational indicators, such a readouts for the distance to an object or the statisticsassociated with a sports player. Essentially any object with which we can associate meta-data to in the real world can have some such readout, and any locations which can beaccurately relatively positioned can be indicated.

AR is not limited to visual changes. Essentially, any added information which is boundto the environment constitutes a form of AR. Music can be played in a user's headphonesas they walk into a room, or tactile information can be provided through gloves or otherdevices to simulate tactile interaction with virtual elements. Informational signals can alsobe provided through audio, such as proximity indicators or a warning klaxon.

Usually visual enhancements to reality is produced through overlaying it onto a cameraview, such that a live camera stream is augmented by the virtual data. This ranges fromdisplaying some form of Heads Up Display (HUD) to rendering objects as if they werephysically in the world.

In addition to indicating or providing information on real-world objects, virtual objectswhich only exist within the application can also be presented through Augmented reality.Some applications for this approach are to decorate a room with arti�cial furniture in orderto plan how it should look or to create virtual pets which interact with the real world.

2

2.2 What is LARP?

LARP is e�ectively the live variation of pen-and-paper games. They can range in setting,from historical recreations to high fantasy, and the rules between any two games can varylargely, especially on details of the execution of combat. For this case study, the focus ison high fantasy settings, where magic plays a major and obvious role.

A large portion of LARP-style games, like most roleplay games, focuses on social interactionbetween players.

Whereas most computer-based games tend to inadvertently eliminate social situations fromgames, one suggestion is to utilize ubiquitous computing [2] to help bring virtual gamingback to a true social setting. A combination of AR and LARP-style gaming seems an idealblend on that path.

2.3 Game Design

Some general requirements of a game designed using AR have been compiled [7]. Thestrongest principal is to focus on the game design itself prior to selecting technologies.The abilities should be utilized to aid the game, the game should not be built around theabilities of AR. This is, of course, a general rule, as some game mechanic made possiblethrough AR may be the initial idea behind a game design.

One key aspect in game design is immersion. Game immersion is a measure of how deeplya player is immersed in the game experience; generally immersion is how real or convincingthe game feels. When immersion is lost, players are jarred out of the experience. This isoften unpleasant and undesirable. It is important that the AR not interfere with immersion.Instead, the purpose of it should be to enhance the sense of immersion in the game, aidingin suspension of disbelief.

2.4 Diminished Reality

Diminished Reality allows for objects or regions to be removed from view in an AR envi-ronment. There have been several attempts to produce this e�ect but almost none of themcan operate on real time video. Fortunately, Herling et al. [3] have recently produced amethod which does operate in real-time with very few constraints.

The target of such an e�ect revolves around the result's completeness and coherence,meaning the result retains all of the information of the original image and has very fewartifacts.

2.5 Structure from Motion

Structure from Motion (SfM) is a form of Simultaneous localization and mapping (SLAM),which has been in use in robotics for over a decade. It is possible to build a 3-Dimensionalmap of the surrounding environment using SfM algorithms such as Parallel Tracking and

Mapping (PTAM) [4] using nothing but a camera. These algorithms function by usingfairly continuous images takens from the camera and calculating the changes betweenthem using some form of feature extraction. Feature extraction, in this context, essentially

3

Figure 1: AR can be used to remove objects from view. [3]

means identifying points of reference and tracking them in order to produce 3-Dimensionalrepresentations of the local environment.

SfM has some strong implementations, though most target custom built or very speci�cdevices. It also has some limitations, particularly that most implementations do not handledynamic environments well, meaning people moving through the environment while map-ping could cause errors. It also requires that a device have a camera in order to correctlyposition and orient itself in virtual space.

An implementation of SLAM can be used to give us very precise positioning data notnormally available to AR systems. A device can use such a mapping system to locate itselfwithin that map and track its location. Additionally, current technology has reached thepoint where many ubiquitous devices are capable of running such implementations.

3 Prototype Design

AR can readily present the information from the virtual world, but interacting with it isthe greater challenge. If the goal is for the AR to be presented through a headset, thenmeans devices other than touch screens need to be utilized to handle user input. If a hand-held device is used, the in-game interfaces should generally have very few menus, tendingtowards gesture recognition.

It is important that any methods of interaction be fairly unobtrusive. Ideally no immersionis lost, meaning the interactions must �t within the game world. Thus, very natural andrapid interactions should be targeted. This goes along with few in-game menus and buttonsand tends towards physical, audio, and visual recognition.

Visual hand recognition is a good option, but if the recognition device is worn it maybe di�cult for it to always have a clear view of the user's hands. Verbal commands aresomewhat more practical, but do not provide much information without more liguisticcapability.

One candidate is to use (Trading) cards with barcodes or QR-codes akin to The Eyeof Judgement [7], a game for the Playstation utilizing the EyeToy. This provides goodidenti�cation information, but still lacks advanced information such as targeting choicesor other metadata.

The ability to track a player's physical state or movements provides very natural feedback

4

and is often quite rich in basic features. If �ne grain detail of hand or �nger movementthrough worn peripherals is available then hand gestures can be done outside of visualobservation.

Other peripherals can be easily used, such as bluetooth wands. Using technology similar tothe Wii-motes would allow for a wealth of information without losing nearly any immersion.

We �rst design a basic game to target. Then we design the interaction methods for thisgame system so that the interactions are as natural as possible. Finally, we design aprototype which allows us to build and evaluate this mode of interaction.

3.1 Game Design

In order to properly design a method of interaction, we must consider the type of game weare targeting. We �rst construct a very simple LARP-style gameplay. This enables us toset a long-term goal for the basic interface system we design.

Since the prototype will focus on the illusion of magic, the game rule set should be almostentirely magic dependent. In order to simplify interaction with the virtual world, themagic system utilizes �wands� in order to cast spells. With this in mind, the two strongestin�uences on the game design will be Dungeons and Dragons and Harry Potter style magic.The magic system of the Harry Potter lore is terrible and illogical, at least from a gamestandpoint, but the interaction itself is still good as a reference point.

In-game, players cast spells in order to perform actions beyond normal mundane inter-actions, such as movement. Examples of such spells include Fire Bolt, Flame Wall,Teleport, and Invisibility. Each of these spells has fairly unique requirements fromthe game system.

Teleportation and invisibility are staples of most magical game systems. While AR cannotdirectly produce any form of teleportation, it may be able to create e�ects that facilitateillusions of teleportation, such as making the user invisible or pausing the game. Invisibility,on the other hand, is a very localized illusion, and might be possible using DiminishedReality. In-game objects are also possible to represent using AR. This means that spellswhich would produce visual e�ects directly, such as Fire Bolts or summoned creatures, arereadily possible.

Flame Wall is the simplest spell, requiring only handling collisions with elements that moveinto it. Fire Bolt requires real-world collisions and physics, which is a step up from theFlame Wall. Invisibility requires the ability to track an individual as they move and toapply an �invisibility e�ect� to them, regardless of pose. Lastly, Teleport is an advancedmechanic with multiple possible solutions, such as making the user invisible and intangible(to in-game objects) for the duration of transit or making the game world freeze until theplayer relocates.

3.2 Interface Design

In order to make the interface system as extensible as possible, we use hand-held �wands�which provide gesture recognition and positional information. We can use these devicesto draw points in space, which can then be recognized as some form of Glyph or sym-bol. This recognition draws from normal character recognition using drawn points. We

5

can additionally handle direct gestures such as shaking or moving the wand in particularpatterns.

Ideally, wireless wands connected to a controller device could be used to draw the pointsin space. Lacking such actual devices, a similar controller can be utilized, such as asmartphone. The primary requirements for whatever device used are that it be possibleto locate in space with high precision and that it be able to recognize motion gestures.The positional information is necessary to permit the emmision of the particles from whichglyphs are built.

For simple spells, a single recognized Glyph will produce a spell result, depending onlocation and orientation. The simplest example is casting a Fire Bolt, which will originatefrom the center of the glyph and travel in the direction the Glyph is �facing�1.

More advanced spells could use larger, more complex Glyphs, or even multiple Glyphschained together. The latter would require that the user have control over when they arecreating particles. Ultimately, this does not a�ect the core premise of the interaction.

3.3 Application Design

The primary hardware requirements of the prototype are the hand-held wands and thevisualization system. The wands serve as the primary source of user input, especiallyfor the prototype, where they are the exclusive source. The visualization system is thenthe primary source of user feedback, informing the user of events and enriching the visualenvironment within their view. Additional devices for tactile feedback could also be utilizedto improve user information, though that is not a priority.

In order for the system to function, the visualization system and the wands must beconnected with each other. In order for the system to work as a game, others must beable to connect as well. The connection between players must be wireless, allowing playersto move about freely, though the �local� system could be connected in any way, includingphysically. Preferably, all of the devices will communicate wirelessly.

All of the primary devices connected to the game need to be aware of game state. Thegame state must be kept synchronized across all of these devices, such that the location ofan object does not vary across clients (noticeably), and the simulation of e�ects needs tobe consistent across all of the in-game devices.

Ideally, small, hand-held �wands� using bluetooth or similar connections would actuallyexist for this purpose, and the visualization would be an nonintrusive device worn over theeyes. If both of these devices lacked processing power, a third device would be necessaryto provide the information they need as well as to process the simulation and communicatewith the network.

For the prototype, the primary devices targeted will be smartphones. These can be usedfor both the wands as well as for the visualization systems. This means that a single devicecan handle both use cases simultaneously. The primary concern here is that the devicemay be overburdened with tasks, as it is covering all roles. Additional phones may beutilized per person in order to lighten that load.

1Assuming Glyphs are essentially 2D characters drawn in the air, this would give them a normal which

is the direction the user was facing when they drew it. Alternatively, the normal may face the user and

the inverse normal would be the direction away. In any case, the Glyphs are highly orientable.

6

For the prototype system, general Android devices will be used, with the Samsung GalaxyS2 being the primary testing device. The accelerometer, gyroscope, and compass sensorswill likely all be necessary to correctly determine device orientation. The away-facingcamera will obviously be necessary in order to overlay reality. The selection of devicecomes primarily from this device being available for dedicated testing work.

3.3.1 Milestones

The �rst goal of the prototype is to enable wand tip tracking in the virtual space, meaningthat the system knows where the wands are and can render a �trail� e�ect for them. Thisversion ignores occlusion and any other world information when rendering. It alreadyincorporates spatial positioning of the wands, which are the viewing devices. This versionis a local prototype, meaning it does not communicate with other devices.

Separately, a chat application is implemented in order to test and work with the network.This prototype application only needs to establish how to connect to other devices andsend information between them. The baseline for this comes directly from the exampleapplications included with the used network API.

The �nal phase is to create a combined prototype such that multiple users can connecttogether to create particle trails in the same space. The particles are viewable by otherusers in the same network, and color-coded to the player. The wands thus need to bebroadcasting their position at each sampling frame. The user should additionally be ableto control if they are producing a particle trail, so as to not obscure their own vision.

4 Speci�cation

In order to build the prototype in the constrained time available, existing solutions areused wherever possible. The intent is to build a working example of the system, not acomplete version of it. Thus, most of the coding work involved in the prototype will be inthe unique logic pertaining to the prototype and in building the bridges between whateveropen source platforms and libraries can be found to achieve the desired mechanics.

In order to properly handle the wand motions from the phones, it is necessary to be ableto correctly assess their orientation and position in space. Using the basic sensors of mostmobile devices it is possible to correctly assess the orientation of a device, but determiningspacial location is much more di�cult. Once devices are equipped with Sensor Fusion [5]or the like internally this will be easier, but still something of a challenge. At present, itis therefore necessary to �nd a way to accurately determine a device's location. For moreinformation on other means of positioning, see appendix A.

13th Lab AB has created a system called PointCloud [1] which utilizes a form of SLAM.The original implementation of this is a browser for HTML 5 content which runs on iOSdevices. There also exist APIs from Android and iOS devices from which other applicationscan be built. Using the Android PointCloud API we can accurately position and orient adevice in world space, allowing very accurate mapping of virtual-space to world-space andback.

Using SLAM mapping poses a few problems. The primary of these is that each device isrequired to have a camera attached to it in order to use the map to identify its location. This

7

means that future applications utilizing simpler wand devices will require more advancedor di�erent solutions to positioning. Additionally, setting up a game requires that the playenvironment be completely mapped out. If a player enters an area or looks in a directionfrom which the device cannot determine its location, the player will drop fro mthe virtualspace and be unable to see or interact with the game world. Some extensions to this arediscussed in section 7.1.

The network communication of the system functions as a network of devices, where eachdevice is aware of the entire simulation. While this is impractical for a large scale system,it should serve for a small-scale environment of a few devices in which everyone is part ofthe same game. Some limitations on information sending may be implemented in order tolimit the bandwidth usage.

In order to handle communication between the devices, AllJoyn is used. This allows thedevices to communicate over Wi-Fi with each other directly. As each device needs theinformation of the entire state, a simple broadcast method works well, though it limits theamount of data that each device can send and the frequency at which it can be sent. Thedi�culty of this approach is managing bandwidth. A more robust method would be someform of distributed peer-to-peer network similar to a torrent system, however this is notnecessary for the sake of the prototype.

The primary requirement on the rendering system for the prototype is to be able to renderparticles in the 3D projection. This is easily doable using OpenGL overlaying the cameraresult. The only requirement is to get the 3D projection to be used. PointCloud providesboth the full projection matrix to use as well as camera position and location, making thistask very simple.

5 Implementation

Implementation of the prototype was carried out targeting each milestone individually.The �rst two milestones were separate targets, meaning they could be approached simulta-neously. The third milestone required the �rst two to at least be mostly functional, thoughbugs could still exist in them such that they could be ignored or �xed in the third phase.

The initial milestone re�ected the core of the prototype. This part required establishingcontrol over and interaction with the PointCloud systems. The primary challenges in thispart were creating the points in space relative to the �wand's� location and rendering thingsappropriately.

The base for the prototype's architecture was built here, relying on a message/event systemto communicate information to objects and observers to pass the information to the ren-dering system. The points are gathered during the main game loop. The main game loopis run as a separate thread from the application's primary execution, which encapsulatesthe rendering and pointcloud updates.

The second milestone essentially became dissecting an existing sample application thatcame with the AllJoyn API. The goal was to understand how AllJoyn communicatedinformation between devices. The primary points noted were that AllJoyn uses a namedservice model for providing interfaces by which information can be sent and automaticnumeric packet identi�cation. This simple model was evaluated to permit the prototypereadily.

8

The third milestone was to e�ectively fuse the previous two applications into one. Theinitial prototype was used as a base from which to work. The server model was set up suchthat a single application would create a session and act as the game server. This serverprovided an interface from which the connecting clients query for the game map. Thisway the map is sent to each device as they connect. Every device connected to the sessionprovides an interface for listening to point creation signals. Point updates are then sentto each user for every point created, and each user tracks the known points for all otherusers.

Building the networked version of the prototype proved to be challenging at �rst, butthis was largely due to taking a false start. The original model of communication wasintended to pass all tra�c through the server application and redistribute, but this provedto be a poor approach with the AllJoyn API. The communication between devices seemssuitable for live use, but very limited testing has been possible. Recent changes to thenetwork system have been made to resolve various issues, but the results of these changesare untested.

During development, the visuals were migrated from GLES 1.0/1.1 to 2.0, in order tohave access to shader programs on the GPU. This necessitated rewriting large portions ofthe render code, and the conversion of all rendering to shaders. Several hours went intoattempting to migrate, over two di�erent sessions. Despite initial di�culty, I eventuallygot it working with the help of Peter Hedman.

6 Evaluation

In order to evaluate the success of the prototype, I have demonstrated it and tested it withothers. The responses have mostly been positive, and the basic toy of drawing in the airis entertaining in itself. The usability of the prototype is an issue, though this is tolerablein a prototype.

The core of the prototype is the ability to create points in the air which remain �xed inreal space. This part works very well so long as the mapping for the area is good. Thereare some issues with producing sound maps for some environments. Particularly, creatingclosed environments often results in errors and partial maps often jitter. As long as a solidmap is available, however, the positioning and presentation of the points functions welland is enjoyable.

The time required to set up a valid map is an issue, and as the map grows larger it issometimes necessary to start over, as the possibility for error increases. Therefore it isinfeasible to play quick games, as the preparation time is so large. It is easier to havea dedicated environment in which the system is used, at which point other means ofestablishing device position would actually be easier to use or implement.

The inclusion of network makes things more di�cult, as the maps need to be larger tosupport more players. Additionally, communication needs to be very fast. Once a gameis set up the drawing and interleaving of points is entertaining, but there is no real gameexperience to be had. The primary experience that network adds currently is the abilityto view the points created by other players from di�erent perspectives.

Overall the prototype performs well. Even though the networked version is not a completegame, it suggests that one can be built using this technology. There is still lots of function-

9

ality which needs to be added in terms of making it into a game, but the core technologyexists. Some of these functionalities will be discussed in section 7.1.

7 Conclusions

We have built a basic game design in the style of a LARP game in order to design and testan interface approach for such games enhanced with AR. A system of drawn particles andsymbol recognition was devised. We built a prototype system demonstrating the primarychallenges to the proposed interaction method and possible solutions to these problems.Finally, we considered the success of the prototype.

Overall the prototype was successful. It demonstrated the possibility of such an approach,despite complications. With improvements and extensions, it should be possible to buildmore advanced technologies from this. Particularly, the example game system should bepossible to approach.

As technologies improve, the systems available to accomplish majority of the outlined tasksshould become easier and faster, both to implement and execute. Software and hardwaresolutions will enable better position tracking and magical e�ects which can be applied tothe example game.

7.1 Future Work

The key issue the prototype faces is still accurately determining the location of devices,as the map recognition can occasionally fail or have serious issues when building the map.However, there are many facets to the project which could be extended or improved upon.

An excellent next step would be glyph recognition. The recent wand positions could bechecked to see if they match a glyph, at which point that glyph will be drawn in the air atthat location. This does not require that spells be castable, yet, but is still very di�cultdue to the 3-Dimensional nature of the drawing space. Normal recognition approacheswould need higher dimensionality added to them.

Once glyphs can be recognized, spells could be added to the system. Once a glyph isactivated the spell is cast from the location of the glyph, in the direction of that glyph(face normal). Most of this should already be supported by the existent system, which canalready map locations and render e�ects (at least particles). The challenge at this step isto attempt to handle virtual object collisions with real world terrain and objects.

Alternatively to adding physical object spells, the invisibility e�ect could be approached.The new requirements for this are to be able to track the body to make invisible and thento attempt to eliminate it from the view. Both are doable, but neither one is easy2.

Similar to physical collisions, point occlusion could be attempted in order to decide ifparts of the virtual system should not be rendered because it is hidden behind a real-worldobject. This could be attempted even before glyph recognition.

Alternate solutions to device positioning could be explored as well, as the SLAM mapping

2The invisibility e�ect requires Diminished Reality. While at least one real-time algorithm for this exists,

I have not seen the source code to it available for public use. It is possible that a similar implementation

will need to be created in order to accomplish such a thing.

10

can completely fail in numerous circumstances. One possibility is to create a fallbacksystem using sensor fusion, and then use SLAM mapping to correct for drift whenever themap is found. See appendix A.

To extend upon the visual presentations an AR headset could also be utilized. This wouldhelp reduce the problem of needing to look through the same device used as the wand,alleviating the burden on the device as well as improving the user interface. It does,however, increase the number of platforms the system needs to run on.

The current network model does not scale reasonably beyond a few clients. A properdistributed peer-to-peer network or other architecture is necessary to carry the game outof very local instances.

References

1 13th Lab. Pointcloud. [Online; accessed 03-October-2013; http://

pointcloud.io].

2 Sta�an Björk, Jennica Falk, Rebecca Hansson, and Peter Ljungstrand. Pi-rates! using the physical world as a game board. In PROCEEDINGS OF

INTERACT 2001, pages 9�13, 2001.

3 Jan Herling and Wolfgang Broll. Advanced self-contained object removal forrealizing real-time diminished reality in unconstrained environments. InMixed

and Augmented Reality (ISMAR), 2010 9th IEEE International Symposium

on, pages 207�212, 2010.

4 Georg Klein and David Murray. Parallel tracking and mapping for small ARworkspaces. In Proc. Sixth IEEE and ACM International Symposium on Mixed

and Augmented Reality (ISMAR'07), Nara, Japan, November 2007.

5 David Sachs. Sensor fusion on android devices: A revolution in motion process-ing, August 2010. [Online; accessed 03-October-2013; http://www.youtube.com/watch?v=C7JQ7Rpwn2k].

6 Ubejd Shala and Angel Rodriguez. Indoor positioning using sensor-fusion in

Android devices. PhD thesis, Kristianstad University, Sweden, 2011.

7 Richard Wetzel, Rod McCall, Anne-Kathrin Braun, and Wolfgang Broll.Guidelines for designing augmented reality games. In Proceedings of the 2008

Conference on Future Play: Research, Play, Share, Future Play '08, pages173�180, New York, NY, USA, 2008. ACM.

A Device Positioning

Many devices have in-built sensors for GPS location, but the accuracy of these devices islow, often 10 meters o� in an ideal case. This is an acceptable system for outdoor use onlyand will not have su�cient accuracy for the later stages of the project, however it might beenough to build a basic prototype with. If higher precision is required, then other systemswill be necessary to either repalce or re�ne the results from GPS.

Sensor Fusion can be used to calculate movement and position [6]. The best case for thisis still frequently meters o�, though it is a reasonable solution. This is a better solutionfor indoor environments than outdoor, as it can utilize WiFi signal strength of stationaryWiFi hotspots. This would be more appropriate for a system requiring higher precisionthan GPS, but it might not do well for outdoor play.

One important point is it is necessary to avoid the double integral in position calculationwhen using device sensors, because it will produce major levels of drift. This is becausethe accelerometer data will usually include some amount of noise, and applying integrationon noise produces drift [5]. Therefore it is important to calculate the spatial location of adevice through other means.

Compared to actual positional location, device orientation is simple. It's actually a verysimple matter to use Sensor Fusion to correctly determine the orientation of a devicewithout major drift over time [5].