Gamify Your Teaching-Using Location-Based Games for Educational Purposes

Gamification has become a hot topic for today’s educators. Many tools and methods have been developed and students have got used to Foursquare or Barcoo. This paper introduces an easy and cost-effective method that educators can use to develop custom-made Scavenger Hunts which meet the needs and expectations of their various fields. In fact, the method can be used for multiple purposes, topics and audiences: elementary school children can be addressed as well as adult workers. The only devices needed to deploy the method are a QR-code-scanning device (such as a smartphone) and a GPS device. It must also be considered that almost 50 per cent of the U.S. population owns a smartphone. As a consequence our method – called “QuizeRo” – can be considered easy to use. It is also expected to make teaching more fun. The paper will offer a toolkit for individual use and a howto guide based on the presenter’s own research and experience. A best practice case will also be presented to illustrate the impact on education. Moreover the paper will address advantages of learning in a playful setting and will outline further steps to quantify the outcome of this specific method. Index Terms — Gamification, Location-based games, QuizeRo

INTRODUCTION Gamification has proven to have an enormous impact on today's learners. A recent study shows that "55% of people would be interested in working for a company that offered games as a way to increase productivity" [1]. Engaged workers are better workers and therefore engaged students are better students. A student who is interested in the lesson or course taught will be a more productive learner [2]. Gamification can be a great tool to help students stay engaged. These objectives can easily be met by allowing educators to restructure and reorganize their lessons creatively. As a result, students will be motivated to broaden their minds and improve their skills. Indeed, these observations were the reason for the university to initiate a project which addresses the following question: "Is it possible to develop a game framework for educational purposes which can be customized by educators for individual use?" At many universities, gamification methods are rather new and knowledge about effective usage is rare. For this reason, the entry-barrier is rather high. While many students have a broad personal gaming history, the vast majority of educators have not. This fact has to be considered as a strong argument against the usage of gamified learning methods and/or tools in the first place.
To help educators close this knowledge gap, a project team was formed to identify easy but effective gamification methods and tools. Moreover the project team was asked to develop a beginner scenario. The team asked the following questions: 1. Which real existing scenario at the university can be used as a test case? 2. How can the chosen scenario be gamified? 3. Which methods and tools can be adapted and administrated easily and effectively? 4. To what extend can the test case be evaluated?
Since the answer to Question 1 is fundamental to the whole project, a brainstorming session was organized and potential stakeholders such as educators, researchers related to the field of study techniques and/or gamification, curriculum developers and public-relation managers were invited. The stakeholders were chosen based on the assumption that a suitable real-life scenario had to be found which was eligible for testing. Since the success of the yet-to-be-developed method was unsure and could not be guaranteed to the responsible parties, curriculum courses essential to the learning outcome could not be considered for testing.
After much consideration, the scenario "Introducing incoming students to their new surroundings" was identified as appropriate test case. The next step was to transform the three questions into separate tasks. How the tasks were executed, how the tools and methods were selected and what findings were made will be described in the following chapters.
II. THE TASKS In order to apply a gamificational element to the chosen scenario, the scenario itself has to be analyzed. A set of questions was developed to outline the scenario: I. When do incoming students come to the university? II.
How are the students introduced to the university and city life? III.
What level of technical knowledge can be expected? Since incoming students are most often supported by the International Office, an emissary from the International Office was asked to participate in the project. This fact has to be mentioned since it is very important to involve stakeholders in the project [3,4,5]. The source area of the stakeholder is insignificant, but provides significant information about certain processes that need to be acknowledged. For this reason, this fact was the first one to be added to the checklist.
Regarding the three initial questions I, II and III, it was stated by the emissary that most of the incoming students arrive during summer. They are introduced to the university and city using a so-called "buddy system" and they seem to have a fair technical knowledge. The "buddy system" was originally established by the Boy Scouts of America [6] and the United States Armed Forces [7]. The following statement was taken from the "Guide to Safe Scouting": "Every participant is paired with another. Buddies stay together, monitor each other, and alert the safety team if either needs assistance or is missing. Buddies check into and out of the area together. Buddies are normally in the same ability group and remain in their assigned area." [8] A similar system could be witnessed in another project some time ago where a "no-one-gets-left-behind"-clause was initiated and evaluated as tremendously helpful [9].
Regarding the university, the buddy system is exercised as follows: A student from the university is paired with an incoming student. He or she serves as a one-stop-shop to common challenges for incoming students and assures that the incoming student has access to the social life and activities at the university. The buddy does not get curricular credit for his or her help but benefits personally from the interaction with the incoming student(s). Buddies interviewed complained about the complex and dull task of arranging a (good) guided tour for incoming students. The project team felt that this scenario could serve as a main task for the project and an incentive to buddies and incoming students. It was therefore decided to design the task around this specific scenario.
After the emissary had been interviewed by the project team, the task was verbalized: "Install a cheap, non-tocode, easy-to-use-and-adapt game to introduce incoming students to the Campus and the city of Vienna". The reason for this format can be interpreted as follows: -"cheap": In many educational institutions budgets are tight. For this reason, this requirement had to be taken into consideration. -"non-to-code": Nowadays coding seems to be a commodity. Nevertheless coding is an asset which is sometimes difficult to achieve. As a result, this requirement was added to the list. The project team was asked to search for software that could be used right away or only needed minor adaptions. -"easy-to-use-and-adapt": Since the game had to be supervised by the International Office it was essential to find an easy-to-learn solution. It was decided that the solution must not create an entry barrier that could easily result in a denial of the solution and failure of the project. -"game": Since a broad range of different games exists, finding the right one was a challenging task.
In compliance with the project team it was decided that adjustments would not be made during the actual evaluation phase. If needed, they could be done after the project's end. Based on the scenario, it was decided to focus on location-based games [10]. Since the team already possessed expert knowledge, they seemed to address various important and adequate issues regarding the task. Additionally, they had already been evaluated by others [11]. -"students": The fact that the students were the addressees/clients of the project was somehow overlooked at the beginning of the project. This issue was also addressed in Question III. As stated above, this fact was crucial [see also 12] and a quick response had to be found. It was decided to use statistic data to characterize the typical incoming student and to back up the information offered single-handedly by the emissary. Finally a project name was created to help the project team identify with the project. QuizeRo was born.
III. DESIGNING QUIZERO After the search for a name, the project was undergoing a transition from a concept to a detailed planning phase [13]. There were still some "left-overs" from the beginning of the project that had to be dealt with. First the level of technical knowledge of the students (a) had to be evaluated and (b) depending on the answer to (a) a useful game had to be found.

