Está en la página 1de 88

Des

arroll
odeunaa pp

bri
das obreel
jue
go
del
aYi ncana
MásterUniver
sit
ari
oenDesar
rol
l
odeSof
twar
e
par
aDi sposi
ti
vosMóvi
les

Tr
abaj
oFi
ndeMást
er

Aut
or:
Sant
iagoMol l
áSánchez
Tut
or/es:
Ant
onioJ av
ierGal
l
egoSánc
hez

Sept
i
embr
e2022
Desarrollo de una App hı́brida
sobre el juego de la Yincana

Autor
Santiago Mollá Sánchez

Directores
Antonio Javier Gallego Sánchez
Departamento de Lenguajes y Sistemas Informáticos

Máster Universitario en Desarrollo de Software


para Dispositivos Móviles

ALICANTE, 26 de septiembre de 2022


Justificación y Objetivos

Una yincana o gincana es una competición de carácter lúdico en la que los equipos
participantes deben superar una serie de pruebas y obstáculos a lo largo de un recorrido.
El tipo de pruebas que tiene que superar los equipos pueden ser pruebas de ingenio, de
habilidad, pruebas fı́sicas o pruebas deportivas. El juego acaba cuando todos los equipos
han participado en todas las pruebas y han acabado el recorrido.

Las yincanas son originarias de la India y en sus orı́genes, estas competiciones se


hacı́an a caballo. En la actualidad son muy populares como actividad al aire libre y se
pueden celebrar a pie o en todo tipo de vehı́culos como bicicletas, coches o patinetes.

Estos juegos tradicionales han ido evolucionando a lo largo de los años, pero a pesar
de ello, no han sufrido una modernización igual a la que se ha llevado a cabo con otros
juegos tradicionales que se han visto beneficiados del uso de la tecnologı́a. Gracias a la
tecnologı́a, se podrı́a facilitar el seguimiento del juego además de que podrı́a hacerlo más
interesante y facilitar su popularidad.

Esta idea de modernizar las yincanas con el uso de la tecnologı́a junto con mis deseos
de profundizar en conocimiento y el uso del GPS de los dispositivos móviles, las API
de datos y el uso herramientas que permitan crear aplicaciones multiplataforma que se
puedan ejecutar tanto en Android como en iOS, son los principales motivos por los que
ha tenido lugar este Trabajo Fin de Máster (TFM).

El objetivo de este TFM es diseñar y desarrollar una aplicación móvil que permita a
los usuarios inscribirse en yincanas y jugarlas ı́ntegramente desde su dispositivo. Una vez
inscritos en la yincana deseada, el jugador deberá encontrar todos los puntos de control
que componen la yincana en el menor tiempo posible. Para ello, el juego le mostrará
una serie de pistas como la dirección en la que está el punto y la distancia que queda
para llegar. Será decisión del jugador el elegir la ruta más corta a dicho punto. En cada
punto de control, tendrá que resolver una prueba para poder obtener las pistas para el
siguiente punto de control.

Además, se va a desarrollar una API que será la encargada de proporcionar toda la


información necesaria a la aplicación móvil y una aplicación web dirigida a los adminis-
tradores para que puedan crear nuevas yincanas que posteriormente estarán disponibles
para los jugadores.
Agradecimientos

A Antonio Javier Gallego Sánchez, mi tutor del proyecto por todo el apoyo recibido
y porque sin él no hubiese podido empezar este proyecto ni llevarlo a cabo.

A Miguel Ángel Lozano Ortega, director del Máster, porque gracias a su apoyo y
ánimos he podido completar este trabajo.

Al resto de profesores del máster por todos los conocimientos transmitidos.

A Germán Santacruz Martı́nez, porque gracias a él me apunté a realizar este máster
y porque siempre me apoyó durante la realización del mismo.

A mi mujer Mar y a mi hija Sira por todo el apoyo recibido y por estar ahı́ siempre
en los buenos y en los malos momentos.
La educación es el arma mas poderosa
que puedes usar para
cambiar el mundo

Nelson Mandela.

v
Índice general

1 Introducción 1
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Estructura del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Estado del arte 6


2.1 El juego de la Yincana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Tipos de yincanas . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Beneficios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Otros tipos de yincanas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Geocaching o Gymkana GPS . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Escape Rooms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Orientación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Aplicaciones móviles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 GooseChase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.2 Scavify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.3 Geocaching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.4 Alternativas a Geocaching . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Planificación y diseño 32
3.1 Metodologı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.1 Diseño aplicación web . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.2 Diseño aplicación móvil . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Tecnologı́as 46
4.1 Herramientas Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Herramientas Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 Laravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4 Ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5 Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.6 Google Maps Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5 Implementación y resultados 61
5.1 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

vi
Índice general vii

5.2 Diagrama UML de la Base de Datos . . . . . . . . . . . . . . . . . . . . . 62


5.3 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4 Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6 Conclusiones 72

Bibliografı́a 78
Índice de figuras

2.1 Resultado de la búsqueda de la palabra Gymkhana en Google . . . . . . . 7


2.2 Gincanas organizadas por la empresa Artemis[1] que están dirigidas a
todo tipo de públicos incluidos empresas. . . . . . . . . . . . . . . . . . . 11
2.3 Ejemplo de travelbug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Ejemplo de Ejemplo de “tesoro” a encontrar en el Geocaching . . . . . . . 13
2.5 Ejemplo de Icono para señalar los puntos de control en la orientación . . 15
2.6 Gráfico con los paı́ses pertenecientes a la OIF . . . . . . . . . . . . . . . . 16
2.7 Ejemplo de mapa usado en Orientación . . . . . . . . . . . . . . . . . . . 17
2.8 Ejemplo de base de control pasando el chip un participante . . . . . . . . 18
2.9 Pantalla de Ranking de GooChase . . . . . . . . . . . . . . . . . . . . . . 20
2.10 Pantalla de creación de misiones . . . . . . . . . . . . . . . . . . . . . . . 21
2.11 Pantalla principal y pantalla de búsqueda de la aplicación GooseChase . . 22
2.12 Pantalla de actividad y ranking de la aplicación GooseChase . . . . . . . 23
2.13 Pantalla principal web Scavify . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.14 Pantalla de ranking y tareas de la aplicación Scavify . . . . . . . . . . . . 24
2.15 Pantalla de Geocaching donde muestra los cachés cercanos a la ubicación
actual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.16 Pantalla detalle de cache a la izquierda y navegación hacia un caché a la
derecha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.17 Pantalla izquierda: cachés encontrados. Pantalla central: cachés escondi-
dos. Pantalla derecha: objetos rasteables encontrados. . . . . . . . . . . . 27
2.18 Pantallas de la aplicación Opencaching QuickFind . . . . . . . . . . . . . 28
2.19 Pantallas de la aplicación c:geo . . . . . . . . . . . . . . . . . . . . . . . . 29
2.20 Pantallas detalle de caché de la aplicación c:geo . . . . . . . . . . . . . . . 30
2.21 Pantallas de navegación de la aplicación c:geo . . . . . . . . . . . . . . . . 30

3.1 Logo de la herramienta Trello . . . . . . . . . . . . . . . . . . . . . . . . . 32


3.2 Pantalla Trello. Estado de las tareas del Proyecto . . . . . . . . . . . . . . 33
3.3 Diagrama de flujo de la navegación de la aplicación web. . . . . . . . . . . 34
3.4 Diagrama de flujo de la navegación de la aplicación móvil. . . . . . . . . . 35
3.5 Aplicación Web - Portada. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6 Aplicación Web - Pantalla de acceso de usuario. . . . . . . . . . . . . . . . 37
3.7 Aplicación Web - Registro de usuario. . . . . . . . . . . . . . . . . . . . . 38
3.8 Aplicación Web - Panel de control. . . . . . . . . . . . . . . . . . . . . . . 39
3.9 Aplicación Web - Ranking general. . . . . . . . . . . . . . . . . . . . . . . 40

viii
Índice de figuras ix

3.10 Aplicación Web - Ranking juego. . . . . . . . . . . . . . . . . . . . . . . . 40


3.11 Aplicación Web - Lista de juegos disponibles. . . . . . . . . . . . . . . . . 41
3.12 Aplicación Web - Información de un juego. . . . . . . . . . . . . . . . . . 41
3.13 Aplicación Web - Crear juego. . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.14 Aplicación Web - Logros. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.15 Aplicación móvil - Figura izquierda: pantalla principal. Figura derecha:
pantalla de creación de usuarios. . . . . . . . . . . . . . . . . . . . . . . . 43
3.16 Aplicación móvil - Figura izquierda: pantalla de login de usuarios. Figura
derecha: pantalla con el panel de control. . . . . . . . . . . . . . . . . . . 43
3.17 Aplicación móvil - Figura izquierda: pantalla con el ranking del jugador
en todos los juegos. Figura derecha: pantalla con el ranking completo de
un juego concreto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.18 Aplicación móvil - Figura izquierda: pantalla general de logros. Figura
derecha: pantalla de logros conseguidos en cada juego. . . . . . . . . . . . 44
3.19 Aplicación móvil - Figura izquierda: pantalla de búsqueda de juegos cer-
canos. Figura derecha: pantalla de juego con la pista al siguiente punto
de control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.20 Aplicación móvil - Figura izquierda: pantalla con un reto para que lo
supere el usuario. Figura derecha: pantalla con el juego finalizado. . . . . 45

4.1 Pantalla del editor Visual Studio Code editando los ficheros del proyecto. 47
4.2 Pantalla de la aplicación web Bitbucket con el repositorio del proyecto. . . 47
4.3 Pantalla de la aplicación SourceTree con el repositorio del proyecto. . . . 48
4.4 Pantalla de la aplicación DataGrip conectado a la base de datos del proyecto. 49
4.5 Pantalla del terminal zsh con el cliente mariadb conectado a la base de
datos del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.6 Captura de pantalla de la web de Laravel. . . . . . . . . . . . . . . . . . . 51
4.7 Elementos del patrón MVC. . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.8 Imagen con la polı́tica de soporte de Laravel. . . . . . . . . . . . . . . . . 54
4.9 Captura de pantalla de la web de Ionic Framework. . . . . . . . . . . . . . 55
4.10 Imagen con la polı́tica de soporte de Ionic Framework. . . . . . . . . . . . 57
4.11 Captura de pantalla de la web de Angular. . . . . . . . . . . . . . . . . . 58
4.12 Imagen con la polı́tica de soporte de Angular. . . . . . . . . . . . . . . . . 59

5.1 Arquitectura del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62


5.2 Diagrama UML de la base de datos. . . . . . . . . . . . . . . . . . . . . . 63
5.3 Estructura de directorios de Laravel. . . . . . . . . . . . . . . . . . . . . . 66
5.4 Detalle de la estructura de directorios de los controladores en Laravel. . . 67
5.5 Detalle de las rutas de Laravel. . . . . . . . . . . . . . . . . . . . . . . . . 67
5.6 Como obtener las coordenadas actuales en el navegador. . . . . . . . . . . 68
5.7 SQL para obtener los puntos que están a menos de 100KM de los puntos
dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.8 Capturas de pantalla de la aplicación web done se muestra la página
principal de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Índice de figuras x

5.9 Capturas de pantalla de la aplicación web donde se muestra el formulario


de login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.10 Capturas de pantalla de la aplicación web donde se muestra la pantalla
de creación de partidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.11 Capturas de pantalla de la aplicación móvil. . . . . . . . . . . . . . . . . . 71
1 Introducción

Según la RAE[2] una yincana o gincana es “una competición de carácter lúdico en


la que los equipos participantes deben superar una serie de pruebas y obstáculos a lo
largo de un recorrido”. Esta palabra tiene su origen en la palabra inglesa Gymkhana
que a su vez deriva del “hindi”1 gend-khāna, que significa “campo de juego de pelota”.
La palabra inglesa sustituyó el formante glend- “pelota” por el inglés gym que significa
“gimnástico” o “gimnasia”. El significado actual designa tanto un lugar en el que se
celebran concursos de habilidad, como al propio concurso o juego.

Las pruebas que tienen que superar los equipos pueden ser de varios tipos, como
ingenio, habilidad, fı́sicas o deportivas. El juego acaba cuando todos los equipos han
participado en todas las pruebas y han acabado el recorrido. En la actualidad, este tipo
de juegos se practica principalmente en la India.

En otros paı́ses como España ha tenido un auge estos últimos años por la pandemia
mundial de COVID-19. Se utilizó básicamente para entretener a los más pequeños en los
dı́as de confinamiento. Gracias a las yincanas que organizaron padres y madres de todo
el mundo en casa, los más pequeños pudieron sobrellevar los dı́as de confinamiento y la
imposibilidad de salir a la calle durante esos dı́as.

Repasando la historia de este juego, ya en el siglo XIX, el ejército Británico las orga-
nizaba en la India para mantener en forma a la caballerı́a y mejorar su destreza como
jinetes. Una gymkhana tı́pica consistı́a en llevar a cabo una carrera a caballo en un circui-
to serpenteante, durante la cual los participantes debı́an sortear una serie de obstáculos
consistentes en hileras de postes situados a diversas alturas, siendo penalizados si omitı́an
saltar algún obstáculo o voltean algún poste.

En sus orı́genes, en las yincanas se competı́a a caballo. Hoy en dı́a, se celebran a pie o
en todo tipo de vehı́culos como bicicletas, coches o patinetes y son muy populares como
actividades al aire libre. En los paı́ses de habla inglesa continua siendo un concurso de
equitación, generalmente infantil, en el que la agilidad de los caballos y el talento de los
jinetes se demuestra en distintas pruebas.

1
Lengua del grupo indio, procedente del indio medio, que se habla principalmente en el norte y centro
de la India, y que difiere del urdu solo en la escritura.

1
Introducción 2

Como se ha podido ver, la yincana es un juego tradicional con siglos de historia que
aún en la actualidad se sigue practicando. De manera similar a la modernización que
se ha llevado a cabo con otros juegos tradicionales, la yincana también podrı́a verse
beneficiada con el uso de la tecnologı́a, no solo para facilitar el seguimiento del juego,
sino que incluso podrı́a hacerlo más interesante y favorecer su popularidad.

1.1. Objetivos

Este proyecto nace con el objetivo de crear una aplicación que posibilite jugar al
juego de la yincana. Los jugadores se tendrán que inscribir en la yincana que deseen y
completar todas las pruebas propuestas en cada punto de control.

Para elegir el juego se utilizará el GPS del móvil para mostrarle al jugador los juegos
que están más cerca de su posición. El usuario podrá elegir el juego que le guste más y
empezar a jugar cuando esté preparado. Una vez iniciado el juego, empezará a contar
el tiempo hasta que alcance el último punto de control. Al finalizar el juego el jugador
obtendrá una clasificación y, cuando lo hayan completado todos los participantes, se
mostrará su clasificación final.

