Facultad

de
Ciencias

Desarrollo de una aplicación móvil de realidad

virtual para el aprendizaje en las aulas
Development of a virtual reality mobile
application for classroom learning

Trabajo de Fin de Grado

para acceder al

GRADO EN INGENIERÍA INFORMÁTICA

Autor: Guillermo Cobo Fernández

Director: Carlos Blanco Bueno

Co-Director: Juan Antonio Pila Fernández

Junio – 2017
2
ÍNDICE DE CONTENIDO
Resumen ................................................................................................. 5
Abstract.................................................................................................... 6
Indice de figuras ...................................................................................... 7
Indice de tablas ........................................................................................ 8
1. Introducción .................................................................................... 9
1.1. Estado del arte: realidad virtual ................................................ 9
1.2. Estado del artE....................................................................... 13
1.3. Motivación .............................................................................. 14
1.4. Objetivos ................................................................................ 15
2. Material y tecnología utilizada....................................................... 15
2.1. Herramientas.......................................................................... 15
2.1.1. Unity 3D.............................................................................. 15
2.1.2. Blender ............................................................................... 18
2.1.3. Adobe Photoshop CC ......................................................... 18
2.1.4. Monodevelop ...................................................................... 19
2.1.5. Unity Remote ...................................................................... 20
2.1.6. Cámara Ricoh Theta S ....................................................... 21
2.1.7. Project 2016 ....................................................................... 21
2.1.8. Draw.io ............................................................................... 21
2.1.9. Balsamiq Mockups ............................................................. 22
2.1.10. XMLSpy ............................................................................ 22
2.2. Tecnología ............................................................................ 22
2.2.1. C# ....................................................................................... 22
2.2.2. XML .................................................................................... 22
2.2.3. Google VR SDK For Unity .................................................. 22
2.2.4. Android SDK ....................................................................... 23
3. Metodología .................................................................................. 23
3.1. Planificación ........................................................................... 24
4. Análisis de requisitos .................................................................... 25
4.1. Requisitos funcionales ........................................................... 25
4.2. Requisitos no funcionales ...................................................... 26
5. Diseño e implementación ............................................................. 27
5.1. Arquitectura del sistema ......................................................... 27
5.2. Capa de presentación ............................................................ 29
5.2.1. Diagrama de flujo de navegación ....................................... 30
5.3. Capa de negocio .................................................................... 34
5.3.1. Diagrama de clases ............................................................ 38
5.4. Capa de datos ........................................................................ 40
5.4.1. Paseos ............................................................................... 40
5.4.2. Entornos del paseo............................................................. 42
5.4.3. Sugerencias ....................................................................... 43
6. Evaluación y pruebas ................................................................... 44
6.1. Pruebas unitarias ................................................................... 44
6.2. Pruebas de integración .......................................................... 46
6.3. Pruebas de sistema ............................................................... 46
6.3.1. Pruebas de rendimiento ..................................................... 46

3
 6.3.2. Pruebas de usabilidad ........................................................ 47
6.4. Pruebas de aceptación .......................................................... 49
7. Conclusiones y trabajos futuros .................................................... 51
7.1. Conclusiones.......................................................................... 51
7.2. Trabajos futuros ..................................................................... 52
Bibliografía ............................................................................................. 53

4
RESUMEN
Con el auge y la múltiple creación dispositivos de realidad virtual este
próximo año, vamos a vivir un salto tecnológico considerable en nuestra
sociedad. La repercusión de estos sistemas va a ser inmensa en su comienzo y
todos los sectores de la sociedad se van a ver beneficiados de una u otra
manera por esta tecnología, por ejemplo, en el ámbito de la educación o la
industria.

El objetivo de este proyecto es el desarrollo de una aplicación de

realidad virtual que permita la visita interactiva de diferentes espacios tales
como museos, monumentos, cuevas prehistóricas o enclaves turísticos desde
plataformas móviles y en cualquier lugar del mundo a través de unas sencillas
gafas “Cardboard”.

A su vez es importante destacar las infinitas posibilidades educacionales

que generará la aplicación en el sector formativo donde alumnos de colegios e
institutos podrían estudiar de manera inmersiva la historia de España a través
de la visita a enclaves físicos sin desplazarse de su aula.

La tecnología utilizada para desarrollar la aplicación es Unity que

además de permitir un desarrollo multiplataforma es capaz de trabajar
conjuntamente con productos audiovisuales. Además, se hace un estudio sobre
cuál es el estado de la Realidad Virtual y las herramientas capaces de
proporcionarla.

Palabras clave: Realidad virtual, Unity, Android, aplicación móvil,

educacional.

5
ABSTRACT
With the boom and the diverse creation of virtual reality devices this
coming year, we will live a considerable technological leap in our society. The
impact of these systems will be immense and all sectors of society will benefit in
some way through this technology, for example in the field of education or
industry.

The target of this project is the development of a virtual reality application

that allows the interactive visit of differents spaces such as museums,
monuments, prehistoric caves or tourist enclaves from mobile platforms and
anywhere in the world through some glasses “Cardboard”.

It is important to emphasize the infinite educational possibilities that the

application will generate in the educational sector, where students could
inmersively study the Spain history through the visit to enclaves without moving
from their classrooms.

The used technology to develop the application is Unity, which in addition

to allow multiplatform development, it is able to work in cooperation with
audiovisual products. And besides, a study is made about which Virtual Reality
state is and the tools capable of providing it.

Keywords: Virtual Reality, Unity, Android, mobile app, educational.

6
INDICE DE FIGURAS
Figura 1. Estereoscopio de Wheatstone ................................................ 10
Figura 2. Sword of Damocles................................................................. 11
Figura 3. Sistema "Vived" ...................................................................... 12
Figura 4. De izquierda a derecha: Google Cardboard, Samsung Gear VR
......................................................................................................................... 13
Figura 5. Dispositivos con pantalla incorporada .................................... 13
Figura 6. Logo de Unity.......................................................................... 16
Figura 7. Interfaz de usuario de Unity .................................................... 17
Figura 8. Interfaz de Blender ................................................................. 18
Figura 9. Interfaz de Photoshop ............................................................. 19
Figura 10. Interfaz de Monodevelop ...................................................... 20
Figura 11. Unity Remote ........................................................................ 20
Figura 12. Cámara Ricoh Theta S ......................................................... 21
Figura 13. Fases de metodología iterativa e incremental ...................... 23
Figura 14. Diagrama de Gantt ............................................................... 25
Figura 15. Arquitectura 3 capas utilizada ............................................... 28
Figura 16. Diagrama de componentes de la arquitectura ...................... 28
Figura 17. Diagrama de flujo de navegación de las escenas................. 30
Figura 18. Mockup de la escena menú principal .................................... 32
Figura 19. Mockup de la escena del formulario de sugerencias ............ 32
Figura 20. Mockup de la escena menú de selección de entorno ........... 33
Figura 21. Mockup de la escena del paseo virtual ................................. 34
Figura 22. Eventos Gaze Pointer ........................................................... 35
Figura 23. Evento que se ejecuta .......................................................... 36
Figura 24. Reconocimiento del gesto .................................................... 37
Figura 25. Carga de las sugerencias del buzón de sugerencias ........... 38
Figura 26. Diagrama de clases .............................................................. 38
Figura 27. Estructura de los paseos ...................................................... 40
Figura 28. Datos del fichero XML paseos .............................................. 41
Figura 29. Esquema del fichero XML paseos ........................................ 41
Figura 30. Estructura de los entornos de los paseos ............................. 42
Figura 31. Esquema de los entornos de los paseos .............................. 43
Figura 32. Estructura de las sugerencias............................................... 43
Figura 33. Esquema de las sugerencias ................................................ 44
Figura 34. Pruebas unitarias ejemplo 1 ................................................. 45
Figura 35. Pruebas unitarias ejemplo 2 ................................................. 45
Figura 36.Pruebas unitarias ejemplo 3 .................................................. 46
Figura 37. Gráfica de resultados de pruebas de aceptación.................. 50

7
INDICE DE TABLAS

Tabla 1. Requisitos Funcionales ............................................................ 26

Tabla 2. Requisitos No Funcionales ...................................................... 27

8
1. INTRODUCCIÓN

En los últimos años, los dispositivos móviles han pasado a ser una parte
esencial de nuestra vida. Las grandes compañías han apostado fuerte en el
desarrollo de estos dispositivos y esto ha significado un aumento exponencial
de sus características técnicas en los últimos años. Los denominados
Smartphone ya no son solo aparatos de comunicación, sino que son pequeños
ordenadores de bolsillo que nos acompañan a todas partes. En este mercado
de teléfonos móviles, la tecnología también se ha incrementado y diversificado
llegando a tener varios sistemas operativos móviles en los terminales. Siendo
Android, el sistema operativo móvil con más cuota de mercado mundial [1].

Entre todas las características que se podrían destacar de estos

dispositivos, cabe destacar la disponibilidad de sensores, como el giroscopio
que sirve para controlar la posición del celular, ayuda a medir, cambiar y
mantener la orientación de un Smartphone y así establecer una mejor posición
del equipo, o el acelerómetro que sirve para medir la aceleración del teléfono.

Gracias a estos sensores, se puede hacer uso de la realidad virtual en

los teléfonos móviles y crear en el usuario una sensación de estar inmenso en
un entorno de escenas u objetos de apariencia real. La aplicación de la realidad
virtual, está centrada inicialmente en el terreno del entretenimiento y de los
videojuegos, aunque se ha extendido a otros muchos campos, como la
educación.

Además, el grado de penetración de los dispositivos tipo Smartphone en

nuestra sociedad actual hace que gran cantidad de alumnos dispongan de
teléfonos inteligentes mediante los cuales se puede tener acceso a
aplicaciones, internet o visualizar contenidos. Aprovechando esto, los alumnos
podrían hacer uso de sus propios teléfonos móviles para acceder a
aplicaciones o plataformas con fines educativos.

El uso de las aplicaciones en la educación [2], está cogiendo mucha

importancia debido a la innovación que proporciona a los centros o la
motivación que suscita en los alumnos. Sumando que las actividades
socioculturales en la educación son un importante recurso didáctico, se debería
considerar las aplicaciones de realidad virtual, como una herramienta de gran
utilidad en el aula y que puede suponer una revolución en la metodología
empleada para la enseñanza. Por ejemplo, realizar una visita a un museo sin
tener que salir del aula, haciendo uso de toda esta tecnología comentada
anteriormente.

