uso de la realidad aumentada en el desarrollo de ... · herramientas unity y la librería vuforia....

Ángela Heredia Rodrigo

María Vico Pascual Martínez-Losa

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Grado en Ingeniería Informática

2014-2015

Título

Director/es

Facultad

Titulación

Departamento

TRABAJO FIN DE GRADO

Curso Académico

Uso de la Realidad Aumentada en el desarrollo de aplicaciones móviles

Autor/es

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2015

publicaciones.unirioja.esE-mail: [email protected]

Uso de la Realidad Aumentada en el desarrollo de aplicaciones móviles, trabajofin de grado

de Ángela Heredia Rodrigo, dirigido por María Vico Pascual Martínez-Losa (publicado porla Universidad de La Rioja), se difunde bajo una Licencia

Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los

titulares del copyright.

Facultad de Ciencias, Estudios Agroalimentarios e Informática

TRABAJO FIN DE GRADO

Grado en Ingeniería Informática

Uso de la Realidad Aumentada en el desarrollo de

aplicaciones móviles

Alumno:

Ángela Heredia Rodrigo

Tutores:

María Vico Pascual Martínez Losa

Logroño, Junio, 2015

Uso de la Realidad Aumentada en el desarrollo de aplicaciones móviles, trabajo fin de grado de Ángela Heredia Rodrigo, dirigido por María Vico Pascual Martínez Losa (publicado por la Universidad de La Rioja), se difunde bajo una Licencia Creative Commons Reconocimiento-

NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a loa titulares

del copyright.

El Autor Universidad de La Rioja, Servicio de Publicaciones, 2015 publicaciones.unirioja.es E-mail: [email protected]

Resumen

Con el paso del tiempo, podemos ver que el mundo de la informática evoluciona a un ritmo vertiginoso desarrollando nuevas tecnologías que se implantan en el mundo real, como es el caso de la Realidad Aumentad. La característica fundamental de este proyecto es el uso de la Realidad Aumentada. Ésta es un nuevo paradigma de interacción con el usuario, por el cual se incluyen elementos virtuales en el mundo real. Uno de los campos en los que la Realidad Aumentada está más presente es el del entretenimiento, por ello se ha desarrollado un juego. Unidos estos dos aspectos, este proyecto consiste en un juego desarrollado con las herramientas Unity y la librería Vuforia. Unity es un motor muy potente de juegos y una de sus características más importantes es la facilidad que nos da para implementar contenido de Realidad Aumentada. DinoShooting es un juego para dispositivos Android en el cual, a través de Realidad Aumentada y apuntando a un marcador específico, aparecerán unos dinosaurios por la escena. El usuario podrá interactuar con ellos a través de la pantalla del dispositivo, lanzando meteoritos que impactarán con los dinosaurios y ganará puntos por ello. También se perderán vidas cuando los dinosaurios no sean alcanzados por el meteorito.

Abstract

In the last decades, we can see how the world of computer science progresses and new technologies are developed being included in the real world, as it is the case of Augmented Reality (AR). The most important characteristic of this project is the use of augmented reality. This technology is a new paradigm in the interaction with the user, by which virtual elements are included in the real world. The field of entertainment is one of the domains in which Augmented Reality is more present. For this reason, this game has been developed. Thus, this project consists of a game developed with the tools Unity and the Vuforia library. Unity is a powerful game engine and one of its main characteristics is the ease to include Augmented Reality content. DinoShooting is a game for Android devices, in which through the use of Augmented Reality and pointing to a specific indicator, some dinosaurs will appear on scene. The user will be able to interact with them through the screen of the device, throwing meteorites that will impact the dinosaur so the user will win points. Moreover, lives will be lost when the dinosaurs are not reached by the user.

1

Contenido

Índices de las figuras………………………………………………………………………………………………………….3 Introducción………………………………………………………………………………………………………………………5 1.- Motivación………………………………………………………………………………………………………………….5 2.- Objetivos…………………………………………………………………………………………………………………..5 3.- Metodología……………………………………………………………………………………………………………….5 4.- Tecnologías concretadas previamente.……………………………………………………………………….6 4.1.- Android……………………………………………………………………………………………………………..6 5.- La Realidad Aumentada en la actualidad…………………………………………………………………….6 5.1.- Uso de la Realidad Aumentada………………………………………………………………………….6 6.- Planificación inicial……………………………………………………………………………………………………..8 Desarrollo del producto……………………………………………………………………………………………………10 SPRINT 0……………………………………………………………………………………………………………………..…10 1.- Planificación……………………………………………………………………………………………………....10 2.- Desarrollo…………………………………………………………………………………………………………..10 2.1.- Soluciones hardware…………………………………………………………………………..10 2.2.- Soluciones software………………………………………………………………………..….11 2.2.1.- Open Source………………………………………………………………………..11 2.2.2 Código cerrado gratuito…………………………………………………………12 2.2.2.1.- Metaio……………………………………………………………......12 2.2.2.2.- Qualcomm Vuforia……………………………………………....13 2.3.- Conclusiones y elección de la aplicación..…………………………………………...15

2.3.1.- Elección de la aplicación…………………………………………………….…16 3..-Revisión y valoración……………………………………………………………………………………….….16

SPRINT 1………………………………………………………………………………………………………………………...17 1.- Planificación………………………………………………………………………………………………………..17 2.- Desarrollo…………………………………………………………………………………………………………...17 2.1 Team FoundationServer (TFS)…………………………………………………………….....17 2.2.- Toma de contacto con Unity………………………………………………………………..18 2.2.1.- Estructura y funcionamiento de juego……………………………….…19 2.3.- Toma de contacto con Vuforia………………………………………………………….…19 2.4.- Ejemplo Unity + Vuforia……………………………………………………………………...20 2.5.- Alcance mínimo……………………………………………………………………………….….20 2.6.- Requisitos de la aplicación…………………………………………………………………..21 2.6.1.- Requisitos funcionales……………………………………………………….…21 2.6.2.- Requisitos no funcionales………………………………………………….…21 2.6.3.- Requerimientos de la aplicación……………………………………….….22 2.7.- Diagrama de navegabilida.…………………………………………………………………..22 2.8.- Posibles ampliaciones……………………………………………………………………….…22 2.9.- Pila inicial de la aplicación……………………………………………………………….….22 2.8.- Diseño del plan de pruebas………………………………………………………………...23 3.- Revisión y valoración……………………………………………………………………………….…………24 SPRINT 2………………………………………………………………………………………………………………………..24

1.- Planificación………………………………………………………………………………………………….……25 2.- Desarrollo……………………………………………………………………………………………………….….25 2.1.- Modelos 3D…………………………………………………………………………………….….25 2.1.1.- Personales principales…………………………………………………… .…..25 2.1.2.- Decorado……………………………………………………………………..……..27 3.- Revisión y valoración……………………………………………………….………………………………...28

2

SPRINT 3…………………………………………………………………………………………………………………….….28 1.- Planificación……………………………………………………………………………………………………….29

2.- Desarrollo…………………………………………………………………………………………………………..29 2.1.- Imagen Target…………………………………………………………………………………….29 2.2.- Importar modelos 3D………………………………………………………………………….29 2.3.- Escena principal………………………………………………………………………………….30 2.4.- Generar dinosaurios por la escena……………………………………………………..30 3.- Revisión y valoración………………………………………………………………………………………….31 SPRINT 4………………………………………………………………………………………………………………………..32

1.- Planificación……………………………………………………………………………………………………….32 2.- Desarrollo……………………………………………………………………………………………………….....32 2.1.- Lanzar meteoritos……………………………………………………………………………….32 2.2.- Implementación de vidas y puntuación……………………………………………….35 2.2.1.- Vidas…………………………………………………………………………………...35 2.2.2.- Puntuación…………………………………………………………………………..37 2.3.- Diseño de vidas y puntos…………………………………………………………………….37 2.4.- Mostrar vidas y puntos en la pantalla………………………………………………….37 3.- Revisión y valoración…………………………………………………………………………………………..38 SPRINT 5…………………………………………………………………………………………………………………………38

1.- Planificación………………………………………………………………………………………………………..39 2.- Desarrollo……………………………………………………………………………………………………………39 2.1.- Diseño de botones……………………………………………………………………………….39 2.2.- Insertar botones………………………………………………………………………………….39 2.3.- Implementación de las funciones de los botones………………………………..40 2.4.- Incrementar la dificultad del juego ……………………………………………………..40 3.- Revisión y valoración………………………………………………………………………………………….41 3.1.- Game Over………………………………………………………………………………………….41 SPRINT 6………………………………………………………………………………………………………………………..46

1.- Planificación……………………………………………………………………………………………………….46 2.- Desarrollo…………………………………………………………………………………………………………..46 2.1.- Diseño de botones y logo………………………………………………………………..….46 2.2.- Diseño de la pantalla de inicio…………………………………………………………….47 2.3.- Implementación de la pantalla de inicio……………………………………………..47 2.4.- Sonido del juego…………………………………………………………………………………48 2.4.1.- Audio…………………………………………………………………………………..50 3.- Revisión y valoración………………………………………………………………………………………….50 SPRINT 7………………………………………………………………………………………………………………………..51

1.- Planificación……………………………………………………………………………………………………….51 2.- Desarrollo…………………………………………………………………………………………………………..51 2.1.- Pantalla de información………………………………………………………………………51 2.2.- Sonido del juego 2………………………………………………………………………………53 2.2.1.- Audios……………………………………………………………………………..….54 2.3.- Pruebas………………………………………………………………………………………………54 2.3.2.- Pruebas realizadas………………………………………………………………54 3.- Revisión y valoración………………………………………………………………………………………….55 3.1.- Sonido Game Over……………………………………………………………………………..56 Gestión real del proyecto…………………………………………………………………………………………………57 Conclusiones…………………………………………………………………………………………………………………..57 Mejoras…………………………………………………………………………………………………………………………..58 Bibliografía………………………………………………………………………………………………………………….….59

3

Índice de las figuras

Fig 1. Ejemplo Historias Misteriosas.

Fig 2. Ejemplo Junaio.

Fig 3. Tabla de tareas.

Fig 4. Ejemplo del uso de la RA en la cabina de un avión.

Fig 5. Gafas, Google Glass, desarrolladas por Google.

Fig 6. Ejemplo creado con la prueba gratuita de Metaio Creator.

Fig 7. Estructura de la SDK de Metaio.

Fig 8. Ejemplo de Junaio en un dispositivo Android.

Fig 9. Ejemplo de Junaio en un dispositivo Android

Fig 10. Uso de Vuforia.

Fig 11. Diagrama de flujo de datos en una aplicación de ejemplo.

Fig 12 Tabla de comparación Vuforia VS Metaio.

Fig 13. Lista de ítems en TFS.

Fig 14. Tablero kanban sprint 1.

Fig 15. Carpeta del proyecto dentro de Unity.

Fig 16. Ventana de importación de Vuforia.

Fig 17. Ejemplo de Unity + Vuforia.

Fig 18. Tabla backlog general del producto.

Fig 19. Burndown sprint 1.


Fig 21. Dino.

Fig 22. Tron.

Fig 23. Tero.

Fig 24. Rita.

Fig 25. Bronto.

Fig 26. Dibujo escaneado de Curri.

Fig 27. Imagen de la realización del modelo en Blender.

Fig 28. Imagen del modelo 3D con texturas.

Fig 29. Imagen del modelo 3D con huesos.

Fig 30. Imagen del modelo Decorado 1.






Fig 36. Foto del diseño de la escena principal.

Fig 37. Imagen de la escena principal en Unity.



Fig 40. Representación del lanzamiento del meteorito.

Fig 41. Imagen del cubo, Subsuelo, para el impacto de los meteoritos.

Fig 42. Imagen del Cubo, Subsuelo, añadiendo la configuración específica.

Fig 43. Tron con el Collider.

Fig 44. Imagen para simular una vida.

Fig 45. Imagen para simular dos vidas.

Fig 46. Imagen para simular tres vidas.

4

Fig 47. Imagen para el marcador de vidas.



Fig 50. Imagen botón play.

Fig 51. Imagen botón pause.

Fig 52. Imagen botón stop.

Fig 53. Imagen asignación del tipo de textura.

Fig 54. Creación de la animación mediante Mecanim.

Fig 55. Creación de las animaciones en el Animator.

Fig 56. Comprobación del Game Over en el dispositivo móvil.



Fig 59. Imagen botón sonido encendido.

Fig 60. Imagen botón sonido apagado.

Fig 61. Imagen del logo del juego.

Fig 62. Imagen del diseño de la pantalla de inicio.

Fig 63. Textura de la pantalla de inicio.

Fig 64. Pantalla del inicio del juego.



Fig 67. Imagen botón información.

Fig 68. Imagen de la pantalla de información.


Fig 70. Imagen del botón de atrás.

Fig 71. Textura para el fondo de la pantalla de información.

Fig 72. Pantalla de información.


Fig 74. Tabla de comparación de horas.

5

Introducción

A continuación se presenta la memoria del Trabajo de Fin de Grado del Grado de Ingeniería Informática de la Universidad de La Rioja. En esta memoria se recogen los aspectos más importantes del desarrollo del proyecto, basado en el estudio y la práctica a través de una aplicación para Android de Realidad Aumentada en la actualidad, denotada ésta con las siglas RA.