Los juegos se podrán crear desde un portal web donde los usuarios registrados tendrán
las herramientas necesarias para geolocalizar el juego que estén creando y añadirle los
puntos de control que consideren. Cuantos más puntos de control tenga el juego, más
difı́cil se considerará.

Una API será la encargada de la comunicación con la aplicación móvil, propor-


cionándole los datos necesarios de los usuarios y de los juegos y guardando los resultados
de los mismos.

El objetivo general de este proyecto consiste en realizar una aplicación para la pla-
taforma Android y para la plataforma iOS, que integre gran parte de los contenidos
impartidos durante el máster, obteniendo un prototipo de juego que sea funcional y
sentando las bases para futuras ampliaciones.

Entre los objetivos iniciales, antes de arrancar con la aplicación, se encuentran:

Toma de requisitos funcionales y no funcionales de la aplicación.

Investigación y análisis sobre aplicaciones similares que existan actualmente en el


mercado.

Estudio de diferentes soluciones para visualizar mapas con información.


Introducción 3

Estudio y pruebas de la integración de mapas en aplicaciones web y en aplicaciones


hı́bridas.

Estudio y diseño del esquema de base de datos para guardar toda la información
necesaria de los juegos y los usuarios.

A su vez, entre los objetivos principales de la aplicación, están:

Creación de una aplicación multiplataforma que controle todo el juego. Esta aplica-
ción estará disponible en las tiendas de aplicaciones de las diferentes plataformas.

Uso del GPS del móvil para obtener la ubicación en tiempo real del jugador y poder
saber qué juegos hay activos en su zona. Además también permitirá determinar
cuándo un jugador ha llegado al punto de control correspondiente.

Integración del uso de una API de mapas en la aplicación multiplataforma para


mostrar los diferentes juegos que hay activos en el área del jugador.

Creación de una aplicación web en la que los administradores de los juegos podrán
crear y administrar los juegos de la yincana.

Integración del uso de una API de mapas en la aplicación web para poder definir
los puntos de control de cada partida que tiene recorrer cada jugador.

Creación de una API para poder enviar y recibir datos de los juegos a través de la
aplicación móvil.

Definición de pistas para los puntos de control que tienen que atravesar cada ju-
gador para acabar el juego por parte de los administradores.

Aumentar la seguridad del todo el sistema con la autenticación de los usuarios


mediante usuario y contraseña.

Aumentar la seguridad de toda la API mediante el uso de “tokens”2 de autenti-


cación que se enviarán al servidor con cada consulta que se haga a la API. De
esta forma, se incrementará la seguridad al no tener que enviar el usuario sus
credenciales con cada llamada a la API.

Y como requisitos opcionales o avanzados que se llevarán a cabo una vez se hayan
alcanzado los objetivos principales, se encuentran:

2
Testigos
Introducción 4

Añadir la posibilidad de desbloqueo de logros y el uso de marcadores para crear


rankings de puntuación entre los distintos usuarios del juego.

Visualización de rankings y logros en la aplicación móvil una vez que el jugador


haya completado el juego.

Visualización de rankings y logros de cada jugador que haya completado el juego


por parte de los administradores en la aplicación web.

Por último, entre los objetivos del autor para este proyecto, tenemos:

Establecer las bases a partir de la cuales poder iniciar otros proyectos similares.

1.2. Estructura del trabajo

A continuación, como introducción al resto del documento, se mencionan, junto con


una breve explicación, el resto de apartados que lo componen:

Capı́tulo 1: Introducción ⇒ Capı́tulo introductorio que abarca los fundamentos


del proyecto y describe los objetivos que se pretenden alcanzar.

Capı́tulo 2: Estado del arte ⇒ Capı́tulo dedicado a la realización de una bre-


ve introducción al mundo de las yincanas y al estudio de los diferentes tipos de
yincanas que se pueden encontrar. También se hace un análisis de las aplicaciones
existentes en la actualidad, cuyas caracterı́sticas se asemejan, en mayor o menor
medida, al prototipo final que se quiere desarrollar en este proyecto. Finalmente, se
obtienen una serie de conclusiones que asientan las bases del trabajo a desarrollar.

Capı́tulo 3: Planificación y diseño ⇒ Capı́tulo dedicado a la realización de


toda la explicación más en detalle de todos los aspectos relacionados con la meto-
dologı́a utilizada, la planificación del desarrollo del proyecto y la fase de diseño del
mismo.

Capı́tulo 4: Tecnologı́as ⇒ Capı́tulo en el que se explican en detalle todas las


tecnologı́as utilizadas para llevar a cambo este proyecto.

Capı́tulo 5: Implementación y resultados ⇒ Este capı́tulo se detallan todos


los aspectos relacionados con la arquitectura elegida y el proceso llevado a cabo
para la implementación del proyecto.
Introducción 5

Capı́tulo 6: Conclusiones y perspectivas de futuro ⇒ Contiene el conjunto


de reflexiones obtenidas tras la finalización del proyecto y las lı́neas de trabajo para
seguir desarrollándolo en futuras ampliaciones.

Capı́tulo 7: Bibliografı́a y referencias ⇒ Capı́tulo dedicado a la recopilación


de toda la bibliografı́a utilizada para la realización del trabajo. Detalla mediante
enlaces web todas las referencias que se han utilizado.
2 Estado del arte

En este apartado se realizará, en un primer momento, un estudio más amplio de


lo que se conoce como juego de la Yincana, sus posibles usos y los beneficios que se
obtienen al practicarlo. Además, se va a analizar las carreras de orientación ya que tienen
muchas similitudes con las yincanas. En segundo lugar se van a analizar una serie de
aplicaciones móviles, tanto para jugar al juego de la Yincana, como para hacer carreras
de orientación ya existentes en este momento, que incluyan funcionalidades similares
a las que queremos integrar en este proyecto. Por último, se incluirá un apartado de
conclusiones que fundamente el trabajo al realizar.

2.1. El juego de la Yincana

Antes de nada, hay que aclarar que las palabras yincana y gincana son sinónimos y
por tanto se va a utilizar indistintamente una de las dos para nombrar al juego.

El juego de la Yincana, como se ha expuesto en la introducción, es una competición


en la que los equipos participantes tienen que superar una serie de pruebas y obstáculos
a lo largo de un recorrido. Al final ganará el equipo que ha superador todas las pruebas
y obstáculos en el menor tiempo posible. Las pruebas que se tienen que superar en una
Yincana pueden ser de ingenio, habilidad, fı́sicas o deportivas.

Haciendo una búsqueda en Google[3] se puede ver que al buscar la palabra Yincana
aparecen unos 287.000 resultados, si se busca la palabra Gincana, aparecen unos 6 mi-
llones de resultados y si se busca la palabra inglesa Gymkhana, aparecen 12 millones de
resultados. Esta última búsqueda se puede ver en la figura 2.1

Analizando estos resultados se puede comprobar que las yincanas son muy populares en
Internet y es un recurso sobre todo muy usado en el mundo de la educación. También se
puede comprobar que, por su propia definición, es un tipo de juego que se puede organizar
de muchas maneras y todas ellas son correctas. Aquı́ se puede sacar una conclusión muy
clara, que es un tipo de juego muy popular y que todo el mundo, en cierta manera, juega
o ha jugado alguna vez en su vida.

6
Estado del arte 7

Figura 2.1: Resultado de la búsqueda de la palabra Gymkhana en Google

2.1.1. Tipos de yincanas

Para organizar una yincana, se pueden pensar en infinitos tipos de pruebas pero las
más comunes son las siguientes:

Juego del teléfono roto: se dividen los participante en dos equipos y se ponen
en dos filas. Al primero de cada fila se le transmite un mensaje que tiene que ir
retransmitiendo al segundo y éste al tercer. Cuando se llega al último de cada fila,
se dice en voz alta y gana el equipo que su mensaje sea más similar al original.
Ésta es una magnı́fica prueba para la diversión y el ingenio de los concursantes.

Juego del relevo de ciegos: se forman dos equipos y se colocan la mitad de cada
equipo en un extremo de la pista y la otra mitad en el otro extremo. A los primeros
de cada uno de los grupos de cada equipo se les venda los ojos. El participante
de un extremo tiene que llegar al otro extremo donde está su compañero con los
ojos vendados y pasarle el relevo. Este recorrido lo tiene que hacer a su vez con
los ojos vendados y siguiendo las instrucciones de los otros miembros del equipo.
Aquı́ gana el equipo que haga todos sus relevos primero. La caracterı́stica de esta
prueba es la agilidad y el equilibro de cada concursante para llegar a hacer todo el
recorrido con los ojos vendados.
Estado del arte 8

Juego de encontrar un tesoro: ésta prueba es una de las más divertidas y que se
usan más a la hora de yincanas en grupo ya que se caracteriza por la incertidumbre
y el espı́ritu de competición. Aquı́ el objetivo es encontrar un tesoro y para llegar a
él los participantes deberán resolver una serie de acertijos y pistas con la ayuda de
un mapa y su propio ingenio. Es muy importante recordar que la piedra angular de
este juego tiene como objetivo encontrar un regalo o un tesoro como recompensa
por haber superado todos los obstáculos.

Juego de carreras de pelotas y/o de cucharas: para este juego se necesitan


unas cuantas pelotas de ping pong y tantas cucharas como participantes haya. Los
jugadores tienen que recorrer arrodillados un circuito a la vez que llevan la cuchara
en la boca y sobre ésta una pelota de ping pong. El recorrido del circuito se hace
con un jugador de cada equipo a la vez. Cuando éste llegue a meta, saldrán los
segundos y ası́ sucesivamente hasta que salgan todos los jugadores. Gana el equipo
que llegue antes el último jugador. Si se le cae la pelota a algún jugador, tiene que
volver a empezar el circuito.

Juego de carreras de cangrejos: los dos equipos se colocan de dos en dos en


filas completamente rectas. Los dos primeros concursantes de cada equipo se atan
los tobillos con una cuerda o un pañuelo y corren hasta alcanzar la meta. Al llegar,
se desatan los tobillos y entregan el pañuelo o la cuerda a la pareja siguiente. Se
hará ası́ sucesivamente y ganará el equipo que termine antes. Ésta prueba es una
de las más conocidas y que más se utilizan en diferentes obstáculos de la gincana,
ya sea para niños o para adultos.

Juego de carrera de sacos: este juego se puede hacer por equipos con relevos o
individualmente. Aquı́ se colocan los concursantes de pie en fila dentro de un saco
que le cubra las piernas y el se hace una carrera donde gana el primero que llegue.

Juego de buscar caramelos en harina: con las manos a la espalda, los partici-
pantes deben buscar y coger con la boca unos caramelos escondidos en un cuenco
con harina en un tiempo determinado. El que haya encontrado más caramelos gana.

Estirar la cuerda: se traza una lı́nea en el suelo que determina el punto central
de una cuerda y cada equipo tiene que estirar de los extremos de la cuerda. Gana
el equipo que supere la marca del suelo.

Relevo de zapatillas: se forman dos equipos y se dibuja una área en el centro. Los
dos primeros jugadores deben descalzarse, dejar allı́ sus zapatos y volver al punto
inicial. Cuando todos están descalzos, se inicia la segunda parte de la prueba que
consiste en correr, calzarse y volver a la meta. La gracia de este juego es que no
podrán hacerlo antes de estar debidamente calzados y ganará el equipo que acabe
primero.
Estado del arte 9

El juego de la silla: la idea es colocar sillas en un cı́rculo pero siempre con


menos sillas que participantes. Pondremos música de ambiente y cada vez que deje
de sonar, los concursantes deberán correr a buscar una silla. El que se quede sin
ella, será eliminado. Sucesivamente, quitaremos una silla por cada jugador que ha
abandonado la prueba.

Hay más tipos de pruebas, además, siempre se pueden hacer variaciones para adap-
tarlas a los participantes o al tipo de yincana que se esté organizando. También se puede
inventar nuevas pruebas que encajen mejor con los participantes o el tipo de yincana.

2.1.2. Beneficios

El juego de la yincana tiene muchos beneficios para niños y adultos pero los principales
son los siguientes:

Realización de ejercicio fı́sico. Además de tener que desplazarnos para realizar


las distintas pruebas, muchas de las pruebas suelen incluir algún tipo de carrera o
actividad fı́sica para poder superarla.

Ayuda a mejorar las relaciones personales. La gincana muchas veces nos


obliga a salirnos de nuestra zona de confort y a tener que interaccionar con otras
personas (jugadores y organizadores), para poder realizar las pruebas.

Fomenta el trabajo en equipo o Team Building. Tener que tomar decisiones


dentro de un grupo para poder superar un reto, requiere capacidad de negociación
y liderazgo. Cada prueba de la gincana requiere de distintas habilidades o destrezas
dónde todos los jugadores pueden colaborar de forma única.

Estimula la inteligencia. Muchas de las pruebas necesitan de ingenio y de un


esfuerzo mental o intelectual para poder ser resueltas. Por ejemplo, la resolución
de enigmas, códigos secretos, etc.

Ayuda a concienciar sobre la importancia del cuidado del medio am-


biente y de los recursos naturales.

Trabaja las habilidades de orientación. Para poder encontrar las distintas


pruebas, los grupos suelen tener un mapa para saber el recorrido y ası́ poder
encontrar los sitios dónde realizar las pruebas.

Lo más importante de un juego es pasar un rato divertido y relajados, y la gincana no


es una excepción. Jugar nos ayuda a evadirnos de nuestra rutina ya que hace focalizar
Estado del arte 10

nuestra atención hacia el juego en grupo.

2.1.3. Usos

El juego de la Yincana es un juego muy heterogéneo que puede tener muchas variantes.
Gracias a esto, es un juego que puede estar dirigido tanto a niños como a adultos. Las
yincanas son una herramienta básica para educar a base de juegos y por eso mismo
constituye una herramienta muy buena que se utiliza en educación. La gincana es una
magnı́fica forma de que todos los alumnos se sientan importantes ya que todos son
imprescindibles a la hora de superar los diferentes obstáculos que se encontraran en esta
actividad, y en la vida.

En Internet hay mucho material dedicado a la aplicación de las yincanas dentro de las
aulas. El tipo de yincana que más se organiza dentro del aula son las búsquedas del tesoro
y prueba de ello es que se pueden encontrar multitud de materiales para organizarlas y
multitud de ejemplos.

También es un recurso muy bueno para fomentar el Team Building[4] en las empresas.
Gracias a las yincanas se puede mejorar las relaciones interpersonales dentro de un
grupo y este objetivo es el que se busca con el Team Building. De hecho, hay empresas
dedicadas a organizar este tipo de gincanas dirigidas a Empresas como se puede apreciar
en la figura 2.2

Las yincanas son un recurso que se utiliza muy a menudo tanto en casa como en
eventos sociales como puede ser cumpleaños, fiestas, reuniones sociales... Por ejemplo, es
común organizar alguna búsqueda del tesoro en casa o en un cumpleaños para entretener
a los más pequeños. Además en tiempos de pandemia del coronavirus se utilizaron mucho
estas búsquedas para entretener a los niños durante el confinamiento. En esos dı́as muchas
webs escribieron artı́culos dando consejos para organizar este tipo de búsquedas en casa.

