Memoria EPSU0809

Escuela Politécnica Superior
Memoria del Trabajo de Fin de Grado
Juego serio para niños con discapacidad

auditiva
Camila Ángela Pérez Arévalo
Grado de Ingeniería Informática
Año académico 2016-17
DNI del alumno: 43192595K
Trabajo tutelado por Cristina Manresa Yee

Departamento de Ciencias Matemáticas e Informática
Se autoriza a la Universidad incluir este trabajo en el Repositorio Institucional Autor Tutor

para su consulta en acceso abierto y difusión en línea, con finalidades Sí No Sí No
exclusivamente académicas y de investigación X X
Palabras clave del trabajo:

Niños, discapacidades auditivas, ritmo, habilidades psicomotoras, diseño, juego serio
A mi familia y, sobre todo, a mis padres por animarme cuando nadie más podía hacerlo.
A mi tutora Cristina Manresa por su ayuda y consejos y por convertir este proyecto en
una forma de vivir nuevas experiencias y de conocer gente apasionada por lo que hace.
A Carlos Tenorio, porque sin su música Armonisia no hubiese sido Armonisia.
A mis amigos con los que he recorrido esta etapa, porque no podría haber tenido
mejores compañeros de viaje.
Í NDICE GENERAL
Índice general iii
Índice de figuras vii
Índice de cuadros ix
Índice de funciones xi
Acrónimos xiii
Resumen xv
1 Introducción 1
1.1 Marco del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Conceptos relacionados 5
2.1 Discapacidad auditiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Sentido del ritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Juegos serios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Sentido del ritmo en diversos videojuegos . . . . . . . . . . . . . 7
2.2.2 Videojuegos para personas con discapacidades auditivas . . . . 8
3 Metodología 11
3.1 Diseño centrado en el usuario . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Proceso de diseño del videojuego 13

4.1 Grupo de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Diseño gráfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1 ¿Por qué 2D? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2 Storyline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3 Técnica de juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Requisitos de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4 Interfaz gráfica de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4.1 Estilo visual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4.2 Personajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4.3 Niveles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
iii
iv ÍNDICE GENERAL
4.4.4 Otras pantallas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.5 Música y sonidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5 Desarrollo e implementación 31
5.1 Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.1 Unity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.2 Monodevelop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.3 InkScape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.4 Sistema de control de versiones . . . . . . . . . . . . . . . . . . . 33
5.2 GameObjects y Scenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Animaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3.1 Personajes principales . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3.2 Personajes secundarios . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.3 Elementos gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.4 Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.5 Física: Movimiento y gravedad . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5.1 RigidBody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5.2 Collider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6 Prefabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.7 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.8 Flujo del videojuego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6 Configuración de nuevos niveles 51

6.1 Pantalla de nivel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7 Evaluación 55
7.1 Participantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2 Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.3 Procedimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
8 Publicaciones y participaciones en eventos científicos o divulgativos 61

8.1 Women Techmakers Menorca 2017 . . . . . . . . . . . . . . . . . . . . . . 61
8.2 Informática para tod@s (IPT2017) . . . . . . . . . . . . . . . . . . . . . . . 61
8.3 Interacción 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
9 Conclusiones 63
9.1 Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9.2 Futuro trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.3 Opinión personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
A Anexos 65
A.1 Fuentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.2 Acta de Reunión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A.3 Póster IPT2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
A.4 Paper Interacción 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
ÍNDICE GENERAL v
Bibliografía 73
Í NDICE DE FIGURAS
3.1 Esquema del proceso de Diseño Centrado en el Usuario (DCU) utilizado. . 12
4.1 Boceto inicial de una pantalla de nivel. . . . . . . . . . . . . . . . . . . . . . . 16

4.2 Implante coclear real y representación gráfica en el personaje principal. . . 18
4.3 Gráfico por partes del cuerpo del protagonista en versión masculina y feme-
nina. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 Esbozos y gráficos finales de la versión masculina y femenina del protagonista. 19
4.5 Evolución de la creación de Rytmus. . . . . . . . . . . . . . . . . . . . . . . . 20
4.6 Gráficos del personaje zombie utilizados para crear la animación de ataque. 20
4.7 Esquema del orden de los niveles de Armonisia. . . . . . . . . . . . . . . . . 20
4.8 Capturas de la animación y pantalla de juego del nivel Sky Level. . . . . . . 22
4.9 Capturas de la animación y pantalla de juego del nivel Cemetery Level. . . . 23
4.10 Capturas de la animación y pantalla de juego del nivel West Level. . . . . . . 24
4.11 Capturas de la animación y pantalla de juego del nivel Christmas Level. . . 25
4.12 Pantalla de inicio de Armonisia. . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.13 Menú de opciones principal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.14 Pantalla de niveles de Armonisia. . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.15 Pantalla de inicio de Armonisia. . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.16 Pantallas de configuración al jugar por primera vez con Armonisia. . . . . . 28
4.17 Pantalla de fin de nivel en sus dos versiones: Nivel superado y nivel no
superado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.18 Pantalla de reporte/puntuaciones de Armonisia. . . . . . . . . . . . . . . . . 29
5.1 Cámara utilizada en Armonisia y GameObjects situados dentro de su campo

de visión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Partes principales del sistema de animación. . . . . . . . . . . . . . . . . . . 36
5.3 Diferentes animaciones del personaje protagonista y su correspondiente
Animator Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4 Diferentes animaciones del personaje de Rytmus y su correspondiente Ani-
mator Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.5 Colliders sobre los objetos que conforman el pentagrama de los niveles. . . 40
5.6 GameObject encargado de destruir las notas que no han sido acertadas. . . 41
5.7 Componentes adjuntados al prefab del círculo de color marrón. . . . . . . . 42
5.8 Diagrama de flujo del usuario al utilizar Armonisia. . . . . . . . . . . . . . . 49
6.1 Vista de Unity al modificar la plantilla de nivel. . . . . . . . . . . . . . . . . . 51

6.2 Vista de los componentes del GameObject ’LevelManager’. . . . . . . . . . . 53
vii
viii Índice de figuras
7.1 Niños jugando con Armonisia durante la evaluación. . . . . . . . . . . . . . 57

7.2 Escala visual del Smileyometer. . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3 Gráfico de barras representando las respuestas del cuestionario. . . . . . . 59
7.4 Gráfico circular representando la emoción de los participantes respecto al
videojuego. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Í NDICE DE CUADROS
2.1 Tabla de niveles de pérdida de audición. [1] . . . . . . . . . . . . . . . . . . . 6

2.2 Videojuegos de género musical y basados en el uso del ritmo. . . . . . . . . 8
2.3 Publicaciones relacionadas con las habilidades motoras fundamentales. . . 9
2.4 Proyectos relacionados con las habilidades motoras perceptuales. . . . . . 10
4.1 Requisitos no funcionales del proyecto. . . . . . . . . . . . . . . . . . . . . . 16

4.2 Requisitos funcionales del proyecto. . . . . . . . . . . . . . . . . . . . . . . . 17
7.1 Perfiles de cada uno de los participantes de la evaluación. . . . . . . . . . . 56

7.2 Preguntas del cuestionario presentado a los participantes. . . . . . . . . . . 58
ix
Í NDICE DE FUNCIONES
5.1 Métodos por defecto al crear un script. . . . . . . . . . . . . . . . . . . . . 42

5.2 Método de iniciliazación Start del script CharacterSelection.cs . . . . . . 43
5.3 Método de inicialización Start del script FinishedLevel.cs . . . . . . . . . 44
5.4 Método LoadData del script GameManager.cs . . . . . . . . . . . . . . . . 45
5.5 Método SaveData del script GameManager.cs . . . . . . . . . . . . . . . . 45
5.6 Método Update del script Note.cs . . . . . . . . . . . . . . . . . . . . . . . . 46
5.7 Método checkTouch del script Note.cs . . . . . . . . . . . . . . . . . . . . . 47
xi
A CRÓNIMOS
EPS Escuela Politécnica Superior
UIB Universitat de les Illes Balears
TFG Trabajo Final de Grado
OCDS Oficina de Cooperación al Desarrollo y Solidaridad
OMS Organización Mundial de la Salud
TIC Tecnologías de la Información y la Comunicación
PNAS Proceedings of the Naticonal Academy of Sciences
ASPAS Asociación de padres de personas con discapacidad auditiva
DCU Diseño Centrado en el Usuario
IDE Integrated Development Environment
UI User Interface
AIPO Asociación para la Interacción Persona-Ordenador
IMI Intrinsic Motivation Inventory
xiii
R ESUMEN
Los niños con discapacidades auditivas presentan diferentes obstáculos durante el

desarrollo de habilidades comunicativas o psicomotoras como la coordinación, el
equilibrio, la memoria, etc. Entre estas habilidades se encuentra la percepción del ritmo,
definido como la alternación de una serie de eventos que se repiten periódicamente en
un determinado intervalo de tiempo. En este Trabajo Final de Grado (TFG) se presenta
el proceso de diseño e implementación de Armonisia, un videojuego serio en 2D para
dispositivos móviles con el objetivo de ayudar a niños con discapacidades auditivas a
entrenar sus habilidades rítmicas y consecuentemente mejorar su coordinación motora
visual.
Durante el desarrollo de este proyecto se ha seguido un proceso iterativo basado en
el análisis de contexto y los requisitos de usuarios, la creación del diseño de la aplicación
y la evaluación con niños y terapeutas de la Asociación de padres de personas con
discapacidad auditiva (ASPAS).
Para lograr el objetivo de entrenamiento del ritmo de forma que los usuarios dis-
fruten de la experiencia, Armonisia se compone de diferentes niveles conducidos por
una historia fantástica y personajes con los cuáles pueden sentirse identificados. Cada
uno de los niveles muestra un patrón rítmico diferente representado por notas que se
mueven sobre la pantalla y que caen sobre unos botones circulares de colores sobre
los cuales el jugador debe pulsar para crear el ritmo de forma correcta. Además, con
el objetivo de mantener el reto y la motivación, cada nivel cuenta con una dificultad
diferente que aumenta a medida que avanza el juego.
xv
CAPÍTULO
1
I NTRODUCCIÓN
En este capítulo se explica la motivación de la creación e implementación de Armonisia,

inspirada por el proyecto Diseño de experiencias interactivas dirigidas al bienestar de
personas con necesidades especiales, del cual formarán parte los resultados obtenidos.
1.1 Marco del proyecto

El proyecto Diseño de experiencias interactivas dirigidas al bienestar de personas con
necesidades especiales (OCDS-CUD2016/13) se enmarca dentro del programa XIII Con-
vocatoria de ayudas para proyectos de cooperación universitaria al desarrollo (2016) de
la Oficina de Cooperación al Desarrollo y Solidaridad (OCDS). El investigador principal
y responsable del proyecto es la Dra. Cristina Manresa Yee, y los centros participantes
son la Universitat de les Illes Balears (UIB), la Universidad del Cauca (Colombia) y
la Universidad de San Buenaventura de Cali (Colombia). Dicho proyecto cuenta con
diferentes miembros de las universidades mencionadas, tanto profesores como estu-
diantes, que buscan transmitir la necesidad de diseñar sistemas interactivos accesibles
a personas con discapacidades.
Su duración aproximada es de dos años (2017-2018) y su objetivo general es el de di-
señar y crear experiencias interactivas multimodales que ayuden a mejorar el bienestar
en diferentes dimensiones (como puedan ser la emocional, social, ocupacional, física
e intelectual) de aquellas personas que presentan alguna discapacidad o necesidad
especial.
De forma más detallada, los objetivos específicos del proyecto son los siguientes:
• Objetivo específico 1: Formación bidireccional e investigación.
• Objetivo específico 2: Experiencias interactivas en educación.
• Objetivo específico 3: Experiencias interactivas en salud.
• Objetivo específico 4: Experiencias interactivas emocionales.
1
1. I NTRODUCCIÓN
Además de los sistemas desarrollados bajo este marco, los resultados que se esperan
obtener de este proyecto servirán tanto para mejorar la formación de los integrantes
como de experiencia en el diseño de sistemas interactivos accesibles.
1.2 Objetivos
El objetivo específico del proyecto de este TFG es diseñar y crear la base de un video-
juego serio en 2D para dispositivos móviles y tabletas con sistemas Android que ayude
a desarrollar la capacidad perceptiva del ritmo a niños con discapacidades auditivas.
Así pues, el proyecto Armonisia se enmarca en las experiencias interactivas en
educación, es decir, en el objetivo específico 3 comentado en el apartado anterior.
La idea principal es crear una primera versión base de la aplicación que pueda
ser expandida añadiéndole más niveles y funcionalidades a medida que se realizan
pruebas con usuarios. Por esta razón, la creación de la base del sistema interactivo
debe ser realizada de forma organizada y estructurada. El código debe ser modular, de
manera que la adición de un nuevo personaje o nivel no suponga una tarea dificultosa
sino que sea un proceso claro y simple.
Se debe crear también una documentación que incluya las explicaciones necesarias
para entender la dinámica del juego y los objetos que la conforman, así como un
manual de configuración para crear nuevos niveles.
1.3 Estructura del documento

Este documento está estructurado en los siguientes capítulos:
1. Capítulo 1 - ’Introducción’: Se describe el marco y contexto en el que se sitúa el

TFG y su objetivo principal.
2. Capítulo 2 - ’Conceptos relacionados’: Se describen los conceptos relacionados

con el contexto del TFG, como las discapacidades auditivas y los juegos serios.
3. Capítulo 3 - Metodología’: Se describe la metodología o procedimientos utiliza-

dos para el desarrollo de este proyecto.
4. Capítulo 4 - ’Proceso de diseño del videojuego’: Se describe la parte creativa del

proyecto. Se define el grupo de usuarios, requisitos principales, historia, música
y gráficos del videojuego.
5. Capítulo 5 - ’Desarrollo e implementación’: Se describe la parte técnica del

proyecto. Se definen las herramientas utilizadas y la estructura y funcionalidad
de los objetos del videojuego.
6. Capítulo 6 - ’Configuración de nuevos niveles’: Se describen los pasos a seguir

para la creación de nuevos niveles del videojuego.
7. Capítulo 7 - ’Pruebas’: Se describen las primeras pruebas y resultados obtenidos

con los usuarios.
2
1.3. Estructura del documento
8. Capítulo 8 - ’Publicaciones y participaciones en eventos científicos o divulga-

tivos’: Se describen las publicaciones y los eventos en los que se ha participado en
relación a los proyectos Armonisia y Diseño de experiencias interactivas dirigidas
al bienestar de personas con necesidades especiales.
9. Capítulo 9 - ’Conclusiones’: Se describen las reflexiones y el aprendizaje obteni-

do al realizar este proyecto y la futura continuación de su desarrollo.
3
CAPÍTULO
2
C ONCEPTOS RELACIONADOS
Este capítulo proporciona información básica y conceptos clave que definen el ámbito
del proyecto. Se explica el problema que se quiere tratar, las habilidades a potenciar,
los usuarios a los que está destinado y el sistema interactivo que se desarrolla para
conseguir el objetivo principal.
2.1 Discapacidad auditiva

La discapacidad auditiva hace referencia a la disminución o falta total de la capacidad
para oír de una persona debido a un problema del aparato auditivo. Las personas que
sufren este tipo de discapacidad se pueden distinguir entre [1]:
1. Sordas: Deficiencia total o profunda de la capacidad de oír. Se puede recuperar

parte de la audición mediante el uso de implante coclear1 .
2. Hipoacúsicas: Deficiencia parcial mejorable con el uso de aparatos auditivos,

entre los cuales destacan por su cantidad de usuarios, el audífono2 y el implante
coclear.
Las causas de este tipo de discapacidad pueden ser genéticas, congénitas o adquiri-
das, siendo la primera la más frecuente. Los niveles de pérdida de audición utilizados
para identificar una discapacidad auditiva se pueden observar en la tabla 2.1. La medi-
da utilizada son los decibelios, expresados con el símbolo dB, el cual expresa cuantas
veces más o cuántas veces menos y no una cantidad exacta.
1 Un implante coclear es un dispositivo médico electrónico que sustituye la función del oído interno
dañado. Al contrario que las prótesis auditivas, que amplifican el sonido, los implantes cocleares realizan
el trabajo de las partes dañadas del oído interno (cóclea) para proporcionar señales sonoras al cerebro.
Requiere una intervención quirúrgica.
2 Un audífono es un dispositivo electrónico que amplifica y modifica las señales sonoras para permitir
una mejor comunicación. Los audífonos reciben el sonido a través de un micrófono que convierte las
5
2. C ONCEPTOS RELACIONADOS
Nivel de discapacidad Decibelios

Hipoacusia leve 20-40 dB
Hipoacusia moderada 40-70 dB
Hipoacusia severa 70-90 dB
Sordera +90 dB
Cuadro 2.1: Tabla de niveles de pérdida de audición. [1]
La Organización Mundial de la Salud (OMS) estimó en el año 2015 que un total de

360 millones de personas convive con alguna discapacidad auditiva, lo que supone
más de un 5 % de la población mundial, de las cuales 32 millones son niños de entre 0 y
14 años, lo que representa un 8,8 % de la población mundial [2].
Estos niños con discapacidades auditivas pueden encontrarse con diversos obs-
táculos a la hora de desarrollar ciertas habilidades comunicativas o psicomotoras que
son importantes para la evolución de sus emociones, acciones y actividades sociales.
El uso de las Tecnologías de la Información y la Comunicación (TIC) puede ayudar a
entrenar dichas habilidades gracias a la creación de distintos sistemas interactivos.
Las competencias psicomotoras afectadas se describen a continuación [3]:
• Habilidades motoras fundamentales: Coordinación, equilibrio, postura y esque-

ma corporal.
• Habilidades motoras perceptuales: Percepción espacial, percepción temporal y
percepción del ritmo.
• Habilidades cognitivas: Razonamiento y memoria.
2.1.1 Sentido del ritmo

La percepción del ritmo es la habilidad motora perceptual que se pretende ayudar a
desarrollar con este proyecto. Un estudio publicado en la revista Proceedings of the
Naticonal Academy of Sciences (PNAS), sostiene que los recién nacidos llegan al mundo
con una capacidad innata para descubrir el ritmo ya que aprecian la música desde el
útero materno. Para demostrarlo, el psicólogo Istvan Winkler trabajó con niños de 37 a
40 semanas sin ninguna discapacidad auditiva haciéndoles escuchar varias canciones
mientras se controlaba la actividad de su cerebro. En el momento en que se eliminaban
golpes de ritmo de las canciones, se detectó que los niños reaccionaban de forma
negativa [4].
Así pues, la mayoría de niños disponen de dicha capacidad gracias al ritmo musical,
a diferencia de aquellos que nacen con alguna discapacidad auditiva, la cual desarrollan,
sobre todo, mediante estímulos visuales y/o táctiles. En los primeros años de colegio
se distingue una diferencia notable en el desarrollo del sentido del ritmo, relacionado
incluso con principios de dislexia [5].
El objetivo de Armonisia es ayudar a desarrollar el sentido del ritmo principalmente
mediante el estimulo visual, además de acompañarlo con el sonido y la música. Estas
técnicas son utilizadas normalmente a la hora de enseñar a niños con discapacidades
auditivas a practicar ejercicios como el baile o la gimnasia.
ondas sonoras en señales eléctricas. El amplificador modula las características de las señales y envía el
sonido al oído a través de un auricular. No requiere una intervención quirúrgica.
6
2.2. Juegos serios
2.2 Juegos serios