1.- Motivación En la actualidad la Realidad Aumentada es una tecnología que está muy presente y que está en continua evolución, por ello en este proyecto se va apostar por esta nueva tecnología que cambia la forma en la que el usuario interacciona con los sistemas de información. El TFG fue impulsado por la empresa Netbrain Media Solutions S.L., la cual propuso la RA en Android como tema principal del proyecto. Al ser ésta una tecnología nueva para mí, me pareció interesante trabajar con ella y juntarla con otras tecnologías que ya conocía como Android.

2.- Objetivos El objetivo global del proyecto es conocer las principales herramientas de realidad aumentada que existen en la actualidad y desarrollar una aplicación para el sistema operativo Android. Dicha aplicación se realizará con alguna de las herramientas y las tecnologías estudiadas y estará asociada a alguno de los campos donde la RA tiene más auge en la actualidad. ¿Qué implicará en la empresa? La empresa ya había tratado alguna vez y de manera puntual con RA a través de Metaio y lo que se pretende con este proyecto es conocer más formas de trabajar con RA con el fin de indagar en otros campos de la informática y ofrecer a los clientes nuevos productos con la última tecnología.

3.- Metodología Todas las metodologías tienen ciertas características que hacen que sea adecuado usarlas en un proyecto u otro. Para este proyecto se va a usar la metodología ágil SCRUM, ya que presenta ciertas ventajas. Esta metodología está basada en el desarrollo incremental en lugar de la planificación y ejecución completa del producto. Cada iteración o sprint va a tener su propia planificación y desarrollo con el fin de obtener al final de ésta un entregable para el cliente. Una de las principales ventajas que nos ofrece SCRUM frente a otras metodologías es que los requisitos son flexibles y no están completamente definidos al principio del proyecto. Por este motivo, en cada sprint o iteración se definirá una planificación con tareas u objetivos nuevos a cumplir, un desarrollo de éstas y una parte final de revisión y valoración global del sprint. Esto se va a llevar a cabo a través de la herramienta Team Foundation Server (TFS), que ofrece características útiles para realizar SCRUM.

6

4.- Tecnologías concretadas previamente

4.1.- Android Aunque al comienzo no se conocen las tecnologías que se van a utilizar, sí que se tiene claro que la aplicación se va a desarrollar para el sistema operativo Android. Éste es un sistema open source basado en el núcleo Linux. Entre las características más destacables se puede observar que utiliza SQLite para almacenamiento de datos, se compila en un ejecutable Dalvik y corre en la Máquina Virtual Dalvik, la cual está diseñada especialmente para Android y utiliza Apache Harmony. Se eligió este sistema ya que la mayor parte de España utiliza un Smartphone con sistema operativo Android, además de poseer una inmensa comunidad de desarrolladores. Para trabajar se descarga el SDK de Android que incluye librerías y herramientas necesarias para el desarrollo de aplicaciones. Incluye herramientas como plugin ADT y SDK de Android.

5.- La Realidad Aumentada en la actualidad La realidad aumentada es una tecnología que nos permite completar la percepción directa o indirecta de la realidad física con elementos virtuales generados por un ordenador, obteniendo una realidad mixta en tiempo real entre ambas cosas. Está relacionada con la Realidad Virtual (RV) y comparte con ésta algunas propiedades y características como la generación de objetos y elementos 2D y 3D mediante un ordenador con el objetivo de presentarlos al usuario en su campo visual. No obstante, ambas tienen una diferencia clara: mientras que la RV consiste en sustituir la realidad percibida por un entorno 100% generado, en la RA lo que se pretende es añadir y completar el mundo real percibido por el usuario con información adicional, sin perder éste la percepción del mundo real pero añadiendo en él más información e incluso interactuar con éste. La RA no es una tecnología nueva. Ya en 1994 Paul Milgram y Fumio Kishino definen la realidad de Milgram-Virtuality Continuum como un continuo que abarca desde el entorno real a un entorno virtual puro. En medio hay Realidad Aumentada (más cerca del entorno real) y Virtualidad Aumentada (más cerca del entorno virtual). También en 1997 Ronald Azuma define la Realidad Aumentada como combinación de elementos reales y virtuales, interactiva en tiempo real y registrada en 3D. En la actualidad, con la creciente presencia de los Smartphones (teléfono móvil inteligente) con conexión a internet y la cultura del nuevo consumidor, están haciendo de los Smartphone los dispositivos de RA más utilizados, gracias a las aplicaciones que proporcionan funciones de RA, que han sido las causantes de acercar este mundo a una gran cantidad de público.

5.1.- Uso de la Realidad Aumentada Entre las aplicaciones, podemos encontrar que la RA puede emplearse en distintos campos y puede dar nuevas posibilidades de interacción que hacen que esté presente en muchos ámbitos como la localización, la educación, la arquitectura, el arte, la medicina, etc. Localización Uno de los principales usos consiste en identificar y localizar todo aquello que nos rodea, como monumentos, tiendas, restaurantes, hoteles, etc. Por ejemplo, si se está haciendo turismo y se mira alrededor a través de la pantalla del Smartphone se podrá ver el nombre de los monumentos que le rodean y obtener información sobre ellos.

7

Educación Otro campo en el que cada vez va cogiendo más importancia es la educación. Muchas de estas aplicaciones se usan en museos, exhibiciones, parques temáticos, etc. En estos lugares es habitual la presencia de redes wi-fi que, junto con las aplicaciones de RA, permiten que los usuarios obtengan información sobre lugares o puedan ver recreaciones en 3D de obras arquitectónicas, artefactos científicos, dinosaurios, etc. Arquitectura La RA es muy útil a la hora de resucitar virtualmente edificios históricos destruidos, así como proyectos de construcción que todavía están bajo plano. Sanidad La capacidad de enriquecer la visión de la realidad mediante el uso de la información digital puede jugar un papel importante en el área de la medicina, siendo un ejemplo claro de cómo las nuevas tecnologías pueden ser útiles para mejorar los servicios que reciben los ciudadanos. Para muchas actividades, los profesionales precisan de gran cantidad de información de contexto como complemento a la visualización directa o a la que es suministrada por las cámaras. Así, para un cirujano, es muy importante disponer de tres dimensiones de los órganos y huesos, alrededor de la zona en la que está realizando la intervención, o también por ejemplo información complementaria de datos del paciente. Publicidad Este ámbito cada vez está cogiendo más importancia. La RA es usada para captar la atención del público. Un ejemplo claro es la nueva campaña publicitaria de Toyota Historias misteriosas (se puede ver en la Fig 1) en las que el usuario apunta con su cámara a cualquier Toyota y después de rastrear el coche, se muestra una serie de relatos en forma de vídeo que desvelan qué hay bajo el capó de un Toyota.

Entretenimiento El campo en el que la RA está más presente es el de los videojuegos, ya que proporcionan una forma novedosa de jugar. Sobre todo porque con el paso del tiempo han ido ganando popularidad plataformas de juegos con controles innovadores, que se escapan del mando tradicional, como es el caso de la videoconsola Wii de Nintendo y los videojuegos táctiles de las plataformas móviles. Turismo Un campo en el que cada vez se utiliza más la Realidad Aumentada es el turismo, ya que se pueden visitar los elementos más significativos de una ciudad y viajar al pasado con ilustraciones o ver toda la información referente a ese elemento con sólo apuntar con el móvil.

Fig 1.Ejemplo Historias Misteriosas.

8

Algunas plataformas como Junaio o Layar, permiten el desarrollo de aplicaciones de terceros, prácticamente sin conocimientos técnicos a través de sus servidores. Se pueden ver estas plataformas en los enlaces [6] y [7] de la bibliografía respectivamente.

6.- Planificación inicial El proyecto se desarrollará del 2 de febrero de 2015 al 12 de junio de 2015 y durante este periodo se dedicarán 300 horas. Como se ha explicado anteriormente se va a utilizar una metodología SCRUM, por lo que las horas van a estar divididas en sprints. En cada sprint se dedicarán entre 30 y 40 horas en función de la tarea a realizar y sobre todo del tiempo del que se disponga. A continuación se describirán las tareas generales del proyecto.

Gestión del proyecto: al comienzo del proyecto se dedicó un tiempo a realizar una descripción global y aproximada del mismo y el tiempo que se dedicará a cada iteración en función de las necesidades.

Estudio de la Realidad Aumentada hoy en día: con el fin de conocer qué es la RA y cómo se utiliza se ha realizado un estudio de los principales usos de la RA en la actualidad así como una pequeña introducción para situar al lector.

Tecnologías de RA: se va a realizar un estudio sobre las principales herramientas para crear RA, con el fin de utilizar en nuestro proyecto la más adecuada.

Reuniones: durante el proyecto, se van a dedicar unas horas a reuniones tanto con el tutor de la empresa como con el tutor de la universidad.

Cierre de la memoria: se retocarán detalles concretos de la memoria, además de añadir la plantilla del proyecto, las conclusiones, la bibliografía, el índice, los anexos y las posibles mejoras.

Presentación: se preparará la presentación y defensa del proyecto.

Estudio de las herramientas: se va a llevar a cabo un estudio de las principales herramientas de creación de Realidad Aumentada con el fin de elegir de entre las estudiadas una para desarrollar la aplicación.

Captura de requisitos: con el software de desarrollo y el tema de la aplicación decididos se va a obtener unos requisitos iniciales.

Diseño del plan de pruebas: se va a diseñar un plan de pruebas que se seguirá durante todo el proyecto.

Desarrollo del producto: realización de la aplicación de Realidad Aumentada para Android.

Fig 2. Ejemplo Junaio. Fuente: http://wtinfotech.co.uk/augmentedreality/

9

Tarea T.Estimado Sprint Comienzo Fin Gestión del Proyecto

5 h - 16/02/2015 16/02/2015

Estudio de la RA hoy en día

10 h - - -

Tecnologías de RA

30 h Sprint 0 02/02/2015 13/02/2015

Reuniones 10 h - - -

Cierre de la Memoria

5 h - 01/06/2015 12/06/2015

Presentación 15 h

Estudio de Herramientas

30 h

Sprint 1 16/02/2015 27/02/2015 Captura de Requisitos

10 h

Diseño plan de pruebas

5 h

Desarrollo del Producto

180 h - 02/03/2015 29/05/2015

Total 300 h

Fig 3. Tabla de tareas.

10

Desarrollo del producto

Como se va a utilizar una metodología SCRUM, para cada sprint se va a desarrollar una planificación inicial, una descripción y por último una valoración y revisión de lo alcanzado. En la planificación se describirán las tareas que se van a realizar, en la descripción se resumirán dichas tareas y se explicará su realización y por último, en la revisión se valorarán las tareas realizadas y se añadirán nuevas tareas surgidas.

Sprint 0

1.- Planificación

Este sprint recogerá todo lo estudiado sobre las herramientas de RA, con el fin de decidir con cuál se desarrollará el proyecto. Entregable: al final del sprint el cliente obtendrá un estudio sobre las principales herramientas de RA en la actualidad y unas conclusiones finales para el desarrollo de la aplicación.

2.- Desarrollo

La tecnología existente en la actualidad para producir RA se puede englobar en dos categorías: tecnologías hardware que proporcionen capacidades de Realidad Aumentada; y, software aplicable a soluciones hardware ya existentes y cuyo propósito general no es el de proporcionar RA, por ejemplo Smartphone, Tablets, etc.

2.1.- Soluciones hardware En la actualidad podemos encontrar desde Smartphones hasta cascos, auriculares o gafas que, por separado o en conjunto, se acoplan al usuario y le ofrecen un sistema de visualización de Realidad Virtual que, aplicada al mundo real, da lugar a la Realidad Aumentada. Estos objetos normalmente llevan incorporados un headset con un sistema GPS necesario para poder localizar con precisión la situación del usuario o un display para mostrarle al usuario la información virtual. Además de esto suelen incorporar una o más tecnologías como cámaras digitales, sensores ópticos, acelerómetros, giroscopios, brújulas de estado sólido, RFID, etc. A grandes rasgos podemos clasificar estos dispositivos físicos en dos conjuntos:

Dispositivos video-through: entre los que se encuentran aquellos dispositivos que realizan la captura de imágenes o video que están aislados de los dispositivos de visualización. En este grupo se encuentran Smartphones o cámaras de vídeo.

Dispositivos see-through: entre los que se encuentran dispositivos capaces de realizar tanto tareas de captura de la escena real como de mostrarla con información aumentada al usuario. Estos dispositivos trabajan en tiempo real, haciéndolos más costosos en presupuesto y en complejidad. Se puede encontrar un ejemplo en los aviones de combate, que muestran información al piloto sobra la altura, velocidad o identificación de blancos, como se ve en la Fig 4.

11

Dentro de este grupo podemos encontrar los dispositivos HMD (head-mounted-display). Se trata de dispositivos parecidos a un casco en el que, sobre una lente muy próxima al ojo del usuario, que le permite ver el mundo real, se proyectan los elementos virtuales. Estos combinados con la visión del mundo real generan la RA. La proyección, puede ser llevada a cabo directamente sobra la retina de los ojos del usuario recibiendo el nombre de monitor virtual de retina. Un ejemplo de estos dispositivos son las Gafas Glass de Google que se ven en la Fig 5.