2.2. Otros tipos de yincanas

Dentro de las gincanas se podrı́an aglutinar una gran variedad de actividades de


aventura, como pueden ser las siguientes:

Geocaching

Escape Rooms
Estado del arte 11

Figura 2.2: Gincanas organizadas por la empresa Artemis[1] que están dirigidas a todo
tipo de públicos incluidos empresas.

Orientación

2.2.1. Geocaching o Gymkana GPS

El Geocaching[5] o Gymkhana GPS consiste en esconder objetos en el campo o en la


ciudad por parte de una persona y hacer públicas sus coordenadas geográficas, por lo
general en webs especializadas para que otros lo encuentren. El “tesoro” básico es un
cuaderno llamado logbook, para dejar registrada tu visita. Hay otros contenedores más
grandes que, además del logbook, incluyen un objeto de poco valor que puede llevarse
el que lo descubre, pero siempre dejando a cambio algo de igual o mayor valor para el
siguiente “geocacher”. Entre los objetos que pueden dejarse en el contenedor, también
están los travelbugs y geocoins que son “objetos viajeros”, es decir, con ellos puedes y
debes sacarlos del contenedor pero sólo para llevarlos a otro “geoescondite” para ayu-
darles a cumplir su misión. Para saber la misión de dichos objetos, hay que meter el
código que llevan en la web de Geocaching. En la figura 2.3 se puede ver un ejemplo de
travelbug y en la figura 2.4 se puede ver un ejemplo de “tesoro” a encontrar.

Geocaching tuvo su origen en un grupo de noticias1 dedicado a los Sistemas Globales


1
Los grupos de noticias (newsgroups[6] en inglés) son un medio de comunicación dentro del sistema
Estado del arte 12

Figura 2.3: Ejemplo de travelbug

de Navegación por Satélite. El 1 de mayo de 2000, el Gobierno Estadounidense suprimió


la disponibilidad selectiva de estos sistemas. Esta disponibilidad selectiva degradaba la
señal intencionadamente de los satélites para evitar que los receptores comerciales fueran
demasiado precisos. David Ulmer, miembro del grupo de noticias, decidió celebrar esta
supresión escondiendo un “tesoro” en los alrededores de Portland en Oregón y publicando
sus coordenadas exactas el 3 de mayo del 2000 para que los demás miembros del grupo
pudieran encontrarlo. El 6 de mayo este “tesoro” ya tenı́a dos visitas registradas en su
logbook.

El Geocaching comenzó como un entretenimiento con un marcado carácter tecnológico


pero se ha ido transformando con el paso del tiempo en una práctica extendida a multitud
de paı́ses. Hoy en dı́a hay millones de tesoros escondidos en ciudades de todo el mundo
y millones de jugadores buscándolos.

Usenet en el cual los usuarios leen y envı́an mensajes textuales a distintos tablones distribuidos entre
servidores con la posibilidad de enviar y contestar a los mensajes
Estado del arte 13

Figura 2.4: Ejemplo de Ejemplo de “tesoro” a encontrar en el Geocaching

Consultando la página Geocaching.com[7] se puede observar que en Alicante ya hay


alrededor de 1.790 “tesoros” escondidos. Otra página con mucha información sobre el
Geocaching en España es Geocachingspain.es[8] la cual organiza eventos de Geocaching
por todo el territorio español para practicar y fomentar esta afición.

2.2.2. Escape Rooms

Los Escape Rooms son juegos de aventura fı́sico y mental donde se encierran un grupo
de jugadores, que forman un equipo, en una habitación. El grupo de jugadores deberá ir
resolviendo enigmas y rompecabezas de todo tipo para conseguir salir de esta habitación.
Una vez que hayan salido de la habitación, entrarán en otra habitación en la que también
tendrán que resolver rompecabezas y enigmas para conseguir salir de dicha habitación.
Esto lo harán sucesivamente hasta que consigan salir de todas las habitaciones del juego
y por tanto escapen del juego. Normalmente tienen de 60 a 90 minutos para conseguir
resolver todos los enigmas y escapar.

Cada Espace Rooms puede estar ambientado en un escenario completamente diferente:


naves espaciales, búnkeres militares, casas encantadas, la guarida de un asesino en serie,
el despacho del director de un colegio y un sinfı́n de temas. Usualmente los temas de los
acertijos siguen la temática del Escape Room.

El primer Escape Room surgió en Japón, en el año 2007 y fue creado por el guionista
y director de anime y cine Takao Kato. Hasta el 2011 no se expandieron fuera de Japón,
siendo Singapur y San Francisco las primeras ciudades donde aparecieron. Los Escape
Room siguieron crediendo y en 2017 ya habı́an más de 8000 en todo el mundo.
Estado del arte 14

Existen tres variantes de los Escape Rooms:

Escape Room exterior: aquı́ las actividades se realizan en el exterior y la finalidad


del mismo ya no es escapar.

Escape Room infantil: este tipo está enfocado al publico infantil. Los jugadores ya
no se encierran en una sala, si no que se puede hacer en el exterior, en un espacio
cubierto, ludotecas... Aquı́ siempre está un Game Master Junior con los jugadores
para ayudarles a conducir el juego y darles pistas.

Escape Book: se trata de una transposición al terreno literario de la experiencia que


tiene lugar en un Escape Room. Los lectores de este tipo de libros deben resolver
una serie de enigmas que indican las páginas que se deben leer a continuación para
que la historia tenga sentido.

En ambientes académicos también se han usado los cuartos de escape como una es-
trategia de “ludificación del aprendizaje”[9] o “gamificación del aprendizaje”. Con esta
estrategia lo que se persigue es fomentar el aprendizaje motivando al alumnado a apren-
der mediante el uso de elementos de juegos y diseños de videojuegos en el entorno del
aprendizaje.

2.2.3. Orientación

La orientación es un conjunto de deportes en los que se necesita recorrer, con ayuda


de un mapa y una brújula, un terreno diverso y generalmente desconocido. En este
recorrido, los participantes tienen que encontrar una serie de puntos de control en un
orden preestablecido. Para ello, son provistos de una brújula y un mapa topográfico,
normalmente confeccionado a medida para este deporte.

Las carreras de orientación cuentan con la peculiaridad de no tener un trazado mar-


cado de principio a fin, sino que cada corredor diseña su propio recorrido basándose
únicamente en el mapa que se le entrega a la salida y con la única ayuda de una brújula,
para acabar pasando por todos los puntos de control o balizas que vienen señalados en
el mapa. En la figura 2.5 se puede ver el icono con el que están marcados los puntos de
control.

El corredor puede tener que llegar en un orden preestablecido a los controles o balizas
o que el orden en que se recorren las balizas sea libre. El número de balizas, la longitud
del recorrido (o extensión del terreno utilizado) y la dificultad del terreno (cuestas,
bosque, obstáculos naturales, etc.) son variables y se eligen en función del nivel de los
participantes.
Estado del arte 15

Figura 2.5: Ejemplo de Icono para señalar los puntos de control en la orientación

La orientación tiene más de cien años de historia, originario de los Paı́ses Escandina-
vos. Concretamente de Suecia donde surgió en el siglo XIX en la Academia Militar de
Karlberg. A partir de ahı́ ha ido evolucionando desde ser una pura instrucción militar
hacia un deporte competitivo para oficiales militares y más tarde para civiles. Es un
deporte muy popular en los Paı́ses Escandinavos que se extendió al resto de Europa
después de la Segunda Guerra Mundial. En España fue introducido en los años 80.

Es un deporte reglado con una Federación Internacional, la Federación Internacional


de Orientación o IOF[10] fundara por las Federaciones de Orientación de varios paı́ses
europeos en 1961. Actualmente hay más de 60 Federaciones Nacionales como miembros
de la Federación Internacional. Entre ellas está la Federación Española de Orientación
o FEDO[11]. Todo esto ha hecho que anualmente se celebre un campeonato mundial de
Orientación. Anteriormente, se celebraba cada dos años.

Dentro de la Orientación hay cuatro elementos principales:

Mapa: es uno de los elementos más importantes de este deporte ya que es el que
indica dónde están los puntos de control. Los mapas que se utilizan son especiales
para este deporte, basados en mapas cartográficos con gran detalle para ser lo más
precisos posibles. En estos mapas se tiene que representar el relieve con las curvas
de nivel del terreno. También pueden incluir elementos como caminos, zonas de
bosque, diferentes densidades de vegetación, etc. Todos los mapas se rigen por la
normativa de la OIF. En la figura 2.7 se puede ver un mapa usado en orientación.
Estado del arte 16

Figura 2.6: Gráfico con los paı́ses pertenecientes a la OIF

Brújula: facilita la orientación del mapa y ayuda a realizar rutas más precisas.
No es obligatoria, es un elemento auxiliar. En este deporte se suelen usar brújulas
planas transparentes con limbo móvil y brújulas de dedo. Estas brújulas son más
precisas porque tiene una aguja magnética dentro de una cápsula llena de lı́quido
estabilizador, el cual hace que la aguja se detenga rápidamente en vez de oscilar
repetidamente alrededor del norte magnético.

Controles: los controles están representados en el mapa por un cı́rculo de color


púrpura. Todos los participantes tienen que pasar por estos puntos de control.
Están marcados en el terreno, de una forma muy visible, por un prisma triangular
con las tres caras laterales de colores naranja y blanco. Para asegurar que cada
participante pasa por cada punto de control, se sitúa un comisario de la competi-
ción en cada punto de control para perforar la tarjeta de cada participante. Estas
perforaciones son diferentes y permiten identificar cada punto de control. Una vez
que el participante llega a meta se comprueba que tiene todas las perforaciones y
en base a ellas, los participantes pueden estar en cuatro estados: no sale, sale pero
no finaliza, finaliza con error en el recorrido y finaliza sin error el recorrido.

Sistema electrónico de control de paso: es un sistema que consiste en dos


elementos, por un lado, un chip que porta cada corredor con un identificador único.
Este identificador permite identificar al participante en cada competición. El otro
elemento es una estación o base de control que está en cada punto de control.
Cuando finaliza la competición, cada participante debe descargar la información
de su chip en el ordenador de meta para comprobar que ha pasado por cada punto
de control y el tiempo que ha hecho.
Estado del arte 17

Figura 2.7: Ejemplo de mapa usado en Orientación

En el mundo de las carreras de orientación hay todo tipo de modalidades y distancias:


diurnas, nocturnas, a pie, en bici o en otro vehı́culo sin motor, individuales o en grupo.
Entre todas ellas las más importante y que están regladas por la federación son las
siguientes:

Carrera a pie (O PIE ): Carrera individual y diurna, la convencional. Es la más


conocida y practicada. Pero también hay carreras de orientación nocturna, que
tienen la dificultad añadida de la oscuridad de la noche, por lo que son recorridos
más cortos y terrenos más fáciles y sin peligros. Además, los participantes llevan
una linterna frontal para facilitar su avance. Dentro de esta categorı́a están las
siguientes competiciones oficiales :

1. Media distancia: aquı́ se reduce la distancia entre cada punto de control,


forzando al participante a leer el mapa de manera más precisa. Por lo tanto
son recorridos más técnicos y es menos importante la forma fı́sica de cada
corredor. Son competiciones que varı́an entre 35 minutos y una hora.

2. Larga distancia: aquı́ importa más el estado fı́sico del corredor frente a la difi-
cultad técnica. Para ello se aumenta la distancia entre cada punto de control.
El tiempo habitual de cada corredor en estos recorridos suelen variar entre la
hora y la hora y media.
Estado del arte 18

Figura 2.8: Ejemplo de base de control pasando el chip un participante

3. Sprint: pruebas de muy corto recorrido, consiguiendo que lo importante sea la


velocidad explosiva frente a la resistencia. Para estas pruebas se debe utilizar
una normativa especı́fica para realizar los mapas de forma que todos sus
sı́mbolos del mapa pueden ser vistos a mayor velocidad.

4. Carreras de orientación por relevos: competición por equipos donde cada


miembro del equipo realiza un recorrido individual y el resultado final del
equipo es la suma de los tiempos de todos los recorridos individuales de cada
uno de sus componentes.

5. Score: en este tipo de pruebas el corredor tiene marcado en el mapa unos


ciertos controles los cuales podrá realizar en el orden que considere oportuno.
Suelen tener un tiempo lı́mite penalizándose a los corredores que superen ese
tiempo. Estas pruebas no suelen realizarse en ámbito nacional y pueden ser
tanto de la modalidad a pie como en bicicleta de montaña

Orientación en Bici (MTB O): esta modalidad consiste en realizar la carrera


pasando por los puntos representados en el mapa en el menor tiempo posible des-
plazándose sobre la bicicleta aunque puedes bajarte de ella y empujarla si fuera
necesario.
Estado del arte 19

Orientación sobre esquı́ (O ESQUÍ): consiste en practicar orientación sobre la


nieve haciendo esquı́ de fondo. Esta modalidad es objetiva y se basa en el tiempo
de manera que el más rápido gana. Desarrolla la capacidad matemática y espacial,
la memoria a corto plazo y otras capacidades mentales además de las habilidades
fı́sicas de un esquiador. Los atletas tienen que leer el mapa y hacer decisiones sobre
las rutas mientras esquı́an a toda velocidad.

Orientación precisa (O PRECISIÓN ): en esta modalidad, los participantes de-


ben seguir un recorrido marcado por los organizadores. En este recorrido habrán
puntos de control y puntos de observación. Los participantes deberán ira a cada
punto de observación para poder localizar los puntos de control que están repre-
sentados en su mapa (cada corredor lleva un mapa distinto). También puede darse
el caso de que ninguno de los puntos de control que se observan desde un punto
de control sea correcto porque no está representado en el mapa. La clasificación de
estas pruebas se realizará dependiendo del número de correctos acertados por el
participante y, a igualdad de puntos, ganará el que haya tardado menos tiempo en
realizar el recorrido o el que resuelva en menos tiempo unas pruebas cronometradas
de desempate.

Raid de aventura: el raid de aventura tiene un reglamento especı́fico. Es una


competición multidisciplinar destinada a probar la capacidad de resistencia, de
navegación y de supervivencia de equipos en completa autonomı́a. Los partici-
pantes deben completar un extenso recorrido de orientación, en el menor tiempo
posible, superando las dificultades naturales que encuentren a su paso, utilizando
exclusivamente sus propias fuerzas, sin recibir ayuda externa, ni valerse de me-
dios motorizados (a pie, canoa, esquı́s. . . cascos, cuerdas, guantes, bastones. . . ).
El recorrido ha de ser desconocido de antemano y se organiza en etapas, secciones,
pruebas especiales y puntos de control intermedios, de paso obligado o voluntario.
El itinerario entre controles es libre y no está señalizado en el terreno.

2.3. Aplicaciones móviles