Un juego serio (serious game en inglés) se diferencia del concepto de juego que conoce-
mos por su objetivo final, que no solo es divertir al usuario, sino que pretende que se
adquiera un conocimiento determinado de forma entretenida. No obstante, hay otros
fines para los que se utilizan estos juegos, ya puedan ser comerciales, de concienciación
o incluso de denuncia social o política [6].
Así pues, juega un importante papel la motivación. El uso de juegos serios para
cultivar y desarrollar conocimientos o habilidades se basa en la motivación que ofre-
cen los juegos que conocemos habitualmente: el desafío que presentan, la fantasía
de la historia que entretiene, la percepción del progreso que obtiene el usuario al ir
aumentando en puntuación o pasando niveles y la exploración libre y segura que se
consigue al saber que nos movemos en un entorno ficticio y donde nuestras acciones
no conllevan un resultado o efecto en el mundo real.
La definición formal es la siguiente: “Un juego serio es un juego digital con la inten-
ción de entretener y conseguir al menos una meta adicional (por ejemplo aprendizaje o
cuidado de la salud). Estas metas adicionales se conocen como metas caracterizadas"[6].
Las ventajas del uso de un sistema interactivo que ayude a la educación se basan
en:
1. Los creadores desean propiciar una experiencia divertida al usuario jugando con
sonidos y efectos visuales atractivos para él y acompañados de una historia o
narración que ayude a incrementar las ganas de jugar.
2. La motivación anteriormente comentada que proporcionan los juegos, ofrece el

desafío, suspense y curiosidad necesarios para atraer al usuario. Además, es muy
importante la capacidad de crear empatía de los jugadores con los personajes del
juego, de forma que se sientan identificados con ellos y muestren mayor interés
en conseguir los objetivos.
3. La capacidad del usuario de influenciar en el desarrollo de la historia de cier-

tos juegos según las acciones que tome, a diferencia de las narraciones que se
cuentan en libros o vídeos.
4. La posibilidad de acceder al progreso que tienen los jugadores gracias a la cuanti-

ficación de los resultados que se obtienen.
5. La obtención de objetivos que no podrían darse debido a la falta de alternativas

equivalentes, como puedan ser escenarios o casos en un mundo simulado.
2.2.1 Sentido del ritmo en diversos videojuegos

Los videojuegos donde la jugabilidad3 va ligada al ritmo de una canción son considera-
dos un subgénero de los juegos musicales, donde por lo general se basan en apretar
diferentes comandos o mover algún periférico en el momento justo de acuerdo a un
3 La jugabilidad describe la calidad del juego en términos de sus reglas de funcionamiento y de su
diseño como juego. Se refiere a todas las experiencias de un jugador durante la interacción con sistemas
de juegos.[6]
7
ritmo establecido. Dentro de esta categoría se incluyen los juegos de instrumentos

musicales, los juegos de baile y cualquier otro tipo de juego centrado en el ritmo.
Actualmente se encuentra una gran variedad de juegos de ritmo en el mercado
y cuyos usuarios finales no son necesariamente personas con discapacidades auditi-
vas. En la tabla 2.2 podemos observar distintos juegos y una breve explicación de su
funcionamiento, de los cuales se han extraído ideas para el desarrollo de Armonisia.
Videojuego Descripción
PaRappa the Rapper [7] Considerado uno de los primeros juegos de ritmo
modernos, PaRappa the Rapper sigue la historia de
un perro que quiere hacer rap. Para ello, el jugador
debe pulsar una combinación de botones según van
apareciendo en la pantalla y lograr que el personaje
pueda crear una canción.
Guitar Hero [8] Guitar Hero es una serie de videojuegos de música en
el que el usuario juega con un controlador en forma
de instrumento musical, como una guitarra o una
batería, para simular la interpretación de la música.
El objetivo es presionar los botones del controlador o
dispositivo en el momento exacto en el que las notas
se desplazan por la pantalla de juego.
Just Dance [9] Just Dance es una saga de videojuegos en la que el
usuario ha de realizar las coreografías de cada can-
ción siguiendo el ritmo marcado en la pantalla. La
forma de detectar los movimientos del usuario pue-
den ser a través de una alfombra en la que pisa el
jugador para marcar los pasos, o con un controlador
como el mando de una consola.
Cuadro 2.2: Videojuegos de género musical y basados en el uso del ritmo.
2.2.2 Videojuegos para personas con discapacidades auditivas

Existen diversos proyectos cuyo objetivo es el de ayudar a desarrollar las habilidades
motoras fundamentales y perceptivas en niños con discapacidades auditivas. En las
tablas 2.3 y 2.4 se observa un resumen de dichos sistemas interactivos y una breve
descripción de cómo funcionan [3].
8
2.2. Juegos serios
Habilidades motoras fundamentales

Competencia Proyecto Descripción
Coordinación The influence of El objetivo de este proyecto era examinar la in-
computer games fluencia del software especializado en la inte-
on visual–motor gración visual motriz de niños con discapacida-
integration in des auditivas profundas. Para ello, se hicieron
profoundly deaf pruebas con dos grupos de niños que utiliza-
children[10] ban juegos online para comprobar la velocidad
de sus actividades psicomotoras. Se demostró
que repitiendo esta actividad, los niños redu-
cían el número de movimientos innecesarios
para completar su tarea y aprovechaban más
los estímulos visuales que se les proporciona-
ban.
Postura Correcting El objetivo de este proyecto fue examinar la po-
Exercise Form sibilidad de utilizar una herramienta de correc-
Using Body ción en tiempo real para la postura de un usua-
Tracking[11] rio mientras realiza un ejercicio libre de peso.
Mediante el uso de una Kinect, el usuario po-
día verse en una pantalla mientras realizaba el
ejercicio a la vez que se le indicaban los requi-
sitos para realizarlo correctamente. Se demos-
tró que, gracias a la repetición constante de los
ejercicios, los usuarios sentían más seguridad
al realizar los movimientos.
Cuadro 2.3: Publicaciones relacionadas con las habilidades motoras fundamentales.
9
Habilidades motoras perceptuales

Competencia Proyecto Descripción
Espacial A Design Tem- El objetivo de este proyecto era mejorar la lo-
plate for Mul- calización del sonido (saber de dónde provie-
tisensory and ne el sonido) a través de teorías y bases para
Multimodal Ga- crear juegos electrónicos para niños con dis-
mes to Train and capacidades auditivas. Finalmente, se crearon
Test Children for 20 principios relevantes a tener en cuenta a la
Sound Localisa- hora de crear un videojuego. Dichos principios
tion Acuity abarcan diferentes áreas de un juego: diseño
multimedia, interacción con el usuario, diseño
de la historia, etc [12].
Temporal Saathi: Making El objetivo de este proyecto es crear un reloj in-
it Easier for Chil- teligente que muestre el tiempo mediante imá-
dren with Lear- genes o audios de la vida cotidiana de los niños
ning Disabilities con discapacidades auditivas. De esta forma, se
to understand les ayuda a comprender el concepto del tiem-
the concept of po y crear una rutina individual que les da la
Time[13] sensación de tener el control sobre su día a día.
Ritmo The Brave Little El objetivo de este proyecto es crear un juego
Troll - A Rhythmic educativo para niños de entre 4 y 7 años con
Game for Deaf discapacidades auditivas, con el fin de mejorar
and Hard of Hea- sus habilidades para identificar y crear patro-
ring Children[14] nes rítmicos. El jugador debe pasar por diversos
niveles en los que ha de crear dichos patrones
ayudado por un estimulo visual y utilizando las
teclas del ordenador.
Ritmo The Brave Little El objetivo de este proyecto es crear un nuevo
Troll - BoomCha- género de juego basado en el ritmo y el modo
Cha: A Rhythm- cooperativo. Se trata de un videojuego en el que
based, Physical tres jugadores utilizan diferentes armas físicas
Role-Playing (elementos controlados con Arduino) que mue-
Game that Fa- ven para crear ritmos.
cilitates Coope-
ration among
Players[15]
Cuadro 2.4: Proyectos relacionados con las habilidades motoras perceptuales.
10
CAPÍTULO
3
M ETODOLOGÍA
En este capítulo se define la metodología utilizada para la creación y diseño de Armoni-

sia.
3.1 Diseño centrado en el usuario

La filosofía seguida en la creación del videojuego ha sido el DCU, cuyo proceso se basa
en la creación de productos que puedan resolver problemas o necesidades de un grupo
de usuarios [16]. Su objetivo es conseguir la mayor satisfacción y experiencia con un
proceso iterativo de análisis de contexto de uso y requisitos de usuario, diseño del
producto y su evaluación. De esta forma, el feedback que se obtiene en las evaluaciones
sirve para volver a hacer un análisis de lo que se puede mejorar e implementar el diseño
en relación a esta nueva información obtenida para poder volver a evaluarla.
En la Fig. 3.1 se refleja dicho proceso detallando los elementos más importantes de
cada uno de los pasos para este proyecto. El análisis de contexto de uso y requisitos de
usuario se basó en un primer lugar en documentarse a través de trabajos relacionados
que se enfocaran en la creación de sistemas interactivos para niños con discapacidades
auditivas. Después de la creación de una propuesta inicial de videojuego, se presentó
en una reunión con ASPAS, donde se obtuvo la confirmación para seguir con la idea
presentada y se detallaron posibles cambios y requisitos a cumplir. Posteriormente se
inició la fase de diseño, comenzado por la creación de los personajes protagonistas y la
definición exacta de la forma de juego del proyecto. Esta primera etapa de diseño se
enfocó especialmente en la creación de personajes que proporcionaran empatía a los
futuros jugadores, teniendo en cuenta que pudiesen escoger el género del protagonista
y que estos llevaran un implante coclear. También se hizo especial hincapié en el reto
que supondrían los diferentes niveles y qué factores podrían añadirse para cambiar la
dificultad entre uno y otro, como el número y la velocidad de las notas o el tamaño de
las figuras sobre las cuales han de pulsar los usuarios.
La evaluación del sistema presentado se obtendrá con las pruebas de usuario que
11
3. M ETODOLOGÍA
se puedan realizar en el centro. De esta manera, se podrá conocer si la dificultad del

juego es la adecuada, si las funcionalidades desarrolladas son útiles o si faltaría añadir
otras más específicas. El sistema final será la primera versión del videojuego subida a la
plataforma Google Play Store.
Figura 3.1: Esquema del proceso de DCU utilizado.
12
CAPÍTULO
4
P ROCESO DE DISEÑO DEL VIDEOJUEGO
En este capítulo se explica el análisis y proceso de diseño seguido para dar forma
al proyecto. Se tratan los aspectos gráficos principales del juego, la creación de los
personajes, los elementos auditivos y la jugabilidad de los niveles según los requisitos
de usuarios obtenidos gracias a la comunicación con ASPAS.
4.1 Grupo de usuarios
El primer aspecto a tener en cuenta es el grupo de usuarios que utilizarán la aplicación

para poder establecer un contexto de juego acorde con sus capacidades y expectativas.
Armonisia está enfocado a niños cuyas edades se encuentren en el rango de 6 a 13
años, pudiendo jugar tanto niños con o sin discapacidades auditivas, obteniendo así
un juego inclusivo.
El rango de edades es bastante amplio, de forma que se ha pensado en un juego cuya
historia fuera fácil de entender para los más pequeños y que a la vez fuese interesante
para los más mayores.
Al hablar con la terapeuta de ASPAS, se estableció que el manejo del dispositivo
móvil o tableta para niños que comprendan esas edades no supondría ningún pro-
blema ya que ellos trabajan con dichas tecnologías en diversas ocasiones (acta de
reunión disponible en el anexo A.2). Teniendo en cuenta dicha capacidad de manejo
y la conducta de las nuevas generaciones con la tecnología [6], se pueden extraer los
siguientes requisitos:
• El juego debe ser visualmente intuitivo.

• El juego debe poder ser interpretado mediante el descubrimiento de los usuarios
y no con explicaciones detalladas.
• El juego debe centrar la atención del usuario en la tarea principal.
13
4. P ROCESO DE DISEÑO DEL VIDEOJUEGO
4.2 Diseño gráfico

Más allá del objetivo de entrenamiento del ritmo, la principal característica del proyecto
es crear un sistema interactivo que sea divertido e interesante para sus usuarios, donde
el factor visual cobra una gran importancia.
4.2.1 ¿Por qué 2D?

La elección de un diseño 2D se ha basado principalmente en la facilidad de crear
gráficos 2D frente a gráficos 3D con profundidad. No obstante, existen otros factores
importantes que han sido tenidos en cuenta para dicha elección.
Un diseño 2D tiene la capacidad de ser claro y conciso, lo que hace más fácil
de asimilar al público que lo observa. Esto es un factor clave teniendo en cuenta el
grupo de usuarios al que va dirigido la aplicación, ya que como se ha mencionado en
los requisitos anteriormente, el diseño debe ser sencillo y agradable para los niños o
usuarios que vayan a jugar.
Entrando en un aspecto más técnico, un diseño 2D es más económico en la mayoría
de los casos, ya que es más rápido de crear. También se ha de tener en cuenta que es
más ligero de procesar y por lo tanto no requiere de tantos recursos hardware.
Teniendo en cuenta todas estas ventajas y el tiempo necesario para la formación en
desarrollo de videojuegos, un diseño 2D parecía lo más apropiado.
4.2.2 Storyline
La historia de Armonisia está pensada con el fin de crear expectación e interés en los
niños que jueguen de forma que se vean inmersos en una historia y se entusiasmen
con la meta a conseguir. La historia se irá desarrollando con pequeñas animaciones
antes de cada nivel donde el/la protagonista mantiene una conversación con diversos
personajes que darán un sentido al objetivo de cada uno de los niveles.
La historia está protagonizada por un niño o niña (el género y nombre es de libre
elección por parte del jugador), el cual se caracteriza por utilizar un implante coclear.
En su aventura conoce a un pequeño dragón que le acompaña y juntos deben superar
los objetivos de la historia mientras son controlados por el jugador.
El desarrollo del videojuego se lleva a cabo en un reino mágico en el que nuestro/a
protagonista entra después de haber sido tragado por un misterioso libro que encuentra
en su casa. Una vez allí, sorprendido del lugar donde se encuentra, se da cuenta de
que todo a su alrededor parece triste y con poco color: las flores están secas, no hay
rastro del sol y el bosque donde se encuentra está apagado. En ese mismo lugar aparece
un elfo vestido de verde y el protagonista decide preguntarle dónde está, la respuesta
no tarda en llegar: "Te encuentras en el reino de Armonisia, aunque ya no parece el
mismo". Cuando el protagonista pregunta a qué se refiere con eso último, el pequeño
ser le contesta que desde hacía un tiempo todo el reino había perdido la alegría y la
magia que lo rodeaban, pues inesperadamente el rey había desaparecido y el ritmo se
había ido por completo de sus tierras: Los habitantes ya no podían tocar instrumentos,
el tiempo cambiaba descontrolado en todo momento porque el reloj no seguía el
mismo compás que antes, el mar no tenía olas... Y todo lo que se conseguía con ritmo
14
4.2. Diseño gráfico
había perdido su movimiento o forma de ser, pero sabía que él/ella era la persona que
estaban esperando para poder solucionarlo.
Angustiado por no creer ser capaz de ayudarlos, el elfo insiste en que el niño/niña
sabrá cómo hacerlo y le presenta a su compañero de aventuras: Rytmus, un pequeño
dragón que, contento y juguetón, comienza a volar alrededor de ellos. Finalmente el/la
protagonista decide ayudar con lo que pueda y el elfo se marcha deseándole buena
suerte y despidiéndose con su nombre, creando aún más misterio.
El primer nivel se centra en el personaje de Rytmus, después de que el/la protagonis-
ta le indique el camino para comenzar su aventura. Está diseñado para que el usuario
obtenga experiencia y aprenda como utilizar y jugar con el sistema interactivo. Después
de superarlo, el segundo nivel presenta una animación donde ambos personajes se
encuentran en un lugar oscuro y tenebroso, donde un chico calabaza les sorprende
al aparecer corriendo. A pesar del susto inicial, descubren que el misterioso ser es un
viejo conocido de Rytmus y acaba por indicarles cómo llegar al castillo del rey Compás,
no sin antes advertirle de que deben esquivar a Cerebrín, un zombie nada amistoso
desde que el ritmo ha desaparecido del reino.
Después de superar el segundo nivel, los protagonistas se encuentran en un lugar
caluroso y desértico, en el cual aparece un orco acusándoles de no encontrar sus
diamantes. Una vez que el/la protagonista convence al monstruo verde de que ellos no
tienen nada que ver, hacen un trato: Ellos le ayudarán a recoger todos los diamantes si
a cambio el orco les indica cómo llegar al castillo, pues no sabían por dónde seguir. El
ser de color verde nunca ha salido de la zona arenosa del reino, pero asegura conocer a
alguien que sabe cómo llegar a cualquier parte de Armonisia.
El cuarto nivel presenta a los protagonistas en un escenario completamente diferen-
te, el lugar es frío y nevado, y la figura que se presenta ante ellos no es nada más y nada
menos que el mismo Santa Claus, quien esperaba su llegada, pues él era el conocido
del que el orco hablaba. Santa Claus quiere ayudar a ambos personajes a llegar hasta el
castillo, pero todos los regalos que tenía que llevar parecen haber cobrado vida propia
y han escapado de su trineo. El niño/a y Rytmus deciden ayudar a Santa Claus sin
ninguna duda.
4.2.3 Técnica de juego
La técnica de juego se basa en la visualización de uno de los personajes sobre la pantalla

y de unos círculos de colores que son los botones sobre los cuales debe pulsar el jugador
para hacer el ritmo sobre el dispositivo. Sobre la pantalla van pasando diversos objetos
y, cuando estos atraviesen una de las esferas, será el momento en que el usuario deba
pulsar sobre ella para conseguir puntos. De esta forma, se pretende que el jugador
marque un ritmo sobre la pantalla ayudado por el estimulo visual de los objetos y los
círculos, además de la música que acompaña de fondo y el sonido que se reproduce al
pulsar sobre los diferentes botones. A medida que se va recorriendo el reino mágico,
cada nivel incrementa la dificultad modificando la cantidad de notas de la melodía,
la velocidad en la que se mueven y el tamaño y posición en la que se encuentren los
círculos sobre los cuales ha de pulsar.
Además, sobre la pantalla se puede visualizar una barra gráfica que representa la
puntuación que va obteniendo el jugador, de forma que cuando se van obteniendo
15
más puntos, la barra se va rellenando y el número que se encuentra encima de ella va

aumentando su valor.
En la Fig. 4.1 se puede observar un primer boceto de lo que sería la pantalla o

escena de uno de los niveles. En este caso, el personaje sería el dragón, mientras que
los objetos que caen sobre los botones en forma de círculos son notas musicales.
Figura 4.1: Boceto inicial de una pantalla de nivel.
4.3 Requisitos de usuario
A continuación se describen los requisitos no funcionales (tabla 4.1) y los requisitos

funcionales (tabla 4.2) de la aplicación, con el objetivo de conocer las funcionalidades
que debe tener el videojuego.
Nº Requisito Descripción
El juego estará desarrollado para dispositivos móviles y tabletas
RNF-1
con sistemas operativo Android.
La interfaz gráfica será atractiva y fácil de utilizar para el grupo
RF-8 de usuarios objetivo. Se tendrá que tener en cuenta la edad de
los usuarios y crear una interfaz llamativa.
Cuadro 4.1: Requisitos no funcionales del proyecto.
16
4.4. Interfaz gráfica de usuario
Nº Requisito Descripción
El juego presentará diferentes patrones rítmicos con diferen-
tes señales visuales y auditivas que pueden ir aumentando su
dificultad. El sonido se ha agregado para aquellos jugadores
que tengan alguna capacidad auditiva. El juego presentará dife-
rentes niveles comenzando con ritmos fáciles y aumentando la
RF-1 complejidad a medida que se van superando. En cada uno de
los niveles habrá una base musical que sonará continuamente y
el jugador deberá encajar los objetos que caen sobre las esferas
de colores. Los objetos caerán siguiendo un patrón rítmico defi-
nido y cada una de las esferas o botones de colores tendrán un
sonido asociado.
El usuario deberá ser capaz de escoger el personaje protagonista
RF-2
en versión femenina o masculina.
El sistema interactivo registrará información y datos sobre la
puntuación obtenida por el usuario en cada nivel para después
RF-3
poder crear un reporte que sea accesible para los terapeutas o
educadores.
El juego tendrá un menú de configuración principal que permita
RF-4
activar y desactivar la música y los sonidos al pulsar botones.
Cada nivel tendrá su propio menú de configuración que per-
RF-5 mita modificar el volumen de la base musical y de las notas en
cualquier momento de ejecución del nivel.
Cada nivel contendrá una escena inicial que continúe la historia
RF-6 del juego y le de un sentido a dicho nivel con el fin de entretener
al usuario.
Cada nivel contendrá elementos que muestren al jugador el
RF-7
progreso o puntuación que llevan en tiempo real.
Cuadro 4.2: Requisitos funcionales del proyecto.
4.4 Interfaz gráfica de usuario