a) Technical Level of Students
Neither time nor resources were available to the project team to research this topic thoroughly. Fortunately, reliable empirical data was provided by various sources. OurMobilePlanet by Google [14] was consulted since it offers a quick and reliable [15] overview of the adequate items. Those items consisted of the countries where most of the incoming students come from (France, Germany, UK) and their age. After the evaluation of the data, it was decided to compare the smartphone penetration (which was equalized with technical knowledge by the project team) of France, Germany and UK to the smartphone penetration of Austrian students. Since most of the students are aged from 18 to 29, it was decided to add this information to the data sheet. The data was compared to the data from the local governmental statistic authority "Statistik Austria" which came up with nearly the same results [16]. To cut a long story short, it can be easily stated that approximately 2/3 of the target group use a smartphone regardless of their origin. For this reason, it was possible to answer the question about the technical knowledge and to include the usage of smartphones into the game.
Furthermore the project team decided to consult empirical data regarding the usage of games on smartphones.

Fig. 2: Playing Games with a smartphone
The data clearly confirms that the majority of young adults is used to playing games on a smartphone and that there are no significant differences between countries. Even though the team did not intend to develop a new game for the smartphone, it was relieved to see that students are familiar with smartphones and gaming. b) Get into the game As mentioned before, the project team members possessed expert knowledge on different location-based games. Since many of those games relate to Scavenger Hunts, further research was done in this direction. The team came up with promising and established games, which had been the focus of a previous research project [17]: Geocaching [18] and Munzee [19]. While Geocaching is a "free real-world outdoor treasure hunt, where Players try to locate hidden containers, called geocaches, using a smartphone or GPS and can then share their experiences online", Munzee is "a real world scavenger hunt game where items are found in the real world and captured using a smartphone. Munzee is based off of the fundamentals of geocaching".
Both games have one thing in common: GPS-enabled devices which can be found in most state-of-the-art smartphones. Participants navigate to a specific set of GPS coordinates and then attempt to find the geocache (container) or respective Munzee.
The project team was positive about both games and decided to look further into it. Both games underwent a quick evaluation which resulted in the following findings: According to the Geocaching-Website, there are over 2,000,000 active geocaches and over 5 million geocachers worldwide [18]. The geocaching rules contain several different types of "caches", such as Traditional Caches, Multi-Caches (also known as Offset Caches) and Mystery or Puzzle Caches. According to the official rules, a "cache" is "at minimum, a container and a log book or logsheet." [20]. As far as a Traditional Cache is concerned, the coordinates listed on the traditional cache webpage (hosted by geocaching.com) provide the geocache's exact location (this is where the container is hidden). A Multi-Cache ("multiple") involves two or more locations, also referred to as "stages". The final location is a physical container.

