Ejecutor de búsquedas del tesoro con realidad aumentada

Ejecutor de búsquedas del tesoro con realidad aumentada Por Leire Osés Sánchez Adrián de Lucas Gómez David Czepiel William Molina Cumba Trabajo de Fin de Grado en Desarrollo de Videojuegos Facultad de Informática Dirigido por Pedro Pablo Gómez Martín Pedro Antonio González Calero Augmented reality treasure hunts engine Madrid, 2021–2022 Ejecutor de búsquedas del tesoro con realidad aumentada En este TFG se plantea la realización de una aplicación web para creación y configuración de búsquedas del tesoro en las que uno de sus ingredientes principales es el reconocimiento de objetos físicos, que permiten ir desbloqueando las pistas. Para ejecutarlo se desarrollará un motor que pueda ejecutar la aventura según la configuración dada por el usuario. También se podrán mostrar, en puntos concretos, minipuzzles específicos que encajen con la ambientación de la búsqueda del tesoro particular. Leire Osés Sánchez Adrián de Lucas Gómez David Czepiel William Molina Cumba Dirigido por Pedro Pablo Gómez Martín Pedro Antonio González Calero Departamento de Ingeniería del Software e Inteligencia Artificial Facultad de Informática Universidad Complutense de Madrid Madrid, 2021-2022 Resumen Las búsquedas del tesoro y las yincanas son una serie de juegos tradicionales que consisten en tratar de resolver una serie de retos y pruebas con el objetivo de ganar algún tipo de premio o recompensa. Pueden ser jugados de forma individual o en grupos y pueden tener un planteamiento más competitivo o casual. La idea del TFG es crear un motor y una herramienta web que sirva para poder generar este tipo de juegos con la premisa de que el usuario no necesita tener conocimiento de programación alguno. Estas aplicaciones estarán formadas por fases de diferentes tipos y en diversas cantidades según las necesidades del creador de la aventura para adaptarse mejor al entorno donde va a ser utilizado y el objetivo que se quiere conseguir. Para generar las aventuras los usuarios deben hacer uso de una herramienta web disponible en un servidor de la UCM donde pueden configurar desde el nombre de la aventura que vayamos a crear, a todas y cada una de las diferentes fases disponibles y luego permitir descargarnos el proyecto para generar el instalador para dispositivos Android. Palabras clave Búsqueda del tesoro Ejecutor búsquedas del tesoro Herramienta de autoría Videojuegos para dispositivos móviles Realidad Aumentada Aplicación web 2 Summary Treasure hunts and gymkhanas are a type of traditional games that consist in trying to solve a series of challenges and tests with the premise of winning some kind of prize or reward. They can be played individually or in groups and they can have a competitive or casual approach. The idea of the TFG is to create an engine and a web tool that is used to generate and play this type of games with the premise that the user does not need to have any knowledge of programming to make use of it. These applications will be made up of phases of different types and in various amounts according to the needs of the creator of the adventure to better adapt it to the environment where it will be used and the objective trying to be achieved. In order to create these games users will use a web tool available at a UCM server where they can configure from the name of the adventure that they are going to create, each and every one of the different phases available and then allow them to download the project to generate the installer to use it in Android devices. Key words Treasure Hunts Treasure Hunts engine Authorship tool Mobile video games AR - Augmented reality Web-based configurator tool 3 Índice general Página Bloque de introducción. 1 1. Introducción 1 1.1. Motivaciones ................................. 2 1.2. Plandetrabajo................................ 2 1.3. Repositorio y página del proyecto . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction 4 1.1. Motivations.................................. 5 1.2. Project´sschedule .............................. 5 1.3. Project’s repository and web page . . . . . . . . . . . . . . . . . . . . . . 6 2. Estado del Arte 7 2.1. Juegosserios ................................. 7 2.2. Aplicacionesweb ............................... 10 2.2.1. Multi Page Application . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.2. Single Page Application . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.3. Capas de las aplicaciones web . . . . . . . . . . . . . . . . . . . . 12 2.3. RealidadAumentada............................. 13 2.4. Productosdelsector ............................. 17 2.4.1. ARVRtech: Tresure Hunt . . . . . . . . . . . . . . . . . . . . . . 17 2.4.2. Educaplay............................... 18 2.4.3. Onirix................................. 20 2.4.4. uAdventure.............................. 21 3. Herramientas 26 3.1. Unity ..................................... 26 3.1.1. Funcionamiento de Unity . . . . . . . . . . . . . . . . . . . . . . 27 3.1.2. Carga de recursos en Unity . . . . . . . . . . . . . . . . . . . . . 28 3.2. Vuforia..................................... 28 3.2.1. Funcionamiento de Vuforia Engine . . . . . . . . . . . . . . . . . 29 3.2.2. Claves de Vuforia . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3. React ..................................... 30 3.3.1. Funcionamiento de React . . . . . . . . . . . . . . . . . . . . . . 30 3.3.2. Componentes............................. 31 4 Augmented reality treasure hunts engine UCM Bloque de implementación. 34 4. Diseño e implementación 34 4.1. Tiposdefases................................. 34 4.1.1. FaseQuiz............................... 35 4.1.2. FaseQR................................ 35 4.1.3. FaseImagen.............................. 35 4.1.4. FaseAR................................ 35 4.1.5. Fasedesonido ............................ 36 4.1.6. Fasedetexto ............................. 36 4.1.7. FasedeGPS ............................. 36 4.2. Configuración de las aventuras . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3. Ejecución de las aventuras . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.4. Datos que constituyen una aventura . . . . . . . . . . . . . . . . . . . . . 37 4.5. Ciclo de generación de una aventura . . . . . . . . . . . . . . . . . . . . 37 5. Herramienta de autoría de yincanas 39 5.1. Frontend.................................... 39 5.1.1. Flujo de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.1.2. Estructura de los componentes de la WEB . . . . . . . . . . . . . 41 5.1.3. Estadointerno ............................ 41 5.1.4. Instanciación de los componentes . . . . . . . . . . . . . . . . . . 42 5.1.5. Estructura de los componentes . . . . . . . . . . . . . . . . . . . 43 5.1.6. Serialización de la aventura . . . . . . . . . . . . . . . . . . . . . 50 5.2. Backend.................................... 52 5.2.1. Arranque del servidor . . . . . . . . . . . . . . . . . . . . . . . . 52 5.2.2. Servicios del backend . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.2.3. Comunicaciones Front-End/Back-End . . . . . . . . . . . . . . . 55 5.2.4. Comunicaciones al guardar una aplicación . . . . . . . . . . . . . 56 6. Motor de ejecución de yincanas 59 6.0.1. GameManager ............................ 60 6.0.2. MasterObject............................. 61 6.0.3. AdventureInfo............................. 61 6.0.4. Stage ................................. 61 6.1. Implementación de las fases . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.1.1. FaseQuiz............................... 62 6.1.2. FaseQR................................ 62 6.1.3. Faseconimagen ........................... 63 6.1.4. Fase de realidad aumentada . . . . . . . . . . . . . . . . . . . . . 63 6.1.5. Faseconaudio ............................ 64 6.1.6. Fase de introducir texto . . . . . . . . . . . . . . . . . . . . . . . 65 6.1.7. Fase con geolocalización . . . . . . . . . . . . . . . . . . . . . . . 65 7. Resultados obtenidos 67 7.1. Busqueda del tesoro - Demostración . . . . . . . . . . . . . . . . . . . . . 68 7.1.1. Recorrido y pruebas de la demo . . . . . . . . . . . . . . . . . . . 68 7.2. Evaluación con usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.3. Posibilidades como motor de juegos serios . . . . . . . . . . . . . . . . . 70 5 Augmented reality treasure hunts engine UCM Bloque de conclusiones. 73 8. Conclusiones 73 9. Trabajo futuro 75 8. Conclusions 77 9. Future Work 79 10.Contribuciones individuales 81 10.1.LeireOsésSánchez.............................. 81 10.2. Adrián de Lucas Gómez . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 10.3.DavidCzepiel................................. 84 10.4. William Molina Cumba . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Bloque de anexos. 90 A. Manual de usuario 90 A.1. Creación de una aventura . . . . . . . . . . . . . . . . . . . . . . . . . . 90 A.1.1. Configurar una fase Quiz . . . . . . . . . . . . . . . . . . . . . . . 91 A.1.2. Configurar una fase QR . . . . . . . . . . . . . . . . . . . . . . . 91 A.1.3. Configurar una fase Image . . . . . . . . . . . . . . . . . . . . . . 92 A.1.4. Configurar una fase de RA . . . . . . . . . . . . . . . . . . . . . . 93 A.1.5. Configurar una fase de GPS . . . . . . . . . . . . . . . . . . . . . 93 A.1.6. Configurar una fase de texto . . . . . . . . . . . . . . . . . . . . . 94 A.1.7. Configurar una fase de sonido . . . . . . . . . . . . . . . . . . . . 94 A.1.8. Ayudasypistas............................ 95 A.2. Editar una aventura previa . . . . . . . . . . . . . . . . . . . . . . . . . . 96 A.3. Descargar aventuras de otros usuarios . . . . . . . . . . . . . . . . . . . . 96 A.4. Creación del APK con Unity . . . . . . . . . . . . . . . . . . . . . . . . . 97 A.5. Instalación en un dispositivo Android . . . . . . . . . . . . . . . . . . . . 98 A.6. Despliegue de la herramienta . . . . . . . . . . . . . . . . . . . . . . . . 98 Bloque de bibliografía. 100 Bibliografía y enlaces de referencia 100 6 Índice de figuras 2.1. Popularización de los juegos serios en el nuevo milenio y sus campos de aplicación ................................... 8 2.2. Aplicaciones web con formato Multi-Page Application y Single-Page Application.................................... 11 2.3. Ciclo de vida de una MPA . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Ciclo de vida de una SPA . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. Espada de Damocles (HMD), 1966 . . . . . . . . . . . . . . . . . . . . . 13 2.6. Knowledge-based Augmented Reality for Maintenance Assistance, 1993 . 14 2.7. ARQuake: Interactive Outdoor Augmented Reality Collaboration System, 2000 ...................................... 15 2.8. WikitudeDrive,2010............................. 15 2.9. Invizimals en batalla, 2009 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.10. Pokemon Go AR+ mode, 2017 . . . . . . . . . . . . . . . . . . . . . . . 16 2.11. Búsqueda del tesoro creada por ARVR como demostración . . . . . . . . 18 2.12. Algunas de las actividades disponibles para configurar . . . . . . . . . . 19 2.13. Actividad sobre animales en Froggy Jumps . . . . . . . . . . . . . . . . . 19 2.14.EditorwebdeOnirix............................. 20 2.15. Búsqueda del tesoro creada por Onirix como demostración . . . . . . . . 21 2.16. Vista general de escenas y conexiones entre ellas . . . . . . . . . . . . . . 22 2.17. Configurador de una escena normal . . . . . . . . . . . . . . . . . . . . . 23 2.18. Configurador de códigos QR . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.19. Configurador de una escena geoposicionada . . . . . . . . . . . . . . . . 24 2.20. Visual scripting en uAdventure . . . . . . . . . . . . . . . . . . . . . . . 24 3.1. Interfaz gráfica del editor de Unity . . . . . . . . . . . . . . . . . . . . . 27 3.2. Procesamiento de una imagen en la SDK de Vuforia . . . . . . . . . . . . 30 3.3. Proceso de gestión de cambios de estado en React . . . . . . . . . . . . . 31 4.1. Ciclo general de la generación de una aventura . . . . . . . . . . . . . . . 38 5.1. Flujodeaplicación .............................. 40 5.2. Estructura del estado global y estados locales en React . . . . . . . . . . 42 5.3. Esquema de instanciación de los componentes React . . . . . . . . . . . . 42 5.4. Elementos visuales del componente Steps . . . . . . . . . . . . . . . . . . 43 5.5. Componente de resumen de la aventura . . . . . . . . . . . . . . . . . . . 44 5.6. Componente de carga de aventuras . . . . . . . . . . . . . . . . . . . . . 45 5.7. FormulariofaseQuiz............................. 46 5.8. Formulario fase de QR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7 Augmented reality treasure hunts engine UCM knowledge. The adventure editor will be accessed from the browser where we can choose the phases and their content in a graphic and simple way. When the user is satisfied with the adventure configured, it can be saved in the server or download the Unity project to generate the executable for an Android device. 1.1. Motivations This project has achieved the creation a very useful tool for the generation of small interactive games that could be directed to various fields. In the educational field, games could be created that invite students to apply concepts given in class, strengthening them. In the cultural field as an interactive guide in visits to museums. Within the most playful sphere, generating treasure hunts with the aim of entertaining groups of people. The project, within the field of education, benefits teachers and students as it allows the former to generate interactive and gamified material in a simple and intuitive way. Students receive an interactive experience that is more engaging and presented in a friendlier way. We also show that it has the potential to be a simple engine for creating serious games[3]. Later we will see that serious games have another objective beyond entertainment, which can be teaching, remembering concepts, etc. 1.2. Project´s schedule During the development of the project we are going to set a series of milestones to be accomplished in the short term in order to add new features each time, always having a functional version of the project. The agile methodology used will be SCRUM and we will have one-week sprints. At the end of each sprint, a meeting with the tutors will be held to show the progress and receive feedback. In October, the work of the project will focus on experimenting with different tools that will be necessary to develop this project, as we will see in the chapter 3. In Unity we will develop a program that reads information from JSON and generates scenes and goes from one to another as necessary. In November with this base and with the chosen tools, two complete phases will be developed to be able to create a mini adventure. To generate this JSON, a web tool will have to be made from which you can create a treasure hunt by configuring and combining the two phases develop. Then the file that defines the adventure written in JSON can be copied into the executor and to create an executable to use on our device. Now the objective will be to simplify the previous process so that the executor with the JSON of the gymkhana already attached can be downloaded directly from the web configurator and to be able to compile the project directly using a batch script. At the start of February and with that cycle closed, a database will be created within the server to be able to save the adventures that are created in order to be able to modify them later and also upload the installers of these adventures so that other users can download and play them directly. 5 Augmented reality treasure hunts engine UCM During March and April more different phases will begin to be added with the purpose of giving more content and versatility to the project to create other experiences. The idea is to have around six to seven different phases to be able to configure and add to the adventures. In May with all the phases developed the goal will be to create a complete treasure hunt to test the entire workflow from the design, through its creation using the web configurator an finally downloading it and generating the executable and then playing it from the mobile device. Finally, the visual aspect of both the configurator and the executor will be improved following the same style and trying to use the most pleasant and intuitive design possible. 1.3. Project’s repository and web page All the work done during the development of the project has been done using GitHub as our version control tool to store the repository 1and improve the workflow, allowing each member to work independently in a different branch. In the project a web tool2has developed for creating treasure hunts, we include the link to it where you can create your adventures and where the demo scavenger hunt seen in the chapter 7 is also available. This adventure in question will be available both to edit it and download ready to install it on our device and play it. 1https://github.com/Adrian-de-Lucas-Gomez/TFG-Ejecutor-de-busquedas-del-tesoro 2http://tfg.UrbanAR.org 6 Capítulo 2 Estado del Arte En este capítulo vamos a dar contexto sobre los avances y estudios que se han realizado en los campos que atañen a nuestro proyecto: realidad aumentada, tecnologías web y juegos serios en los últimos años y que han permitido que a día de hoy sea viable realizar un proyecto como este. También veremos algunas empresas que desarrollan software similar y/o comparable que ya se encuentran asentadas en el mercado. 2.1. Juegos serios Los juegos serios (serious games en inglés) son juegos diseñados con un propósito concreto, distinto al lúdico aunque pueden ser también divertidos de jugar. La expresión “serio” viene dada porque se utilizan en el sector educativo, científico, en la atención médica, planificación urbana, ingeniería y política, entre otros campos. El término fue acuñado en 1970 por Clark C. Abt, investigador estadounidense y autor del libro Serious Games[3] donde se exploran las diferentes formas en las que los juegos se pueden incluir en el proceso de enseñanza y aprendizaje sin eliminar la diversión y el placer. Este tipo de software ha adquirido gran importancia desde la entrada del siglo XXI (figura 2.1b) y ha sido adoptados por instituciones educativas y empresas, especialmente para programas de formación y campañas publicitarias. En el caso específico de España[4], hay muchas empresas que ya están utilizándolos sobre todo en el campo educativo para la formación tanto de niños como de adultos. Algunas de estas empresas son Humantiks, Gamelearn, Binnakle, Netlanguages y Chiara entre otras. Campos de aplicación de los juegos serios Como ya ocurre con los videojuegos tradicionales, los juegos serios se agrupan por su temática o su público objetivo. Como este tipo de juegos están pensados con una finalidad y objetivo muy concreto existen muchas subcategorías posibles pero se suelen agrupar por campo de aplicación (figura 2.1). A continuación vamos a ver algunos de los campos de aplicación más importante que hay en la actualidad. 7 Augmented reality treasure hunts engine UCM (a) Distribución por ámbitos de uso de 1970 a 2002 (953 juegos) (b) Distribución por ámbitos de uso de 2002 a 2010 (1265 juegos) Figura 2.1: Popularización de los juegos serios en el nuevo milenio y sus campos de aplicación Fuente: www.ludoscience.com/files/ressources/origins_of_serious_games.pdf Educación Esta parte del mercado son los que conocemos como juegos educativos, en los que el objetivo que se persigue es que el usuario adquiera una serie de conocimientos y competencias. Uno de los primeros y conocido en EEUU, fue The Oregon Trail (1971). El juego tenía como objetivo enseñar a los niños acerca de la vida de los pioneros de la Ruta de Oregón en el Siglo XIX. El jugador asumía el rol de un líder en un carro e iba guiando a su grupo de colonos tratando de sobrevivir cazando y gestionando los recursos. Tuvo éxito, teniendo en cuenta la época (figura 2.1a), y a lo largo de los años tuvo múltiples secuelas y spin-offs. En la actualidad los juegos serios van tomando cada vez más y más relevancia lo cual ha hecho que desarrolladoras de videojuegos, enfocados en el ámbito lúdico, lancen un formato educativo usando sus propiedades intelectuales. Este fue el caso de Microsoft y Mojang con Minecraft y su Education Edition1lanzado en 2018. Se trata de una versión adaptada del popular juego Minecraft donde los docentes pueden hacer uso de herramientas para transmitir las lecciones a los alumnos de una forma novedosa e interesante. Sanidad Los juegos pensados para el mundo médico y sanitario tienen como objetivo refrescar conocimientos al propio personal sanitario sobre ciertos procedimientos, aunque también existen juegos que están dirigidos a un público general y permiten enseñar a la ciudadanía técnicas2que podrían ayudar a salvar vidas o ayudar a mantener la salud. Dentro del ámbito médico ya se usan videojuegos[12] desde hace años para ayudar en labores de diagnóstico, tratamiento y rehabilitación de los pacientes. En este ámbito destacan juegos como FreeDive3, usado para distraer y tranquilizar a pacientes con enfermedades 1Minecraft Education Edition:https://education.minecraft.net/en-us 2Efectividad de juegos serios con realidad aumentada por 3ciencias: https://www.3ciencias.com/wp -content/uploads/2018/09/Art_4-1.pdf 3https://www.breakawaygames.com/case-studies/free-dive/ 8 Augmented reality treasure hunts engine UCM crónicas o Hungry Red Planet4, el cual trata de inculcar buenos hábitos alimenticios en los niños. También hay que añadir que hay juegos que originalmente no se habían creado como juegos serios para el ámbito de salud pero que sí que se aplican. Este uso no se limita solo a los hospitales o centros de salud, donde se aconseja a los pacientes que se jueguen ciertos tipos de juegos ya sea para mantenerse en forma, tanto física como mental o como ayuda a la hora de rehabilitarse. Títulos que se usan de esta forma son Wii Sports, Brain Age, Ring Fit Adventures o Just Dance por mencionar algunos ejemplos. Militar Uno de los ámbitos más antiguos de los juegos serios son los simuladores militares[15], utilizados como herramienta de entrenamiento. Comenzaron siendo formas de ensayar maniobras militares durante la Guerra Fría (1945-1989). Uno de estos primeros juegos no era un videojuego electrónico sino de mesa, HUTSPIEL[5] (1955). Consistía en un juego para 2 jugadores donde debían de gestionar los recursos de combustible y munición en cada unidad con el objetivo de ganar la batalla. En los años posteriores, los ordenadores comenzarían a tomar más relevancia en la escena militar lo que permitió que se desarrollasen simuladores donde se enseñaba a las tropas a manejar los vehículos sin necesidad de salir a realizar las maniobras y pudiendo probar escenarios concretos de batalla. Suelen ir acompañados de compleja maquinaria para simular de la mejor forma posible el entorno. Estos juegos no están disponibles para el público general por motivos de seguridad nacional, ya que revelaría entrenamientos y tácticas a otros países. Publicidad Los juegos serios utilizados como herramientas de marketing, los conocidos como advergaming, son videojuegos cuyo objetivo es el de publicitar una marca o producto. Los juegos elaborados como parte de una estrategia de advergaming suelen ser gratuitos y distribuirse de manera online siendo compatibles con diferentes dispositivos. El protagonista de los mismos es la marca, empresa, producto, institución o servicio que se quiere promocionar. Debemos distinguir el advergaming de la publicidad insertada dentro de un videojuego estándar, por ejemplo, los banners dentro de los estadios de videojuegos deportivos. En los juegos publicitarios la presencia de marca no es secundaria, sino que es el punto central del juego. A día de hoy, en la era de las redes sociales, son muy comunes este tipo de juegos ya que las marcas han visto lo bien que funcionan. Algunos ejemplos de advergames antes de la época de las redes sociales son America´s Army (Windows, 2002), un juego bélico que lanzó el ejército de EEUU con el objetivo de captar a los más jóvenes para que se alistasen, Pepsiman5(Playstation, 1999), un juego donde debíamos evitar obstáculos y recoger 4https://serious.gameclassification.com/EN/games/15815-Hungry-Red-Planet/index.html 5Gameplay de Pepsiman: https://www.youtube.com/watch?v=8UvgQ8jybIw 9 Augmented reality treasure hunts engine UCM Pepsis y por último Yaris6(Xbox 360, 2007), un juego donde conducíamos un Toyota Yaris por pistas tubulares tratando de disparar a los enemigos y ganar puntos. Arte y cultura Este tipo de videojuegos trata de transmitir conocimientos sobre arte, rasgos culturales o historia sobre un lugar concreto. En especial, cuando se trata de civilizaciones antiguas como romanos, griegos o egipcios, la adaptación a videojuegos (especialmente en 3D) ayuda a entender y visualizar mejor como eran esas sociedades. En la última década ha habido un auge de juegos de realidad aumentada en zonas de yacimientos arqueológicos donde superponiéndose a las ruinas podemos ver cómo eran las estancias en su época. Es una de las categorías que más está creciendo en los últimos años. Incluso ha llevado a empresas muy grandes del mundo de los videojuegos convencionales a involucrarse en proyectos de esta índole. Una de ellas fue Nintendo, quien en colaboración con el Louvre desarrollo una audioguía7interactiva para Nintendo 3DS. Corporativos Videojuegos desarrollados para ser usados como una herramienta para la empresa con el objetivo de entrenar a sus trabajadores o gamificar una serie de actividades como pueden ser las reuniones, conferencias, etc. Son juegos que no se hacen disponibles al público externo a la empresa ya sea por motivos de seguridad u otros, aunque sí hay constancia de algunos a lo largo de los años. Uno de los que conocemos es Pepsi Invaders8(1983) el cual es un clon del videojuego Space Invaders9(1978) que usó internamente Coca-Cola con el objetivo de aumentar la competitividad de sus empleados frente a Pepsi. 2.2. Aplicaciones web La potencia de lo que es posible hacer en la web ha ido aumentado muchísimo desde la llegada al mercado de los primeros navegadores durante la década de los 90. En esos primeros años los navegadores, las aplicaciones que permiten acceder a la web, solamente se encargaban de descargar páginas HTML y mostrarlas. Un avance importante en esos años fueron los lenguajes de scripting que permitieron dinamizar estas páginas estáticas. Aunque ha habido más avances en la web, uno de los más relevantes en este proyecto es el de poder pedir la información bajo demanda, es decir, cuando sea necesario. Esto ha permitido la creación de aplicaciones que se ejecutan en el navegador, lo cual elimina la necesidad de tenerlas instaladas en nuestro ordenador y las hace más accesibles al 6Gameplay Yaris: https://www.youtube.com/watch?v=StsW-ZW9iWI&t=56s&ab_channel=Miste rJantix 7Demostración Nintendo 3DS Guide Louvre: https://www.youtube.com/watch?v=27lAJiYTZwQ 8https://www.retrogames.cz/play_1215-Atari2600.php 9https://www.retrogames.cz/play_016-Atari2600.php 10 Augmented reality treasure hunts engine UCM público ya que pueden acceder desde cualquier dispositivo en el que se pueda ejecutar un navegador web. Para el desarrollo de páginas web se suelen seguir uno de estos dos patrones: MPA (MultiPage Application) y SPA (Single-Page Application). (a) Página web que usa MPA (GAME) (b) Página web que usa SPA (Twitter) Figura 2.2: Aplicaciones web con formato Multi-Page Application y Single-Page Application 2.2.1. Multi Page Application El patrón de diseño de las Multi Page Application (MPA) consiste en la división del contenido de la página en diferentes pantallas. Este es el patrón que se ha usado durante muchísimos años en el desarrollo web. A día de hoy sigue estando muy extendido y se usa generalmente para páginas muy grandes ya que suelen tener mucho contenido y muy variado por lo que es más razonable el dividirlo ya que no sería viable tenerlo todo en una sola pantalla. Figura 2.3: Ciclo de vida de una MPA Al acceder a una página MPA vemos que en su ciclo de vida (figura 2.3) se pide la página y esta se muestra al usuario pero cada vez que se produzcan cambios de página o se actualice la información de la misma el servidor nos dará un nuevo archivo HTML y CSS con la página actualizada, descartando la que se estaba mostrando hasta ahora. Cada una de las diferentes pantallas que tiene una MPA lleva asociada una URL (Uniform Resource Locator) la cual sirve para identificar a cada uno de los recursos disponibles en la red y poder acceder directamente a ellas evitando pasar por otras páginas intermedias. 11 Augmented reality treasure hunts engine UCM 2.2.2. Single Page Application La filosofía de diseño[7] de páginas web conocida como Single-Page Application (SPA) consiste en una aplicación web que muestra todo el contenido desde una misma página. Esto no quiere decir que todo el contenido esté al mismo tiempo en la pantalla sino que se va ocultando y mostrando contenido según se vaya necesitando. Al cargar por primera vez la página se descarga el HTML, CSS y el código Javascript[11]. Este código Javascript controla el cambio de una sección a otra, actualizando lo que se debe mostrar en pantalla. Al cargarse esta estructura ligera al principio, y después cargar el contenido desde el servidor, los tiempos de respuesta de la aplicación son mejores y esto mejora la experiencia de usuario no haciéndole esperar tanto para abrir la página. Figura 2.4: Ciclo de vida de una SPA Aunque se accede a todo el contenido desde la misma URL, esta se puede modificar para que cada sección tenga una propia como pasaría en una MPA. Esto es útil para acceder directamente a la sección que te interesa de la página sin tener que repetir el recorrido desde el inicio de la web. Las SPA suelen ir asociadas a una base de datos desde la cual descargan el contenido, ya que este suele ir cambiando (ej. Twitter: figura 2.2b). En este ciclo de vida (figura 2.4) se puede ver que solamente piden el contenido a mostrar, no la página entera ya que no se va a refrescar completamente. 2.2.3. Capas de las aplicaciones web Cabe destacar que un enfoque típico en el desarrollo web es contar con una división clara entre la interfaz y el servidor donde se encuentra alojada la información de la aplicación. Dichas capas reciben el nombre de frontent y backend respectivamente. El frontend es la capa de una aplicación encargada de mostrar el contenido en pantalla y con la que interactúa el usuario. Para el apartado visual se emplea generalmente HTML con hojas de estilo y para la funcionalidad suele emplearse JavaScript como lenguaje de programación. Es típico el uso de frameworks como React o Angular para la implementación de esta capa. El backend, por otro lado, es la capa de la aplicación que se ejecuta en el servidor la cual se utiliza para la gestión del envío y recepción de solicitudes y datos que se envían entre el cliente y el servidor. Se puede usar cualquier lenguaje de programación para implementarla, aunque algunos de los más usados son: Node.js, Python, PHP o Java. Esto se debe a que están pensados para que sea fácil hacer que se comuniquen con bases de datos, serializar la información para ser enviada o realizar trabajo de forma asíncrona que es muy común en el desarrollo web. 12 Augmented reality treasure hunts engine UCM Cabe destacar que hay webs que usan un modelo híbrido en el que tienen secciones implementadas como SPAs pero están dentro de páginas separadas y conectadas como ocurre en una MPA. 2.3. Realidad Aumentada La realidad aumentada es una tecnología que consiste en la superposición de elementos virtuales sobre el mundo real de forma que, de la sensación de que esos elementos virtuales realmente existen en la mundo real[1]. Para experimentar esta tecnología hay varias formas: a través de la pantalla de un dispositivo como puede ser el caso de un teléfono móvil o a través de láminas translúcidas sobre las que se proyecta la imagen a superponer como ocurre por ejemplo con Google Glass10. Debido a la gran popularización de esta tecnología a día de hoy es barata y accesible gracias a la gran cantidad de software gratuito y la escasa necesidad de hardware específico. A diferencia de la realidad virtual (VR) la realidad aumentada no sustituye la realidad por una virtual sino que la expande y complementa. Uno de los primeros avances en este campo fue en el año 1966, cuando el profesor de Ingeniería Eléctrica de la Universidad de Harvard, Iván Sutherland[9], creó el HMD (Head Mounted Display). Conocido también como La Espada de Damocles11, el dispositivo era un visor (figura 2.5a) que mostraba elementos tridimensionales con gráficos vectoriales (wireframe) proyectados sobre unas lentes de cristal. Para saber la localización y rotación de la cabeza del individuo se hacía uso de diversos sensores mecánicos (figura 2.5b) que tenía el anclaje de las gafas al techo en conjunto a sensores de ultrasonidos. (a) Visor del dispositivo (b) Esquema de funcionamiento Figura 2.5: Espada de Damocles (HMD), 1966 Imágenes HMD: https://proyectoidis.org/espada-de-damocles/ 10https://www.google.com/glass/start/ 11Espada de Damocles: https://www.youtube.com/watch?v=eVUgfUvP4uk&ab_channel=Ultim ateHistoryofVideoGames 13 Augmented reality treasure hunts engine UCM K.A.R.M.A.[16] (Knowledge-based Augmented Reality for Maintenance Assistance) fue desarrollado en la Universidad de Columbia12 por Steven Feiner, Blair MacIntyre y Dorée Seligmann en 1993. Desarrollaron un software que iba dando instrucciones al usuario sobre cómo recargar la impresora, sin tener que recurrir al manual de uso, proyectando figuras vectoriales (figura 2.6b) que iban indicando los pasos a seguir a través de un visor (figura 2.6a) con proyectores y lentes transparentes. Para mostrar las imágenes hicieron modificaciones sobre un software previo llamado IBIS[6], el cual se especializaba en la generación de ilustraciones basado en reglas desarrollado por Steven Feiner y Dorée Seligmann. (a) Visor del dispositivo (b) Gráficos mostrados Figura 2.6: Knowledge-based Augmented Reality for Maintenance Assistance, 1993 En el año 2000 surge un nuevo hito en el desarrollo de la realidad aumentada, ARQuake[18]. Este proyecto era una demostración técnica13 de realidad aumentada pero esta vez enfocada al mundo de los videojuegos. Este proyecto era una derivación del popular juego Quake de id Software14 lanzado en 1996. Desarrollado por Wayne Piekarski y Bruce Thomas, este prototipo permitía seguir la posición del jugador en el mundo real a través de GPS de alta precisión. También empleaba una combinación de girómetro15 y brújula magnética para registrar y manejar la rotación de la cabeza del usuario. Para mostrar el contenido usaban un HMD (Head Mounted Display). La relevancia de este proyecto viene marcada por ser la primera vez que hacía uso de RA (realidad aumentada) en un dispositivo “portátil”, ya que el ordenador que procesaba todo se encontraba dentro de la mochila (figura 2.7a). Esto, unido a la capacidad GPS, permitía al usuario moverse libremente por su entorno (figura 2.7b) interactuando con puertas, enemigos, armas, etc (figura 2.7c). Los desarrolladores además abrieron una página web16 donde se pueden ver datos técnicos del proyecto y del dispositivo. Tras este prototipo comenzaron con el desarrollo de Tinmith17, el cual es una versión mejorada y genérica del hardware usado en ARQuake para crear aplicaciones de RA al aire libre. 12https://graphics.cs.columbia.edu/projects/karma/karma.html 13Video ARQuake: https://youtu.be/No7QF0MwSjg 14https://www.idsoftware.com/es-es 15Aparato que sirve para medir la velocidad de rotación de una máquina. 16Página ARQuake: http://www.tinmith.net/arquake/ 17Página sobre Tinmith: http://www.tinmith.net/ 14 Augmented reality treasure hunts engine UCM (a) Realidad aumentada por ubicación (b) Realidad aumentada por superficie Figura 2.15: Búsqueda del tesoro creada por Onirix como demostración Fuente: https://www.youtube.com/watch?v=i1zAfxlGkjU&ab_channel=Onirix 2.4.4. uAdventure uAdventure24 es una plataforma para el desarrollo de juegos de ordenador de aventuras clásicas con fines educativos. Esta plataforma ha sido desarrollada por el grupo de investigación de la Universidad Complutense de Madrid. Es la sucesora de la plataforma eAdventure25. A diferencia de su predecesor, que se creó en el marco de Java, uAdventure se ejecuta sobre el motor de juego Unity y para utilizarlo no se requieren conocimientos previos de Unity. Este motor fue concebido para hacer juegos serios de tipo aventuras gráficas que pueden o no hacer uso de geoposicionamiento según la aventura que queramos crear. uAdventure se instala como un paquete en Unity y ofrece un editor propio separado del editor de Unity en el cual nos ofrecen diferentes tipos de objetos que podemos crear para hacer nuestras aventuras: 24https://www.e-ucm.es/uadventure/ 25http://e-adventure.e-ucm.es) 21 Augmented reality treasure hunts engine UCM Figura 2.16: Vista general de escenas y conexiones entre ellas Escenas: aquí podemos añadir y modificar escenas que formarán parte de nuestra aventura. Se puede añadir el fondo, zonas de interacción, objetos y personajes (figura 2.17) para dar la funcionalidad que se busque en ese momento. Podemos visualizar las conexiones (figura 2.16) que tengamos entre distintas escenas. Personajes: en esta sección podemos añadir y ver los personajes creados. Estas son las entidades con las que podemos conversar dentro del juego pudiendo tener cuatro orientaciones diferentes según hacia donde miren. Conversaciones: permite crear líneas de diálogo entre los personajes y también para el protagonista. Pueden ser disparadas por eventos como por ejemplo al acceder a una escena nueva. Objetos: aquí podemos crear y editar los objetos con los que podemos interactuar durante la partida pudiendo elegir su representación en pantalla y los eventos a los que están asociados. Códigos QR: permite la creación de códigos QR (figura 2.18) que luego se escanearán durante el juego teniendo la opción de guardarlos e imprimirlos. Escenas de mapa: este tipo de escena tiene la particularidad de que está asociada a una localización real y se suele utilizar para hacer secciones o juegos geoposicionados. El fondo de la escena siempre será el mapa de la zona en la que se encuentre el usuario y en él se pueden añadir zonas especiales (figura 2.19) que desaten eventos al entrar en ellas y colocar objetos y personajes en zonas del mapa. Objetos geoposicionados: son una variante de los objetos pensada para ser colocada y utilizada en los mapas geoposicionados. Se puede establecer además de su aspecto, la distancia a la que es visible. 22 Augmented reality treasure hunts engine UCM Figura 2.17: Configurador de una escena normal Figura 2.18: Configurador de códigos QR 23 Augmented reality treasure hunts engine UCM Figura 2.19: Configurador de una escena geoposicionada A la hora de programar estas aventuras gráficas en uAdventure se hace todo a través de visual scripting (figura 2.20). Esto quiere decir que la programación de los comportamientos del juego se realizan a través de secuencias de nodos que son una forma gráfica de manipular objetos y comportamientos en Unity sin tener que escribir código desde cero. La lógica se construye conectando nodos entre sí, lo que permite que personas no familiarizadas con la programación puedan crear juegos y sistemas interactivos de una manera sencilla. Esta herramienta ya incluye comportamientos ya predefinidos para acciones comunes como el incremento de variables, navegación entre escenas, activación de objetos, borrado de objetos, etc. Figura 2.20: Visual scripting en uAdventure 24 Augmented reality treasure hunts engine UCM uAdventure al ser un motor que está muy pensado para la creación de juegos serios tiene un sistema de telemetría. Un sistema de telemetría se encarga de la recolección de datos durante las sesiones de juego de los usuarios, permitiendo guardarlos de forma local o en un servidor, y el formato de la información puede ser en formato CSV o XAPI. Esto es muy útil ya que permite evaluar que tal funciona el juego y cuál ha sido el desempeño de los jugadores en función de los valores recogidos. 25 Capítulo 3 Herramientas En este capítulo vamos a conocer algunas de las herramientas que hemos utilizado para desarrollar este TFG. Comenzaremos hablando de qué tipo es la herramienta, sus orígenes, como funciona internamente y las características que nos han hecho decantarnos por ellas sobre otras alternativas. Como el proyecto consta de dos partes bien diferenciadas, la aplicación web y el ejecutor de las búsquedas del tesoro, haremos uso de herramientas diferentes para cada una de las partes. 3.1. Unity Unity1es una plataforma de desarrollo de videojuegos la cual combina motor gráfico, motor físico, motor de audio, sistemas de input, un editor con el que poder crear los juegos y la capacidad para generar versiones para distintas plataformas. Existe gran cantidad de información y documentación para el desarrollo de videojuegos y además una tienda donde podemos acceder a miles de recursos que se pueden añadir a un proyecto para ser utilizados, tanto gratuitos como de pago. Unity surgió a raíz del videojuego “GooBall”, desarrollado por David Helgason, Nicholas Francis y Joachim Ante. Aunque no tuvo el éxito esperado, para ese proyecto desarrollaron una serie de herramientas muy útiles a la hora de desarrollar un videojuego, por lo que decidieron agrupar esas herramientas creando un motor con el que pudiesen trabajar programadores, diseñadores y artistas, ya fueran estudios grandes o pequeños para crear juegos, y después poder desplegarlo en diferentes plataformas. Unity fue presentado en la WorldWide Developers Conference (WWDC) de Apple en el año 2005 siendo inicialmente solo disponible para MacOS pero tiempo después aparecería también en la plataforma Microsoft Windows. Originalmente el modelo de negocio que seguía Unity era con versiones de pago, la versión Indie y la Pro. Entre ambas versiones no solo existía una sustancial diferencia en precio (300 dólares la Indie y 1500 dólares la Pro) sino también con respecto a la funcionalidad ya que la versión de acceso carecía de algunas funciones más avanzadas. En ese entonces, Unity no podía competir en igualdad de condiciones con los motores de ese momento. 1https://unity.com/es 26 Augmented reality treasure hunts engine UCM En el año 2009 desapareció la versión Indie de pago y esta pasó a ser gratuita. A partir de ese momento solo se debe de pagar en caso de rebasar un umbral de beneficios generados por los juegos desarrollados en la plataforma. Esto aumentó enormemente la popularidad del motor, el cual comenzó a ser usado por nuevos usuarios creando sus primeros juegos. En los años siguientes, Unity ha continuado añadiendo funcionalidades y mejorando las capacidades gráficas del motor poniéndose al nivel de los referentes en el sector. 3.1.1. Funcionamiento de Unity Unity sigue una arquitectura orientada a componentes y por lo tanto para desarrollar juegos u otras aplicaciones se hace uso de dos tipos de objetos, las entidades conocidas como GameObjects y los componentes. Las entidades son principalmente contenedores de componentes que por defecto tienen la información sobre su posición, rotación y escala en un componente Transform. Figura 3.1: Interfaz gráfica del editor de Unity Fuente de la imagen: https://unity3d.com/es/beta/2020.1b Los componentes se encargan de aportar la funcionalidad concreta que queremos para el programa. Unity ofrece componentes de todo tipo para la mayoría de funciones básicas en cualquier juego como renderizar un objeto, emitir sonidos o realizar interacciones físicas, entre otras. Para poder hacer juegos usando estas herramientas Unity cuenta con un editor con interfaz gráfica (figura 3.1) desde donde un usuario puede ir añadiendo entidades. Está dividido en cuatro secciones por defecto: Jerarquía: colocado en la parte izquierda, el usuario puede ver un listado con los GameObject que tiene en la escena en la que nos encotramos actualmente. Visor de escena y juego: en la pestaña central se puede ver la representación y posición de los GameObject de la escena. También podemos ver como se ve la escena a través de la cámara, que es como se vería al ejecutar el juego. Inspector: en la parte derecha se puede ver toda la información sobre los componentes del GameObject seleccionado y variar sus valores directamente. 27 Augmented reality treasure hunts engine UCM Explorador de archivos y consola: colocado en la parte inferior, se permite ver los directorios de recursos del proyecto donde podemos arrastrar otros nuevos. En la otra pestaña podemos ver la consola donde aparecen los mensajes de error. Unity gestiona por sí mismo el bucle de juego además del ciclo de vida de la aplicación, las entidades y sus componentes. Los usuarios pueden crear sus propios componentes programándolos en scripts que pueden heredar de Monobehaviour[13] haciendo que el ciclo de actualización del script lo lleve Unity. Estos scripts los editaremos a través de IDEs2como Visual Studio u otros. Unity permite añadir a los proyectos paquetes de terceros que pueden ayudar a la hora de desarrollar algo o poder añadir alguna funcionalidad, por ejemplo Vuforia. 3.1.2. Carga de recursos en Unity En el sector de los videojuegos sabemos que es muy importante que la carga de recursos sea rápida y eficiente debido al gran número de texturas, modelos, sonidos y otros elementos que requieren los juegos actuales. Por este motivo el equipo de Unity dio mucha importancia a este aspecto. Los recursos que se vayan a utilizar en un proyecto de Unity deben estar almacenados dentro del directorio Assets. Todos los recursos que están bajo el control de Unity contarán con archivos con extensión meta. Estos archivos tienen como función almacenar la configuración de importación del archivo al que está asociado en el proyecto y otras funciones. Unity también nos permite cargar de forma dinámica archivos haciendo uso del directorio Resources y su API3específica. Los recursos que se encuentran dentro del directorio Resources formarán parte de la aplicación final independientemente de si están siendo referenciados por alguna de las escenas que la conforman, por lo que es recomendable no dejar recursos no empleados en ese directorio. 3.2. Vuforia Vuforia4es un kit de desarrollo de software (SDK) pensado para la creación de aplicaciones de Realidad Aumentada. Su funcionamiento está basado en una tecnología de visión computacional con la que puede reconocer y seguir imágenes planas o tridimensionales conocidas como targets. Sobre esos objetivos que ha reconocido podemos proyectar elementos virtuales usando un motor gráfico[10], por ejemplo el de Unity, para simular que existen realmente. Vuforia fue creado originalmente por Qualcomm pero posteriormente fue vendido en el año 2015 a PTC la cual ha seguido desarrollando el software y añadiendo nuevas funcionalidades. Vuforia tiene muy buena integración con Unity y es una herramienta gratuita siempre que se use con fines no comerciales como es el caso del proyecto. Esta herramienta permite 2Sistema software para el diseño de aplicaciones que combina herramientas comunes para desarrolladores en una sola interfaz de usuario gráfica (GUI). 3Unity Resources: https://docs.unity3d.com/ScriptReference/Resources.html 4Portal de Vuforia: https://developer.vuforia.com/ 28 Augmented reality treasure hunts engine UCM la creación de targets de forma automática sin necesidad de usar el configurador de su propia página, eliminando pasos a realizar. En Vuforia encontramos tres elementos principales para el funcionamiento del reconocimiento de imágenes: Target: es el elemento físico que se va buscando a través de lo que ve la cámara. Puede ser una imagen plana, un objeto o una superficie. Tracker: es el encargado de analizar y procesar lo captado por la cámara buscando coincidencias con los datos del target que estamos usando. Database: es donde se guardan los datos que identifican a los target que se estén usando a la vez. También nos ofrece gran variedad de tipos de targets que se podrían llegar a integrar en nuestras aventuras tales como: Image Target, Cilinder Target, Cuboid Target y Surface Target. 3.2.1. Funcionamiento de Vuforia Engine Ahora vamos a ver cómo funciona internamente la librería de Vuforia para poder identificar y rastrear los targets haciendo uso de la cámara del dispositivo. Para ello durante la ejecución (figura 3.2), el dispositivo capta vídeo a través de la cámara y de este la SDK de Vuforia selecciona un fotograma. Esta imagen es transformada a una resolución más reducida para mejorar la velocidad de procesamiento y poder ser correctamente tratada por el Tracker. Vuforia analiza la imagen y busca coincidencias en la base de datos, la cual está compuesta por “targets”. Si consigue encontrar coincidencias mandará a Unity renderizar en pantalla los elementos que este objetivo tuviese asociados, alterando posición y rotación según cambie la posición del target detectado. 3.2.2. Claves de Vuforia Las aplicaciones de Vuforia necesitan de una clave para poder acceder a las cualidades del motor. Dichas claves se consiguen a partir de las licencias que se muestran a continuación: Licencia básica. Licencia básica + soporte en la nube. Licencia pro. Para conseguir una se debe ir a la página oficial de Vuforia, crear una cuenta nueva e ir al administrador de licencias para obtener cualquiera de las mencionadas previamente. Al hacer esto, se le pedirá al usuario que inserte un nombre para generar una nueva clave a partir de dicha licencia. Tras haberlo asignado, la clave se mostrará disponible en el administrador de licencias5de la cuenta del usuario. 5https://developer.vuforia.com/vui/develop/licenses 29 Augmented reality treasure hunts engine UCM Figura 3.2: Procesamiento de una imagen en la SDK de Vuforia Fuente de la imagen: https://www.scirp.org/html/1-9301927_48585.htm 3.3. React React6es una librería de código abierto para el lenguaje de programación web JavaScript. Fue concebida con el objetivo de facilitar la creación de aplicaciones en una única página (Single Page Application) las cuales vimos en la sección 2.2.2. La librería se encarga de la parte visual de la página y se suele usar con aplicaciones cuyos datos cambian constantemente. Fue creado por Jordan Walke, ingeniero de software en Facebook, bajo el nombre de FaxJS en el año 2011. Ese mismo año se comenzó usar en Facebook y al año siguiente en Instagram. En el 2013 pasó a ser de código abierto y en 2015, con la llegada de React Native, permitiría desarrollar de forma nativa en Android, IOS, Universal Windows Platform. Elegimos usar React como librería para crear nuestra aplicación web debido a que está especializada en SPAs y justo ese es el enfoque que queríamos dar a la página web con el objetivo de ser simple y rápida. 3.3.1. Funcionamiento de React React está construido en torno a hacer funciones, que toman las actualizaciones de estado de la página y que se traducen en una representación virtual de la página. Siempre que React es informado de un cambio de estado, vuelve a ejecutar esas funciones para determinar una nueva representación virtual de la página y, a continuación, se traduce automáticamente ese resultado en los cambios del DOM7necesarios para reflejar como 6https://es.reactjs.org/ 7Document Object Model: interfaz de programación para los documentos HTML y XML 30 Augmented reality treasure hunts engine UCM otra que hizo anteriormente, debe de construirlas desde cero, lo cual es un inconveniente importante cuando se trata de aventuras grandes. Para solucionar esto, la aplicación web permite almacenar aventuras “en la nube”. Los usuarios tienen la posibilidad de guardar la configuración de sus aventuras en el servidor que sostiene la aplicación web. Estas configuraciones engloban elementos como: el nombre de la aventura, las fases que la constituyen y una descripción de lo que trata la aventura. Adicionalmente, esta herramienta permite guardar aplicaciones hechas por los usuarios con el objetivo de que si un usuario quiere directamente jugar una ventura almacenada, no tengan que generarla a partir de su configuración. Al igual que con dichas configuraciones, estas aplicaciones también son almacenadas junto a una descripción sobre la misma dada por su autor. 4.3. Ejecución de las aventuras Por su parte, para la ejecución en el móvil se ha decidido usar Unity. Como se ha contado, Unity es un motor generalista para realizar juegos. Lo que se ha hecho es crear un “juego sin terminar” en el que le faltan los datos reales de la yincana que se ejecutará. Esos vienen de la herramienta de autoría. Cuando alguien hace una aventura, lo que está realmente haciendo sin enterarse es crear los recursos que le faltan al “juego sin terminar” y para conseguir la aplicación final lo que se hace es juntar las dos partes y pedir a Unity que haga la build final. 4.4. Datos que constituyen una aventura Estos datos que genera el usuario engloban: el nombre de la aventura, su clave de Vuforia para acceder a las cualidades del motor de AR y las fases de las que se compone dicha aventura. La manera en la que se almacena todo esto es mediante un JSON. Sin embargo, hay algunos tipos de fases que hacen uso de imágenes o ficheros de audio. Por lo que, en conjunto, los datos que configuran la aventura de un usuario están representados por un JSON y los ficheros adicionales que se referencien en el mismo. 4.5. Ciclo de generación de una aventura Habiendo mostrado los elementos que constituyen este proyecto y los datos que representan las aventuras del usuario, el esquema que se debe de seguir para generar una aventura es el que se muestra en la figura4.1 37 Augmented reality treasure hunts engine UCM Figura 4.1: Ciclo general de la generación de una aventura Para crear su propia aventura, el autor abrirá la aplicación de autoría, donde insertará datos como el título de esta y su clave de Vuforia. A partir de entonces, seleccionará las fases que desea incluir y rellenará los formularios de cada una de estas. En el momento en el que esté satisfecho con su resultado, podrá materializar su aventura, lo que le otorgará un proyecto de Unity que le permitirá generar una aplicación que representará su aventura. 38 Capítulo 5 Herramienta de autoría de yincanas Para conseguir esta herramienta se necesita una aplicación web que, como se vio en la Sección 4.2, esta aplicación estará compuesto de un frontend, que es lo que ejecuta el navegador, y el backend que proporciona servicios al frontend. Para mejorar la interactividad, usamos una SPA. El backend proporciona servicios de almacenamiento. En particular, mantiene los datos de las yincanas creadas, de forma que es posible reabrirlas y continuar su edición. Por otro lado, mantiene las aplicaciones para móvil generadas a partir de esas configuraciones de yincanas para que los usuarios puedan descargárselas e instalarlas en sus móviles para jugarlas. Para aprender a utilizar esta herramienta se puede consultar el manual de uso en el Apéndice A. 5.1. Frontend El módulo de frontend representa la página web que el usuario ve. Esta parte está desarrollada con React. A continuación se discuten las diferentes decisiones de diseño tomadas en esta parte del proyecto. 5.1.1. Flujo de la aplicación La aplicación web presenta una serie de pantallas por las que le usuario puede pasar para configurar sus aventuras, un esquema del flujo de la aplicación que seguiría un usuario sería el que se muestra en la siguiente figura: 39 Augmented reality treasure hunts engine UCM Figura 5.1: Flujo de aplicación 40 Augmented reality treasure hunts engine UCM 5.1.2. Estructura de los componentes de la WEB Dentro de las dos alternativas que ofrece React a la hora de crear componentes mencionadas en la Subsección 3.3.2. Nuestra decisión ha sido realizar nuestros componentes a modo de componentes funcionales. Esto es debido a que su estructura es más sencilla de escribir, además de que como tambien se ha visto en la Subsección 3.3.2, mediante los Hooks de React es posible obtener funcionalidades como estado interno y ciclo de vida. Por lo que éramos capaces de obtener los mismos resultados que utilizando componentes a modo de clases. 5.1.3. Estado interno Para almacenar los diferentes valores relacionados con las aventuras que configura el usuario, hacemos uso de los estados de cada uno de los componentes del proyecto. El problema aparece con el hecho de que, en la página web existen múltiples componentes, cada uno especializándose en una sección concreta de las aventuras, y tener toda su información desperdigada por múltiples componentes no es buena idea a la hora de recopilarla o acceder a ella. Por lo que la solución a esto es, tomar el estado del componente principal de la aplicación (aquel que contiene a los demás) y dárselo al resto a la hora de instanciarlos. El objetivo de esto es que cada componente tenga su estado propio, en el que almacene la información que solo le interesa a dicho componente, pero que el resto de cosas que sean relevantes para la creación de la aventura se almacenen en el estado del componente padre, el cual de esta forma pasa a ser una especie de “estado global”. Lo que nos permite esto es que, en caso de que sea necesario consultar algún dato sobre la aventura, basta con ir al estado del componente padre. Esta solución permite también la comunicación entre componentes que no están relacionados entre sí, utilizando pares clave-valor auxiliares en el estado global para intercambiar información. El estado interno cuenta con una estructura como la que se muestra en la figura 5.2. En él, aparte de almacenarse información general de la aventura mencionada en la Sección 4.4 se almacenan los siguientes elementos: Una sección que representar la fase que se esté configurando en cada momento junto con información adicional que permite saber si está completa o faltan campos por rellenar. Una variable de control que permite saber si se pretende crear una fase nueva o hacer modificaciones sobre una ya existente. Un índice que representa la posición en la que queremos que se añada la próxima fase que configuremos dentro la aventura. 41 Augmented reality treasure hunts engine UCM Figura 5.2: Estructura del estado global y estados locales en React 5.1.4. Instanciación de los componentes Como ya se ha mencionado, la idea es tener un componente que funcione como padre, y que sobre este se instancien el resto. Este proyecto tiene como pilar principal el componente “App” el cual es el componente que viene por defecto cuando se crea un nuevo proyecto de React. En él, se van a ir añadiendo los distintos elementos que den funcionalidad a la página. Dicha estructura se muestra en la figura 5.3. Figura 5.3: Esquema de instanciación de los componentes React En este caso, el componente que se instancia en App es “Steps”, el cual funciona como un contenedor de los componentes que representan los diferentes formularios que permiten configurar una aventura. Cada uno de estos formularios tiene como propósito configurar algún elemento relacionado con esta. 42 Augmented reality treasure hunts engine UCM 5.1.5. Estructura de los componentes A continuación se explica un poco más en detalle el resto de componentes que forman el frontend y permiten configurar las aventuras del usuario: Componente Steps Este componente funciona a modo de contenedor de los diferentes formularios que sirven para configurar las aventuras, sin embargo, solo muestra uno de estos en cada momento. Su representación visual se muestra en la figura 5.4: Figura 5.4: Elementos visuales del componente Steps El estado interno de este componente consta únicamente de un índice que tiene el propósito de indicar cuál de todos los componentes que contiene es el que debe de mostrar. Componente de resumen de la aventura Es el componente que “Steps” muestra por defecto, el objetivo de este es mostrar al usuario el estado de la aventura que está configurando en cada momento. Su representación visual es la que se muestra en la figura 5.5: 43 Augmented reality treasure hunts engine UCM Figura 5.5: Componente de resumen de la aventura Este componente carece de valores en su estado interno debido a que todos los datos que muestra en pantalla los obtiene o modifica directamente del estado global de la aplicación. Componente de carta de fase Este componente representa las cartas que se utilizan en la pantalla de resumen para representar las diferentes fases que tiene la aventura. Su representación visual es la que se muestra en la figura 5.5. El estado interno de estas cartas se compone de los siguientes elementos: Un objeto con toda la información de la fase a la que representa. Un índice con la posición de dicha fase dentro de la aventura. Componente de carga de aventuras Este componente tiene como objetivo dar información sobre las aventuras disponibles en el servidor. Su representación visual es la que se muestra en la figura 5.6 44 Augmented reality treasure hunts engine UCM Figura 5.6: Componente de carga de aventuras Este componente almacena en su estado interno los siguientes elementos: Una lista con los nombres de las configuraciones de aventuras disponibles para cargar. Una lista con las descripciones de dichas configuraciones. Una lista con las aplicaciones disponibles para descargar. Una lista con las descripciones de dichas aplicaciones. Un fichero para guardar la posible aplicación que el usuario quiera mandar al servidor para su almacenamiento. Una cadena de texto para almacenar la descripción de dicha aplicación. Componente de cartas aventuras Este componente es utilizado para representar tanto las diferentes configuraciones como las aplicaciones que se encuentran almacenadas en el servidor y están disponibles de cara al usuario. El estado interno de este componente está formado únicamente por un índice que sirve para identificar la configuración o la aplicación que representa. Su representación visual se puede ver en la figura 5.6. Componente Quiz Este componente representa el formulario que es necesario rellenar para poder incluir fases de tipo Quiz en una aventura. La representación gráfica de dicho formulario se muestra en la figura 5.7. 45 Augmented reality treasure hunts engine UCM Figura 5.7: Formulario fase Quiz El estado de este componente está compuesto por una cadena de texto que representa la pregunta del quiz y una lista de objetos que representan las distintas respuestas del mismo. Estas respuestas están compuestas por dos elementos, una cadena de texto que representa la respuesta en sí, y un booleano que indica si es correcta o no. Componente QR Esta fase representa el formulario que es necesario rellenar para poder incluir fases de tipo QR en una aventura. La representación gráfica del formulario se muestra en la figura 5.8. Figura 5.8: Formulario fase de QR 46 Augmented reality treasure hunts engine UCM 5.2.2. Servicios del backend El backend está preparado para recibir una serie de peticiones por parte del cliente haciendo uso del framework Express[2]2. Por medio de peticiones POST, el backend recibirá recursos e información necesaria para configurar una aventura. Dichos recursos serán almacenados en el servidor haciendo uso de un middleware de Express llamado Multer[14]. Por otro lado, el cliente hará uso de peticiones GET, cuando quiera recibir algo del servidor, como puede ser la propia página estática para configurar la aventura o los datos de configuración de una aventura alojada en el servidor. A continuación vamos a diferenciar los diferentes endpoints de los que dispone el backend. 1. Endpoints para recibir ficheros: El backend dispone de una serie de endpoints que le permiten recibir los diferentes archivos configurados por el usuario en el frontend: http://tfg.urbanar.org//image-upload(POST): representa la dirección a la que se envían las imagenes relacionadas con las fases de tipo imagen. http://tfg.urbanar.org/package-upload(POST): representa la dirección a la que se envían las imagenes relacionadas con las fases de tipo AR que van a ser escaneadas. http://tfg.urbanar.org/overlapping-upload(POST): representa la dirección a la que se envían las imagenes relacionadas con las fases de tipo AR que se van a superponer sobre otras. http://tfg.urbanar.org/sound-upload(POST): representa la dirección a la que se envían los archivos de audio relacionados con las fases de tipo sonido. http://tfg.urbanar.org/apk-upload(POST): representa la dirección a la que se envían las aplicaciones realizadas por los usuarios para su almacenamiento en el servidor. 2. Endpoints para generar una aventura: estos endpoints se utilizan para la generación del proyecto de Unity que le permitirá al usuario generar su aventura. http://tfg.urbanar.org/reset(GET): Tiene como objetivo preparar los directorios utilizados para la generación de aventuras. Esto implica eliminar cualquier archivo residual que se pudiera haber quedado de una aventura configurada anteriormente. http://tfg.urbanar.org/guardame-json(POST): Tiene como objetivo mandarle al servidor un JSON con toda la información que constituye una aventura. http://tfg.urbanar.org/generate-zip(GET): Tiene como objetivo recopilar toda la información relacionada con la aventura enviada por el frontend y devolver un archivo comprimido con el proyecto de Unity que permita generar la aventura en cuestión. 3. Endpoints para guardar aventuras: estas direcciones se utilizan para almacenar nuevas configuraciones de aventuras o aplicaciones en el servidor: 2https://expressjs.com/es/ 53 Augmented reality treasure hunts engine UCM http://tfg.urbanar.org/guardame-aventura(POST): recibe una descripción y tiene como objetivo tomar todos los ficheros de la aventura que se le hayan mandado previamente (imágenes, sonidos...), para crear un nuevo directorio dentro del servidor en el que se almacene dicha aventura. La estructura de dicho directorio es la que se muestra en la figura 5.17. Figura 5.17: Estructura de almacenamiento de configuraciones de aventuras en el servidor http://tfg.urbanar.org/guardame-APK(POST): recibe una descripción y tiene como objetivo tomar la aplicación que previamente el usuario ha mandado y agruparla con dicha descripción en un nuevo directorio que tenga la estructura que se muestra en la figura 5.18. Figura 5.18: Estructura de almacenamiento de aplicaciones en el servidor 4. Endpoints para obtener aventuras almacenadas en el servidor: dentro de esta sección se engloban los endpoints utilizados para obtener tanto las configuraciones de aventuras como las aplicaciones que otros usuarios hayan guardado en el servidor previamente: http://tfg.urbanar.org/aventuras-guardadas(GET): Tiene como objetivo devolver una lista con todas las configuraciones de aventuras que se encuentren disponibles en el servidor. http://tfg.urbanar.org/dame-aventura(POST): Recibe el nombre de una aventura y tiene como objetivo buscar el JSON que contiene su estructura dentro de las configuraciones alamacenadas en el servidor y devolverlo como respuesta. http://tfg.urbanar.org/getFile(GET): Recibe el nombre de un fichero y el nombre de la aventura a la que pertenece, tiene como objetivo buscar dicho 54 Augmented reality treasure hunts engine UCM fichero dentro de los que componen la aventura mencionada y devolverlo como respuesta. http://tfg.urbanar.org/aplicacionesListas-guardadas(GET): Tiene como objetivo devolver una lista con todas las aplicaciones almacenadas en el servidor. http://tfg.urbanar.org/getAPK(GET): Recibe el nombre de una aplicación, tiene el objetivo de buscar dicha aplicación entre las que se encuentran almacenadas y devolverla como respuesta. 5.2.3. Comunicaciones Front-End/Back-End Tras haber visto la manera en la que se pueden comunicar los dos módulos de la aplicación web. Es preciso analizar las situaciones en las que estas comunicaciones tienen lugar. Dichas situaciones se producen en los siguientes escenarios. Comunicaciones al generar una aventura Estas comunicaciones se realizan en el momento en el que el usuario está satisfecho con la aventura que ha configurado, ha cumplido todos los requisitos necesarios para poder generarla y presiona el botón de “Generar Aventura”. A partir de entonces los pasos que se siguen se muestran en la figura 5.19: Figura 5.19: Peticiones al generar una aventura Primero se le avisa al backend de que se va a generar una nueva aventura, el siguiente paso es mandarle uno por uno los ficheros relacionados con las fases que la conforman, como imágenes y los ficheros de audio. Posteriormente se envía el JSON con la estructura de la misma y finalmente se manda una petición para que se genere el proyecto con todos los datos enviados que permita generar la aventura configurada por el usuario. 55 Augmented reality treasure hunts engine UCM Comunicaciones al guardar una aventura Al igual que al generar una aventura, se llega a situación cuando el usuario está satisfecho con la que ha configurado y presiona el botón de ”guardar aventura”. Los pasos que se siguen son los mismos que a la hora de generar una aventura, a excepción del último, donde en lugar de recopilar todos los datos en un proyecto de Unity se mueven a otro directorio del servidor para su almacenamiento. El proceso que se sigue es el que se muestra en el esquema de la figura 5.20: Figura 5.20: Peticiones al guardar una aventura 5.2.4. Comunicaciones al guardar una aplicación Se llega a esta situación en el momento en el que el usuario se encuentra en la pantalla de carga de aventuras, ha subido una aplicación al frontend y tras presionar el botón de ”guardar”ha dado una descripción sobre la misma. En caso de existir una aventura con el mismo nombre en el servidor, se le avisa al jugador de que en caso de guardar se eliminará la ya existente. Si el jugador desea guardar la aventura en el servidor, los pasos que se siguen se muestran en la figura 5.21. Figura 5.21: Peticiones al guardar una aplicación Primero se envía la aplicación del jugador, una vez hecho esto se manda otra petición 56 Augmented reality treasure hunts engine UCM con la descripción de la misma para agruparlas y almacenarlas en el directorio que corresponda. Comunicaciones para obtener las aventuras almacenadas en el servidor Estas comunicaciones ocurren en la pantalla de carga de aventuras, donde al entrar en esta, se mandan peticiones para preguntar por las configuraciones y las aplicaciones que puede obtener el usuario. Los pasos que se realizan en esta situación se ven en la figura 5.22. Figura 5.22: Peticiones para obtener las aventuras disponibles en el servidor En caso de querer obtener una aplicación se manda únicamente una petición con el nombre de dicha aventura y se obtiene la misma como respuesta. Los pasos que se siguen en esta situación se ven en la figura 5.23. Figura 5.23: Peticiones al descargar una aplicación almacenada en el servidor En caso de que el usuario quiera cargar la configuración de una aventura los pasos que se siguen son los que se muestran en la figura 5.24. 57 Augmented reality treasure hunts engine UCM Figura 5.24: Peticiones al cargar una configuración almacenada en el servidor Primero se manda una petición para obtener el JSON de dicha aventura, luego se analizan las fases que esta contiene en busca de aquellas que requieran de archivos adicionales, como las de tipo imagen. Por cada una de estas fases se mandan peticiones para obtener los archivos que estas utilicen. 58 Capítulo 6 Motor de ejecución de yincanas Durante el desarrollo se utilizó la versión 2020.3.13f1[17] de Unity para aprovechar las ventajas de ser una LTS1. Tras haber visto en profundidad el funcionamiento de la aplicación web desarrollada para configurar nuestras búsquedas del tesoro, vamos a detallar dónde deben almacenarse los distintos recursos necesarios para las aventuras, el funcionamiento de nuestro ejecutor en Unity y como ha sido implementado. Como se menciona en el apartado anterior, la aventura viene definida en un fichero JSON, que en nuestro ejecutor de búsquedas del tesoro se denomina “AdventureData.json”. Está compuesto por el nombre de la aventura, la clave de Vuforia del usuario y un listado con la configuración de las fases de las que va a constar la búsqueda del tesoro. Dicho archivo será posteriormente procesado por nuestro motor para generar las fases que conformen nuestra aventura junto con el resto de archivos adicionales que requieran las fases de sonido, imagen y realidad aumentada. Dichos recursos adicionales se encontrarán almacenados dentro de la carpeta “Resources” en los siguientes directorios: AdventureImages: directorio en el que se encuentran almacenadas las imágenes empleadas en la fase de imagen. AdventureSounds: directorio en el que se encuentran almacenadas los audios empleados en la fase de sonido. OverlappingImages: directorio en el que se encuentran almacenadas las imágenes que se deben superponer sobre los targets en la fase de realidad aumentada. Cabe destacar también la ubicación en el proyecto de las imágenes que utilizaremos como targets para la fase de realidad aumentada. Dichas imágenes se encuentran en el directorio “/StreamingAssets/Vuforia” para que Vuforia sea capaz de generar los targets en tiempo de ejecución y sin necesidad de pasar por la página web para registrarlos dentro de una base de datos. Los archivos almacenados en StreamingAssets2no se llegan a procesar si no que se empaquetan en la APK y al abrirse la aplicación por primera vez se vuelcan en un subdirectorio dentro del directorio de la aplicación. 1Versión de un software que recibirá mantenimiento y parches a largo plazo. 2https://docs.unity3d.com/Manual/StreamingAssets.html 59 Augmented reality treasure hunts engine UCM Para que el desarrollo de las distintas fases sea modular, se emplea una escena por cada tipo de fase configurable desde la aplicación web. De esta forma se puede trabajar de forma independiente en cada una de ellas y es extensible a la hora de añadir fases nuevas. Como se detallará más adelante, se hace uso de carga aditiva de escenas, por lo que conviven al mismo tiempo los objetos que componen cada una de las escenas que estén cargadas. Contamos además con tres escenas propias del motor que no están asociadas a ninguna fase configurable: Una escena Logic, la cual es la primera en ejecutarse en el ciclo de vida de la aplicación. En la escena Logic se encuentran todos los elementos que son comunes al resto de escenas: GameManager, el canvas con el botón para pasar de nivel y las cámaras tanto de realidad aumentada como la cámara por defecto de Unity. Como empleamos carga aditiva, no es necesario que ninguna de las escenas de las fases tengas estos los elementos ya existen en esta escena base. Una escena Start en la que se muestra el nombre designado por el usuario a la búsqueda del tesoro. Una escena End en la que se muestra el logo de la Universidad Complutense de Madrid con el porcentaje de fases superadas. Tras esta introducción sobre la estructura interna del proyecto y su división en escenas, vamos a detallar en profundidad el funcionamiento del motor haciendo un recorrido por los componentes que han sido desarrollados. 6.0.1. GameManager GameManager es la clase principal que controla la administración de la información de la aventura obtenida del JSON, la carga de recursos y el cambio de escenas. Dicha clase ha sido implementada siguiendo el patrón Singleton como se explica en el libro Design Patterns: Elements of Reusable Object-Oriented Software[8]. A pesar de que las escenas por las que podemos pasar por la aventura son relativamente ligeras (principalmente debido a que casi todos los elementos presentes son de la interfaz), con el objetivo de reducir al mínimo la espera al pasar de una fase a otra, el GameManager hace uso de la carga aditiva de escenas. Una vez ha leído el JSON que compone la aventura, pone a precargar todas las escenas que estén involucradas, pero no las cargan completamente, las deja a un ochenta por ciento para completar el restante una vez que vayamos a pasar a dicha escena. En el momento en el que una fase se ha completado el GameManager es notificado de esto y antes de pasar a la siguiente fase comprueba si quedan más fases de este tipo. Si no vuelve a aparecer se descarga esa escena. La excepción a esta norma son las escenas de realidad aumentada y de escaneo de QR ya que son consideradas como “pesadas” debido a que al necesitar acceder a la cámara, consumen más recursos que las otras. La precarga de las escenas pesadas comienza una fase antes de llegar a ellas y su descarga se realiza automáticamente al completarlas aunque vuelvan a aparecer en la aventura, con la excepción de que la siguiente fase sea idéntica a la que se acaba de ejecutar. GameManager también se encarga de la gestión de las distintas cámaras con las que cuenta el proyecto. Contamos con una cámara de realidad aumentada que se emplea en 60 Augmented reality treasure hunts engine UCM las fases de escaneo de QR y de detección de targets, mientras que en el resto de fases se emplea la cámara con los componentes por defecto que proporciona Unity. Cuando se realiza un cambio de fase, GameManager comprueba cual es el tipo de fase a la que vamos a pasar y se encarga de dejar activa la cámara correspondiente para que no haya conflictos entre ambas. 6.0.2. MasterObject Este componente está asociado en cada una de las escenas de la aventura a un objeto que es representado como el padre del resto de objetos que la componen. Su función es activar o desactivar los objetos de la escena dependiendo de si la fase en la que se encuentra es la siguiente a ejecutar en la aventura o no. Para obtener la información de si este objeto debe activar/desactivar al resto, se ha hecho uso del patrón listener en el que esta clase, al inicializarse, se registra como listener del GameManager pasando a estar dentro del grupo de listeners de este. Dichos listeners van a ser notificados en el momento en el que se pase de una fase a otra, y en dicha notificación se les va a informar de la fase que toca en la aventura. De esta forma, si el MasterObject es informado de que toca una fase distinta a la suya, desactiva todos los objetos que contiene. 6.0.3. AdventureInfo Clase padre que representa la información mínima que tienen que contener las fases de la aventura. Cuenta con los siguientes atributos: el nombre de la fase y la pista asociada a la misma. También declara un método para rellenar dichas variables con información obtenida del JSON que define la aventura. Debido a que la información de cada fase tiene una estructura y atributos diferentes, cada fase que hereda de AdventureInfo añade sus atributos propios para su correcta definición y redefine el método para asignar dichos atributos. Es al principio de la ejecución, a la hora de leer el JSON, cuando se instancian estos objetos los cuales guardan la información que lleva cada fase para después ser dada al componente que ejecuta la fase, los “Stage’’. 6.0.4. Stage Clase abstracta de la cual heredan el resto de fases para poder hacer uso del polimorfismo y la cual dota de la funcionalidad a la fase. Cuenta con dos métodos abstractos, Init y OnStageEnd, que serán redefinidos en las clases hijas según la funcionalidad que requiera cada tipo de fase en el momento de comenzar y finalizar la fase respectivamente. El método Init recibe por parámetro un objeto que hereda de AdventureInfo y que como se ha visto almacena los datos de esa fase los cuales se usarán para configurar la escena. Las clases hijas tendrán otros métodos que se encargarán de dar la funcionalidad propia de cada fase. 61 Augmented reality treasure hunts engine UCM 6.1. Implementación de las fases A continuación, se describirá qué información se utiliza para cada fase disponible y cómo funciona internamente de cada una de ellas. 6.1.1. Fase Quiz La fase Quiz consiste en una escena de cuestionario donde se nos presenta una pregunta, un listado de respuestas posibles (figura 6.1a) que podemos seleccionar y un botón para confirmar nuestra selección. La pregunta puede tener una o varias respuestas correctas posibles. Para pasar a la siguiente fase deberemos de responder a la pregunta correctamente. Esta escena estará controlada por la clase “QuizStage”. Durante la inicialización de la aventura La clase que representa la información contenida en una fase de quiz es “QuizInfo”, la cual por medio del método “ReadFromJSON”, leerá una estructura JSON para obtener todos los datos necesarios para configurar la fase. Estos datos son una pregunta a responder y una serie de respuestas representadas por un string y un booleano que indica si es correcta o no. Ejecución de la fase en la aventura La clase “QuizStage” recibe en su método inicialización un objeto de tipo “QuizInfo”, que es de donde va a sacar la pregunta y las respuestas que debe mostrar en pantalla. Cuando el botón que disponemos para comprobar si hemos respondido bien al quiz es pulsado, el objeto “QuizStage” comprueba que dicha selección sea correcta. En caso en el que se haya respondido correctamente, se informa al GameManager de que la fase ha sido completada para que podamos continuar la aventura. 6.1.2. Fase QR La fase de QR hace uso de la cámara del dispositivo móvil a través de Vuforia. Para completar esta fase deberemos de buscar el QR que haya en nuestro alrededor y escanearlo (figura 6.1b). Esta fase está controlada por la clase “QRStage”. Durante la inicialización de la aventura La clase que representa la información contenida en una fase de QR es “QRInfo”, la cual por medio del método “ReadFromJSON”, leerá una estructura JSON para obtener todos los datos necesarios para configurar la fase. Estos datos constan de un string que representa el valor que tiene el QR que debemos de escanear. Ejecución de la fase en la aventura Cuando sea el turno de procesar una fase de QR, se llamara al método Init de QRStage donde guardaremos el valor del QR almacenado en QRInfo en una variable string para más tarde poder comparar el valor leído con el esperado. 62 Augmented reality treasure hunts engine UCM 4. Interferencias en el museo Por desgracia FiDI aún no será capaz de localizar los títulos ya que siguen existiendo interferencias. Nos sugerirá subir a la tercera planta, el museo, ya que allí hay muchos aparatos electrónicos que pueden ser causantes de las mismas. Usando la fase de GPS haremos un detector de interferencias que nos indicará como de cerca o lejos estamos del causante, el AD-1-32. Para poder apagarlo y eliminar por fin las interferencias se deberá responder correctamente a preguntas sobre su historia. 5. Buscar la biblioteca Ahora FiDI, liberada de las interferencias, hallará donde estaban ocultos los títulos, en la biblioteca. Por ello se deberá de buscar la entrada usando el GPS. Al llegar de nuevo la puerta estará bloqueada pero no por otra contraseña sino por una llave la cual ha sido hecha pedazos y los fragmentos han sido esparcidos por la facultad. 6. Primer fragmento de llave Este primer fragmento está oculto entre los videojuegos de ZX Spectrum que hay en el museo. Al llegar deberemos de escanear las carátulas en busca de pistas. Al escanear “Olé toro” se mostrará texto sobre la carátula indicando en cual carátula está el fragmento que buscamos, siendo “Army Moves” quien lo oculta. Al ser escaneado veremos el fragmento de la llave que no se veía a simple vista. 7. Segundo fragmento de llave El segundo fragmento de la llave estará en la segunda planta, la de los laboratorios, donde deberemos de buscar la sala de técnicos. Allí se presenta el siguiente reto a completar que es encontrar la combinación que se obtiene al traducir los símbolos que hay en las puertas de los laboratorios, previamente colocados por el organizador de la yincana, siguiendo el orden: 5-4-9-7-10-2-1-3-6-8-11. Para ello usará una tabla de conversión que podrá obtener en la sala de técnicos. Al introducirla correctamente obtendremos el segundo fragmento. 8. Tercer fragmento de llave El tercer fragmento se encontrará oculto entre la maleza en la parte trasera de la facultad por lo que se deberá de ir a la planta baja. Al salir al exterior se usará el GPS como detector de metales hasta que se encuentre el último fragmento de la llave. 9. Búsqueda del diploma Ya con la llave completa se podrá acceder al interior de la biblioteca para buscar el preciado título universitario, aunque deberemos de rebuscarlo entre el montón ya que solo nos interesa el de nuestra titulación. Para identificarlo usaremos los QR que tienen por dentro. Esta montaña de diplomas deberá de colocarse antes de comenzar el juego. 69 Augmented reality treasure hunts engine UCM 7.2. Evaluación con usuarios Aunque no se han realizado gran cantidad de pruebas con usuarios sí que se han hecho evaluaciones con las diferentes demos que se han ido creando durante el desarrollo y con la aventura de demostración. Quedarían por hacer pruebas con otros usuarios de forma más metódica y organizada. Durante estas pruebas hemos visto que en general el usuario era capaz de entender que debía de hacer en cada momento de la aventura a excepción de cuando se pedía la contraseña para entrar al edificio, ya que no quedaba claro que el valor escaneado por el QR era la contraseña. En ese momento se indicó a los probadores que pueden consultar las pistas siendo la única situación donde ha sido requerido su uso. Estas pruebas tenían el fin de pulir los puntos de interacción que no queden del todo claros a nivel del propio motor ya que pueden existir otros problemas de comprensión derivados del propio diseño que se ha dado a la búsqueda del tesoro. 7.3. Posibilidades como motor de juegos serios Hemos visto que con el proyecto es posible, además de hacer búsquedas del tesoro, adaptar y/o crear juegos serios. Tomando como ejemplo los videojuegos desarrollados para la asignatura de Juegos Serios en los que se usa la plataforma de uAdventure vista en el Capítulo 2, tanto las aventuras gráficas como las geoposicionadas, podemos ver que las interacciones necesarias pueden ser transportadas o adaptadas pero manteniendo la esencia. Tomamos dos juegos desarrollados para esa asignatura como ejemplo: Guerra Civil Guerra Civil2desarrollado por Miguel Mur, Georgi Medkinov y Liyuan Li es un juego donde se recorre Ciudad Universitaria tratando de identificar donde se habían tomado fotografías durante la Guerra Civil Española (1936-1939). El tiempo de desarrollo del mismo estuvo en torno a un mes entre diseño e implementación del mismo. El robo de Breda El robo de Breda3, desarrollado por Adrián de Lucas, Felipe Cuadra y Aurora García es un juego en el cual se recorre el centro de Madrid mostrando puntos de interés de la época de los Austrias mientras sigues la pista de un ladrón que había robado el cuadro La Rendición de Breda de Velázquez. Al igual que el otro título se desarrolló en un mes entre diseño e implementación. En ambos casos los ingredientes principales de estos juegos son: los diálogos, las decisiones y el uso del GPS para dirigir al jugador por el mapa. Todos esos aspectos son replicables usando las fases disponibles actualmente en el motor e incluso poder reconvertir otras interacciones que en los juegos originales no hubieran sido posibles como escanear QRs o usar realidad aumentada. 2Repositorio del juego Guerra Civil: https://github.com/JuegosSeriosGr3/JuegosGeoposicionados2 3Repositorio del juego El robo de Breda: https://github.com/Alonefcp/MadridDeLosAustrias 70 Augmented reality treasure hunts engine UCM Uno de los aspectos que no replicables en nuestro motor sería la no linealidad que se puede conseguir en uAdventure. El motor de este TFG, al estar desarrollado con un enfoque hacia las búsquedas del tesoro, está forzado a ser lineal y tener que completar los objetivos en el orden dado. 71 Bloque de conclusiones 72 Capítulo 8 Conclusiones Originalmente en la propuesta de este TFG proponía la realización de un motor en Unity con el objetivo de ejecutar búsquedas del tesoro con elementos de realidad aumentada. La idea era que fuera lo más genérico posible pues se iba a usar para generar este tipo de juegos en las diferentes facultades de la Universidad Complutense de Madrid. Durante el desarrollo se planteó la idea de hacer un configurador web para simplificar de cara al usuario la creación de las búsquedas del tesoro, el cual ha acabado siendo una parte fundamental del resultado final. El resultado final del proyecto son dos piezas bien diferenciadas: el configurador de aventuras en la web y el motor de ejecución de las aventuras en Unity. Herramienta de autor web En el configurador web tenemos la opción de crear aventuras desde cero, continuar con una previa guardada en el servidor o descargar una búsqueda del tesoro lista para instalar y jugar. A la hora de configurar aventuras podrás añadir diferentes tipos de fases como ya se han visto, añadir pistas a cada una, reordenar las fases o añadirlas en la posición que el usuario quiera. Podemos guardar la aventura en el servidor para seguir configurándola en otro momento y también descargar el zip que contiene el proyecto de Unity. El proyecto cuenta con un total de siete fases diferentes entre las que elegir y configurar para crear las búsquedas del tesoro. Cada una de esas fases puede llevar asociada una pista en el caso de que se crea conveniente dar algo de información extra. En el configurador se ha tenido en cuenta la importancia de mejorar en cada revisión su usabilidad con el objetivo de limitar en la medida de lo posible las fricciones cuando se use, tratando que el usuario tenga la mejor experiencia posible. Se ha creado un pequeño manual como forma de ayuda para las primeras veces que se haga uso de la herramienta el cual se puede consultar en el Apéndice A. 73 Augmented reality treasure hunts engine UCM Motor de ejecución de yincanas El motor de ejecución de Unity implementa todas las fases disponibles, la gestión de escenas y de recursos. El usuario no necesita utilizar Unity ya que solo deberá de utilizar el archivo AutoBuild.bat el cual generará la APK ya preparada para ser instalada en un dispositivo Android. El motor al arrancar lee del archivo de configuración las fases que componen la aventura y el orden de las mismas. Estas fases se cargarán de forma simultanea por carga aditiva en el caso de ser sencillas o bajo demanda si son más pesadas (como se vio en el Capítulo 6). Según se va completando cada fase de la aventura se comprueba si esa fase aparece más veces en la aventura pero si no es el caso de descarga porque ya no será necesaria. Se añadieron las opciones de dar pistas específicas para cada fase y permitir saltarlas. Al final de la aventura se muestra un mercador que indica el porcentaje de fases que ha completado el jugador por sí mismo sin tener que saltar la fase. A la hora de desarrollar el motor en Unity hubo problemas derivados de las diferentes versiones de librerías que usamos, en especial Vuforia ya que ha sido actualizado hace poco a la versión 10.0 y la documentación previa de la versión 9.8, la versión que utilizamos, está siendo eliminada de su página web dificultando bastante el desarrollo de las fases de realidad aumentada. 74 Capítulo 9 Trabajo futuro El estado actual del proyecto podría considerarse cerrado. Esto no quita que se puedan introducir mejoras y añadidos que podrían dar más valor a los usuarios que vayan a usarla. Algunas de las ideas para expandir el proyecto son: Generación del APK en el servidor: La idea sería de tener dentro del servidor una copia de Unity donde poder generar la build y devolver al usuario únicamente el APK en vez de hacer al usuario de bajarse un zip y hacer que tenga que lanzar el AutoBuild.bat. Esto eliminaría pasos y complicación a usuarios menos familiarizados con la informática. Guardado de partida: Esta funcionalidad permitiría a los usuarios guardar el progreso que lleven en la búsqueda del tesoro que estén jugando ya sea porque deben parar un momento o porque quieran continuar otro día. Al acabar cada fase es un momento idóneo para realizar estos guardados, quitando la necesidad al usuario de hacerlo manualmente a través de un botón. Soportar nuevas plataformas: Unity da muchas facilidades a la hora de hacer aplicaciones multiplataforma por lo que esta expansión sería relativamente sencilla. Esto permitiría que más personas puedan usar sus dispositivos en este tipo de actividades. Realizar evaluación formal con usuarios: Durante el desarrollo se han hecho varias pruebas con usuarios usando pequeñas demos pero se han realizado con familiares y amigos por lo que sería beneficioso para el proyecto el realizar pruebas más formales y planificadas con otros usuarios ajenos al proyecto. Esto permitiría evaluar la herramienta web de creación de aventuras y también las diferentes fases del motor para ver si son intuitivas e identificar puntos a mejorar. 75 Augmented reality treasure hunts engine UCM Soporte de sesiones múltiples en la herramienta web: Actualmente la herramienta está preparada para ser usada por una persona a la vez. Esto es así ya que si hay dos o más personas puede haber solapamiento a la hora de mandar los recursos de las aventuras configuradas. La idea sería dar un identificador único a cada sesión para hacer las peticiones de guardado y recuperación en base a ese identificador evitando la colisión con datos de otros usuarios. Fases compartimentalizadas en paquetes de Unity: El objetivo sería que cada una de las fases disponibles estuviera en su propio paquete de Unity y solo instalar las necesarias según la aventura configurada, lo que ayudaría a reducir el tamaño de la aplicación al solo tener los recursos indispensables para cada aventura. Nuevas fases: Aunque, como se ha demostrado, se puede llegar a crear una búsqueda del tesoro muy completa con las fases que ya hay disponibles, la adición de otras nuevas abriría más posibilidades a nuevos tipos de puzles o dinámicas de juego. Algunas propuestas para trabajo futuro podrían ser fases con reconocimiento de voz o realidad aumentada con objetos tridimensionales. Sistema de telemetría: Un sistema de telemetría podría ser una mejora muy importante para el proyecto sobre todo si se hace uso de la aplicación como un juego serio ya que, por ejemplo, un docente podría comprobar: que han hecho sus alumnos, que respuestas han dado y que desempeño han tenido en la prueba. Habría eventos específicos a cada tipo de fase según los parámetros que tiene y también eventos más genéricos como duración de una fase. 76 Chapter 8 Conclusions Originally, in the proposal of this TFG, was proposed the realization of an engine in Unity with the objective of executing treasure hunts with elements of augmented reality. The idea was for it to be as generic as possible, since it was going to be used to generate this type of game in the different faculties of the Complutense University of Madrid. During development, the idea of making a web configurator was proposed to simplify the creation of treasure hunts for the user, which has ended up being a fundamental part of the final result. The final result of the project is two well-differentiated pieces: the authorship tool on the web and the adventure execution engine in Unity. Web-based authorship tool In the web configurator we have the option to create adventures from scratch, continue with a previous one saved on the server or download a treasure hunt ready to install and play. When configuring adventures you can add different types of phases as we have already seen, add clues to each one, reorder the phases or add them in the position preferred. We can save the adventure on the server to continue configuring it at another time and also download the zip that contains the Unity project to create the APK. The project offers a total of seven different phases to choose from and configure to create the treasure hunts. Each of these phases can be associated with a clue in case it is convenient to give some extra information and there is also a button to skip the phase in progress with the aim of preventing players from being blocked or not knowing how to continue. In the tool the importance of improving its usability in each revision has been taken into account with the goal of limiting errors as much as possible when using it, trying to ensure that the user has the best possible experience. A small manual has been created as a form of help for the first times that the tool is used, which can be consulted in the Appendix A. 77 Augmented reality treasure hunts engine UCM Treasure Hunts engine The Unity runtime implements all available stages, scene and resource management. The user does not need to use Unity since he will only have to use the AutoBuild.bat file which will generate the APK already prepared to be installed on an Android device. When the engine starts, it reads from the configuration file the phases that are part the adventure and their order. These phases will be loaded simultaneously by additive load in the case of being simple or on demand if they are heavier (as seen in chapter 6). As each phase of the adventure is completed, it is checked if that phase appears more times in the adventure, but if it is not the case the phase is removed because it will no longer be necessary. The option to give specific hints for each stage and allow them to be skipped was added. At the end of the adventure a market is displayed that indicates the percentage of phases that the player has completed by himself without having to skip the phase. When developing the engine in Unity there were problems derived from the different versions of libraries that we use, especially Vuforia since it has recently been updated to version 10.0 and the previous documentation of version 9.8, the version that we use, is being removed from its website, making the development of the augmented reality phases quite difficult. 78 Augmented reality treasure hunts engine UCM El hecho de utilizar siempre los mismos directorios para agrupar los ficheros que componen las aventuras en el backend generó diversos problemas como la contaminación de las aventuras con archivos residuales de otras aventuras configuradas anteriormente. Por lo que soluciené esto añadiendo funcionalidades al backend que solucionaban esta clase de problemas. Con la aparición de nuevas fases tanto en el motor de Unity como en la página web volví a realizar aportaciones en el motor de Unity con la creación de la clase Master Object que controlaba los objetos de cada escena. A la hora de crear nuevos formularios en el frontend me dediqué a preparar el de las fases de Sonido, intervine en la creación del componente de resumen de la aventura y creé el componente que se especializa en la carga de aventuras almacenadas en el backend. Estos dos últimos contenían mucha información que inicialmente se mostraba no muy elegantemente asi que creé los componentes que representan las cartas que se utilizan para mostrar dichos bloques de datos. El siguiente apartado en el que trabajé fue en la posibilidad de almacenar aplicaciones hechas en el servidor siguiendo las mismas ideas que se utilizaron a la hora de guardar las configuraciones. A medida que íbamos probando a hacer aventuras de ejemplo, nos íbamos dando cuenta de que en ocasiones, a pesar de que las fases de una aventura estuvieran bien configuradas, podía surgir el caso de que un jugador no entendiera lo que se suponía que tenía que hacer. Por lo que el siguiente elemento en el que me puse a trabajar fue en la incorporación de pistas, tanto en la parte del frontend, como en la otorgación de las mismas en el motor de Unity. Habiendo tenido en cuenta que era posible que los usuarios pudieran no saber cómo completar una fase, pensamos que podría ocurrir lo mismo con los usuarios a la hora de rellenar correctamente los formularios del frontend, por lo que lo siguiente en lo que me centré fue en la posibilidad de otorgarle un botón en cada uno de estos que le diera información sobre cómo rellenarlos. Esto nos llevó a pensar en la manera en la que íbamos a mostrar dicha información, la solución a la que llegué fue en la utilización de un paquete de npm que daba la posibilidad de utilizar alertas estilizadas las cuales se podían personalizar con diversos elementos. Aprovechando esta nueva manera de darle información al usuario, lo siguiente que hice fue la preparación de alertas en momentos como cuando el usuario ha guardado su configuración para informarle de que la operación se ha hecho satisfactoriamente. O a la hora de intentar guardar una fase incompleta, darle información de cómo se tiene que rellenar el formulario para poder guardar. En esencia, mejorar el diseño UX de la página web. El siguiente objetivo que tuve, fue hacer que las aventuras almacenadas en el servidor, tanto las configuraciones como las APKs, tuvieran una descripción que el usuario que las guardó hubiera dado para dar algo de información sobre las mismas. Una vez hecho esto hice que en el frontend a la hora de mostrar las aventuras disponibles se mostraran también sus respectivas descripciones. Volviendo a la parte del motor de Unity, me dediqué a estilizarlo mediante assets que tenía guardados, a realizar las transiciones entre escenas y a meter animaciones a los 85 Augmented reality treasure hunts engine UCM distintos elementos de la interfaz. Sin embargo, solo realicé la estilización de un par de escenas, el resto fue terminado por mis compañeros. Una vez llegados a este punto, teníamos ya la página web funcional y capaz de generar aventuras y el motor preparado para pasar por todo el ciclo de vida de una de estas, independientemente de las fases que tuviera. Por lo que el siguiente paso fue hacer la aventura de ejemplo que se muestra en el Capítulo 7 con la ayuda de mis compañeros Adrián y William. Por último, mis últimas aportaciones hasta la fecha en el TFG han sido en la memoria, donde he complementado la sección de implementación, redactando la parte relacionada con la página web, y he realizado aportaciones en la sección del motor en Unity. 10.4. William Molina Cumba Tuve interés en participar en este TFG por el tema de la realidad aumentada, a pesar de no haber tenido experiencia previa con ninguna herramienta de las utilizadas en este trabajo como Vuforia y React, a excepción de Unity con el ya estaba familiarizado gracias al grado que estaba cursando. Debido a esto, he podido profundizar mis conocimientos sobre todos los temas que trata nuestro TFG, aunque partiendo de cero en algunos de ellos. Empecé investigando sobre las distintas herramientas a usar antes de iniciar una implementación, y participé en las decisiones sobre escoger versiones apropiadas tanto para el proyecto de Unity como para Vuforia. Sin embargo, me centré en la implementación y uso de los Scriptable Objects como contenedores de lo que iba a ser finalmente una aventura dentro del proyecto de Unity. Partiendo de la base que realizó mi compañero Adrián para la fase de QR en Unity, realicé una segunda iteración para que esta sea completamente funcional y se adaptase a la primera estructura de fases montada por mi compañero David. Con el objetivo de automatizar la generación de una aventura en forma de APK a partir del proyecto de Unity creado con las características determinadas por el configurador web, junto a mi compañero Adrián, implementamos un script en C Sharp para Unity y un archivo BAT que lograra una build completa con su simple ejecución. Desarrollando más esta idea de automatización de builds, me dediqué a explorar opciones para poder realizarlas desde el propio servidor, investigando el servicio Unity Cloud Build y descartando la idea de instalar Unity en un sistema operativo linux sin interfaz gráfica como era el servidor. Posteriormente me encargué de implementar las bases del sistema de precarga de escenas en Unity, que tenía como objetivo evitar largas esperas entre fases de la aventura al ser completadas, anticipando la carga de una escena que se usaría consecutivamente a otra con ayuda del orden determinado en el archivo JSON que describía la aventura y el orden de las fases. Después de establecer de nuevo ciertas bases en la estructura de las fases en Unity, me ocupé de la investigación e implementación de escenas aditivas en Unity, siguiendo 86 Augmented reality treasure hunts engine UCM el mismo principio anterior sobre tener una carga ligera de escenas. También junto a mis compañeros, participé en las decisiones de diseño para las siguientes iteraciones de implementación de este sistema. El siguiente paso del que me encargué, fue crear un script de comandos tanto en versión Windows BAT como en versión Linux SH para generar de forma automática un archivo ZIP con todos los directorios necesarios del proyecto de Unity para generar una aventura. A continuación, trabajé en el proceso de petición desde el frontend al backend para llamar a este script desde la herramienta web, y que finalmente al acabar su ejecución, se descargase el ZIP con el proyecto de Unity para el usuario. En cuanto a las implementaciones de las fases en Unity, empezó a surgir la necesidad de ajustar los elementos que componían las escenas y mejorar su disposición en pantalla, por lo que añadí un paquete al proyecto de Unity para facilitar el ajuste de los elementos UI y realicé varios ajustes en las escenas que habían creadas en ese momento. Siguiendo con Unity, continué trabajando en la lógica para la fase Quiz, la cual había sido iniciada por David. La misma necesidad de mejora visual surgió en el apartado web, por lo que modifiqué la mayoría de archivos CSS y elementos HTML, para obtener un acabado más amigable con el usuario de la herramienta web tanto en las fases desarrolladas hasta ese momento, QR, Quiz, ImageCharger e ImageTarget, como en la navegación y aspecto del resto de la web. Aprovechando la realización de estos ajustes, también arreglé algún que otro bug en la parte de los componentes del frontend. Retomando el apartado de implementación del proyecto de Unity, continué realizando cambios en la fase para QR e implementé la escena y la lógica para la fase Sound y para la fase InputText. De esta última además, añadí su correspondiente formulario en la parte del frontend, y volviendo a familiarizarme con los cambios de mis compañeros, hice algunos ajustes y arreglos de errores en otros formularios. Una vez mi compañero David añadió los recursos visuales que se iban a usar para las escenas finales en Unity, adapté la mayoría de escenas a la nueva estética definitiva, ajusté elementos de la UI en las diferentes fases creadas y me encargué de que la interfaz funcionara de forma correcta en distintas resoluciones de pantalla. Siguiendo con Unity, implementé el conteo de las fases que se iban completando de forma normal y de las que se iban saltando con el botón de ayuda, y su posterior muestra al final de la aventura. Se volvió a requerir una vez más cambios en el aspecto de la web, en este caso me encargué de esta tarea modificando algunos elementos que ya había creado en la anterior iteración y aportando colores más acordes al aspecto general de la herramienta web. Y volviendo a recuperar contacto con los cambios de mis compañeros en la parte de frontend en React, me dediqué a implementar restricciones requeridas en la fase de TargetImage para evitar posibles errores o conflictos con el uso de Vuforia. Entre estas restricciones estaban que las imágenes subidas en esta fase tuvieran un tamaño máximo de 2 Megabytes y en caso de escoger una imagen a superponer sobre el target, que esta tenga el mismo tamaño que el target. Como últimas aportaciones al proyecto en Unity, estuve haciendo algunos ajustes más a elementos de la UI y finalmente busqué recursos para los sonidos de toda la interfaz e implementé el sistema de sonido global para la aplicación. 87 Augmented reality treasure hunts engine UCM Saltando de nuevo a la herramienta web, concretamente en el componente de carga de aventuras, estuve trabajando en frontend y backend para mostrar avisos y advertencias al usuario a la hora de sobrescribir una APK que ya había sido subida con el mismo nombre o notificar que la APK ha sido guardada en el backend. Al acabar esta tarea, junto a David solucionamos un error que no permitía actualizar de forma correcta la lista de APKs subidas. Con el flujo de trabajo y creación de aventura bastante pulidos, colaboré en el diseño de la aventura de ejemplo junto a mis compañeros Adrián y David. Como últimas aportaciones al trabajo, he estado documentando parte del código en el proyecto de Unity, he realizado algunos ajustes mínimos en los elementos de la herramienta web y me he dedicado a colaborar en la corrección de este documento. 88 Bloque de anexos 89 Apéndice A Manual de usuario En esta sección verás una introducción a como se crean las búsquedas del tesoro con las herramientas hechas para este TFG, desde la configuración de la aventura hasta la ejecución en nuestro dispositivo. Comenzaremos explicando cómo se utiliza la aplicación web donde vamos a configurar las búsquedas del tesoro. Veremos cómo se usa, que opciones nos ofrece y como se configuran las diferentes fases disponibles. Una vez estemos conformes con la aventura podremos descargar el proyecto de Unity y se explicarán los pasos y requisitos necesarios para poder generar una APK para nuestro dispositivo Android. A.1. Creación de una aventura La creación de una aventura de la búsqueda del tesoro se realiza desde una página web1en los servidores de la UCM. Una vez estemos dentro de la página podremos poner nombre a la aventura e introducir la clave de Vuforia aunque esta solo será requerida en el caso de que haya fases de RA. Si queremos añadir una fase a la aventura usaremos en desplegable de la parte superior donde podremos elegir la fase que queremos. Tendremos como opciones: Quiz, QR, Image, ImageTarget, Sound, InputText y GPS. Según vayamos añadiendo fases iremos viendo cómo se van añadiendo al resumen de la aventura. En esta sección (figura A.1) veremos todas las fases creadas y el orden que tienen. Para cada fase tendremos la opción de editarla o de borrarla completamente. Si queremos insertar una fase en una posición concreta dentro de la aventura podremos hacerlo con el selector de la parte superior donde podremos seleccionarlo. La fase que hubiera en esa posición pasara a ser la siguiente en la lista. Una vez acabada la configuración de todas las fases podremos guardar la aventura en el servidor, pudiendo recuperarla más tarde y también descargar el proyecto de Unity con todo listo para generar el APK. A continuación vamos a ver como se configura cada una de las diferentes fases que podemos utilizar para crear nuestras propias búsquedas del tesoro. 1Página del configurador de aventuras: http://tfg.urbanar.org/ 90 Augmented reality treasure hunts engine UCM Figura A.1: Vista resumen de fases que conforman la búsqueda del tesoro A.1.1. Configurar una fase Quiz La fase de Quiz permite crear una fase que contiene una pregunta y de dos a seis respuestas diferentes (figura A.2). El enunciado de la pregunta lo escribiremos en el primer cuadro de texto que aparece. Las respuestas se irán añadiendo una a una en el cuadro de texto inferior. Cada vez que confirmemos una respuesta esta aparecerá un la parte inferior donde podremos marcarla como correcta o incorrecta y también podremos eliminarla. Figura A.2: Creación de una fase Quiz A.1.2. Configurar una fase QR La fase de QR se configura escribiendo lo que queremos que contenga el código QR (figura A.3). Según lo vayamos escribiendo el código que aparece en pantalla se irá recalculando para que devuelva lo que hemos escrito cuando sea escaneado. Una vez estemos conformes podemos descargar el código QR para poder imprimirlo y escanearlo durante la aventura y guardar la fase. 91 Augmented reality treasure hunts engine UCM Figura A.3: Creación de una fase con código QR A.1.3. Configurar una fase Image Las fases de Image consisten en una imagen en la parte superior y debajo un texto donde podemos escribir una descripción de lo que se ve o dar información al usuario. Para configurar la fase se requiere que se seleccione una imagen (figura A.4) que el usuario tenga en el ordenador para luego mostrarla en la aventura. También podemos añadir un texto que se deberá de introducir en el cuadro de texto que aparece debajo de la previsualización de la imagen. Figura A.4: Configuración de una fase Image 92 Augmented reality treasure hunts engine UCM A.1.4. Configurar una fase de RA Lo primero que deberemos hacer para poder configurar una fase de realidad aumentada será disponer de una cuenta en la página2de Vuforia. Esto se debe a que se necesita una key3para poder utilizar las funcionalidades de RA. Ya teniendo nuestra cuenta podremos crear una de forma gratuita desde la pestaña Develop->LisenceManager. Cuando la tengamos tendremos que ponerla en el resumen de la aventura. Para configurar las fases con realidad aumentada tenemos dos opciones disponibles que son superponer un texto (figura A.5a) o una imagen(figura A.5b) al objetivo que vamos a escanear. Para seleccionar un tipo u otro recurrimos a un desplegable. En ambos casos deberemos de subir una imagen que hará de target y luego adicionalmente le pasaremos un texto u otra imagen según que queramos conseguir con la fase. (a) Superponer texto (b) Superponer imagen Figura A.5: Dintintas configuraciones para fases con realidad aumnetada A.1.5. Configurar una fase de GPS Para configurar este tipo de fases el usuario podrá utilizar un marcador en el mapa (figura A.6) para indicar el lugar a donde quiere que llegue el jugador. En el lugar escogido podremos ver las coordenadas de latitud y longitud. Además deberemos de indicar el radio de acción que tiene el lugar indicado (según queramos que se acerque más o menos al lugar el jugador) y podemos introducir un texto que sirva de pista para dar una idea al usuario de donde tiene que ir. 2Página de Vuforia para crear una cuenta: https://developer.vuforia.com/vui/auth/register 3Clave de producto que se utiliza para verificar que una copia de un software es original. 93 Augmented reality treasure hunts engine UCM Figura A.6: Configurador de una fase con geolocalización A.1.6. Configurar una fase de texto Las fases de introducir texto solo requieren de introducir un pequeño texto para explicar al jugador lo que debería de hacer o buscar y luego la frase o contraseña (figura A.7) que debe de introducir el jugador para poder pasar a la siguiente fase. Figura A.7: Configurador de una fase con introducción de texto A.1.7. Configurar una fase de sonido Para configurar fases que hacen uso de sonido deberemos de subir el audio que queramos usar en formato mp3 o wav y poner un texto para poder explicar al jugador lo que queramos. Una vez hayamos subido el audio a la aplicación podemos escucharlo (figura A.8) para verificar que es el correcto. 94 Augmented reality treasure hunts engine UCM [16] Steven Feiner, Blair MacIntyre, and Dorée Seligmann. Knowledge-based augmented reality, volume 36. Communications of the ACM, 1993. [17] Unity-Technologies. Unity User Manual 2020.3 (LTS). [18] Wayne Piekarski and Bruce Thomas. ARQuake: The Outdoor Augmented Reality Gaming System, volume 1. Bubok Publishing S.L, 2002. 101 Autores: Leire Osés Sánchez Adrián de Lucas Gómez David Czepiel William Molina Cumba Leire Osés Sánchez Adrián de Lucas Gómez David Czepiel William Molina Cumba 21 de diciembre de 2022 Ult. actualización 28 de mayo de 2022 L A T EX lic. LPPL & powered by TEFLONCC-BY-NC-SA Esta obra está bajo una licencia Creative Commons “Reconocimiento-NoCommercial-CompartirIgual 3.0 España”.