En esta sección se trata el estilo visual general del proyecto, el proceso de creación de
los personajes y las diferentes pantallas que conforman el videojuego.
Se puede encontrar la fuente de aquellos gráficos que no han sido creación propia
en el anexo A.1.
4.4.1 Estilo visual

El aspecto gráfico de este proyecto se basa en un estilo sencillo, de trazos marcados y
colores llamativos, tanto para los personajes como para los elementos que componen
las diferentes escenas del videojuego.
La interfaz gráfica de usuario utilizada ha sido un set de ventanas, iconos y botones
de temática medieval y fantasía que encajaba con el estilo visual y el contexto que se le
quería proporcionar a Armonisia.
17
Los colores principales utilizados para dicha interfaz son las diferentes tonalidades
de verde y un color marrón que simula la textura de la madera.
4.4.2 Personajes
La creación de los personajes de este proyecto se pueden dividir en personajes princi-
pales y personajes secundarios. Los primeros, haciendo referencia al pequeño dragón
Rytmus y al personaje protagonista tanto femenino como masculino, han sido diseña-
dos y creados desde cero, mientras que los personajes secundarios se han obtenido de
diversos bancos de gráficos para juegos 2D.
Principales
Los personajes principales fueron diseñados desde cero con el fin de crear empatía con
los usuarios finales del juego. El personaje principal tiene tanto una versión masculina
como una versión femenina, y ambos son caracterizados por llevar un implante coclear.
Cabe mencionar que existen diferentes implantes, audífonos o prótesis en el mercado y
que son utilizadas por niños con diferentes discapacidades auditivas, pero se ha optado
por una versión simple y clara que pueda representar de forma general este tipo de
dispositivos médicos, tal y como se muestra en la Fig. 4.2.
Figura 4.2: Implante coclear real y representación gráfica en el personaje principal.
De esta manera, los niños que jueguen con Armonisia podrán escoger el personaje
y sentirse reflejados en el héroe o heroína de la historia.
El primer paso fue crear los bocetos a mano de ambas versiones y utilizar los trazos
del cuerpo como guía para un posterior diseño a ordenador. El programa utilizado
para dar forma y color fue el editor de gráficos vectoriales Inkscape. Cada uno de los
personajes fue divido en partes del cuerpo, facilitando así el dibujo y permitiendo crear
posteriormente sus animaciones y movimientos con el motor de Unity. Así pues, como
se observa en la Fig. 4.3, los dibujos de ambos personajes se basaron en: Brazos, manos,
piernas, pies, tronco y cabeza (incluyendo las versiones de gesto feliz, gesto dormido,
gesto sorprendido y gesto de dolor). En el caso de la versión femenina, se dibujó una de
las coletas separada de la cabeza con el objetivo de dar más movimiento y realismo a la
animación.
En la Fig. 4.4, se puede observar la diferencia entre los primeros bocetos a mano y
el dibujo final de los personajes con las partes del cuerpo ya unidas.
18
Figura 4.3: Gráfico por partes del cuerpo del protagonista en versión masculina y
femenina.
Figura 4.4: Esbozos y gráficos finales de la versión masculina y femenina del protago-
nista.
De la misma forma que se trabajó con ambas versiones del protagonista, el perso-
naje de Rytmus fue dibujado a mano para después tratarlo gráficamente por ordenador.
En la Fig. 4.5 se puede visualizar tanto el esbozo inicial como el gráfico final por partes
del cuerpo (cabeza y sus múltiples gestos, cola, versiones de cuerpo, piernas, brazos,
cola y llamarada que será utilizada en las animaciones).
Secundarios
Los personajes secundarios se han obtenido de diferentes fuentes web que ofrecían los
gráficos de forma gratuita. Los personajes utilizados han sido los siguientes: elfo, chico
calabaza, zombie, orco y Santa Claus.
Por un lado, el gráfico del elfo se ha obtenido por partes del cuerpo, de la misma
manera que se han creado los personajes principales. Por esta razón, la animación y
movimiento del personaje sí que ha sido creación propia. Para este caso se han creado
tres animaciones: estado de reposo, personaje hablando y personaje caminando.
Por otro lado, los personajes restantes han sido obtenidos de forma diferente, pues
sus gráficos no estaban separados por partes del cuerpo, sino que se han creado un
gran número de gráficos del cuerpo entero (como el de la Fig. 4.6) por cada animación
que realizaba. De esta manera, para una sola animación puede existir, por ejemplo, 8
19
(a) Esbozo inicial y gráfico final.
(b) Gráficos por partes del cuerpo.
Figura 4.5: Evolución de la creación de Rytmus.
gráficos del personaje que al ir pasando de uno a otro a gran velocidad, se crea el efecto
de movimiento.
Figura 4.6: Gráficos del personaje zombie utilizados para crear la animación de ataque.
4.4.3 Niveles
A continuación, se detalla la estructura general de los niveles del videojuego y se presen-
tan los diferentes niveles y su temática. Para la realización del TFG se han implementado
los cuatro primeros niveles del videojuego, los cuales funcionan como concepto del
juego final y sirven a la hora de realizar las pruebas con el grupo de usuarios objetivo.
En la Fig. 4.7 podemos observar un esquema de los niveles creados hasta el momento.
Figura 4.7: Esquema del orden de los niveles de Armonisia.
20
Estructura general
Siguiendo el esbozo ilustrado en el apartado 3.2.3, cada uno de los niveles cuenta con
uno de los personajes en pantalla y el llamado pentagrama que representa la sección
de los botones de colores y los objetos que caen o se mueven sobre ellos. Además, cada
nivel cuenta con una barra de progreso que muestra la puntuación en cifras hasta el
momento y proporciona información rápida de cómo se va avanzado. También cuenta
con un contador de notas, donde se muestra la cantidad de aciertos en relación al
número total de notas que hay en cada nivel.
Para posibilitar la configuración del volumen de la música de fondo, los sonidos de
los botones y la capacidad de volver al menú inicial o reiniciar el nivel, se presenta en
cada nivel un botón de configuración que activa el menú correspondiente y pausa la
partida actual. Además, cada nivel incluye una cuenta atrás de tres segundos tras la cual
se inicia la música para que de tiempo al usuario a situarse sobre la pantalla. También
existe un texto de bonus sobre el pentagrama musical que aparece cada vez que el
jugador acierte una cierta cantidad de notas seguidas, haciendo que las puntuaciones
de cada nota acertada a partir de ese momento se multiplique por el número que ha
marcado el bonus. Cuanto más notas seguidas se acierten, más grande será el bonus
(x2, x3 y x4).
La puntuación estándar obtenida por cada nota acertada es de 100 puntos, por lo
que al conseguir un bonus, cada nota puede llegar a valer 200, 300 y hasta 400 puntos.
En el momento en que el usuario falle una de las notas, la bonificación extra por cada
nota se pierde y cada acierto vuelve a sumar 100 puntos hasta que se vuelva a conseguir
otro bonus.
Así pues, no se obtiene el mismo resultado si un jugador falla, por ejemplo, cinco
notas que caen seguidas o cinco notas aleatorias del patrón musical. Con este sistema
de puntuación se quiere motivar aún más al usuario mostrando las bonificaciones
extras que consigue con la continuidad de aciertos.
En los siguientes apartados se explica con detalle la estructura de cada uno de los
niveles y la puntuación máxima que se puede obtener en cada uno de ellos.
Sky Level
El primer nivel fue el más complicado de implementar, pero sirvió como modelo para
los demás niveles una vez que estaba casi finalizado.
La temática del primer nivel se basa en una melodía simple y alegre sobre la cual
Rytmus vuela sobre el cielo. Los objetos que representan las notas son gotas de agua
que simulan caer del cielo sobre el cual el pequeño dragón vuela (Fig. 4.8). Cada vez
que se consiga llegar a un bonus por acertar ininterrumpidamente las notas, Rytmus
cambiará de animación para continuar volando mientras hecha una llamarada por su
boca. En el caso de que el usuario falle las notas, el dragón sacará humo disgustado.
El pentagrama consta de cinco notas musicales ordenadas de derecha a izquierda,
siendo las primeras las más graves. Las notas, en este caso las gotas de agua, son un
total de 41 y caen de arriba hacia abajo a una velocidad estándar. La mayor puntuación
que se puede obtener en el nivel es de 11600 puntos.
21
(a) Animación previa con los personajes del elfo

y la versión femenina del protagonista.
(b) Captura del nivel con bonus de puntuación

conseguido.
Figura 4.8: Capturas de la animación y pantalla de juego del nivel Sky Level.
Cemetery Level
El segundo nivel se basa en un contexto de miedo, siendo el escenario principal un

cementerio donde se encuentran los personajes de un chico con cabeza de calabaza de
Halloween y un zombie. El primero aparece en la animación de introducción al nivel,
mientras que el segundo aparece en la pantalla de juego junto al pentagrama (Fig. 4.9).
A pesar de tratarse de un nivel ambientado en una temática terrorífica, se ha realizado
con un diseño e historia que no asustara al grupo de usuarios objetivo, al igual que la
música que presenta una melodía tenebrosa y con unas notas que provocan sensación
de tensión.
Las notas de este nivel son representadas por unos ajos que se mueven de derecha
a izquierda. El pentagrama está formado por cuatro notas ordenadas de abajo arriba,
siendo las primeras las más agudas, imitando a un pentagrama musical real. El número
total de ajos es de 35 y la puntuación máxima posible a conseguir es de 9200 puntos.
Cada vez que el jugador consiga un bonus, el zombie realizará la animación de
mover sus brazos hacia las notas, en señal de ataque.
La peculiaridad de este segundo nivel se basa en los círculos de colores sobre los
cuales pulsa el jugador, pues a mitad de la canción estos cambian de tamaño y de color,
pues representan otras notas musicales. La modificación de su dimensión a una más
pequeña es una dificultad añadida para el jugador, ya que habrá de ser más preciso a la
hora de pulsar sobre ellos y tendrá menos margen para acertar la nota cuando pase el
objeto por el círculo de color.
22
(a) Animación previa con los personajes del chi-

co calabaza, Rytmus y la versión masculina del
protagonista.
(b) Captura del nivel con los botones circulares

reducidos.
Figura 4.9: Capturas de la animación y pantalla de juego del nivel Cemetery Level.
West Level
El tercer nivel gira entorno al estilo del desierto del Oeste. La música de fondo es
de género Western, mientras que el sonido de las notas pertenece a una guitarra. En
este caso, el pentagrama musical está conformado por seis notas y los objetos que las
representan son unas esmeraldas que siguen un movimiento de derecha a izquierda en
la pantalla.En la animación introductoria se presenta el personaje de un orco verde,
mientras que en la escena de juego aparece el/la protagonista del videojuego (Fig. 4.10).
Tanto en la versión femenina como en la versión masculina, el protagonista dará
un salto cuando se consigan bonus por acertar notas seguidas, y recreará cara de dolor
y estrellas a su alrededor cuando el jugador las falle.
La dificultad del nivel ambientado en el desierto viene dada por el patrón de las
notas musicales que aparecen de manera más seguida. Además, la existencia de seis
círculos de colores en el pentagrama posibilita que el patrón musical tenga saltos de
extremo a extremo entre notas, es decir, puede pasar una nota por uno de los extremos
del pentagrama y la siguiente por el extremo contrario, haciendo que el desplazamiento
del dedo del usuario tenga que ser mayor.
El número total de notas en este nivel es de 50, mientras que la puntuación máxima
que se puede obtener es de 15200 puntos.
23
(a) Animación previa con los personajes del Or-

co, Rytmus y la versión femenina del protago-
nista.
(b) Captura de la pantalla de juego con gran

cantidad de notas seguidas.
Figura 4.10: Capturas de la animación y pantalla de juego del nivel West Level.
Christmas Level
El cuarto nivel sigue una temática navideña, donde el personaje principal tanto de la
animación como de la pantalla del juego es Santa Claus (Fig. 4.11). La música de fondo
sigue una melodía inspirada en los villancicos, mientras que el sonido de las notas se
representa con un sample electrónico1 .
Santa Claus dará un salto cada vez que se consiga un bonus por acertar notas
seguidas, mientras que cuando se fallen, la animación será la del personaje cayéndose.
El pentagrama está formado por cinco sonidos de notas diferentes que caen de
arriba a abajo, las cuales están representadas por paquetes de regalo. En total el nivel
contiene 75 notas, y la puntuación máxima posible a obtener es de 26700 puntos.
La dificultad del nivel se basa en la velocidad aumentada de las notas al caer sobre
los círculos de color. También aumenta la complicación la gran cantidad de notas que
aparecen, lo que supone que el usuario ha de estar más cantidad de tiempo concentrado
y en movimiento que en el resto de niveles.
1 Muestra de un sonido grabado en cualquier tipo de soporte para reutilizarla posteriormente como
un instrumento musical o una grabación de sonido diferente.
24
(a) Animación previa con los personajes de San-

ta Claus, Rytmus y la versión femenina del pro-
tagonista.
(b) Captura de la pantalla de juego con gran

variedad de notas.
Figura 4.11: Capturas de la animación y pantalla de juego del nivel Christmas Level.
4.4.4 Otras pantallas

En esta sección se describen aquellas pantallas que no sean las de juego propiamente
dicho. Entre ellas encontramos la pantalla principal, menú de opciones, información,
mapa de niveles y puntuación. Todas ellas siguen el mismo estilo de botones y ventanas
descrito anteriormente.
Inicio
La pantalla de inicio (Fig. 4.12) de Armonisia muestra el título del videojuego y dispone
de cuatro botones. Los dos principales y situados en el centro tienen las funcionalidades
principales: El botón para comenzar a jugar y el botón para visualizar las puntuaciones
de cada nivel. En la esquina inferior derecha se encuentran dos botones de menor
tamaño, uno encargado de visualizar el menú de opciones y el otro de mostrar la
pantalla de información sobre el juego.
Menú de opciones
El menú de opciones al que se puede acceder desde la pantalla inicial o desde el mapa
de niveles se puede observar en la Fig. 4.13. Las funcionalidades implementadas en
dicho menú posibilitan al usuario activar o desactivar tanto la música ambiente que
25
Figura 4.12: Pantalla de inicio de Armonisia.
existe en las pantallas que no son niveles, como los sonidos que suenan cuando se
pulsa un botón.
Las banderas que se encuentran en la parte inferior pretenden ser botones para
cambiar el idioma del videojuego. No obstante, hasta la realización de este TFG no se
ha implementado el cambio de idioma, sino que se ha preparado el diseño gráfico que
tendría para el usuario. Cada bandera sería un botón y destacaría en mayor tamaño y
con más iluminación el idioma seleccionado, como lo hace en este caso el castellano. En
la esquina inferior izquierda se encuentra un botón para cerrar la pantalla de opciones
y volver a la pantalla inicial.
Figura 4.13: Menú de opciones principal.
Información
La pantalla de información (Fig. 4.14) muestra en la parte izquierda los logos de la

UIB, la Escuela Politécnica Superior (EPS) y la OCDS, mientras que en la derecha se
encuentra un texto deslizable que proporciona información sobre el modo de juego y
los participantes en el proyecto.
26
Figura 4.14: Pantalla de niveles de Armonisia.
Mapa de niveles
El mapa de niveles es la pantalla encargada de mostrar los niveles desbloqueados y

bloqueados para el usuario. En la Fig. 4.15 se puede observar un ejemplo donde el
jugador tiene los cuatro primeros niveles desbloqueados. Además, debajo de cada uno
de los niveles superados se muestran las estrellas conseguidas, mientras que el nivel
cuatro no tiene ninguna porque todavía no se ha superado. Todos los niveles pueden
volver a jugarse para mejorar la puntuación obtenida.
En la parte inferior se encuentran cuatro botones. De izquierda a derecha realizan
las siguientes funciones: botón para volver a la pantalla inicial, botón para mostrar el
menú de opciones, botón para ir a la pantalla que muestra las puntuaciones obtenidas
y botón para ir a la pantalla de información.
Figura 4.15: Pantalla de inicio de Armonisia.
Configuración del personaje
En el momento de jugar por primera vez con Armonisia e iniciar el nivel uno, se le
solicita al usuario que escoja uno de los personajes principales posibles (versión feme-
nina o masculina), para después mostrar un input donde se puede indicar el nombre
27
que el jugador desea que represente a dicho personaje (Fig. 4.16). La primera pantalla
contiene un botón derecho e izquierdo para ir cambiando de personaje, mientras que
la segunda simplemente muestra el botón para comenzar el juego que se activa una
vez se haya introducido el nombre.
(a) Pantalla de selección de personaje.
(b) Pantalla de configuración de nombre.
Figura 4.16: Pantallas de configuración al jugar por primera vez con Armonisia.
Pantalla fin de nivel
Cada vez que se finalice uno de los niveles, aparece una pantalla que muestra la puntua-
ción obtenida e indica al usuario si ha superado el nivel o no. Esta escena puede ser de
dos tipos diferentes (Fig. 4.17), una versión cuando el nivel se ha superado y por lo tanto
aparece el personaje feliz y se obtienen las estrellas acorde a los puntos conseguidos,
y una versión cuando el nivel no ha sido superado y se muestra al personaje con un
gesto de derrota. En el primer caso, la pantalla cuenta con un botón de continuar que
devuelve al usuario al mapa de niveles, mientras que el segundo caso, se presentan dos
opciones: volver al menú principal o repetir el nivel.
Puntuación
La pantalla de reporte (Fig. 4.18) muestra las puntuaciones obtenidas en cada uno de
los niveles que se han superado. La información de la que dispone el usuario sobre
cada nivel se enumera a continuación:
1. Estrellas: En la parte superior del recuadro se muestra el número de estrellas

correspondiente a la puntuación obtenida en el nivel.
28
(a) Pantalla cuando un nivel se ha su-(b) Pantalla cuando un nivel no se ha

perado. superado.
Figura 4.17: Pantalla de fin de nivel en sus dos versiones: Nivel superado y nivel no
superado.
2. Fecha: En la parte superior derecha se muestra la fecha de la última vez que se

jugó al nivel.
3. Puntos: Dentro del recuadro de información, en la parte superior izquierda se

puede visualizar la máxima puntuación obtenida para ese nivel.
4. Notas: En la parte inferior izquierda se muestra el número de notas acertadas en

relación al número total de notas que hay en el nivel.
5. Volumen música y volumen sonido: En la parte derecha se muestra el volumen

al que se encontraban tanto la música de fondo como la del sonido de las notas.
Dicho volumen se mide con un rango de 0 a 1, siendo 0 la ausencia total de sonido
y 1 el volumen máximo posible.
6. Número de partidas: En la parte inferior derecha, bajo el recuadro principal de

la información, se puede visualizar el número total de veces que el usuario ha
repetido y completado el nivel.
Figura 4.18: Pantalla de reporte/puntuaciones de Armonisia.
29
4.5 Música y sonidos