1.1. ESTADO DEL ARTE: REALIDAD VIRTUAL

La realidad virtual [4] es un entorno de escenas u objetos de apariencia

real, que crea en el usuario una sensación de estar inmenso en el propio
entorno. Para disfrutar de dicho entorno se necesitan unos dispositivos

9
conocidos como gafas de realidad virtual. Por lo tanto, el punto clave de esta
tecnología, es la eliminación de la frontera existente entre realidad e irrealidad
en un entorno no real.

Además, para mejorar esta experiencia se pueden usar otros

dispositivos acompañando a los anteriores, por ejemplo, trajes o guantes, que
contienen diversos sensores y perciben estímulos para intensificar la sensación
de realidad.

Este concepto no es ni mucho menos nuevo. Antes de los años 50 ya se

hablaba, con ilustraciones, textos, proyectos e ideas refiriéndose a una realidad
alternativa, y con máquinas que simulaban viajes a gente a mundos
desconocidos. Por lo que ya desde un principio, se presentó la realidad virtual
como sumergir al usuario en un mundo alternativo y permitiendo interactuar con
el entorno.

Si nos vamos bastante atrás [5], antes de la invención de los

ordenadores, ya en el siglo XIX se creaban murales panorámicos (o murales
360º) cuya idea era ocupar completamente el campo de visión del observador
con el cuadro, de tal forma que este tuviera la sensación de estar presenciando
el momento histórico representado. En 1983, Charles Wheatstone demostró
que el cerebro procesaba las dos imágenes bidimensionales de cada ojo en
una sola imagen tridimensional.

Partiendo de esa idea, Wheatstone creó el estereoscopio, el cual

consistía en un visor con dos fotografías, una para cada ojo, que habían sido
tomadas en el mismo momento, pero con unos puntos de toma diferentes,
generando una sensación de profundidad en la imagen.

Figura 1. Estereoscopio de Wheatstone

En 1929, se crea el primer “Link Trainer”, que era un simulador de vuelo

mecánico. Más de 500.000 norteamericanos fueron entrenados en simuladores
basados en este modelo durante la 2º Guerra mundial. Un año más tarde, una
novela de ciencia ficción “Pygmalion’s Spectacles” de Stanley G. Weinbaum,
contiene ya la idea de unas gafas de realidad virtual que permiten al usuario
experimentar un mundo de ficción a través de todos sus sentidos.

10
 Cerca de los años 60, la empresa Philco Corporation crea un casco de
realidad virtual que utiliza los movimientos de la cabeza del usuario para
realizar los desplazamientos. El invento fue creado con la idea de ser utilizado
por el ejército para la visualización de situaciones peligrosas de forma remota.

Llegando a 1965, Ivan Sutherland describe el concepto de realidad

virtual en un dispositivo de inmersión definitivo, en un artículo titulado “The
Ultimate Display”. En este, se describía el dispositivo como uno en el que se
simulaba la realidad de tal forma que fuera imposible de distinguirlo de lo real,
dando también la posibilidad al usuario de interactuar con objetos de este
mundo virtual.

En los años siguientes, apareció otro proyecto relevante. En 1968 se

desarrolló el llamado “Sword of Damocles”, creado por Ivan Sutherland y Bob
Sproull. Consistía en un HMD de realidad virtual desde el que se podían
visualizar gráficos generados por un ordenador. Pese a todo, los gráficos eran
muy básicos ya que aún no se disponía de la suficiente tecnología ni a nivel de
hardware, ni de software. La mejora en los gráficos 3D en ordenadores, sería
desarrollada más adelante por los militares en simuladores de vuelo y
posteriormente por la industria del videojuego que no hizo su aparición hasta la
década de los 70.

Figura 2. Sword of Damocles

A lo largo de las dos décadas siguientes, la investigación en realidad

virtual se empezó a acelerar. Se crearon guantes y diversos sistemas añadidos
para interactuar con ambientes virtuales. Ejemplos de esto, se produjeron en
1977 con los “Sayre Glove” por Tom Defanti y Daniel Sandin, que permitían
calcular lo flexionados que se tuvieran los dedos. Posteriormente, los guantes
de Gary Grimes, en 1983, que disponían de sensores de flexión en los dedos,
táctiles en las yemas y de orientación y posición en la muñeca.

Un avance importante en los HMD sucedió el 1985. Mc Greevy y Jim

Humphries junto con la NASA, desarrollaron el sistema “Vived” (Visual
Environment Display system). Fue el primer proyecto que intentó crear un HMD
de bajo coste dotado con visón estereoscópica, estéreo y sensores de
orientación.

11
 Figura 3. Sistema "Vived"

En los años 90, la realidad virtual se hizo mucho más popular. En el

ámbito del cine, se estrenaba la película “El cortador del césped”. Además,
varias empresas de videojuegos como Sega VR o Nintendo dieron un nuevo
empujón a este mundo, lanzando unos cascos para transportar al usuario al
interior de los videojuegos. Sin embargo, las gafas de SEGA nunca salieron al
mercado por problemas técnicos y las de Nintendo acabaron siendo un fracaso.

En 2000, Google innovo con su Street View en los contenidos de la

realidad virtual, que permite ver en 360 grados varias calles de una ciudad y
moverse por ellas. Sin embargo, fue en 2010 cuando todo cambió, Palmer
Luckey, diseñó la primera versión de las Oculus Rift, un casco de realidad
virtual con un ángulo de visión de 90 grados. Tal fue su éxito y las posibilidades
que había, que despertó el interés de varios ingenieros y empresas.

Grandes empresas del sector se pusieron a diseñar dispositivos de

realidad virtual. Google saco las “Google Cardboard”, un HMD con estructura
de cartón, que usa la pantalla de un Smartphone con estereoscopia por
software para el visionado y sensores del dispositivo para determinar la
posición. Samsung sacaría el Samsung Gear VR una versión de más calidad
para dispositivos Samsung. Sony sacaría las PlayStation VR para su consola
PlayStation 4. O Microsoft que ha desarrollado las “HoloLens” desde Windows
a los diversos videojuegos de su consola.

En el mercado actualmente existen dos tipos de gafas de realidad virtual:

 Las que no tienen un visor incorporado, por lo que necesitan un móvil, que
contenga los sensores de giroscopio y acelerómetro.

12
 Figura 4. De izquierda a derecha: Google Cardboard, Samsung Gear VR

 Los cascos de VR (HMD) con pantallas incluidas, que contienen los

sensores.

Figura 5. Dispositivos con pantalla incorporada

Debido a la popularización de las plataformas “Crowdfounding”

(Plataformas online que financian proyectos de personas u organizaciones),
muchos otros desarrolladores independientes han empezado a crear
dispositivos relacionados con el área y se espera que salgan a la venta una
gran cantidad de productos de realidad virtual. Claramente, la realidad virtual
está de moda, al menos por el momento.

1.2. ESTADO DEL ARTE

En la actualidad, con el auge de la tecnología de la realidad virtual, cada
vez están dándose a conocer muchas más aplicaciones o juegos, para
Smartphone.

La mayoría de las aplicaciones de realidad virtual en los Smartphone, su

funcionalidad principal es el entretenimiento para vivir experiencias reales,
como, por ejemplo, una montaña rusa o nadar con tiburones. Las aplicaciones
más famosas son VRSE, donde el usuario puede experimentar escenarios
hiperrealistas, Jaunt VR, contiene una gran variedad de videos en 360º grados
de todo tipo, o Google Cardboard, donde encontraras la iniciación perfecta para
dar tus primeros pasos en la realidad virtual.

A parte del entretenimiento, hay muchas aplicaciones en muchos otros

ámbitos como en la industria, las cuales permiten a los operarios experimentar

13
situaciones de riesgo realistas en primera persona, mejorando la detección de
riesgos, en la medicina, para la formación de médicos y enfermeras en
situaciones de entrenamiento donde tienen que interactuar con un paciente, o
para el tratamiento de fobias de pacientes.

En el ámbito las aplicaciones educativas en los entornos socioculturales,

de momento no ha cogido mucha importancia. Sin embargo, expertos dicen
que la continua e inexorable evolución de las tecnologías, producen nuevos
avances y nuevas formas de entender la educación en la actualidad. Existen
aplicaciones cuya función es similar, como, New York Times VR, que permiten
conocer historias y noticias en 360º.

En el caso de las aplicaciones móviles educativas de realidad virtual

para entornos socioculturales, no se ha hecho uso de estas tecnologías
conjuntamente. Pero se está empezando a dar interés, debido a sus criterios
pedagógicos, al proporcionar motivación, participación, interés e interacción en
los alumnos, al usar estas tecnologías.

1.3. MOTIVACIÓN
En la actualidad, la realidad virtual es una tecnología que está muy
presente y que está suponiendo una auténtica revolución, puede suponer un
antes y un después en muchos sectores como la educación, la medicina o la
industria. Por ello en este proyecto se va a apostar por esta nueva tecnología
que cambia la forma en la que el usuario interacciona con los sistemas de
información.

Habría que resaltar que las actividades socioculturales, en el campo de

la educación, no usan estas tecnologías y se está empezando a incrementar el
interés en este ámbito con la realidad virtual. Por tanto, estas actividades se
podrían beneficiar dando a los usuarios la posibilidad de conocer y visitar
virtualmente un museo o un parque, proporcionando una función de
aprendizaje a la vez de diversión, y añadiendo un interés mayor en los
usuarios.

Mis principales motivaciones personales para llevar a cabo este proyecto

son la creación de una aplicación con esta tecnología conocida a la vez que
nueva para mí, la posibilidad de que usuarios reales puedan disfrutar del
trabajo al ser un proyecto real que no quedará guardado en un cajón, la
utilización de una de las plataformas de desarrollo más completas y más
famosas que existen como es Unity 3D, y el interés en trabajar en un futuro en
esta área laboral, ya que esta industria ha crecido de manera muy elevada
estos últimos años. Siendo unos de los sectores actualmente en cabeza,
trabajando para diferentes dispositivos como consolas, móviles u ordenadores.