2.2.- Soluciones software Se trata de proporcionar software a dispositivos electrónicos tales como Smartphones o tabletas, los cuales disponen de las tecnologías hardware necesarias para ofrecer funcionalidad de RA. Este software ha de ser capaz de realizar una función coherente entre las imágenes obtenidas con la cámara del mundo real y las imágenes virtuales. Estos modelos 3D tienen que estar situados en lugares del mundo real y el mundo real tiene que estar capturado con la cámara en un sistema de coordenadas. Esto recibe el nombre de registro de imágenes. Este proceso viene dado a partir de métodos de visión computacional. Gran número de métodos de visión por ordenador de RA se heredan de modo similar a los métodos de odometría visual. En el mercado podemos obtener multitud de soluciones software de RA que las podemos dividir en software de código abierto (open source) y software de código cerrado gratuito.

2.2.1.- Open Source Entre estas herramientas se encuentran algunos ejemplos como:

ArToolkit: es una librería para la construcción de Realidad Aumentada. Ésta utiliza algoritmos de visión por computador para calcular la ubicación de la cámara y la orientación relativa respecto a la posición de los marcadores físicos que se sitúan en el mundo real. Todo esto en tiempo real.

ArUco: biblioteca para el desarrollo de Realidad Aumentada basada en OpenCV.

ATOMIC Authoring Tool: es un proyecto para desarrollar RA y mapas mentales y está orientado principalmente para no desarrolladores.

Fig 4. Ejemplo del uso de la RA en la cabina de un avión Fuente: http://www.diarionorte.com/article/85862/tecnologia-militar-al-auto-familiar

Fig 5.Gafas, Google Glass, desarrolladas por Google. Fuente: Google

12

ATOMIC'Web' Authoring' Tool: herramienta que permite crear aplicaciones de RA para exportarlas a cualquier sitio web. Desarrollada especialmente para no desarrolladores.

2.2.2.- Código cerrado gratuito Aunque hay más software de creación de Realidad Aumentada, se ha indagado más en dos. Se han estudiado sus componentes principales con el fin de ver cuál puede aportar más y a cuál se le va a sacar más provecho. 2.2.2.1.- Metaio Metaio es una empresa Alemana, fundada en Múnich en 2003 por el actual CEO, Thomas Alt y CTO, Peter Meier. Esta empresa fue creada a partir de un proyecto inicial con Volkswagen y tras esto, los fundadores recibieron una subvención alemana con la que lanzaron su empresa. Actualmente cuenta con más de 500 proyectos, 450 clientes y más de 100.000 desarrolladores. Su principal objetivo es integrar a la perfección los datos virtuales con la realidad. Cuenta con una serie de productos como: Metaio Creator: programa propio para crear experiencias de Realidad Aumentada de forma sencilla y rápida para iOS, Android o PC, sin necesidad de conocimientos en programación. Se puede destacar alguna característica como que es multiplataforma, formato fbx o lenguaje de programación propio, AREL, además de poder exportar la aplicación nativa en iOS, Android, Windows o paquete AREL. Es un software cuyo coste ronda los 600 euros y cuya versión gratuita tiene ciertas limitaciones como:

Sólo se pueden crear dos patrones Trackeables.

Sólo se puede exportar con paquete AREL. Metaio SDK: Herramienta por excelencia de Metaio. Es la más completa, ya que te permite programar aplicaciones de RA en Android, iOS y PC. Existe una versión gratuita con el inconveniente que muestra una marca de agua en las aplicaciones creadas con este SDK. Los precios de las versiones de pago están entre los 3000 y los 5000 euros. La SDK incluye componentes de captura, de sensor, de representación de seguimiento y la interfaz. La interfaz proporciona la interacción entre la aplicación y los otros 4 componentes. Se puede ver su estructura en la Fig 7.

Fig 6. Ejemplo creado con la prueba gratuita de Metaio Creator.

13

Metaio Cloud: Servicio que ofrece Metaio para guardar tu contenido en la nube, donde éste podrá ser actualizado fácilmente. Hace falta una versión de pago de Metaio Creator, ya que para subir los proyectos a la nube, es necesario exportar dicho proyecto como App Cloud y con la versión gratuita esta forma de extracción es imposible. También será necesario tener cuenta en Metaio, cuyo registro es gratuito. Metaio CVS (Búsqueda continua visual): servicio de pago adicional que ofrece Metaio para el reconocimiento de imágenes. Está incorporado dentro de la web de Metaio y en él se puede crear una base de datos de imágenes propia. Estas imágenes serán reconocidas y rastreables por SDK APP, Junaio o Metaio Cloud. Junaio: es un navegador móvil creado por Metaio de uso exclusivo para RA. Dicho navegador se puede descargar gratuitamente desde Play Store o Apple Store y se basa en tecnologías web tales como CML o HTML5. Una característica a destacar es que un usuario podrá subir su aplicación directamente al navegador de Junaio para probarla en su dispositivo.

2.2.2.2.- Qualcomm Vuforia En 1985 siete personas de la industria se reunieron para discutir una idea. Aquellos visionarios decidieron construir Quality Communications y esbozaron un plan que ha evolucionado hasta

Fig 7. Estructura de la SDK de Metaio. Fuente: http://dev.metaio.com/sdk/documentation/



14

convertirse en uno de los más grandes de puesta en marcha de la industria de las telecomunicaciones históricas de éxito: Qualcomm Incorporated. Desde ahí fue evolucionando pero fue en 2010 cuando dio el paso a la Realidad Aumentada, proporcionando las herramientas API y SDK necesarias para los desarrolladores. En estos últimos años también proporciona un servicio de reconocimiento de imágenes en la nube, Target Manager, dando lugar a nuevas experiencias comerciales móviles que benefician a desarrolladores, consumidores, etc. Análisis General Según su propia descripción, una aplicación basada en el SDK de Vuforia utiliza la pantalla del dispositivo móvil como unas “lentes mágicas”. La aplicación renderiza la imagen previsualizada en la cámara y superponen objetos virtuales 3D. La Fig 10 muestra el proceso.

Para desarrollar, se debe disponer previamente de las imágenes que van a ser reconocidas por su aplicación. Éstas deben ser subidas a la herramienta de reconocimiento Target Manager y, o bien se crea una base de datos de imágenes alojada en la nube y se consulta en tiempo de ejecución, o bien se descarga dicha base de datos y se incluye en la aplicación. Durante la ejecución de la aplicación, ésta interacciona con el motor de Vuforia para reconocer las imágenes almacenadas en la base de datos. Cuando el motor de Vuforia detecta una imagen en la escena, se proyectará el contenido virtual creado por el desarrollador.

Fig 10. Uso de Vuforia. Fuente: Qualcomm.

Fig 11. Diagrama de flujo de datos en una aplicación de ejemplo. Fuente: Qualcomm.

15

La Fig 11 muestra el diagrama de flujo de datos de una aplicación de ejemplo que usa el SDK de Vuforia. La cámara del dispositivo obtiene un frame que se convierte al formato requerido y se pasa al tracker, que puede tener distintas configuraciones. Entre las distintas alternativas se puede optar por reconocer un Image Target (reconocer un solo target o marcador en el frame) o por reconocer un Multi Image Target (reconocer más de un target o marcador en el frame). El tracker obtiene la lista de marcadores que tiene que buscar en la base de datos alojada en la nube, o integrada en la aplicación. Finalmente, el tracker indica dónde debe renderizarse el modelo y el nuevo frame se proyecta en la pantalla. Arquitectura Una aplicación de RA basada en Vuforia consta de una serie de componentes esenciales. A continuación se describen términos referentes a la arquitectura de clases básica de Vuforia:

Camera: garantiza que el cuadro de vista previa es capturado y ha pasado de manera eficiente al tracker.

Image Converter: realiza la conversión entre el formato con el que trabaja la cámara y un formato adecuado para el renderizado.

Tracker: contiene algoritmos de visión computacional para detectar y seguir los objetos en los fotogramas capturados por la cámara. Los resultados se almacenan en un objeto de estado.

Video Background Render: procesa la imagen capturada por la cámara que se encuentra almacenada en el objeto de estado.

Application Code: el desarrollador ha de iniciar todos los componentes anteriores.

User.defined Targets y Cloud Databases: se crean mediante el Target Manager System. El fichero descargado contiene la base de datos. Estos elementos (XML y binario) son compilados por la aplicación a desarrollar en el paquete de instalación. Los usa el SDK de Vuforia en tiempo de ejecución.

Muchos de estos componentes se tratan de singletons; cuya traducción literal sería “hijo único”, y que consiste en una clase diseñada para tener sólo una instancia(o número limitado de ellas).

2.3.- Conclusiones y elección de la aplicación

A partir de lo estudiado y con la revisión por parte de la empresa, se decidió que lo más adecuado a las necesidades de la empresa sería el uso de uno de los dos SDKs de código cerrado gratuito. A partir de esto se han sacado las siguientes conclusiones:

Vuforia Metaio

Licencia Libre Libre con restricciones

Marcadores Sí Sí

Tracking 3D Sí En desarrollo

Formato 3D OpenGL OpenGL, .md2, .obj

Multiplataforma Sí Sí

Documentación Completa Completa

Soporte API API

Comunidad de desarrolladores

Sí Sí

Marca de agua No Sí

Fig 12: Tabla de comparación Vuforia VS Metaio.

16

Como se ve en la Fig 12, ambos SDKs son muy parecidos, pero se ha creído oportuno utilizar Vuforia en el desarrollo del proyecto por aspectos como:

No hay marcas de agua en la versión gratuita, algo que preocupaba bastante a la empresa.

La herramienta de reconocimiento de imágenes es gratuita.

Metaio es un software con más restricciones en la versión gratuita, algo que podría ser un hándicap importante ya que el proyecto puede verse mermado en algún punto.

Otro de los aspectos a elegir es el software de desarrollo. En principio se eligió Eclipse ya que se conocía su lenguaje y se dominaba el entorno. No obstante, después del estudio se vio que Unity es una herramienta muy completa, con mucho potencial y que puede ayudar al desarrollo de la Realidad Aumentada. Además se encuentra mucha más información para el desarrollo en Unity debido a que muchos más usuarios lo utilizan. Uno de los lenguajes de programación soportados por Unity es C# y como se está familiarizado con éste, es el que se escoge para desarrollar la aplicación. Por último cabe destacar que Unity permite desarrollar en otras plataformas como son iOS o Windows, carácter que puede ser útil para posibles ampliaciones.

2.3.1.- Elección de la aplicación Unity, además de ser un software que aporta muchas ventajas a la hora de trabajar con RA, es un potente motor de creación de videojuegos, campo donde más se utiliza la RA en la actualidad. Por ambos motivos se ha decidido crear un juego de Realidad Aumentada para Android.

3.- Revisión y Valoración

Se ha completado este sprint en el tiempo estimado 30 horas y el entregable coincide con el planificado.

17

Sprint 1

1.- Planificación

Este sprint durará dos semanas, desde el 16 de febrero de 2015 hasta el 27 de febrero de 2015 y habrá una reunión con el tutor de la empresa antes del comienzo para dejar claros los objetivos de la aplicación.

Se va a realizar un estudio de la herramienta de seguimiento TFS.

Se van a obtener los requisitos de la aplicación. A partir de la toma de contacto tanto con Unity como con Vuforia obtendremos una orientación acerca de qué requisitos vamos a poder alcanzar.

Se van a describir las posibles ampliaciones.

Se obtendrá una planificación inicial de las tareas iniciales o pila inicial de producto.

Se realizará un diseño del plan de pruebas.

Entregable: Al final de este sprint el cliente obtendrá los requisitos de la aplicación, las posibles ampliaciones y la planificación inicial del producto.

2.- Desarrollo 2.1.- Team Foundation Server (TFS). La herramienta que se va a utilizar para el seguimiento de cada sprint va a ser Visual Studio Online, o como se denotaba anteriormente Team Foundation Server. Se puede ver en el enlace [11] de la bibliografía. El principal motivo por la que se ha elegido, es por ser una herramienta ideal para utilizar metodología SCRUM. Además es de fácil acceso, ya que basta con una cuenta de la universidad. Una vez dentro se ha creado un proyecto llamado “TFG RA”. A continuación se van a describir algunos aspectos clave que pueden ser de ayuda. En el área Work se pueden ver los distintos sprints en los que se divide el proyecto. Si se selecciona alguno de ellos, en la pestaña Backlog, se muestran una serie de ítems de este sprint. Estos ítems son una serie de requisitos u objetivos del sprint.

En cada ítem, se pueden agregar tareas. A cada tarea se le pueden asignar una serie de características, como la persona encargada (si hubiese más integrantes en el proyecto), las horas estimadas, el tipo de actividad (despliegue, diseño, desarrollo, documentación, requisitos, pruebas), el estado, una descripción, etc.

Fig 13. Lista de ítems en TFS.

18

Para verlo de forma más gráfica a modo de tablero kanban, se selecciona la pestaña board y se ve el despliegue de las tareas y el estado en el que se encuentran, como podemos ver en la Fig 14.

Mediante la revisión del informe Burndown, un gráfico a lo largo de la vida del sprint, se permite conocer la velocidad a la que se están completando las tareas en función del tiempo estimado. También al finalizar el proyecto se puede obtener un gráfico Burndown del resultado final. Otra funcionalidad interesante es la colaboración de varios participantes en cada proyecto. Esto es útil para que ambos tutores puedan ver el progreso. Para finalizar, TFS también sirve como programa de control de versiones, conectando el proyecto Visual Studio con TFS. Esta característica es muy interesante aunque no la vamos a utilizar en este proyecto.