La utilización de música y sonidos en un juego cuyo objetivo es entrenar el ritmo de
los jugadores parece indiscutible, pero no se ha de olvidar que el grupo de usuarios
principal al que va dirigido son niños con discapacidades auditivas. Así pues, el uso de
música ambiente o las notas utilizadas para crear el ritmo cuando el jugador acierta fue
analizado y debatido con Carme Zoilo (terapeuta de ASPAS), ya que no se quería crear
desventaja en ciertos jugadores. Se llegó a la conclusión de que dichos sonidos eran
importante que estuvieran incluidos, siempre y cuando el volumen de estos pudiesen
ser configurados por separado. De esta forma, se puede tener un control sobre cómo
se comportan los niños y qué puntuación obtienen con diferentes configuraciones de
volumen de música ambiente y volumen de las notas que marcan el ritmo.
Una vez confirmado el uso de música, fue importante crear canciones diferentes
para cada uno de los niveles. Tal y como indica Oscar Araujo, compositor de bandas
sonoras de diversos videojuegos como ’Castlevania: Lord of Shadow’ [17]:
"Pienso, y piensan los productores de los juegos, que la música es mucho más importante
en el videojuego que en el cine, porque hace que te creas aun más la historia, los gráficos
y los personajes." - Óscar Araujo.
Así pues, tanto la música base como los sonidos de ritmo están creados especial-
mente para cada uno de los niveles, de forma que la armonía y la tonalidad de las notas
complementan el contexto en el que se encuentra dicho nivel. Tanto las canciones de
base, como los sonidos de ritmo y la canción principal del juego que se han utilizado en
el menú y pantallas de configuración o de información, han sido compuestas y creadas
por Carlos Tenorio Pérez.
30
CAPÍTULO
5
D ESARROLLO E IMPLEMENTACIÓN
En este capítulo se tratan los aspectos técnicos y la estructura del proyecto. Así mismo,
se explican las tecnologías y herramientas utilizadas y las razones de su uso. Por último,
se establece el flujo normal que sigue un usuario por las pantallas de Armonisia.
5.1 Herramientas de desarrollo

A continuación se detallan las diferentes herramientas o tecnologías utilizadas para el
desarrollo del proyecto.
5.1.1 Unity
Al investigar qué herramienta utilizar como motor de videojuego para el desarrollo
de Armonisia, destacaban dos tecnologías: Unity y Cocos2D. Después de leer varias
comparativas la decisión final fue la de utilizar Unity, y en esta sección se explicarán las
razones y la estructura que tiene dicho motor.
¿Por qué Unity?
En la actualidad, Unity es uno de los motores de videojuegos multiplataformas más

importantes y conocidos del mundo de la programación. Destaca sobre todo por la
facilidad que proporciona trabajar a los programadores y diseñadores y por la capacidad
de poder exportar el trabajo final a diversas plataformas tanto para ordenador, consolas
o dispositivos móviles, sin la necesidad de realizar demasiados cambios.
A pesar de ser en sus inicios un entorno para juegos 3D, desde la versión 4.6, el motor
de Unity ofrece un entorno de desarrollo para juegos 2D que simplifica el desarrollo
con la física 2D y cámara 2D entre otros.
El desarrollo de este proyecto se ha realizado utilizando su versión gratuita, la
cual proporciona las funcionalidades necesarias para crear un videojuego sencillo.
No obstante, Unity cuenta con versiones de pago profesionales con las cuales se han
31
5. D ESARROLLO E IMPLEMENTACIÓN
realizado videojuegos muy conocidos a día de hoy, tales como Flat Kingdom o Angry
Birds 2 [18]. La ventaja de Cocos2D es que es totalmente gratuito en todas sus versiones
y de código libre, pero la opción gratuita de Unity incluía todas las funcionalidades
necesarias para este proyecto.
Las principales ventajas que ofrece éste motor de videojuegos frente a Cocos2D se
citan a continuación:
• Capacidad de utilizar diversos lenguajes de programación: C#, Javascript y Boo,

mientras que Cocos2D solo ofrece C++. La elección para el proyecto de éste TFG
ha sido C#.
• Documentación extensa y completa tanto en español como en inglés [19].
• Tienda online que contiene recursos (materiales, efectos, scripts...) creados por
otros desarrolladores, tanto gratuitos como de pago, que pueden ayudar rápida-
mente al desarrollo de ciertas funciones o diseños [20].
• Tecnología multiplataforma: móvil y tableta (iOs, Android, Windows Phone y

BlackBerry), navegador (con Unity Web Player y HTML 5), consola (Xbox, PlayS-
tation y Wii) y escritorio (PC, Mac y Linux). En este sentido, Cocos2D solo ofrece
plataforma móvil.
Estructura
Los proyectos realizados con Unity se basan en el uso de paquetes de recursos, normal-
mente conocidos como Assets. Dichos paquetes contienen los recursos necesarios para
el desarrollador, como animaciones, efectos y materiales entre otros.
En el caso del proyecto Armonisia, la estructura general del proyecto es la siguiente:
• Animations: Contiene todas las animaciones de los personajes y notas de los

niveles, y efectos de movimiento de elementos de la interfaz como puedan ser
los botones.
• Backgrounds: Contiene los fondos utilizados en cada una de las pantallas del
videojuego. Algunos contienen un efecto de movimiento llamado Parallax, se
trata de una imagen en movimiento a una velocidad diferente al fondo que la
contiene. De esta manera, si uno de los personajes tiene una animación donde
mueve las piernas pero siempre se mantiene en el mismo punto del eje X, el
movimiento del fondo produce la sensación de avance del personaje.
• Fonts: Contiene las fuentes utilizadas para los textos del videojuego.
• Music: Contiene todas las canciones y efectos de sonido del videojuego, ya sean
bases musicales o el sonido al pulsar uno de los botones.
• Prefabs: Definidos como un tipo de asset, ya sea un objeto como un personaje

o una nota, que permite almacenar un GameObject completamente con sus
respectivos components y propiedades. De esta forma, si un mismo objeto se
reutiliza en varias ocasiones, no será necesario editarlo uno a uno, sino que todos
los prefabs se modificarán a la vez.
32
5.1. Herramientas de desarrollo
• Scenes: Las escenas de un proyecto contienen los objetos del videojuego. A nivel
visual se pueden interpretar como las diferentes pantallas que ven los usuarios,
como el menú principal, cada uno de los niveles, la pantalla de puntuación, etc.
• Scripts: Los scripts contienen el código que permite accionar los eventos del
videojuego, modificar componentes de los objetos y responder a las interacciones
del usuario con el videojuego.
• Sprites: Los sprites son objetos gráficos 2D. Es decir, son todas las imágenes
utilizadas para crear gráficamente los objetos en Unity, como sean las partes del
cuerpo de los personajes principales, los botones o las ventanas.
5.1.2 Monodevelop
El entorno de desarrollo integrado o Integrated Development Environment (IDE) utili-
zado ha sido Monodevelop, proporcionado con Unity. Es libre y gratuito, y proporciona
las operaciones básicas de un editor de texto con características adicionales para depu-
rar y gestionar tareas sobre el proyecto.
El entorno fue diseñado especialmente para los lenguajes de programación C#,
Boo, Java o Python. Para el desarrollo de este proyecto, se ha utilizado el lenguaje de C#
debido a la facilidad de comprensión que suponía y por ser el lenguaje más utilizado
por los usuarios de Unity.
5.1.3 InkScape
Para la realización de los gráficos de los personajes principales y de Rytmus, así como
para las ediciones de elementos como botones o ventanas, se ha utilizado la herramien-
ta gratuita y de código libre Inkscape. Se trata de un editor de gráficos vectoriales que
permite crear todo tipo de ilustraciones complejas. Es muy utilizado por los usuarios
que buscan programas open source1 .
5.1.4 Sistema de control de versiones

Con el fin de gestionar los cambios del proyecto de forma fácil y eficiente, se ha hecho
uso del software de control de versiones Git. Gracias a esta herramienta se puede dispo-
ner de un repositorio donde está alojado el código y crear ramas, a partir de la versión
master, que permiten crear diferentes funcionalidades de forma independiente. Es una
gran ventaja, sobre todo, para desarrollos donde trabaja más de una persona, pero en
este caso ha sido muy útil para ordenar y separar la implementación de diferentes pan-
tallas. Además, el control del código mediante una herramienta de este estilo, permite
tener una copia de seguridad en la nube. En este caso, se ha creado el repositorio del
código en GitHub.
Otro factor importante es que se trata de un videojuego que seguirá siendo desarro-
llado en un futuro, por lo que permitir descargar el código y seguir trabajando en él con
el uso de Git, aporta flexibilidad a la hora de continuar con el proyecto.
1 El software de código abierto (en inglés open source) es el software cuyo código fuente y otros
derechos que normalmente son exclusivos para quienes poseen los derechos de autor, son publicados
bajo una licencia de código abierto o forman parte del dominio público.
33
5.2 GameObjects y Scenes

El concepto más importante a la hora de utilizar y programar con Unity es el de Ga-
meObject. Cada uno de los elementos u objetos que se crean en un videojuego es un
GameObject, desde un botón de la interfaz gráfica hasta el fondo utilizado en un ni-
vel o un efecto de explosión. Todo lo que sea un elemento o parte del videojuego es
considerado un GameObject.
No obstante, un GameObject simplemente es un contenedor que no puede funcio-
nar por si solo, sino que se le han de añadir las propiedades pertinentes para crear un
personaje, un sonido, un texto, etc. Dichas propiedades son llamadas componentes
(components en inglés).
Cada GameObject tiene asociado un componente obligatorio llamado Transform
que no se puede eliminar. Este componente determina los valores de posición, rotación
y escala en las coordenadas X,Y,Z del objeto. De esta forma, se puede determinar la
posición, por ejemplo, de un personaje en la parte izquierda de una escena, con un
rotación de 15º y una escala de 1 (que representa el tamaño original con el cual el
gráfico fue importado).
Todos los GameObject de un proyecto de Unity se encuentran situados en las
escenas, las cuales son utilizadas para crear los niveles, el menú principal u otras
pantallas. Dichas escenas contienen los obstáculos, decoraciones, personajes y demás
objetos del videojuego, pero es importante tener en cuenta que para que estos se
visualicen en la pantalla de los dispositivos en los que se utilizará, debe contener un
objeto de tipo cámara.
De la misma forma que desde una televisión solo vemos aquello que es apuntado
por la cámara, en un videojuego creado con Unity solo veremos en modo de ejecución
aquello que se encuentre en el campo de visión de la cámara, tal y como se muestra
en la Fig. 5.1. Cada una de las escenas del juego tendrá como mínimo una cámara
para poder visualizarla, pero es posible tener más de una para crear, por ejemplo, una
partida de dos jugadores y separar la vista. Para este proyecto solo se ha necesitado una
cámara para cada una de las escenas.
5.3 Animaciones
La creación de animaciones en Unity se realiza con el sistema de animación Mecanim,
principalmente utilizada para la animación humanoide retargetint 2 , que tienen capaci-
dad para animar diferentes elementos incluyendo objetos, personajes y propiedades.
Las animaciones se basan en el concepto de clips de animación que contienen las
instrucciones para modificar posiciones, rotaciones, imagen y otras propiedades en un
espacio de tiempo determinado. Cada uno de los clips representa, por ejemplo, uno
de los movimientos de un personaje como respirar, balancearse o saltar. Todos estos
clips se organizan y complementan en una estructura llamada Animator Controller,
una maquina de estados que controla qué clip se debe reproducir en cada momento
según los parámetros y condiciones marcadas por el desarrollador. Dichas condiciones
pueden ir cambiando en tiempo de ejecución del videojuego por medio de los scripts,
creando así los diferentes movimientos que tiene, por ejemplo, un personaje en un
2 Habilidad para aplicar animaciones del modelo de un personaje a otro.
34
5.3. Animaciones
Figura 5.1: Cámara utilizada en Armonisia y GameObjects situados dentro de su campo

de visión.
juego de plataformas al ir corriendo y luego hacer un salto debido a una acción del
usuario.
A continuación se explicarán las diferentes animaciones que se crearon para los
personajes principales, así como sus máquinas de estados.
5.3.1 Personajes principales

Como se ha podido observar en el apartado 3.4.2, los personajes principales fueron
diseñados y creados por partes para así poder realizar la animación desde el editor de
Unity. Al tener dichos fragmentos, la animación de un clip se basaba principalmente
en ir modificando la posición de cada una de estas partes segmentadas en diferentes
instantes de tiempo. De esta forma, el movimiento del personaje era fácilmente editable
y controlable.
En la Fig. 5.2 se puede observar un diagrama con las diferentes partes del sistema
de animación que se conectan para ejecutar y controlar el movimiento del protagonista
en su versión masculina.
Donde las partes numeradas muestran lo siguiente:
1. Animator Controller: La máquina de estado muestra los diferentes clips del

personaje (Respirar, Correr, Hablar, Ser golpeado y Saltar) en forma de nodos
conectados por líneas, las cuales representan los cambios que pueden haber entre
las animaciones. Estos cambios son controlados por parámetros establecidos
como un boolean, un integer, un float o un trigger.
2. Animations Clips: Los diferentes clips que pueden ser importados de un progra-
ma externo o, como en este, creados con la línea de tiempo y la modificación de
tamaño y posición de las diferentes partes del personaje.
3. Componente Animator: Cada vez que se crean animaciones a partir de un obje-

to, se genera automáticamente un componente Animator donde se le asigna el
35
Animator Controller definido anteriormente. En el caso de animación de huma-

noides se debe añadir el personaje adjunto.
Figura 5.2: Partes principales del sistema de animación.
Protagonista
Tanto la versión femenina como la masculina del protagonista del videojuego realizan
las mismas animaciones y, por lo tanto, tienen una máquina de estados idéntica, la cual
se puede observar con más detalle en la Fig. 5.3.
La animación de inicio marcada como ’Stand’, hace referencia al estado de reposo
del personaje, es decir, un movimiento que simula la respiración a base de mover la
parte troncal del cuerpo y los brazos de arriba abajo mientras que las piernas y pies se
mantienen en la misma posición. A partir de este estado, se puede cambiar a cualquiera
de los otros cuatro clips. El marcado como ’Jump’ simula un salto corto y de alegría
del personaje, levantando un brazo hacia arriba y flexionando la pierna derecha. La
animación ’Run’ simula el movimiento de piernas y brazos al correr, pero el personaje
siempre se sitúa en el mismo punto del eje X, ya que la ilusión de que se desplaza por
un escenario se crea con el movimiento del fondo (Parallax). El clip ’Hit’ simula que el
personaje ha recibido un golpe o que está desorientado con un cambio de la expresión
facial y un movimiento de cabeza ligero mientras unas estrellas la rodean. Por último,
la animación ’Talking’ es una versión muy similar a la de ’Stand’, en la que se añade un
suave movimiento de brazos y manos, y el efecto de la boca abriéndose y cerrándose
para que de la sensación de que el personaje está manteniendo una conversación.
Para moverse de un estado a otro, se ha hecho uso de variables booleanas que
controlan el movimiento del personaje y que se van cambiando en el juego a nivel
de código según la parte de la conversación en la que se encuentre o si el jugador ha
acertado o no las notas de los diferentes niveles.
En el caso del personaje de Rytmus, las animaciones creadas fueron muy similares
pero con el factor de que el personaje podía realizar las diferentes acciones en dos
versiones: de pie y en vuelo. Por lo tanto, como se observa en la Fig. 5.4, la máquina de
estados contiene más cantidad de clips.
36
5.3. Animaciones
(a) Máquina de estados de las animaciones del protagonista versión mascu-

lina y femenina.
(b) Captura de las animaciones. De izquierda a derecha:

’Stand’, ’Talking’, ’Run’, ’Jump’ y ’Hit’.
Figura 5.3: Diferentes animaciones del personaje protagonista y su correspondiente

Animator Controller.
37
(a) Máquina de estado de las animaciones de Rytmus.
(b) Captura de las animaciones. De izquierda a derecha:

’Stand’, ’Run’, ’Jump’, ’Hit’, ’Fly’, ’FlyJump’ y ’FlyHit’ .
Figura 5.4: Diferentes animaciones del personaje de Rytmus y su correspondiente

Animator Controller.
5.3.2 Personajes secundarios
En el caso de los personajes secundarios, la creación de la animación fue mucho más

sencilla, ya que al utilizar sprites creados, la transición de un movimiento a otro se
realiza reemplazando una imagen por otra siguiendo una determinada línea de tiempo
para controlar la velocidad del cambio.
5.3.3 Elementos gráficos
Los botones utilizados en las diferentes pantallas de videojuego tienen el efecto de una
leve expansión, de forma que aumenta y disminuye su tamaño de manera constante.
5.4 Canvas
En Unity se pueden crear GameObjects que tengan por defecto un componente Canvas
adjuntado. Dicho objeto Canvas es el área donde deben situarse todos los elementos
User Interface (UI) (botones, texto, imágenes...) como objetos hijos. Todos estos ele-
mentos UI se pintan en el mismo orden que en la jerarquía, es decir, el primer hijo será
el elemento que se pinte primero y así sucesivamente.
38
5.5. Física: Movimiento y gravedad
5.5 Física: Movimiento y gravedad

Para controlar el movimiento de cualquier objeto que se encuentre en una escena, Unity
cuenta con un motor de física que proporciona distintos componentes. De esta forma,
se pueden modificar los diferentes parámetros para simular colisiones o gravedad
entre los objetos. Estos componentes han sido utilizados para la implementación del
pentagrama, concretamente en los círculos de colores y las notas que se mueven hacia
ellos.
5.5.1 RigidBody
El comportamiento físico de cualquier objeto en Unity se realiza adjuntando el compo-
nente RigidBody, el cual le otorga la propiedad de ser afectado por la gravedad. Así pues,
un objeto no se encuentra de forma estática en la escena de juego, sino que, según los
parámetros establecidos, cae a una velocidad u otra.
Debido a que un RigidBody controla el movimiento de un objeto según su gravedad,
no debería cambiarse la posición mediante Transform a un objeto que contiene ambos
componentes. Según el papel que deba jugar dicho objeto en la escena del juego, deberá
tenerse en cuenta cuando utilizar uno u otro.
En el caso de Armonisia, las animaciones de los personajes principales y secun-
darios no cuentan con el componente de RigidBody, ya que no se ven afectados por
ningún tipo de gravedad y no tienen que interactuar con otros objetos sobre la escena
de juego. Este tipo de movimiento se conoce como kinematic o cinemática3 , ya que es
una actividad no física. Por lo tanto, el control del movimiento de estos objetos solo
tienen en cuenta los cambios de parámetros del Transform que se realizan desde el
código de los scripts.
No obstante, no sucede lo mismo con las notas que se mueven sobre el pentagrama
y que deben caer o pasar sobre los círculos de colores. Los diferentes objetos que las
representan contienen un RigidBody con una gravedad establecida a 0 y una veloci-
dad cambiante según el nivel en que se encuentren. Estos valores permiten que las
notas no caigan directamente al iniciar el nivel, sino que se muevan a una velocidad
predeterminada.
5.5.2 Collider
La colisión física entre objetos se controla con el componente Collider. El Collider de
un objeto es invisible y puede, o no, tener la misma forma que el GameObject al que
se le adjunta. Este componente puede ser visualizado en la Fig. 5.5, representado por
un contorno de color verde que rodea a los objetos y que es el encargado de detectar
colisiones con otros colliders de la escena.
Existen diferentes tipos de Collider, entre ellos los llamados primitivos (Box Collider
2D y Circle Colldier 2D) que tienen una forma preestablecida y que a menudo se pueden
aproximar a la forma de un objeto de forma bastante precisa y a la vez mantener una
sobrecarga del procesador baja. No obstante, para objetos con formas más concretas se
3 La cinemática es la rama de la física que describe el movimiento de los objetos sólidos sin considerar
las causas que lo originan (las fuerzas) y se limita, principalmente, al estudio de la trayectoria en función
del tiempo.
39
pueden crear colliders definidos por el desarrollador con la única desventaja de que son
más intensivos para el procesador. Debido a la forma de los objetos de este proyecto
que contienen este componente, se ha optado por utilizar colliders primitivos.
(a) Diferentes representaciones de notas y collider mos-

trado sobre la imagen del ajo.
(b) Diferentes tipos de círculos de colo-