Fig. 3: Hidden and revealed Container
The players thus know that their previous locations or stages have been passed successfully. There are many variations but most Multi-Caches have a hint or riddle to solve to find the next location. The last clue or final riddle will lead players to the real existing container. Last to mention are Mystery or Puzzle Caches which may involve complicated puzzles that players need to solve first to determine the coordinates. It is possible to mix up Multi-and Mystery Caches.
Munzee uses QR-code style barcodes, called Munzees, which come in any size or shape. The barcode is a mandatory requirement for the game since it is linked to the GPS coordinates, which are the essential gameplay elements of Munzee. Compared to Caches, Munzees follow the same principles but instead of signing a logbook, players log their positive find by scanning the QR-Code with their smartphone using the Munzee App [21]. Since Munzees are plain QR-Codes, they can be hidden in containers, camouflaged or placed in plain view. Compared to geocaches they are easier to hide but lack the ability to contain anything (like a logbook or an object). Most of the findings of the project team were positive. The games can be played free of charge and nothing has to be coded. Unfortunately, the possibilities of adaption are limited. None of the games could carry out the task on its own. For this reason, the project team decided to merge both games. The result of this merging process will be described in the following chapter.
IV. DEPLOYING QUIZERO The next step for the project team was to complete the work breakdown structure to classify the project into work packages. It is important to mention this fact since the appliance of project management methods resulted in great benefits for the project. The most important work packages "Game Design", "Game Development" and "Going Live" will be described:

a) Game Design
This work package had to be completed first, since it offered essential information to the other work packages. In a brainstorming session the project team decided that -the game should "move" incoming students around the city like a normal Scavenger Hunt. -it should address team play also known as co-op mode -instead of containers or virtual marks, QR-Codes should be used -QR-Codes should be linked to customized riddles (further referred to as "quests") -quests should be carried out "Multi-Cache"-style -quests should be informatory but not to "nerdy" -competition between teams should be possible.

b) Game Development
The results of the brainstorming session described in the work package "Game Design" had an enormous impact on the work package "Game Development". The project team identified the two requirements "QR-Codes should be used" and "QR-Codes should be linked to customized riddles" as most challenging. Those tasks could not be carried out using the existing proprietary tools connected to Geocaching or Munzee. As a consequence, a tool had to be found that could link QR-Codes to predetermined websites where the riddle would be made available to the participants. The team decided to expand this requirement. Apart from just finding a tool that could generate usable QR-Codes, a framework had to be found where the Quest Giver could easily design the Quest. Additionally, a tool was demanded that could save and archive the data of each team.
The solution to those requirements was easier than anticipated. As QR-Code generator a tool called "QR Code Generator from the ZXing Project" [22] was discovered. It is able to generate a QR-Code and link it to several different types of destinations, such as contact information, calendar event, email address, geo location, phone Number, SMS, text or webpage. ZXing (pronounced "zebra crossing") is an open-source, multiformat 1D/2D barcode image processing library implemented in Java, with ports to other languages. The focus of ZXing is on using the built-in camera on mobile phones to scan and decode barcodes on the device, without communicating with a server. ZXing can be used to encode and decode barcodes on desktops and servers [22]. It is licensed under the Open Source License Apache License 2.0. For this reason, it served the requirements perfectly. Nothing had to be coded, the tool can be used free of charge, no advertisement must be included at a target location such as a website. It can be hosted "on own soil" which ensures the availability of the tool at all times. Moreover it can be adapted if necessary. This was considered a "nice-to-have" benefit since it was not a requirement.
The question remained to which destination the generated QR-Codes could be linked. The project team relied on the knowledge and experience regarding managed learning environments (MLS) and learning content management systems (LCMS). Google Docs was reported as a convenient and worthwhile tool [e.g. see 23]. Google Docs is accessible through Google Drive [24] and provides the possibility to create forms and questionnaires. It has a good reputation among educators (the project team counted more than 500.000 tutorial videos how to use Google Docs in a learning environment on Youtube). Testing towards connectivity with ZXing was therefore strongly recommended. Since ZXing is able to link the QR-Code to any website it was possible to create a Quest using Google Docs. Google Docs is able to run a customized survey and to sum up the data in a spreadsheet. The idea of creating a survey was replaced by creating a quiz since both ideas serve the same purpose. After filling out a form the program provides a unique URL which the QR-Code can be linked to.
The design of the form represented another challenge. Although the team decided to master it learning by doing and in a trial & error style, they agreed to use common quest building knowledge [25,26,27]. It was important for the project to test the applicability towards any scenario in order to create a framework for common usage. The project team therefore decided to develop a customized storyboard for an international scientific conference. The attendees were seen as substitutes for incoming students, since most of them did come from various locations around the world. Moreover the project team was eager to find out more about the surroundings of the conference. Deploying QuizeRo for the first time at the conference was considered a valuable test case.
The necessity to do some research about the targeted city (Darmstadt, Germany) and the story of a historic figure called "Datterich" emerged. The historic figure was used to introduce the attendees of the conference to the city.
They were informed that the Datterich was revived by the scientific personnel of the university where the conference took place. The attendees had to take Datterich for a walk through the city. While he was providing them with information about the history of the city, they were teaching him about the present situation of the city. The attendees thus immersed in the city history and they also had to act as a tourist guides themselves although most of them had never been to city before. After the story had been developed by using tourist guide books, books and historic documents about Datterich and information found on the internet, QuizeRo was ready to start. The "making of" will be described in the following paragraph.