Además, la motivación se incrementaba sabiendo que no hay ideas

iniciales o precedentes anteriores realizadas por otros alumnos del Grado de
Informática de la Universidad de Cantabria. Sin embargo, se ha podido contar

14
con ideas realizadas en otras aplicaciones con otros fines, adaptando esa
información a este proyecto.

Finalmente, para recalcar, esta motivación personal no es simplemente

la de crear un sistema, si no la de ahondar tanto en estos conceptos que, a
pesar de que ya han sido mencionados en el transcurso de la carrera, me
gustaría haber podido practicar e indagar más en profundidad.

1.4. OBJETIVOS
El objetivo principal de este proyecto es desarrollar una aplicación para
el entorno educativo mediante el sistema operativo Android, que permita a los
alumnos estar inmersos en un entorno sociocultural virtual sin salir de sus
aulas. Pudiendo interactuar con objetos del entorno, aportando y cumpliendo
una función educativa además de entretenimiento y diversión. Para la creación
de los entornos virtuales, se hace uso de la tecnología de Realidad virtual, y los
usuarios pueden disfrutar de una buena experiencia a través de unas gafas de
realidad virtual, en este caso “Cardboard”. Además, los usuarios no necesitan
hacer uso de los botones que proporcionan determinadas gafas de realidad
virtual, ya que toda, la interacción se hace con el movimiento de la cabeza y la
mirada fija a un objeto.

En base al objetivo principal, se plantean los siguientes objetivos

parciales:

 Estudiar el estado de las distintas tecnologías que intervienen en la creación

de la aplicación.

 Diseño de una interfaz intuitiva para facilitar el uso de aplicación y la

interacción de los usuarios con el entorno.

 Programación de todas las funcionalidades de la aplicación.

2. MATERIAL Y TECNOLOGÍA UTILIZADA

En este capítulo se expondrán las herramientas y tecnologías utilizadas
en el desarrollo del proyecto.

2.1. HERRAMIENTAS
2.1.1. UNITY 3D

Unity3D [8] es un motor de videojuego multiplataforma creado por Unity

Technologies, que permite crear aplicaciones o juegos para Windows, Android,
PlayStation 4, WebGL o Switch, entre muchos. Además, este software tiene

15
una versión gratuita y una versión Pro de pago, que incorpora funcionalidades
que la versión gratuita no posee.

Figura 6. Logo de Unity

Unity tiene muchas ventajas en comparación con otros motores de

desarrollo, como poder compilar el mismo proyecto en varias plataformas o su
sencilla interfaz y fácil manejo, sin embargo, las que más destacan son:

 Su gran documentación [9] (tanto en inglés como en español) para distintos