res y collider mostrado sobre el círculo
marrón.
Figura 5.5: Colliders sobre los objetos que conforman el pentagrama de los niveles.
Los colliders pueden ser agregados a objetos sin la necesidad de que haya un
RigidBody. Este es el caso de los círculos de colores ya que no tienen ningún movimiento
pero necesitan saber cuándo ha colisionado otro objeto con ellos. Dicho Collider
es conocido como ’Static Collider’, donde el motor de física asume que el objeto al
que está adjuntado nunca se moverá o cambiará y puede, por lo tanto, hacer uso de
optimizaciones basadas en este conocimiento.
La colisión de dos objetos se activa cuando uno de los colliders hace contacto con el
otro. Hay que tener en cuenta que uno de ellos ha de tener la opción ’Is Trigger’ activada
para poder detectar dicha colisión y poder responder de determinada forma desde el
código de los scripts.
Para detectar que una de las notas ha pasado por uno de los círculos de colores,
estos últimos contienen el trigger activado y hacen uso de la función ’OnTriggerEnter2D’
de su script adjunto para responder a dicho comportamiento. Cuando la colisión está
activa, se comprueba si la nota ha sido pulsada por el usuario y se elimina. En caso
que la nota se pulse cuando la colisión no está activa, el estado será el mismo y no se
destruirá la nota, sino que seguirá su movimiento habitual hasta salir de la escena.
Con el fin de optimizar el juego y evitar que las notas que no sean acertadas sigan
moviéndose fuera de la pantalla del dispositivo del usuario, se ha creado un GameObject
con un componente Collider para destruirlas una vez que interaccionen. Dicho objeto
llamado ’Destroyer’, se ha situado siempre fuera de la cámara de las escenas para que la
eliminación de las notas no sea visible para el jugador. Concretamente, se ha localizado
en forma de rectángulo después de que finalizara el pentagrama de cada nivel, como se
puede observar en el ejemplo del nivel 4 en la Fig. 5.6.
40
5.6. Prefabs
Figura 5.6: GameObject encargado de destruir las notas que no han sido acertadas.
5.6 Prefabs
Cada uno de los GameObjects que se crean en Unity tienen unos componentes y
propiedades determinados. Esto proporciona flexibilidad en cuanto al comportamiento
de los objetos, pero puede suponer trabajo extra si se hace uso de elementos que han
de funcionar de la misma forma y cuando haya un cambio tener que editarlos uno a
uno. Es por esta razón que existe el asset llamado ’Prefab’, el cual permite almacenar un
objeto con sus propiedades y componentes y después utilizarlo como plantilla para
crear nuevas instancias de este mismo objeto. Cualquier cambio que se realice en una
de las instancias puede ser reflejado o no en las otras con un simple botón.
Para este proyecto, la creación de prefabs ha sido esencial ya que tanto los perso-
najes como los elementos que conforman el pentagrama de cada nivel, son utilizados
constantemente en cada una de las escenas de los niveles, animaciones introductorias
y pantallas de puntuaciones al finalizar cada nivel.
En el caso de los círculos de colores, se ha creado un prefab para cada uno de ellos.
Aunque a primera vista parezca que todos son iguales y que simplemente cambian su
color, en realidad existen diferencias importantes que produjeron la necesidad de crear
prefabs independientes. En la Fig. 5.7 se observa los componentes del círculo de color
marrón. Todos los círculos contienen los mismos componentes, pero varían los valores
de sus propiedades. Dichos prefabs mantienen un componente Transform que les da
un tamaño y posición, un componente Sprite Renderer que les proporciona el sprite
de su color correspondiente, el componente Circle Collider explicado anteriormente
para detectar la colisión con las notas y el script ’Activator’ que contiene el código que
controla su comportamiento.
41
Figura 5.7: Componentes adjuntados al prefab del círculo de color marrón.
5.7 Scripts
Los scripts son las instrucciones de código creadas por el desarrollador que se adjuntan
a los GameObject como un component más. Dichos scripts permiten implementar
caracaterísticas propias de cada videojuego y proporcionan la capacidad de activar
o desactivar eventos, modificar propiedades de otros components y responder a las
entradas de información por parte del usuario.
Cada script nuevo que se crea tiene la estructura mostrada en el código 5.1. Como
se puede ver, cada clase que se crea deriva de la clase integrada MonoBehaviour, propia
de Unity. Las funciones más importantes y que vienen por defecto son las siguientes:
1 using UnityEngine ;
2 using System . Collections ;
3
4 public class MainPlayer : MonoBehaviour {
5
6 // Use this for initialization
7 void Start () {
8 }
9
10 // Update is called once per frame
11 void Update () {
12 }
13 }
Código 5.1: Métodos por defecto al crear un script.
42
5.7. Scripts
• Start: Llamada por Unity antes de que comience el ’gameplay’, es decir, antes
de que se llame a la siguiente función ’Update’. En dicha clase se recomienda
realizar las inicializaciones necesarias de los objetos a utilizar.
• Update: Esta función será llamada cada vez que se actualice un frame del Ga-
meObject. Es recomendable utilizarla para crear movimiento, responder a un
evento o a un input del usuario.
Los scripts creados para el desarrollo de Armonisia son los siguientes:
• Activator.cs: Adjuntado a cada uno de los círculos de colores, se encarga de

instanciar o crear las notas para formar el patrón de una de las canciones cuan-
do está en modo crear. Se encarga de marcar mediante una variable booleana
cuando una de las notas pasa sobre el objeto del círculo y de cambiar de color y
reproducir la música cuando se pulsa sobre ellos en el momento correcto.
• AspectUtily.cs: Adjuntado a la cámara de cada una de las escenas, se encarga de

ajustar su enfoque al tamaño de la escena en la que se encuentra.
• BackgroundScroll.cs: Adjuntado a cada uno de los fondos en movimiento. Se

encarga de crear el efecto Parallax que realizan los fondo a una velocidad especí-
fica.
• CharacterSelection.cs: Adjuntado a un objeto invisible en la escena que contie-

ne las versiones femenina y masculina del protagonista. Se encarga de controlar
los botones de derecha e izquierda y hacer visibles los objetos de los personajes.
Como se puede ver en el código 5.2, la función ’Start’ crea una lista de GameOb-
jects a partir del componente Transform del objeto que tiene como hijos los
personajes. De esta manera, al selector de protagonista se podrían añadir per-
sonajes nuevos sin la necesidad de modificar el código. El control de las flechas
derecha e izquierda se realiza con las funciones ’ToggleRight’ y ’ToggleLeft’, las
cuales modifican el índice utilizado para marcar el personaje seleccionado de la
lista.
1 void Start () {
2 index = PlayerPrefs . GetInt
( " MainCharacterSelected " ) ;
3
4 // List with all the possible main characters
5 characterList = new
GameObject [ transform . childCount ];
6
7 for ( int i = 0; i < transform . childCount ; i ++) {
8 characterList [ i ] =
transform . GetChild ( i ) . gameObject ;
9 }
10
11 // All characters hidden
43
12 foreach ( GameObject go in characterList ) {

13 go . SetActive ( false ) ;
14 }
15
16 // We toggle on the selected character
17 if ( characterList [ index ]) {
18 characterList [ index ]. SetActive ( true ) ;
19 }
20 }
Código 5.2: Método de iniciliazación Start del script CharacterSelection.cs
• Countdown.cs: Se encarga de controlar la animación de la cuenta atrás cada vez

que se inicia uno de los niveles.
• FinishedLevel.cs: Adjuntado a un objeto transparente, se encarga de gestionar

la pantalla de puntuación que se visualiza cada vez que se acaba uno de los
niveles del videojuego. Tanto si el nivel ha sido superado como si no, se activa
una ventana que muestra las puntuaciones obtenidas y los botones de continua-
ción según el caso. El método ’Start’ que se observa en el código 5.3 muestra
la comprobación inicial de si el último nivel jugado ha sido completado o no,
para mostrar así el menú de enhorabuena o el menú para repetir el nivel. En el
primer caso se comprobará según la puntuación obtenida cuántas estrellas se
consiguen y se utilizan las notificaciones para llamar al método que guarda todas
las puntuaciones en el fichero ’data.dat’.
1 void Start () {
2 // If the level is completed
3 if ( gameManager . lastLevelPlayed . IsCompleted ) {
4 finishMenu . SetActive ( true ) ;
5 CheckStars () ; // Checks how many stars for
this level
6 // Save Data in data file
7 NotificationCenter . DefaultCenter
() . PostNotification ( this , " SaveData " ) ;
8 } else {
9 finishMenuLost . SetActive ( true ) ;
10 }
11 // Score and points are showed if the level is
completed or not
12 CheckScoreAndNotes () ;
13 // A character is showed . If the level is passed ,
the animation will be ’ Jump ’ , otherwise it
will be ’Hit ’
14 ActiveCharacter () ;
15 }
Código 5.3: Método de inicialización Start del script FinishedLevel.cs
44
5.7. Scripts
• GameManager.cs: Se encarga de gestionar los métodos para leer y guardar los da-
tos del videojuego. Dicho script se encuentra adjuntado a un objeto transparente
que se encuentra en todas las escenas del proyecto. Su método ’Start’ utiliza la
función ’DontDestroyOnLoad’ propia de Unity que evita que el objeto se destruya
al cambiar de escena. Contiene los métodos para cargar y guardar los datos del
fichero ’data.dat’, visibles en los códigos 5.4 y 5.5 respectivamente.
1 void LoadData () {
2 // If the file exists , we read the information
3 if ( File . Exists ( filePath ) ) {
4 BinaryFormatter bf = new
BinaryFormatter () ;
5 FileStream file = File . Open
( filePath , FileMode . Open ) ;
6 DataBase data =
( DataBase ) bf . Deserialize ( file ) ;
7
8 playerName = data . PlayerName ;
9 isAGirl = data . IsAGirl ;
10 levels = data . Levels ;
11 musicOn = data . MusicOn ;
12 effectsOn = data . EffectsOn ;
13 file . Close () ;
14 } else { // If not , we use the default
configuration
15 playerName = " Andy " ;
16 List < LevelData > levels = new
List < LevelData >() ;
17 isAGirl = true ;
18 }
19 }
Código 5.4: Método LoadData del script GameManager.cs
1 void SaveData ( Notification notification ) {

2 // Every time a Level is played , the data
file is overwritten
3 BinaryFormatter bf = new BinaryFormatter () ;
4 FileStream file = File . Create ( filePath ) ;
5 // The data base object is created
6 DataBase data = new DataBase ( isAGirl ,
playerName , levels , musicOn , effectsOn ) ;
7
8 bf . Serialize ( file , data ) ;
9 file . Close () ;
10 }
Código 5.5: Método SaveData del script GameManager.cs
45
• LevelMapManager.cs: Adjuntado a un objeto transparente, este script se encarga

de controlar la pantalla de acceso a los diferentes niveles del videojuego. Su fun-
ción principal es desbloquear aquellos niveles que ya se han superado mediante
los datos obtenidos del fichero ’data.dat’. Además, pinta las estrellas correspon-
dientes de cada uno de los niveles completados. El desbloqueo de un nuevo
nivel se basa en una simple desactivación del GameObject que tapa el botón para
acceder a dicho nivel.
• MainSettings.cs: Adjuntado al Canvas de la pantalla inicial, se encarga de mostrar

el menú de configuración principal y de llevar a cabo las finalidades de apagar y
encender la música y sonidos.
• NameSelector.cs: Adjuntado a un objeto transparente, este script se encarga de

obtener el texto introducido por el usuario en el input del nombre del personaje
y activar el botón de continuar cuando se haya finalizado dicha tarea.
• Note.cs: Adjuntado a cada una de los objetos que actúan como notas en el pen-
tagrama musical (gotas, ajos, diamantes y regalos), se encarga de indicar la di-
rección del movimiento que deben seguir y de detectar la pulsación sobre ellas
cuando el usuario utiliza la pantalla para jugar. Para ello, en la función ’Update’
( 5.6) se controla por cada frame la dirección hacia donde se ha de mover y si el
usuario ha pulsado sobre la pantalla (o ha hecho clic con el ratón en la versión de
desarrollo) para llamar a la función ’checkTouch’ ( 5.7). Dicho método controla si
se ha tocado la nota cuando pasaba por encima de uno de los círculos de colores,
si es así se destruirá y se añadirán los puntos correspondientes.
1 void Update () {
2 // Note movement and speed
3 if ( RightToLeft ) {
4 transform . Translate ( - speed * Time . deltaTime ,
0 , 0) ;
5 } else if ( LeftToRight ) {
6 transform . Translate ( speed * Time . deltaTime ,
0 , 0) ;
7 } else if ( UpToDown ) {
8 transform . Translate (0 , - speed *
Time . deltaTime , 0) ;
9 } else if ( DownToUp ) {
10 transform . Translate (0 , - speed *
Time . deltaTime , 0) ;
11 }
12 // The touch is with a mobile device , we use the
touch position
13 if ( platform == RuntimePlatform . Android ||
platform == RuntimePlatform . IPhonePlayer ) {
14 if ( Input . touchCount > 0) {
15 if ( Input . GetTouch (0) . phase ==
TouchPhase . Began ) {
46
5.7. Scripts
16 checkTouch ( Input . GetTouch

(0) . position ) ;
17 }
18 }
19 // The touch is with Unity Editor , we use the
mouse position
20 } else if ( platform ==
RuntimePlatform . WindowsEditor ) {
21 if ( Input . GetMouseButtonDown (0) ) {
22 checkTouch ( Input . mousePosition ) ;
23 }
24 }
25 }
Código 5.6: Método Update del script Note.cs
1 // Checks where the user has touched ( tactile in

mobile devices and click in computers )
2 void checkTouch ( Vector3 pos ) {
3 Vector3 wp = Camera . main . ScreenToWorldPoint ( pos ) ;
4 Vector2 touchPos = new Vector2 ( wp .x , wp . y ) ;
5 Collider2D hit = Physics2D . OverlapPoint ( touchPos ) ;
6 // If the collider detects the touch in a
position where the object is tagged like a
note ...
7 if ( hit && hit . transform . gameObject . tag == " Note " ) {
8 note = hit . transform . gameObject ;
9 if ( inside == true && gameObject . name ==
note . name ) { // If the touched note is itself
10 // The note has been touched when passes
through the activator ( color circle )
11 NotificationCenter . DefaultCenter
() . PostNotification ( this ,
" NotePressedCorrectly " ) ;
12 activator . GetComponent < Activator >
() . playNoteSound () ;
13 activator . GetComponent
< Activator >() . SetColorChange () ;
14 Destroy ( note ) ;
15 pointsManager . GetComponent < PointsManager >
() . AddScore () ;
16 }
17 }
18 }
Código 5.7: Método checkTouch del script Note.cs
47
• NoteDestroyer.cs: Adjuntado al objeto transparente de cada nivel que se presen-

tó como ejemplo en la Fig. 5.6, se encarga mediante el método ’OnTriggerEnter2D’
de destruir las notas que no han sido acertadas por el usuario y que han seguido
su movimiento hasta salir de la pantalla.
• PauseMenu.cs: Adjuntado al Canvas de cada uno de los niveles del juego, se

encarga de realizar las funciones del menú de configuración además de pausar el
tiempo del juego para detenerlo momentáneamente y poder reanudar la partida
en el mismo instante antes de la pausa. Las configuraciones posibles son las de
modificar el volumen de la base musical y del sonido de las notas.
• PointsBar.cs y PointsManager.cs: Se encargan de controlar las puntuaciones

que se obtienen en cada nivel. El primer script se adjunta a la barra de progreso y
modifica su valor a medida que se van sumando puntos. El script ’PointsMana-
ger.cs’ controla los bonus de puntos y se encarga de guardar dichos datos en el
objeto de cada uno de los niveles.
• ReportManager.cs: Adjuntado a un objeto transparente, se encarga de mostrar

los datos pertenecientes a cada uno de los niveles, así como de controlar cuáles
están completos y cuáles no para poder pintar la información.
• SceneController.cs: Adjuntado a un objeto transparente, se encarga de realizar

los cambios entre escenas. De la misma forma que el ’GameManager.cs’, el objeto
que la contiene se encuentra en todas las escenas.
• dialogLEVELNAME.cs: Existe un script de este tipo para cada uno de los niveles
del juego. Es el encargado de visualizar los textos de los diálogos que aparecen en
las animaciones previas a cada uno de los niveles. Además, controla la animación
de los personajes cada vez que el usuario da paso a la siguiente oración con
el botón habilitado. En el caso de que en la escena deba aparecer el personaje
protagonista, el script se encarga de comprobar cuál ha sido la elección del
usuario.
• LEVELNAMELevel.cs: Se dispone de un script de este tipo para cada uno de los

niveles del juego. Es el encargado de indicar cuántas notas hay en total en el pen-
tagrama del nivel y cuál es la puntuación máxima posible que se puede conseguir.
En este script se crea el objeto ’Level’ inicial y se controlan las animaciones del
personaje según si el usuario acierta o no las notas sobre los círculos de colores.
5.8 Flujo del videojuego

A continuación, se puede observar en la Fig. 5.8 el flujo entre las diferentes pantallas de
Armonisia. Las flechas indican la movilidad que existe desde una pantalla a otra. Las
fechas en ambos sentidos indica que se puede volver a la pantalla de la que ha venido.
El punto verde indica la pantalla principal del videojuego, desde donde se inicia
el flujo que puede seguir el usuario con la aplicación. El cuadro Diálogos y el cuadro
Niveles representan a todas las escenas del mismo tipo.
48
5.8. Flujo del videojuego
Figura 5.8: Diagrama de flujo del usuario al utilizar Armonisia.
49
CAPÍTULO
6
C ONFIGURACIÓN DE NUEVOS NIVELES
En este capítulo se explicarán los pasos a seguir para la creación de un nuevo nivel de
Armonisia.
6.1 Pantalla de nivel

Todos los niveles de Armonisia cuentan con la misma estructura de GameObjects en
su escena, por lo que solo se debe modificar el valor de los parámetros de los scripts
adjuntados y los sprites de los personajes y notas. Los pasos a seguir para la creación
del nivel se definen a continuación:
1. Realizar una copia de la Scene llamada ’TemplateLevel’, creada especialmente

para general niveles de forma flexible. Como se observa en la Fig. 6.1, el nivel
cuenta con los GameObjects pero sin ninguna configuración o sprites añadidos.
Figura 6.1: Vista de Unity al modificar la plantilla de nivel.
51
6. C ONFIGURACIÓN DE NUEVOS NIVELES
2. Añadir un personaje a la escena utilizando los prefabs de personajes que se

encuentran en la carpeta ’Prefabs’. Una vez se haya arrastrado el personaje a la
escena, se verá inmediatamente su GameObject en la pantalla de la jerarquía de
la derecha.
3. Añadir un fondo. Para ello, se arrastra una de las imágenes de la carpeta ’Back-
grounds’ a la ventana del inspector del GameObject ’BG’. Dicho objeto es hijo de
’Main Camera’.
4. Modificar posiciones y pentagrama. La plantilla de nivel viene con una posición

y número de círculos determinado, pero son fácilmente editables seleccionando
los objetos en el modo editor. Para añadir nuevos círculos, se pueden obtener
dentro de la carpeta ’Prebafs’ y la subcarpeta ’Activators’.
5. Añadir música. Para ello, se ha de utilizar el GameObject ’Music’, el cual contiene

otros objetos hijos que representan cada uno de los sonidos o canciones del
nivel. ’LevelBase’ y ’LevelHit’ hacen referencia a la música ambiente y al clip de
audio que contiene todas las notas sonando con el patrón correcto. ’MenuMusic’
y ’MenuMusicB’ son audios idénticos a los anteriores con la diferencia de que
estos serán utilizados para reproducir en el momento en que se active el menú de
pausa. ’NoteSounds’ contiene los objetos de cada una de las notas de cada círculo
de color, cuyos audios han de ser el sonido único de la nota que les corresponde.
Todos los sonidos creados hasta el momento se han guardado en la carpeta
’Music’.
6. Configurar el script del nivel. El GameObject ’LevelManager’ tiene adjuntado