c) Going Live
The story developed by the team had to be transformed into a "route" through the city. Routing tools such as Google Maps were used to measure the route online. This was crucial to ensure that players had to walk a reasonable distance. The original story had to be changed to a certain extent to adapt the quest to the planned walking path. Along the path different points of interest (POI) were identified. The story had to be cut into pieces to build "Multi-Cache"-style stages. Each stage consisted of a riddle which had to be solved in order to reach the next POI/stage. For some stages the solution had to be converted into geographic coordinates, adding a mathematical element to the quest.
Finally the game consisted of the following items: I.

A Tip for the game master documenting useful information
After the story was implemented into the Google Docs forms following the above mentioned structure, the project team was able to create QR-Codes using ZXing which is linked to each stage. Additionally a pattern was designed for the QR-Codes to give QuizeRo a corporateidentity look & feel and to help participants find the right QR-Codes. This became necessary when the team found out that many QR-Codes, which were mostly linked to some company or event websites, could already be found at the target locations. The unique design of the QuizeRo-QR-Code helped to tell the different QR-Codes apart. After printing out each QR-Code, the project team was able to place the QR-Codes at the designated places. Two things were left before the game could be started. Firstly, the exact geographic location where the QR-Code was placed had to be determined and forwarded to the riddle team for implementation. Secondly, a hint had to be given to players in order to find the QR-Code.
V. EVALUATION Using QuizeRo for the first time was a big challenge and the project team was not sure whether the riddles for each stage were linked together logically for the participants. In the end, 18 teams solved the quest successfully, 7 got lost on the way and 4 quit after the first stage. As a positive side effect it could be observed that Google Docs did save each answer to each stage adding a time-stamp to it. The project team was able to observe the progress of each team. Moreover the project team was able to add the factor "time" to the game to rank the teams in descending order and to be able to announce a winner. After the first playthrough, the team evaluated the whole project. Feedback from participants was gathered using a survey as well as feedback from the project team's own experience.
Based on the feedback, the project team came up with a guideline: 1. Create a story. This story may consist of anything an educator wants to come up to. The story should follow basic rules known from storytelling. This is a big advantage, since the design of the game is not limited to any certain topic or field of interest. It can be linked to any field. 2. Create a walking path. This path can be very short or very long. It will determine how many stages the educator's quest will have at a minimum or maximum. For longer walking paths a riddle each half mile was evaluated as convenient by participants. 3. Use a (software) tool to create your quiz/riddle/scenario/question. Google Docs Forms was evaluated positively by the project team and many educators are already familiar creating riddles using Google Docs. If one is not familiar with it, there are many helpful resources on the web. 4. Use a QR-Code Generator such as ZXing to create your QR-Codes. Link it to any location or target. Any other QR-Code generator might work as well, of course.

Search for suitable spots to hide your QR-
Code. This is a mandatory since badly hidden QR-Codes may be removed by third parties. Do not break any laws. Do not hide your QR-Code on private property without the owner's permission. Do not hide your QR-Code where GPS tracking is difficult or not available since it will make the quest more complicated. 6. Test Run your game! Adapt if necessary. The riddle itself can even be changed while playing a game. 7. Create Help E-Mail Addresses to send out auto-replies helping teams whose quest got stuck. Those teams will be frustrated, if they cannot solve the quest. Using a Help E-Mail Address may result in loss of points, but participants will still be able to finish the quest. 8. Listen to feedback. Any further development of QuizeRo depends on experience and feedback. The next step will be the evaluation by the project team.
VI. FINAL REMARKS A lot has happened since Pong [28] was introduced to the gaming market. The initial question "Is it possible to develop a game framework for educational purposes which can be customized by educators for individual use?" can be answered with "Yes". QuizeRo has shown that by using this method, any scenario can be gamified. It has also shown that no expert IT-knowledge is necessary to develop a QuizeRo-Quest. Customization is not very difficult, only designing the Quest following the rules of storytelling can represent a challenge. For this reason, educators may want to collaborate with experienced professionals because a poor story will result in poor quest design and bored participants. In the end, the main task of the game is to make learning more fun.
Finally, the statement made by Kapp "Simple Games help to save both time and money and are easier to develop and, in some cases, more impactful for a particular type of learning than elaborately developed complex learning games" seems to be true [29]. This statement certainly deserves further research in the future.