lenguajes de programación (C#, JavaScript y Boo) y numerosos tutoriales.

 La comunidad de Unity [10], donde se puede obtener ayuda y analizar

soluciones con usuarios experimentados de Unity. Esta proporciona cuatro
herramientas:

 Foro: Son el eje central de los debates y charlas de la comunidad,

donde puedes expresar tu opinión y puedes contactar con otros
desarrolladores de Unity.

 Answers: Es la herramienta para preguntas y respuestas concretas

en relación con Unity, donde tanto principiantes como expertos
pueden publicar y ayudarse unos a otros por igual.

 Issue Tracker: Es la herramienta para obtener información clara

acerca del estado de los errores que se han reproducido con éxito.

 Feedback: En el foro de Feedback se puede hacer saber que

deseos se quieren incluir en versiones futuras, y votar por esas ideas
de todo el mundo.

 Los Assets [11], son paquetes ya desarrollados que realizan distintas

funcionalidades, desde juegos completos hasta el controlador del jugador,
que permiten utilizarlos sin necesidad de programarlos uno mismo,
ahorrando tiempo.

Todas estas ventajas y características, hace a Unity3D una de las

plataformas más utilizadas y potentes en la actualidad a la hora de desarrollar
videojuegos, y cada vez más en el ámbito específico de Android.

La interfaz de usuario de Unity, como se puede ver en la imagen

siguiente, está separada principalmente de 8 ventanas o secciones más
importantes:

16
 Figura 7. Interfaz de usuario de Unity

1. Es una parte de la barra de herramientas que contiene los controles de

reproducción para ejecutar o parar el proyecto.

2. La ventana de jerarquía es una representación de texto jerárquico de cada

objeto en la escena (donde se encuentran los objetos de la escena actual).
Cada elemento en la escena tiene una entrada en la jerarquía. La jerarquía
también sirve como método rápido y fácil para seleccionar objetos en la
escena.

3. Muestran las características y/o componentes del objeto seleccionado,

como atributos o scripts que dan funcionalidad a los objetos. Además de
mostrar la información, esta también puede ser modificada a nuestro gusto
tanto en tiempo de ejecución como en tiempo normal, o se puede añadir y
eliminar estos componentes.

4. En esta ventana/vista es donde se construye visualmente nuestro juego o

aplicación, donde se pueden modificar, mover o rotar los objetos de la
escena.

5. Muestra cómo se verá la aplicación o el juego al compilarse, hay que tener

cuidado con el AspectRatio o la resolución de pantalla elegida, dependiendo
de la plataforma sobre la que se desarrolle el proyecto.

6. Muestra la estructura del proyecto en Unity, en ella se muestran los Assets

que incluyen recursos a usar en las escenas.

7. Muestra los mensajes de error/debug.

8. Tienda donde se pueden comprar o descargar, pagando o gratuitamente,

los Assets creados por otros desarrolladores.

17
 2.1.2. BLENDER

Blender [12] es un programa de modelado en 3D y multiplataforma,

apoyado por varias herramientas. Fue creado por la empresa Not a Number
(NaN).

Está orientado a artistas y profesionales del diseño y multimedia. Puede

ser usado para crear visualizaciones 3D estáticas o vídeos de alta calidad.
También incorpora un motor de 3D en tiempo real el cual permite la creación de
contenido tridimensional interactivo que puede ser reproducido de forma
independiente.

Este programa se desarrolla como software libre, con el código fuente

disponible bajo la licencia GNU GPL, su descarga y su uso es completamente
gratuito.

Figura 8. Interfaz de Blender

En este proyecto, se ha utilizado Blender para la creación de la esfera

con los polígonos invertidos. Debido a que la esfera de Unity, con la cámara
solo se pueden ver los polígonos de la cara externa. Por lo que se invirtió los
polígonos de la esfera, para poner la textura de la imagen de 360º y meter la
cámara dentro de la esfera.

2.1.3. ADOBE PHOTOSHOP CC

Adobe Photoshop [13] es un editor de gráficos rasterizados desarrollado

por Adobe Systems Incorporated.

Usado principalmente para el retoque de fotografías y gráficos, su

nombre en español significa literalmente "taller de fotos". Es líder mundial del
mercado de las aplicaciones de edición de imágenes y domina este sector de
tal manera que su nombre es ampliamente empleado como sinónimo para la
edición de imágenes en general.
18
 Figura 9. Interfaz de Photoshop

Antes de realizar la importación de las imágenes 360º que componen la

parte grafica de la aplicación, ha sido necesario la utilización de este editor de
imagen. El tratamiento realizado sobre las imágenes de partida, ha sido la
eliminación de la base del trípode y su sombra, mediante el uso del punto de
fuga en coordenadas polares.

2.1.4. MONODEVELOP

El desarrollo del código de la aplicación es llevado a cabo mediante el

IDE de Unity llamado Monodevelop [14]. Este entorno de desarrollo cuenta con
un depurador, autocompletado y compilador. Este IDE está basado en una
versión de software libre de .NET, el framework de Microsoft.

Monodevelop es un entorno multiplataforma que es compatible con

varios lenguajes, sim embargo, Unity admite los lenguajes C#, JavaScript y
Boo. Cada script puede ser codificado en el lenguaje que el programador
prefiera, por esto, hace que el desarrollo del juego sea mucho más ameno,
pudiendo el programador adaptar su código a distintos lenguajes según las
librerías que estos posean o la finalidad del código.

19
 Figura 10. Interfaz de Monodevelop

2.1.5. UNITY REMOTE

Unity Remote [15] es una app descargable diseñada para ayudar con el
desarrollo Android y iOS. La aplicación se conecta con Unity mientras estas
corriendo el proyecto en el modo de reproducción desde el editor. El output
visual desde el editor es enviado a la pantalla del dispositivo y unos inputs en
vivo son enviados de vuelta al proyecto ejecutándose en Unity.

Figura 11. Unity Remote

Este permite obtener una impresión de como se ve el juego realmente y

poder controlarlo remotamente, sin tener que hacer una construcción completa
del juego y la posterior instalación en el dispositivo.

20
 2.1.6. CÁMARA RICOH THETA S

Ricoh Theta S es una cámara de bolsillo (candybar) capaz de

capturar fotos y vídeos 360º gracias a dos cámaras gran angular montadas en
la parte frontal y trasera de la misma, que cubren 180º cada una (ojo de pez) y
dan imagen a cada sensor. Estos contenidos pueden ser vistos en un
ordenador, móvil e incluso con gafas de realidad virtual cambiando el punto de
vista según el movimiento de tu cabeza. Además, permite la retransmisión en
directo en alta definición.

Figura 12. Cámara Ricoh Theta S

Su finalidad en este proyecto, ha sido la creación de las imágenes 360º,

tanto videos como imágenes, para la creación del paseo virtual.

2.1.7. PROJECT 2016

Microsoft Project [16] es un software de administración de

proyectos, diseñado, desarrollado y comercializado por Microsoft para asistir a
administradores de proyectos en el desarrollo de planes, asignación de
recursos a tareas, dar seguimiento al progreso, administrar presupuesto y
analizar cargas de trabajo. Este software ha sido utilizado para la creación del
diagrama de Gantt.

2.1.8. DRAW.IO

Draw.io [17] es una increíble herramienta que nos permite elaborar

diagramas en línea sin necesidad de instalar absolutamente nada en nuestro
PC. Su interfaz es bastante sencilla y fácil de utilizar, además es tan completa
que nada tiene que envidiarle a cualquier software de pago para escritorio. Esta
herramienta ha sido utilizada para la creación de los diagramas.

21
 2.1.9. BALSAMIQ MOCKUPS

Balsamiq Mockups [18] es una herramienta que nos permite realizar

Wireframes fácilmente. Es una representación esquemática de la solución que
llevaremos adelante, sin entrar en etapas posteriores como el diseño gráfico o
la programación web. Podemos verlo como el esqueleto general visual de la
solución. Su finalidad ha sido la creación de los mockups.

2.1.10. XMLSPY

XMLSpy [19] el editor XML más vendido gracias a sus avanzadas

funciones de modelado, edición, transformación y depuración de tecnologías
XML, además de muchas otras funcionalidades. Al ser una aplicación de pago
se ha utilizado una versión de prueba de 30 días. En este proyecto, se ha
utilizado para generar esquemas de la estructura de un fichero XML a raíz de
su fichero de validación XSD.

2 .2 . TECNOLOGÍA
2.2.1. C#

Este proyecto se ha realizado exclusivamente con C# [20], es un lenguaje

de programación que se ha diseñado para compilar diversas aplicaciones que
se ejecutan en .NET Framework. C# es simple, eficaz, con seguridad de tipos y
orientado a objetos. Las numerosas innovaciones de C# permiten desarrollar
aplicaciones rápidamente y mantener la expresividad y elegancia de los
lenguajes de estilo de C.

Además, se ha elegido este lenguaje porque de los lenguajes que

proporciona Unity es el mejor y el que más capacidades tiene.

2.2.2. XML

XML [21] un lenguaje que permite la organización y el etiquetado de

documentos. Esto quiere decir que el XML no es un lenguaje en sí mismo, sino
un sistema que permite definir lenguajes de acuerdo a las necesidades. Para
resumir, es un lenguaje que se encarga de describir datos.

2.2.3. GOOGLE VR SDK FOR UNITY

El VR SDK de Unity [22] permite el desarrollo de aplicaciones que, con el

uso de las gafas, son capaces de mostrar imágenes en 3D que reaccionan ante
el movimiento de la cabeza. El imán de las Cardboard, colocado en el lateral,
permite interactuar con el Smartphone Android, modificando el comportamiento
22
de la brújula del teléfono y facilitando que la aplicación de realidad virtual
funcione correctamente sin tocar el dispositivo.

2.2.4. ANDROID SDK

Android SDK [23] es el kit de desarrollo de software con el cual es posible

desarrollar aplicaciones para dispositivos con el sistema operativo Android. Una
aplicación Android está compuesta por un conjunto de ficheros empaquetados
en formato. apk y guardada en el directorio /data/app del sistema operativo
Android.

Para poder publicar los proyectos de destinados a esta plataforma, Unity

3D, requerirá tener instalado el Android SDK. Las aplicaciones podrán ser
vendidas a través de Play Store propiedad de Google, los desarrolladores
reciben el 70% de los ingresos a través de Google check out.

3. METODOLOGÍA
Para realizar este proyecto, se ha utilizado una metodología de
desarrollo iterativa e incremental [7]. Este procedimiento permite planificar un
proyecto en distintos bloques temporales denominados iteración. Por lo tanto,
este tipo de metodología, nos va a permitir dividir nuestro proyecto en
diferentes etapas, que van a ser validadas al final de cada una. Se puede
comprobar que todos los resultados son los esperados sin la necesidad de
tener terminado nuestro software completamente, y se puede identificar
situaciones de error (o simplemente aplicar mejoras) en las fases ya
desarrolladas.

Figura 13. Fases de metodología iterativa e incremental

En el siguiente apartado, se explicará más detenidamente las fases e

iteraciones usadas en el proyecto.

23
 3.1. PLANIFICACIÓN
El proyecto está dividido principalmente en 3 fases, en la que una de
ellas, está dividida en iteraciones:

 Fase de formación

La primera fase consistirá en la instalación del material necesario y la

investigación y estudio de las herramientas, como la búsqueda de ejemplos,
tutoriales guiados o la realización de pruebas y ejemplos.

 Fase de desarrollo

La segunda fase consistirá en satisfacer los requisitos del proyecto, para lo

cual será necesario realizar iteraciones, generando un prototipo en cada
una de ellas para ir probándolo y mejorándolo de manera progresiva.
Durante el desarrollo del proyecto, el cual se dividió en 4 iteraciones, en
cada una va a haber varias fases:

 Análisis: Fase de análisis sobre qué hacer, cómo hacerlo, con qué
herramientas, limitaciones y objetivos a conseguir.

 Diseño: Diseño de la aplicación, tanto de las escenas como de las UI’s,

entre otros.

 Implementación: Desarrollo de la lógica de la aplicación.

 Pruebas: Fase en la que se comprueba el correcto funcionamiento de

las funcionalidades implementadas.

 Revisión

 Fase de integración de contenido

La última fase consistirá en la integración del material gráfico final y

asignación final de coordenadas de los objetos del entorno.

Al ser un caso real en una empresa, las fases de análisis y revisión se

realizaron mediante reuniones con el jefe del proyecto en las que se
determinaba los objetivos a seguir en el caso del análisis, y las conclusiones
finales es sobre las determinadas iteraciones del proyecto en el caso de la
revisión. Además, todas las revisiones fueron satisfactorias para el desarrollo
del proyecto.

Cada iteración comprende las fases indicadas, y se realizó una

planificación, un diagrama de Gantt, en la que se establecían las tareas
realizadas con sus determinados plazos de tiempo.

24
 Figura 14. Diagrama de Gantt

 Iteración 1

Esta etapa abarca el desarrollo de las escenas y funcionalidades previas

antes de llegar al menú principal. Como, por ejemplo, la escena del tutorial
o consejos.

 Iteración 2

Esta etapa abarca el desarrollo de las escenas y funcionalidades del menú

principal y elección del paseo virtual.

 Iteración 3

Esta etapa abarca el desarrollo del entorno del tour virtual.

 Iteración 4

Esta etapa abarca el desarrollo de nuevas funcionalidades que mejoraran el

producto final.

4. ANÁLISIS DE REQUISITOS
En este capítulo se presenta la fase de análisis, parte inicial de todo
proyecto software. Se muestra una especificación de requisitos detallada [7],
tanto los requisitos funcionales como los no funcionales.

4.1. REQUISITOS FUNCIONALES

En este apartado se estudia el problema y se acuerdan los requisitos
que se deben satisfacer. Los siguientes requisitos funcionales describen las
características que tiene que cumplir nuestro sistema.

Identificador Descripción
RF01 El sistema moverá la cámara siguiendo el movimiento de la
cabeza del usuario.
RF02 El puntero de la aplicación generara continuamente raycast,
que generarán eventos al colisionar con objetos válidos.

25
RF03 El sistema no se iniciará por completo si el dispositivo móvil no
dispone de sensor de giroscopio o la versión de Android es
menor que 5.1.
RF04 Las sugerencias se almacenarán en ficheros de datos XML.
RF05 El sistema debe representar el contenido gráfico y sugerencias
a partir de ficheros de datos XML.
RF06 El sistema generará dos imágenes desfasadas para que
nuestro cerebro las una y genere una única imagen
tridimensional, como la visión en el mundo real.
RF07 El sistema avisará al usuario de tomar un descanso, tras un
periodo de tiempo razonable usando la aplicación.
RF08 El sistema interpretará el gesto que hace el usuario con la
cabeza para avanzar a una escena u otra.
RF09 El usuario podrá hacer una captura de pantalla y compartirla
en sus redes sociales.
RF10 El usuario podrá configurar el volumen del sonido y el brillo del
entorno.
RF11 El usuario podrá realizar un tour virtual.
RF12 El usuario podrá elegir el paseo y el entorno a su gusto.
RF13 El usuario podrá ver información del entorno.
RF14 El usuario podrá ver videos del entorno y controlar su
reproducción.
RF15 El usuario podrá ver imágenes del entorno.
RF16 El usuario podrá ver imágenes 360 del entorno.
RF17 El usuario podrá salir de la aplicación en todo momento.
RF18 El usuario podrá ocultar/mostrar el contenido gráfico del
entorno cuando desee.
RF19 El usuario podrá ver y dejar sugerencias de la aplicación, en el
buzón del menú principal.
RF20 La aplicación no necesita de uso de Internet, por lo que se
puede usar en todo momento.
Tabla 1. Requisitos Funcionales

4.2. REQUISITOS NO FUNCIONALES

Los requisitos no funcionales son aquellos que sirven para indicar cómo
se ha de implementar la aplicación, y no lo que debe hacer, poniendo
restricciones en el diseño e implementación de la aplicación.

Id Tipo de Descripción Importancia

requisito
RNF01 Portabilidad El sistema solo se podrá Alta
ejecutar en el sistema
operativo Android.
RNF02 Compatibilidad El sistema se deberá ejecutar Media
en una versión de Android
mayor o igual a 5.1.

26
RNF03 Rendimiento El sistema deberá ofrecer un Alta
buen rendimiento, cargando y
respondiendo a las acciones
del usuario en un mínimo de 1
segundo.
RNF04 Rendimiento El sistema deberá funcionar a Alta
más de 30 FPS.
RNF05 Interfaz La aplicación debe ser fácil e Media
intuitiva.
RNF06 Hardware El sistema necesita que el Alta
móvil disponga de los
sensores de giroscopio y
acelerómetro.
RNF07 Hardware La aplicación debe ser Alta
utilizada con unas gafas de
realidad virtual.
RNF08 Disponibilidad La aplicación necesita al Media
menos 350 mega bytes
disponibles de
almacenamiento dentro del
dispositivo para poder ser
instalada y ejecutada
correctamente.
RNF09 Usabilidad y El sistema ha de presentar los Media
Accesibilidad elementos gráficos claramente
visibles e identificables.
RNF10 Usabilidad La aplicación ha de cumplir Alta
con los consejos de usabilidad
de una aplicación Android y
de realidad virtual.
Tabla 2. Requisitos No Funcionales

5. DISEÑO E IMPLEMENTACIÓN
En este capítulo se explican los procesos de diseño e implementación
del sistema. Para ello, se especifica la arquitectura de la aplicación y cada una
de las capas que compone la arquitectura.

Cabe destacar que, debido al contrato de confidencialidad con la

empresa, no se va a mostrar la implementación de la aplicación, solo algunos
escasos ejemplos de código, y se mostraran mockups en vez de escenas
propias de la aplicación.

5.1. ARQUITECTURA DEL SISTEMA

La arquitectura o modelo de capas [7] es una técnica software para

separar las diferentes partes de la aplicación, con el objetivo de mejorar su

27
rendimiento, mantenimiento y sus funciones. Esta separación de las diferentes
partes hace que los cambios en cualquiera de las capas no afecten o afecten
poco a las otras capas en que está dividida la aplicación.

Este sistema sigue una arquitectura de tres capas, capa de

presentación, capa de negocio y capa de datos. Cada capa se apoya por la
capa anterior y todas se encuentran en el mismo nivel, o lo que es lo mismo, en
el mismo dispositivo. A continuación, se detallan esas capas y se muestra un
diagrama de componentes que describe la estructura de la aplicación. Se
mostrará una descripción más detallada de los componentes en sus
respectivos apartados.

Figura 15. Arquitectura 3 capas utilizada

Figura 16. Diagrama de componentes de la arquitectura

 Capa de presentación. Es la capa que ve el usuario y permite la

interacción con él. Presenta el sistema, captura la información y presenta la
información al usuario en un mismo proceso. Los comportamientos y
eventos generados en esta capa son realizados en la siguiente capa, la
capa de negocio, con la cual se comunica únicamente. Esta capa está
formada por dos módulos que gestionan la interacción de la aplicación con
los diferentes dispositivos de entrada (información que necesita o que se
manda a la aplicación) y salida ofrecidos por la aplicación (información
enviada por la aplicación).

 Capa de negocio. Es la capa que hace de intermediaria entre la capa de

presentación y la de datos. Recibe las solicitudes de la capa de

28
 presentación e información de la capa de datos, y encargarse de mostrarlos
en la capa de presentación. Además, es la que contiene toda la lógica de la
aplicación, como scripts. Esta capa está formada por un módulo principal
que se encarga de todo aquello que está sucediendo durante el juego, y
varios submódulos que se encargan de la gestión de la realidad virtual o las
escenas, entre muchos otros.

 Capa de datos. Es la capa donde se almacena toda la información y la

encargada de acceder a ellos. En este proyecto, la base de datos son los
ficheros XML que contienen los datos necesarios para crear los paseos,
sugerencia, entornos y material gráfico. Esta capa tiene dos módulos, el de
entrada donde está la información, por ejemplo, del material gráfico que
pide la capa de negocio, y el módulo de salida donde se guarda la
información enviada por la capa de negocio, en este caso, las sugerencias
creadas por el usuario.

5.2. CAPA DE PRESENTACIÓN

Previamente, en esta sección, se va a hablar de los componentes que
forman esta capa y del diagrama de flujo de navegación, junto con la
explicación de cada escena y algunos mockups.

Esta capa, como se ha citado anteriormente, aparte de trabajar con el

aspecto gráfico, está formada principalmente por dos módulos.

 Módulo de Entrada. Se encarga de gestionar la información introducida por

el usuario en la aplicación, es decir se encarga de gestionar la interfaz de
entrada de la aplicación.

 Sensor de acelerómetro: Es el principal responsable de detectar los

cambios de orientación en el terminal, con el fin de que este pueda
rotar el contenido de la pantalla hacia una posición vertical u
horizontal.

 Sensor de giroscopio: Es capaz de decirnos la velocidad angular

del teléfono en todos sus ejes de rotación. Gracias a este sensor la
cámara de la aplicación se mueve siguiendo los movimientos de
nuestra cabeza con las gafas de realidad virtual.

 Pantalla táctil: Todo el proceso de navegación por las diferentes

escenas sin realidad virtual de la aplicación.

 Módulo de Salida. Este módulo se encarga de gestionar la interacción de

la aplicación con el dispositivo de salida, que es el móvil. Contiene dos
componentes.

 Altavoz: A modo de enriquecimiento, existirán melodías de fondo

durante la navegación de la aplicación.

29
  Pantalla: Todo lo que suceda en la aplicación se representará
gráficamente a través de la pantalla del dispositivo.

5.2.1. DIAGRAMA DE FLUJO DE NAVEGACIÓN

A continuación, se determina el diseño del diagrama de navegación

describiendo los comportamientos que tiene la aplicación según las acciones
del usuario, mediante símbolos con significados definidos e interconectados
con flechas marcando los pasos del sistema. Dicho diagrama se caracteriza por
tener un único punto de inicio y un único punto de finalización. La simbología
utilizada es la siguiente:
 Óvalo/Elipse: Inicio y fin.
 Rectángulo: Actividad/Escena.
 Rombo: Decisión.

Además, se realiza una descripción detallada de los procesos y algunos

mockups.

Figura 17. Diagrama de flujo de navegación de las escenas

1. Splash Screen

Es la escena inicial de la aplicación, en la cual aparece el logo de Unity y

de la empresa “Creative Rainbow”, durante unos segundos. Es
importante para el aspecto visual de la aplicación.

2. No giroscopio

Esta escena aparece si la aplicación detecta que el dispositivo móvil no

dispone de sensor de giroscopio o la versión Android del dispositivo es
menor que 5.1. Contiene una imagen y un texto, que indican al usuario
que no puede seguir utilizando la aplicación por el fallo correspondiente.
También contiene un botón para poder salir de la aplicación.

30
3. Escena inicial

Esta escena aparece si el dispositivo móvil si dispone de sensor de

giroscopio. Contiene un botón, una imagen y un texto, que indican que la
experiencia de realidad virtual va a comenzar. Al pulsar continuar, el
usuario tiene unos segundos para introducir el dispositivo en las gafas y
ponérselas, antes de que comience la experiencia 360º.

4. Escena consejos y elección

La escena está dividida en dos partes. La primera, contiene

principalmente una serie de consejos que se deberían de seguir para
utilizar la aplicación y disfrutar de una buena experiencia, durante un
determinado tiempo. La segunda parte, aparece un texto que indica si es
la primera vez que utilizas la aplicación, con lo que el usuario tiene que
responder gesticulando con la cabeza un “si” o un “no”, para continuar.
Si la aplicación no detecta ningún movimiento, aparecerán unos botones,
los cuales, el usuario tendrá que seleccionar con la mirada.

5. Escena tutorial

Esta escena aparece si el usuario gesticula un “si” o selecciona el botón

de “si”. En dicha escena, el usuario realiza 3 pasos, en los cuales,
aprende a interactuar con los diferentes botones y objetos de la
aplicación. En el primer paso, el usuario aprende a interactuar con los
botones generales de la aplicación, en el segundo paso, el usuario
aprende a interactuar con el deslizador o “slider” del menú de selección,
y en el último paso, aprende a interactuar con los elementos que pueden
aparecer en el entorno.

6. Escena menú principal

Esta escena aparece si el usuario gesticula un “no” o selecciona el botón

“no”. Es el menú principal de la aplicación. El usuario tiene que mantener
el punto negro (retículo), durante 2 segundos, para hacer la acción de
seleccionar. Además, contiene los 4 submenús (botones) principales:

 Menú: Este submenú aparece por defecto al iniciar esta escena. En

esta aparecen los botones para elegir un paseo virtual, ir al tutorial o
salir de la aplicación.

 Ajustes: Aparecen los botones con los que el usuario puede calibrar
los valores de brillo de la escena o sonido ambiente.

 Compartir: El usuario puede compartir la aplicación a sus amigos en

las redes sociales. Cuando se selecciona este botón, se inicia una
cuenta atrás para que el usuario enfoque la imagen que quiere
capturar para compartir.

31
  Ayuda: Es un texto de ayuda para saber cómo interactuar con los
botones, saber la funcionalidad de los botones que aparecen a lo
largo de la aplicación u otras funcionalidades de la aplicación.

En definitiva, el usuario tiene que interactuar con los diversos botones

para acceder a menús que tiene la escena o avanzar a otras escenas.

Figura 18. Mockup de la escena menú principal

7. Escena sugerencia

Esta escena contiene un botón y un formulario. El formulario contiene 3

campos de input, el nombre del usuario, el asunto y el comentario de la
sugerencia. El nombre y el comentario son obligatorios a rellenar. Si el
usuario no rellena algún campo de esos, y pulsa continuar, saldrá un
pop-up de error. Además, cuando el usuario pulsa continuar, y ha
rellenado todo correctamente, saldrá una ventana diciendo, que se va a
activar el modo 360º y que introduzca de nuevo el móvil en las gafas de
realidad virtual, durante unos segundos.

Figura 19. Mockup de la escena del formulario de sugerencias

32
8. Escena selección del entorno

La escena contiene un “slider” con las imágenes del paseo virtual

seleccionado por el usuario y la opción de salir. El usuario tiene que
seleccionar una imagen para poder realizar la experiencia 360º del
paseo. La imagen central funciona como un botón normal, sin embargo,
los botones laterales funcionan como flechas para cambiar la imagen
central. Las imágenes están situadas formando un array circular. Por
ejemplo, si la imagen central es la imagen x, entonces, la imagen
izquierda es la x-1 y la derecha la x+1.

Figura 20. Mockup de la escena menú de selección de entorno

9. Escena del Paseo Virtual

Es la escena principal de la aplicación donde el usuario disfruta de un

paseo virtual en un entorno, puede contener objetos que el usuario
puede visualizar como imágenes, textos, videos o imágenes 360 que, si
el usuario selecciona, puede cerrarlos cuando quiera. También visualiza
los marcadores que son esenciales para moverse a través de los
entornos. Además de disponer de un menú de ajustes, el usuario puede
ocultar los objetos que aparecen en el entorno y volver a mostrarlos
cuando le convenga, o compartir una imagen en sus redes social, con
los botones que aparecen en el menú de ajustes.

33
 Figura 21. Mockup de la escena del paseo virtual

5.3. CAPA DE NEGOCIO

En la capa de negocio, se han establecido una serie de componentes
que aparecen en el diagrama de componentes de la arquitectura de la figura
16. Esta capa esta principalmente formada por un componente llamado
“Gameplay” que se encarga de todo aquello relacionado con lo que está
sucediendo durante la aplicación. A su vez, este componente está conectado
con otros subcomponentes que forman el núcleo de la aplicación. Se ha
definido esta estructura, ya que mucha implementación de esta capa, se
implementa como scripts de comportamiento asociados a componentes.

Además, para la implementación de esta capa, como se ha comentado

anteriormente, se ha optado por el lenguaje C#. Porque de los lenguajes que
proporciona Unity es el mejor y deja hacer cosas más complejas.

Antes de hablar del diagrama de clases, se va a hacer una detallada

descripción de los principales componentes que aparecen en esta capa.

 Gameplay: Es un componente de E/S del resto de componentes

pertenecientes al módulo del núcleo de la aplicación, que procesa toda la
información y actualiza tanto el flujo como la lógica de la aplicación.

 Flujo de la aplicación: Consiste en la gestión y ejecución del ciclo

de vida de la aplicación.

 Lógica de la aplicación: Engloba a todo lo relacionado con disparar

eventos, ajustes, realidad virtual, GUI… En definitiva, todo aquello
que pueda ocurrir en la aplicación durante la ejecución de una
escena, como un entorno.

 Gestión de la realidad virtual: Este componente se encarga de gestionar

la funcionalidad de la realidad virtual en la aplicación.

34
  Gaze Pointer: Este sistema compone la interacción del usuario con
el entorno de realidad virtual. El retículo situado en mitad de la
pantalla manda continuamente “Raycast” y al chocar con un
elemento 3D o un elemento UI se producen determinados eventos y
comportamientos. Cuando los “Raycast” chocan con un objeto válido,
el puntero del retículo se transforma en un círculo, y cuando deja de
chocar, se transforma otra vez en un punto. Este comportamiento
ayuda a los usuarios a saber en todo momento lo que está pasando y
es manejado mediante el uso de OnGazeStart, OnGazeStay y
OnGazeExit. Además, se comprueba si el elemento al que se está
mirando es un elemento grafico del entorno. Ya que los elementos
del entorno son creados con el tag instancia.

Figura 22. Eventos Gaze Pointer

 VR Viewer: Nosotros somos capaces de percibir los volúmenes y la

profundidad gracias a que tenemos dos ojos ligeramente separados, lo
que provoca que las imágenes recogidas por cada uno de ellos sean
ligeramente diferentes. Después, nuestro cerebro las une y genera una
única imagen tridimensional. Esta forma de percepción se llama
estereoscopia, y nuestra visión es de tipo binocular. Y, lógicamente, para
que la realidad virtual sea creíble, el visor debe proyectar hacia nuestros
ojos dos imágenes ligeramente desfasadas, que es lo que sucede
cuando observamos el mundo real. Este sistema genera al usuario la
visión de realidad virtual al usuario en el dispositivo generando la famosa
estereoscopia. Además, el usuario se puede configurar los ajustes
generales de la realidad virtual como el estéreo, la distorsión o la
activación/desactivación de la propia realidad virtual.

35
 Gestión de los eventos: Este componente se encarga de gestionar la
funcionalidad de determinados objetos del entorno. Debido a que muchos
de los objetos del entorno se implementan como scripts de comportamiento
asociados a componentes.

 Eventos y comportamientos de los objetos: Los objetos del

sistema ejecutan unos eventos en función de determinados
comportamientos. Por ejemplo, los botones menú del menú principal
ejecutarán un evento de carga de siguiente escena al interaccionar el
retículo durante 2 segundos sobre dicho botón, gracias a las
funciones OnPointerEnter y OnPointerExit, cuyo funcionamiento es
similar al de GazePointer.

Figura 23. Evento que se ejecuta

Como se explica anteriormente, cuando el usuario pasa el retículo

por un objeto válido, se ejecuta la función PointerEnter, la cual,
establece un valor booleano a true. En la función Update cuando ese
valor es true, se empieza a sumar el tiempo en un contador llamado
timer. Cuando este es mayor que gazeTime se ejecuta el evento escrito
dentro del if. Los id que se establecen como condición en el if, equivalen
a que cada botón tiene un id diferente. Además, si el usuario retira el
retículo del objeto valido mientras el tiempo no se ha cumplido, el valor
booleano se vuelve false y se pone reestablece el tiempo a 0.

36
 Figura 24. Reconocimiento del gesto

En este ejemplo, se puede ver otro evento que se ejecuta. Cada un

determinado tiempo se toman 80 datos (vectores de los ángulos x e y de
la cámara). Si las trazas de esos vectores forman un “si” (gesticulando el
usuario un sí) o forman un “no” (gesticulando el usuario un no), se
cambian los respectivos valores booleanos y se ejecutan los
correspondientes eventos.

 Gestión de escenas: Este módulo se encarga de la gestión de las distintas

pantallas que se visualizarán durante la ejecución, así como la carga y
descarga de los objetos que componen la aplicación.

 Carga de escenas y objetos: Bajo ciertas condiciones, se harán

llamadas a la aplicación correspondientes a la carga de escenas y
objetos.

En el siguiente ejemplo, se cargan las sugerencias en su

correspondiente array de la clase EstadoApp, si el fichero XML existe. Si
no existe, significaría que no se ha añadido ninguna sugerencia en dicho
buzón.

37
 Figura 25. Carga de las sugerencias del buzón de sugerencias

 Gestión de ajustes: Este componente centraliza la gestión del audio y brillo

de la aplicación:

 Audio y brillo: Se ha desarrollado un script que centralice todas las

llamadas de configuración de la melodía de la escena o brillo de la
imagen de la esfera. Dichas llamadas, se realizarán mediante un
menú del sistema GUI.

5.3.1. DIAGRAMA DE CLASES

Figura 26. Diagrama de clases

38
 A continuación, se va a hacer una descripción detallada de las clases del
diagrama anterior:

 EstadoApp

Es la clase donde se encuentra la información global, la cual, las demás

clases pueden acceder. Contiene información como los paseos y
sugerencias creadas a través del fichero XML, el paseo actual elegido por el
usuario, el entorno que se está viendo o los valores de sonido y brillo
actuales, entre muchos otros.

 Sugerencia

Es la clase donde se encuentra la información de una sugerencia. Estos

datos son el nombre del usuario, el asunto de la sugerencia, la fecha de
creación de la sugerencia y el campo de explicación de la sugerencia.
Adema contiene métodos getters y setters.

 Paseo

Es la clase donde se encuentra la información de un paseo, sus datos que

lo identifican como el nombre, el template o la lista de entornos que
contiene el paseo. También contiene métodos getters, métodos que
devuelven el número que entornos que tiene el paseo o devuelven un
entorno determinado.

 Entorno

Esta clase contiene los ítems que hay por el entorno como marcadores,
imágenes, videos, imágenes 360 o textos. Estos objetos se obtienen
mediante uso del documento XML. Cada vez que se elige o cambia un
nuevo entorno, se limpian los ítems anteriores y se busca en el documento
XML los ítems del nuevo entorno elegido.

 Ítem

Es la clase base de la herencia, sus clases derivadas son Marcador,

Imagen, Texto, Video e Imagen360. Esta clase contiene los atributos de las
coordenadas de esos objetos, ya que todas esas clases comparten clases
esos mismos atributos. Además, contiene métodos getters y setters de
dichos atributos.

 Marcador,Imagen,Imagen360,Texto,Video

Son las clases derivadas. A parte de los atributos que heredan de la clase
Ítem, cada clase tiene un atributo distinto y sus respectivos getters.
Marcador tiene un atributo Integer con el id del entorno destino de ese
marcador. Imagen tiene un atributo Sprite 2D de la imagen a mostrar.
Imagen360 tiene un atributo Material con el fondo la imagen 360 a mostrar.

39
 Texto tiene un atributo String con el texto a mostrar. Video tiene un atributo
VideoClip del video.

5.4. CAPA DE DATOS

La información debe estar organizada en estructuras de forma que
faciliten los accesos y su modificación. Para almacenar la información
inicialmente se investigó que soportes daba Unity3D para bases de datos y se
decidió por el uso de XML [24] como sistema de almacenaje de datos, ya que
está bien estandarizado y estructurado. Además, este lenguaje permite la
validación de datos, comprobando que un documento en lenguaje XML está
bien formado y se ajusta a la estructura definida.

Para validar estos datos, se decidió por el uso de esquemas (XML

Schema) debido a que es la evolución de los DTD (formato de validación de
esquemas más antiguo) y es un lenguaje de esquema completo y potente.

Por último, tras decidir el lenguaje de la base de datos y su método de

validación, lo siguiente era decidir los datos que eran necesarios almacenar.
Estos datos como se puede ver en el diagrama de componentes de la
arquitectura, son los datos necesarios para crear los paseos, los datos
necesarios para crear los elementos que aparecen por el entorno y sugerencias
que pueden dejar los usuarios en la aplicación para que las vean otros
usuarios. A continuación, se mostrará detalladamente estos datos y sus
estructuras gracias al programa XMLSpy.

5.4.1. PASEOS

Figura 27. Estructura de los paseos

Los paseos son la base de la aplicación, este documento contiene los

datos principales para crearlos. Estos están formados por un atributo principal y
una lista con los datos que identifican también al paseo.

 Tipo: Es el atributo principal que lo identifica, este es una clase enumerativa

que puede ser “Museos”, “Parques”, “Literatura” o “Historia”.

40
 Nombre: Es el nombre del paseo virtual.

 Template: Es el nombre de la plantilla XML que contiene los entornos y

objetos del paseo virtual.

 Path: Contiene el nombre de la carpeta donde se encuentra el contenido

grafico necesario del paseo virtual.

 Música: Es el nombre del archivo mp3 de la música ambiental del paseo.

A continuación, se va a mostrar el esquema de validación y el

documento XML creado. El documento XML solo va a ser mostrado en esta
sección, debido a la confidencialidad de los datos y por mostrar un ejemplo del
funcionamiento de este lenguaje.

Figura 28. Datos del fichero XML paseos

Como se puede ver en la imagen anterior, se ve el documento XML con

los paseos creados con sus datos que los identifican.

Figura 29. Esquema del fichero XML paseos

En este caso, se puede ver el esquema que valida el anterior

documento, identificando los elementos, los atributos y las restricciones
determinadas de los elementos.

41
 5.4.2. ENTORNOS DEL PASEO

Este documento es esencial en la creación de los entornos que contiene

un paseo y los elementos gráficos que contienen los propios entornos. Se va a
mostrar solo la estructura y esquema de un paseo, ya que todos los paseos
siguen la misma estructura y lo único que cambia es el nombre del primer
elemento de la estructura.

Figura 30. Estructura de los entornos de los paseos

Un paseo puede contener 1 o varios entornos, en los cuales, hay uno o

varios ítem y un fondo. Además, cada ítem contiene un tipo y una lista con los
datos necesarios para su creación.

 Fondo: Es el nombre del material 360º que se va usar en el entorno como

fondo.

 Tipo: Este atributo es una clase enumerativa y es esencial, ya que identifica

si el ítem a crear es del tipo “Marcador”, “Imagen”, “Imagen360”, “Texto” o
“Video”.

 X: Valor de la coordenada x del ítem en el entorno.

 Y: Valor de la coordenada y del ítem en el entorno.

 Z: Valor de la coordenada z del ítem en el entorno.

 RotX: Valor de rotación x del ítem en el entorno.

 RotY: Valor de rotación y del ítem en el entorno.

 Información: Valor String esencial para la creación del ítem, pero tiene una
finalidad diferente en cada uno. Si el tipo es “Marcador”, es el número del
entorno que te diriges si se pulsa ese marcador. Si el tipo es “Imagen”, es el
nombre del archivo que contiene la imagen que se quiere mostrar al pulsar

42
 sobre el elemento. Si el tipo es “Imagen360”, es el nombre del material que
contiene el fondo que se quiere ver. Si el tipo es “Texto” contiene el texto
que se va a mostrar al pulsar sobre el elemento. Si el tipo es “Video”, es el
nombre del video que se va a mostrar al pulsar sobre el elemento.

A continuación, se va a mostrar el esquema de validación del documento

XML de los entornos del paseo.

Figura 31. Esquema de los entornos de los paseos

5.4.3. SUGERENCIAS

Figura 32. Estructura de las sugerencias

Los usuarios pueden dejar sugerencias en la aplicación, las cuales, se

guardarán en un documento XML. Una sugerencia tiene como atributo y una
lista con datos necesarios:

 Fecha: Este atributo contiene la fecha de creación de la sugerencia por el

usuario.

 Nombre: Nombre del usuario que realiza la sugerencia. Es un campo

obligatorio.

43
 Asunto: Tema de la sugerencia. No es un campo obligatorio.

 Comentario: Explicación de la sugerencia. Es un campo obligatorio.

A continuación, se va a mostrar el esquema de validación del documento

XML de las sugerencias de la aplicación.

Figura 33. Esquema de las sugerencias

6. EVALUACIÓN Y PRUEBAS
En este capítulo se realizan las pruebas [7] para validar y comprobar el
funcionamiento de la aplicación, y asegurarse que los requisitos especificados
se han cumplido. Al haber utilizado la metodología incremental, cada iteración
debía realizar pruebas sobre lo implementado.

En este proyecto se han realizado pruebas unitarias, de integración, de

sistema y de aceptación.

6.1. PRUEBAS UNITARIAS

Una prueba unitaria es una forma de comprobar el correcto
funcionamiento de la unidad de código. La mayor parte de estas pruebas se
han hecho con la clase Assert Log y las funciones Log, LogError y LogWarning,
que mandan mensajes a la consola de Unity en tiempo de ejecución. Por
ejemplo, para conocer el estado de Game Objects de la aplicación, esperar un
mensaje en el registro o evitar que una prueba falle.

El resto de pruebas se han hecho con una herramienta gratuita que

proporciona Unity llamada Test Tools, que usa NUnit para crear las pruebas
unitarias. Esta herramienta tiene 3 formas de hacer pruebas, mediante Assert
Component, Integration Test y Unity Testing. En este proyecto se ha elegido la
primera opción Assertion. A continuación, se van a mostrar una serie de
ejemplos del uso de dicha herramienta.

44
 Figura 34. Pruebas unitarias ejemplo 1

En el primer ejemplo, se encuentran 3 asserts. Los dos primeros

comprueban que el valor del array de sugerencias (la sugerencia que se está
mostrando), está siempre entre el valor 0 y el número de sugerencias menos
uno. La última, comprueba en el menú principal, que el objeto que se está
mirando no es objeto, solo es objeto si es un ítem del paseo virtual. En los 3
casos, no se muestra ningún mensaje de error por consola, ya que, si
apareciera dicho mensaje, significaría que su funcionamiento no es correcto.
Además, las tres pruebas se comprueban en todo momento con la opción
Update, que quiere decir, durante toda la ejecución de la escena, y cada 100 y
200 frames.

Figura 35. Pruebas unitarias ejemplo 2

En este ejemplo, se comprueba en todo momento si el valor booleano

del botón menú cambia a true en algún momento. Si cambia a true, significa
que se va a ejecutar su correspondiente evento, por lo tanto, su funcionamiento
es correcto. Como se puede ver en la parte posterior de la imagen, se observa
un mensaje de error enviado por la aserción que indica que se cambia el valor
y se ejecutará el evento.

45
 Figura 36.Pruebas unitarias ejemplo 3

En el último ejemplo, se comprueba al principio de la escena del paseo

virtual que el array de marcadores sea igual a 0. Este valor nunca debe ser 0
ya que el número de marcadores en un entorno debe ser 1 o mayor. Por lo
tanto, se observa un mensaje de error que indica que el número de marcadores
en ese entorno es 1, y el funcionamiento es correcto.

6.2. PRUEBAS DE INTEGRACIÓN

El objetivo de las pruebas de integración, es una vez verificados los
módulos unitarios por separado, ampliar el rango de alcance de las pruebas.
De forma que se compruebe el comportamiento de dichos módulos, a la vez
que se van integrando en el proyecto en cada iteración. Cada vez que se carga
una escena nueva en la aplicación, se considera una prueba de integración. Ya
que depende de que se pulse un botón en la escena anterior. Para comprobar
esto, se han ido probando escenas sueltas y luego añadiéndolas
progresivamente para ver su correcto funcionamiento.

6.3. PRUEBAS DE SISTEMA

Estas pruebas, finalmente son las que se encargan de verificar que todo
el sistema funciona correctamente en su conjunto, con todos los módulos y
funciones instaladas, como parte final de todas las iteraciones realizadas. En
estas pruebas vamos a diferenciar dos tipos, de usabilidad y de rendimiento.

6.3.1. PRUEBAS DE RENDIMIENTO

En el caso de las pruebas de rendimiento, se han marcado varias

pruebas para verificar que los fotogramas por segundo en la aplicación
(velocidad a la que el dispositivo muestra imágenes llamados cuadros o
fotogramas) son correctos. Como se ha citado anteriormente en los requisitos
funcionales, la aplicación tendrá que funcionar a más de 30 fps. Por tanto,
significaría que la aplicación va mucho más fluida e influye de una manera
grata en la jugabilidad. Además, influye gratamente en la cinetosis del usuario,
evitando mareos por el movimiento.

46
 Para demostrar esto, se ha utilizado un prefab que nos proporciona el
paquete de Google VR, que se añade a la cámara y nos indica en número de
fotogramas por segundo a los que va la aplicación. Se ha tomado los fps de la
aplicación en todas las escenas y se ha hecho la media. Resultando una media
de 34.8 fps, por lo que, los fps son fluidos.

Además, Unity proporciona un analizador que ayuda a optimizar la

aplicación y conocer su rendimiento. Este reporta los datos de rendimiento o el
tiempo que se está gastando en las diferentes áreas de la aplicación, como, por
ejemplo, el porcentaje de tiempo que se gasta renderizando o en la lógica de la
aplicación.

La ventana del analizador muestra los datos en una línea de tiempo, en

la cual, se pueden ver el tiempo o frames que toma cada área. A continuación,
se mostrará una imagen del analizador.

Como se puede ver en la imagen, el renderizado es el área de CPU que

más gasta en la aplicación. En el panel inferior, se puede ver que el
renderizado de la cámara gasta un 61.8% de tiempo. Es debido a las funciones
de dibujo y culling que gastan mucho tiempo. Sin ellas, el tiempo gastado seria
mínimo.

Además, en el panel inferior, se puede ver un icono warning, que detecta

y advierte sobre problemas de rendimiento. En nuestro caso, no hay ningún
problema.

En los siguientes paneles, se puede ver el área de renderización y de

memoria utilizado.

6.3.2. PRUEBAS DE USABILIDAD

La usabilidad es considerada uno de los factores más importantes dentro

de la calidad de un producto software. Para medir la usabilidad, es necesario

47
seguir unos consejos adecuados. Para estas pruebas se ha seguido la guía de
usabilidad de Android.

Los elementos claramente visibles, el contraste y tamaño suficiente de

los iconos, botones o imágenes, la clara jerarquía y la información clave,
ayudan a los usuarios a navegar por la aplicación. Simplificando la interfaz de
usuario y ayudando en el tema de claridad.

Se ha utilizado el color y el contraste de botones, iconos e imágenes,

para ayudar a los usuarios a interpretar el contenido de su aplicación, e
interactuar con los elementos adecuados.

Es importante la agrupación de los elementos y mantener el contenido y

la accesibilidad del texto breve. De esta manera, los usuarios pueden navegar
más rápido por la aplicación.

Se ha utilizado verbos de acción para indicar la función de un botón,

para que personas con discapacidad visual lo puedan entender. Además, el
texto del vínculo especifica la tarea que al tocar el botón llevara a cabo.

La aplicación también proporciona feedback en el usuario, pudiendo

volver al menú principal en cualquier escena de la aplicación y dando la opción
de salir de la aplicación.

La aplicación también sigue muchas de las pautas más importantes para

el diseño de aplicaciones de realidad virtual, para Google Cardboard [25].

Se mantiene siempre el seguimiento de la cabeza, evitando largas

congelaciones en el seguimiento de la cabeza para no perder el seguimiento, y
se evitan cambios bruscos de luminosidad, que podrían causar molestias en los
usuarios.

El sistema desestima el uso de los botones laterales que proporcionan

algunas gafas de realidad virtual, ya que su uso puede sentirse lento y
frustrante. En vez de ello, se usan botones virtuales, que se clic kan mediante
un temporizador, después de que el usuario se haya centrado en ellos, durante
un determinado periodo de tiempo.

Se utilizan botones, que disponen de una cuenta atrás para su

activación, para evitar missclicks y el usuario sepa lo que está sucediendo.
También se utiliza un tamaño grande para los botones y se evita su colocación
cercana, para evitar que el usuario haga clics de manera accidental.

Finalmente, para ayudar al usuario a sumergirse en el entorno, se utiliza

audio como fondo para hacer la aplicación más realista y se proporciona una
retícula visual para ayudar a focalizar y apuntar objetos.

48
 6.4. PRUEBAS DE ACEPTACIÓN
Las pruebas de aceptación se conciben como la última parte del proceso
de verificación, ya que se refieren a la validación del funcionamiento del
sistema según los propios usuarios o jugadores. En nuestro caso, se ha hecho
una encuesta a 6 usuarios de diferentes edades. Tras el uso de la aplicación,
han rellenado el siguiente formulario, en el cual, se han definido un conjunto de
tareas con el fin de comprobar el correcto funcionamiento y el nivel de
usabilidad. Dichas pruebas, se realizaron con el mismo terminal con la
aplicación instalada.

Pregunta 1
El usuario debe lanzar la aplicación. ¿Ha comenzado de manera
satisfactoria? Si la respuesta es no indique que ha pasado.
□ Si
□ No

Pregunta 2
El usuario debe salir de la aplicación. ¿Ha salido de manera
satisfactoria? Si la respuesta es no indique que ha pasado.
□ Si
□ No

Pregunta 3
¿Reconoce el sistema correctamente el gesto “si” o “no” del usuario? Si
la respuesta es no indique que ha pasado.
□ Si
□ No

Pregunta 4
El usuario debe interactuar con los botones de los menús. ¿Ha podido
interactuar de manera satisfactoria? Si la respuesta es no indique que ha
pasado.
□ Si
□ No

Pregunta 5
El usuario debe interactuar con los objetos del entorno del paseo virtual.
¿Ha podido interactuar de manera satisfactoria? Si la respuesta es no indique
que ha pasado.
□ Si
□ No

Pregunta 6
¿Le parece una interfaz fácil e intuitiva?
□ Si
□ No
□ Regular

49
 Pregunta 7
¿Le ha parecido una aplicación difícil de utilizar?
□ Si
□ No
□ Regular

Pregunta 8
¿Le ha gustado la aplicación?
□ Si
□ No
□ Regular

Pregunta 9
¿Le parece una buena idea el aprendizaje a través de una aplicación de
realidad virtual, en el ámbito de la educación? Si la respuesta es no indique que
por qué.
□ Si
□ No
□ Regular

Pregunta 10
¿Qué aspectos mejorarías de la aplicación?

A continuación, se va a mostrar el resultado obtenido de los

cuestionarios entregados a los usuarios escogidos para la evaluación de la
aplicación, junto con las indicaciones o conclusiones de los usuarios.

Figura 37. Gráfica de resultados de pruebas de aceptación

50
 En las primeras 5 preguntas y la pregunta 7, todos los usuarios
respondieron a todo que positivamente. Sin embargo, en la pregunta 6, un
usuario respondió que la interfaz no le parecía muy intuitiva y que cambiaría la
organización y diseño de algunas cosas. En la pregunta 8, un usuario
respondió regularmente, ya que no veía mucho futuro a la aplicación. En la
pregunta 9, dos usuarios respondieron negativamente con una respuesta
similar, que preferirían el aprendizaje de los entornos visitándolos en persona y
que veían la aplicación más en el ámbito del turismo y entretenimiento. En la
última pregunta, la mayoría de los usuarios contestaron que mejorarían la
calidad de la imagen de algunos elementos de la aplicación.

7. CONCLUSIONES Y TRABAJOS FUTUROS

Para finalizar, el objetivo de este último capítulo de la memoria es
exponer las conclusiones obtenidas en el desarrollo del proyecto, y las posibles
líneas futuras de trabajo a través de mejoras o adaptaciones de nuevos
elementos.

7.1. CONCLUSIONES
En primer lugar, hay que centrarse en ofrecer las conclusiones obtenidas
desde el análisis y desarrollo de una aplicación de Android, usando la
tecnología de realidad virtual, desde un punto de vista de un ingeniero de
software.

El objetivo principal marcado al principio del proyecto consistía en la

creación de una aplicación móvil Android, en el ámbito de la educación para
entornos socioculturales, usando la tecnología de realidad virtual. Este objetivo
se ha conseguido satisfactoriamente, ya que se dispone de una aplicación,
mediante la cual, alumnos sin salir de sus aulas, pueden conocer entornos
culturales. Y permite el aprendizaje de los entornos junto con el factor del
entretenimiento. Esto incrementara el interés de los alumnos, un factor muy
importante en el aprendizaje. En el caso de los objetivos parciales, la
realización de este proyecto ha supuesto un gran esfuerzo de aprendizaje tanto
del motor Unity, lenguaje C# y muchas de las tecnologías y procesos utilizados.
Además, afortunadamente, a los alumnos se nos insta a la realización de un
Trabajo Fin de Grado como éste, que nos permite aplicar los conocimientos
adquiridos en dichos estudios, así como la posibilidad de ampliarlos de acuerdo
a nuestros intereses profesionales.

Gracias a la metodología utilizada y la realización de un documento

como este, ha sido útil para comprender la función de un ingeniero de software
a la hora de desarrollar un proyecto, permitiendo aprender los pasos a seguir
en futuros proyectos.

Durante el desarrollo del proyecto, han surgido varios problemas. Uno de

ellos, ha sido la estructuración del código. Se ha tenido que cambiar el diseño
de clases varias veces debido a diferentes problemas que han ido surgiendo.
51
Esto podría haberse evitado mejorando la planificación previa, y habiendo
tenido más experiencia en este tipo de proyectos. Otros problemas han sido la
falta de conocimientos de la tecnología de realidad virtual en Unity, los
problemas con las nuevas versiones de Unity. Por ejemplo, la nueva versión de
Unity no deja cargar los videos desde la carpeta de Assets.

Aunque algunos aspectos pueden ser mejorables, como los elementos

del juego o la interfaz de usuario. El resultado final de la aplicación fue
satisfactorio. Cumpliendo los requisitos funcionales y no funcionales, y las
pruebas finales realizadas.

Por último, me gustaría recomendar el uso de Unity a cualquiera que

desee crear una aplicación o un videojuego sin disponer de grandes recursos,
ya que se pueden crear maravillas y dispone de gran ayuda online y
documentación.

7.2. TRABAJOS FUTUROS

El hecho de proponer futuras líneas de desarrollo implica que la
aplicación de realidad virtual implementada es susceptible de mejorar, aun
obteniendo buenos resultados y cumpliendo todas las expectativas iniciales.

Como se ha comentado numerosas veces, el sistema operativo a

emplear la aplicación, ha sido Android. Lógicamente, este sistema operativo
dispone la mayor parte del mercado. Sin embargo, hay un gran número de
dispositivos que se quedan sin dar funcionalidad. Por tanto, una posible mejora
seria portar la aplicación a otras plataformas como iOS e inclusive a PC. En el
caso del PC, significaría el uso de otro tipo de gafas, más caras, pero más
potentes.

Se decidió hacer la aplicación para las gafas “Cardboard”, debido a su

escaso coste de material, y que muchos colegios no pueden permitirse comprar
unas gafas “Oculus Rift” con su respectivo material hardware para mover la
aplicación. Una posible mejora, si la aplicación tiene éxito, la creación de la
aplicación para este tipo de gafas, muchísimo más potentes y con muchas más
funcionalidades, por lo que, el aprendizaje y la diversión sería mucho mayor.

Otra gran mejora seria, centralizar todo el material audiovisual, como

imágenes, videos, fotos o texto, en un servidor. Y que la aplicación acceda al
servidor via streaming. En vez de descargarte una aplicación con muchos
megas, te descargas una aplicación que requiera conexión a internet
permanente y aliviaría el peso de la aplicación. Todo el material estaría
centralizado según la zona o el país.

52
BIBLIOGRAFÍA
1. Android domina el mercado global de sistemas operativos Android:
http://www.elcomercio.com/guaifai/android-ios-mercado-sistema-
operativo.html

2. El futuro de la educación pasa por la realidad virtual:

http://blogthinkbig.com/el-futuro-de-la-educacion-pasa-por-la-realidad-
virtual/

3. Toda la actualidad sobre la realidad virtual:

https://www.realovirtual.com/

4. Que es la realidad virtual y tipos:

https://www.mediatrends.es/a/65544/que-es-vr-historia-tipos-gafas-
realidad-virtual/

5. Orígenes históricos de la realidad virtual:

http://www.realidadvirtual.com/info/origenes-de-la-realidad-virtual.html

6. Rainbow Consulting: http://creative-rainbow.com/

7. Sommerville, 2012. Ingeniería del Software. 9a Edición, Addison-

Wesley. 2012.

8. Unity 3d: https://unity3d.com/es

9. Documentación Unity 3D: http://docs.unity3d.com/Manual/index.html

10. Comunidad Unity 3D: http://docs.unity3d.com/Manual/index.html

11. Asset Store Unity: https://www.assetstore.unity3d.com/

12. Blender: https://www.blender.org/

13. Adobe Photoshop: http://www.adobe.com/es/products/photoshop.html

14. Monodevelop: http://www.monodevelop.com/

15. Unity Remote:

https://docs.unity3d.com/es/current/Manual/UnityRemote4.html

16. Project 2016.

17. Draw.io: https://www.draw.io/

18. Balsamiq mockups: https://balsamiq.com/products/mockups/

19. XMLSpy: https://www.altova.com/es/xmlspy.html

53
20. C#: https://es.wikipedia.org/wiki/Extensible_Markup_Language

21. XML: https://www.w3schools.com/xml/

22. Google VR SDK For Unity: https://developers.google.com/vr/unity/

23. Android SDK: https://developer.android.com/studio/index.html?hl=es-

419

24. w3schools XML: https://www.w3schools.com/xml/

25. Consejos de diseño y usabilidad Google Cardboard:

https://vr.google.com/intl/es_es/cardboard/developers/

54