el script ’TemplateLevel’, del cual se debe crear una copia para el nuevo nivel y
adjuntar de la misma manera que la plantilla. Como se observa en la Fig. 6.2, se
han de rellenar los parámetros del nivel, donde ’Character Name’ hace referencia
al nombre del objeto del personaje añadido, ’Total Score’ es la cantidad máxima
de puntos que se puede conseguir, ’Total Notes’ el número total de notas que
contiene el nivel y ’Level Num’ el número de nivel que es. Dentro del script, se
definen las animaciones del personaje en los casos en que el jugador acierte
las notas, las falle o se consiga un bonus. Para modificarlo, se han de usar las
variables booleanas definidas en la animación del personaje y controlar si son
falsas o verdaderas.
7. Puntuación. El GameObject ’TotalNotesText’ contiene el componente de texto

para mostrar el número total de notas, el cual se ha de modificar por el valor
correspondiente. De la misma manera, el objeto ’LevelManager’ contiene el script
’Points Manager’, donde se ha de volver a especificar la puntuación máxima
posible del nivel para que la barra de puntos se mueva acorde a dicha cantidad.
8. Crear las notas. Se debe crear un objeto nuevo que represente las notas del nivel,
para ello se utilizará un sprite nuevo al que se le adjuntará los componentes
siguientes: Circle Collider 2D, Rigidbody2D y el script ’Note’. En este último se
ha de indicar el valor de su parámetro ’Speed’ el cual representa la velocidad de
movimiento y se ha de marcar la dirección que se desea que siga (De izquierda a
52
6.1. Pantalla de nivel
Figura 6.2: Vista de los componentes del GameObject ’LevelManager’.
derecha, de derecha a izquierda, de arriba a abajo, de abajo a arriba). Se ha de

guardar dicho objeto como un nuevo prefab.
9. Patrón musical. El último paso será crear el patrón musical del juego, por lo que
a cada uno de los círculos de colores se les debe adjuntar en su script ’Activator’ y
en el parámetro ’N’, uno de los prefabs de notas creados anteriormente. Se ha de
marcar la opción de ’Create Mode’ y se ha de especificar una tecla en el parámetro
’key’. De esta forma, en el modo de juego, cada vez que el usuario pulse sobre la
tecla especificada, una de las notas se creara desde la posición del círculo y se
podrá generar un patrón rítmico. Cuando se haya finalizado, se debe pausar el
modo de juego y copiar el conjunto de notas creadas para después copiarlas en
el GameObject ’Notes’. A partir de este paso, solo quedará mover el conjunto de
notas para coordinar su posición y que se muevan en dirección a los círculos de
colores y no al contrario.
53
CAPÍTULO
7
E VALUACIÓN
En este capítulo se describe la primera evaluación realizada con la versión base de Ar-
monisia. Se definen los participantes, las pruebas, el material utilizado, el procedimien-
to seguido y, por último, los resultados obtenidos tanto con un enfoque cuantitativo
como uno cualitativo. Con el primero se obtienen estadísticas y resultados numéricos,
mientras que con el segundo se atiende a cualidades observables y más subjetivas.
7.1 Participantes
La evaluación de la aplicación se ha realizado con un grupo de usuarios conformado
por 6 niños y 3 niñas de ASPAS. Como se ha comentado en capítulos anteriores, los
niños de dicha asociación ya habían utilizado diferentes dispositivos electrónicos como
tablets, teléfonos móviles, consolas u ordenador, por lo que la tablet empleada para
las pruebas no ha sido un inconveniente para ellos. Los niños participantes utilizaban
como ayuda auditiva implantes cocleares o audífonos, tanto en un oído como en ambos.
En la tabla 7.1, se puede observar con detalle la información de cada uno de los niños
que han probado Armonisia.
7.2 Material
El material utilizado para la evaluación ha sido una tablet Samsung Galaxy Tab 3 GT-
P5210 de 10.1"de 16GB. El dispositivo contaba con el sistema operativo Android™ Jelly
Bean y la aplicación de Armonisia instalada. También se hizo uso de unos altavoces
externos que se conectaron a la tablet con el objetivo de aumentar el volumen.
7.3 Procedimiento
La evaluación de la aplicación base con el grupo de usuarios duró un total de tres días,
en los cuales los evaluadores se dirigieron hasta el centro de ASPAS para poder realizar
55
7. E VALUACIÓN
ID Sexo Edad Ayuda en oído derecho Ayuda en oído izquierdo

1 Masculino 6 - Audífono
2 Femenino 7 Audífono Audífono
3 Masculino 6 Audífono Audífono
5 Femenino 8 - Implante coclear
6 Femenino 8 Implante coclear Implante coclear
7 Masculino 12 Audífono -
8 Masculino 12 Implante coclear Implante coclear
Cuadro 7.1: Perfiles de cada uno de los participantes de la evaluación.
la prueba con niños de diferentes edades.

El espacio utilizado para realizar la evaluación es importante para que los usuarios
se sientan cómodos y se desenvuelvan con naturalidad. En este caso, las pruebas se
llevaron a cabo en un despacho del centro. En el caso de los niños más pequeños,
además del evaluador, se encontraba presente uno de los terapeutas, mientras que en
el caso de los más mayores, los evaluadores iban a buscarlos a las salas donde realizan
talleres y el monitor hacía las presentaciones con los niños. Durante el camino de las
salas hasta el despacho donde se realizaba la evaluación, se creaba un ambiente de
confianza entre ellos y los evaluadores mediante conversaciones informales y preguntas
del estilo ¿Qué estabais haciendo en este taller?, ¿Cómo ha ido el colegio?, ¿Qué harás este
verano?, etc. De esta manera, los niños se relajaban y se les podía ir explicando durante
el camino quiénes éramos y el motivo de la visita: Mostrarles un videojuego que se
estaba desarrollando y que necesitábamos de su ayuda para saber tanto lo bueno como
lo malo y así poder mejorarlo.
Cada sesión era individual y el niño se sentaba en una silla del despacho delante de
la tablet que contenía el juego. Antes de comenzar a utilizar la aplicación se rellenaba
un cuestionario con información demográfica: Nombre, fecha de nacimiento, curso
escolar cursado este año, tecnología utilizada en casa de forma frecuente y el tipo de
ayudas auditivas que se utilizaba en cada uno de los oídos.
Después de guardar toda la información indicada, se procedía a realizar una in-
troducción del juego y de su historia. En algunos casos se leyó la historia completa y
en otros se hizo un resumen para situar al niño y poder mostrarle los personajes de
Armonisia. Para que la explicación fuese más clara se mostraba, utilizando la tablet, el
nivel más fácil del juego y se explicaba qué se debía hacer para superar el nivel. Una
vez que el niño entendía la dinámica del juego, se reiniciaba el mismo nivel enseñado
para que fuese él o ella quien jugara. Todos los participantes jugaron a un total de 3
niveles, mientras que algunos hicieron alguna repetición ya que querían mejorar su
resultado (Fig. 7.1).
El siguiente paso después de que el niño probara el juego, fue realizarles un conjunto
de preguntas basadas en las siguientes herramientas:
• Intrinsic Motivation Inventory (IMI) [21]: Herramienta de medida utilizada para

recoger experiencias subjetivas de los participantes de una evaluación en una
56
7.4. Resultados
actividad realizada en entornos controlados. Esta herramienta busca valorar

aspectos como el interés/divertimento, el esfuerzo o la concentración.
• Smileyometer [22]: Herramienta basada en la escala de Likert 1 de 5 puntos, re-

presentados por 5 smileys, fue diseñada para recoger la opinión de los niños
realizando una actividad o juego.
Figura 7.1: Niños jugando con Armonisia durante la evaluación.
El IMI se responde con una escala de Likert de 7 puntos (desde ’No del todo cierto’
hasta ’Muy cierto’), mientras que el Smileyometer tiene cinco respuestas, las cuales se
pueden observar en la Fig. 7.2.
Figura 7.2: Escala visual del Smileyometer.
A los niños participantes se les presentó el cuestionario formado por cinco pregun-
tas (Tabla 7.2) y la escala de respuestas simplificada. Además, se formuló una pregunta
sobre la emoción con la que asociaban el juego y que debían contestar con uno de las
tres siguientes smileys: Contento, neutro o descontento.
Por último, se animó a todos los niños a dar su opinión y a hacer comentarios sobre
aspectos tanto positivos o negativos sobre su experiencia con Armonisia y posibles
mejoras a realizar.
7.4 Resultados
A continuación se explican y comentan los resultados obtenidos en diferentes aspectos
del juego: Historia, diseño gráfico, cuestionarios y otros comentarios.
1 Es la escala de uso más amplio en encuestas para la investigación, principalmente en ciencias
sociales. Al responder a una pregunta de un cuestionario con esta técnica, se especifica el nivel de acuerdo
o desacuerdo con una declaración (elemento, afirmación, pregunta).
57
7. E VALUACIÓN
¿Has comprendido la actividad a realizar? Sí No Poco

¿Fue claro para ti realizar la actividad? Sí No
¿Has tenido que realizar mucho esfuerzo? Sí No Poco
¿Disfrutaste la experiencia? ¿Te has divertido? Sí (poco, mucho) No
¿Has tenido que concentrarte mucho? Sí (poco, mucho) No
Cuadro 7.2: Preguntas del cuestionario presentado a los participantes.
Historia
Aunque la historia del videojuego se contó de manera resumida a los usuarios, una de
las niñas participantes de 8 años leyó por si misma los diálogos que se presentan antes
de cada nivel para posteriormente dar su opinión y saber si dichas animaciones son
útiles o adecuadas para los usuarios a los que va destinado el juego. Antes de comenzar
se animó a la niña a preguntar cualquier palabra que no entendiera o le supusiese una
dificultad. El texto de los diálogos se leyó sin ningún problema, destacando solo que
las palabras que más complejas le parecían eran aquellas que se referían a los nombres
propios de los personajes o del reino (Armonisia, Rytmus, Pumpkin).
Durante esta lectura se observó que la niña parecía disfrutar y reírse cuando en cier-
tas partes de la historia el personaje de Rytmus rugía (representado por un ’Grrrr, grrr’
en los textos). La niña opinó que había demasiado texto pero le gustó especialmente
las partes en que se hacía referencia a su nombre en los diálogos (recordemos que el
nombre del personaje principal es configurable por parte del jugador al principio del
juego).
Diseño gráfico
Todos los participantes de la evaluación coincidieron en que les gustó la estética que
presenta el juego y comentaron, sobre todo, nuevas temáticas para posibles nuevos
niveles del juego como el fútbol, la selva, etc.
Cuestionarios
Gracias a las respuestas obtenidas con los cuestionarios, se han podido analizar datos
cuantitativos que ayudan a analizar y entender los resultados obtenidos en la evalua-
ción. Como se puede observar en el gráfico de barras de la Fig. 7.3, se representan las
respuestas obtenidas en forma porcentual por cada una de las preguntas del cuestiona-
rio.
La respuesta más clara y en la que han coincidido el 100 % de los participantes ha
sido la claridad a la hora de realizar la actividad que se proponía, por lo que se puede
deducir que la técnica del videojuego es fácil de comprender. Este dato es importante ya
que uno de los requisitos de la aplicación era que fuese intuitiva y fácil de utilizar para
el grupo de usuarios objetivo. No obstante, la pregunta ¿Has tenido que realizar mucho
esfuerzo? muestra diversidad de opiniones, ya que a partes iguales han contestado Sí,
No y Un poco. Estudiando detalladamente estas contestaciones según las edades de los
niños, no se ve relación alguna con dicho factor, ya que cada tipo de respuesta ha sido
dado por niños de 6 hasta 13 años.
58
7.4. Resultados
Cabe destacar también los datos obtenidos a la pregunta ¿Has tenido que concen-
trarte mucho?, ya que casi un 80 % de los niños evaluados ha respondido que sí. Esto es
un aspecto positivo, ya que la concentración es imprescindible para el aprendizaje y el
objetivo de este videojuego es que los usuarios entrenen una capacidad.
Figura 7.3: Gráfico de barras representando las respuestas del cuestionario.
A nivel general, en la Fig. 7.4 se puede observar un gráfico circular que representa
las emociones con las cuales los niños asociaban el juego. Las posibles opciones eran:
contento, neutro y descontento. El resultado ha sido positivo, ya que 8 de los 9 niños han
respondido con el estado de contento, mientras que el restante ha indicado neutralidad
y ninguno de ellos ha sentido descontento.
Comentarios y observaciones
La sensación general es que la aplicación gustó a todos los niños y niñas que partici-
paron en la evaluación. En el momento de hacer el intercambio entre la sala común
donde se encontraban los niños y el despacho donde realizaban la prueba, se podían
escuchar comentarios que se hacían entre ellos como: ’Ve, te va a gustar’, ’Es chulo, ya
verás’. También señalaban a sus compañeros para indicar a los evaluadores a quien
deberían llevar para la siguiente prueba.
En cuanto a la música, muchos de los niños comentaron que les gustaba e incluso
algunos movían la cabeza mientras jugaban para seguir el ritmo de la canción. Otra
de las observaciones que se hizo mientras los niños jugaban, era que los más mayores
apretaban de forma continuada los botones circulares de colores sobre los cuales iban
a pasar las notas antes de que estas llegaran, esperando así interceptar el objetivo más
fácilmente.
59
7. E VALUACIÓN
Figura 7.4: Gráfico circular representando la emoción de los participantes respecto al

videojuego.
La mayoría de los niños empezaban utilizando solo de una las manos, pero después,
ya sea por iniciativa propia o por comentarios realizado por los evaluadores, utilizaban
ambas manos. Esta técnica se puso apreciar, sobre todo, en los niveles más difíciles.
En relación a la forma de puntuar los niveles, los niños prestaron especial interés
en las estrellas que representaban de forma gráfica los puntos obtenidos. Algunos de
ellos, cuando se daban cuenta que habían conseguido una puntuación alta pero que no
habían logrado obtener las tres estrellas querían repetir el nivel cuando los evaluadores
les preguntaban si querían volver a intentarlo. Aquellos que repetían y conseguían
más estrellas que la primera vez se mostraban realmente contentos mediante gestos y
comentarios.
60
CAPÍTULO
8
P UBLICACIONES Y PARTICIPACIONES EN
EVENTOS CIENTÍFICOS O DIVULGATIVOS
8.1 Women Techmakers Menorca 2017

El 10 de marzo de 2017 se celebró en Menorca el evento Women Techmakers1 , una
iniciativa liderada por Google que promueve dar a las mujeres que se dedican al sector
tecnológico protagonismo y visibilidad. Mediante diversos eventos como exposiciones,
mesas redondas o talleres prácticos se pretende conseguir que en un futuro no siga
siendo extraño que una mujer se dedique al mundo de las tecnologías.
El evento en Menorca fue organizado por GDG Menorca y fue la primera edición
que se celebraba en la isla. Constó de un total de ocho ponencias todas ellas dadas por
mujeres relacionadas con el ámbito tecnológico. Así pues, la charla impartida por mí,
titulada La informática también habla de personas, trató de las experiencias de una
estudiante en la carrera de Ingeniería Informática, los proyectos realizados por el grupo
de Unidad de Gráficos y Visión por Ordenador e IA de la UIB y el trabajo realizado con
Armonisia.
8.2 Informática para tod@s (IPT2017)

El 5 de mayo de 2017 se celebró en la UIB la segunda edición de ACM Celebrations:
Informática para tod@s2 , un evento que pretende facilitar el encuentro e intercambio
de ideas entre personas de habla castellana. El evento realizado contaba con ponencias,
una mesa de discusión y una sesión de pósteres. Mi participación con el proyecto
Armonisia se incluyó en esta última actividad, en la cual se proponía compartir ideas
o trabajos, tanto en progreso como finalizados, que pudieran ser diseños, técnicas,
sistemas, herramientas, etc.
1 http://wtm.gdgmenorca.com/
2 http://ipt2017.uib.es/
61
8. P UBLICACIONES Y PARTICIPACIONES EN EVENTOS CIENTÍFICOS O DIVULGATIVOS
En el anexo A.3 se puede visualizar el póster enviado que pasó un proceso de

revisión por parte del comité de programa y fue expuesto en el evento. Se presentó
la idea de la aplicación haciendo hincapié en la motivación y el objetivo a conseguir.
Aunque el proyecto no estuviese finalizado, se pudo explicar cuál es la técnica de juego
y mostrar con las imágenes una parte de la versión base que se estaba desarrollando.
8.3 Interacción 2017

Del 25 al 27 de septiembre de 2017 se celebrará en México la décimo octava edición de
la conferencia internacional promovida por la Asociación para la Interacción Persona-
Ordenador (AIPO)3 , cuyo objetivo principal es promover los avances en el marco de
la interacción Persona - Ordenador. Entre los temas que se tratarán se encuentran la
accesibiblidad, multimedia, usabilidad, experiencia de usuario, realidad aumentada,
etc.
Entre las diferentes actividades del evento, como las ponencias y talleres, se expon-
drán diferentes trabajos y proyectos de diferentes categorías: Full papers, Short Papers,
Doctoral Colloquium y Experiences and case studies. En nuestro caso, presentamos un
Short Paper, ya que se buscaban trabajos que describieran un proyecto innovador en
proceso de realización y sin resultados significativos hasta el momento.
El Short Paper se ha titulado Game to Develop Rhythm and Coordination in Children
with Hearing Impairments, y sus autores son: Camila Pérez Arévalo, Cristina Manresa
Yee y Victor M.Peñeñory Beltrán. En él se hace una introducción de las discapacidades
auditivas y sus consecuencias, se muestran trabajos relacionados y se explica la idea
base del videojuego y los requisitos a cumplir.
El Short Paper ha pasado por un proceso de revisión y ha sido aceptado por el
comité de programa para su publicación y explicación en el congreso y será presentado
por Victor M. Peñeñory el próximo septiembre. Se puede encontrar el documento en el
anexo A.7 [23].
3 http://webmilab.com/interaccion2017/
62
CAPÍTULO
9
C ONCLUSIONES
En este capítulo se realiza un resumen de los objetivos principales del desarrollo del
proyecto y de las conclusiones obtenidas. Además, se especifica el trabajo futuro que se
espera realizar con Armonisia.
9.1 Conclusión
"Mi trabajo es un juego, un juego muy serio." - Maurits Cornelis Escher, artista.
En este TFG se ha presentado el proceso de diseño y desarrollo de la aplicación

Armonisia para dispositivos móviles con sistema operativo Android. Dicha aplicación
se trata de un videojuego serio en 2D que genera patrones rítmicos visuales y auditivos,
cuyo objetivo es entrenar la percepción del ritmo y la coordinación visual motora de
niños con discapacidades auditivas. El proceso para diseñar este sistema interactivo ha
incluido entrevistas con profesionales y terapeutas, investigación y análisis de otros
proyectos similares o con el mismo objetivo y la evaluación del prototipo realizado con
los terapeutas y niños de ASPAS.
Gracias a la evaluación del prototipo realizada con niños, se han podido extraer
algunos datos concluyentes sobre el futuro trabajo y uso de Armonisia. Se ha consegui-
do crear una base de juego que sea, en general, agradable y divertida para los usuarios
y que, al mismo tiempo, suponga una actividad en la que entrenen la percepción del
ritmo de forma concentrada.
En cuanto a la dificultad de los niveles, se observó que los niños encontraban más
fácil el segundo nivel que el primero, por lo que se deduce que la principal dificultad a
la hora de crear un nivel es el factor de la velocidad a la que se mueven las notas por
delante de la cantidad de estas o el tamaño de los botones circulares.
Al realizar la evaluación en un centro de Mallorca, se ha podido comparar las
dificultades que presentan los niños con discapacidades auditivas nacidos en España en
relación a los nacidos en Colombia. Las diferencias marcan una realidad distinta entre
ambos países, pues los niños nacidos en Colombia presentan problemas psicomotores
63
9. C ONCLUSIONES
más notables como pueda ser el equilibrio. Esta distinción se basa principalmente en
la detección temprana y la utilización de ayudas auditivas desde muy jóvenes, lo que
presenta una gran ventaja frente a países donde los niños, por razones económicas o
sociales, no disponen de estos apoyos.
9.2 Futuro trabajo

