DESARROLLO DE VIDEOJUEGOS PARA TERAPIA DE REHABILITACIÓN DEVELOPMENT OF VIDEO GAMES FOR REHABILITATION THERAPY AUTORES Juan Romo Iribarren - Grado en Ingeniería del Software Álvaro Serna Ramírez - Grado en Desarrollo de Videojuegos Luis Manuel Pérez Cuadrado - Grado en Ingeniería Informática DIRECTOR Carlos García Sánchez Facultad de Informática Universidad Complutense de Madrid Trabajo Fin De Grado Curso 2023/2024 Dedicatoria Juan Romo A mi abuelo que esté donde esté se que está orgulloso de mí. A mis padres, a mi abuela, a mis hermanos y a Milo, que son mi familia. A mi novia, que siempre está para apoyarme. A mis amigos. Álvaro Serna A mi familia y mi pareja, por darme todo su apoyo. A mis amigos, por confiar en mi. Luis Manuel Pérez A mi familia y mi pareja, por su amor y apoyo constante. A mis compañeros del TFG, por su colaboración y compañerismo a lo largo de este proyecto. A mis amigos ii Agradecimientos A Tom Weiland por proporcionar licencias de uso gratuito para uso educativo y ofrecer recursos para la comunidad de desarrollo. A la comunidad de software libre que ha construido varias de las herramientas que hemos utilizado. A nuestro tutor Carlos García Sánchez por el apoyo y la ayuda recibida para realizar este proyecto. Al personal de la Facultad de Informática de la Universidad Complutense de Madrid que nos han acompañado durante estos años. iii Resumen en castellano Los pacientes que han estado un tiempo en la UCI habitualmente han perdido una gran can- tidad de masa muscular debido a la inactividad física, siendo el trabajo de los fisioterapeutas la única forma de estimular su musculatura. El proceso de rehabilitación puede llegar a ser pesado y dificultoso para pacientes, espe- cialmente si son niños, que requieren largos períodos de estancia en la Unidad de Cuidados Intensivos (UCI). Por otro lado, los fisioterapeutas deben seguir el progreso de varios pa- cientes cada uno con limitaciones distintas y esto puede llegar a causar una saturación del trabajo. De esta manera, nuestro trabajo de fin de grado busca ampliar la solución propuesta del año anterior mediante el desarrollo de más videojuegos que permitan al paciente de forma autónoma realizar una serie de ejercicios de rehabilitación. Los videojuegos tendrán como entrada un sistema de sensorización para interaccionar de manera interactiva con el videojuego. Buscamos que el paciente acelere su proceso de recuperación y disfrute del proceso re- cibiendo estímulos positivos por parte de los videojuegos. Por otro lado, también queremos que el equipo de fisioterapeutas pueda llevar un control de sus pacientes, por lo que se va a crear una plataforma web en la que se podrá asignar a los pacientes series de ejercicios personalizados que se aplicarán dentro del videojuego cuando se realice una sesión. Además, durante cada sesión de juego se recuperarán los datos que se obtengan del movimiento de los pacientes, para así poder analizar y crear gráficas donde se vea reflejado el progreso de cada uno. Palabras clave Videojuegos, terapia, rehabilitación, fisioterapeuta, datos, sensor, seguimiento, aplicación web, base de datos, framework. Abstract ICU patients have usually lost a great amount of muscle mass due to long periods of inactivity, and the work of physiotherapists is the only way to stimulate their musculature. Rehabilitation process can be burdensome and difficult for patients, specially if they are kids, that require a great ammount of sessions to recover after long periods in the Intensive Care Unit (ICU). On the other hand, physiotherapists must track patients’ progress, each of the patients with different problems that can involve a greater volume of work. In this way our thesis looks to improve the solution from last year, developing more video games that allow to the patient autonomously to do a set of exercises for rehabilitation. The videogames have as input a sensorization controller that allows the control and interaction with the video games. Our goal is that the patient doesn’t feel rehabilitation as a boring and tedious process, but to speed up their recovery process, enjoying the process by receiving good incentives from the video games. On the other hand, we also want that the physiotherapists to have control over their patients. Therefore, a web application is used to assign sets of exercises to patients, which are configured and personalized so that they are applied within the video game when a patient submits their username. After each game session data will be recovered, tracked from the movement of patients to analyze them and create charts where progress can be followed. Keywords Video games, therapy, rehabilitation, physiotherapist, data, sensor, monitoring, web ap- plication, database, framework. Índice general Dedicatoria ii Agradecimientos iii Resumen iv Abstract v Índice vi Índice de Figuras x 1. Introducción 1 1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Introducción a las tecnologías . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Plan de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Introduction 9 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. State of the art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Introduction to technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. Work plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 vi 3. Tecnologías empleadas y arquitectura del sistema 16 3.1. Tecnologías aplicadas en los videojuegos . . . . . . . . . . . . . . . . . . . . 16 3.1.1. Unity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.2. Piskel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.3. Chart.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2. Tecnologías de control de versiones . . . . . . . . . . . . . . . . . . . . . . . 18 3.3. Tecnologías para la gestión del proyecto . . . . . . . . . . . . . . . . . . . . . 19 3.3.1. GitHub Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.2. Notion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.3. Discord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3.4. diagrams.net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4. Tecnologías aplicadas para la persistencia de datos . . . . . . . . . . . . . . . 21 3.5. Tecnologías aplicadas para la aplicación web . . . . . . . . . . . . . . . . . . 22 3.5.1. Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.5.2. Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.6. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.6.1. Arquitectura general del sistema . . . . . . . . . . . . . . . . . . . . . 25 3.6.2. Arquitectura del módulo videojuegos . . . . . . . . . . . . . . . . . . 26 3.6.3. Arquitectura del módulo aplicación web . . . . . . . . . . . . . . . . 28 3.6.4. Modelo entidad-relación del sistema . . . . . . . . . . . . . . . . . . . 30 4. Diseño y Metodología 32 4.1. Tipos de ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.1.1. Rehabilitación de hombro . . . . . . . . . . . . . . . . . . . . . . . . 32 4.1.2. Rehabilitación de tobillo y pie . . . . . . . . . . . . . . . . . . . . . . 33 4.2. Proceso de diseño de los videojuegos . . . . . . . . . . . . . . . . . . . . . . 33 4.2.1. Recolección de ideas y ejemplos de videojuegos . . . . . . . . . . . . . 34 4.2.2. Diseño de los videojuegos . . . . . . . . . . . . . . . . . . . . . . . . 35 vii 4.2.3. Estética común . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3. Diseño de jugabilidad y mecánicas . . . . . . . . . . . . . . . . . . . . . . . . 36 4.4. Desarrollo artístico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.5. Música y Efectos de sonido . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5. Implementación 40 5.1. Elementos Unificados en todos los juegos . . . . . . . . . . . . . . . . . . . . 40 5.1.1. Menú principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.1.2. Menú de pausa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.1.3. Menú de opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.1.4. Menú de instrucciones . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.1.5. Captura de movimiento . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.1.6. Configuración de los parámetros . . . . . . . . . . . . . . . . . . . . . 45 5.1.7. Registro de datos de movimiento . . . . . . . . . . . . . . . . . . . . 46 5.1.8. Diseño de una API escalable a futuro . . . . . . . . . . . . . . . . . . 47 5.2. Juego 1: GolfingMiniGame . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.2.1. Concepto del juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.2.2. Desarrollo y clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.3. Juego 2: JumpingMiniGame . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.3.1. Concepto del juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.3.2. Desarrollo y clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.4. Aplicación móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.4.1. Desarrollo y clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.5. Aplicación web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.5.1. Desarrollo y clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 6. Resultados 61 6.1. Resultados generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 viii 6.2. Resultados de los videojuegos . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.3. Resultados de la aplicación web . . . . . . . . . . . . . . . . . . . . . . . . . 63 7. Conclusión y perspectivas futuras 69 7.1. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.2. Perspectivas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 8. Conclusion and future perspective 72 8.1. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 8.2. Future perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 9. Contribución 75 9.1. Contribución común . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 9.2. Contribución Álvaro Serna . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 9.3. Contribución Juan Romo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 9.4. Contribución Luis Manuel Pérez . . . . . . . . . . . . . . . . . . . . . . . . . 78 Bibliografia 83 A. Prototipos en papel 84 A.1. Prototipo minijuego de golf . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 A.2. Prototipo minijuego de coche . . . . . . . . . . . . . . . . . . . . . . . . . . 85 A.3. Prototipo minijuego de salto . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 ix Índice de figuras 3.1. Tablero Kanban en GitHub Projects . . . . . . . . . . . . . . . . . . . . . . 20 3.2. Visualización del panel Clerk . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3. Arquitectura general del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4. Arquitectura interacción juego con el controlador . . . . . . . . . . . . . . . 26 3.5. Arquitectura juego-persistencia . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.6. Alta cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.7. Interacción aplicación-clerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.8. Modelo del dominio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.1. Rehabilitación de hombro de pie . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2. Rehabilitación de hombro en silla18 . . . . . . . . . . . . . . . . . . . . . . . 33 4.3. Rehabilitación de tobillo y pie19 . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4. Uso de piskel para la creación de sprites . . . . . . . . . . . . . . . . . . . . 38 5.1. Menú principal GolfingMiniGame . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2. Menú principal JumpingMiniGame . . . . . . . . . . . . . . . . . . . . . . . 41 5.3. Menú pausa GolfingMiniGame . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.4. Menú pausa JumpingMiniGame . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.5. Menú de opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.6. Panel de información GolfingMiniGame . . . . . . . . . . . . . . . . . . . . . 44 5.7. Panel de información JumpingMiniGame . . . . . . . . . . . . . . . . . . . . 44 5.8. Captura Golfing Minigame . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.9. Aplicación controlador dispositivo móvil . . . . . . . . . . . . . . . . . . . . 56 6.1. Configuración obtenida de base de datos . . . . . . . . . . . . . . . . . . . . 62 x 6.2. Nombre de usuario incorrecto . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.3. Retroalimentación movimiento del usuario . . . . . . . . . . . . . . . . . . . 63 6.4. Retroalimentación progreso de la sesión . . . . . . . . . . . . . . . . . . . . . 63 6.5. Formulario de inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 6.6. Listado global de pacientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.7. Listado global de pacientes con dos pacientes asignados al médico . . . . . . 65 6.8. Listado Mis pacientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.9. Crear tabla de ejercicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.10. Error al tratar de asociar una tabla a un paciente con una ya activa . . . . . 67 6.11. Gráficas asociadas a la telemetría del movimiento de los ejercicios . . . . . . 68 6.12. Otras gráficas que muestran las estadísticas mencionadas . . . . . . . . . . . 68 xi Capítulo 1 Introducción En este primer capítulo haremos una introducción acerca del trabajo realizado, indican- do lo que nos ha motivado a desarrollarlo, los objetivos a conseguir e implementar y las tecnologías que hemos empleado para realizarlo. 1.1. Motivación La idea de realizar el proyecto surge de una propuesta de nuestro director del Trabajo de Fin de Grado, Carlos García, consistente en hacer una ampliación del proyecto realizado el año pasado por unos compañeros nuestros. Esta idea nace de buscar una manera de conseguir que el proceso de rehabilitación sea más ameno y menos tedioso de realizar, en el cual la posibilidad de poder desarrollar videojuegos es el escaparate perfecto para poder demostrar que los videojuegos no solamente son para entretener, si no que además puede cumplir este propósito. Este proyecto nace con la intención de complementar el desarrollo de estos videojuegos con una plataforma dónde tanto los profesionales de la salud cómo los pacientes puedan acceder para ver el progreso de la rehabilitación, además de los ejercicios y tareas que deben realizar para poder recuperarse satisfactoriamente, adicionalmente por parte del equipo de fisioterapia tendrán a un par de clicks la información y estadísticas del progreso de sus respectivos pacientes, y de poder medir de manera cuantitativa este progreso gracias a la recogida de datos en crudo, además la capacidad de poder asignar nuevos ejercicios según 1 vaya avanzando el paciente en el proceso de recuperación. En definitiva, es una propuesta que tiene un bonito objetivo como es el hacer más agradable el duro proceso que puede llegar a ser una rehabilitación, y con el complemento de poder visualizar este progreso en una aplicación. Es un proyecto que toca muchos matices y en el que hemos podido plasmar lo aprendido durante estos años. 1.2. Estado del arte Actualmente es cada vez más común que la tecnología cobre un papel mucho más rele- vante en todos los aspectos de nuestras vidas. En el ámbito de la sanidad se han realizado grandes avances gracias a la tecnología que como puede ser en el caso de la rehabilitación han propiciado una mejora en la calidad de vida de aquellos que deben seguir un proceso de recuperación de lesiones o afecciones físicas. La tecnología ha revolucionado por completo la manera en que se tratan y abordan las lesiones físicas y discapacidades. Como pueden ser dispositivos de ayuda o entornos de realidad virtual y aumentada. Uno de los avances más destacados es la integración de la realidad virtual (RV) y la realidad aumentada (RA) en la terapia de rehabilitación, estas tecnologías permiten a los pacientes sumergirse en entornos virtuales que simulan actividades del mundo real, lo que facilita la práctica de movimientos y actividades físicas de una manera mucho más controlada que en un entorno externo. De la misma manera los videojuegos han surgido como una herramienta innovadora en la terapia de rehabilitación. Gamificar una terapia puede motivar a los pacientes a ser más participativos en el proceso y hacer más llevadera su recuperación. Los videojuegos al igual que los entornos interactivos pueden ofrecer un escenario seguro para realizar los ejercicios necesarios por los pacientes y permitiendo a los terapeutas observar los resultados a través del rendimiento y el desempeño de los pacientes en cada partida. No es habitual ver el desarrollo de juegos orientados específicamente a la terapia de rehabilitación y se optan por opciones más comerciales, cómo puede ser el conocido juego 2 de Nintendo, Wii Fit36. En este juego se realizan sobre un dispositivo similar a una balanza varios tipos de ejercicios y actividades físicas, tales como yoga o ejercicios aeróbicos realmente útiles para rehabilitación y mejora de la movilidad de la zona lesionada, y para recuperar el equilibrio y coordinación. Bien es cierto que este tipo de opción no es tan personalízale, por lo que la idea de desarrollar un juego totalmente enfocado a la terapia y dónde el terapeuta pueda configurar y personalizar el juego en función de las necesidades de cada paciente, en vez de que el paciente se adapte al juego, es la mejor solución. Nuestra idea es buscar la manera de llevar a cabo este desarrollo y que además sea accesible y de fácil instalación para todo el que necesite hacer uso de ello. Nuestra idea plantea un proceso de instalación sencillo ya que tan solo se deberá instalar el juego tanto en un ordenador de sobremesa o portátil con Windows, o un dispositivo de tipo tablet Android, y por otro lado la aplicación que establece el envío de movimientos en un dispositivo móvil Android. Al utilizar este sistema se abre la posibilidad de que los pacientes no requieran de estar presencialmente en el centro médico para realizar sus terapias de rehabilitación, ya que el terapeuta podrá recabar información del paciente después de la realización de cada sesión de ejercicios, consultando estos datos en una base de datos que almacene las sesiones realizadas por cada paciente. 1.3. Objetivos Los objetivos del proyecto son claros: Hacer más llevadero el proceso de rehabilitación de los pacientes proporcionando soft- ware que facilite este objetivo. Usar un hardware que esté al alcance de todos. Implementar unos videojuegos que: 3 • Sean sencillos de instalar. • Sean personalizables. • Sean de fácil despliegue en varias plataformas. • Tengan una interfaz de usuario sencilla y responsiva. • Reaccionen al movimiento de los usuarios. Implementar una aplicación que permita: • La autenticación de usuarios. • Ver estadísticas. • Configurar nuevos ejercicios o sesiones de rehabilitación. Para cumplir los objetivos anteriores debemos diseñar y desarrollar dos juegos los cuales sean personalízales por parte de los fisioterapeutas en función de las necesidades de cada paciente. Por ello tendremos que: Diseñar e implementar mecánicas, dinámicas y jugabilidad basadas y que sean respon- sivas a la realización del movimiento de rehabilitación designado. Buscar un sistema de detectar el movimiento por parte del jugador y enviar esos datos al juego en forma de entrada. Añadir visualización y retroalimentación claras acerca del estado del juego. Ofrecer una experiencia satisfactoria y precisa para el paciente a la hora de realizar el movimiento. Guardar los datos recogidos a través del sistema de sensorización para el feedback y el posterior análisis por parte de los fisioterapeutas. Por otro lado se debe desarrollar una aplicación que, para cumplir el objetivo de portabili- dad y accesibilidad será en formato web y además tendrá un back-end donde se almacenarán 4 tanto los usuarios de la aplicación como la configuración personalizada de cada uno de los pacientes en cada uno de los juegos, y por otro lado el juego después de cada sesión de un paciente actualizará los datos recogidos del input y los almacenará en la base de datos haciendo referencia al usuario que tuviese asignado ese ejercicio. 1.4. Introducción a las tecnologías Aquí nombraremos y haremos una breve introducción sobre las tecnologías que nos han servido de ayuda para llevar a cabo nuestro proyecto. Más adelante, en el capítulo 3, daremos una explicación más detallada de cada tecnología además de la arquitectura de nuestro proyecto. Para el desarrollo de los juegos nos hemos decantado por el motor de videojuegos Unity23, ya que con sus licencias para estudiantes gratuitas nos facilita el desarrollo de cada uno de los juegos, es una herramienta de la que ya se poseía un mínimo cono- cimiento y por otro lado también es uno de los motores para aprender e introducirte en el desarrollo de videojuegos, además la comunidad activa de desarrolladores que tiene Unity nos ha permitido poder buscar información y solventar dudas o inconvenientes que nos hayan surgido durante el desarrollo. Para la aplicación web: • Frontend: como framework hemos hecho uso de Tailwind21 un framework de CSS que prioriza la utilidad y viene equipado con clases que ayudarán a construir el estilo de nuestro sitio web directamente desde nuestros HTML. Además hemos empleado React16 para agregar componentes y crear una interfaz de usuario que satisfaga las necesidades de nuestra aplicación web. • Backend: Hemos hecho uso de TypeScript22, es un lenguaje construido sobre JavaScript pero que al contrario que éste, permite un fuerte tipado y añade 5 sintaxis adicional para soportar una mejor integración y poder comunicar el front- end de nuestra aplicación con la base de datos. En cuanto a la persistencia decidimos usar una base de datos no relacional como es MongoDB10, ya que tiene una excelente integración con Unity gracias al SDK17 que ofrece para diversas plataformas entre ellas C# .NET, y Unity posee un sistema de scripting basado en C#. Además uno de los puntos que también nos hizo decantarnos por este modelo de base de datos fue la capa de aplicación y servicios que ofrece Mongo de manera totalmente gratuita como pueden ser MongoDB Atlas11 y MongoDB Compass12. Para el control de versiones hemos usado Git7, es uno de los sistemas de control de versiones distribuidos más conocidos y además todos habíamos trabajado ante- riormente con él, con lo cual no nos ha sido muy dificultoso poder llevar una buena gestión de los elementos que se subían al repositorio y el poder trabajar simultánea- mente sobre el mismo proyecto, mejorando de esta manera nuestro flujo de trabajo considerablemente. Hemos alojado nuestros repositorios en GitHub8. Referido a la gestión del proyecto hemos hecho uso de varios software de gestión pa- ra llevar acabo las tareas y objetivos del proyecto, en primer lugar empezamos con Notion14, un programa de gestión tanto de proyectos grupales como organización personal, en él existen numerosas plantillas realizadas por usuarios o desarrolladas por el propio Notion y éstas plantillas nos han ayudado a gestionar nuestro proyecto ya sea tomando apuntes y notas rápidas, crear listas de tareas para poder aplicar meto- dologías ágiles de desarrollo, programar reuniones y apuntar los aspectos importantes de cada una y un largo etcétera de gestiones. Más avanzado el desarrollo descubrimos la herramienta de proyectos29 que posee GitHub, en esta herramienta se pueden definir tableros estilo Kanban o Scrum totalmente personalízales dónde generar las 6 tareas a realizar y que una vez definidas se asignen a un issue concreto de un repo- sitorio concreto, de esta manera rápida, sencilla y visual se puede centralizar todo el trabajo a realizar de un proyecto y poder tener un seguimiento más preciso ya que desde estas tareas definidas se puede crear ramas para resolver ese problema concreto. Con esto sobre la mesa decidimos migrar todo nuestra lista de tareas a esta plataforma y trabajar directamente sobre GitHub. Por último para la comunicación hemos hecho uso de Discord5, una plataforma enfocada a la comunicación tanto por chat de voz cómo por chat de texto, para realizar el seguimiento de nuestra actividad a través de reuniones de frecuencia adaptable al punto del proyecto en el que nos encontrásemos. 1.5. Plan de trabajo Con el fin de conseguir los objetivos mencionados anteriormente, primeramente deba- timos la manera de organizarnos y cómo procederíamos con el desarrollo, y llegamos a la conclusión de aplicar una metodología de trabajo basado en metodologías ágiles como SCRUM20 y Kanban30. Esta metodología ha consistido en establecer reuniones para definir hitos y en función de esos hitos programar una serie de sprints de un tiempo de duración variable en función del estado en el que se encontrase el proyecto, en un principio la dura- ción de un sprint se definió en una semana. Al finalizar cada sprint se realizaba una reunión para definir la iteración del siguiente sprint. Con el cumplimiento de cada hito se volvía a iterar sobre lo trabajado y reajustando el tiempo de los sprints para el siguiente hito en caso de que fuese necesario, también entre cada sprint se programaba al menos una reunión para definir las tareas a realizar por cada uno de nosotros durante ese sprint. Con el uso del software de gestión también mencionado con anterioridad podíamos definir de manera concisa las tareas que estaban pendientes de realizar, las que se iban a realizar en el sprint actual y quién tenía asignada cada tarea, entre otras cosas. Para tener un buen control de versiones decidimos fragmentar cada uno de los aspectos del trabajo en un proyecto y repositorio distinto en GitHub, en total han sido cuatro repo- 7 sitorios, uno para cada uno de los juegos, otro para la aplicación móvil encargada de enviar la sensorización, y un último repositorio alojando la aplicación web. Esto nos ha permitido tener un mejor manejo de cada aspecto de los proyectos evitando mezclar elementos que pudiesen causar conflictos a la hora de unificar el trabajo. Los repositorios se encuentran en la siguientes direcciones: Golfing Minigame: https://github.com/TFG2324Rehabilitacion/GolfingMiniGame Jump Minigame: https://github.com/TFG2324Rehabilitacion/JumpingMiniGame Phone application: https://github.com/TFG2324Rehabilitacion/MobileApplication Web application: https://github.com/JuanRomo-dev/TFG_APP 8 https://github.com/TFG2324Rehabilitacion/GolfingMiniGame https://github.com/TFG2324Rehabilitacion/JumpingMiniGame https://github.com/TFG2324Rehabilitacion/MobileApplication https://github.com/JuanRomo-dev/TFG_APP Capítulo 2 Introduction In this chapter we will make an introduction about the work done, indicating what has motivated us to develop it, the objectives to be achieved and implemented and the technologies we have used to do it. 2.1. Motivation The idea of start up this project arises from a proposal consisting of making an extension of the projects carried out last year by our colleagues. This idea comes from looking for a way to make the rehabilitation process more enjoyable and less tedious to perform. The possibility of being able to develop video games is the perfect showcase to demonstrate that video games are not only to entertain but also can fulfill a purpose like this. This project was also born with the intention of complementing the creation of the video games with a platform where both patients and health professionals can access to see the progress of the rehabilitation, in addition to the exercises and tasks to be performed to have a successful recovery. Additionally, the physiotherapy team will have within a couple of clicks the information and statistics of their respective patients, and will be able to quantitatively measure this progress thanks to the raw data gathering, in addition the ability to assign new exercises as the patient progresses in the recovery process. Definitely, it it a proposal that has a beautiful objective like it is to soften the process of rehabilitation in some patients and with the complement of being able to visualize the 9 progress in an application. It is a project that touches many nuances and in which we have been able to show what we have learned through the years. 2.2. State of the art Nowadays it is increasingly common for technology to play a more relevant role in all aspects of our lives. In the field of healthcare, a great amount of advances have been made thanks to technology that have led to an improvement in the quality of life. Like the lives of those who must follow a process of recovery from injuries that affect physical conditions. Technology has completely revolutionized the way physical injuries and disabilities are treated and addressed. Such as assistive devices or virtual and augmented reality envi- ronments. One of the most prominent advances is the integration of virtual reality (VR) and augmented reality (AR) in rehabilitation therapy, these technologies allow patients to immerse themselves in virtual environments that simulate real-world activities, which faci- litates the practice of movements and physical activities in a much more controlled manner than in an external environment.26 31 In the same way, video games have emerged as an innovative tool in rehabilitation therapy. Gamifying a therapy can motivate patients to be more active in the process and make their recovery more bearable. Video games as well as interactive environments can provide a safe scenario to perform the exercises needed by patients and allow therapists to observe the results through the performance of patients in each game. It is not common to see the development of games specifically oriented to rehabilitation therapy and more commercial options are chosen, such as the well-known Nintendo game, Wii Fit. In this game, various types of exercises and physical activities are performed on a scale, such as yoga or aerobic exercises that are really useful for rehabilitation and improving the mobility of the injured area, and also useful for recovering balance and coordination. It is true that this type of option can not be customize in every way. So there goes the idea of developing a game totally focused on therapy and where the therapist can configure and 10 customize the game according to the needs of each patient, instead of the patient adapting to the game, this have resulted to be the best solution. Our idea is to find a way to carry out this development and also to make it accessible and easy to install for anyone who needs to make use of it. Our idea proposes a simple installation process since the games can be installed on a desktop computer with Windows or an Android device, and on the other hand the applica- tion that send the patient movements in a mobile device. Using this system opens the possibility that patients do not need to be in the Intensive Care Unit(ICU) to perform their rehabilitation therapies, since the therapist can collect information from the patient after the completion of each exercise session. The results can be obtained by consulting to a database that stores the sessions performed by each patient. 2.3. Objectives The objectives of the project are clear, to make the rehabilitation process more bearable for patients by providing software that facilitates the above, and using hardware that is affordable for everyone, simple to install, customizable and easy to deploy anywhere. Also with the addition of implementing an application that allows user authentication and with different screens both to view statistics and to configure new exercises or rehabilitation sessions. To accomplish the above we must design and develop two games which are customizable by physiotherapists depending on the needs of each patient. Therefore we will have to: Design and implement mechanics, dynamics and gameplay to be based and responsive to the performance of the designated rehabilitation movement. Find a system to detect the movement by the player and send that data to the game to act as the video game input. Add clear visualization and feedback about the state of the game. 11 Provide a satisfying and accurate experience for the patient in performing the move- ment. Store data collected through the sensorization system for feedback and further analysis by the physical therapists team. On the other hand, an application must be developed which will have to meet the objective of portability and accessibility, the best way to achieve this is by a web based format and will also have a backend where both the users of the application and the personalized configuration of each of the patients in each of the games will be stored, and way apart the game after each session of a patient will update the data collected from the input and store them in the database with reference to the user assigned to that exercise. 2.4. Introduction to technologies Here we will name ad briefly introduce the technologies that has helped us to develop our project. Later in chapter 3, we will give a more extensive explanation of each technology in addition of the architecture of our project. For the game development we have decided to use the game engine Unity23, due to the free student licenses has made it easier for us to develop the video games. It is a tool of which we already had a minimum knowledge and on the other hand is also one of the easier engines to learn and to introduce you to the development of video games. Also the active community of developers that has Unity has allowed us to find information and solve doubts or problems that have arisen during development. For the web application: • Frontend: we have made use of Tailwind21 as a CSS framework, it prioritizes utility and comes equipped with classes that will help us to build the styles for our website directly from our HTML. Also we used React16 to add components and create a user interface that satisfies the needs of our web application. 12 • Backend: we have used TypeScript22, it is a language build over JavaScript but unlike it, permits a strong type and adds additional syntax to support a better integration and communicate the frontend of our application with the database. Talking about persistence, we decided to use a non realational database like it is Mon- goDB10, additionally it has a great integration with Unity thanks to the SDK it offers for different platforms including C# .NET, and Unity has a C#-based scripting sys- tem. Also one of the points made us decide in favor of this database it is the application layer and services that Mongo provides in a totally free manner like MongoDB Atlas11 and MongoDB Compass12. For version control we have used Git7, it is one of the most popular distributed version control system and in addition we all have worked previously with it, whereby it has not been very difficult for us to have a great management on the elements that we uploaded to the repository and work simultaneously on the same project. Improving in this way our workflow considerably. We hosted our repositories on GitHub8. Refered to project management we have made use of different management software to take care of the tasks and objectives of the project. Firstly we have Notion14, a program destined to project management and self daily organization, in it exists numerous templates made by user or developed by Notion, this type of templates helped us to manage the project with the option to take quick notes, create task list, made collaborative documentation and to schedule meetings and a long etcetera. At a more advanced point we heard of the projects tool29 from GitHub, in this tool you can define Kanban-like boards totally customized where you can quickly generate tasks and assign them to a determined issue, with this we could centralize our work and have a more precise tracking because GitHub permits to create a branch for a specific issue. With all this alternatives over the table we migrated all over GitHub. Finally for the communication part we used Discord5, it is a platform focused to voice and 13 chat communication, to keep track of our activity we made frequent meeting over this platform to expose our advancements and assign new ones. 2.5. Work plan In order to achieve the objectives mentioned before, firstly we had to debate the to organize us and how we would proceed with the development, we ended up concluding that the way to go was to apply a wor methodology based on the agile method like SCRUM and Kanban. This methodology consisted in the establishment of meetings to define milestones, based on these milestones, schedule a series of sprints of varying duration depending on the status of the project; initially the duration of a sprint was defined as one week. At the end of each sprint a meeting was organized to define the iteration on the upcoming sprint. With the accomplishment of each milestone we iterated over the work done and in case it was necessary, we made readjustments to the sprint duration for the next milestone. Also between every sprint at least one meeting was programmed to define the tasks to be done by each of us in that sprint. With the use of the management software mentioned above we could define in a precise manner the tasks that were pending to be carried out, the ones that would be done in that sprint and who had assigned each task. To have a clean version control we have decide to fragment every aspect of the work in a different repository hosted on GitHub, a total of four repositories, one for each game, one for the mobile application and the last one hosting the web application. This allowed us to have a better management of every aspect of the projects and avoiding to merge elements that could cause conflicts when unifying the work. The repositories can be found in the following directions: Golfing Minigame: https://github.com/TFG2324Rehabilitacion/GolfingMiniGame Jump Minigame: https://github.com/TFG2324Rehabilitacion/JumpingMiniGame Phone application: https://github.com/TFG2324Rehabilitacion/MobileApplication 14 https://github.com/TFG2324Rehabilitacion/GolfingMiniGame https://github.com/TFG2324Rehabilitacion/JumpingMiniGame https://github.com/TFG2324Rehabilitacion/MobileApplication Web application: https://github.com/JuanRomo-dev/TFG_APP 15 https://github.com/JuanRomo-dev/TFG_APP Capítulo 3 Tecnologías empleadas y arquitectura del sistema A continuación se indican las tecnologías y herramientas aplicadas para el proyecto, así como la arquitectura del sistema explicando cómo funciona. 3.1. Tecnologías aplicadas en los videojuegos 3.1.1. Unity El motor de desarrollo utilizado es Unity23, que se utiliza principalmente para la crea- ción de videojuegos multiplataforma. Unity Technologies25 fue fundada en Dinamarca en el año 2004, centrado en aquel entonces en el desarrollo para dispositivos de Apple, pero desde entonces fue creciendo para convertirse en uno de los frameworks de videojuegos más importantes del mercado, estableciéndose para el desarrollo multiplataforma tanto de orde- nadores de mesa, como móviles Android o iOS, así como videoconsolas (PlayStation, XBOX, Nintendo Switch, etc.). Además, Unity permite crear videojuegos tanto en dos como en tres dimensiones, utilizándolo desde estudios ya establecidos en la industria como es el caso de Super Mario Run, desarrollado por Nintendo para dispositivos móviles o Hollow Knight, uno de los metroidvanias más importantes de los últimos años, publicado y desarrollado por el estudio indie Team Cherry. También ha trascendido la industria de los videojuegos, utilizándose para crear simulaciones interactivas en sectores como el cine, la animación, la 16 automoción, la arquitectura e ingeniería, o incluso las Fuerzas Armadas de los Estados Uni- dos han utilizado Unity para sus simulaciones. Otra gran ventaja de Unity es que permite acoplar una gran variedad de integraciones con otras aplicaciones como Blender, Adobe Photoshop, Cinema 4D, Cheeta3D, etc. En cuanto a las tecnologías Unity utiliza OpenGL para poder implementar los juegos también en navegador, Direct 3D y las interfaces propias de cada plataforma. Observando todas estas características, es un hecho que Unity ha permitido que el desa- rrollo de videojuegos sea más accesible, junto a otros motores como Godot, Phaser o Unreal Engine, por lo que en el ámbito académico también destaca. Es por todas estas ventajas que decidimos implementar los videojuegos con Unity, ya que en el equipo teníamos al menos nociones básicas para poder empezar a trabajar y conseguir soluciones funcionales. En cuan- to al desarrollo en sí, nos inclinamos por implementar los videojuegos en dos dimensiones, para simplificar las complicaciones que se pueden dar en tres dimensiones, utilizando una estética pixel art y como lenguaje para los scripts hemos utilizado C# Para establecer una red interna que permita conectarse con un dispositivo móvil Android y controlar el juego hemos utilizado la integración Riptide41, que se utiliza principalmente para juegos multijugador, pero en nuestro caso lo hemos adaptado para que se establezca un servidor local mediante el cuál el cliente se conecta introduciendo la dirección IP mostrada en la pantalla a través de la aplicación del controlador en el móvil antes de comenzar el juego, y procesando la conexión para que así el jugador pueda mediante captura de movimiento controlar el movimiento del ejercicio. Por otro lado, el movimiento del dispositivo Android se captura mediante el acelerómetro que todos los dispositivos de estas características tienen por defecto, permitiendo leer la aceleración lineal en los 3 ejes X, Y, Z, que se obtiene mediante la librería interna de Unity Input. Mediante la API de esta librería se obtienen estos parámetros, procesándolos para que la red los envíe al juego. Por otra parte, para la gestión de la persistencia y poder obtener y almacenar datos sobre las sesiones de los juegos, hemos utilizado Realm17, que almacena datos en colecciones 17 de objetos para enviarlos a MongoDB. 3.1.2. Piskel Piskel15 es un editor online y gratuito que permite crear sprites animados y pixelart desde el navegador. Lo hemos utilizado para crear algunas de las animaciones y editar texturas pixel art de los juegos. Otras texturas que se han utilizado se han obtenido en itch.io y se han citado debidamente a sus creadores en la sección de citas de la memoria. Piskel es muy sencillo, pues permite por capas crear sprites y mediante frames se pueden crear spritesheets que implementan las animaciones que luego se construyen desde Unity. La facilidad de poder construir sprites y exportarlos como spritesheets son las razones por las cuáles hemos utilizado este editor que además es intuitivo y se puede utilizar sin casi aprendizaje. 3.1.3. Chart.js Chart.js2 es una biblioteca de JavaScript de código abierto que permite crear gráficos interactivos y visualmente atractivos directamente en el navegador web. Utiliza la etiqueta canvas de HTML5 para renderizar los gráficos, lo que los hace altamente personalizables y compatibles con una amplia gama de dispositivos y navegadores. Hemos utilizado Chart.js debido a su facilidad de uso y su amplia gama de opciones de personalización en nuestro proyecto para visualizar datos de manera clara y comprensible para los usuarios. Con esta herramienta, hemos creado diversos tipos de gráficos, como gráfi- cos de líneas y barras, para representar datos estadísticos, progreso de juegos y puntuaciones para nuestra aplicación. 3.2. Tecnologías de control de versiones En el caso de los videojuegos nos hemos inclinado por hacer uso de Git7, pues aunque Unity tiene su propio sistema de control de versiones conocido anteriormente como Plastic 18 itch.io y actualmente como Unity Version Control, hemos considerado más complejo el uso de este, pues en Git tenemos conocimientos más avanzados y estamos más habituados a su uso, además de que está probada su eficacia como sistema de control de versiones para desarrollos con Unity. El único problema que nos encontramos es que hay que configurar correctamente el proyecto de Unity y excluir en el fichero .gitignore los archivos temporales y de configuración internos de Unity, manteniendo únicamente lo que tiene que ver con el desarrollo del juego en sí. Para ello nos hemos basado en el fichero .gitignore contenido en Github for Unity27. En concreto hemos utilizado GitHub8 ya que contiene aún más funcionalidades que nos han sido útiles también además del control de versiones. Además GitHub está contrastado, pues se utiliza en una gran parte del mercado de desarrollo de software. Nos ha permitido colaborar y realizar cambios en el proyecto manteniendo un seguimiento del progreso, albergando los repositorios de los juegos y la aplicación, además de que nos ha ayudado con la gestión de proyecto. 3.3. Tecnologías para la gestión del proyecto 3.3.1. GitHub Projects GitHub Projects29 se trata de una herramienta incorporada nativamente en GitHub que permite planificar y realizar un seguimiento del trabajo en un repositorio. Funciona como una hoja de cálculo en la cual se pueden establecer paneles y tablas que se integran con las issues creadas, pudiendo tanto filtrarlas, agruparlas, así como asignarlas a campos y estados diferentes. En nuestro caso nos hemos basado en Kanban30, por lo que hemos utilizado un tablero que permite dividir las tareas en diversos estados. Se describe más en profundidad la gestión del proyecto en su debido apartado. 3.3.2. Notion Notion14 lo hemos utilizado para gestión de documentación que nos pudiese ayudar en el proyecto, aunque hemos tratado de usar la menor documentación propia posible, al 19 Figura 3.1: Tablero Kanban en GitHub Projects utilizar las metodologías agile y buscar la optimización del tiempo sin tener que depender de procesos cerrados en documentos. Notion permite tener un espacio de gestión documental, similar a OneDrive o Google Drive, pero permitiendo utilizar una gran variedad de plantillas focalizadas en el desarrollo de software. Aquí hemos descrito algunos de los requisitos básicos del sistema, además de llevar un registro básico de las reuniones. 3.3.3. Discord Discord5 consiste en un servicio que incorpora chat de voz VoIP, mensajes de texto ya sea conversaciones privadas o servidores. En nuestro caso establecimos un servidor de Discord, en el cuál tenemos una serie de canales de voz que al trabajar colaborativamente nos ha sido muy útil, pues permite compartir pantalla mientras se está hablando y también se pueden compartir ficheros y archivos de forma instantánea, agilizando nuestro flujo de trabajo. 20 3.3.4. diagrams.net Anteriormente conocido como draw.io, diagrams.net4 se trata de un software libre multiplataforma que se ejecuta en web, que se puede utilizar para la creación de diagramas UML y otros, permitiendo exportarlos en formatos como PDF, SVG, PNG o JPG. Lo hemos utilizado para la creación de diagramas que nos permitiesen entender la arquitectura del sistema así como para los diagramas presentes en la memoria. 3.4. Tecnologías aplicadas para la persistencia de datos Para poder almacenar y mantener una base de datos, hemos apostado por MongoDB10, pues nos encontramos con la necesidad de poder cruzar datos entre los juegos y la aplicación web, entonces como Unity se integra muy bien con MongoDB, decidimos implementar la persistencia en esta tecnología, además de que el hecho de que MongoDB Atlas11 permi- tiese gratuitamente implementar la base de datos en la nube es un factor también a tener en cuenta. Mediante Atlas hemos podido gestionar el cluster que contiene la base de datos completa, permitiendo a través de su API la conexión desde todos los puntos necesarios del sistema. Por otra parte, MongoDB Compass12 se trata de la GUI propia de Mongo, que permite consultar, optimizar y modificar los datos, por lo que nos servía para validar y confirmar que las diversas operaciones del sistema se estaban ejecutando correctamente. El funcionamiento es muy sencillo, pues Compass se conecta a la IP del cluster que contiene Atlas, y entonces se despliega la base de datos, donde se contienen las colecciones de docu- mentos y estos se pueden editar y realizar consultas sobre ellos. MongoDB se trata de una base de datos NoSQL, por lo que no usan SQL como lenguaje estándar (aunque lo soportan) para las consultas, ni permiten el uso de operaciones como JOIN. Su estructura se parece más bien al formato JSON, en este caso el sistema de documentos se conoce como BSON al permitir almacenar datos de forma binaria al contrario de JSON. Se trata por tanto de lo que se conoce como una base de datos documental. 21 3.5. Tecnologías aplicadas para la aplicación web 3.5.1. Backend Node.js Se trata de un entorno de ejecución para JavaScript multiplataforma de código abierto y gratuito, que permite crear aplicaciones web escalables. Se localiza en la capa del servidor, teniendo una arquitectura orientada a eventos. Node.js13 funciona con un único hilo, por lo que usa entradas y salidas asíncronas, atendiendo por tanto múltiples peticiones concu- rrentes. Otra gran ventaja de este entorno es que su ecosistema de gestión de paquetes es npm, que además es uno de los gestores de software libre más grandes que existen. A través de npm hemos instalado las dependencias necesarias para las extensiones y herramientas utilizadas en la aplicación, que se gestiona mediante la terminal de comandos y también ejecutar el programa cuando se encontraba en desarrollo a nivel local. Typescript Es un lenguaje de programación fuertemente tipado que está basado en JavaScript. Fue creado por Microsoft ideado para poder inferir tipos, a diferencia de como sucede en Javas- cript. Typescript22 facilita la gestión y localización de bugs y errores en el código, además de que se acopla muy bien a frameworks de desarrollo web. Mediante scripts implementados con este lenguaje se ha realizado la conexión con MongoDB y la integración con Clerk para gestionar las sesiones. Clerk Proporciona una plataforma de gestión de usuarios y de sesiones mediante una API. Clerk28 permite incorporar funciones de inicio y registro de usuarios, mediante correo elec- trónico y contraseña o mediante integraciones como Google y Facebook, además de mantener sesiones abiertas de la aplicación. Esto facilita mucho la gestión de usuarios, ya que imple- mentarlo desde 0 es complejo. El administrador puede observar desde el panel de Clerk los 22 usuarios que se han registrado y gestionarlos. El problema que nos hemos encontrado ha sido almacenar los datos referentes a los usuarios, como su nombre o correo electrónico en la base de datos, por lo que para solventarlo se ha implementado un webhook en los ser- vicios de aplicación en MongoDB Atlas. Este script extrae los encabezados de la solicitud HTTP cuando se registra un nuevo usuario en clerk, gracias a una clave secreta para el uso de webhooks en clerk. A continuación se obtienen el ID, el nombre el apellido y el correo electrónico del usuario para insertarlos en MongoDB en la colección Usuarios, respondiendo con un JSON de que se ha gestionado correctamente. Para integrar Clerk en la aplicación, se han incorporado las dependencias necesarias y simplemente añadiendo los componentes ya es funcional. Figura 3.2: Visualización del panel Clerk 3.5.2. Front-end Vercel Se trata de una plataforma en la nube que permite alojar webs dinámicas. En Vercel24 hemos desplegado nuestra aplicación, que ofrece un link público (tfg-app-juans-projects-a71ef168. vercel.app), por lo que no necesitamos tener que pagar un dominio para desplegar la 23 tfg-app-juans-projects-a71ef168.vercel.app tfg-app-juans-projects-a71ef168.vercel.app aplicación. Además aunque está pensado para albergar aplicaciones Front-end, permite la interacción, por lo que nuestra aplicación funciona perfectamente en Vercel. Next.js Consiste en un framework de desarrollo web front-end de código abierto creado por Vercel, aprovechando el uso de los componentes de React. Next.js40 permite la renderización en el lado servidor y en el lado cliente, incrementando en gran medida la optimización y carga de las páginas. También incluye funcionalidades como las rutas dinámicas, en el cuál al definir una clase, se crea automáticamente una ruta de esta. React.js Es una biblioteca de JavaScript de código abierto desarrollada por Meta (antes Facebook) que es usada para construir interfaces de usuario interactivas y reutilizables mediante la creación de componentes. React16 utiliza una API tipo DOM (Document Object Model) que optimiza el rendimiento de las webs. Además mediante useState y las props se puede gestionar la comunicación entre componentes React. TailwindCSS Tailwind21 es un framework CSS de código abierto que permite crear interfaces con un aspecto moderno y personalizado. Es muy directo su aplicación, ya que al importar sus dependencias se puede utilizar en código HTML como clase, donde al pasarle distintos parámetros se pueden obtener resultados muy logrados. ChartJS Es una librería de JavaScript pensada para aplicaciones web que permite dibujar y configurar diversos tipos de gráficas mediante HTML5 CANVAS. El uso de ChartJS3 es re- lativamente sencillo pues se puede aplicar directamente sobre HTML tras haber configurado previamente las gráficas en un fichero. Lo hemos utilizado para poder mostrar estadísticas 24 del rendimiento de los pacientes en los juegos, tal que en la aplicación web, los médicos podrán observar en un panel estos parámetros de cada paciente que tengan asociado. 3.6. Arquitectura del sistema A continuación se describe la arquitectura implementada en el sistema, detallando tanto la arquitectura general del funcionamiento de este, como desglosando más detalladamen- te algunos de los procedimientos más técnicos, acompañados por diagramas que permitan entender mejor las implementaciones. 3.6.1. Arquitectura general del sistema A continuación se despliega un esquema que permite entender mejor la interacción entre los diversos componentes del sistema. Podemos observar como los juegos y la aplicación web comparten la misma base de datos. El juego accede a esta a través de la librería de Unity de Realm y también utiliza la librería Riptide para gestionar el servidor que permite conectarse a un dispositivo Android conectarse Figura 3.3: Arquitectura general del sistema 25 3.6.2. Arquitectura del módulo videojuegos Arquitectura del controlador del juego En el siguiente diagrama de secuencia se detalla la interacción del videojuego con el dispositivo Android que se utiliza a modo de controlador. A través de la librería Riptide de Unity, se levanta un servidor local HTTP, el cuál se inicializa y el juego recibe la dirección IP, mostrándolo por pantalla al comenzar el juego, y el usuario paciente deberá introducir la dirección IP, que al proporcionarla correctamente desde la aplicación del dispositivo Android, entonces la partida dará comienzo y el dispositivo captará el movimiento del ejercicio en cuestión, enviando estos datos a través del servidor. Figura 3.4: Arquitectura interacción juego con el controlador 26 Arquitectura del juego y la persistencia En este diagrama de secuencia se despliega la lógica detrás de la gestión de la persis- tencia con el videojuego, en este caso el de golf. Una vez en el menú principal del juego, se introduce el nombre del usuario para poder comenzar la partida, ya que se necesita ve- rificar las credenciales del usuario para poder de esta forma obtener la instancia de la base de datos.Entonces, MongoDB devuelve los datos necesarios para comenzar la partida, que consiste en el ángulo al que se debe realizar el movimiento para completar una repetición, el número de repeticiones y el número de series. Durante la partida, se irán leyendo los da- tos, como el ángulo del jugador según el tiempo en ese momento, y al terminar esta, Unity mandará una petición a Realm para almacenar los datos de esta sesión de juego en la base de datos y así la aplicación web podrá utilizarlos para las estadísticas. Figura 3.5: Arquitectura juego-persistencia 27 3.6.3. Arquitectura del módulo aplicación web Arquitectura de la aplicación y su persistencia La aplicación se comunica con la base de datos a través de los endpoint contenidos en el back-end. En general, se mandará una petición desde el cliente para conectarse al servidor de la base de datos, a través del cual se pueden obtener datos con consultas e insertarlos. En la figura 3.4 se detalla el diagrama de secuencia del alta de un nuevo cliente, el que una vez registrado en el sistema a través de Clerk, y enviado con el webhook a MongoDB los datos del usuario, se guardará en un documento en la colección Usuarios de MongoDB, y por tanto la aplicación mostrará un formulario, donde el usuario debe indicar si es un médico o un paciente, que al enviarlo lo validará y enviará los datos de la colección Usuario a Médico o Paciente. Arquitectura de la aplicación y Clerk En la figura 3.5, se observa en otro diagrama de secuencia el funcionamiento de Clerk. Clerk proporciona la funcionalidad total de gestión de usuarios y sesiones. En este caso, cuando el cliente accede a la aplicación, esta obtiene una instancia del componente de Clerk, devolviendo al usuario una interfaz para poder registrarse o iniciar sesión. Una vez proporcionados los datos de inicio de sesión, la aplicación mandará una petición a Clerk para validarlos, y por tanto la aplicación otorgará acceso al cliente. Si se vuelve a utilizar la aplicación, esta habrá almacenado la sesión del usuario, por lo que no tendrá que volver a iniciar sesión desde el mismo dispositivo o navegador. Hacer uso de Clerk ha supuesto una gran ventaja en cuanto a implementación de la gestión de usuarios y sesiones, pues implementarlo de forma nativa es complejo y requiere una gran inversión de tiempo, por lo que ha permitido ahorrar ese tiempo de desarrollo para poder emplearlo en otras tareas. 28 Figura 3.6: Alta cliente 29 Figura 3.7: Interacción aplicación-clerk 3.6.4. Modelo entidad-relación del sistema En el modelo del dominio (o entidad-relación, figura 3.6), es una representación del mo- delo de datos del sistema. En este caso, observamos la entidad Usuario, que es especializada ya que tiene los subtipos Médico y Paciente. Un médico puede tener asignados N pacientes y un paciente puede estar asignado a N médicos. Luego, un médico asigna N juegos a los pacientes, mientras que un paciente realiza N sesiones en los juegos. Finalmente una sesión de juego genera N datos en crudo que se almacenan para su posterior análisis 30 Figura 3.8: Modelo del dominio 31 Capítulo 4 Diseño y Metodología 4.1. Tipos de ejercicios En esta sección se detallan los tipos de ejercicios seleccionados para la integración en los videojuegos desarrollados. Los ejercicios elegidos se centran en la rehabilitación de hombro y del tobillo y pie, abordando áreas específicas de recuperación y ofreciendo movimientos adaptados para su implementación en los videojuegos. 4.1.1. Rehabilitación de hombro El ejercicio de rehabilitación de hombro se enfoca en mejorar la movilidad y fortale- cer los músculos del hombro. Los pacientes pueden realizar este ejercicio sentados o de pie, comenzando con los hombros relajados, y a continuación el paciente debe ir subiendo progre- sivamente el vertical ambos hombros, tan alto como sea posible. Una vez se ha completado el movimiento de subida, se debe comenzar la baja progresivamente hasta volver al punto inicial en el que los hombros se encuentran relajados. 32 Figura 4.1: Rehabilitación de hom- bro de pie Figura 4.2: Rehabilitación de hombro en silla18 4.1.2. Rehabilitación de tobillo y pie Este ejercicio se concentra en fortalecer y mejorar la movilidad del tobillo y del pie. Los pacientes pueden realizarlo tumbados, con el objetivo de simular la acción de presionar un acelerador. Deben colocar el pie de modo que la punta apunte hacia arriba y, usando el tobillo, realizar un movimiento hacia abajo, tratando de alcanzar el máximo recorrido posible. Figura 4.3: Rehabilitación de tobillo y pie19 4.2. Proceso de diseño de los videojuegos En este apartado hablaremos sobre el proceso de investigación, búsqueda de ideas y diseño de los distintos videojuegos que hemos desarrollado. 33 En los siguientes subapartados vamos a explicar el proceso que hemos seguido para llegar hasta las ideas y conceptos definitivos de los videojuegos. 4.2.1. Recolección de ideas y ejemplos de videojuegos El primer paso antes de empezar el proceso de diseño era hacer una búsqueda de obras ya existentes que pudiesen cumplir la meta con la que se iba a desarrollar el juego. Según nos comentó Carlos al comienzo del curso, estas debían tener unas características específicas, basadas en parte en la retroalimentación ofrecida por el equipo de fisioterapeutas sobre los resultados del proyecto anterior. Los requisitos eran los siguientes: El videojuego no debía suponer un reto para el jugador. Debía estar enfocado a personas que no tienen unas capacidades físicas y motoras recuperadas. El juego debía adaptarse a la situación del jugador, reaccionando al movimiento de rehabilitación. No debía penalizar al jugador en gran medida por no realizar el movimiento o hacerlo a destiempo. El juego debía ser sencillo y ligero en cuanto a recursos, para poder ser instalado en la mayoría de dispositivos actuales y no tan actuales del mercado. En conjunto con el requisito anterior, se propuso la idea de hacer los juegos multipla- taforma de manera que no estuviesen restringidos a un solo tipo de dispositivo. Con toda esta información recabada, el siguiente paso fue buscar ideas de videojuegos ya existentes con mecánicas y dinámicas adaptables a nuestro objetivo. Nos pusimos manos a la obra y llegamos a la conclusión de que los videojuegos debían ser minijuegos. Algunos de los mejores ejemplos que pudimos encontrar fueron juegos del estilo de Super Mario Party35 32. 34 Para implementar el sistema de sensorización, nos basamos en una manera de captar el input similar a la que utiliza Nintendo con su mando de Wii34 o los JoyCon de la Switch33. Por ello, buscamos información acerca de juegos que pudiesen aprovechar esta forma de leer la entrada. Ejemplos como Wii Sports38, Wii Party37 o Switch Sports? rápidamente se nos vinieron a la mente. Con todos estos aspectos presentes, ya pudimos pasar al proceso de diseñar los juegos. 4.2.2. Diseño de los videojuegos El proceso de diseño consistió en pensar que mecánicas y que dinámicas querríamos en nuestros juegos, como se desarrollaría la partida y el flujo que se tendría que seguir para completar de manera satisfactoria una sesión completa de rehabilitación. Mediante la conocida lluvia de ideas propusimos varias opciones y temáticas que querríamos en nuestros juegos y poniendo todo en común elegimos las que mejor opción nos parecieron. De estas ideas iniciales se desarrollaron unos prototipos en papel definiendo como fun- cionaría el estado del juego y los distintos elementos que estarían contenidos en las escenas, dando tanto retroalimentación al usuario, como elementos visuales y cómo se recibiría la entrada del usuario y las consecuencias que esta entrada provocaría en la partida. También definimos las mecánicas de cada uno de los juegos y el objetivo final de éstos. Inicialmente partimos con dos prototipos de videojuego, uno consistía en un minijuego de golf donde el jugador debería golpear pelotas que irían apareciendo para introducirlas en el hoyo y evitar golpear bombas que eventualmente irán apareciendo en lugar de estas pelotas. El segundo prototipo se basó en un coche que debería acelerar sobre una rampa para después realizar un salto al final de esta rampa, el coche cuánto más velocidad punta alcan- zase más lejos llegaría con ese salto, durante el descenso habría obstáculos entorpeciendo al jugador. Este segundo prototipo no terminó de cuadrarnos ya que no tenía ese aspecto de jugabi- 35 lidad y entretenimiento que se busca con un videojuego y resultaba algo lineal y repetitivo. Así que se terminó por sustituir por un videojuego de saltos, donde el jugador debería ir subiendo por plataformas y evitando que aparezcan pinchos sobre ellas si tarda demasiado en realizar el salto. Este prototipo si que se adaptaba mejor a los objetivos especificados y además la acción del jugador no repercutiría tanto como en el otro prototipo por, lo que el paciente puede preocuparse en realizar bien el objetivo en lugar de hacerlo apresuradamente. Una vez definido el prototipo en papel se pasó al diseño de mecánicas explicado en una sección más adelante en este capítulo. 4.2.3. Estética común Para que nuestros videojuegos tuviesen cierta integridad se buscó una estética común que no difiriese de un juego a otro. Nuestra idea fue una estética más enfocada al pixel art simulando minijuegos retro. Más adelante en la sección 4.4 en este mismo capítulo se expondrá con más detalle el proceso de búsqueda y de desarrollo artístico que hemos desempeñado para alcanzar la estética y el aspecto visual que buscábamos. 4.3. Diseño de jugabilidad y mecánicas El proceso inicial en el desarrollo de los videojuegos implicó la creación de prototipos simples para implementar y evaluar las mecánicas propuestas en la fase de diseño. Durante esta etapa, los juegos carecían de elementos artísticos y todos los objetos se representaban mediante imágenes básicas actuando de placeholders. Dado que en esta fase aún no se había implementado el sistema final de captación de datos o sensor de movimiento, se utilizó un sistema provisional basado en el teclado para probar las mecánicas implementadas. Este enfoque temporal fue posteriormente reemplazado por el desarrollo del sistema de captación de movimiento. El prototipo simple permitió realizar pruebas rápidas para verificar el funcionamiento de las mecánicas y la dinámica del juego. Esta fase de pruebas facilitó la identificación de 36 posibles mejoras y ajustes en el diseño original de manera ágil y sencilla, contribuyendo así a la iteración y refinamiento del concepto de juego. Con esta forma de rápido prototipado nos pudimos dar cuenta de qué mecánicas eran buenas y cuáles no cumplían con el objetivo propuesto y poder rediseñar juegos con relativa simplicidad sin necesidad de empezar el proceso desde el principio. 4.4. Desarrollo artístico Como se ha nombrado anteriormente, hemos apostado por una estética pixel art en dos dimensiones, o también de estilo retro, pues hoy en día muchos juegos indie y otros de menor escala utilizan este estilo artístico. Esto se debe a que diseñar sprites o animaciones en este estilo resulta muy sencillo, pues se puede ir pixel a pixel determinando un color, que al plasmarlos forman una imagen. De la misma forma, al mostrar diversos frames cada uno con un sprite, se pueden crear también sencillamente animaciones, que le otorgan a los juegos de un gran atractivo visual y una sensación de dinamismo, proporcionando al usuario un feedback visual de sus acciones. La estética de nuestros juegos se inspira en la época de principios de los 90, es decir la era de los 16 bits39, en la cuál se dio un gran salto de calidad visual respecto a la era de los 8 bits, pues se permitía una mayor definición y acabados mucho más estéticos, permitiendo a los videojuegos evolucionar a una mayor complejidad sobre todo en géneros como los RPG, y en esta época se crearon algunos de los grandes clásicos que impulsaron a la industria a estándares nunca antes vistos y acercando los videojuegos al público general como sucedía en otras industrias como el cine o la animación. Por tanto, nos hemos inspirado en el estilo artístico de algunos de los juegos de aquella época, además de en otros títulos actuales que también emplean esa estética. El proceso de diseño artístico del escenario se ha realizado en el tile map que proporciona Unity, en el cual se pueden seleccionas tiles (conjuntos de píxeles que forman una imagen) para que, colocándolos debidamente, se puedan construir formas, mientras que el diseño artístico de elementos como el personaje principal del golf u otras texturas se han diseñado en Piskel, 37 donde pixel a pixel y mediante el uso de capas se han construido estos elementos. También se han obtenido otras texturas y diseños en itch.io9, que es una plataforma en la cual hay una gran comunidad de desarrolladores indie donde publican sus juegos o assets para crearlos, y gran parte de ellos son gratuitos. Los artistas de los cuáles se han obtenido algunos de los recursos están debidamente citados en el apartado de bibliografía. Figura 4.4: Uso de piskel para la creación de sprites 4.5. Música y Efectos de sonido En el desarrollo de los videojuegos, la música y los efectos de sonido desempeñan un papel fundamental en la creación de una experiencia inmersiva y atractiva para el jugador. Para obtener recursos de audio de alta calidad, se utilizó la plataforma web de Freesound6, que ofrece una amplia variedad de pistas musicales y efectos de sonido bajo licencias libres. La selección de música para los juegos y el menú principal se realizó cuidadosamente, buscando piezas que se adaptaran al tono y la atmósfera de cada juego. Se optó por pistas que no solo completaran la jugabilidad, sino que también generarán una sensación de cohesión y fluidez en la experiencia general del usuario. Además, se incorporaron efectos de sonido para realzar la interactividad y la inmersión 38 en el juego. Por ejemplo, se utilizó el sonido de un click para representar la interacción del jugador con los botones de los videojuegos, el sonido de un salto para indicar los movimientos del personaje en el JumpingMiniGame, y efectos de sonido específicos para eventos como el game-over en ambos juegos o el golpeo de la pelota y la explosión de una bomba en el GolfinMiniGame. Para completar la selección de música y efectos de sonido, se utilizó la aplicación Au- dacity1. Esta herramienta permitió perfeccionar el audio mediante la edición de la calidad del sonido y la duración de las pistas, asegurando que se integraran perfectamente con la dinámica y el ritmo de los videojuegos. La combinación de Freesound y Audacity facilitó el proceso de producción de audio, permitiendo ajustes precisos para lograr una experiencia auditiva cohesiva y envolvente para los jugadores. 39 Capítulo 5 Implementación Para este proyecto, hemos diseñados dos videojuegos simples destinados a abordar dos modalidades distintas de rehabilitación previamente mencionadas, junto con una estructura web complementaria. 5.1. Elementos Unificados en todos los juegos En nuestros dos juegos, hemos implementado una serie de funciones comunes de manera consistente, adaptándolas ligeramente para satisfacer las necesidades de cada uno. 5.1.1. Menú principal Cada uno de los juegos incorporará una escena en Unity con el punto de partida inicial del juego al iniciarse, conocido como el menú principal. Desde este punto, los usuarios tendrán acceso a diferentes secciones, como opciones e instrucciones, además de la capacidad de iniciar el juego propiamente dicho. 40 Figura 5.1: Menú principal GolfingMiniGame Figura 5.2: Menú principal JumpingMiniGame 41 5.1.2. Menú de pausa Durante el transcurso del juego, al activar la función de pausa, se desplegará un panel que ofrecerá tres opciones distintas: reanudar la partida desde el punto en el que se detuvo, acceder al menú de opciones o regresar al menú principal. Figura 5.3: Menú pausa GolfingMiniGame Figura 5.4: Menú pausa JumpingMiniGame 5.1.3. Menú de opciones El menú de opciones proporciona una variedad de configuraciones personalizables para mejorar la experiencia del usuario. Presenta dos controles deslizantes para ajustar el vo- 42 lumen y el brillo de la pantalla, permitiendo a cada usuario adaptar las configuraciones según sus preferencias individuales. Además, incluye un menú desplegable para seleccionar la resolución de la pantalla, ofreciendo varias opciones para elegir. Este menú se encuentra disponible tanto en el menú principal como en el menú de pausa de ambos juegos. Un botón de retorno permite al usuario regresar a la pantalla anterior, ya sea el menú principal o el menú de pausa. Figura 5.5: Menú de opciones 5.1.4. Menú de instrucciones Cada juego presenta un área específica destinada a proporcionar instrucciones detalladas para los pacientes. Esta sección explica de manera clara y concisa el ejercicio asociado al juego. Además, se incluye una breve explicación sobre la colocación adecuada del dispositivo de captación de movimiento en el paciente para garantizar una recopilación precisa de datos. Este menú es accesible a través del menú principal de cada juego. 43 Figura 5.6: Panel de información GolfingMiniGame Figura 5.7: Panel de información JumpingMiniGame 44 5.1.5. Captura de movimiento En cada juego, el movimiento del paciente se convierte en la entrada principal para interactuar con el juego. A medida que el paciente realiza los ejercicios, el juego responde a sus movimientos, proporcionando retroalimentación en tiempo real. Este sistema de entrada se ha diseñado de manera que a través de un servidor UDP local se comunica el dispositivo de captura de movimiento con el juego que se esté ejecutando enviando la información requerida por el juego para determinar el movimiento del jugador. Sumergiéndonos un poco más en el funcionamiento, se desarrolló una aplicación destinada a dispositvos Android que será la encargada de recabar la información de los movimientos del usuario haciendo uso de los sensores del dispositivo. Tanto el dispositivo móvil como la plataforma en la que se esté ejecutando el juego deben estar en la misma red local para poder establecer la conexión, esta conexión se realiza introduciendo en la aplicación Android la IP del dispositivo que ejecute el juego la cual aparecerá en la pantalla antes de iniciar la partida. Una vez establecida la conexión el servidor arrancará y comenzará el envío de los datos del movimiento. Este sistema ha podido ser desarrollado gracias al uso del plugin de Riptide41, un plugin desarrollado para Unity y con licencia gratuita para fines educativos. El plugin es el encar- gado de gestionar la conexión entre el cliente y el servidor y del envío y recibo de paquetes, además ofrece funciones cuyo contenido se desencadene con la conexión o desconexión de un cliente, etcétera. En definitiva, es un plugin que nos ha resultado de gran utilidad para desarrollar este sistema de captura de movimiento usando dispositivos a los que la mayoría de usuarios tienen acceso. 5.1.6. Configuración de los parámetros La configuración de los parámetros del juego se realiza a través de la base de datos. El fisioterapeuta podrá personalizar tablas de ejercicios con un número de series y repeticiones a alcanzar y el ángulo objetivo al que debería llegar el paciente, estos se almacenarán en 45 un documento de la base de datos que luego se encargará el juego de leer y devolver la información necesaria para iniciar una partida. Por otro lado los pacientes podrán acceder con su usuario en el juego que corresponda y automáticamente se aplicará la configuración que se haya designado para esa sesión, se establecerá una conexión con la base de datos y si todo está debidamente cumplimentado se iniciará una partida con los datos obtenidos de la consulta a la base de datos. Al tener lo datos almacenados en una base externa al juego, no es necesario para el fisioterapeuta acceder al juego y configurar el juego de cada paciente antes de una sesión. Simplemente desde la aplicación se crea la sesión de rehabilitación con los parámetros que sean necesarios y se asigna esa sesión a un paciente. De esta manera se añade comodidad a los usuarios y se asegura que los datos de confi- guración se mantienen íntegros en la base de datos en lugar de en una localización local en el dispositivo de cada paciente. 5.1.7. Registro de datos de movimiento El registro de movimientos funciona de una manera inversa a la configuración de los parámetros en cuánto a la comunicación con la base de datos, es decir, en esta ocasión el encargado de enviar la información a la base de datos es el juego. Hay varias formas de registrar el progreso del paciente como puede ser el rendimiento de éste en el juego ya sea a través de la puntuación total alcanzada, o el tiempo total de la sesión, los objetivos completados, etcétera. Estos datos son distintos en cada juego y no ofrecen un progreso en específico, aunque si que ofrecen información y es bueno almacenarlo. Pero si que existe una manera en la que ver reflejada la actividad del jugador de forma más efectiva y esa es la evolución del ángulo de movimiento del jugador durante toda la partida. Este dato se recoge cada poco tiempo, enviando a la base de datos una marca de tiempo y el ángulo que tiene el paciente en ese instante de tiempo, de esta manera será posible construir gráficas para ver de una forma mucho más visual como evoluciona cada 46 paciente. La base de datos recibe esta información enviada desde el juego y se almacena en el documento al que se accedió para aplicar la configuración inicial de la partida. De esta ma- nera una vez se reciba esta información el médico asignado podrá comprobar los resultados del paciente en la propia plataforma web una vez se vayan completando las sesiones. Así el fisioterapeuta podrá hacer un análisis más profundo y comprobar el éxito de la sesión de rehabilitación. 5.1.8. Diseño de una API escalable a futuro La comunicación con la base de datos en cada uno de los juegos se ha realizado mediante el uso del SDK de Realm que proporciona MongoDB para C#, gracias a este SDK se ha podido desarrollar una clase común que se encarga de establecer la conexión con la base de datos, enviar los datos que sean necesarios y hacer consultas para recibir la configuración que se solicite. En caso de ampliar el proyecto en un futuro con la implementación de más videojuegos, se debe importar un paquete de Unity con la clase necesaria para realizar estas transacciones con la base de datos, además de una clase ejemplo y una documentación incluidas para resolver posibles dudas 5.2. Juego 1: GolfingMiniGame 5.2.1. Concepto del juego Este juego está pensado para la rehabilitación de hombros, facilitando en la medida de lo posible la pausa necesaria para realizar este movimiento. El objetivo consiste en golpear las pelotas de golf que van apareciendo en pantalla y obtener la mayor puntuación posible. La mecánica del juego es simple pero efectiva: en una zona de respawn, aparecerán al- ternativamente pelotas de golf y bombas. Cuando el paciente realiza un movimiento de levantamiento del hombro hasta un ángulo específico, determinado por los parámetros es- tablecidos por el fisioterapeuta o médico, el juego activa el golpeo de la pelota o bomba, 47 dependiendo de qué objeto esté presente en ese momento. Cada vez que el paciente golpea con éxito una pelota de golf, se suman puntos a su marcador y se genera una nueva pelota o bomba en la zona de respawn. Sin embargo, golpear una bomba antes de que pase un tiempo determinado restará puntos a la puntuación del jugador y hará que la bomba estalle. La dinámica del juego está diseñada para motivar al paciente a realizar los movimientos terapéuticos de manera correcta y constante, mientras se divierte y se esfuerza por obtener la puntuación más alta posible. El objetivo es que la mejora del paciente sea progresiva, a me- dida que va aumentando el número de sesiones completadas, incrementando las estadísticas para observar una evolución. Figura 5.8: Captura Golfing Minigame 5.2.2. Desarrollo y clases En la creación de este juego, hemos elaborado una serie de Scripts que se vinculan con los GameObjects de nuestras escenas de Unity. A continuación, se describe la función de cada uno de ellos y cómo contribuyen a la experiencia de juego. GameData: Se encarga de almacenar los datos del jugador. Se definen dos clases PlayerData que representa los datos del jugador en el juego como el ID, nombre, 48 ángulo, tiempo de juego, número total de golpes a pelotas, número total de golpes a las bombas, número de repeticiones, la puntuación total y el número total de series. Y RawInputData representa los datos brutos de entrada del jugador incluido el ID, ángulo y la marca de tiempo de cuando se registraron estos datos. RealmController: Maneja la conexión con una base de datos Realm y administra los datos del jugador en un juego. Se encarga de autenticar al usuario, recuperar y actualizar información como el ángulo, las series, las repeticiones, los golpes de pelotas y bombas, la puntuación y el tiempo de juego. Además, proporciona métodos para limpiar y agregar datos de entrada del jugador. BallAnimation: Controla el comportamiento de la animación de la pelota de golf en el juego. Activa o desactiva la animación de la pelota en función de los eventos del juego. BallBehaviour: Controla el comportamiento de la pelota de golf. Cuando la bola es golpeada, activa su animación, suma puntos a la puntuación total del jugador, actualiza la interfaz de usuario para mostrar si se ha tenido éxito o fracaso en el golpe, y registra el golpeo en el GameManager. BombBehaviour: Controla el comportamiento de la bomba en el juego. Activa la animación asociada a la bomba y maneja el tiempo en que la bomba desaparece después de un cierto período de tiempo. MessageExtensions: Proporciona métodos de extensión para la clase Message, que facilitan la adición y recuperación de datos de tipo Vector2, Vector3, Quaternion desde un mensaje. Estos métodos simplifican el proceso de manejo de estos tipos de datos al encapsular la lógica de conversión y almacenamiento de datos dentro del propio script. NetworkManager: Se encarga de administrar la conectividad de red del juego. Es- tablece y mantiene la comunicación entre el servidor y los clientes. 49 InputManager: Gestiona la entrada del usuario relacionada con el movimiento del jugador en el juego. Controla la detección para iniciar el movimiento, calcula la inclina- ción del dispositivo utilizando los datos del acelerómetro, guarda los datos de entrada del usuario, actualiza la interfaz de usuario para reflejar el progreso del movimiento y maneja el estado de la animación del jugador. Además, coordina el inicio y reinicio del movimiento del jugador según sea necesario. CodigoVolumen: Controla el volumen del audio en el juego y permite al usuario ajustarlo mediante un slider. ControllerOptions: Controla las opciones del juego. Almacena una referencia al objeto de panel de opciones para controlar aspectos relacionados con las opciones del controlador del juego. LogicaBrillo: Controla el brillo de la pantalla en el juego y permite al usuario ajus- tarlo mediante un slider. LogicaEntreEscenas: Garantiza que el panel de opciones persista entre transiciones de escena y que solo exista una instancia activa de este objeto en cualquier momento. LogicaOpciones: Es la lógica de la interfaz del usuario, permitiendo que otras partes del juego, como los botones de pausa, puedan mostrar el panel de opciones del juego. LogicaFullScreen: Gestiona la configuración de la resolución de pantalla en el juego. Al iniciarlo, revisa las configuraciones disponibles del sistema y las muestra en un menú desplegable. También permite al usuario cambiar la resolución seleccionando una opción del menú. Player: Controla la animación del jugador en el juego. Se asegura de que la animación se active o desactive según el estado del juego y las acciones de este. 50 PlayerMovement: Maneja las acciones que ocurren al entrar en un estado específico de animación del jugador, como establecer parámetros de animación e iniciar otras acciones relacionadas con la interacción con otros elementos del juego, como golpear una pelota. BallBombSpawner: Se encarga de generar pelotas y bombas en el juego de forma aleatoria. Invoca un método para generar una instancia del objeto (ya sea una pelota o una bomba) en función de una probabilidad predefinida. EndGamePanel: Maneja el panel de fin de juego en el juego. PreparationCountdownTimer: Gestiona un temporizador de cuenta regresiva uti- lizado para preparar el comienzo de una ronda en el juego. UIManager: Administra todos los elementos visuales y de interfaz de usuario en el juego, actualizando y mostrando información relevante al jugador mientras juega. GameManager: Actúa como núcleo del sistema del juego, coordinando diferentes aspectos del juego y facilitando la comunicación entre diferentes sistemas y compo- nentes. MainMenu: Gestiona la navegación del usuario en el menú principal, verifica las credenciales del usuario y carga la escena del juego cuando se inicia. MenuPausa: Controla la funcionalidad del menú de pausa en el juego. Cuando el jugador pulse sobre el icono de pausa, este script muestra un cuadro de pausa en la pantalla y detiene el tiempo de juego. También permite al jugador continuar desde el punto de pausa o salir del juego para regresar al menú principal. 51 5.3. Juego 2: JumpingMiniGame 5.3.1. Concepto del juego En este caso, el juego está enfocado para la rehabilitación del tobillo, ayudando al pacien- te a realizar el ejercicio de manera controlada y pausada. El objetivo consiste en completar el número de saltos asignado para completar la seria en el menor tiempo posible. La mecánica del juego consiste en que por cada repetición completada, el personaje saltará a la siguiente plataforma situada en la parte superior, aumentando la puntuación del paciente. Por otro lado, si se tarda demasiado en realizar el siguiente salto, se activará una trampa de pinchos que restará puntuación, aunque sí se podrá continuar con la sesión para no penalizar al jugador, ya que se busca la recompensa de completar todas las repeticiones. Para completar el movimiento, el paciente debe realizar un movimiento similar al que se produce en los pedales de un coche, pues en la posición inicial la punta del pie debe estar inclinada ligeramente hacia arriba, con el talón apoyado en el suelo, y se debe ir bajando la punta del pie hacia el suelo hasta el ángulo especificado por el fisioterapeuta. La dinámica del juego ha sido diseñada para incentivar al paciente a realizar el ejercicio de forma precisa y pausada, tratando de reforzar el movimiento de los tobillos y con el tiempo fortalecer estas articulaciones. 5.3.2. Desarrollo y clases En la creación de este juego, hemos elaborado una serie de Scripts que se vinculan con los GameObjects de nuestras escenas de Unity. A continuación, detallaremos la función de cada uno de ellos y cómo contribuyen a la experiencia de juego. GameData: Se encarga de almacenar los datos del jugador. Se definen dos clases PlayerData que representa los datos del jugador en el juego como el ID, nombre, ángulo, tiempo de juego, número total de plataformas en la que se ha activado la trampa de pinchos, número total de saltos sin trampa, número de repeticiones, la 52 puntuación total y el número total de series. Y RawInputData representa los datos en bruto de entrada del jugador, donde se incluyen el ID, el ángulo por cada marca de tiempo y la marca de tiempo de cuando se registraron estos datos. RealmController: Maneja la conexión con una base de datos Realm que establecerá la conexión con MongoDB y administra los datos del jugador en el juego. Se encarga del registro del usuario, recuperar y actualizar datos del usuario, el número de series, el número de repeticiones, el número de saltos en los que la trampa de pinchos estaba activo, el número de saltos en plataformas sin trampa activa, la puntuación y el tiempo de juego. Además, proporciona métodos para limpiar y agregar datos de entrada del jugador. MessageExtensions: Proporciona métodos de extensión para la clase Message, que facilitan el añadido y la recuperación de datos de tipo Vector2, Vector3, Quaternion desde un mensaje. Estos métodos simplifican el proceso de manejo de estos tipos de datos al encapsular la lógica de conversión y almacenamiento de datos dentro del propio script. NetworkManager: Se encarga de administrar la conectividad de red del juego. Es- tablece y mantiene la comunicación entre el servidor y el cliente. InputManager: Gestiona la entrada del usuario relacionada con el movimiento del jugador en el juego. Controla la detección para iniciar el movimiento, calcula la inclina- ción del dispositivo utilizando los datos del acelerómetro, guarda los datos de entrada del usuario, actualiza la interfaz de usuario para reflejar el progreso del movimiento y maneja el estado de la animación del jugador. Además, coordina el inicio y el reinicio del movimiento del jugador según sea necesario. SoundLogic: Controla el volumen del audio en el juego y permite al usuario ajustarlo mediante un slider. 53 ControllerOptions: : Controla las opciones del juego. Almacena una referencia al objeto de panel de opciones para controlar aspectos relacionados con las opciones del controlador del juego. BrightnessLogic: Controla el brillo de la pantalla en el juego y permite al usuario ajustarlo mediante un slider. LogicBetweenScenes: Garantiza que el panel de opciones persista entre transiciones de escena y que solo exista una instancia activa de este objeto en cualquier momento. ResolutionLogic: Gestiona la configuración de la resolución de pantalla en el juego. Al iniciar, revisa las configuraciones disponibles del sistema y las muestra en un me- nú desplegable. También permite al usuario cambiar la resolución seleccionando una opción del menú. GameManagerOptionsGame: Es la lógica de la interfaz del usuario, permitiendo que otras partes del juego, como los botones de pausa, puedan mostrar el panel de opciones del juego. PreparationCountdownTimer: Gestiona un temporizador de cuenta regresiva uti- lizado para preparar el comienzo de una ronda en el juego. UIManager: Administra todos los elementos visuales y de interfaz de usuario en el juego, actualizando y mostrando información relevante al jugador mientras juega. EndGamePanel: Maneja el panel de fin de juego en el juego. GameManager: Actúa como núcleo del sistema del juego, coordinando diferentes aspectos del juego y facilitando la comunicación entre diferentes sistemas y compo- nentes. GameManagerMenu: Gestiona la navegación del usuario en el menú principal, ve- rifica las credenciales del usuario y carga la escena del juego cuando se inicia. 54 PauseManager: Controla la funcionalidad del menú de pausa en el juego. Cuando el jugador pulse sobre el icono de pausa, este script muestra el menú de pausa y detiene el juego. También permite al jugador continuar desde el punto de pausa o salir del juego para regresar al menú principal. PlatformGenerator: Se encarga de generar las plataformas y las trampas de pinchos en el juego. Player: gestiona el movimiento del jugador, específicamente los saltos entre platafor- mas. Controla los puntos obtenidos al saltar, activa/desactiva los pinchos y manejas los efectos de sonido asociados. También maneja el estado del jugador durante el juego. SpikeController: Controla el comportamiento de las trampas de pinchos en el juego. Proporciona un control centralizado para activar y desactivar las trampas. 5.4. Aplicación móvil La aplicación móvil se encarga del envío de los datos de los sensores del teléfono, en este caso el acelerómetro, a través de la conexión con el juego, establecida en un servidor UDP por medio del plugin Riptide. Esta aplicación es muy sencilla ya que únicamente se encarga de establecer la conexión y una vez se ha confirmado esa conexión, comenzará en el envío de los datos a través de ella. Cuando la conexión se pierde el envío acaba y se vuelve a solicitar la introducción de una IP para establecer la conexión de nuevo. Se ha desarrollado con una estética similar a los videojuegos para que haya coherencia a nivel de la interfaz de usuario entre ellos. 5.4.1. Desarrollo y clases La aplicación consta de un campo de texto para introducir la IP que aparece en el juego y un botón para confirmar la conexión. Y una serie de clases asociadas a estos objetos que 55 Figura 5.9: Aplicación controlador dispositivo móvil definen el comportamiento: NetworkManager: Es la encargada de establecer una conexión al contrario que los juegos esta vez es por parte del cliente. Busca un servidor que tenga la dirección IP proporcionada y se establece la conexión MessageSender: Es la clase encargada de enviar mensajes hacia el servidor. Primera- mente obtiene los datos de los sensores del teléfono y después manda esa información en forma de Vector3 para que el servidor lo reciba. UIManager: Encargado de la interfaz de usuario, simplemente activa y desactiva la interfaz en función de si hay una conexión establecida. Si no hay una conexión con el servidor se permite al usuario introducir datos para establecer una, en caso contrario se desactivan el campo de texto y el botón para evitar alterar la información por error y perder la conexión en mitad de una partida. 56 5.5. Aplicación web La aplicación web consiste en una plataforma en la cuál los fisioterapeutas pueden realizar un seguimiento de los pacientes y su desempeño en las sesiones de juego, y donde los pacientes pueden comprobar las tablas de ejercicios que tienen asignadas para poder cumplir los requerimientos de los sanitarios a la hora de realizar la rehabilitación. Hay dos tipos de usuarios, médicos y pacientes, cada uno con diversos casos de uso. Un médico podrá: Registrarse: Al utilizar por primera vez la aplicación. Iniciar sesión: Para validar sus credenciales y establecer una sesión. Ver lista de pacientes asignados: Para poder observar el panel de estadísticas del paciente seleccionado. Ver panel de estadísticas por paciente: Mostrará gráficas y estadísticas del pa- ciente y su desempeño en las sesiones de juego. Asignar tablas de ejercicios a los pacientes: Permitirá mediante un formulario asignar tablas de ejercicios que los pacientes deberán completar. Ver lista completa de pacientes en el sistema: Despliega una lista con todos los pacientes en el sistema para poder seleccionar uno. Asignarse un paciente: Al seleccionar uno de los pacientes listados, quedará asig- nado al médico. Mientras que un paciente podrá: Registrarse: Al utilizar por primera vez la aplicación. Iniciar sesión: Para validar sus credenciales y establecer una sesión. Ver tabla de ejercicios asignada: Para entender que sesión deben realizar a conti- nuación, y una vez completada, la tabla ya no se mostrará como pendiente. 57 Ver las estadísticas propias del paciente: Muestra el panel de estadísticas del desempeño propio del paciente en las sesiones de juego. 5.5.1. Desarrollo y clases En el desarrollo de nuestra aplicación web, hemos creado un conjunto de scripts que se asocian con los elementos de la interfaz y la lógica de la aplicación. A continuación, descri- biremos la función de cada uno de los scripts y cómo contribuyen a mejorar la experiencia del usuario en la aplicación. _app.tsx: Es el punto de entrada principal de la aplicación. Se importan los estilos globales y se define el componente de la aplicación. _document.tsx: Personaliza el marcado HTML que se genera en el servidor. crear_tablas: Representa un formulario para que el médico cree nuevas tablas de ejercicios para sus pacientes. La página incluye campos para ingresar el ángulo del ejercicio, el nombre del ejercicio, el paciente al que se asignará la tabla de ejercicios, el total de series y el total de repeticiones. dashboard_medico.tsx: Representa el panel de control del médico en la aplicación web. dashboard_paciente.tsx: Representa el panel de control del paciente en la aplica- ción web. global_pacientes.tsx: Representa una página web que muestra el listado global de los pacientes. La página obtiene los datos de los pacientes mediante una llamada a la API, que a su vez interactúa con una base de datos de MongoDB.Los pacientes se muestran en una lista con sus datos y un botón para que los médicos puedan asignar un paciente a su lista personal. 58 index.tsx: Esta clase muestra un formulario para que los pacientes puedan seleccionar su tipo de usuario (médico o paciente) y proporcionar su correo electrónico. Una vez que se envíe el formulario, los datos se envían a una API que los inserta en la base de datos. lista_pacientes.tsx: Esta clase muestra la lista de pacientes asignados a un médico. Cada paciente se representa con su nombre, apellido y correo electrónico, y se propor- ciona un botón para que el médico pueda consultar las estadísticas específicas de cada paciente. asignar_paciente.ts: Define un controlador que maneja las solicitudes POST para asignar un paciente a un médico en la base de datos. connection.ts: Define un controlador que establece una conexión con la base de datos de MongoDB. insert_tabla.ts: Define un controlador que maneja solicitudes POST para insertar una nueva entrada en la colección de MongoDB. insertUser.ts: Define un controlador que maneja solicitudes POST para insertar usuarios en la base de datos. leerAsignados.ts: Define un controlador que maneja solicitudes POST para obtener los pacientes asignados a un médico en particular en la base de datos. leer_datosCrudo.ts: Define un controlador que maneja solicitudes POST para ob- tener los datos en curod de una sesión de juego almacenados en la base de datos. leer_juegos.ts: Define un controlador que maneja solicitudes POST para leer los datos de los juegos en la base de datos. leer_pacientes.ts: Define un controlador que maneja solicitudes POST para obtener el listado de pacientes de la base de datos. 59 siderbar_medico.tsx: Crea el menú lateral de navegación para la interfaz de usuario de un médico en la plataforma sanitaria. siderbar_paciente.tsx: Crea el menú lateral de navegación para la interfaz de usua- rio de un paciente en la plataforma sanitaria. golf_angle_chart_component.tsx: Representa un gráfico de líneas de la progre- sión del ángulo en función del tiempo para el juego GolfingMiniGame. golpes_chart_component.tsx: Representa un gráfico de barras que compara el número de golpes totales de pelotas y bombas en GolfingMiniGame. jump_angle_chart_component.tsx: Representa un gráfico de líneas de la pro- gresión del ángulo en función del tiempo para el juego JumpingMiniGame. puntos_chart_component.tsx: Representa un gráfico de líneas de la puntuación total de cada sesión de juego en GolfingMiniGame en función de la fecha. puntos_chart_jump_component.tsx: Representa un gráfico de líneas de la pun- tuación total de cada sesión de juego en JumpingMiniGame en función de la fecha. repeticiones_jump_chart_component.tsx: Representa un gráfico de líneas que representa el número total de repeticiones de cada sesión para el juego JumpingMini- Game en función de la fecha. middleware.ts: Es el fichero de configuración de Clerk. 60 Capítulo 6 Resultados En este capítulo se expondrán los resultados obtenidos del desarrollo de nuestro sistema. 6.1. Resultados generales Como resultado general consideramos que nuestro desarrollo cumple con las expectativas propuestas y se ha conseguido una implementación competente y escalable a futuro. Con el objetivo de centralizar el proceso de configuración de los juegos además de tener un lugar donde visualizar datos y resultados de cada uno de los pacientes, se ha conseguido montar una aplicación web que permite el alta usuarios y realiza consultas a una base de datos en MongoDB tanto para actualizar datos cómo crear nuevas entradas. Por otro lado se han desarrollado dos juegos que adicionalmente también están conectados con esa base de datos, para publicar o consultar la información que haga falta. 6.2. Resultados de los videojuegos Los videojuegos cumplen el objetivo propuesto son totalmente personalizables, sencillos de instalar en distintas plataformas (Windows y Android), y que además no necesitan un extra de configuración más allá de la instalación en la plataforma que se requiera. Además cuentan con un sistema de sensorización a través de la aplicación de móvil que también se adapta al requisito de fácil instalación y uso. 61 Los videojuegos están totalmente conectados con la aplicación web a través de la base de datos, haciendo uso de consultas son capaces de auto configurar una partida en función del nombre de usuario que se introduzca antes de iniciar la partida y al finalizar la sesión se sincronizan los resultados obtenidos en esta con la base de datos. Figura 6.1: Configuración obtenida de base de datos Figura 6.2: Nombre de usuario incorrecto Por otro lado se ha hecho hincapié en el sistema de entrada de los juegos y se ha diseñado de manera que sea intuitivo para el usuario y que sepa la acción que realiza en todo instante, esto es posible mediante el indicador de progreso del movimiento que se muestra por pantalla acompañado de las indicaciones visuales como se aprecia en la figura 6.3. A esta entrada además se le añade un buen sistema de visualización del trabajo restante que en conjunto permite al usuario saber en qué punto de la sesión se encuentra. (Figura 6.4). 62 Figura 6.3: Retroalimentación movimiento del usuario Figura 6.4: Retroalimentación progreso de la sesión Estos juegos no solo hacen las sesiones más atractivas para los pacientes, sino que también permiten una monitorización detallada del progreso de cada sesión. Los datos de cada sesión se envían automáticamente a la base de datos para posteriormente mostrarlos en la aplicación web y por parte de los fisioterapeutas pode realizar un análisis más detallado de la evolución de cada paciente. 6.3. Resultados de la aplicación web La aplicación web desarrollada para este proyecto permite a los fisioterapeutas y médicos monitorizar el progreso de los pacientes y su desempeño durante las sesiones de juego, mientras que los pacientes pueden acceder a las tablas de ejercicios asignadas y verificar los requisitos de los profesionales sanitarios para realizar una rehabilitación adecuada. Cabe resaltar que para poder obtener un acceso completo a la aplicación, se debe solicitar permiso, pues está protegido por un API KEY de MongoDB para ocultar la base de datos y que de esta manera cualquier tercero o usuario no autorizado pueda modificarla o destruirla. Si se 63 tiene acceso al entorno de la aplicación, pero las funcionalidades no estarán activas al no tener un usuario validado por Clerk y MongoDB. En caso de querer probar correctamente la aplicación se debe contactar con alguno de los autores y se concederá el acceso y los permisos pertinentes. A través de esta aplicación, los médicos pueden interactuar con los pacientes, para lo cuál deberán registrarse como médicos en el formulario que se muestra una vez se ha iniciado sesión a través de Clerk. Figura 6.5: Formulario de inicio Una vez el médico acceda a la aplicación tras completar el formulario, podrá observar los diversos casos de uso en el menú lateral. Al inicio no tendrá ningún paciente asignado, por lo que deberá seleccionar en la barra lateral del menú Listado global de pacientes, donde se listan todos los pacientes que se encuentran en el sistema. Entonces el médico, seleccionando la opción Asignar paciente, vinculará al paciente para poder interactuar con él, pues en la base de datos quedará establecido en el documento del paciente en la colección Paciente un array de los médicos asignados a ese paciente, pues un paciente puede tener asignados diversos médicos y fisioterapeutas. También se pueden consultar los pacientes que tiene el médico asignados en el apartado Mis pacientes 64 Figura 6.6: Listado global de pacientes Figura 6.7: Listado global de pacientes con dos pacientes asignados al médico Figura 6.8: Listado Mis pacientes 65 Una de las funcionalidades más interesantes de la aplicación consiste en poder establecer rutinas y tablas de ejercicios que se almacenarán en la base de datos para que después el pa- ciente al iniciar el juego y validar sus credenciales, observe cómo se cargan automáticamente los parámetros de la partida, como el número de series o de repeticiones entre otros. Esto se establece desde el apartado Crear tablas de ejercicios, que consiste en un formulario donde se debe seleccionar el ángulo máximo al que deberá recorrer el movimiento del ejercicio el paciente para que la repetición sea válida, se deberá seleccionar también el nombre del ejercicio del que se desea crear una tabla, seleccionar el paciente al que se desea asociar ese rutina de ejercicios, el número de series y el número de repeticiones que tendrá esa rutina. Cabe resaltar que únicamente puede existir una rutina de ejercicios sin completar, por lo que al tratar de asociar una rutina de un mismo ejercicio a un mismo paciente, cuando este ya tenía una asociada, resultará en error, pues hasta que el paciente no complete esa rutina, no se podrá establecer una nueva. Figura 6.9: Crear tabla de ejercicios 66 Figura 6.10: Error al tratar de asociar una tabla a un paciente con una ya activa Finalmente, la otra funcionalidad característica de la aplicación consiste en un panel de estadísticas donde el médico podrá consultar varias gráficas que muestren el progreso y los datos de las sesiones de juego de los pacientes. Esto permite una visualización rápida que permita al personal sanitario tener un apoyo a la hora de evaluar el progreso de los pacientes que se están recuperando. Este panel muestra en el lado izquierdo las gráficas (realizadas mediante Chart.js) asociadas al ejercicio de hombros y en el lado derecho al ejercicio del tobillo. La primera de las gráficas muestra la progresión del movimiento del paciente según el tiempo de la última sesión de juego, es decir, una manera gráfica de observar cómo ha ejecutado el movimiento el paciente y durante cuanto tiempo, lo que puede resultar tremendamente útil para tener una telemetría del progreso del paciente. Esta gráfica se encuentra en ambas columnas. Por otra parte, en la columna asociada al movimiento de hombros, se puede observar cuántas veces en la partida se ha golpeado pelotas y cuántas veces bombas, lo que permite hacerse una idea de la agilidad mental del paciente y ver sus progresos en las últimas sesiones de juego, mostrando en el eje x la fecha y en el eje y el número de golpeos, mientras que en color verde se observa el golpeo de pelotas, y en rojo de bombas. En la columna del ejercicio del tobillo, la segunda gráfica describe el número de 67 repeticiones totales que se han hecho en las últimas sesiones de juego y así poder tener un registro de la carga de ejercicios que ha tenido el paciente. Finalmente en la última gráfica de ambas columnas, se despliega la puntuación total de cada una de las sesiones de juego, mostrando también la fecha, y los puntos totales de esa sesión, lo cuál se podría abstraer y compararlo a las gráficas anteriores para entender el progreso del paciente. Figura 6.11: Gráficas asociadas a la telemetría del movimiento de los ejercicios Figura 6.12: Otras gráficas que muestran las estadísticas mencionadas 68 Capítulo 7 Conclusión y perspectivas futuras 7.1. Conclusión Este trabajo de fin de grado tuvo como objetivo continuar el proyecto de fin de grado del año anterior, con la meta de completar la serie de ejercicios destinados a los pacientes del hospital. La idea inicial era desarrollar tres videojuegos diferentes para abordar distintos tipos de movimiento, sin embargo, consideramos más conveniente crear dos videojuegos y dedicar recursos adicionales a la construcción de una arquitectura web que permitiera gestionar los juegos y monitorizar la evolución de los pacientes por parte de los médicos y fisioterapeutas. Durante el desarrollo del proyecto, hemos podido aplicar los conocimientos adquiridos a lo largo de nuestra formación en ingeniería informática, ingeniería del software y desarrollo de videojuegos. La combinación de habilidades en arquitectura web y desarrollo de videojuegos nos permitió diseñar una solución integral que busca mejorar la experiencia de rehabilitación de los pacientes. Nuestra elección de Unity como motor de videojuegos nos permitió crear un sistema de bajo coste, fácil de instalar y accesible para la mayoría de las personas, ya que no requiere hardware específico adicional, como una consola. En resumen, este proyecto nos permitió aplicar nuestros conocimientos en el desarrollo de videojuegos con un enfoque sanitario, específicamente en el ámbito de la rehabilitación 69 de pacientes. Esperamos que nuestro prototipo pueda contribuir de manera significativa al proceso de recuperación de las personas que lo utilicen. 7.2. Perspectivas futuras Estos juegos han sido diseñados con el objetivo de mejorar la experiencia de rehabi- litación para pacientes en situación grave dentro del entorno hospitalario. Sin embargo, se ha considerado la posibilidad de ampliar su alcance para permitir la continuidad de la rehabilitación desde el hogar en caso de mejoría del paciente. Como miras a mejorar la experiencia y la calidad del producto, se plantean las siguientes acciones futuras: Framework adaptable: Se propone el desarrollo de un framework que permita la implementación de más videojuegos y la adición de nuevas funcionalidades en los exis- tentes. Este framework brindaría flexibilidad y escalabilidad al sistema, permitiendo su adaptación a diferentes necesidades y contextos. Para lograrlo, se han realizado las siguientes acciones en nuestro trabajo, que servirán como base para futuros desarro- llos: Hemos desarrollado un paquete de Unity que simplifica la conexión con la base de datos de MongoDB, proporcionando configuraciones predefinidas para establecer conexiones de manera rápida y sencilla, evitando configuraciones manuales complejas. Además, creamos una plantilla para el envío de datos a la base de datos, y facilitar la implementación de nuevos juegos. Personalización de personajes: Permite a los usuarios crear y personalizar su pro- pio avatar o personaje dentro del juego, lo que aumentaría el sentido de identidad y motivación personal. Sistema de recompensas y desafíos: Introducir un sistema de recompensas por logros y desafíos completados, incentivando a los usuarios a seguir participando y superando obstáculos. 70 Creación de instancias interhospitalarias: Implementa la capacidad de crear ins- tancias de rehabilitación entre distintos hospitales, permitiendo así compartir el ser- vicio y los datos de rehabilitación entre diferentes centros de salud. Esto facilita la colaboración y la interoperatibilidad entre profesionales de la salud de distintas insti- tuciones, lo que puede mejorar la calidad y eficacia de la rehabilitación de los pacientes. Esta funcionalidad podría ser gestionada mediante un sistema de Software as a Service (SaaS, o Software como Servicio) que permita la configuración y coordinación de las instancias entre hospitales de manera centralizada. 71 Capítulo 8 Conclusion and future perspective 8.1. Conclusion This final degree project had as objective to continue the project made by our colleagues the previous year, with the goal of complete the series of exercises intended for patients of the hospital. The initial idea was to develop three different video games to approach different types of movement. However, we considered more convenient to create two video games and to dedicate additional resources to the build of a web architecture which would permit to manage the video games and to monitor the evolution of the patients from the physiotherapist side. During the development of the project we could apply our acquired knowledge th- roughout our formation in computer science and video game development. The combination of abilities in web architecture and video game development permitted us to design a com- prehensive solution which searches to improve the experience of the rehabilitation process. Our choice of Unity as the game engine allowed us to create a low-cost system, easy to install and accessible for the majority of people, since it does not require a specific hardware like a console could be. In short, this project permitted us to to apply our knowledge on computer science making emphasis in a health approach, specifically in the rehabilitation area. We hope our prototype could contribute in a significative way to the recovery process of the people will use it. 72 8.2. Future perspective These games have been designed with the objective of improve the experience of the rehabilitation process for patients in a hard situation inside the hospital environment. Ho- wever, the possibility of enlarge this range have been considered, permitting the continuity of the rehabilitation from home in case of improvement in the health of the patient. Looking forward to improve the experience and the quality of the product the following actions are proposed: Adaptive Framework: The development of a framework that permits the implemen- tation of more video games is proposed and the addition of new functionalities in the existing ones. This framework would bring flexibility and scalability to the system, permitting the adaptation in different needs and contexts. We have developed a Unity package that simplifies the connection with the MongoDB database, providing predefined configurations to establish the connection Character customization: Permit the user to create and personalize their own ava- tar or character inside the game, this would increase the sense of identity and personal motivation. Challenges and rewards system: Introduce a rewards system by achievements and completed challenges, encouraging the patients to keep participating and overcoming obstacles. Creation of inter-hospital instances: Implement the capacity to create instan- ces of rehabilitation between different hospitals, permitting to share the service and the data of the rehabilitation between different health centres. This would facilitate the collaboration and the interoperability between health professionals from different institutions, which can greatly improve the quality and efficiency of the patients’ reha- bilitation. This functionality could be managed through Software as a Service (SaaS) 73 system that allows the configuration and coordination of the instances between hos- pitals in a centralized tool. 74 Capítulo 9 Contribución 9.1. Contribución común En esta sección se mencionará los aspectos comunes en la contribución del proyecto. En primer lugar se definió la metodología que íbamos a usar y los primeros pasos a seguir. A continuación se diseñó cada uno de los juegos que se iba a implementar y la arqui- tectura general del sistema con posibilidad de cambio, definiendo tecnologías a utilizar y herramientas de apoyo en nuestro desarrollo. Se hizo el prototipado en papel de varias ideas de posibles minijuegos a implementar. Cuando se puso en común y se escogieron las ideas definitivas se implementó el prototipo en Unity. Desarrollo de las mecánicas más básicas de cada juego y los primeros objetos de cada escena para definir los aspectos básicos. Una vez implementados los juegos y conectados con la aplicación web se realizó una serie de pruebas de integridad y testeos de la funcionalidad del sistema para asegurar el correcto funcionamiento de todos los módulos. 9.2. Contribución Álvaro Serna Además de lo mencionado anteriormente, Álvaro se ha encargado de los siguientes as- pectos del proyecto: 75 Desarrollo de la aplicación móvil: con ayuda del plugin de Riptide se ha desarrolla- do la aplicación móvil que se encarga de establecer la conexión con los distintos juegos y una vez establecida comienza el envío de los datos de los sensores del dispositivo. Crear servidor local en los juegos: Para establecer la conexión con la aplicación móvil se ha requerido establecer un servidor local en cada uno de los juegos con la ayuda de Riptide. Diseño y desarrollo del sistema de entrada: Con los datos que se reciben de la aplicación se ha diseñado y desarrollado un sistema de entrada que permita la detección de la realización de un movimiento gracias a la información de los sensores, y calculando el ángulo de inclinación del dispositivo, este sistema es común para los dos juegos. Interfaz de usuario y feedback: Diseño de la interfaz de usuario a nivel de escena del juego, mostrando los aspectos relevantes de la partida, como la puntuación o el progreso total, además del diseño de la barra de progreso para mostrar al usuario su rango de movimiento en tiempo real. Diseño e implementación del flujo de juego: Pensar y desarrollar como se va a comunicar el juego con el resto de componentes del sistema, cuando establecer conexión con la base de datos o con la aplicación móvil. Definir los distintos estados por los que va a pasar el juego durante el desarrollo de una partida. Diseño y desarrollo de la conexión con la base de datos: a través el SDK de Realm se ha desarrollado un módulo en cada juego que establece una conexión con nuestra base de datos para recibir datos de configuración de cada usuario y para enviar los resultados de los pacientes después de cada partida. Procesos de búsqueda de información para implementar los módulos de cone- xiones hacia el exterior del cada uno de los juegos, tanto para recibir los datos de un 76 sensor como para los datos de configuración y guardado. Arreglos y correcciones de errores: en ambos juegos corrección de aquellos fallos referentes al flujo de la partida o relacionados con la base de datos y el sistema de guardado. Lanzamiento de los juegos: Creación de las distintas versiones finales de los juegos para varias plataformas, así como el empaquetado de la aplicación de móvil. En cuánto a la memoria: Encargado de escribir los capítulos y/o secciones siguien- tes: Resumen, 1. Introducción, 2. Introduction, 4.2. Proceso de diseño de los videojuegos, 4.3. Diseño de jugabilidad y mecánicas, 5.1.5. Captura de mo- vimiento, 5.1.6. Configuración de los parámetros, 5.1.7. Registro de datos de movimiento, 5.4. Aplicación móvil, 6.2. Resultados de los videojuegos, 8. Conclusion, Apéndice A. Prototipos en papel. 9.3. Contribución Juan Romo Además de lo mencionado anteriormente, Juan se ha encargado de los siguientes aspectos del proyecto: Diseño y planificación de la arquitectura: Planteamiento y diseño de la lógica y arquitectura del sistema, resolviendo cuestiones como donde desplegar el sistema, que herramientas utilizar o que servicios en la nube tal como Vercel o MongoDB Atlas, tomando las principales decisiones tecnológicas. Diseño de los juegos y de sus prototipos: Planteamiento y diseño de que tipo de juegos se podrían diseñar y desarrollar que se ajustasen al problema planteado, y una ves resuelto este punto, se dibujó el prototipo en papel. Diseño de los escenarios de los juegos: Ya desarrollando en Unity, se hizo el diseño e implementación de los escenarios de fondo y de algunos de los elementos gráficos de 77 los juegos. Desarrollo y lógica de los juegos: Se colaboró en codificar y pensar la lógica de los juegos implementada en Unity en C#. Creación de las animaciones: Implementación de algunas de las animaciones de los juegos, como la del movimiento de la pelota, de la bomba o del personaje. Diseño y lógica de la aplicación: Concepción inicial de la aplicación de estadísticas, y que podría aportar al proyecto, describiendo los casos de uso y tecnologías a utilizar. Implementación completa de la aplicación: Desarrollo completo de la aplicación, realizado en NextJS, desarrollando todas las clases tanto del Back-end como del Front- end y planteando también toda la lógica detrás del uso de la aplicación. Testing del sistema completo: Realización de pruebas y testeo de todos los com- ponentes del sistema, con el objetivo de detectar y depurar errores para su posterior corrección. En cuánto a la memoria: Encargado de escribir los capítulos y/o secciones siguien- tes: Resumen, 3. Capítulo 3 completo, 4.4. Desarrollo artístico, 6. Capítulo 6 completo, Revisión de todos los textos y traducciones al inglés. 9.4. Contribución Luis Manuel Pérez Además de lo mencionado anteriormente, Luis Manuel se ha encargado de los siguientes aspectos del proyecto: Procesos de búsqueda de información para implementar la base de datos y su integración con Unity, garantizando una gestión eficiente de los datos de los juegos y su correcta unificación en la plataforma de desarrollo. 78 Creación de imágenes para las interfaces de usuario: diseño y elaboración de imágenes para las explicaciones de los ejercicios integrados en las interfaces del juego. Estas imágenes fueron creadas para mejorar la experiencia del usuario al proporcionar instrucciones visuales claras y concisas sobre los ejercicios. Desarrollo del panel de opciones: creación y programación del panel de opciones que incluye funcionalidades para ajustar el volumen, modificar el brillo y seleccionar la resolución de la pantalla. Desarrollo y lógica de los juegos: Se contribuyó significativamente en la progra- mación y concepción de la lógica de los juegos, implementados en Unity. Interfaz de usuario para los juegos: creación completa de la interfaz de usuario para ambos juegos. Esto incluyó no solo el diseño visual de elementos interactivos como botones, paneles y menús, sino también la implementación y programación para garantizar su correcto funcionamiento y una experiencia de usuario fluida. Búsqueda y creación de arte para los videojuegos: llevar a cabo la búsqueda y selección de personajes, interfaces de usuario (botones, paneles, menús,etc.) y fuen- tes. Utilizando recursos disponibles en plataformas como itch.io y otras fuentes con licencias gratuitas, o creándolas desde el principio con la herramienta pixel. Arreglos y correcciones de errores: Se realizaron correcciones en ambos juegos, enfocándose en resolver fallos relacionados con el flujo de la partida. En cuánto a la memoria: Encargado de escribir los capítulos y/o secciones si- guientes: 4.1. Tipos de Ejercicios, 4.2.2. Diseño de los videojuegos, 4.2.3. Estética común, 4.5. Música y Efectos de sonido, 5.1. Elementos Unificados en todos los juegos, 5.2. Juego 1: GolfingMiniGame, 5.3. Juego 2: Jumping- MiniGame, 5.5.1. Desarrollo y clases, 6.3. Resultados de la aplicación web, 7. Conclusión 79 Bibliografía [1] «Audacity». https://www.audacityteam.org/. [Online]. [2] «Chart.js». https://www.chartjs.org/. [Online]. [3] «Chart.js». https://www.chartjs.org/. [Online]. [4] «diagrams.net». https://diagrams.net/. [Online]. [5] «Discord». https://discord.com/. [Online]. [6] «Freesound». https://freesound.org/. [Online]. [7] «Git». https://git-scm.com/. [Online]. [8] «GitHub». https://github.com/. [Online]. [9] «Itch.io». https://itch.io/. [Online]. [10] «MongoDB». https://www.mongodb.com/. [Online]. [11] «MongoDB Atlas». https://www.mongodb.com/atlas. [Online]. [12] «MongoDB Compass». https://www.mongodb.com/products/tools/compass. [On- line]. [13] «Node.js». https://nodejs.org/. [Online]. [14] «Notion». https://www.notion.so/es-es. [Online]. [15] «Piskel». https://www.piskelapp.com/. [Online]. [16] «React». https://es.react.dev/. [Online]. 80 https://www.audacityteam.org/ https://www.chartjs.org/ https://www.chartjs.org/ https://diagrams.net/ https://discord.com/ https://freesound.org/ https://git-scm.com/ https://github.com/ https://itch.io/ https://www.mongodb.com/ https://www.mongodb.com/atlas https://www.mongodb.com/products/tools/compass https://nodejs.org/ https://www.notion.so/es-es https://www.piskelapp.com/ https://es.react.dev/ [17] «Realm SDK». https://www.mongodb.com/developer/products/realm/sdk/. [On- line]. [18] «Rehabilitación de hombro en silla». https://www.mskcc.org/es/cancer-care/ patient-education/arm-exercise-program. [Online]. [19] «Rehabilitación de tobillo y pie». https://www.angelinipharma.es/media/ dx5drb0f/8819_ejercicios-pie-y-tobillo_web.pdf. [Online]. [20] «scrum.org». https://www.scrum.org/. [Online]. [21] «Tailwind CSS». https://tailwindcss.com/. [Online]. [22] «TypeScript». https://www.typescriptlang.org/. [Online]. [23] «Unity». https://unity.com/es. [Online]. [24] «Vercel». https://vercel.com/. [Online]. [25] Dani Candil and Vida Extra. «Unity, el motor de desarrollo capaz de partir la historia de los videojuegos en dos». https://www.vidaextra.com/industria/ unity-el-motor-de-desarrollo-capaz-de-partir-la-historia-de-los-videojuegos-en-dos. [Online]. [26] Angel Denche-Zamorano, Yeray Rodriguez-Redondo, Sabina Barrios-Fernandez, María Mendoza-Muñoz, Antonio Castillo-Paredes, Jorge Rojo-Ramos, Miguel Angel Garcia- Gordillo, Jose Carmelo Adsuar, and Patricia Sánchez González. «Rehabilitation Is the Main Topic in Virtual and Augmented Reality and Physical Activity Research: A Biblio- metric Analysis». https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10056397/, 2023. [Online]. [27] Andreia Gaita. «GitHub for Unity». https://github.com/github-for-unity/ Unity?tab=readme-ov-file. [Online]. 81 https://www.mongodb.com/developer/products/realm/sdk/ https://www.mskcc.org/es/cancer-care/patient-education/arm-exercise-program https://www.mskcc.org/es/cancer-care/patient-education/arm-exercise-program https://www.angelinipharma.es/media/dx5drb0f/8819_ejercicios-pie-y-tobillo_web.pdf https://www.angelinipharma.es/media/dx5drb0f/8819_ejercicios-pie-y-tobillo_web.pdf https://www.scrum.org/ https://tailwindcss.com/ https://www.typescriptlang.org/ https://unity.com/es https://vercel.com/ https://www.vidaextra.com/industria/unity-el-motor-de-desarrollo-capaz-de-partir-la-historia-de-los-videojuegos-en-dos https://www.vidaextra.com/industria/unity-el-motor-de-desarrollo-capaz-de-partir-la-historia-de-los-videojuegos-en-dos https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10056397/ https://github.com/github-for-unity/Unity?tab=readme-ov-file https://github.com/github-for-unity/Unity?tab=readme-ov-file [28] Clerk Inc. «Clerk». https://clerk.com/. [Online]. [29] GitHub Inc. «GitHub Projects». https://docs.github.com/es/issues/ planning-and-tracking-with-projects/learning-about-projects/ about-projects. [Online]. [30] Julia Martins. «What Is Kanban?». https://asana.com/es/resources/ what-is-kanban, 2024. [Online]. [31] Marta A. Montalbán and Oscar Arrogante. «Rehabilitación me- diante terapia de realidad virtual tras un accidente cerebrovas- cular: una revisión bibliográfica». https://www.elsevier.es/ en-revista-revista-cientifica-sociedad-espanola-enfermeria-447-articulo-rehabilitation-through-virtual-reality-therapy-S2530299X20300078, 2020. [Online]. [32] Nintendo. «Mario Party Superstars». https://www.nintendo.com/es-es/Juegos/ Juegos-de-Nintendo-Switch/Mario-Party-Superstars-1987416.html. [Online]. [33] Nintendo. «Nintendo Switch». https://www.nintendo.com/es-es/Hardware/ Familia-Nintendo-Switch/Nintendo-Switch/Nintendo-Switch-1148779.html. [Online]. [34] Nintendo. «Nintendo Wii». https://www.nintendo.com/es-es/Wii/Accesorios/ Accesorios-Wii-Nintendo-Ib-eacute-rica-626430.html. [Online]. [35] Nintendo. «Super Mario Party». https://www.nintendo.com/es-es/Juegos/ Juegos-de-Nintendo-Switch/Super-Mario-Party-1388641.html. [Online]. [36] Nintendo. «Wii Fit». https://www.nintendo.com/es-es/Juegos/Wii/ Wii-Fit-283894.html. [Online]. [37] Nintendo. «Wii Party». https://www.nintendo.com/es-es/Juegos/Wii/ Wii-Party-283938.html. [Online]. 82 https://clerk.com/ https://docs.github.com/es/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects https://docs.github.com/es/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects https://docs.github.com/es/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects https://asana.com/es/resources/what-is-kanban https://asana.com/es/resources/what-is-kanban https://www.elsevier.es/en-revista-revista-cientifica-sociedad-espanola-enfermeria-447-articulo-rehabilitation-through-virtual-reality-therapy-S2530299X20300078 https://www.elsevier.es/en-revista-revista-cientifica-sociedad-espanola-enfermeria-447-articulo-rehabilitation-through-virtual-reality-therapy-S2530299X20300078 https://www.nintendo.com/es-es/Juegos/Juegos-de-Nintendo-Switch/Mario-Party-Superstars-1987416.html https://www.nintendo.com/es-es/Juegos/Juegos-de-Nintendo-Switch/Mario-Party-Superstars-1987416.html https://www.nintendo.com/es-es/Hardware/Familia-Nintendo-Switch/Nintendo-Switch/Nintendo-Switch-1148779.html https://www.nintendo.com/es-es/Hardware/Familia-Nintendo-Switch/Nintendo-Switch/Nintendo-Switch-1148779.html https://www.nintendo.com/es-es/Wii/Accesorios/Accesorios-Wii-Nintendo-Ib-eacute-rica-626430.html https://www.nintendo.com/es-es/Wii/Accesorios/Accesorios-Wii-Nintendo-Ib-eacute-rica-626430.html https://www.nintendo.com/es-es/Juegos/Juegos-de-Nintendo-Switch/Super-Mario-Party-1388641.html https://www.nintendo.com/es-es/Juegos/Juegos-de-Nintendo-Switch/Super-Mario-Party-1388641.html https://www.nintendo.com/es-es/Juegos/Wii/Wii-Fit-283894.html https://www.nintendo.com/es-es/Juegos/Wii/Wii-Fit-283894.html https://www.nintendo.com/es-es/Juegos/Wii/Wii-Party-283938.html https://www.nintendo.com/es-es/Juegos/Wii/Wii-Party-283938.html [38] Nintendo. «Wii Sports». https://www.nintendo.com/es-es/Juegos/Wii/ Wii-Sports-283971.html. [Online]. [39] Adell Destino RPG. «Historia de los videojuegos: La generación de los 16 bits». https://www.destinorpg.es/2016/01/historia-de-los-videojuegos-la. html, 2016. [Online]. [40] Vercel. «Next.js». https://nextjs.org/. [Online]. [41] Tom Weiland. «Riptide». https://github.com/RiptideNetworking/Riptide. [On- line]. 83 https://www.nintendo.com/es-es/Juegos/Wii/Wii-Sports-283971.html https://www.nintendo.com/es-es/Juegos/Wii/Wii-Sports-283971.html https://www.destinorpg.es/2016/01/historia-de-los-videojuegos-la.html https://www.destinorpg.es/2016/01/historia-de-los-videojuegos-la.html https://nextjs.org/ https://github.com/RiptideNetworking/Riptide Apéndice A Prototipos en papel En el siguiente apéndice se recogen los distintos prototipos en papel que hemos realizado para definir y diseñar las funcionalidades y mecánicas más básicas de nuestros juegos. A.1. Prototipo minijuego de golf 84 A.2. Prototipo minijuego de coche 85 A.3. Prototipo minijuego de salto 86 Portada Dedicatoria Agradecimientos Resumen Abstract Índice Índice de Figuras Introducción Motivación Estado del arte Objetivos Introducción a las tecnologías Plan de trabajo Introduction Motivation State of the art Objectives Introduction to technologies Work plan Tecnologías empleadas y arquitectura del sistema Tecnologías aplicadas en los videojuegos Unity Piskel Chart.js Tecnologías de control de versiones Tecnologías para la gestión del proyecto GitHub Projects Notion Discord diagrams.net Tecnologías aplicadas para la persistencia de datos Tecnologías aplicadas para la aplicación web Backend Front-end Arquitectura del sistema Arquitectura general del sistema Arquitectura del módulo videojuegos Arquitectura del módulo aplicación web Modelo entidad-relación del sistema Diseño y Metodología Tipos de ejercicios Rehabilitación de hombro Rehabilitación de tobillo y pie Proceso de diseño de los videojuegos Recolección de ideas y ejemplos de videojuegos Diseño de los videojuegos Estética común Diseño de jugabilidad y mecánicas Desarrollo artístico Música y Efectos de sonido Implementación Elementos Unificados en todos los juegos Menú principal Menú de pausa Menú de opciones Menú de instrucciones Captura de movimiento Configuración de los parámetros Registro de datos de movimiento Diseño de una API escalable a futuro Juego 1: GolfingMiniGame Concepto del juego Desarrollo y clases Juego 2: JumpingMiniGame Concepto del juego Desarrollo y clases Aplicación móvil Desarrollo y clases Aplicación web Desarrollo y clases Resultados Resultados generales Resultados de los videojuegos Resultados de la aplicación web Conclusión y perspectivas futuras Conclusión Perspectivas futuras Conclusion and future perspective Conclusion Future perspective Contribución Contribución común Contribución Álvaro Serna Contribución Juan Romo Contribución Luis Manuel Pérez Bibliografia Prototipos en papel Prototipo minijuego de golf Prototipo minijuego de coche Prototipo minijuego de salto