2.2.- Toma de contacto con Unity Unity es un motor de videojuegos multiplataforma. Está disponible como plataforma de desarrollo para Windows Microsoft y OS X, y permite crear juegos para Windows, iOS, Linux, Xbox 360, PlayStation 3, PlayStation 3, PlayStation Vita, Wii, Wii U, iPad, iPhone, Android, Windows Phone y gracias al plugin web de Unity también se pueden desarrollar videojuegos de navegador para Windows y Mac. Desde el sitio web oficial, enlace [14] de la bibliografía, se pueden descargar dos versiones; Unity y Unity Pro, esta última de pago. Una de las funcionalidades más importantes y la que hace que sea un editor muy potente, es la facilidad para importar librerías, modelos, texturas, audios, secuencias y otros activos al proyecto y a Unity de forma instantánea. Además cuenta con muchas tecnologías, como por ejemplo Mecanim o MonoDevelop. Mecanim es el sistema de animaciones de Unity que hace posible que los modelos cobren vida con movimientos naturales y fluidos. Está integrada de forma nativa en Unity. MonoDevelop es una herramienta que viene de forma nativa en Unity y que permite programar en los tres lenguajes que acepta Unity, JavaScript, C# y Boo.

Fig 14. Tablero Kanban sprint 1.

19

2.2.1.- Estructura y funcionamiento de juegos Se va a explicar cómo funciona Unity y la estructura que va a seguir el juego. En Unity cada proyecto está compuesto por escenas. Las escenas contienen los objetos del juego y pueden ser usadas para crear un menú principal, niveles del juego, etc. Cada uno de los objetos de una escena es un GameObject diferente, sin embargo los GameObject no hacen nada por sí mismos y necesitan propiedades especiales antes de convertirse en un personaje, un paisaje, una luz, un efecto especial, etc. Para conseguir esto es necesario entender un GameObject como un contenedor que almacena componentes, llamados Components. En función de qué tipo de GameObject se quiere crear se le añadirán distintas combinaciones de Components. Cada Component posee unas propiedades que pueden ser modificadas (por ejemplo el Component “Transform” define la posición, el tamaño y la rotación del GameObject dentro del mundo 3D). El desarrollador puede crear componentes propios que reciben el nombre de Script. Estos

script son clases que heredan del manejador principal (MonoBehaviour) que es el que permite que se ejecuten. Cada script posee inicialmente dos métodos para manejar el GameObject al que está asociado. El método Start()que se utiliza para inicializar las variables y el método Update() al que se llama una vez por cada frame del juego.

2.3.- Toma de contacto con Vuforia De la página de Vuforia, enlace [9] de la bibliografía, se descarga el paquete específico de Unity. Sólo se tendrá que hacer doble clic en dicho paquete, vuforia-unity-android-ios-3-0-9.unitypackage, y se abrirá una ventana en Unity, como la Fig 16, para poder importarlo en el proyecto de trabajo.

En el paquete se puede ver una serie de carpetas donde se encuentra todo el material. En la página oficial de Vuforia se explica detalladamente cada una de las carpetas y su contenido. Aspectos importantes útiles para el proyecto:

Para realizar una aplicación de RA es necesario sustituir la cámara incorporada por defecto por una cámara de Realidad Aumentada. Para ello, Vuforia proporciona un Prefab (la explicación está más delante en el sprint 3, apartado 2.4) con una cámara especial de RA que, tras eliminar la cámara básica, se debe incorporar al proyecto desde Qualcomm Augmented Reality - Prefabs - ARCamera

Para que la RA se genere al ver el marcador, se necesitará un Image Target que se encontrará en la carpeta prefabs – Image Target. Para configurar ese foco, se necesita una base de datos con imágenes. Esto es posible gracias a una herramienta online de Vuforia, Target Manager. En ella se crean bases de datos con imágenes. Dichas imágenes serán analizadas por la herramienta que decidirá si son adecuadas para dicho trabajo, ya que analiza los puntos de las imágenes y los clasifica con un

Fig 15. Carpeta del proyecto dentro de Unity.

Fig 16. Ventana de importación de Vuforia.

20

número de estrellas de mayor a menor grado de aceptación. Posteriormente la base de datos se descarga y se importa en el proyecto indicando en las propiedades del Image Target que se quiere una imagen concreta de una base de datos.

2.4.- Ejemplo Unity + Vuforia Para aplicar todo lo estudiado, se va a realizar un pequeño ejemplo. Se han descargado unos modelos1 con los que trabajar. Estos modelos están en formato .blend por lo que será necesario instalar el software Blender. Una vez se importan al proyecto Unity tanto los modelos como la base de datos de Imágenes Prueba, se monta la escena con estos modelos. Se ha añadido alguna funcionalidad para probar la parte de los script. Uno de los dinosaurios gira en torno al eje central. También se ha probado la herramienta Mecanim para añadir una animación si se pulsa la pantalla del Smartphone, es decir; a través de un script se ve si un usuario ha pulsado la pantalla del Smartphone y si es así, activa una variable booleana que será lo que active la animación.

Después de este ejemplo se ha visto la importancia del software Blender, ya que a través de él se pueden crear animaciones para los modelos mucho más fácilmente que con la herramienta para animaciones de Unity.

2.5.- Alcance mínimo Se va a desarrollar un juego de RA para dispositivos Android. Va a estar compuesto por dos escenas, una pantalla inicial, en la que el usuario podrá comenzar el juego así como encender y apagar el sonido y otra para el juego. Esta pantalla iniciará la cámara del dispositivo móvil y, apuntando a un marcador específico, comenzará el juego. Durante el juego van a ir apareciendo dinosaurios de forma aleatoria. Conforme pasa el tiempo, el número de dinosaurios en la escena irá aumentando y así aumentará también la dificultad. Al pulsar la pantalla del dispositivo en cualquier punto, saldrá desde éste un meteorito que, al impactar con los dinosaurios, sumará un punto en el total del juego. Cuando los dinosaurios no son impactados y su tiempo de vida en el juego ha finalizado el usuario perderá una vida.

1 Swap Blender Assents - http://www.blendswap.com/

Fig 17. Ejemplo de Unity + Vuforia.

21

Además de esto, el usuario contará con una pantalla de información en la que se especificará cómo se juega.

2.6.- Requisitos de la aplicación A partir de lo estudiado anteriormente ya se pueden fijar unos requisitos iniciales para la aplicación. Puede que estos vayan cambiando o aumentando conforme se avance, ya que se pretende crear algo abierto y flexible. 2.6.1.- Requisitos funcionales Enumeración de casos de usos (CU) Actor: Usuario CU1.Apagar sonido

1.- El usuario seleccionará en la pantalla inicial que no desea escuchar sonido. 2.- La aplicación silenciará el sonido. 3.- La aplicación cambiará el icono del sonido al icono de silencio.

CU2.Encender Sonido 1.- El usuario seleccionará en la pantalla inicial que desea escuchar el sonido. 2.- La aplicación activará el sonido. 3.- La aplicación cambiará el icono del sonido.

CU3. Empezar partida 1.- El usuario comenzará una partida nueva. 2.- La aplicación iniciará la pantalla de juego.

CU4. Disparar meteoritos 1.- El usuario disparará un meteorito pulsando la pantalla del dispositivo. Extensiones 1.1.- El meteorito alcanza un dinosaurio. 1.1.1. La aplicación destruye dinosaurio. 1.1.2.-La aplicación aumenta los puntos. 1.2.- El meteorito no alcanza un dinosaurio. 1.2.1.- La aplicación elimina el meteorito.

CU5. Pausar el juego 1.- El usuario podrá seleccionar la opción de pausar la partida actual. 2.- La aplicación pausará el juego.

CU6.- Reanudar el juego. 1.- El usuario podrá reanudar un juego que se encuentra pausado. 2.- La aplicación reanudará el juego.

CU7. Detener el juego 1.- El usuario podrá detener el juego actual. 2.- La aplicación volverá al inicio.

2.6.2.- Requisitos no funcionales La aplicación deberá cumplir al menos los siguientes requisitos:

Requisitos tecnológicos: la aplicación se ejecutará en un Smartphone con sistema operativo Android.

Requisitos de interfaz: la aplicación debe ajustarse correctamente a cada dispositivo donde se vaya a ejecutar. También debe ser intuitiva y fácil de usar.

Requisitos de rendimiento: para no ralentizar demasiado la aplicación, la cámara no tardará más de 15 segundos en aparecer.

La interacción entre el usuario y la aplicación no deberá sobrepasar dos segundos.

22

2.6.3.- Requerimiento de la aplicación A continuación se enumeran los requerimientos de la aplicación:

Versión de Android mínima será 2.3.1 Gingerbread.

No será necesario el uso de internet, por lo que es posible el uso de la aplicación en cualquier momento.

Soporte Open GL Es 2.0.

Procesador ARMv7+x86.

Cámara integrada.

Una imagen a la que enfocar con el dispositivo móvil.

2.7.- Diagrama de navegabilidad

2.8.- Posibles ampliaciones Al usar una metodología SCRUM se han fijado unos requisitos iniciales que, en función del tiempo y del coste, pueden verse ampliados. Algunas de las ampliaciones que se pueden realizar son:

Aplicación Multiplataforma.

Ranking de puntos. Para ver tus progresos en el juego.

Conexión online para añadir un ranking global de jugadores.

Multijugador.

2.9.- Pila inicial de la aplicación A continuación se desglosarán el backlog o pila de tareas iniciales de la aplicación.

Pantalla de carga

Escena Inicial

Escena de Juego

Escena de Información

Inicio de la cámara

Inicio Fin

23

Tarea T. Estimado Sprint Comienzo Fin IT1: Modelos 3D 30 h Sprint 2 02/03/2015 13/02/2015

IT2:Escena Juego 30 h Sprint 3 16/03/2015 27/03/2015

IT3: Meteoritos 15 h

Sprint 4 06/04/2015 17/04/2015 IT4: Vidas y Puntos

20 h

IT5: Parar y Pausar

10 h

Sprint 5 20/04/2015 30/04/2015 IT6: Incrementar la dificultad

15 h

IT7: Pantalla de inicio

20 h

Sprint 6 04/05/2015 15/05/2015 IT8: Game Over 5 h

IT9: Diseño y realización de botones y logo

10 h

IT10: Sonido del juego

10 h

Sprint 7 18/05/2015 29/05/2015 IT11: Información del juego 10 h

IT12: Pruebas 5 h

Total 180 h

2.10.- Diseño del plan de pruebas En cada sprint se van a realizar las pruebas oportunas para poder tener al final de éste un entregable que el cliente pueda ver. Estas pruebas van a estar agrupadas en pruebas de caja negra, de caja blanca por pantalla y de integración. Además al final del proyecto se realizará un testeo general de la aplicación, unas pruebas con probadores y pruebas de aceptación.

Pruebas de caja negra: pruebas donde se van a comprobar funcionalidades del juego como el disparo de los meteoritos, colisiones, puntos, vidas, etc.

Pruebas de caja blanca por pantalla: pruebas de integración donde se van a ir probando todas las pantallas. La forma de probarlas va a ser comprobar que toda la funcionalidad que ofrece la pantalla funciona correctamente y que está bien integrada con el resto de la aplicación.

Pruebas con probadores: se va a ofrecer la aplicación a usuarios para que utilicen ésta como si fueran usuarios finales.

Pruebas de integración: se va probar la aplicación en otros dispositivos móviles distintos al usado durante el desarrollo del proyecto con el fin de ver la correcta escalabilidad de la aplicación.

Pruebas de aceptación: se presenta la aplicación ante la empresa Netbrain Media Solutions S.L., que es la empresa con la que se ha desarrollado el proyecto, para que determinen si cumple con los requisitos fijados al comienzo.

Fig 18. Tabla backlog general del producto.

24

3.- Revisión y valoración Durante este sprint se han completado todas las tareas previstas en esta segunda iteración y, como podemos ver en el gráfico Burndown, se ha acabado un día antes de lo previsto aunque sin mucha variación en las horas estimadas ya que se ha invertido 45 horas.


25

Sprint 2

1.- Planificación

Este sprint durará dos semanas desde el 2 de marzo de 2015 hasta el 13 de marzo de 2015. Mediante el tablero Kanban, se ve la lista de ítems con tareas asignadas y ordenadas en función de las necesidades.

Durante estas dos semanas se va a invertir la totalidad del tiempo en el modelado 3D. Estos modelos serán vistos por el usuario en forma de Realidad Aumenta y aparecerán cuando se enfoque una imagen concreta con la cámara del dispositivo. Entregable: El cliente podrá ver todos los modelos 3D que se van a incluir en la aplicación.

2.- Desarrollo

Una de las principales características de la Realidad Aumentada son los modelos 3D que el usuario va a ver, por eso se creyó oportuno dedicar cierto tiempo a esto. Dado que va a ser un juego, el diseño es algo fundamental. Además es importante adecuar dicho diseño al rango de edades de los usuarios. En la documentación de Unity, se muestra cómo se deben importar modelos 3D con diferentes programas como maya, Cinema 4D, etc. Para este proyecto se ha elegido Blender como programa de modelado. Blender, como se ve en la referencias [12] y [13], parece hecho a medida para crear modelos 3D que luego se usen en juegos o aplicaciones desarrolladas en Unity. Ofrece un enorme abanico de opciones para crear, modelar, renderizar y animar en 3D. La creación de modelos para Unity requiere usar un subconjunto de funciones de Blender y resulta muy fácil acostumbrarse a localizar esas funciones e ignorar el resto, además de poder importar los modelos directamente en formato .blend.