El trabajo futuro con este videojuego incluye la implementación de nuevas funcio-
nalidades como la posibilidad de cambiar el idioma de la aplicación, la generación
de reportes más completos para los terapeutas y, por supuesto, la adición de nuevos
niveles que prosigan con la historia creada y completen el juego. Además, se realizarán
nuevas evaluaciones sobre las mejoras que se realicen para seguir con la filosofía del
DCU.
Otro aspecto a mejorar es la posibilidad de hacer más configurable el juego, dando
la opción de escoger entre varios personajes con distintos peinados, colores de piel y,
sobre todo, con otros dispositivos de ayuda auditiva como los audífonos.
Una vez se llegue a una versión más completa en cuanto a las funcionalidades
comentadas y con un mínimo considerable de niveles, se pretende subir la aplicación a
la plataforma de distribución digital Google Play Store.
9.3 Opinión personal

La realización de este proyecto me ha permitido conocer en profundidad la filosofía
del DCU y, la que considero, su ventaja principal: evaluación constante y desarrollo
a partir del feedback obtenido. Creo que la parte más interesante ha sido poder ver
la forma de interactuar con la aplicación que tienen los usuarios reales a los que va
destinada y conocer así las funcionalidades que pueden llegar a ser útiles para ellos.
Me parece importante, sobre todo, porque el grupo de usuarios al que está destinado
era totalmente desconocido para mí.
El aspecto de diseño e implementación de la aplicación también ha supuesto
un reto, ya que es el primer videojuego que he desarrollado. He podido conocer en
pequeñas porciones diferentes aspectos de este mundo, tanto de la parte creativa
(creación de la historia, diseño de los personajes, etc.) como de la parte tecnológica
(motor de física, animaciones gráficas, etc.).
Gracias al proyecto Armonisia y al proyecto Diseño de experiencias interactivas
dirigidas al bienestar de personas con necesidades especiales he podido conocer una
gran cantidad de formas de ayudar a personas con discapacidades mediante el uso
de sistemas interactivos. Me ha sorprendido mucho las carencias que puede tener
una persona con discapacidad auditiva y las ingeniosas ideas tecnológicas con las que
se les puede ayudar. No obstante, esto no habría sido posible sin la comunicación
entre todas las partes implicadas, por lo que el mayor aprendizaje que me llevo es que
los informáticos han de trabajar con todo tipo de profesionales (terapeutas, biólogos,
deportistas...) para crear sistemas interactivos que puedan ser útiles y funcionales para
toda la sociedad.
64
APÉNDICE
A
A NEXOS
A.1 Fuentes
• Ventanas, botones y personajes: http://www.gameart2d.com
• Fondos y elementos gráficos: https://opengameart.org/
• Fondos: http://www.freepik.com
• Fuentes: http://www.pixelsagas.com/
• Música de ambiente: http://freesound.org
A.2 Acta de Reunión
65
ACTA DE REUNIÓN
FECHA 02/12/2016
LUGAR ASPAS (Palma de Mallorca)
HORA INICIO 09:30 HORA FIN 12:00
ASISTENTES Carme Zoilo: Terapeuta de ASPAS.
Camila Pérez: Universidad de las Islas Baleares.
Cristina Manresa: Universidad de las Islas Baleares.
ASPECTOS TRATADOS
Se comenta que se tiene el prototipo físico del juego realizado en Colombia
para evaluarlo en ASPAS. Falta el software para el dispositivo tablet.
Datos obtenidos:
Prototipo físico 1. Se desea cambiar el nombre del personaje a nombres más
del juego mallorquines.
realizado en 2. Se quiere traducir la historia, tarjetas y otros textos al catalán.
Colombia 3. Cambiar ciertas palabras por su versión al castellano español.
4. En vez de que el software sea método invariante, trabajar la
discriminación auditiva (fonemas: br, tr,…) y que suene el sonido, y
se enseñe los dibujos para que el niño seleccione el correcto.
Se comenta la idea de aplicación para el desarrollo del ritmo y se enseña el

primer prototipo para obtener nuevos requisitos.
Datos obtenidos:
1. Un personaje puede llevar implante coclear y otro audífono, para
crear más empatía.
Aplicación para 2. Diferencia de volumen entre ruido o música de fondos y sonido del
el desarrollo ritmo a seguir.
del ritmo 3. El ruido de fondo podría ser ruido blanco.
4. Niveles con diversas dificultades: Velocidad de las notas, número
de botones, número de objetos que caen.
5. Guardar información de los niveles para posterior evaluación.
6. Retirar la ayuda auditiva/visual de las notas que caen para repetir
el nivel y trabajar memoria y ritmo.
7. Añadir vidas.
Se comenta la posibilidad de crear una aplicación que ayude a la
localización del sonido. Funcionaría de la siguiente forma: sonará un
sonido/palabra y el niño tiene que identificar de donde proviene. Una vez
encontrado se pueden enseñar varias imágenes para que el niño escoja el
sonido/palabra que escuchó.
Aplicación para
la localización Los sonidos/palabras pueden ser:
de sonido 1. Sonidos de animales (imágenes del animal)
2. Sonidos de Ling: evalúan la percepción del habla a través
de 6 sonidos que abarcan tanto las frecuencias agudas
como las graves, estos son: /m/, /a/, /i/, /u/, /ch/, /s/.
http://www.aspasleehablacomunica.com/los-sonidos-de-
ling/ (imágenes de tarjetas relacionadas con los sonidos)
Aplicación con dos modos: juego y evaluación. Si está en evaluación,
entonces se tiene que poder guardar la información:
1. Sonido generado.
2. Lado que se está trabajando.
3. Si detecta o no el sonido.
4. Distancia (10 cm, 1 metro, 3 metros, >3 metros).
Carme Zoile explica otros ejercicios que se realizan con los niños y que
podrían mejorar con la tecnología:
1. Desmutizar: proceso por el cuál será preciso en el sordo, realizar
dos entrenamientos previos: por un lado, concienciar de la
existencia de un entorno sonoro; y por el otro, percibir e
Otros ejercicios interiorizar las propias habilidades fonatorias. Siguiendo el ejemplo
de las notas que caen, hacer crecer alguna barra mientras el niño
genera algún sonido.
2. Mención a posibilidad de crear una aplicación que utilice el ruido
blanco / ruido PAVER.
A. A NEXOS
A.3 Póster IPT2017
Desarrollo de la percepción del ritmo en niños con

discapacidad auditiva a través de juegos serios
Autora: Camila Ángela Pérez Arévalo
Tutora: Cristina Manresa-Yee
Motivación
Los niños con discapacidades auditivas pueden encontrarse diversos
obstáculos a la hora de desarrollar ciertas habilidades comunicativas o 8,8%
psicomotoras que son importantes para la evolución de sus emociones, Un total de 360 millones de
acciones y actividades sociales. El uso de las tecnologías de la información personas convive con alguna
y la comunicación (TIC) pueden ayudar a entrenar dichas habilidades discapacidad auditiva, es decir,
más de un 5% de la población
gracias a la creación de distintos sistemas interactivos.
mundial. [2] Del total mundial de afectados,
32 millones son niños de 0 a 14
Las competencias psicomotoras afectadas son las siguientes [1]: años, es decir, el 8.8% de la
población mundial. [2]
- Habilidades motoras fundamentales: Coordinación, equilibrio, postura
+5%
y esquema corporal.
- Habilidades motoras perceptuales: Percepción espacial, percepción
temporal y percepción del ritmo.
- Habilidades cognitivas: Razonamiento y memoria.
Desarrollo de un juego serio, o serious game, diferenciado La propuesta de este sistema interactivo es la de crear un
del concepto de juego conocido normalmente debido al
OBJETIVOS videojuego en 2D para móviles y tabletas con sistema
objetivo final que persigue: Conseguir que el usuario operativo Android, que ayude a los usuarios a desarrollar
adquiera un conocimiento o habilidad determinada de una la capacidad perceptiva del RITMO.
forma entretenida.
A través de una historia ficticia el jugador deberá pasar
Es importante la motivación, el desafío que ofrecen, la por diferentes niveles que pondrán en entrenamiento el
historia del juego y la percepción del progreso mediante manejo del ritmo y que harán conseguir los objetivos del
niveles o puntuaciones. videojuego.
PERSONAJES E HISTORIA
La historia estará protagonizada por un niño o niña (el género será de libre elección por parte
del usuario) que utiliza un implante coclear. En su aventura conocerá a un pequeño dragón que
le acompañará y juntos deberán superar los objetivos de la historia mientras son controlados
por el jugador. El desarrollo del videojuego se llevará a cabo en un reino mágico en el que
nuestro/a protagonista se da cuenta de que todo a su alrededor parece triste y con poco color:
el ritmo ha desaparecido. El/la protagonista, sorprendido por la historia que le cuentan en el
extraño reino y angustiado al ver ese lugar tan desolado, decide ayudar. Así comienza su
aventura totalmente emocionado por descubrir ese nuevo mundo.
DISEÑO Y JUGABILIDAD
La técnica de juego se basará en la visualización de uno de los personajes en la pantalla y de
unos círculos que serán los botones sobre los cuales deberá el jugador situarse para hacer el
ritmo de forma táctil. Sobre la pantalla irán pasando diversos objetos y cuando éstos
atraviesen una de las esferas, será cuando el jugador deba pulsar sobre ella para conseguir
puntos. De esta forma, se pretende que el jugador marque un ritmo sobre la pantalla ayudado
por el estimulo visual de los objetos y los círculos, además de la música que acompañará de
fondo. A medida que se vaya recorriendo el reino mágico, cada nivel incrementará la
dificultad para el usuario modificando la cantidad de notas de la melodía, la velocidad en las
que se moverán y la posición en la que se encuentren los círculos sobre los cual ha de pulsar.
Se ha seguido el diseño centrado en el usuario (UCD), de forma que se investiga a los futuros
usuarios, se diseñan los productos que resuelvan sus necesidades y se van evaluando para
volver a diseñar con las mejoras que se puedan realizar, siguiendo así un proceso iterativo.
Planificación Los resultados de este TFG forman parte del

proyecto OCDS-CUD2016/13 “Diseño de
Análisis de contexto de experiencias interactivas dirigidas al bienestar de
Sistema final uso y requisitos de personas con necesidades especiales” (OCDS, UIB).
• Juego en Google Play usuario

Store • ASPAS (Asociación de
Padres y Amigos del Sordo)
REFERENCIAS
• Trabajos relacionados Diseño [1] V. Peñeñory, C. Manresa-Yee, I. Riquelme, et al. Review of
systems to train psychomotor skills in hearing impaired children.
• Empatía a través de los personajes
REHAB2016.
Evaluación (elección del género, uso de implantes
[2] OMS. Sordera y pérdida de la audición. [online] Disponible en:
• Informe de cocleares)
www.who.int/features/factfiles/deafness/es/. Marzo, 2015.
resultados para el • Jugabilidad
terapeuta • Reto
camilaperezarevalo@gmail.com
cristina.manresa@uib.es
Informática para tod@s: una celebración de ACM-W
Icons made by Freepik from www.flaticon.com
68
A.4. Paper Interacción 2017
A.4 Paper Interacción 2017
Game to Develop Rhythm and Coordination in Children

with Hearing Impairments
Camila Pérez-Arévalo Cristina Manresa-Yee Victor M. Peñeñory Beltrán
Universitat de les Illes Balears Universitat de les Illes Balears University of San Buenaventura Cali
Crta. Valldemossa km 7.5 Crta. Valldemossa km 7.5 Ave. 10 de Mayo, La Umbria, Cali
07122 Palma 07122 Palma Colombia
Spain Spain vmpeneno@usbcali.edu.co
camilaperezarevalo@gmail.com cristina.manresa@uib.es
ABSTRACT fundamental motor skills (e.g. balance, body schema), perceptual

motor skills (e.g. rhythm, coordination) and cognitive skills [4].
Children1 with hearing impairments have deficits and delays in Rhythm in music can refer to the perceived temporal
their psychomotor skills, among them in the perception of rhythm. organization of the physical sound pattern and it is linked to the
In this work we present the design procedure and criteria of an concepts of grouping (figural coding), beat, and meter (metric
app that can help these children to train their rhythm skills and coding). Beats occur at periodic intervals, while meter refers to
consequently improve their visual motor coordination. the temporal organization of beats on multiple hierarchically
related time scales [5]. The perception of rhythm allows
CCS CONCEPTS organizing small perceptual auditory units into highly structured
• Human Centered Computing → Interaction design • Applied auditory sequences that the brain can easily recognize and
computing → Life and medical sciences; Education comprehend [6]. Further, metrical perception is also fundamental
in speech, therefore, benefits in training music rhythm can be
KEYWORDS transferred to communication skills [7,8].
Children, Hearing Impairments, Rhythm, Psychomotor skills, According to Gordon’s Music Learning Theory, the essence of
Design, Serious game rhythm is movement [9], therefore, following rhythm with the
body can imply coordination. Motor coordination refers to the
“harmonious functioning of body parts that involve movements,
ACM Reference format: including gross motor movement, fine motor movement, and
C. Pérez-Arévalo, C. Manresa-Yee and V. Peñeñory. 2017. SIG motor planning” [10] and also comprises the visual motor
Proceedings Paper in word Format. In Proceedings of International coordination which coordinates the vision with the body
Conference on Human Computer Interaction, Cancun, Quintana roo movements.
MEXICO, September 2017 (Interaccion’17), 4 pages Children with hearing impairments perceive rhythm relying
mostly on visual information or tactile stimulation. The
experience of training rhythm and coordination with children with
1 INTRODUCTION hearing impairments can be enhanced by using a serious game,
According to WHO (World Health Organization), 360 million that is, a digital game developed with the intention to entertain
people worldwide have disabling hearing loss, and 32 million of and to achieve the additional goal of training [11]. By means of
these are children whose ages range from 0 to 14 years old. the serious game, we can increase the motivation and the
Disabling hearing loss refers to hearing loss greater than 30 engagement of the children and seek for the actual learning of
decibels (dB) in the better hearing ear in children [1]. other skills.
Children with levels of hearing loss ranging from mild to In this work, we present the design procedure and criteria of an
profound have deficits and delays in their psychomotor app for Android-based mobile devices. The app is a game that
development [2,3]. This special development may affect generates rhythms visually and aurally, and aims at training
rhythm and (visual motor) coordination for children with hearing
impairments (see Fig. 1).
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full
citation on the first page . Copyrights for third-party components of this work must
be honored. For all other uses, contact the owner / author (s).
Interaccion'17, September 2017, Cancun, Quintana roo MEXICO
© 2017 Copyright held by the owner / author (s). 978-1-4503-5229-1 / 25/09. . . $
15.00
69
A. A NEXOS
INTERACCIÓN’17, September 2017, Cancun, Quinta roo, Mexico Pérez-Arévalo et al.
experiences and for serious games. Deterding et al. [18] presented

a taxonomy of game design elements by level of abstraction
which comprises, among others, game interface design patterns
(e.g. badge, leaderboard, level), game design patterns and
mechanics (e.g. limited resources), game design principles and
heuristics (e.g. clear goals), game models (e.g. challenge) and
game design methods (e.g. play-centric design). There are other
game mechanics to design for engagement such as points, levels,
leaderboards, onboarding, challenges and quests, dashboards or
customization [19]. And Reeves and Read [20] listed 10 important
ingredients of great games such as ranks, levels, self-
representation with avatars and competition under rules that are
explicit and enforced.
Figure 1: “El misterio de Armonisia” app: a game to train Recommendations addressed to develop serious games for
rhythm. hearing impaired users are scarce. Cano et al. [21] presented a
methodology for the design of serious games for children with
2 RELATED WORK hearing impairments which considered aspects such as the most
appropriate device, continuous feedback, challenges, scoring
Systems, strategies and studies on training rhythm are the ones
system, and learning levels. They applied the methodology in a
closest to the case we present. Then, game development research
case study for literacy learning. Yi and Kim [22] designed a
works are also compiled to consider game elements to include in
serious game for auditory training taking into account elements of
the development.
initiative, continuity, and fulfillment.
2.1 Training rhythm 3 SYSTEM DESIGN PROCEDURE

We find research works [12] or commercial rhythm games for all
We followed a User-centered design philosophy (UCD),
audiences such as Guitar Hero or Just Dance that challenge the
analyzing the context and the user requirements, designing
player's sense of rhythm by making them generate actions at
solutions and evaluating them initially with therapists. The
precise times following visual cues.
techniques used during the process were field observation,
To teach rhythm to students with hearing impairments, music
interviews with the therapists, literature review, similar systems
educators help students interpret rhythm by playing music suitable
analysis and evaluation of the prototypes with the therapists.
for slower or faster activities, they promote whole body
Specifically, we conducted field observation and collaborated
movement to internalize a rhythm and feel the beat and make use
with therapists and educators from centers and schools for people
of visual and tactile aids (e.g. touching a musical instrument to
with hearing disabilities, both in Colombia and in Spain. Then, we
feel the vibrations) [13].
reviewed the existing literature regarding psychomotor
Finally, we also find in the literature rhythm games addressed
development and children with hearing impairments and studied
specifically to users with special needs. Umaski et al. [14]
game development. Further, we already had experience working
presented a speech rhythm game for children with speech
with hearing impaired children [4,23,24].
disorders. The game represented a downhill slalom ski
Field observation was initially conducted in Colombia at the
competition and the user controlled the slalom skier producing a
Institute of Blind and Deaf Children of Valle del Cauca, to study
sequence of syllables with precise timing. Flappy Voice is a
the activities carried out in a class with children whose ages
mobile game that uses voice control to interact and aims at
ranged from 5 to 13 years. Field observation and interviews with
facilitating acquisition of speech timing and prosody skills for
the educators reported that children with hearing impairments had
children with apraxia of speech. The game is based on the game
the central nervous system altered, presented very soft of very
Flappy Bird and the user controls the bird via the duration and
rigid muscle tone and their psychomotor development was slower
amplitude of his or her voice [15]. Blind Hero, is based on Guitar
compared to a normal hearing child.
Hero, but replaces the visual cues with haptic feedback provided
The children presented balance problems due to the damage in
by a glove [16] for users with visual impairments. Jouhtimäki et
their vestibular system. This condition caused self-distrust in the
al. [17] presented a rhythm game for deaf and hard of hearing
body movements such as jumping, running, catching and throwing
children. In this game, users had to perform various rhythm
objects, and keeping pace. Further, their dynamic coordination,
patterns, from a constant rhythm to more complex ones, to move
balance and muscle tone were affected, therefore it influenced in
the character.
the movement development. Although these children shared
common characteristics, each child presented a unique profile, so
2.2 Game development for serious games therapists carried out a personalized work to contribute in their
Research has analyzed guidelines and recommendations on how motor development.
to design for engagement that are used both for gamified
70
A.6. Paper Interacción 2017
Developing Rhythm and Coordination in Children with HI INTERACCIÓN’17, September 2017, Cancun, Quinta roo, Mexico WOODSTOCK’
In the center for children with hearing impairments, we

observed activities performed in class: activities aiming at
stimulating the gross motor development involved rolling,
crawling, jumping, crouching, throwing objects and dancing.
Other activities trained the fine motor development in which
precision tasks were involved, such as the use of clay, tearing or
punching holes. Both the gross and fine developments were
trained in parallel, as gross motor skills consider also the postural
and muscular development, which help in achieving good fine
motor skills.
Then, we reviewed research related to psychomotor deficits
and delays in children with hearing impairments to generalize the
insights compiled from the field observation and the interviews
and we compiled interactive systems to train psychomotor skills Figure 2: Draft of a level.
with this population [4].
A first prototype was developed and reviewed with a therapist R8. The system should be configurable (e.g. volume and sound
in the Center for Parents of Children with Auditory Impairments for the music base and the targets).
(ASPAS) in Spain. R9. The system must be accessible.
4 SYSTEM DESIGN 4.3 The storyline and characters