Después de revisar las principales tiendas de aplicaciones como son Google Play[12] y
la App Store[13] de Apple se ha podido comprobar que hay varias aplicaciones dedicadas
al juego de la yincana y del Geocaching o al mundo de la Orientación. A continuación
se van a exponer las que son más interesantes y tienen caracterı́sticas que se plantean
en este proyecto.
Estado del arte 20

2.3.1. GooseChase

GooseChase es una aplicación disponible para tanto para iOS como para Android
desarrollada por la empresa Goose Chase Adventures Inc. Tiene dos partes, una web[14]
desde donde el usuario se puede registrar y crear los juegos y una aplicación desde donde
los usuarios pueden jugar a dichos juegos. Está pensada de tal forma que la parte de
jugar los juegos es gratuita pero la parte de crear los juegos tiene un coste. En un primer
momento se pueden crear dos juegos sin tener hacer ninguna subscripción. tiene una
serie más de limitaciones:

Sólo pueden crear tres equipos en el modo Equipo o tres jugadores individuales en
el modo individual.

Sólo se puede tener un juego activo a la vez.

Sólo permite 5 móviles por equipo en el modo juego.

Para quitar estas limitaciones hay que pagar por cada juego que se cree. Hay tres
modalidades de pago que básicamente permiten que jugar a más usuarios a la vez,
ocho en el caso de la modalidad intermedia y 20 en la más avanzada. También hay una
modalidad de empresa en la que no hay ninguna limitación a cambio de una cuota anual.

Figura 2.9: Pantalla de Ranking de GooChase

Cuando la partida está activa y hay equipos o participantes individuales jugando, se


puede consultar el ranking (figura 2.9) de éstos para ver quien ha conseguido más puntos.
También se puede consultar toda la activad que hay en el juego durante el desarrollo del
Estado del arte 21

mismo y las respuestas o imágenes que han subido los participantes.

Se pueden crear tantas partidas, que la empresa llama experiencias, hay que como
queramos pero en el plan gratuito sólo se puede tener una de estas experiencias acti-
vas a la vez. Crear una experiencia es una tarea sencilla, sólo pide un nombre para la
experiencia, una descripción y opcionalmente una localización para la misma.

Las experiencias están formadas por misiones que a su vez también son fáciles de crear.
Para crearlas hay que indicar el tipo de misión, el nombre y una puntuación. Hay tres
tipos de misiones que se pueden crear:

Enviar una foto de la galerı́a de fotos o de la cámara: en este caso tambı́en hay
que indicar la temática de la que tiene que ser la foto que posteriormente tendrá
que comprobar el administrador del juego si es correcta o no.

Contestar una pregunta: hay que indicarle el texto de la pregunta y las respuestas
que se admiten como correctas. Si el participante acierta, gana los puntos.

Ir a un lugar usando el GPS: se le indican unas coordenadas y el participante tiene


que ir a dicho punto.

Figura 2.10: Pantalla de creación de misiones

En cuanto a la aplicación para jugar a las experiencias es muy fácil de utilizar. Tiene
una pantalla principal donde el usuario puede entrar a la aplicación con su usuario y
contraseña y, en el caso de que no esté registrado, hacer el registro en la aplicación. Una
vez que se ha autenticado en la aplicación, puede visualizar todas las experiencias que
Estado del arte 22

ya ha finalizado o buscar nuevas experiencias para inscribirse. Estas pantallas se pueden


ver en la figura 2.11.

Figura 2.11: Pantalla principal y pantalla de búsqueda de la aplicación GooseChase

Para poder registrarte en una experiencia, previamente te tienen que pasar una invita-
ción con el código de la experiencia. Sin dicho código no puedes inscribirte en la misma.
Las experiencias se pueden jugar en equipo o individuales. Esto se tiene que elegir en el
momento de crear la experiencia.

Una vez superadas todas las misiones de la experiencia, se puede consultar toda la
actividad que se ha hecho en la misma y el ranking de los usuarios que más puntuación
han obtenido. Esto se puede ver en la figura 2.12

Por lo que se puede ver en la web de GooseChase, esta aplicación es sobre todo para
fomentar el Team Building en las empresas. El esquema de precios que tiene la aplicación
y los tramos de usuarios también dan pistas de este hecho.

2.3.2. Scavify

Scavify es una aplicación muy similar a GooseChase. También está formada por una
parte web[15] desde la que se pueden crear los juegos y una aplicación de móvil[16] para
jugar a dichos juegos. La mayor diferencia que tiene con GooseChase es que si quieres
crear juegos, entonces tienes que suscribirte.
Estado del arte 23

Figura 2.12: Pantalla de actividad y ranking de la aplicación GooseChase

En Scavify, la suscripción sólo es obligatoria para los organizadores de las partidas.


Una vez que los organizadores han creado las partidas, los participantes no tienen que
pagar nada. Pero sólo se podrán apuntar a las partidas si previamente el organizador
o los organizadores les han enviado el código o contraseña para poder entrar en las
partidas.

Figura 2.13: Pantalla principal web Scavify

En el caso de la aplicación del móvil, Scavify una vez instalada pide que el usuario
se registre, o en el caso de que ya lo esté, que introduzca su usuario y contraseña. En
la pantalla principal de la aplicación se pueden ver los juegos en los que ha jugado el
jugador o está jugando en este momento y un buscador para buscar nuevos juegos. Para
Estado del arte 24

poder acceder a un juegos, el usuario tiene que tener una invitación o un password de
dicho juego que se lo tiene que facilitar el administrador del juego.

Para poder probar la aplicación, hay un juego demo con una lista de tareas a completar.
Las tareas son de tres tipos: tomar una foto de la temática que indique la tarea, ir a
un sitio con el GPS del móvil, contestar una pregunta o escanear un código QR2 . En la
figura 2.14 se pueden ver las pantallas de raking y la lista de tareas de la aplicación de
Scavify.

Figura 2.14: Pantalla de ranking y tareas de la aplicación Scavify

Esta aplicación también está muy orientada al Team Building y está muy dirigidas a
empresas que quieran fomentar este tipo de dinámicas entre sus trabajadores. También
está dirigida a Universidades, conferencias y destinos turı́sticos.

2.3.3. Geocaching

La aplicación Geochaging[7] esta disponible tanto para Android como para iOS en sus
respectivas tiendas de aplicaciones. Esta aplicación es la aplicación oficial para poder
encontrar objetos escondidos por personas que practican el Geocaching. En un primer
momento, una persona escondı́a un tesoro y después publicaba sus coordenadas en algún
grupo de noticias o algún blog o web dedicados al Geocaching. Después los demás usua-
rios de los grupos de noticias o de las web donde surgı́an publicadas las coordenadas
2
Es un módulo para almacenar información en una matriz de puntos o en un código de barras bidimen-
sional
Estado del arte 25

podı́an ir a buscar estos tesoros y poder firmar en su logbook y ver que más objetos
existı́an.

Figura 2.15: Pantalla de Geocaching donde muestra los cachés cercanos a la ubicación
actual.

Con el auge de los dispositivos móviles esto ha mejorado mucho, aunque su esencia
sigue igual. Ahora con la aplicación se pueden buscar los tesoros directamente desde su
interfaz. Para ello muestra un mapa con los cachés o tesoros cercanos y que aún no los ha
encontrado el usuario (figura 2.15). Desde esta pantalla se puede seleccionar cualquier
caché que aparezca para ver más información. Una vez seleccionado, mostrará toda
información en detalle de dicho caché y aparecerá la opción de buscarlo o de guardarlo
en una lista para buscarlo posteriormente. Estas dos pantalla se pueden ver en la figura
2.17.

Una vez encontrado el caché, se añadirá a la lista de los cachés que ya ha encontrado
el usuario. Fı́sicamente, el usuario ya podrá firmar en el logbook y mirar los otros objetos
que contiene e intercambiarlos por otros. Una vez hay terminado, tiene que volver a
esconder el caché donde estaba para que lo puedan encontrar los usuarios que vengan
después.

En el perfil del usuario, éste puede ver cuantos cachés ha encontrado y cuando ha
escondido además de sus estadı́sticas. Para poder esconder un caché, los usuarios tienen
que haber encontrado antes veinte cachés, si no la aplicación no da la opción de utilizar
esta función. La aplicación tiene otras funciones interesantes como poder enviar mensajes
a otros usuarios de la comunidad para poder contactar con ellos. En el perfil de usuario
también se puede ver los objetos rasteables que ha encontrado el usuario. Cada vez que
Estado del arte 26

Figura 2.16: Pantalla detalle de cache a la izquierda y navegación hacia un caché a la


derecha

encuentre un objeto rasteable y este consulte su información con su código, se añadirá


a esta lista.

Todas estas funciones que se han descrito son gratuitas ya que la aplicación tiene una
modalidad de pago para poder desbloquear ciertas caracterı́sticas de la misma. El pago
es una suscripción que puede ser mensual (6,40€) o anual (32,09€). Las caracterı́sticas
que se añaden son las siguientes:

Acceso a todos los tipos de Geocachés. Hay varios tipos de cachés en la aplica-
ción, representados en el mapa con un icono verde y uno gris. En principio, los
usuarios normales, sólo pueden buscar los cachés con el icono verde. Para poder
encontrar los cachés con icono gris hay que ser usuario premium. Estos cachés
mejorados necesitan superar una prueba para acceder a ellos o tener que buscar
cachés intermedios para llegar al caché principal.

Buscar y ordenar con filtros avanzados. Si el usuario no es premium, la aplicación


ofrece una búsqueda básica. En ella se puede buscar por código de caché, por
ubicación (actual o una que le pase el usuario), por objetos rasteables o por geotours
(tours que se organizan para encontrar varios geocaches en una misma zona). Si
el usuario es premium, la búsqueda se aplia permitiendo que se pueda buscar por
tipo de chaché. Además, los filtros directamente no se pueden usar si el usuario no
es premium.
Estado del arte 27

Figura 2.17: Pantalla izquierda: cachés encontrados. Pantalla central: cachés escondidos.
Pantalla derecha: objetos rasteables encontrados.

Crear y descargar listas y mapas para los usuarios sin conexión. Para poder uti-
lizar los mapas sin conexión el usuario tienen que ser premium. Esta opción es
interesante para encontrar cachés en zonas donde la cobertura sea mala o no haya
cobertura. El acceso al GPS será posible en estas zonas pero el usuario no podrá
ver un mapa de la misma para facilitarle la búsqueda del caché. Las lista sirven
para que el usuario pueda guardar varios geocachés de una zona y poder planificar
el orden en el que va a ir a buscarlos. Si además guarda el mapa de la zona, puede
ir a buscarlos cuando quiera sin necesidad de tener cobertura.

2.3.4. Alternativas a Geocaching

La aplicación Geocaching está desarrollada por la empresa Groundspeak Inc.[17] que


a su vez es dueña de la web https://www.geocaching.com. Esta empresa es la que
se encarga de almacenar todos los datos referentes a los usuarios y a los cachés que se
pueden buscar dentro de la aplicación. Por ese motivo, hay una suscripción premium y
cachés que sólo se pueden buscar si el usuario es premium. El modelo de negocio de esta
empresa es freemium, es decir, ofreciendo servicios básicos gratuitos, mientras se cobra
dinero por otros servicios más avanzados o especiales.

La “Opencahing Network” surgió como alternativa libre de esta red de geocaching


donde los datos de los cachés están en mano de una empresa. Todos los cachés que
Estado del arte 28

hay en esta red son libres y los puede buscar cualquier usuario sin necesidad de cuotas
mensajes o servicios premium. En esta red también se pueden registrar los usuarios para
poder guardar los cachés que encuentran y crear nuevos que deben mantener ellos.

Hay aplicaciones alternativas que se conectan a esta red para poder hacer la búsqueda.
Esto es posible gracias a que la red Opencaching tiene una API abierta con la que los
programadores pueden crear aplicaciones y servicios para consumir dicha API. Este es el
caso de la aplicación Opencaching QuickFind disponible sólo para móviles Android. Esta
aplicación es muy simple pero permite que el usuario se conecte a la red Opencaching
para marcar los cachés que ha encontrado.

Figura 2.18: Pantallas de la aplicación Opencaching QuickFind

Una vez que el usuario se ha logueado en la red Opencaching, la aplicación le da la