2.1.- Modelos 3D

2.1.1.- Personajes principales Se han seleccionado algunos Modelos 3D de dinosaurios. Sobre ellos se han creado dos o tres animaciones que simulan aspectos como andar, volar, rugir, correr, etc. Se han modificado las texturas para que se adecúen a lo que realmente se quería.


26

Curri Curri es el protagonista principal del juego. Como el modelado requiere un esfuerzo, no se han podido crear todos los personajes desde cero. Sin embargo se quería crear uno propio que fuese el protagonista del juego. Lo primero que se hizo fue un dibujo del alzado y el perfil del dinosaurio.

A continuación se importa dicho dibujo en Blender. Se va creando el cuerpo como se ve en la Fig 27, teniendo en cuenta aspectos como la uniformidad a la hora de proyectar las caras y hacer el modelo hueco.

Fig 21. Dino. Fuente: http://www.blendswap.com/blends/view/45823

Fig 22. Tron. CC: Jeff2207 Fuente: http://www.blendswap.com/blends/view/73512

Fig 23. Tero. CC: Jeff2207 Fuente:

http://www.blendswap.com/blends/view/73510

Fig 24. Rita. CC: Jeff2207 Fuente: http://www.blendswap.com/blends/view/73509

Fig 25. Bronto. CC: Jeff2207 Fuente: http://www.blendswap.com/blends/view/73511 .

Fig 26. Dibujo escaneado de Curri.

http://www.blendswap.com/users/view/Jeff2207







27

Una vez acabado, se crean las texturas, Fig 28 y se insertan huesos en forma de esqueleto, como se ve en la Fig 29, para poder dotar de movimiento al modelo.

Por último, se ha creado una animación que simula el movimiento realizado por el personaje al correr. 2.1.2.- Decorado Además de los dinosaurios, se han colocado algunos aspectos de decorados como árboles o hierba. Debido a la dimensión del proyecto, no se ha podido invertir más tiempo al modelado, por lo que algunas de las partes del decorado no se han creado ni modificado.

Fig 27. Imagen de la realización del modelo en Blender.

Fig 28. Imagen del modelo 3D con texturas.

Fig 29. Imagen del modelo 3D con huesos.

Fig 30. Imagen del modelo Decorado 1. Fuente: Paquete “Tree Creator” de Unity.

Fig 31. Imagen del modelo Decorado 2. Fuente: Paquete “Tree Textures” de Unity

Fig 32. Imagen del modelo Decorado 3. Licencia CC-BY-SA- Autor: APanimation.

Fig 33. Imagen del modelo Decorado 4. Licencia CC-BY-SA- Autor: OliverMH.

28

3.- Revisión y valoración

Se han completado todas las tareas previstas pero como podemos ver en el gráfico Burndown, se ha tardado más horas de las estimadas en la creación del modelo 3D propio. Al ver que el tiempo estimado no era el suficiente se han invertido más horas durante el sprint para no alargarlo más en el tiempo. El total de horas invertidas para este sprint ha sido de 42 h.

Aunque se cuente el proceso de forma superficial, ha tenido mucha dificultad ya que no se había trabajado nunca con tareas de modelado 3D. Varios pasos del proceso han tenido que ser repetidos en ocasiones al obtener resultados de baja calidad.


29

Sprint 3

1.- Planificación

Este sprint durará dos semanas desde el 16 de marzo de 2015 hasta el 27 de marzo de 2015. Mediante el tablero Kanban, se ve la lista de ítems con tareas asignadas y ordenadas en función de las necesidades.

En este sprint, se va a preparar el proyecto del juego en Unity. Esto implica la importación de varios aspectos como la SDK de Vuforia, los modelos 3D creados anteriormente y la base de datos que contiene las imágenes que van a servir de foco. Además se va a dar forma a la escena principal del juego, tan importante en este tipo de desarrollos. Por último se van a ajustar los modelos 3D a la escena y su tiempo de vida dentro de ella. Entregable: al final de este sprint el cliente podrá ver el decorado de la escena principal del juego y cómo se generan los dinosaurios 3D aleatoriamente.

2.- Desarrollo

Se importa la librería de Vuforía y se prepara el proyecto para comenzar, la forma de hacerlo se ha obtenido de la referencia [10].

2.1.- Imagen Target Para la base de datos se ha utilizado la herramienta web de Vuforia, Target Manager, que permite gestionar bases de datos en línea. Esta herramienta tiene un reconocimiento de imágenes además de varios formatos para descargar la base de datos. En este caso se descarga en .unitypackage para la importación directa en Unity.

2.2.- Importar modelos 3D En la importación de los modelos 3D se han tenido algunos problemas con las texturas, ya que no permanecían en el modelo después de la importación. Por lo que se han tenido que importar aparte y asociar al modelo específico. También se han tenido problemas con las animaciones, ya que al ejecutarlas en Unity cambiaban con respecto a Blender.


30

La migración de un programa a otro ha sido algo compleja y se han tenido que modificar algunas de las partes de los dinosaurios en blender para que el funcionamiento sea el mismo que en Unity.

2.3.- Escena principal Se ha dado forma a la parte de Realidad Aumentada de la escena principal. Para ello se hizo un primer diseño que va a servir de base para montar el escenario.

2.4.- Generar dinosaurios por la escena Para generar dinosaurios aleatorios por la escena se necesita crear un GameObject para cada uno de ellos en tiempo de ejecución. Obviamente cada uno de estos GameObject va a tener unos Components similares por lo tanto, para no repetir todo el proceso para cada tipo de dinosaurio, Unity proporciona el tipo Prefab, que actúa a modo de plantilla. Mediante Prefabs se puede almacenar un GameObject con sus Components. Una de las ventajas de utilizar Prefabs es que se pueden realizar cambios sobre una instancia y que no afecten al resto. No obstante, también puedes modificar el Prefab directamente para reflejar dicho cambio sobre todas las instancias en la escena. Se ha considerado oportuno crear cuatro GameObjects vacíos por la escena, con la posibilidad de crear o eliminar alguno dependiendo de las necesidades del proyecto. A estos se les ha añadido un script que instancia un vector de GameObject. En ese vector se introducirán los Prefabs (Dinosaurios) que queremos que aparezcan en este generador y sobre ese vector se van generando elementos aleatorios en función de un tiempo máximo y un tiempo mínimo. Cada Prefab contendrá además unos script propios, que darán la funcionalidad cuando el generador instancie dichos Prefab.

A diferencia del resto de generadores, en el generador 3 GeneradorDinos3, no se instancia un vector de GameObject si no que solamente instanciaremos un prefab para poder asignarle en tiempo de ejecución propiedades propias ya que es un dinosaurio volador y se le quiere asignar un objeto sobre el que dar vueltas, es decir un objeto del escenario, en este caso un árbol para que pueda girar sobre él. Exportar a Android para compilar Para poder ver las modificaciones en un dispositivo Android, se configurarán las opciones de compilación en Build Settings. Ahí se especificará qué se quiere ejecutar en un dispositivo Android y se editarán las opciones pulsando Playing Settings. Se podrá cambiar el nombre, el logo, las versiones máxima y mínima de Android entre otras cosas.

Fig 36. Foto del diseño de la escena principal.

Fig 37. Imagen de la escena principal en Unity.

31

Juego en funcionamiento Después de hacer las pruebas adecuadas para este sprint, se ha visto un error grave en el desarrollo del juego. Cuando no se apunta al marcador con el dispositivo móvil, el juego sigue funcionando por detrás y esto da lugar a la pérdida de vidas. En caso de pérdida del marcador el juego debería detenerse por completo saliendo un mensaje en el que se indica que para continuar será necesario apuntar al marcador. Para poder realizar esto, se ha creado un GameObject vacío al que se ha llamado ControladorDelJuego. Este GameObject contendrá los scripts necesarios para controlar el funcionamiento del juego. El primer script va a ser el encargado de parar el juego si el dispositivo móvil no apunta al marcador y reanudarlo cuando sí. Para ello se parará el tiempo en el caso de pausa y volverá a iniciar en caso contrario, pausando con él todos los objetos que dependan del tiempo. Cuando se ha realizado esto, se han mejorado los scripts propios de cada prefab para que los movimientos dependan del tiempo.

Se mueve un modelo en el eje x con una velocidad determinada y en función del tiempo. Es decir se quiere mover el objeto 10 metros por segundo en lugar de 10 metros por cada frame.


Se han completado todas las tareas previstas como podemos ver en el gráfico Burndown. Además se ha realizado una tarea más, la explicada en el apartado Juego en Funcionamiento que, aunque no estaba planificada, se ha realizado dentro del tiempo estimado para este sprint, 30 horas.

Al final de este sprint se han realizado pruebas de caja negra para comprobar la funcionalidad

de los generadores de dinosaurios y cómo se para y se reanuda el juego al encontrar o perder

el marcador.

transform.Translate(transform.position.x*speed*Time.deltaTime,transf

orm.position.y, transform.position.z);

Time.timeScale = 0f; Stop time Time.timeScale = 1f; Restart time


32

Sprint 4

1.- Planificación

Este sprint durará dos semanas desde el 6 de abril de 2015 hasta el 17 de abril de 2015. Mediante el tablero Kanban, se pueden ver la lista de ítems con tareas asignadas y ordenadas en función de las necesidades.

En estas dos semanas se va a desarrollar todo lo relacionado con el lanzamiento de los meteoritos. Se incluirán el propio lanzamiento, el impacto que produce en los dinosaurios, el marcador que irá aumentando cuando un dinosaurio es alcanzado y las vidas del usuario que se perderán cuando un dinosaurio desaparezca del juego sin ser impactado. Entregable: Al final de este sprint el cliente podrá:

Lanzar meteoritos

Alcanzar dinosaurios

Ganar puntos

Perder vidas

2.- Desarrollo

2.1.- Lanzar meteoritos Para esta tarea se han estudiado de la página de Unity los disparos y las colisiones, enlaces [20] y [21] de la bibliografía respectivamente. El meteorito se va a crear con un sistema de partículas del paquete particles de Unity que lo simulará. Para su mejor manejo, en tiempo de ejecución mediante programación se va a crear un objeto vacío en el que se encapsulará dicho sistema de partículas parar almacenarlo en el proyecto como un prefab llamado Meteorito.


33

Para lanzar los meteoritos se va a crear un script Lanzar que se añadirá a la cámara. Suponiendo un punto imaginario situado cerca de los ojos del jugador, una vez se pulse la pantalla del dispositivo, un meteorito saldrá en línea recta desde dicho punto hacia el punto de la pantalla pulsado hasta colisionar o bien con el Suelo o bien con un dinosaurio.

Como se puede ver en el cuadro de la Fig 40, el meteorito saldrá del punto seleccionado pasando por unas coordenadas que el usuario seleccionará pulsando la pantalla del dispositivo.

Al prefab Meteorito se le va a añadir un script que, por un lado le añada fuerza, enlace

[22] de la bibliografía, y por otro a través de la función OnTriggerEnter maneje las colisiones.

if ( (Input.GetButtonDown ("Fire1")) && (Time.time >

siguienteDisparo){

siguienteDisparo=Time.time + tiempoEntreDisparos;

Ray ray=Camera.main.ScreenPointToRay(Input.mousePosition);

Transform

metGO=Instantiate(meteorito,ray.origin,transform.rotation) as

Transform;

metGO.gameObject.GetComponent<Meteorito>().Lanzar(ray.direction

);

}

if ((Input.touchCount > 0) && (Time.time > siguienteDisparo)) {

Ray

ray=Camera.main.ScreenPointToRay(Input.touches[0].position);

GameObject

metGO=Instantiate(meteorito,ray.origin,transform.rotation) as

GameObject;

metGO.GetComponent<Meteorito>().Lanzar(ray.direction);

}

public void Lanzar(Vector3 vector){

//Access the rigibody. A force is applied forward.

rigidbody.AddForce (vector * 70000);

}

Fig 40. Representación del lanzamiento del meteorito. imaginario.

34

El meteorito va a poder colisionar por un lado con los dinosaurios y por otro, para que dichos

meteoritos no perduren en el juego, se va crear un 3D Object – Cube, por debajo del marcador o Suelo, al que se llamará, Subsuelo, para que cuando un meteorito no impacte con un dinosaurio, impacte con él y éste se destruya. Se modifican las siguientes características de Subsuelo:

Sin las propiedades Cube y el Mesh Renderer, para que sea transparente, como se ve en la Fig 42.

Con un Collider en el objeto padre del Meteorito y con la propiedad Is Trigger del Collider marcada.

Para la colisión con los dinosaurios, se añade a cada uno de ellos un Colliders, como se ve en la Fig 43 añadido a Tron.

El motor de física, cuando detecta una colisión, llama al método OnTriggerEnter de todos los script que tenga ese objeto y dentro de este método se comprobará con qué ha colisionado. Si colisiona con un GameObject llamado Subsuelo el meteorito se destruirá. Para gestionar las colisiones con los dinosaurios, como cada uno tiene un nombre, se ha considerado oportuno asignarle un tag (estrategia utilizada en Unity para unificar un conjunto

de GameObjects).

if (other.name == "Subsuelo") {

EliminarMeteorito();

} else if (other.tag == "TagDinosaurio") {

EliminarMeteorito();

other.SendMessage("Muere",

SendMessageOptions.DontRequireReceiver);

}

}

void EliminarMeteorito(){

Destroy (gameObject, 1);

}