In this section, we present the system developed, which is a The main character, Andy, appears in Armonisia, a mysterious,
rhythm game app for Android-based mobile devices. sad and colorless kingdom. The character meets there Rytmus, a
dragon that follows Andy everywhere. While exploring the place,
4.1 Users they encounter an Elf that tells them all about how the kingdom
The target group for the app will be children with hearing lost the joy, and the rhythm (e.g. time beats in an uncontrolled
impairments whose sense of rhythm is underdeveloped. We will manner, citizens cannot play music) and the King is missing.
focus on children whose ages range 5 to 13 years. Nevertheless, Andy, together with Rytmus, decides to help finding the King,
children with no hearing limitations will also be able to play the and the Elf gives them a map with the path to walk. Both start the
game. Therefore, we will achieve an inclusive game. adventure very excited for all the quests and challenges that will
appear in the path.
4.2 Requirements Our experience showed that female players preferred a girl
R1. The game is developed for mobile devices. main character and male players a boy character. Therefore, the
R2. The game presents different pattern rhythms with increasing user is able to choose the genre of the main character (see Fig. 3).
difficulty with visual and sound cues. We decided to include The name of Andy is given due to its possibility of being a girl or
sound as well as visual cues, for those users that had some boy’s name. Further, to improve the empathy of the users, Andy
hearing. The game comprises different levels starting with easy uses a cochlear implant. Due to the therapist comments, the name
rhythms and increasing their complexity. A music base will sound after the first iteration of evaluation is configurable, allowing the
continuously, and the user will match falling/flying objects that main character to be named after the child who is playing.
will scroll onto colored buttons (see Fig. 2). The objects will
follow defined patterns that beat rhythmically, and each button
has an associated sound. The music base can also be white noise.
R3. The system will offer initially visual and auditory cues. Then
the user will have to repeat the rhythm removing all aids or with
just some hints.
R4. The system has to record automatically data on the usage and
results and create reports for the educators or therapists.
R5. The game should include game mechanics to design for fun
and engagement such as points, levels, challenges and quests, and
customization (e.g. character selection) [18].
R6. The user interface has to be informative (showing feedback),
easy to use and attractive for the target group.
R7. The challenge of each level has to be adequate to maintain the
engagement and motivation of the user. Figure 3: Main characters
71
A. A NEXOS
INTERACCIÓN’17, September 2017, Cancun, Quinta roo, Mexico Pérez-Arévalo et al.
rhythm processing in young children. Neuroreport 15, 11: 1723–1726.

4.4 Development [7] Martina Huss, John P Verney, Tim Fosker, Natasha Mead, and Usha
The first system was developed for Android-based mobile devices Goswami. 2011. Music, rhythm, rise time perception and developmental
dyslexia: perception of musical meter predicts reading and phonology.
and uses Unity (a game development platform) to create a 2D Cortex 47, 6: 674–689
game, which will facilitate the development in iOS devices later. [8] Michele Tittarelli, Patrizia Marti, and Diana Peppoloni. 2014. Rapping
Dyslexia: Learning Rhythm, Rhyme and Flow in Dyslexic Children. In
The game displays three states: Proceedings of the 8th Nordic Conference on Human-Computer Interaction:
- Animations: short animations that introduce the story, the Fun, Fast, Foundational (NordiCHI ’14), 865–870.
game and the goals of each level to the player. https://doi.org/10.1145/2639189.2670181
[9] E. E. Gordon. 2012. Learning Sequences in Music: A Contemporary Music
- Map: shows the kingdom of Armonisia, the path and the key Learning Theory. Chicago, IL: GIA Publication
points to visit (which represent the different levels), and Andy’s [10] Mosby. 2009. Mosby’s Medical Dictionary. Elsevier
[11] R Dörner, S Göberl, W Effelsberg, and J Wiemeyer. 2016. Chapter 1.
progress. Introduction. In Serious games, R Dörner, S Göberl, W Effelsberg and J
- Levels: Each level will have a different rhythm to follow: Wiemeyer (eds.). Springer, 1–34. https://doi.org/10.1007/978-3-319-40612-1
number of falling/flying objects, their speed, pattern and number [12] Fengyuan Zhu, Wangshu Sun, Carrie Zhang, and Rebecca Ricks. 2016.
BoomChaCha: A Rhythm-based, Physical Role-Playing Game that
of buttons and their size. By configuring these variables we will Facilitates Cooperation among Players. Proceedings of the 2016 CHI
increase or decrease the difficulty of the level. Fig. 1 shows one of Conference Extended Abstracts on Human Factors in Computing Systems -
CHI EA ’16: 184–187. https://doi.org/10.1145/2851581.2890368
the levels. [13] D M C Trial. 2012. The effects of adaptive instruction on developmental
Each level has a maximum number of points to achieve, and rhythm aptitude and rhythm achievement of preschool students with hearing
impairment. Honors Projects Overview. Paper 62
by following correctly the rhythm, the player gets more or less [14] D Umanski, D Kogovšek, M Ozbič, and N O Schiller. 2010. Development of
points, which will allow him or her to advance in the adventure or a voice-based rhythm game for training speech motor skills of children with
to repeat the same level. speech disorders. In Proc. 8th Intl Conf. Disability, Virtual Reality &
Associated Technologies, 255–262
[15] Tian Lan, Sandesh Aryal, Beena Ahmed, Kirrie Ballard, and Ricardo
4 CONCLUSIONS AND FUTURE WORK Gutierrez-Osuna. 2014. Flappy Voice: An Interactive Game for Childhood
Apraxia of Speech Therapy. In Proceedings of the First ACM SIGCHI
In this work, we presented the design of an app for Android-based Annual Symposium on Computer-human Interaction in Play (CHI PLAY
’14), 429–430. https://doi.org/10.1145/2658537.2661305
mobile devices. The app is a game that generates rhythms visually [16] Bei Yuan and Eelke Folmer. 2008. Blind Hero: Enabling Guitar Hero for the
and aurally, and aims at training rhythm and (visual motor) Visually Impaired. In Proceedings of the 10th International ACM
coordination for children with hearing impairments. The SIGACCESS Conference on Computers and Accessibility (Assets ’08), 169–
176. https://doi.org/10.1145/1414471.1414503
procedure followed to design the game included field observation, [17] Juho Jouhtimäki, Suvi Kitunen, Margaret Plaisted, and Päivi Rainò. 2009.
interviews to professionals, literature review, similar system The Brave Little Troll – A Rhythmic Game for Deaf and Hard of Hearing
Children. 60558. https://doi.org/10.1145/1621841.1621880
analysis and evaluation of prototypes with therapists. The design [18] Sebastian Deterding, Dan Dixon, Rilla Khaled, and Lennart Nacke. 2011.
criteria of the game consider fun, engagement, usability, From Game Design Elements to Gamefulness: Defining “Gamification.” In
Proceedings of the 15th International Academic MindTrek Conference:
aesthetics, configurability and monitoring for the therapists or Envisioning Future Media Environments (MindTrek ’11), 9–15.
educators. https://doi.org/10.1145/2181037.2181040
Future work includes the evaluation of the system with [19] Gabe Zichermann and Christopher Cunningham. 2011. Gamification by
Design: Implementing Game Mechanics in Web and Mobile Apps. O’Reilly
children with hearing impairments. In this evaluation phase, we Media, Inc.
will use interviews with the therapists or educators and end-users, [20] B. Reeves and J.L Read. 2009. Total Engagement: Using Games and Virtual
Worlds to Change the Way People Work and Businesses Compete. Harvard
the System Usability Scale (SUS) and the Intrinsic Motivation Business School Press
Inventory (IMI) questionnaire to assess the game usefulness, [21] S Cano, J Munoz Arteaga, C A Collazos, C S Gonzalez, and S Zapata. 2016.
usability and engagement. Toward a methodology for serious games design for children with auditory
impairments. IEEE Latin America Transactions 14, 5: 2511–2521.
https://doi.org/10.1109/TLA.2016.7530453
ACKNOWLEDGMENTS [22] C. Yi and T. Kim. 2015. Serious Game Design for Auditory Training of
HearingImpaired Children. TechArt: Journal of Arts and Imaging Science 2,
This work was partially supported by the project OCDS- 1: 46–51
CUD2016/13 funded by the University of Balearic Islands. [23] Sandra Cano, César A Collazos, Cristina Manresa-Yee, and Victor Peñeñory.
2016. Principles of Design for Serious Games to Teaching of Literacy for
Children with Hearing Disabilities. In Proceedings of the XVII International
REFERENCES Conference on Human Computer Interaction (Interacción ’16), 6:1--
6:2. https://doi.org/10.1145/2998626.2998650
[1] World Health Organization. 2017. Fact sheet. Deafness and hearing loss. [24] S. Cano, V. Peñeñory, C. A. Collazos, H. M. Fardoun, and D. M.
Availabe at: http://www.who.int/mediacentre/factsheets/fs300/en Alghazzawi. 2015. Training with Phonak: Serious Game As Support in
[2] Freja Gheysen, Gerrit Loots, and Hilde Van waelvelde. 2008. Motor Auditory -- Verbal Therapy for Children with Cochlear Implants. In
development of deaf children with and without cochlear implants. Journal of Proceedings of the 3rd 2015 Workshop on ICTs for Improving Patients
Deaf Studies and Deaf Education 13, 2: 215–224. Rehabilitation Research Techniques (REHAB ’15), 22–25.
https://doi.org/10.1093/deafed/enm053 https://doi.org/10.1145/2838944.2838950
[3] Venkadesan Rajendran and Finita Glory Roy. 2011. An overview of motor
skill performance and balance in hearing impaired children. Italian journal of
pediatrics 37, 1: 33. https://doi.org/10.1186/1824-7288-37-33
[4] V M Peñeñory, C Manresa-Yee, I Riquelme, C A Collazos, H M Fardoun,
and D M Alghazzawi. 2016. Review of systems to train psychomotor skills
in hearing impaired children. In Proc. 4th Workshop on ICTS for improving
patients rehabilitation research techniques, 81–84.
[5] J.D. McAuley. 2010. Tempo and rhythm. In Music Perception. 165–200.
[6] Katie Overy, Andrea C. Norton, Karl T. Cronin, Nadine Gaab, David C.;
Alsop, Ellen; Winner, and Gottfried CA Schlaug. 2004. Imaging melody and
72
B IBLIOGRAFÍA
[1] SFSM, “Discapacidad Auditiva - Sociedad Federada de personas Sordas de Málaga.”

pp. 54–73.
[2] OMS, “Sordera y pérdida de la audición,” 2015, http://www.who.int/features/

factfiles/deafness/es/, (Accessed January 2017).
[3] V. M. Peñeñory, C. Manresa-Yee, I. Riquelme, C. A. Collazos, and H. M. Fardoun,

“Review of systems to train psychomotor skills in hearing impaired children,” 2016.
[4] T. C. Zhao and P. K. Kuhl, “Musical intervention enhances infants’ neural pro-
cessing of temporal structure in music and speech,” Proceedings of the National
Academy of Sciences, p. 201603984, 2016.
[5] U. Goswami, “Rhythmic Timing and Dyslexia: A Causal Connection? : Full Research
Report ESRC End of Award Report, RES-000-23-0475. Swindon: ESRC,” vol. 2010,
no. January, pp. 14–27, 2010.
[6] R. Dörner, S. Göbel, W. Effelsberg, and J. Wiemeyer, Serious Games - Foundations,

Concepts and Practice, 2016.
[7] N. Accordino, “Masaya Matsuura and Shuhei Yoshida on the birth of PaRappa the
Rapper,” 2017, https://blog.eu.playstation.com/2017/04/04/masaya-matsuura-
and-shuhei-yoshida-on-the-birth-of-parappa-the-rapper/, (Accessed November
2016).
[8] “Guitar Hero Series,” 2017, https://www.guitarhero.com/es/, (Accessed November

2016).
[9] “Just Dance Serie,” 2017, https://just-dance.ubisoft.com/es-es/home/, (Accessed

June 2017).
[10] V. Radovanovic, “The influence of computer games on visual-motor integration in

profoundly deaf children,” British Journal of Special Education, pp. 182–188, 2013.
[11] C. Conner, “Correcting Exercise Form Using Body Tracking,” CHI Extended Abs-
tracts on Human Factors in Computing Systems, pp. 3028–3034, 2016.
[12] M. C. Sogono and D. Richards, “A Design Template for Multisensory and Multimo-
dal Games to Train and Test Children for Sound Localisation Acuity,” Proceedings
of The 9th Australasian Conference on Interactive Entertainment Matters of Life
and Death - IE ’13., pp. 1–10, 2013.
73
B IBLIOGRAFÍA
[13] V. Aditya, S. Dhenki, L. Amarvaj, A. Karale, and H. Singh, “Saathi : Making it Easier
for Children with Learning Disabilities to,” pp. 56–61, 2016.
[14] J. Jouhtimäki, S. Kitunen, M. Plaisted, and P. Rainò, “The Brave Little Troll – A
Rhythmic Game for Deaf and Hard of Hearing Children,” Proceedings of the 2016
CHI Conference Extended Abstracts on Human Factors in Computing Systems - CHI
EA ’16., p. 60558, 2009.
[15] F. Zhu, W. Sun, C. Zhang, and R. Ricks, “BoomChaCha : A Rhythm-based , Physical

Role-Playing Game that Facilitates Cooperation among Players,” Proceedings of the
2016 CHI Conference Extended Abstracts on Human Factors in Computing Systems
- CHI EA ’16., pp. 184–187, 2016.
[16] International Organization for Standardization, “ISO 9241-210: Ergonomics of

human–system interaction - Human-centred design for interactive systems,” In-
ternational Organization for Standardization, vol. 2010, p. 32, 2010.
[17] A. CD, “Entrevista a Óscar Araujo,” https://www.vidaextra.com/entrevistas/pienso-

que-la-musica-es-mucho-mas-importante-en-el-videojuego-que-en-el-cine-
entrevista-a-oscar-arajuo-autor-de-la-bso-de-castlevania-lords-of-shadow,
(Accessed May 2016).
[18] Unity, “Made with Unity: Angry Birds 2,” 2013, https://madewith.unity.com/en/
stories/angry-birds-2, (Accessed June 2017).
[19] ——, “Manual Unity,” https://docs.unity3d.com/Manual/index.html, (Accessed

May 2016).
[20] ——, “Asset Store,” https://www.assetstore.unity3d.com/en/, (Accessed December

2016).
[21] E. L. Deci and R. M. Ryan, “The "what.and "why.of goal pursuits: Human needs and
the self-determination of behavior,” Psychological Inquiry, vol. 11, no. 4, pp. 227–
268, 2000. [Online]. Available: http://dx.doi.org/10.1207/S15327965PLI1104_01
[22] J. C. Read and S. MacFarlane, “Using the fun toolkit and other survey methods
to gather opinions in child computer interaction,” in Proceedings of the 2006
Conference on Interaction Design and Children, ser. IDC ’06. New York, NY, USA:
ACM, 2006, pp. 81–88. [Online]. Available: http://doi.acm.org/10.1145/1139073.
1139096
[23] C. Pérez-Arévalo, C. Manresa-Yee, and V. M. P. Beltrán, “Game to Develop Rhythm

and Coordination in Children with Hearing Impairments,” Proc. of the 18th edition
of the International Conference on Human Computer Interaction, pp. 1–4, 2017.
74

Memoria EPSU0809

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Memoria EPSU0809

Cargado por

Copyright:

Formatos disponibles

Escuela Politécnica Superior

Memoria del Trabajo de Fin de Grado

Juego serio para niños con discapacidad

Camila Ángela Pérez Arévalo

Grado de Ingeniería Informática

Año académico 2016-17

DNI del alumno: 43192595K

Trabajo tutelado por Cristina Manresa Yee

Se autoriza a la Universidad incluir este trabajo en el Repositorio Institucional Autor Tutor

Palabras clave del trabajo:

A Carlos Tenorio, porque sin su música Armonisia no hubiese sido Armonisia.

Índice general iii

Índice de figuras vii

4 Proceso de diseño del videojuego 13

4.4.4 Otras pantallas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 Configuración de nuevos niveles 51

8 Publicaciones y participaciones en eventos científicos o divulgativos 61

A.7 Paper Interacción 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.1 Esquema del proceso de Diseño Centrado en el Usuario (DCU) utilizado. . 12

4.1 Boceto inicial de una pantalla de nivel. . . . . . . . . . . . . . . . . . . . . . . 16

5.1 Cámara utilizada en Armonisia y GameObjects situados dentro de su campo

6.1 Vista de Unity al modificar la plantilla de nivel. . . . . . . . . . . . . . . . . . 51

7.1 Niños jugando con Armonisia durante la evaluación. . . . . . . . . . . . . . 57

2.1 Tabla de niveles de pérdida de audición. [1] . . . . . . . . . . . . . . . . . . . 6

4.1 Requisitos no funcionales del proyecto. . . . . . . . . . . . . . . . . . . . . . 16

7.1 Perfiles de cada uno de los participantes de la evaluación. . . . . . . . . . . 56

5.1 Métodos por defecto al crear un script. . . . . . . . . . . . . . . . . . . . . 42

EPS Escuela Politécnica Superior

UIB Universitat de les Illes Balears

TFG Trabajo Final de Grado

OCDS Oficina de Cooperación al Desarrollo y Solidaridad

OMS Organización Mundial de la Salud

TIC Tecnologías de la Información y la Comunicación

PNAS Proceedings of the Naticonal Academy of Sciences

ASPAS Asociación de padres de personas con discapacidad auditiva

DCU Diseño Centrado en el Usuario

IDE Integrated Development Environment

AIPO Asociación para la Interacción Persona-Ordenador

IMI Intrinsic Motivation Inventory

Los niños con discapacidades auditivas presentan diferentes obstáculos durante el

En este capítulo se explica la motivación de la creación e implementación de Armonisia,

1.1 Marco del proyecto

• Objetivo específico 1: Formación bidireccional e investigación.

• Objetivo específico 2: Experiencias interactivas en educación.

• Objetivo específico 3: Experiencias interactivas en salud.

• Objetivo específico 4: Experiencias interactivas emocionales.

1.3 Estructura del documento

1. Capítulo 1 - ’Introducción’: Se describe el marco y contexto en el que se sitúa el

2. Capítulo 2 - ’Conceptos relacionados’: Se describen los conceptos relacionados

3. Capítulo 3 - Metodología’: Se describe la metodología o procedimientos utiliza-

4. Capítulo 4 - ’Proceso de diseño del videojuego’: Se describe la parte creativa del

5. Capítulo 5 - ’Desarrollo e implementación’: Se describe la parte técnica del

6. Capítulo 6 - ’Configuración de nuevos niveles’: Se describen los pasos a seguir

7. Capítulo 7 - ’Pruebas’: Se describen las primeras pruebas y resultados obtenidos

8. Capítulo 8 - ’Publicaciones y participaciones en eventos científicos o divulga-

9. Capítulo 9 - ’Conclusiones’: Se describen las reflexiones y el aprendizaje obteni-

2.1 Discapacidad auditiva

1. Sordas: Deficiencia total o profunda de la capacidad de oír. Se puede recuperar

2. Hipoacúsicas: Deficiencia parcial mejorable con el uso de aparatos auditivos,

Nivel de discapacidad Decibelios

Cuadro 2.1: Tabla de niveles de pérdida de audición. [1]

La Organización Mundial de la Salud (OMS) estimó en el año 2015 que un total de

• Habilidades motoras fundamentales: Coordinación, equilibrio, postura y esque-

2.1.1 Sentido del ritmo