opción de buscar caches en la página web de Opencaching, abriendo la página web de
Opencaching (https://www.opencaching.de3 ) en un navegador. Una vez encontrado el
caché que el usuario ha encontrado, lo selecciona y vuelve a la aplicación, donde indica
que acción ha hecho con ese caché y la valoración que le da. Este registro se queda
guardado en la red de Opencaching vinculado al usuario. Todo esto se puede ver la
figura 2.18.

Esta aplicación es muy simple si se compara con la aplicación Geocaching ya que sólo
permite guardar un caché encontrado y poco más. Para dar de alta cachés o buscar
cachés existentes el usuario tiene que consultar la web.

Una alternativa mejor es la aplicación “c:geo”[18] disponible solo para la plataforma


Android[19]. Esta aplicación es open source, y en ella, el usuario puede conectarse a la
red de Opencaching pero también permite interactuar con la red de Geocaching gracias
3
Hay varios dominios de opencaching pero esté en concreto tiene versión en español.
Estado del arte 29

Figura 2.19: Pantallas de la aplicación c:geo

a su API RESTful. Además puede tener conectadas varias redes de geocaching y en el


mapa mostrará los cachés de todas ellas que estén en la zona en la que ha buscado el
usuario. En la figura 2.19, la pantalla superior izquierda e inferior izquierda se puden
ver los cachés que muestra la aplicación con la red Opencaching. La pantalla superior
derecha e inferior derecha muestra la misma información pero con la red de Opencaching
y Geocaching.

Una vez que el usuario ha elegido el caché que desea buscar, puede ver toda la infor-
mación referente a él. En este caso, si el usuario esta conectado a la red Geocaching,
también podrá ver el detalla de los cachés premium, cosa que en la aplicación oficial no
se pueden ver si no se tiene una cuenta premium. Esto se puede apreciar en la figura
2.20, en la pantalla de la izquierda que muestra la información avanzada de un caché
premium que se compone de otros cachés secundarios. Desde la página de detalle tam-
Estado del arte 30

Figura 2.20: Pantallas detalle de caché de la aplicación c:geo

bién se puede guardar el caché para buscarlo más tarde o iniciar la navegación para que
ayuda al usuario a encontrar el tesoro. Una vez lo haya encontrado también lo marcará
como encontrado y guardará los datos del usuario en la red correspondiente.

La pantalla de navegación muestra una brújula apuntando a la dirección del caché y


la distancia que queda hasta llegar al mismo (figura 2.21).

Figura 2.21: Pantallas de navegación de la aplicación c:geo

Esta aplicación es muy completa y permite hacer lo mismo que la aplicación oficial de
la red Geocaching pero sin necesitar una suscripción anual o mensual para poder tener
todas las funciones. Además, también permite acceder a casi todas las funcionalidades
Estado del arte 31

de pago de Geocaching de manera nativa y sin ninguna cuota mensual. Permite hacer
listas de cachés, guardar mapas offline como Geocaching y buscar los cachés premium
esta red. Con el añadido de que el usuario puede conectarse a otras redes de geocaching
como puede ser Opencaching.

Otras aplicaciones alternativas son Cachly[20] y GeoCaches[21] disponibles únicamente


para iOS. En el caso de Cachly es un cliente alternativo de Geocaching ya que no permite
conectarse a redes alternativas como Opencaching para encontrar cachés. Simplemente
ofrece las mismas caracterı́sticas que la aplicación oficial de Geocaching. Esta aplicación
tiene un coste de 4,95€ además de tener compras dentro de la aplicación.

En el caso de Geocaches, es un cliente alternativo a Geocaching pero que también


permite conectar con la red Opencaching. En este caso es muy similar a c:geo pero en
la plataforma iOS.

2.4. Conclusiones

Una vez analizadas las principales aplicaciones existentes en el mercado para el Juego
de la Yincana, se puede concluir que no hay ninguna que cubra por completo todos los
objetivos que se plantean en este proyecto:

Aplicación que posibilite jugar al juego de la yincana donde los jugadores tendrán
que inscribirse en la yincana que deseen y completar todas las pruebas sin necesidad
de códigos ni invitaciones.

Sólo se podrán inscribir a las yincanas que estén dentro de su zona ya que para
jugar deberán ir de un sitio a otro y llegar a puntos concretos que se comprobarán
con el GPS del móvil.

Se podrán consultar las clasificaciones de los jugadores una vez completado el


juego.

Los juegos se podrán crear desde un portal web donde podrán geolocalizar el juego
y añadir los puntos de control que deseen. Además, a estos puntos de control se
les podrán añadir pruebas que deberán superar los jugadores.

Por todo esto, se plantea el prototipo a desarrollar en este trabajo. Este prototipo
busca sentar las bases para el desarrollo de juegos similares en un futuro.
3 Planificación y diseño

Una vez que están los conceptos claros del tipo de aplicación que se va a desarrollar, a
continuación se detallará la metodologı́a que se ha seguido para el desarrollo del proyecto
además del diseño preliminar que se hizo de su interfaz.

3.1. Metodologı́a

Para el desarrollo del proyecto se estuvieron barajando varias metodologı́as, tanto


ágiles como SCRUM[22] como más tradicionales como la metodologı́a en cascada[23].
Al final se optó por utilizar una metodologı́a ágil como es KANBAN[24]. Junto a la
metodologı́a kanban, se ha usado la herramienta online Trello para la gestión de las
tareas.

Figura 3.1: Logo de la herramienta Trello

La metodologı́a Kanban tiene su origen en Japón. Fue desarrollado por Taiichi Ohno,
un ingeniero japonés de Toyota, a finales de la década de 1940. Es ingeniero se dio
cuenta de que se podı́a mejorar el sistema de producción cambiando a unos procesos
de producción “just-in-time” (JIT). De esta manera en vez fabricar en función de una
demanda anticipada, se pasó a producir en función de la demanda real que tenı́a el con-
sumidor. Con este método se tenı́an una serie de tarjetas para identificar las necesidades
de material en la cadena de producción.

Esta metodologı́a se ha aplicado también al desarrollo de aplicaciones. Su objetivo es


el usar tarjetas para identificar las tareas. Estas tarjetas se clasifican según su estado y
su prioridad dentro del proyecto. Además, se les puede indicar una fecha de vencimiento
y asignarlas a una persona concreta.

32
Planificación y diseño 33

Se ha optado por esta metodologı́a porque se trata de una metodologı́a simple y fácil
de entender y usar. Además provee de información de una manera rápida, permitiendo
ver el estado del proyecto en cada momento de una manera inmediata.

Aplicando esta metodologı́a se ha creado un panel en Trello con cuatro listas de tareas:

1. Pendiente: tareas pendientes de iniciar

2. En proceso: tareas que se están implementado en este momento

3. Pruebas: tareas ya implementadas que se encuentran en fase de pruebas

4. Finalizado: tareas ya finalizadas y cerradas

Para la construcción de este proyecto, se empezó por hacer un estudio del arte a la vez
que se analizaban los requisitos de la aplicación. Como resultado de estos dos estudios,
se definieron las funcionalidades que debı́a tener la aplicación objeto de este trabajo.

Figura 3.2: Pantalla Trello. Estado de las tareas del Proyecto

Posteriormente, una vez que se tenı́an definidas estas funcionalidades, se analizaron


diferentes tecnologı́as con el fin de encontrar las más adecuadas para su implementación.
A continuación, y para poder planificar mejor el proyecto, se hizo el diseño de todas las
pantallas de la aplicación en forma de mockups para tener una visión global del proyecto
a desarrollar.
Planificación y diseño 34

3.2. Diseño

Para la realización de del prototipo tanto de la aplicación como de la web se utilizó la


herramienta Balsamiq Mockups en su versión web.

En las figuras 3.3 y 3.4 se puede ver el diagrama de flujo de la navegación de la


aplicación web y de la aplicación móvil respectivamente.

Figura 3.3: Diagrama de flujo de la navegación de la aplicación web.

3.2.1. Diseño aplicación web

Las pantallas de las que está compuesta la aplicación web son las siguientes:

Pantalla principal (figura: 3.5): contiene dos botones, uno para entrar como
usuario registrado en la aplicación y otro para registrarse en ella. Además, contiene
el logotipo de la aplicación y un carrusel de imágenes.

Pantalla de acceso (figura: 3.6): contiene dos cuadros de texto donde el usuario
podrá poner su correo y su contraseña para iniciar sesión. También dispone de un
enlace para recuperar la contraseña en el caso de que el usuario no la recuerde.

Pantalla de registro de usuario (figura: 3.7): pantalla para darse de alta en


Planificación y diseño 35

Figura 3.4: Diagrama de flujo de la navegación de la aplicación móvil.

la aplicación. El usuario tiene que introducir la siguiente información para realizar


el alta: nombre, apellidos, nick, teléfono, email y contraseña (que deberá introducir
dos veces). Si la información es correcta se procederá a hacer el alta. Si falta algún
campo o es incorrecto, mostrará un error y le pedirá que lo corrija. También hay
un campo para que el usuario pueda entrar en la aplicación en el caso de que el
usuario ya esté dado de alta.

Pantalla del panel de control(figura: 3.8): pantalla principal para los usuarios
registrados. En ella se muestra un resumen de los juegos que ha creado, los que hay
activos en este momento y los rankings que puede consultar de juegos ya acabados.
También hay un menú superior con todas las opciones de la aplicación (Resumen,
Juegos, Ranking y Logros)

Pantalla de ranking general (figura: 3.9): contiene el ranking de todos los


jugadores de todos los juegos. En el se puede ver qué jugador tiene más puntos y
cuando tiempo ha tardado en completar todos los juegos.

Pantalla de ranking de cada juego (figura: 3.10): esta pantalla muestra el


ranking de cada juego. En ella el usuario puede saber que participante ha com-
pletado el juego consiguiendo más puntos. También puede ver el tiempo que ha
tardado en completar el juego.

Pantalla de juegos (figura: 3.11): contiene el listado de todos los juegos que
Planificación y diseño 36

Figura 3.5: Aplicación Web - Portada.

ha creado el usuario. También muestra la fecha de inicio del mismo y la fecha de


fin, además de su dificultad. En esta pantalla también hay un botón directo para
crear nuevos juegos.

Pantalla de información de un juego (figura: 3.12): esta pantalla muestra


toda la información de un juego concreto. Muestra el nombre, la descripción, la
fecha de inicio y de fin (en el caso de que la haya) y un botón para ver el ranking
de dicha partida en ese momento. También muestra un mapa con los puntos de
control a los que tiene que ir cada usuario para completar el juego.

Pantalla para crear juegos (figura: 3.13): esta pantalla permite al usuario
crear juegos nuevos. Para crear un juego, el usuario tiene que definir un nombre,
una descripción, una fecha de inicio y una de fin y una dificultad. La fecha de
siempre tiene que ser mayor que la fecha de inicio, pero, también puede ser vacı́a
indicando que el juego siempre estará disponible. Para acabar, el jugador tendrá
un mapa para poder elegir la zona donde estará ubicado el juegos y los puntos de
control de los cuales se compondrá.

Pantalla de logros (figura: 3.14): aquı́ el usuario podrá consultar todos los
logros que se han desbloqueado durante el juego y el jugador que ha desbloqueado
estos logros.
Planificación y diseño 37

Figura 3.6: Aplicación Web - Pantalla de acceso de usuario.

3.2.2. Diseño aplicación móvil

Las pantallas de las que está compuesta la aplicación móvil son las siguientes:

Pantalla principal (figura: 3.15 [pantalla izquierda]): pantalla principal de


la aplicación con el logotipo de la misma, el nombre y una imagen. En la parte de
abajo tiene dos botones, uno para que el usuario pueda entrar en la aplicación si
ya está registrado y el otro para que el usuario pueda registrarse.

Pantalla de registro de usuario (figura: 3.15 [pantalla derecha]): pantalla


para darse de alta en la aplicación. El usuario tiene que introducir la siguiente
información para realizar el alta: nombre, apellidos, nick, teléfono, email y contra-
seña (que deberá introducir dos veces). Si la información es correcta se procederá
a hacer el alta. Si falta algún campo o es incorrecto, mostrará un error y le pe-
dirá que lo corrija. También hay un campo para que el usuario pueda entrar en la
aplicación en el caso de que el usuario ya esté dado de alta.

Pantalla de acceso (figura: 3.16 [pantalla izquierda]): pantalla para acceder


a la aplicación que tiene dos campos de texto, uno para que el usuario introduzca
el usuario y el otro para que introduzca la contraseña. Además, hay un botón para
que compruebe los datos y un enlace para recuperar la contraseña en el caso de
que no la recuerde el usuario.

Pantalla del panel de control(figura: 3.16 [pantalla derecha]): pantalla


principal para los usuario de la aplicación que están registrado y han entrado
Planificación y diseño 38

Figura 3.7: Aplicación Web - Registro de usuario.

correctamente con su usuario y contraseña. En esta pantalla aparece una pequeña


estadı́stica del progreso del usuario indicando los juegos que ha completado, los
juegos que hay activos cerca de su zona y la posición global en la que está en el
raking. Siempre que el usuario esté autenticado en el sistema, el la parte de abajo
de la pantalla habrá un menú con las acciones más importante a realizar en la
aplicación: panel de control, juegos, ranking y logros.

Pantalla de ranking general (figura: 3.17 [pantalla izquierda]): en esta


pantalla el usuario puede consultar la posición del ranking en la que esta´en cada
juego. Si pulsa sobre la tarjeta que le muestra la posición en dicho juego, podrá
ver el ranking completo de dicho juego.

Pantalla de ranking de cada juego (figura: 3.17 [pantalla derecha]): esta


pantalla muestra el ranking de cada juego. En ella el usuario puede saber que
posición ocupa en el mismo y de los demás participantes al juego. También se
puede ver el tiempo total que ha tardado cada jugador en completar el juego y su
puntación total.

Pantalla de logros totales (figura: 3.18 [pantalla izquierda]): en esta pan-


talla el usuario puede consulta que logros a desbloqueado hasta ahora en cada
juego.
Planificación y diseño 39

Figura 3.8: Aplicación Web - Panel de control.

Pantalla de logros de un juego (figura: 3.12 [pantalla derecha]): esta


pantalla muestra los logros que ha desbloqueado el usuario en un juego concreto.
También indica la fecha en la que desbloqueó dicho logro.

Pantalla para buscar juegos (figura: 3.19 [pantalla izquierda]): esta pan-
talla permite al usuario buscar juegos en su zona para poder jugarlos. Aparece
un mapa y en el aparecen los puntos donde está el juego. También aparece un
listado con el nombre del juego, la dificultad, hasta cuando está disponible y los
participantes que lo han completado hasta ahora.

Pantalla de juego (figura: 3.19 [pantalla derecha]): en esta pantalla se le


mostrará un mapa al usuario de la zona donde está jugando y una pista de a
donde tiene que dirigirse. La pista será de la forma “Dirı́gete al norte 200 metros”.

Pantalla de retros (figura: 3.20 [pantalla izquierda]): en esta pantalla apa-


recerá cuando el jugador llegue al punto de control correspondiente. Aparecerá una
pregunta con tres opciones para responder. Si responde correctamente, el juego le
mostrará la siguiente pista para ir al siguiente punto de control. Si la respuesta
es incorrecta, el jugador tendrá que esperar 30 segundos para que se muestre la
siguiente pista.

Pantalla de juego finalizado (figura: 3.20 [pantalla derecha]): en esta pan-


talla el jugador podrá ver todos los puntos de control por los que ha pasado, además
del tiempo total que hay hecho y su puntuación total.
Figura 3.9: Aplicación Web - Ranking general.

Figura 3.10: Aplicación Web - Ranking juego.


Planificación y diseño 41

Figura 3.11: Aplicación Web - Lista de juegos disponibles.

Figura 3.12: Aplicación Web - Información de un juego.


Planificación y diseño 42

Figura 3.13: Aplicación Web - Crear juego.

Figura 3.14: Aplicación Web - Logros.


Planificación y diseño 43

Figura 3.15: Aplicación móvil - Figura izquierda: pantalla principal. Figura derecha: pan-
talla de creación de usuarios.

Figura 3.16: Aplicación móvil - Figura izquierda: pantalla de login de usuarios. Figura
derecha: pantalla con el panel de control.
Planificación y diseño 44

Figura 3.17: Aplicación móvil - Figura izquierda: pantalla con el ranking del jugador en
todos los juegos. Figura derecha: pantalla con el ranking completo de un
juego concreto.

Figura 3.18: Aplicación móvil - Figura izquierda: pantalla general de logros. Figura de-
recha: pantalla de logros conseguidos en cada juego.
Planificación y diseño 45

Figura 3.19: Aplicación móvil - Figura izquierda: pantalla de búsqueda de juegos cer-
canos. Figura derecha: pantalla de juego con la pista al siguiente punto de
control.

Figura 3.20: Aplicación móvil - Figura izquierda: pantalla con un reto para que lo supere
el usuario. Figura derecha: pantalla con el juego finalizado.
4 Tecnologı́as

En este capı́tulo se van a explicar las herramientas utilizadas para la realización el


proyecto. También se introducen las diferentes tecnologı́as integradas en la aplicación
final resultado de este trabajo.

4.1. Herramientas Software

A nivel de software, se han utilizado una serie de herramientas para la realización del
proyecto que están detalladas a continuación:

Visual Studio Code[25]: editor de código fuente que está desarrollado por Mi-
crosoft. Es multiplataforma y se puede instalar en Windows, MacOS y Linux.
Además tiene una versión web que es idéntica a la versión de escritorio. Incluye
soporte para la depuración, control integrado de Git, resaltado de sintaxis, fina-
lización inteligente de código, fragmentos y refactorización de código. También es
personalizable, por lo que los usuarios pueden cambiar el tema del editor, los atajos
de teclado y las preferencias. Es gratuito y de código abierto. Todo el desarrollo
de la aplicación móvil como de la aplicación web se ha hecho en este editor. La
versión de Visual Studio Code que se ha utilizado es la 1.71.2. En la figura 4.1 se
puede ver la pantalla del editor.

Git[26] y Bitbucket[27]: Git es una herramienta para el control de versiones


del software que está en desarrollo. Su propósito es llevar registro de los cambios
en archivos del código fuente. Bitbucket en cambio, es un servicio de alojamiento
basado en web, para proyectos que usan como sistema de control de versiones
Git. En el proyecto, Git se han utilizado para guardar todos los cambios que
se han realizado y Bitbucket para guardar dichos cambios en la nube y ası́ poder
consultarlos en cualquier momento. Bitbucket también permite consultar el registro
de cambios de una manera más visual y, también, se puede conectar con Trello para
integrar dentro de su entorno la lista de tareas del proyecto que se ha comentado
anteriormente. La versión de Git que se ha utilizado es la 2.37.0 (Apple Git-136). En
la figura 4.2 se puede ver como se muestra el repositorio del proyecto en Bitbucket.

46
Tecnologı́as 47

Figura 4.1: Pantalla del editor Visual Studio Code editando los ficheros del proyecto.

Figura 4.2: Pantalla de la aplicación web Bitbucket con el repositorio del proyecto.

SourceTree[28]: es un cliente gráfico para Git y, por tanto, permite hacer todas
las acciones de Git desde un entorno gráfico. Se ha utilizado para facilitar la gestión
del repositorio del proyecto. La versión de SourceTree que se ha utilizado es la 4.2.0.
En la figura 4.3 se puede ver el repositorio del proyecto en SourceTree.

XAMPP[29]: es un paquete de software libre que incluye las siguientes aplicacio-


nes:

• Apache Webserver[30] : servidor web encargado de atender las peticiones de


los clientes mediante el protocolo http y devolver el recurso solicitado, nor-
malmente, una página web. En este caso incluye la versión 2.4.52 de Apache
WebServer.
Tecnologı́as 48

Figura 4.3: Pantalla de la aplicación SourceTree con el repositorio del proyecto.

• MariaDB[31] MySQL Database[32] : sistema de gestión de base de datos


relacional (SGBD). En este caso incluye la versión 10.4.21 de MariaDB.

• ProFTPD[33] : servidor que implementa el protocolo FTP (File Transfer Pro-


tocol) encargado de la transferencia de ficheros por la red. En este caso incluye
la versión

• PHP[34] : lenguaje de programación de uso general que se adapta especial-


mente bien al desarrollo web. En este caso incluye la versión 8.1.2 de PHP.

• phpMyAdmin[35] : entorno web para la gestión de la base de datos. Desde aquı́


se pueden hacer consultas en la misma, crear bases de datos, usuario tablas...
En este caso incluye la versión 5.1.1 de phpMyAdmin.

De las tres únicamente se ha utilizado Apache Webserver para servir las páginas
web del proyecto y MariaDB para gestionar la base de datos del proyecto. La
versión de XAMPP que se ha utilizado es la 8.1.2-0

DataGrip[36]: entorno de escritorio para la gestión de bases de datos. Permite


la gestión de diferentes gestores de bases de datos como pueden ser Oracle, SQL
Server o PostreSQL. En este caso se ha utilizado para ver y configurar la base de
datos del proyecto. La versión de DataGrip que se ha utilizado es la 2022.2.3. En
la figura 4.4 se puede ver la base de datos del proyecto en DataGrip.

Android Studio[37]: se trata del entorno de desarrollo integrado oficial desa-


rrollado por Google para la plataforma Android. Sólo se ha utilizado para crear
dispositivos virtuales en los que ir probando la aplicación móvil. Además, para el
Tecnologı́as 49

Figura 4.4: Pantalla de la aplicación DataGrip conectado a la base de datos del proyecto.

desarrollo de la aplicación es necesario el Android SDK y Android Studio ya lo


instala por defecto. La versión de Android Studio es la 2021.3.1.

Xcode[38]: se trata del entorno de desarrollo integrado oficial para el desarrollo


de aplicaciones para iOS i MacOS creado por Apple. En este caso, también se ha
utilizado únicamente para crear dispositivos virtuales en los que probar la aplica-
ción móvil. Además también es necesario para tener el SDK de desarrollo de iOS.
La versión de Xcode es la 14.0.

Terminal zsh[39] y cliente MariaDB[31] - MySQL Database[32]: se trata


del interprete del comando para entornos de tipo Unix. En este interprete se pude
controlar todos los aspectos del sistema operativo desde una interfaz de texto. Por
otro lado, el cliente MariaDB es un entorno para la gestión de la base de datos pero
desde el terminal. Por lo tanto está basado en texto. Se ha utilizado para hacer
tareas sencillas de gestión de la base de datos. La versión de zsh utilizada es la
5.8.1 (x86 64-apple-darwin21.0) y para mariadb la 15.1 (Distrib 10.4.21-MariaDB,
for osx10.10 (x86 64) using EditLine wrapper). En la figura 4.5 se puede ver una
ventana de teminal con el cliente de mariadb conectado a la base de datos del
proyecto.

4.2. Herramientas Hardware

A nivel de software, se han utilizado una serie de herramientas para la realización del
proyecto que están detalladas a continuación:

Pc portátil: Macbook Pro 13 pulgadas (2017)[40] con las siguientes caracterı́sticas:


Tecnologı́as 50

Figura 4.5: Pantalla del terminal zsh con el cliente mariadb conectado a la base de datos
del proyecto.

• Procesador Intel Core i5-7267U [41] a 3,1GHz con Turbo boost a 3,5GHz

• 8GB de memoria RAM a 2133MHz LPDDR3

• Gráfica Intel Iris Plus Graphics 650 [41] con 1536MB de memoria

Dispositivos de prueba:

• Dispositivos fı́sicos: Samsung S7 [42] con Android 8.0 (64bits), Samsung Ex-
perience 9.0 y nivel de parches de seguridad del 1 de marzo de 2020. Tiene un
Exynos 8 Octa 8890 2.3 con ocho núcleos (4 de alto rendimiento y cuadro de
eficiencia). Tiene 4GB de RAM y una GPU ARM Mali-T880 MP12 650 Mhz
con una resolución de 1440x2560px px (QHD) y una pantalla de 5,1 pulgadas
(576ppi).

• Dispositivos virtuales: se han utilizado distintos dispositivos virtuales tanto


en Android como en iOS para hacer las pruebas correspondientes. Estos se
han creado desde el Device Manager de Android Studio en el caso de los dis-
positivos Android y desde el Simulador de Xcode en el caso de los dispositivos
iOS.
Tecnologı́as 51

4.3. Laravel

Laravel[43] es un framework[44] de código abierto para desarrollar aplicaciones y ser-


vicios web mediante el lenguaje de programaicón PHP. Su filosofı́a es desarrollar código
PHP de forma elegante y simple, evitando el “código espagueti”1 . Un framework es un
esquema o marco de trabajo que ofrece una estructura base para elaborar un proyecto
con objetivos especı́ficos, una especie de plantilla que sirve como punto de partida para
la organización y desarrollo de software. Laravel fue creado en 2011 y una gran influencia
de otros framworks como Ruby on Rails[45], Sinatra[46] y ASP.NET MVC [47].

Figura 4.6: Captura de pantalla de la web de Laravel.

Laravel tiene como objetivo ser un framework que permita el uso de una sintaxis
elegante y expresiva para crear código de forma sencilla. Intenta aprovechar lo mejor
de otros frameworks y aprovechar las caracterı́sticas de las últimas versiones de PHP.
Laravel está basado en Synfony[48], otro framework de desarrollo web y, al igual que
éste, sigue una arquitectura de modelo-vista-controlador (MVC). Además, tiene otras
caracterı́sticas:

Tiene un sistema de paquete modular gestionados mediante composer [49].

Eloquent ORM para gestionar la base de datos. Gracias a Eloquent se puede ma-
pear las tablas de la base de datos en clases del modelo.

Tiene un “Query Builder” gracia al cual se pueden diseñar consultas para acceder
1
Término peyorativo para los programas de computación que tienen una estructura de control de flujo
compleja e incomprensible.
Tecnologı́as 52

de una manera más directa a la base de datos y se puede usar como alternativa a
Eloquent.

Tiene Reverse Routing que permite definir una relación entre las rutas de aplicación
y los links que haya dentro de las vistas. Esto hace posible que cambios en la rutas
se propaquen automáticamente a los links de las vistas.

Laravel carga las clases necesarias en todo momento sin necesidad de incluirlas
explı́citamente.

Tiene un sistema de plantillas llamado Blade para generar las vistas de la aplicación
que se esté desarrollando.

La gestión de la base de datos la hace a base de ficheros de migraciones que proveen


control de versiones de la misma.

Tiene un sistema de “database seeding” que sirve para incializar los datos de la
base de datos.

Test unitadios para hacer pruebas unitarias en la aplicación que se esté desarro-
llando.

Paginación automática a la hora de reprentar datos en las vistas.

Validación de formularios

Laravel utiliza el patrón Modelo-Vista-Controlador que normalmente es utilizado para


el desarrollo de interfaces que dividen la lógica del programa en tres elementos interconec-
tados. Esto se hace para separar el modelo de datos que tiene la aplicación, de la formas
que tiene la aplicación de representar la información y de como le llega la información
al usuario. Esta patrón, tal y como se ha dicho, tiene tres elementos:

Modelo (M): aquı́ está la representación de los datos del dominio, es decir, las
entidades que sirven para almacenar información del sistema. También se encarga
de gestionar el almacenamiento y recuperación de los datos y entidades del dominio
y por tanto incluirá mecanismos de persistencia. En el caso de Laravel, Eloquent
es el que se encarga de esta representación y de las tareas de persistencia de datos.

Vista (V): los componentes de la vista son los encargados de generar la interfaz
de la aplicación. Componen las pantallas, páginas o cualquier tipo de resultado
utilizable por el usuario. La Vista es una representación del estado del Modelo en
un momento concreto y en el contexto de una acción determinada. Laravel para
facilitar la creación de las vistas tiene un sistema de procesamiento de plantillas
Tecnologı́as 53

Figura 4.7: Elementos del patrón MVC.

llamado Blade. Este sistema favorece un código mucho más limpio en las vistas,
además incluye un sistema de caché que lo hace mucho más rápido.

Controlador (C): el controlador es el encargado de actuar de intermediario el


usario y el sistema. Tiene que capturar las acciones que haga el usuario en la
vista, como pulsar algún botón o introducir una serie de datos, interpretar estas
acciones y actuar en función de ellas. El controlador también realiza tareas de
transformación de datos para hacer que los componentes de las vistas y los datos
del modelo se entiendan. En el controlador estará toda la lógica de la aplicación.
En Laravel, todos los controladores heredan de la clase base BaseController.

En la figura 4.7 se puede ver de manera esquemática el funcionamiento del patrón


modelo-vista-controlador.

Cada versión de Laravel tiene actualizaciones de errores durante 18 meses y actualiza-


ciones de seguridad durante 24 meses. El ritmo de actualizaciones es muy bueno y más
Tecnologı́as 54

o menos cada dos semanas lanzan una versión corrigiendo errores. También lanzan una
versión mayor cada año, concretamente en febrero. Actualmente, Laravel 9 es la versión
mayor más actual que existe. Para este proyecto se ha elegido dicha versión ya que es la
más reciente y la que tendrá un ciclo de vida mayor a la hora de mantener el proyecto
sin necesidad de cambiar de versión. La versión que se está utilizando en el mismo es la
9.29. En la figura 4.8 se pueden ver las ultimas versiones que han aparecido y la fecha
hasta las que recibirán actualizaciones de seguridad.

Figura 4.8: Imagen con la polı́tica de soporte de Laravel.

4.4. Ionic

Ionic Framework[50] es un SDK2 de código abierto que permite desarrollar aplica-


ciones hı́bridas para dispositivos móviles, aplicaciones de escritorio y aplicaciones web
progresivas. Está basado en tecnologı́as web como son HTML, CSS y Javascript. Permi-
te desarrollar aplicaciones para iOS nativo, Android y web desde un mismo código. Fue
creado en 2013 por Max Lynch, Ben Sperry y Adam Bradley en la empresa Drifty Co.

En un primer momento, Ionic Framework utilizaba AnguarJS como framework de


interfaz de usuario y Apache Cordoba, pero en las últimas versiones, el usuario puede
elegir el framework de interfaz de usuario que más le guste entre Angular, React o
Vue.js aunque también puede utilizar los componentes de Ionic sin necesidad e tener un
framwork de interfaz de usuario.

2
Conjunto de herramientas de desarrollo de software que permite a un desarrollador de software crear
una aplicación informática para un sistema concreto
Tecnologı́as 55

En el caso de las aplicaciones web hı́bridas, Ionic Framework permite que se puedan
distribuir en las tiendas de aplicaciones nativas tanto de iOS como de Android gracias
al uso de Apache Cordova[51] o Capacitator[52]. Gracias al uso de los plugins de Apache
Cordova o Capacitator, Ionic es capaz de tener acceso a los dispositivos del terminal
móvil como son la cámara, el GPS o el led del flash.

Figura 4.9: Captura de pantalla de la web de Ionic Framework.

Ionic Framework tiene una serie de ventajas a la hora de desarrollar aplicaciones


móviles hı́bridas:

Es fácil de aprender y utilizar: al basarse en tecnologı́as web (HTML, CSS, JavaS-


cript), no hay que aprender una nueva tecnologı́a para utilizar Ionic Framework.

Tiene numerosas integraciones y plugins: Ionic se integra con los frameworks de


interfaz gráfica más habituales como Angular, React y Vue. Además, se integra
también con numerosas herramientas y dispone de numerosos plugins.

Más productividad y menos costes: favorece una mayor productividad y reduce los
costes de desarrollo de la aplicación. Desarrollar aplicaciones hı́bridas en un único
código propicia un menor tiempo de desarrollo y hace que su mantenimiento y
escalado sea más sencillo. Además, resulta menos costoso que el desarrollo de una
aplicación nativa.

Diseño de interfaces sencillo: hace más sencillo y rápido el diseño de interfaces de


usuario, gracias a su librerı́a de componentes.

Buena documentación y respaldo de la comunidad: Ionic Framework es un proyecto


de código abierto, muy bien documentado y con una comunidad muy activa.
Tecnologı́as 56

No obstante, Ionic Framework también tiene una serie de desventajas:

Peor rendimiento que las aplicaciones nativas: por su propia naturaleza, las aplica-
ciones nativas siempre serán más rápidas que las aplicaciones hı́bridas ya que las
aplicaciones nativas están diseñadas y mejor optimizadas para la plataforma.

Dependencia con los plugins: cada vez que se necesita acceder a funcionalidad
nativa deberemos recurrir a un plugin. Normalmente, siempre hay un plugin para
cada funcionalidad nativa, pero en casos de funcionalidades nuevas o para casos
muy concretos habrá que esperar a que se desarrolle plugins nuevos.

Aplicaciones más pesadas que las nativas: crear aplicaciones usando HTML, CSS
y JavaScript implica escribir mucho código y agregar librerı́as, complementos y
dependencias que harán que la aplicación sea más pesada que una aplicación nativa.

Ionic Framework lanza una versión mayor del SDK cada seis meses más o menos,
aunque este plazo se puede acortar si se ha introducido algún cambio importante en la
librerı́a. Antes de lanzar la versión final, siempre se publicarán varias versiones candida-
tas. En cuanto a las versiones menores del SDK, se publicará una cada mes, siempre que
se realicen cambios en la API que no sean importantes. Si se corrige algún error y no ha
habido ningún cambio importante o no importante en la API, se lanzará un parche para
corregir el error.

Cada versión de Ionic Framework se actualiza una media de año y medio o dos años.
A partir de ahı́ tiene un tiempo de mantenimiento extendido de medio año a un año
adicional. Una vez pase ese tiempo, se recomienda actualizar el desarrollo a una versión
más nueva. En la figura 4.10 se puede ver las versiones y su ciclo de vida.

Actualmente, Ionic Framework 6 es la versión mayor más actual que existe. Para este
proyecto se ha elegido dicha versión ya que era la más reciente y la que tendrı́a un ciclo
de vida mayor a la hora de mantener el proyecto sin necesidad de cambiar de versión.
La versión que se está utilizando en el mismo es la 6.2.1.

4.5. Angular

Angular[53] es un framework para el desarrollo de aplicaciones web SPA o de una


sóla página, es de código abierto y está mantenido por Google. Es un framework basado
en componentes lo que permite crear aplicaciones web escalables. También incluye una
colección de librerı́as que cubren una variedad enorme de caracterı́sticas como rutas,
gestión de formularios y comunicación cliente-servidor.
Tecnologı́as 57

Figura 4.10: Imagen con la polı́tica de soporte de Ionic Framework.

Angular está desarrollado en TypeScript[54], que es un superconjunto de JavaScript[55]


que añade, esencialmente, tipos estáticos y objetos basados en clases. Gracias a esto, se
puede desarrollar en Angular utilizando tanto TypeScript como JavaScript.

Usar Angular tiene una serie de ventajas:

Componentes personalizados: los desarrolladores tienen total libertad de construir


sus propios componentes. Estos componentes pueden empaquetar la funcionalidad
junto con la lógica de renderizado para ası́ crear piezas reutilizables de código.

Enlace de datos: una de las grandes ventajas es que permite mover datos sin
esfuerzo desde el código JavaScript a la vista y reaccionar a los eventos del usuario
sin tener que escribir adicional.

Inyección de dependencias: permite escribir servicios modulares e inyectarlos donde


se necesiten. Esto mejora la capacidad de prueba y la reutilización de los mismos.

Pruebas: Angular se ha creado desde cero teniendo en cuenta la capacidad de


prueba. Este permite realizar pruebas a cada parte de la aplicación.

Integral: proporciona soluciones listas para la comunicación del servidor y el enru-


tamiento dentro de su aplicación.
Tecnologı́as 58

Figura 4.11: Captura de pantalla de la web de Angular.

Compatibilidad del navegador: es multiplataforma y compatible. Una aplicación


normalmente se puede ejecutar en todos los navegadores y sistemas operativos.

Angular también tiene una serie de limitaciones:

Curva de aprendizaje elevada: tiene gran cantidad de componentes básicos que


se deben conocer para poder programar aplicaciones. Además tiene compoentes
avanzados que son difı́ciles de aprender.

Opciones de SEO limitadas: Angular ofrece opciones de SEO limitadas y poca


accesibilidad para los rastreadores de motores de búsqueda.

Migración: dificultad de migrar código heredado basado en JavaScript a una ar-


quitectura de Angular. También hay dificultad a hora de actualizar un proyecto
en Angular a la última versión de la librerı́a.

Complejo: tiene una estructura compleja a la hora de escribir código.

Angular lanza una versión cada seis meses y cada versión la mantiene más o menos
un año y medio. Estos plazos pueden variar en el caso de que se hay introducido algún
cambio importante en el framework y sea necesario lanzar una versión mayor antes
de tiempo. Angular también se actualiza cuando hay cambios de menor importancia o
cuando hay algún parche de seguridad. En estos casos se lanzan una versión menor o
una versión de parcheo respectivamente. Cuando se lanza una versión mayor, la versión
anterior para a ser versión LTS o “Long Term Support” y se mantiene durante un año
más o menos. La versión más actual de Angular es la 14.2.3.
Tecnologı́as 59

Figura 4.12: Imagen con la polı́tica de soporte de Angular.

En este proyecto se usa la versión 14.2.1 de Angular. Esta decisión viene condicionada
por la versión de Ionic que se usa ya que la versión 6 de Ionic soporta versiones de
angular a partir de la versión 12.0.0. Por lo tanto se ha elegido la versión mayor mas
reciente de Angular para ası́ tener soporte hasta diciembre de 2023.

4.6. Google Maps Platform

Google Maps[56] es un servicio de Google que ofrece imágenes satelitales, fotografı́as


aéreas, mapas de calles, vistas panorámicas interactivas en 360° de las calles (Street
View), condiciones del tráfico en tiempo real y planificación de rutas para viajar a pie,
en automóvil, en bicicleta, por aire (en versión beta) y en transporte público.

Google Maps comenzó como una aplicación de escritorio en C++ desarrollado por
los hermanos Lars y Jens Rasmussen en Where 2 Technologies. En octubre de 2004, la
empresa fue adquirida por Google, que la convirtió en una aplicación web. Después de
adquisiciones adicionales de una empresa de visualización de datos geoespaciales y un
analizador de tráfico en tiempo real, se lanzó Google Maps en febrero de 2005.
Tecnologı́as 60

Google Maps Platform[57] utiliza la plataforma de Google Maps para ofrecer un con-
junto de APIs y SDKs para que los desarrolladores puedan incorporar Google Maps a sus
aplicaciones para dispositivos móviles y páginas web. También pueden recuperar datos
desde Google Maps para mostarlos en sus aplicaciones. Google Maps Platform ofrece los
siguientes productos:

Maps: API de Maps JavaScript, SDK de Maps para Android, SDK de Maps para
iOS, API de Maps Static, API de Street View Static, URL de Maps, API de Maps
Embed.

Routes: API de Directions, API de Distance Matrix, API de Roads.

Places: API de Places, SDK de Places para Android, SDK de Places para iOS.

Biblioteca de Places para la API de Maps JavaScript: API de Geocoding, API de


Geolocation, API de Time Zone.

En este proyecto se va a utilizar la API de Maps para poder mostrar los mapas de los
juegos tanto en la aplicación web como en la aplicación móvil. En estos mapas es donde
se visualizarán y/o se podrán marcar los puntos de control de los juegos.
5 Implementación y resultados

Siguiendo con el trabajo realizado en este TFM, este capı́tulo está dedicado a detallar
la implementación del proyecto y analizar los resultados del mismo. Se va a desglosar en
los siguientes apartados:

Arquitectura

Diagrama UML de la Base de Datos

API

Implementación y Resultados

5.1. Arquitectura

Una vez revisado el marco teórico de la aplicación junto con la metodologı́a empleada,
el diseño de la aplicación y las tecnologı́as usadas, se presenta la arquitectura planteada
en el proyecto.

Donde se pueden apreciar los siguientes componentes:

Base de datos: la base de datos se usará para guardar toda la información de la


aplicación. El acceso a la misma estará restringido al backend, es decir, sólo éste
podrá consultar y guardar datos en la base de datos.

Backend: esta parte se encargará de comunicarse con la base de datos tanto en la


aplicación web como en la API Rest y le servirá los datos a los clientes, tanto web
como de la aplicación móvil. También será el que contenga toda la lógica de negocio
del proyecto. Los clientes únicamente se encargarán de representar los datos en sus
iterfaces.

Frontend: esta parte se encargará de comunicarse con el usuario. Hay que tener en
cuenta que habrá dos frontends diferentes, uno para la aplicación web en Laravel

61
Implementación y resultados 62

Figura 5.1: Arquitectura del proyecto.

y otro para la aplicación móvil en Ionic.

Consulta de mapas: cada frontend se encargará de consultar los mapas correspon-


dientes desde Google Maps. En la base de datos sólo se guardarán coordenadas de
los puntos correspondiente pero nada de mapas ni cartografı́a.

5.2. Diagrama UML de la Base de Datos

Un aspecto importante de la aplicación es la base de datos, ya que en ella se va a


almacenar toda la información relativa a la misma. En la figura 5.2 se puede ver el
esquema propuesta para la aplicación. En este esquema se van a guardar tanto los datos
que se generen desde la aplicación web como los que se generen por la aplicación móvil.

En el esquema se puede apreciar las siguientes tablas:

users: tabla donde que contiene todos los datos de los usuarios registrados en la
aplicación.

partidas: tabla que contiene todos los datos de las partidas que se han creado.

puntos: tabla que contiene los puntos de control de todas las partidas. Estos
puntos sólo pueden pertenecer a una partida aunque una partida puede tener uno
o varios puntos de control.
Implementación y resultados 63

Figura 5.2: Diagrama UML de la base de datos.

juegan: tabla que contiene las partidas que ha jugado cada participante. Aquı́
se guardará tanto las partidas que han sido superadas como las que no se han
superado.

puntos superados: tabla que contiene los puntos que ha superado cada partici-
pante durante una yincana.

5.3. API

Otro aspecto importante del proyecto es la API que se va a utilizar para que la
aplicación móvil pueda obtener los datos necesario y guardar los datos que va generando
durante y después de cada gincana. Una vez que ya se ha definido el diseño de la base de
datos, se puede abordar el diseño de la API junto con las peticiones a las que responderá
y su formato.

La API responderá a las operaciones CRUD (Create, Read, Update y Delete) haciendo
uso de los métodos HTTP más extendidos:

GET: peticiones de lectura.


Implementación y resultados 64

POST: peticiones de crear un nuevo objeto.

PUT: peticiones de actualización de un objeto existente.

DELETE: peticiones de borrado de un objeto.

A continuación, se pueden ver las llamadas que atiende la API, con su endpoint co-
rrespondiente, el método HTTP que utilizan y los parámetros de la propia llamada:

api/v1/auth [POST]: comprueba si el usuario y la contraseña son correctos. Si


son correctos devuelve un token que deberá utilizar el usuario en las siguientes lla-
madas a recursos protegidos. Se le pasan dos parámetros: email (string) y password
(string).

api/v1/partida [GET]: devuelve todas las partidas de la base de datos. No tiene


parámetros

api/v1/partida/:id [GET]: devuelve toda la información de partida que tiene el


id :id.

api/v1/partida/cercanas/:latitud/:longitud [GET]: devuelve una lista de


partidas ordenadas de mayor cercania a la posición que se le pasa.

api/v1/punto/:partida [GET]: devuelve una lista con todos los puntos de control
que están asociados a la partida que tiene como id :partida.

api/v1/punto/:id [GET]: devuelve toda la información del punto de control que


tiene el id :id.

api/v1/juegan/:user [GET]: devuelve una lista de juegos que ha jugado el usua-


rio :user.

api/v1/juegan [POST]: en el cuerpo del POST se le pasan dos parámetros: :user


y :partida. Crea un registro en la tabla juegan de la base de datos con el id :user
y la partida :partida. Esto significa que el usuario ha iniciado una partida.

api/v1/puntossuperados [POST]: en el cuerpo del POST se le pasan dos paráme-


tros: :user y :punto. Crea un registro en la tabla puntossuperados de la base de
datos con el id :user y el punto de control :punto. Esto significa que el usuario ha
superado un punto de control
Implementación y resultados 65

5.4. Desarrollo

Una vez que ya está todo el proyecto definido, ya se puede llevar a cabo el proceso
de implementación. Para ello se ha seguido la metodologı́a Kanban, tal y como se ha
explicado anteriormente. Para la implementación del proyecto primero se empezó con-
figurando todo el entorno de trabajo, el repositorio de software y la base de datos que
iba a utilizar. En la etapa de desarrollo se pueden diferenciar dos fases, en la primera se
implemento todo el backend y en la segunda el frontend.

El proyecto se abordó de esta manera para facilitar el desarrollo del mismo ya que
el frontend es más dependiente de los datos que le pueda proporcionar el backend para
comprobar su corecto funcionamiento. Se podrı́a haber abordado primero el desarrollo
del frontend pero se tendrı́a que haber usado “mocks” para simular los datos y las
llamadas al Backend.

El desarrollo del backend y de la aplicación web se realizado prácticamente a la misma


vez por el hecho de que ambos están desarrollados en Laravel. Gracias a la arquitectura
de Laravel, muchos componentes que se han desarrollado para la API se pueden reutilizar
para el desarrollo de la aplicación web.

En el backend la primera tarea que se abordó fue la creación de todas las migracio-
nes de la base de datos y sus respectivos modelos. Estos modelos están enumerados a
continuación:

User: modelo correspondiente a la tabla de usuarios. En la aplicación se encarga


de representar los datos del usuario. Esta tabla se ha aprovechado del esqueleto
que genera Laravel cuando se le añade la autenticación de usuarios.

Partida: modelo correspondiente a la tabla de partidas. Esta modelo interactuará


con los datos referentes a las partidas de la aplicación.

Punto: modelo correspondiente a la tabla puntos. En esta clase se guardarán los


datos de los puntos de control que tiene que buscar los usuarios en cada juego.

Juegan: modelo correspondiente a la tabla juegan. Aquı́ se guardarán los datos de


los juegos que están jugando o que ya han jugado los participantes de las partidas.

Puntossuperado: modelo correspondiente a la tabla Puntossuperados. En este mo-


delo se guardarán los datos de los puntos de control encontrados por los usuarios.

En cuando a las migraciones, se hizo una por cada tabla que se iba a crear en la base
de datos. Por lo tanto, al final de su creación se han obtenido tantas migraciones como
Implementación y resultados 66

modelos de datos. En la figura 5.3 se puede ver la organización que hace Laravel de los
modelos y de las migraciones de la base de datos.

Figura 5.3: Estructura de directorios de Laravel.

Una vez que se ha acabó de crear el modelo de datos, se pasó al desarrollo de los
controladores. En estos elementos estará toda la lógica de negocio de la aplicación tanto
para la aplicación web como para la API. Para separar un poco más el código y hacerlo
mas mantenible en un futuro se optó por crear dos Controladores para cada Modelo. Un
Controlador será el encargado de la lógica de negocio de la API y el otro controlador
tendrá toda la lógica de negocio de la aplicación web.

En este caso se hubiese podido utilizar el mismo Controlador gestionar la API y la


Implementación y resultados 67

Figura 5.4: Detalle de la estructura de directorios de los controladores en Laravel.

aplicación web pero se ha optado por hacerlo ası́ para tener separaras la lógica de negocio
de ambas para que sea más fácil de mantener. También, se hubiese podido abordar de otra
manera y crear una carpeta para agrupar ambos tipos de controladores y ası́ tenerlos más
organizados. En la figura 5.4 se puede ver el detalle de la carpeta de los controladores.

A continuación se crearon las rutas de entrada para la aplicación y para la API. Laravel
separa las rutas de la aplicación web de las rutas de la API en dos ficheros diferentes.
En la figura 5.5 se puede ver una parte del fichero donde están las rutas de la aplicación
web.

Figura 5.5: Detalle de las rutas de Laravel.

Para acabar, se diseñaron las vistas de la aplicación web que son con las que el usuario
va a interactuar. Estas vistas se hicieron con el sistema de plantillas Blade que tiene
Laravel. En este caso hay una vista especialmente compleja ya que se encarga de mostrar
el mapa de Google Maps con la ubicación actual. En este mapa se puede elegir tanto la
zona de juego donde se pueden colocar los puntos de control como los puntos de control
mismos. En la figura 5.6 se puede ver el código usado para obtener la ubicación actual
del navegador.
Implementación y resultados 68

Figura 5.6: Como obtener las coordenadas actuales en el navegador.

Una vez se tenı́a la aplicación web funcionando aunque sin todas sus funcionalidades,
se pasó a desarrollar la aplicación móvil. En este caso con Ionic Framework. Primero se
definieron los modelos de datos y las llamadas a la API para obtener los datos. En este
caso me basé en los modelos hechos en Laravel, ya que los datos eran los mismos.

Para devolver las partidas más cercanas al usuario tuve que utilizar la formula del
Harvesine:

a = sin2 (φB − φA/2) + cosφA ∗ cosφB ∗ sin2 (λB − λA/2)


√ q
c = 2 ∗ atan2( a, (1 − a))
d=R∗c

Figura 5.7: SQL para obtener los puntos que están a menos de 100KM de los puntos
dados.

Gracias a esta fórmula, se puede saber la distancia que hay entre dos puntos geográficos
ya éstos están situados en una esfera. Esta fórmula la he implementado en una consulta
Implementación y resultados 69

de la base de datos y ası́ se pueden obtener directamente los puntos que están más cerca
de las coordenadas del usuario. Esto se puede ver en la figura ??

5.5. Resultados

Para acabar, en esta sección se incluyen algunas capturas de pantalla de la aplicación


web y de la aplicación móvil.

En las capturas de pantalla 5.8 se puede ver la pagina principal de la aplicación web

En la captura de pantalla 5.9 se puede ver la pantalla de login de la aplicación web

En la captura de pantalla 5.10 se puede ver la pantalla de creación de partidas de la


aplicación web.

En la captura de pantalla 5.11 se puede ver la pantalla de login de la aplicación móvil.

Figura 5.8: Capturas de pantalla de la aplicación web done se muestra la página principal
de la aplicación
Figura 5.9: Capturas de pantalla de la aplicación web donde se muestra el formulario de
login

Figura 5.10: Capturas de pantalla de la aplicación web donde se muestra la pantalla de


creación de partidas
Implementación y resultados 71

Figura 5.11: Capturas de pantalla de la aplicación móvil.


6 Conclusiones

En conclusión, se ha logrado completar en gran medida el objetivo principal de este


proyecto, esto es, la creación de una aplicación hı́brida sobre el juego de la Yincana. Re-
visando los objetivos especı́ficos que se nombraron en el apartado 1.1 de este documento,
se puede comprobar que se han cumplido la mayorı́a de ellos:

Creación de una aplicación multiplataforma que controle todo el juego. Esta aplica-
ción estará disponible en las tiendas de aplicaciones de las diferentes plataformas.

Uso del GPS del móvil para obtener la ubicación en tiempo real del jugador y poder
saber qué juegos hay activos en su zona. Además también permitirá determinar
cuándo un jugador ha llegado al punto de control correspondiente.

Integración del uso de una API de mapas en la aplicación multiplataforma para


mostrar los diferentes juegos que hay activos en el área del jugador.

Creación de una aplicación web en la que los administradores de los juegos podrán
crear y administrar los juegos de la yincana.

Integración del uso de una API de mapas en la aplicación web para poder definir
los puntos de control de cada partida que tiene recorrer cada jugador.

Creación de una API para poder enviar y recibir datos de los juegos a través de la
aplicación móvil.

Definición de pistas para los puntos de control que tienen que atravesar cada ju-
gador para acabar el juego por parte de los administradores.

Aumentar la seguridad del todo el sistema con la autenticación de los usuarios


mediante usuario y contraseña.

Aumentar la seguridad de toda la API mediante el uso de “tokens” de autenticación


que se enviarán al servidor con cada consulta que se haga a la API. De esta forma,
se incrementará la seguridad al no tener que enviar el usuario sus credenciales con
cada llamada a la API.

72
Conclusiones 73

En cuanto al diseño de la aplicación, se ha respetado en gran medida los bocetos


planteados en un principio, a pesar de realizar algún cambio en la interfaz para mejorar
la usabilidad de las aplicaciones.

Una de las mayores dificultades que he encontrado a la hora de realizar el proyecto fue
saber realmente lo que tenı́a que hacer. Después de profundizar en el juego de la yincana,
y como se puede comprobar en el capitulo 2 dedicado al estudio del arte, el juego de la
yincana es un juego muy fácil y por eso se puede confundir con otros juegos similares
como la búsqueda del tesoro, las carreras de orientación, el geocaching... Esto hace que
en un primer momento no tenı́a muy claro que debı́a hacer ya que se las fronteras entre
un juego y otro estaban un poco difusas. De hecho tengo la convicción de que estos
juegos no son más que variantes de una yincana que han ido evolucionando y cogiendo
personalidad propia.

Una vez superado este escollo y habiendo definido los objetivos que querı́a que tuviera
el juego, el desarrollo se simplificó bastante. El único problema adicional que surgió fu
aprender a utilizar la API de Google Maps, que en un principio resulta un poco difı́cil
pero se va simplificando con forme vas profundizando en su estudio.

A nivel personal, los objetivos principales del autor, se han cumplido. Se ha creado
un sistema que utiliza el GPS y los mapas de terceros para geolocalizarte que puede
servir de base a proyectos futuros que tengan requisitos similares. Además, este trabajo
ha servido para reforzar los conocimientos adquiridos durante el máster, ası́ como para
adquirir nuevas capacidades avanzadas en el desarrollo de este tipo de aplicaciones.

De cada al futuro se plantea completar los objetivos avanzados que se definieron en el


apartado 1.1 de este documento:

Añadir la posibilidad de desbloqueo de logros y el uso de marcadores para crear


rankings de puntuación entre los distintos usuarios del juego.

Visualización de rankings y logros en la aplicación móvil una vez que el jugador


haya completado el juego.

Visualización de rankings y logros de cada jugador que haya completado el juego


por parte de los administradores en la aplicación web.
Bibliografı́a

[1] Artemis gymkhanas. https://gymkhana-barcelona.com/es/


nuestras-gymkhanas/. Accessed: 2022-09-11.

[2] Diccionario de la lengua española - real academia española. https://dle.rae.es.


Accessed: 2022-09-11.

[3] Buscador google. https://www.google.es. Accessed: 2022-09-11.

[4] Team building. https://es.wikipedia.org/wiki/Team_building. Accessed:


2022-09-11.

[5] Geocaching o gymkhana gps - wikipedia. https://es.wikipedia.org/wiki/


Geocaching. Accessed: 2022-09-11.

[6] Grupo de noticias o newsgroup - wikipedia. https://es.wikipedia.org/wiki/


Grupo_de_noticias. Accessed: 2022-09-11.

[7] Grupo de geocaching a nivel mundial. https://www.geocaching.com/play. Ac-


cessed: 2022-09-11.

[8] Grupo de geocaching de españa. http://www.geocachingspain.es. Accessed:


2022-09-11.

[9] Ludificación del aprendizaje - wikipedia. https://es.wikipedia.org/wiki/


Ludificacin_del_aprendizaje. Accessed: 2022-09-11.

[10] Federación internacional de orientación. https://orienteering.sport. Accessed:


2022-09-11.

[11] Federación española de orientación. https://www.fedo.org/web/. Accessed: 2022-


09-11.

[12] Google play. https://play.google.com/store/apps. Accessed: 2022-09-11.

74
Bibliografı́a 75

[13] App store de apple. https://www.apple.com/es/app-store/. Accessed: 2022-09-


11.

[14] Web de goosechase. https://www.goosechase.com. Accessed: 2022-09-11.

[15] Web de scavify. https://www.scavify.com. Accessed: 2022-09-11.

[16] Scavify en la play store de google. https://play.google.com/store/apps/


details?id=com.scavify.app. Accessed: 2022-09-11.

[17] Groundspeak, inc. https://g.co/kgs/FTyvCC. Accessed: 2022-09-11.

[18] c:geo - web. https://www.cgeo.org. Accessed: 2022-09-11.

[19] c:geo en google pay. https://play.google.com/store/apps/details?id=cgeo.


geocaching&hl=es&gl=US. Accessed: 2022-09-11.

[20] Cachly geocaching en la app store. https://apps.apple.com/es/app/


cachly-geocaching/id645384141. Accessed: 2022-09-11.

[21] Geocaches en la app store. https://apps.apple.com/es/app/geocaches/


id536646724. Accessed: 2022-09-11.

[22] Metodologı́a scrum. https://www.scrum.org. Accessed: 2022-09-11.

[23] Metodologı́a en cascada. https://es.wikipedia.org/wiki/Desarrollo_en_


cascada. Accessed: 2022-09-11.

[24] Kanban. https://es.wikipedia.org/wiki/Kanban. Accessed: 2022-09-11.

[25] Visual studio code - web. https://code.visualstudio.com. Accessed: 2022-09-11.

[26] Git - web. https://git-scm.com. Accessed: 2022-09-11.

[27] Bitbucket - web. https://bitbucket.org/. Accessed: 2022-09-11.

[28] Sourcetree - web. https://www.sourcetreeapp.com. Accessed: 2022-09-11.

[29] Xampp - apache friends web. https://www.apachefriends.org/es/index.html.


Accessed: 2022-09-11.

[30] Apache webserver - web. https://httpd.apache.org. Accessed: 2022-09-11.


Bibliografı́a 76

[31] Mariadb - web. https://mariadb.org. Accessed: 2022-09-11.

[32] Mysql - web. https://www.mysql.com. Accessed: 2022-09-11.

[33] Proftpd - web. http://www.proftpd.org. Accessed: 2022-09-11.

[34] Php - web. https://www.php.net. Accessed: 2022-09-11.

[35] phpmyadmin - web. https://www.phpmyadmin.net. Accessed: 2022-09-11.

[36] Datagrip - web. https://www.jetbrains.com/es-es/datagrip/. Accessed: 2022-


09-11.

[37] Adnroid studio - google developer web. https://developer.android.com/studio.


Accessed: 2022-09-11.

[38] Xcode - apple developer web. https://developer.apple.com/xcode/. Accessed:


2022-09-11.

[39] Zsh - web. https://www.zsh.org. Accessed: 2022-09-11.

[40] Información detallada del macbook pro de 13 pulgadas del 2017. https://support.
apple.com/kb/SP755?locale=es_ESm. Accessed: 2022-09-11.

[41] Información detallada del procesador intel core i5 7267u.


https://www.intel.es/content/www/es/es/products/sku/97528/
intel-core-i57267u-processor-4m-cache-up-to-3-50-ghz/
specifications.html. Accessed: 2022-09-11.

[42] Información detallada del samsung s7. https://www.kimovil.com/es/


donde-comprar-samsung-galaxy-s7-eu. Accessed: 2022-09-11.

[43] Página oficial de laravel. https://laravel.com. Accessed: 2022-09-11.

[44] Framework - wikipedia. https://es.wikipedia.org/wiki/Framework. Accessed:


2022-09-11.

[45] Página oficial de ruby on rails. https://rubyonrails.org. Accessed: 2022-09-11.

[46] Página oficial de sinatra. https://sinatrarb.com. Accessed: 2022-09-11.

[47] Página oficial de asp.net mvc. https://dotnet.microsoft.com/en-us/apps/


aspnet/mvc. Accessed: 2022-09-11.
Bibliografı́a 77

[48] Página oficial de symfony. https://symfony.com. Accessed: 2022-09-11.

[49] Página oficial de composer. https://getcomposer.org. Accessed: 2022-09-11.

[50] Página oficial de ionic framework. https://ionicframework.com. Accessed: 2022-


09-11.

[51] Página oficial de apache cordova. https://cordova.apache.org. Accessed: 2022-


09-11.

[52] Página oficial de capacitator. https://capacitorjs.com. Accessed: 2022-09-11.

[53] Página oficial de angular. https://angular.io. Accessed: 2022-09-11.

[54] Página oficial de typescript. https://www.typescriptlang.org. Accessed: 2022-


09-11.

[55] Página de mozilla de javascript. https://developer.mozilla.org/es/docs/Web/


JavaScript. Accessed: 2022-09-11.

[56] Página de google maps. https://www.google.es/maps. Accessed: 2022-09-11.

[57] Api google maps. https://developers.google.com/maps?hl=es-419. Accessed:


2022-09-11.

[58] AENOR. norma une 50136:1997., 1997.

[59] Isaac Newton. Newton’s Principia: the mathematical principles of natural philo-
sophy. First American edition, 1 edition, 1846.

[60] Balsamiq. https://balsamiq.com/. Accessed: 2018-04-10.

[61] Escape rooms - wikipedia. https://es.wikipedia.org/wiki/Escape_room. Ac-


cessed: 2022-09-11.

[62] Goosechase en la play store de google. https://play.google.com/store/apps/


details?id=com.goosechaseadventures.goosechase. Accessed: 2022-09-11.

[63] Geocaching en la app store de apple. https://apps.apple.com/app/


apple-store/id329541503. Accessed: 2022-09-11.

[64] Scavify en la play store de google. https://play.google.com/store/apps/


details?id=com.groundspeak.geocaching.intro. Accessed: 2022-09-11.
Bibliografı́a 78

[65] Opencaching quickfind. https://play.google.com/store/apps/details?id=


net.rygielski.roadrunner&hl=es_419&gl=US. Accessed: 2022-09-11.

[66] Opencaching de garmin. https://www.garmin.com/es-ES/blog/


garmin-crea-una-aplicacion-de-opencachingcom-para-su-uso-en-telefonos-moviles/.
Accessed: 2022-09-11.

[67] Opencaching network. https://www.opencaching.de. Accessed: 2022-09-11.

También podría gustarte