Fig 41. Imagen del cubo, Subsuelo, para el impacto de los meteoritos.

Fig 42. Imagen del cubo, Subsuelo,

añadiendo la configuración específica.

Fig 43. Tron con el Collider.

35

Este mensaje se manda a través del método SendMessage a todos los GameObject que

cumplan con la condición other.tag == "TagDinosaurio", y que tengan el método llamado Muere. El segundo parámetro del SendMessage, ignorará cualquier script que no posea dicho método. El método Muere estará en otro script Impacto que eliminará el GameObject sobre el que está colisionando. Para dar más sensación de impacto se va a crear un prefab Explosión con un sistema de partículas que recrea una explosión. Se le añade además un script tiempoVidaExplosion para que una vez que sucede no se siga ejecutando y se elimine. Se añade por tanto dicha explosión al método Muere del script Impacto, que ahora instanciará dicha explosión y eliminará el GameObject con el que ha colisionado.

2.2.- Implementación vidas y puntación 2.2.1.- Vidas Un usuario pierde vidas si un dinosaurio ha desaparecido del juego sin ser interceptado. Para ello se ha creado un script que tendrá cada prefab que sea un dinosaurio y que se va a encargar de controlar si el tiempo que tiene que estar ese dinosaurio en el juego ha pasado.

Cuando el tiempo haya pasado se llamará a una función que eliminará el dinosaurio y hará que el usuario pierda una vida. Para gestionar las vidas se ha creado un script EstadoJuego en el objeto vacío

ControladorDelJuego con una función que restará una vida de las vidas actuales. Dentro de los GameObject se puede acceder desde un componente a otro componente de la siguiente manera:

No se hace de la misma forma cuando se quiere acceder a un componente de otro GameObject como ahora que se requiere acceder al script EstadoJuego para que elimine las vidas. En el sprint 3 ya se ha llamado a un componente de otro GameObject del siguiente modo:

}

public void PerderUnaVida() {

//Remove when greater than 0 lives to avoid negative numbers. if (vidasActuales > 0) {

vidasActuales--;

}

}

private eliminarDinoo tiempoEliminar;

void Start () {

tiempoEliminar = GetComponent<eliminarDinoo> ();

}

//Referencia to GameObject controlador del juego

GameObject controlador = GameObject.Find ("ControladorDelJuego");

if (controlador != null) {

eventosMarcador=controlador.GetComponent<EventosMarcador

>();

} else {

Debug.LogError("No se ha encontrado el GameObject con el

objeto ControladorDelJuego");

}

36

Ahora para hacer esto más genérico y no tener que poner este código modificado cada vez que

se quiera acceder a otro GameObject se va a preparar un script ControladorJuego. Este script nos permite acceder a otro GameObject que exista en el proyecto. Va a estar compuesto de una función estática para poder acceder desde ella a cualquier script y genérica para cualquier componente y cualquier GameObject. El script queda así:

Ahora se añade a todos los dinosaurios un script DinosaurioSeEscapa y se modifica el script que poseían los dinosaurios a través del cual se eliminaban si había pasado un tiempo. Ahora cuando pase un tiempo se almacenará dicho tiempo en una variable y será el script DinosaurioSeEscapa quien se encargará de eliminar al dinosaurio y de hacer perder una vida. Será por lo tanto aquí donde se necesita dicha referencia descrita anteriormente.

Referencia al script EstadoJuego

Script DinosaurioSeEscapa

using UnityEngine;

using System.Collections;

public class ControladorJuego : MonoBehaviour {

// Use this for initialization

void Start () {

}

// Update is called once per frame

void Update () {

}

// generic used for any class of any GameObject.

public static T ObtenerComponente<T>(string nombreDelGameObject)

where T : UnityEngine.Component{

//Referencia to GameObject controlador del juego

GameObject controlador = GameObject.Find

(nombreDelGameObject);

if (controlador != null) {

return controlador.GetComponent<T>();

} else {

Debug.LogError("No se ha encontrado el GameObject con el

objeto"+nombreDelGameObject);

return null;

}

}

}

private EstadoJuego estadoJuego;

void Start () {

estadoJuego =

ControladorJuego.ObtenerComponente<EstadoJuego>

("ControladorDelJuego");

}

void Update () { {if(tiempoEliminar.tiempoStart >= 4){

DinosaurioSeAcabaDeEscapar();

}

}

private void DinosaurioSeAcabaDeEscapar(){

//destroy dinosaur

Destroy (gameObject);

//remove a life

estadoJuego.PerderUnaVida ();

}

37

2.2.2.- Puntuación

Para la puntuación en el script EstadoJuego se crean una variable y dos funciones, una que incremente puntos y otra que vaya actualizando la puntuación. Se ganan puntos cuando muere un dinosaurio por lo que se puede saber en el script Impacto que se incorporó en todos los dinosaurios. Será ahí donde vamos a incrementar la puntuación del jugador.

2.3.- Diseño de vidas y puntos

Se ha usado Photoshop y una tableta bamboo fun – Wacom para el diseño de las vidas y el marcador. Para las vidas se ha partido del dinosaurio que se dibujó para crear el modelo 3D en Blender. Se ha dibujado su cara y se han creado 4 imágenes, una vacía y las otras con el mismo número de caras que vidas hasta 3 vidas que son con las que va a comenzar el juego.

Para el marcador se ha dibujado un meteorito y sobre él se ven los puntos.

2.4.- Mostrar vidas y puntos en la pantalla

Se va a insertar un UI RawImage que nos va a permitir poner una imagen en la pantalla. En el script EstadoJuego, donde se perdía una vida, ahora se irá cambiando la textura al objeto que se ha creado antes y hemos llamado Vidas. Para ello:

En EstadoJuego se añade una referencia al objeto Vidas y un vector de texturas para introducir las imágenes.

Se añade en el Inspector al objeto vidas las cuatro texturas que van a ir cambiando.

Después de asignar las vidasActuales a las vidasIniciales se va a incorporar en la imagen de vidas el vector en la posición que tenga vidasActuales.

vidasActuales = vidasIniciales;

vidas.texture =

vidasImagenes[vidasActuales];

Fig 44. Imagen para simular una vida.

Fig 45. Imagen para simular dos vidas.

Fig 46. Imagen para simular tres vidas.

Fig 47. Imagen para el marcador de vidas.

38

Lo mismo para cuando se decrementan las vida además de comprobar si las

vidasActuales son mayores que el tamaño del vector.

Para la parte de la puntuación se añade un objeto UI Text que se llamará Puntuacion.

En EstadoJuego hacemos una referencia al objeto Puntuacion y en el método Actualizar cogerá la referencia a ese objeto y cambiará la propiedad text poniendo la puntuación de este modo: Con D4 indicamos el formato con el que queremos que aparezca el número. Con la D decimos que es un formato de enteros y el 4 para 4 dígitos.


Se han completado todas las tareas previstas en el tiempo estimado 35 horas, como podemos ver en el gráfico Burndown.

Al final de este sprint se han realizado una serie de pruebas:

Pruebas de caja negra para ver las funcionalidades implementadas como lanzar meteoritos, colisiones, ganar puntos o perder vidas.

Pruebas de integración para comprobar que los UIs se adaptan correctamente a distintos dispositivos.

if (vidasActuales < vidasImagenes.Length) {

vidas.texture = vidasImagenes [vidasActuales];

}

tPuntuacion.text = puntuacion.ToString("D4");


39

Sprint 5

1.- Planificación

Este sprint durará dos semanas desde el 20 de abril de 2015 hasta el 30 de abril de 2015. A continuación se ve la lista de tareas en el tablero Kanban.

Este sprint va tener dos ítems principales; uno en el que se crearán dos botones que se situarán en la escena de juego y que facilitarán al usuario las funciones de pausar y parar el juego y el otro hace referencia a la dificultad del juego, por la cual, cuanto más tiempo pasa, más dinosaurios saldrán en la escena y más complicado será alcanzarlos. Entregable: El cliente al final de este sprint podrá ver los botones de stop, pause y play del juego y cómo se aumenta la dificultad conforme avanza la partida.

2.- Desarrollo

2.1.- Diseño de botones Al igual que en el sprint 4 se ha utilizado Photoshop y una tableta bamboo fun – Wacom para el diseño de los botones de pausa, stop y play.

2.2.- Insertar botones Se insertan las texturas que se han creado para los botones en Unity y se crean los GameObject de Pausar y Stop desde el inspector de tipo UI Button. Para asignarle a cada botón su textura será necesario que dichas texturas sean de tipo Sprite, por lo que se cambiará dicha propiedad. Esta propiedad hace que las texturas no sean necesariamente rectangulares y puedan asumir en sus bordes apariencia transparente.

Fig 49.Tablero Kanban sprint 5.

Fig 50. Imagen botón play. Fig 51. Imagen botón pause. Fig 52. Imagen botón stop.

40

2.3.- Implementación de las funcionalidades de los botones Con los botones situados en la parte inferior derecha de la pantalla se crea un script Pause que se asignará al GameObject, ControladorDelJuego. Dicho script va a estar compuesto de dos métodos, uno para pausar el juego y otro para parar. El método Pausar comprobará si el botón está pulsado utilizando una variable booleana. Cuando el botón esté pulsado la textura del botón cambiará y el juego quedará pausado. El método PararJuego,

finalizará la partida y hará que el usuario vuelva a la pantalla de inicio. Para finalizar, habrá que indicarle a cada botón qué es lo que tiene que hacer cuando se pulse, por lo que en el método On Click()de cada botón, se especificará el método correspondiente del script Pausar del GameObject, ControladorDelJuego.

2.4.- Incrementar la dificultad del juego Como ya se explica en el sprint 3, para crear objetos en tiempo de ejecución será necesario que estos sean prefab, así que los 4 generadores de dinosaurios se van a pasar a prefab.

En el GameObject ControladorDelJuego se ha creado un script

IncrementarDificultad que es el encargado de, pasado un tiempo, instanciar un nuevo

generador en la escena. Para ello, se ha creado un array de GameObject con los generadores, un tiempo entre generadores y un tiempo para esperar al primer generador ya que el juego comenzará con uno de estos. Por último, al realizar esto se detectó un fallo y es que los elementos se creaban fuera de

Suelo o marcador. Para solucionar esto, al instanciarse el GameObject aleatorio, se va a indicar que debe hacerse dentro de otro GameObject, que es el Suelo o marcador.

public void Pausar(){

if (puedesPausar) {

puedesPausar = false;

boton_pausar.image.sprite=play;

Time.timeScale = 0f;

} else {

puedesPausar = true;

boton_pausar.image.sprite=pause;


}

}

public void PararJuego(){

Application.LoadLevel("pantallaInicio");

}

Fig 53. Imagen asignación del tipo de textura.

41

Esto es importante a la hora de apuntar al marcador o no, ya que si dichos elementos no se

crean dentro del marcador, al no apuntar a éste, algunos dinosaurios quedarán en la escena.


Se han completado todas las tareas previstas en un tiempo menor a las estimadas 25 horas. Como la duración estimada de la tarea Game Over del sprint siguiente es similar a las horas que quedan para finalizar este sprint, se ha decidido adelantar su realización.

3.1.- Game Over Esta tarea se ha realizado siguiendo la estructura de Game over de la página de Unity, que podemos ver en el enlace [23] de la bibliografía. No obstante se han realizado modificaciones adecuándose a las necesidades de este proyecto. En el script EstadoJuego, en la función PerderUnaVida, se va a comprobar si las vidas han llegado a 0 y en el momento que lleguen, se va a mandar un mensaje con la siguiente instrucción:

Ahora se crea un script GameOver, con la función PartidaTerminada en el GameObject ControladorDelJuego que se encargue de poner el TimeScale a 0.

Al llegar las vidas a 0 finalizará el juego, pero si se pierde de vista el marcador y se vuelve a encontrar, el juego se pone en funcionamiento y no se quiere que después de mostrar el Game Over pase nada, ya que la partida estará finalizada. Para solucionar esto, a través de una variable booleana se va a crear un mecanismo para que las funciones MarcadorEncontrado y MarcadorPerdido, del script EventosMarcador, no hagan nada si el juego se encuentra en Game Over. Se añade al script EstadoJuego una variable booleana, llamada GameOver y se define

como internal, ya que no se quiere que se vea en el inspector pero sí se quiere acceder a ella desde otro script.

En la función PartidaTerminada del script GameOver, se ha puesto el valor de esta variable a true y en el script EventosMarcador, en las funciones MarcadorPerdido y MarcadorEncontrado, se añade una condición por la cual, cuando dicha variable sea true, no se ejecutará la función.

if (vidasActuales <= 0) {

//a message is sent to the other components.

GameOverSendMessage("PartidaTerminada",SendMessageOptions.D

ontRequireReceiver);

}

if (Time.time >= horaDelSiguienteDinosaurio){

horaDelSiguienteDinosaurio=Time.time + tiempoEntreGeneradores;

GameObject generador= Instantiate (Generadores[Random.Range (0,

Generadores.Length)]) as GameObject;

generador.transform.parent=padreDeLosDinosaurios.transform;

}

if (estadoJuego.gameOver) return;

42

Por último, el usuario tiene que saber que la partida ha finalizado, por lo que siguiendo la referencia [24] de la bibliografía, se ha creado una animación a través de la herramienta para animaciones de Unity. Primero se ha creado un UI Image, que ocupa toda la pantalla y se le asigna un color. Se crean también dos UI Tex, una para el texto de Game Over y otra para la puntuación. Se abre ahora la herramienta de animaciones, Window – Animation. En la ventana que aparece, se añaden los elementos que se quieren animar, en este caso el color y la escala de los tres elementos mencionados en el párrafo anterior. Se pulsa el botón rojo que simula la grabación, para modificar sus valores. Lo que se quiere en esta animación es que salte una imagen, que empezará opaca y se irá aclarando. Y que los UI Tex, simulen un salto empezando en 0, aumentando su tamaño hasta 1.8 y acabando en 1.4. Se guarda la animación con el nombre de GameOverClip y se añade al Canvas, ya que todos los elementos gráficos están contenidos en él. Para añadirlo se necesita un elemento Animator, al que asignarle dicha animación. En el elemento Animator se crea por defecto la animación asignada y se va a crear otra que no haga nada en el tiempo en reposo. La animación se activará a través de una variable booleana mediante la cual, al ser true, se pasará del tiempo en reposo a la animación. Ahora sólo queda programar la parte en la que la animación se activa. Esto sería sencillo, ya que se tiene una función PartidaTerminada en el script GameOver dentro del

GameObject ControladorDelJuego. Sin embargo, los elementos que componen la animación están dentro de otro GameObject, por lo que si se activa la animación en el GameObject ControladorDelJuego, dicha animación en tiempo de ejecución no sabrá cuáles son los elementos.

Fig 53: Creación de la animación desde Unity

Fig 55. Creación de las animaciones en el Animator.

Fig 54. Creación de la animación mediante Mecanim.

43

Para solucionarlo se ha tenido que modificar la función PartidaTerminada y ahora se

pondrá la variable gameOver a true y otra variable que se ha creado nueva, activar, a true, y será esta la que active la animación en otro script ActivarAnimación asignado al Canvas. Es este script el que realizará las demás funciones específicas del Game Over, como mostrar la puntuación, parar el juego y llevar al usuario a la pantalla de inicio si pulsa la pantalla del dispositivo. Para que el usuario sepa si la puntuación que ha obtenido ha superado el récord, además de mostrar dicha puntuación, comprobará el record añadiendo una variable en EstadoJuego de la siguiente manera. Para ir guardando la puntuación será en el script ActivarAnimación donde se comprueba

el record y en caso de superarlo, se guarda y se muestra en el script ActivarAnimacion:

//With this function we save a chain of ints for next game

highscore = PlayerPrefs.GetInt ("highscore", 0);// the value is 0 the first time

Fig 56. Comprobación del Game Over en el dispositivo móvil.

44

Con este sprint acabado se puede ver el gráfico Burndown del desarrollo del sprint. Las horas totales invertidas han sido 30.

Al realizar una tarea más, el entregable del cliente cambia. En el nuevo entregable el cliente podrá ver los botones de stop, pause y play, cómo aumenta la dificultad coforme avanza la partida y el game over o partida terminada.

void Start () {

gameover = ControladorJuego.ObtenerComponente<GameOver>


estadoJuego = ControladorJuego.ObtenerComponente<EstadoJuego>


comprobar = true;

}

void Awake(){

anim =GetComponent<Animator>();

}


void Update () {

if (gameover.activar) {

//increase a timer

restartTimer += Time.deltaTime;

anim.SetTrigger ("GameOver");

//if you have exceeded the maximum of punctuation

if ((estadoJuego.puntuacion > estadoJuego.highscore) && comprobar)

{

estadoJuego.highscore = estadoJuego.puntuacion;

//save

PlayerPrefs.SetInt ("highscore", estadoJuego.puntuacion);

gameOverPuntuacion.text = "Record "+estadoJuego.puntuacion.ToString

("D4"); comprobar=false;

} else if(comprobar){

gameOverPuntuacion.text = "No record

"+estadoJuego.puntuacion.ToString ("D4");

} if(restartTimer >= tiempoEspera) {


//change of scene by touching the screen

if((estadoJuego.gameOver) && (Input.GetButtonDown ("Fire1") ||

Input.touchCount > 0)) {

Application.LoadLevel("pantallaInicio");

gameover.activar = false;}

}

}

}


45

Para acabar se han realizado una serie de pruebas:

Pruebas de caja negra para comprobar la funcionalidad de la dificultad del juego y el Game Over.

Pruebas de caja blanca para la funcionalidad de los botones.

Pruebas de integración para ver que los botones se adaptan correctamente a los diferentes tamaños.

46

Sprint 6

1.- Planificación

Este Sprint durará dos semanas desde el 4 de mayo de 2015 hasta el 15 de mayo de 2015. Mediante el tablero Kanban se puede ver la lista de ítems con tareas asignadas y ordenadas en función de las necesidades.

En estas dos semanas se van a realizar tres ítems; en el primero se diseñarán y crearán las texturas para los botones de sonido y el logo de la aplicación. En el segundo se diseñará, creará la textura e implementará la pantalla de inicio. Para finalizar, en el tercero se va a implementar el sonido de fondo del juego. Entregable: Al final de este sprint el cliente podrá comprobar el sonido del juego, la funcionalidad del botón del sonido y la pantalla de inicio.

2.- Desarrollo

2.1.- Diseño de botones y logo Para la creación, al igual que en otros sprint se ha usado Photoshop y una tableta bamboo fun – Wacom Se han creado dos texturas para los botones del sonido, una para sonido activado y otra para sonido desactivado, siguiendo el modelo de diseño del resto de botones.


Fig 59. Imagen botón sonido encendido. Fig 60. Imagen botón sonido apagado.

47

Para el logo se ha dibujado un boceto y se ha creado la textura.

2.2.- Diseño de la pantalla de Inicio Sobre el boceto inicial de la pantalla de inicio se ha dibujado primero el fondo para más tarde crear la textura.

2.3.- Implementación de la pantalla de Inicio Lo primero que se implementa es el botón de sonido. Para ello se añade al Canvas un UI

Button al que se llama Sonido. Se le añaden a éste las dos texturas creadas anteriormente cambiando el tipo de textura a Sprite. Al pulsar este botón cambiará su textura y activará o desactivará el sonido, pero de momento se va a proceder a modificar dicha textura.

Para ello se ha creado un script BotonSonido con una función llamada ActivarDesactivarSonido que cambiará la textura, al igual que se hacía en el sprint 5 con el pause.

public void ActivarDesactivarSonido(){

if (pausarSonido) {

pausarSonido = false;

boton_sonido.image.sprite = sinSonido;

} else {

pausarSonido = true;

boton_sonido.image.sprite = sonido;

}

}

Fig 62. Imagen del diseño de la pantalla de inicio. Fig 63. Textura de la pantalla de inicio.

Fig 64. Pantalla de inicio del juego.

Fig 61. Imagen del logo del juego.

48

Se ha creado otro UI Button para comenzar el juego con la textura de play. A éste se le

añade un script BotonPlayPantallaInicio con la función BotonPlay() que al pulsar cambiará la escena. A ambos botones se les asocia en su función On Click(), qué función es la que tiene que realizar al pulsar. 2.4.- Sonido del juego Se ha buscado información de cómo reproducir sonido en una escena y cómo mantener el sonido entre las diferentes escenas del juego. Reproducir sonido es sencillo, se ve el funcionamiento en el enlace [25] de la bibliografía. Se tendrá que añadir un elemento Audio Source al objeto al que se quiere añadir sonido y, a través de funciones como por ejemplo audio.Stop()y audio.Play(),se controlará dicho sonido. Pasar el sonido a través de las escenas es algo más complejo. Al estudiar el funcionamiento se vio que hay dos formas de hacerlo:

Pasar un objeto con sonido de una escena a otra a través del método DontDestroyOnLoad(gameObject), ya que el método que se usa para pasar de escena (LoadLevel()) elimina todos los elementos de la escena primera y carga los de la nueva escena. Esta opción es una solución rápida al problema pero tiene un inconveniente fundamental, y es que al volver a la escena inicial se generaban dos instancias de ese objeto.

Hacer un patrón Singleton, cuyo propósito es que exista una instancia de una clase además de proporcionar un acceso fácil a dicha clase.

Estudiadas ambas se opta por la última, como se ve en el enlace [26] de la bibliografía, se crea un objeto vacío al que se ha llamado Sonido y se le ha añadido un script, ManagerAudio, con un patrón Singleton.

public class ManagerAudio : MonoBehaviour {

private static ManagerAudio instance = null;

public static ManagerAudio Instance {

get { return instance; }

}

void Awake() {

if (Instance) {

DestroyImmediate (gameObject);

}else {

DontDestroyOnLoad (gameObject);

instance = this;

}

}

public void Play() {

audio.Play();

}

public void Stop() {

audio.Stop();

}

public void Pause() {

audio.Pause();

}

}

49

Este script consta de una clase con un constructor privado que expone una instancia de sí misma para acceder a ella. En este caso, no se permite construir nuevas instancias de ella, ni heredar de ella. Se accede desde otro GameObject a este objeto del siguiente modo:

Por último, se crea un botón de sonido botonSonido en ambas pantallas que, además de reproducir el sonido, cambia la textura de botón. Se crea un nuevo método en el script del singleton.

Como explica la API de Unity, enlace [14] de la bibliografía, el método IsPLaying() devuelve true si el audio se está reproduciendo y false en caso contrario, por lo que en el script BotonSonido, se comprobará al instanciarse si el sonido está o no reproduciéndose para asociar la textura al botón.

Los dos botones de ambas pantallas serán iguales, contendrán el script BotonSonido.

ManagerAudio.Instance.Play();

ManagerAudio.Instance.Stop();

ManagerAudio.Instance.Pause();

public bool IsPlaying(){

return audio.isPlaying;

}

public class BotonSonido : MonoBehaviour {

public Button boton_sonido;

public Sprite sonido;

public Sprite sinSonido;

static bool pausarSonido;


void Start () {


if (ManagerAudio.Instance.IsPlaying ()) {


} else {


}

}


void Update () {

}


if (pausarSonido) {

pausarSonido = false;


// sound Pause


} else {



//sound restart


}

}

}

50

2.4.1.- Audio El juego tiene un sonido de fondo2 que está bajo la licencia CC BY 3.


Se han completado todas las tareas en el tiempo estimado como se puede ver en el gráfico Burndown.

Al finalizar se han realizado las siguientes pruebas:

Prueba de caja negra para comprobar la funcionalidad del sonido.

Pruebas de caja blanca para comprobar la funcionalidad del botón de sonido tanto de la pantalla de inicio como de la pantalla principal del juego.

Pruebas de integración para comprobar que los botones se adaptan correctamente a distintos tamaños

2 Descargado de la página http://www.freesound.org/, en el enlace http://www.freesound.org/people/vikuserro/sounds/265549/

3 Creative Commos BY - http://creativecommons.org/licenses/by/3.0/.


51

Sprint 7

1.- Planificación

Este Sprint durará dos semanas, desde el 18 de mayo de 2015 hasta el 29 de mayo de 2015. Mediante el tablero Kanban, podemos ver la lista de ítems con tareas asignadas y ordenadas en función de las necesidades.

En estas dos semanas se van a desarrollar tres ítems. En el primero se realizará la pantalla de información del juego, primero se diseñará, tanto la pantalla como los botones específicos y luego se implementará. En el segundo ítem se terminará con el sonido del juego, aplicando sonidos a los dinosaurios y al impacto entre los meteoritos y los dinosaurios. Y para finalizar, en el tercero se realizarán unas pruebas generales para corregir posibles errores que se detecten. Entregable: Al final de este sprint el cliente podrá ver la pantalla de información, el sonido de cada dinosaurio y la funcionalidad del botón de información.

2.- Desarrollo

2.1.- Pantalla de Información En la pantalla de inicio del juego, se ha incorporado un botón, creado con la tableta bamboo fun – Wacom y con Photoshop, siguiendo el diseño de los botones del juego e intuitivo para el usuario.


Fig 67. Imagen botón información.

52

A través de este botón, se accede a una nueva escena o pantalla llamada

pantallaInformacion, en la que se tendrán unas indicaciones para el usuario:

Apunta al marcado con una imagen creada con Photoshop.

Pulsa la pantalla para lanzar meteoritos con una imagen creada con Photoshop.

Los dinosaurios se destruirán si son alcanzados por los meteoritos.

Cuando un dinosaurio desaparezca perderás una vida. En esta escena se ha añadido fondo creando un GameObject, Quad, GameObject – 3D Object – Quad, dentro de la cámara y a éste se le ha asignado una textura. Además se ha creado de la misma manera que el otro botón, un botón para volver a la pantalla de inicio.

Para finalizar, se ha insertado un último botón para el sonido botonSonido, que tiene la misma función y configuración que el botonSonido de las otras pantallas: activa y desactiva el sonido. Podemos ver el resultado:



Fig 70. Imagen del botón de atrás. Fig 71. Textura para el fondo de la pantalla información.

Fig 72. Pantalla de información.

53

2.2.- Sonido del juego 2

Cuando un dinosaurio es alcanzado por un meteorito se instancia un prefab, que hace referencia a una Explosión, por lo que es ahí donde se añadirá el AudioSource que contiene el AudioClip con el sonido que se ha descargado. A todos los dinosaurios se les ha asignado un sonido específico, añadiendo un AudioSource a cada uno. Lo que se quiere ahora es controlar todos ellos desde el botón de sonido y silenciar o activar el sonido, como se hace con el sonido de fondo del juego. Para ello se ha creado una clase o script MuteControl, que tiene una variable booleana que se pondrá true o false en función de si está o no activado el sonido, un delegado, un evento y una función que devuelve un bool con un get y un set. Los eventos y los delegados en Unity, es la forma que tiene una clase de comunicarse a uno o varios objetos cuando ocurre algo. Cualquier objeto se podrá subscribir al evento sin necesidad de que nuestro evento tenga conocimiento de sus subscriptores. Ahora se crea otro script controladorSonido, que se añadirá a todos los elementos que tienen un AudioSource, con el fin de controlar si Muted es true o false para active o desactive el sonido Esto se añade en el Awake() para que se haga antes del Start().

Se cambia el script de control de sonido que va asociado al botón BotonSonido. Ahora tanto al pulsar como al instanciarse comprobará la variable Muted.

public class MuteControl {

private static bool muted=false;

public delegate void MuteChangedEventHandler(bool muted);

public static event MuteChangedEventHandler MutedStateChanged;

public static bool Muted{

get{

return muted;

}set{

if(MutedStateChanged!=null) MutedStateChanged(value);

muted=value;

}

}

}

public class controladorSonido : MonoBehaviour {


void Awake () {

if (!MuteControl.Muted) this.audio.Play ();

}

}

54

Antes se comprobaba con una variable booleana que cambiaba en este propio script. 2.2.1 Audios Los audios del juego4:

Explosión5: bajo la licencia CC BY6.

Dino7: bajo la licencia CC BY8 y cortado9 para adecuarlo a las necesidades del proyecto.

Tron10: bajo la licencia CC BY-NC11 y cortado12 para adecuarlo a las necesidades del proyecto.

Bronto13: bajo la licencia CC BY14.

Rita15: bajo la licencia CC BY-NC16 y cortado17 para adecuarlo a las necesidades del proyecto.

Curri18: bajo licencia CC019. 2.3.- Pruebas Aunque durante todo el proyecto se han ido realizando pruebas, además de realizar las pruebas concretas para este sprint, se ha creído oportuno realizar unas pruebas generales para comprobar que la aplicación funciona correctamente. 2.3.1.- Pruebas realizadas

Pruebas de caja negra. o Disparo de los meteoritos

4 Descargados de la página http://www.freesound.org/

5 http://www.freesound.org/people/juskiddink/sounds/108640/

6 Creative Commons BY - http://creativecommons.org/licenses/by/3.0/

7 http://www.freesound.org/people/BESTROFLMAN/sounds/212433/

8 Creative Commons BY - http://creativecommons.org/licenses/by/3.0/

9 Cortador de audio online - http://mp3cut.net/es/

10 http://www.freesound.org/people/Robinhood76/sounds/134785/

11 Creative Commons BY-NC- http://creativecommons.org/licenses/by-nc/3.0/

12 Cortador de audios online - http://mp3cut.net/es/

13 http://www.freesound.org/people/reinsamba/sounds/15280/

14 Creative Commons BY- http://creativecommons.org/licenses/by/3.0/

15 http://www.freesound.org/people/FK_Prod/sounds/190504/

16 Creative Commons BY-NC- http://creativecommons.org/licenses/by-nc/3.0/

17 Cortador de audios online - http://mp3cut.net/es/

18 http://www.freesound.org/people/JarredGibb/sounds/233279/

19 Creative Commons Zero - http://creativecommons.org/publicdomain/zero/1.0/

void Start () {

if (!MuteControl.Muted) {


} else {


}

}


if (!MuteControl.Muted) {

MuteControl.Muted=true;


//pause


} else {

MuteControl.Muted=false;


//sound restart


}

}

55

Al pulsar la pantalla del dispositivo, se lanzan meteoitos con cierta velocidad y en la posición del dedo en la pantalla. Resultado: el sistema de disparo funciona correctamente. CORRECTO.

o Colisiones entre el meteorito y los dinosaurios. Los meteoritos al ser lanzados colisionan o bien con los dinosaurios o bien con el suelo. En ambas colisiones se destruyen y también el dinosaurio si ha sido impactado con él. Resultado: el sistema de colisiones funciona correctamente. CORRECTO.

o Puntos y vidas. Al ser un dinosaurio alcanzado en el marcador se suma un punto. Al desaparecer un dinosaurio sin ser impactado el usuario pierde una vida. Resultado: el sistema de puntos y vidas funciona correctamente. CORRECTO.

o Sonido de los dinosaurios. Al instanciarse los dinosaurios cada uno emitirán un sonido que se activaráo desactivará en función de la configuración de sonido actual. Resultad: el sonido de los dinosaurios funciona correctamente. CORRECTO

Pruebas de caja blanca por pantalla. Se ha ido pantalla a pantalla probando todas las posibilidades. Resultado: Se encontró un problema que no se había detectado durante el desarrollo. Al pausar el juego en la pantalla principal el sonido sigue sonando y no debería ocurrir ya que todo el juego debe pararse. Solución: el script Pause, además de las funciones ya hechas, se añade una comprobación al pulsar el botón de pausa. Se comprobará si el sonido está activado y en ese caso se parará y al reanudar, con el script, MuteControl, se comprobará la variable booleana y si tiene esta activa, se reanudará el sonido del singletón, ManagerAudio.Instance.Play(); CORRECTO.

Pruebas con Probadores. Otros usuarios han jugado con el fin de encontrar más fallos y ver otras perspectivas. Resultado: Todos los usuarios han quedado contentos con el resultado. CORRECTO.

Pruebas de integración. La apk se ha instalado en otros dispositivos con variación en la pantalla para ver la correcta redimensión. Resultado: El sistema funciona correctamente y la interfaz se adapta adecuadamente a la pantalla de cada dispositivo. CORRECTO.

Pruebas de aceptación. Durante la realización del proyecto la empresa se ha encargado de supervisar la evolución de éste. Se ha realizado una exposición para ver el producto final y ver que los requisitos iniciales se han cumplido. CORRECTO


Se han llevado a cabo todas las tareas en 20 horas, tiempo inferior al planificado, por lo que se ha añadido sonido también al Game over. Se puede ver el gráfico Burndown del desarrollo del séptimo sprint.

56

3.1.- Sonido Game Over El sonido del Game Over20 está bajo la Licencia CC021.

Se va agregar un AudioSource a unos de los componentes del Game over, por ejemplo al UI Text, del canvas y así cuando este se ejecute, se ejecutará también el sonido. Se configura el AudioSource mediante el inspector, añadiéndole el AudioClip correspondiente y quitado la pestaña Play On Awake, para que no se ejecute cuando el objeto al que está asociado despierte. Para el sonido, se ha desarrollado de la misma manera que los demás sonido. Se ha añadido en el UI Text el script controladorSonido, que verá si el sonido está o no desactivo. Además de esto, cuando el sonido está activado, se quiere que el sonido de fondo se desactive, por lo que se va a crear un script audioDisabler que, cuando se instancie, pause el sonido del objeto con el singleton. Los demás sonidos quedarán parados ya que pausa el juego y con ello los dinosaurios. Al añadir una nueva tarea al sprint, el entregable del cliente cambia. En el nuevo entregable el cliente podrá ver la pantalla de información, el sonido de cada dinosaurio, la funcionalidad del botón de información y el sonido del Game Over.

20

Descargado de la página http://www.freesound.org/ en el enlace

http://www.freesound.org/people/jivatma07/sounds/173859/ 21

Creative Commons Zero - http://creativecommons.org/publicdomain/zero/1.0/


57

Gestión real del proyecto

Tarea Sprint Horas. Estimadas Horas. Reales Gestión del proyecto - 5 h 5 h

Estudio de la RA hoy en día

- 10 h 10 h

Tecnologías de RA Sprint 0 30 h 30 h

Reuniones - 10 h 8 h

Cierre de la Memoria - 5 h 10 h

Presentación - 15 h 15 h

Estudio de Herramientas

Sprint 1 45 h 45 h Captura de Requisitos

Diseño plan de pruebas

Desarrollo del producto

IT1: Modelos 3D Sprint 2 30 h 42 h

IT2:Escena Juego Sprint 3 30 h 30 h

IT3: Meteoritos Sprint 4 35 h 35 h

IT4: Vidas y Puntos

IT5: Parar y Pausar

Sprint 5 25 h 30 h IT6: Incrementar la dificultad

IT7: Pantalla de inicio

Sprint 6 35 h 30 h IT8: Game Over

IT9: Diseño y realización de botones y logo

IT10: Sonido del juego

Sprint 7 25 h 25 h IT11: Información del juego

IT12: Pruebas

Total 300 h 315 h

Conclusiones

Gracias a la realización de este TFG se ha aprendido mucho sobre la Realidad Aumentada y su aplicación en sectores cotidianos. Con la elección de Unity como herramienta de desarrollo, se ha aprendido mucho sobre él y sus principales ventajas e inconvenientes. Esto nos puede ser muy útil para el futuro ya que Unity es un gran motor de juegos que permite el desarrollo en Android, iOS y Windows. Además permite importar muchas librerías y complementos adicionales, como por ejemplo la librería Vuforia, que hace que el trabajo con la RA sea más sencillo. El resultado global de este trabajo ha sido grato ya que ha aportado muchos conocimientos adicionales a los obtenidos en la carrera.

Fig 74. Tabla de comparación de horas.

58

Mejoras

Como el tiempo para el proyecto está limitado a 300 horas no se han podido incorporar las mejoras que han ido surgiendo durante el proyecto como son:

Dificultad inicial del juego. En función de qué usuario juegue podría seleccionar un nivel inicial superior. Implementar dicha tarea es sencilla pero sería necesario dedicar bastantes horas a la creación de la pantalla para los niveles y los botones específicos.

En la interfaz de la pantalla principal se podría incorporar un temporizador para que el usuario pueda ver cuánto tiempo le queda a cada dinosaurio en el juego.

Otra mejora que no depende del tiempo, si no que al tener la versión gratuita de Unity no se puede crear pantallas de carga en las transiciones entre escenas. Esto podría ser útil para la transición entre la pantalla inicial y la pantalla principal del juego.

59

Bibliografía

[1] Ramesh Raskar, Greg Welch, Henry Fuchs. (1998) - Spatially Augmented Reality,

First International Workshop on Augmented Reality, November 1998.

[2] Acuma, 1997 - R.A Survey of Augmented Reality. Presence Teleoperators and

Virtual Environments.

[3] O. Bimber, R. Rakar, 2005 - “Spatial Augmented Reality. Merging Real and Virtual Worlds”.

[4] Realidad Aumentada - http://es.wikipedia.org/wiki/Realidad_aumentada

[5] Android - https://www.android.com/

[6] Layar - http://www.layar.com

[7] Junaio - http://www.junaio.com/

[8] Metaio - http://www.metaio.com/

[9] Vuforia Developer Portal - https://developer.vuforia.com/

[10] How To Install the Vuforia Unity Extension -

https://developer.vuforia.com/library/articles/Solution/Installing-the-Unity-Extension

[11] Documentación de Team Foundation Server - https://msdn.microsoft.com/es-

es/library/fda2bad5(v=vs.90).aspx

[12] Blender - https://www.blender.org/

[13] Comunidad de Blender 3D en Español - http://www.g-blender.org/

[14] Unity documentation - http://docs.unity3d.com/

[15] Official Community - http://unity3d.com/community

[16] Official Scripting Documentation -

http://docs.unity3d.com/ScriptReference/index.html

[17] Unity Tutorials https://unity3d.com/es/learn/tutorials/modules

[18] Live Training Archive - https://unity3d.com/es/learn/tutorials/modules/live-

training-archive

[19] UnitySpain - http://www.unityspain.com/

[20] Project: Space Shooter, Shooting Shots -

https://unity3d.com/es/learn/tutorials/projects/space-shooter/shooting-shots

[21] Colliders -

http://unity3d.com/es/learn/tutorials/modules/beginner/physics/colliders

[22] AddForce -

http://unity3d.com/es/learn/tutorials/modules/beginner/physics/addforce

[23] Game Over - https://unity3d.com/es/learn/tutorials/projects/space-

shooter/ending-the-game

[24] Game Over Screen and animation- http://unity3d.com/es/node/6951

[25] Audio Listeners & Sources -

htt1ps://unity3d.com/es/learn/tutorials/modules/beginner/audio/audio-sources-and-

listeners y http://docs.unity3d.com/ScriptReference/AudioSource.html

[26] Unity Patterns - http://unitypatterns.com/singletons/ y

http://www.gamedev.es/?p=10282

[27] Repositorio de trabajos de fin de grado de la biblioteca de la Universidad de la

rioja - http://investigadoresur.unirioja.es/?q=node/38&var=2112&cod=2

Anexo I: Marcador Uso de la Realidad Aumentada en el desarrollo de aplicaciones

móviles

1

Fig 1. Marcador de la escena principal del juego.

Instalación DinoShooting

Para la instalación será necesario activar la opción Permitir fuentes desconocidas (Se encuentra en Ajustes). Esta opción permite instalar aplicaciones que no provienen de Play Store. Si esta opción no se acepta el dispositivo bloqueará la instalación. Para la instalación, siga los siguientes pasos:

1. Conecte su dispositivo al ordenador. 2. Acceda a su dispositivo a través del ordenador 3. Copie el archivo DinoShooting.apk en un directorio del dispositivo. 4. Abra el archivo DinoShooting.apk desde el dispositivo y pulse instalar.

uso de la realidad aumentada en el desarrollo de ... · herramientas unity y la librería vuforia....

Documents