Repositorio Institucional de Documentos

Proyecto Fin de Carrera Ingeniería en Informática Curso de programación de videojuegos en Unity 3D para iPad Autor: Cristian Escudero Cestero Director: Ramón Piedrafita Moreno Área de Ingeniería de Sistemas y Automática Departamento de Informática e Ingeniería de Sistemas Escuela de Ingeniería y Arquitectura Universidad de Zaragoza Septiembre 2013 Repositorio de la Universidad de Zaragoza – Zaguan http://zaguan.unizar.es Curso de programación de videojuegos en Unity 3D para iPad Resumen El curso de programación de videojuegos en Unity 3D para iPad es un PFC que consiste en una aplicación iOS interactiva diseñada y creada para el dispositivo iPad de Apple. Con esta aplicación se pretende facilitar y estimular la enseñanza de la programación de videojuegos. Unity es un motor gráfico multiplataforma que se distribuye junto a un IDE (Entorno de Desarrollo Integrado) que permite la creación de contenido 3D (en especial videojuegos) de forma más rápida y sencilla que la mayoría de entornos existentes. La aplicación tiene el objetivo de introducir a los usuarios dentro del mundo del desarrollo de videojuegos mediante el uso de Unity 3D. Para ello se ha creado una amplia documentación que cubre desde los aspectos más básicos hasta la creación de un videojuego completo. Esta aplicación está compuesta por las siguientes partes: ‣ Visor: es la parte de la aplicación que centraliza todo el curso. Desde el visor se accede al resto de elementos. Se han programado las funcionalidades típicas de los visores de documentos (zoom, desplazamiento táctil, acceso a los contenidos y a la ayuda), así como el lanzamiento del reproductor de vídeos, ejecución de las aplicaciones y del juego completo. También muestra la documentación del curso. ‣ Documentación: conjunto de temas escritos que explican la programación de videojuegos con Unity 3D. ‣ Vídeos: ejemplos visuales que resumen partes de las explicaciones escritas más relevantes. Los vídeos se reproducen en la misma aplicación. ‣ Aplicaciones: ejemplos interactivos creados con Unity 3D, que se ejecutan desde el visor y se manejan dentro de la aplicación principal. ‣ Juego: ejemplo completo de videojuego. Es una parte fundamental puesto que es una aplicación en sí misma ya que posee los elementos tradicionales de un videojuego. El juego se comunica con una aplicación web de gestión de máximas puntuaciones. La aplicación está diseñada para que su manejo sea intuitivo y sencillo y que pueda ser usada por cualquier persona sin la necesidad de tener conocimientos avanzados en este tipo de dispositivos. Para el seguimiento del curso se recomienda tener mínimos conocimientos de programación. 3 Índice Índice de contenido 1. Introducción .......................................................... 14 1.1. Contexto y motivación del proyecto ..................... 15 1.2. Objetivos y alcance ............................................. 17 1.3. Estudios preliminares .......................................... 19 1.4. Tecnología. Uso y justificación ............................ 19 1.5. Ámbito del proyecto ............................................. 21 1.6. Metodología y planificación ................................. 22 1.7. Estructura del documento .................................... 23 2. Trabajo realizado .................................................. 25 2.1. Visor ..................................................................... 27 2.1.1. Introducción ............................................. 27 2.1.2. Estudio preliminar .................................... 27 2.1.3. Determinación de requisitos .................... 28 2.1.4. Casos de uso .......................................... 29 2.1.5. Decisiones de diseño .............................. 31 2.1.6. Diseño de la interfaz ................................ 33 2.1.7. Implementación del visor ......................... 37 2.2. Videojuego “La venganza de Timan” ................... 38 2.2.1. Introducción ............................................. 38 2.2.2. Análisis y diseño ...................................... 38 2.2.3. Modelado de objetos en 3D .................... 50 2.2.4. Implementación ....................................... 53 2.2.5. Interfaz .................................................... 56 2.3. Aplicación web ..................................................... 58 2.3.1. Introducción ............................................. 58 2.3.2. Decisiones de diseño .............................. 59 2.3.3. Web de puntuaciones .............................. 62 2.4. Resto de elementos de la aplicación ................... 65 2.4.1. Textos del curso ...................................... 65 2.4.2. Vídeos ..................................................... 65 2.4.3. Aplicaciones interactivas ......................... 66 4 2.5. Pruebas ............................................................... 68 3. Conclusiones ........................................................ 70 3.1. Cumplimiento de objetivos .................................. 70 3.2. Mejoras y ampliaciones ....................................... 71 3.3. Perspectivas de futuro del proyecto .................... 71 3.4. Valoración personal ............................................. 72 4. Bibliografía ............................................................ 74 Anexos Anexo A. Estudios preliminares .............................. 77 A.1. Situación de la industria de los videojuegos ....... 77 A.2. Estudio de mercado de los dispositivos iOS ....... 85 A.3. Importancia de Unity 3D como motor gráfico ...... 90 A.4. Conclusiones ....................................................... 90 Anexo B. Tecnologías empleadas ........................... 92 B.1. Pages .................................................................. 92 B.2. Keynote ............................................................... 93 B.3. Numbers .............................................................. 93 B.4. GIMP ................................................................... 94 B.5. InkScape ............................................................. 97 Anexo C. Modelado de objetos con Blender ......... 100 Anexo D. Unity 3D .................................................... 103 D.1. UnityScript ........................................................... 104 D.1.1. Generalidades ........................................ 104 D.1.2. Sintaxis ................................................... 106 D.2. C# ....................................................................... 109 D.2.1. Características de C# ............................. 110 Anexo E. Tecnologías web empleadas ................... 115 E.1. AJAX ................................................................... 115 E.2. PHP ..................................................................... 117 E.3. MySQL ................................................................ 119 Anexo F. Documentación del proyecto .................. 121 F.1. Estudio preliminar de visores ............................... 121 5 F.2. Especificación de requisitos ................................ 123 F.3. Planificación ......................................................... 128 F.3.1. Planificación inicial .................................. 128 F.3.2. Planificación real ..................................... 130 F.4. Análisis y diseño del videojuego .......................... 134 F.4.1. Casos de uso ........................................... 134 F.4.2. Diagrama de flujo del videojuego ............ 135 F.4.3. Diagrama de clases ................................. 139 F.4.4. Modelado dinámico ................................. 147 F.4.5. Interfaz del videojuego ............................ 155 F.5. Pruebas ............................................................... 156 F.6. Vídeos del curso .................................................. 158 F.7. Aplicaciones interactivas ...................................... 160 Anexo G. Manual de usuario ................................... 163 G.1. Perspectiva general de la aplicación .................. 163 G.2. Visor .................................................................... 164 G.3. Videojuego “La venganza de Timan” .................. 174 G.3.1. Objetivos del juego ................................. 176 G.3.2. Control del personaje ............................. 177 G.3.3. Puntuaciones .......................................... 178 G.3.4. Interfaz de la partida ............................... 179 Anexo H. Documento de Diseño del Juego (GDD) 180 H.1. Modelo de DGG .................................................. 181 H.2. Modelo de TDD ................................................... 183 Anexo I. Ejemplo de capítulo del curso .................. 185 6 Índice de figuras Figura 1. Ingresos a nivel mundial logrados por la industria de los videojuegos"15 Figura 2. Motores gráficos empleados por los desarrolladores de videojuegos para móviles"16 Figura 3. Diagrama del modelo en cascada modificado"22 Figura 4. Visión general del sistema creado"25 Figura 5. Caso de uso general del visor"30 Figura 6. Diagrama de actividades del visor"32 Figura 7. Jerarquía de ventanas del visor"33 Figura 8. Aspecto de la interfaz del curso con una página de texto cargada"34 Figura 9. Aspecto de la interfaz con el menú de opciones desplegado "35 Figura 10. Aspecto de la interfaz con el menú de vídeos cargado"36 Figura 11. Diagrama del patrón de diseño Modelo - Vista - Controlador"37 Figura 12. Diagrama de secuencia del caso de uso avanzar página "38 Figura 13. Diagrama de flujo de datos de nivel 0 del juego"41 Figura 14. Elementos básicos de un videojuego"42 Figura 15. Ejemplo de interacción con el personaje y enemigos en el videojuego"43 Figura 16. Ejemplo de los enemigos del personaje principal"44 Figura 17. Ejemplo de superficie mortal"44 Figura 18. Ejemplo de estrella y cofre del videojuego"45 Figura 19. Ejemplo de checkpoint"45 Figura 20. Ejemplo de Corazón que representan las vidas del personaje"46 Figura 21. Esquema del primer nivel del videojuego"47 7 Figura 22. Captura de pantalla real del primer nivel del videojuego"47 Figura 23. Esquema del segundo nivel del videojuego"48 Figura 24. Captura de pantalla real del segundo nivel del videojuego "48 Figura 25. Esquema del tercer nivel del videojuego"49 Figura 26. Captura de pantalla real del tercer nivel del videojuego"50 Figura 27. Modelo del personaje principal para uno de los niveles del juego"51 Figura 28. Modelo de lava con textura animada"51 Figura 29. Modelo de foso con pinchos"51 Figura 30. Modelos de las plataformas empleadas en los tres niveles "52 Figura 31. Modelo de rayo creado para el nivel 3"52 Figura 32. Modelos de objetos empleados como decoración de los niveles"53 Figura 33. Diagrama de las clases empleadas en el personaje principal del videojuego"54 Figura 34. Diagrama de secuencia de la interacción entre enemigos y personaje principal"55 Figura 35. Diagrama de navegación del menú principal"56 Figura 36. Ejemplo de interfaz del menú principal"57 Figura 37. Interfaz del juego"58 Figura 38. Diagrama Entidad / Relación de la aplicación web"60 Figura 39. Diagrama de actividades del Juego - Aplicación web"62 Figura 40. Captura de pantalla de la página de resultados máximos "63 Figura 41. Captura de pantalla de resultados máximos ordenados por el total de estrellas"64 Figura 42. Hola Mundo 3D. Ejemplo de aplicación interactiva"67 Figura 43. Ejemplo de aplicación de fuerzas sobre objetos"68 Figura A.1. Ingresos globales en móviles (1010 dólares) y participación del total del segmento de videojuegos (%) de 2008 a 2017"78 8 Figura A.2. Ingresos por venta de consolas por zonas (1010 dólares) de 2011 a 2017"79 Figura A.3. Ingresos por venta de videojuegos en los tres mercados más importantes (1010 dólares) de 2008 a 2017"80 Figura A.4. Gasto global de los usuarios por tipo de dispositivo (1010 dólares) de 2008 a 2017"81 Figura A.5. Total de ingresos por juegos en línea (1010 dólares) y participación del total del segmento de videojuegos (%) de 2008 a 2017"82 Figura A.6. Ingresos totales (109 dólares) de la industria de los videojuegos en EE.UU. (2012)"82 Figura A.7. Videojuegos más vendidos por género en consolas en unidades (2012)"84 Figura A.8. Videojuegos más vendidos por género en computadoras en unidades (2012)"85 Figura A.9. Distribución de nuevos proyectos en iOS Vs Android"86 Figura A.10. Dispositivos Android activos como porcentaje de dispositivos iOS"86 Figura A.11. Total de tiempo pasado en aplicaciones por Android como porcentaje del total de tiempo en aplicaciones por iOS"87 Figura A.12. Países con el mayor número de dispositivos iOS y Android activos (millones) (2013)"88 Figura A.13. Millones de ventas de iPad (2010-2013)"89 Figura A.14. Tiempo empleado por categoría de aplicación"91 Figura B.1. Icono de la aplicación Pages"92 Figura B.2. Icono de la aplicación Keynote"93 Figura B.3. Icono de la aplicación Numbers"93 Figura B.4. Icono de la aplicación GIMP"94 Figura B.5. Modelo 3D del enemigo Cosa con textura aplicada"95 Figura B.6. Modelo 3D del enemigo Cosa sin textura"95 Figura B.7. Modelo 3D del objeto con las aristas marcadas en rojo"95 Figura B.8. Mapa UV en formato png importado con GIMP"96 Figura B.9. Textura creada a partir del mapa UV"97 9 En términos económicos la creación de videojuegos es una actividad que genera volumen de negocio y a grandes rasgos queda justificada su importancia. La importancia económica se explica con más detalle en el estudio de mercado incluido en el anexo A.1. Los videojuegos no son solo para jugar, también proporcionan puestos de trabajo. Por ejemplo en 2009 se crearon 32.000 puestos de trabajo como desarrollador de videojuegos en los Estados Unidos. El salario medio anual se encuentra entre los 52.00 y 60.000 dólares y el crecimiento en los últimos diez años ha sido del 32,4% en creación de puestos de trabajo. La opción laboral puede ser otra motivación para especializarse en el desarrollo de videojuegos. Desde el punto de vista del motor gráfico, Unity se encuentra entre el top 10 de los mejores motores usados por la industria de videojuegos. Es usado por importantes compañías como Coca-Cola, Electronic Arts, LEGO, Cartoon Network, Disney, Microsoft, Nasa, U.S. Army. Motor gráfico empleado por desarrolladores de videojuegos para móviles Figura 2. Motores gráficos empleados por los desarrolladores de videojuegos para móviles 16 En la figura 2 se puede observar la importancia de Unity como motor gráfico para el desarrollo de videojuegos dentro del sector de móviles ocupando la primera posición con el 53,1%1. En el anexo A.3 se justifica la importancia de Unity como motor gráfico. El desarrollo de este proyecto tiene como propósito general desarrollar una aplicación que introduzca al alumno en el mundo de la creación de videojuegos mediante el uso de un motor gráfico puntero cubriendo los aspectos fundamentales del mismo. Actualmente no existe ninguna aplicación de este tipo, y se pretende que gracias al impacto que tiene en la sociedad el mercado de los videojuegos sea el origen para la creación de aplicaciones interactivas de enseñanza en general y de videojuegos en particular. Por último añadir que el proyecto aparte de ser novedoso por sus características y por el potencial que posee es interesante desde el punto de vista de trabajo final de una carrera de Ingeniería en Informática. Supone un trabajo que implica la ingeniería del software, estructura de datos y algoritmos, diseño de aplicaciones móviles, análisis de interacción hombremáquina, servicios web, diseño de bases de datos, informática gráfica, expresión gráfica y redes móviles. 1.2. Objetivos y alcance El objetivo principal del proyecto es el de crear una aplicación para el sistema operativo iOS (iPad) que haciendo uso del motor gráfico Unity 3D permita impartir un curso completo de programación de videojuegos. El proyecto presenta otros objetivos secundarios: ‣ Formar al alumno en los aspectos fundamentales del manejo de Unity 3D. ‣ Mostrar el manejo de un motor gráfico. Los motores gráficos al igual que ocurre con otras aplicaciones presentan similitudes en su manejo y características. 1 Nota: el porcentaje total es superior al 100% eso es debido a que hay desarrolladores que emplean varios motores gráficos. 17 ‣ Guiar al alumno en el proceso de creación de un videojuego. ‣ Crear un Documento de Diseño del Juego (GDD) que sirva como ejemplo de documentación generada durante la creación de un videojuego. ‣ Motivar a los alumnos del curso a crear aplicaciones interactivas. ‣ Mostrar otras especialidades implicadas en el proceso de creación de videojuegos abriendo nuevas posibilidades de desarrollo para el alumno. Para el desarrollo de la aplicación se utilizará el propio entorno de Unity 3D, el IDE (Entorno de Desarrollo Integrado) MonoDevelop y como lenguajes de programación se emplearán UnityScript (variante de JavaScript) y C#. El desarrollo del proyecto se ha realizado en varias partes que se indican a continuación: La primera parte del proyecto consiste en la creación de la documentación escrita que cubre los aspectos fundamentales del curso. Junto a esta documentación escrita se han creado los vídeos de ejemplo que tienen relación con ella y muestran el resultado final de las explicaciones realizadas. Para complementar esta primera parte, se han creado las aplicaciones interactivas realizadas con Unity 3D. La segunda comprende la creación del videojuego de ejemplo completo y la documentación escrita que se corresponde con este. Esta documentación estaría formada por el GDD (Documento de Diseño del Juego) y por una descripción detallada del proceso de creación del videojuego. La tercera parte consiste en la creación de la aplicación web que interacciona con el juego completo. El videojuego realiza peticiones a la base de datos sobre los usuarios del juego para poder crearlos y posteriormente, si se desea, modificarlos. Una vez creado un usuario si se consigue una puntuación máxima (dentro del top 100) se registra en la base de datos y se muestra en la web, enviando posteriormente un mensaje al juego indicando la posición lograda en ese top 100. Por último la cuarta parte del proyecto es la creación del visor de documentos que permite también la reproducción de los vídeos y la ejecución de las aplicaciones interactivas y del videojuego completo. Es decir 18 aglutina todas las partes del proyecto a excepción de la aplicación web y permite reproducirlas o ejecutarlas sin salir de la aplicación. 1.3. Estudios preliminares Pese a realizar un PFC en el que se predefinen las características tecnológicas a nivel hardware (iPad) y software (Unity 3D y sus lenguajes asociados junto a Xcode y Objetive-C), en el anexo A se ha realizado un estudio que pone en relevancia la importancia de la industria de los videojuegos, el uso de dispositivo móviles y las características y razones por las que se ha elegido un iPad como dispositivo. Debido a su extensión y a que se han justificado parcialmente las razones anteriormente mencionadas en el apartado “Contexto y motivación” del presente documento, se remite al lector al anexo A redactado al final de la memoria. 1.4. Tecnología. Uso y justificación Aunque el proyecto verse sobre un curso de videojuegos con un motor y dispositivo determinados, para su realización se han utilizado diversos entornos y herramientas de trabajo. En este punto se detallan y justifican las tecnologías que han sido empleadas aunque habrá momentos en los que se remita al lector a los anexos en los que existen versiones más detalladas de estas o que han sido utilizadas pero resultan de menor entidad en la realización del proyecto y que se ha decidido no mencionar en este apartado. A continuación se va a ir indicando la tecnología empleada para cada una de las partes en las que se ha realizado el proyecto. Para la primera parte se han utilizado diversas herramientas, por ejemplo, para la creación de los textos del curso se han empleado: editores de texto como Pages, de presentaciones como Keynote y de imágenes como Gimp e Inkscape y hojas de cálculo como Numbers (ver anexo B). Los vídeos del curso se han creado utilizando ScreenFlow, aplicación para la grabación de la pantalla y edición de video. 19 Por último para la creación de las aplicaciones interactivas se ha hecho uso de Unity 3D (ver anexo D) como entorno de desarrollo, ya que permite integrar el proyecto en una única aplicación, realizar pruebas mientras se realiza el desarrollo y servir como ejemplo de creación de aplicación para el curso. Con Unity se ha modelado el entorno y creado los objetos necesarios para poblar las escenas de las aplicaciones. Para la programación del comportamiento de los objetos creados con Unity se ha hecho uso de los lenguajes de programación C# y UnityScript (variante de JavaScript) (ver anexo D). Para la segunda parte del proyecto se ha hecho uso de varias herramientas que pertenecen a distintas disciplinas, que forman parte de la creación de un videojuego y que han sido usadas en la creación del videojuego completo de ejemplo del curso. Para el modelado y animación de los personajes del juego y objetos del juego se ha empleado Blender (anexo C), por ser una herramienta de software libre que permite crear elementos del juego para ser usados directamente con Unity 3D. Otros motivos por los que se ha elegido Blender para el modelado de los objetos del juego es que existe gran cantidad de documentación en la red sobre modelado de objetos en 3D, por su facilidad de uso para crear objetos simples a partir de formas geométricas primitivas y por su integración con otras aplicaciones usadas en el proceso de creación de los elementos de un videojuego (como por ejemplo creación de mapas UV para ser utilizados con Gimp). La siguiente herramienta utilizada es Gimp, aplicación para la manipulación de imágenes, que como se comentó, fue usada en la primera parte. Con Gimp se han creado las texturas de los objetos en 3D a partir de los mapas UV generados con Blender. Algunos elementos usados en el juego han sido directamente creados con Unity 3D. Una vez creados se les ha aplicado una textura importada creada con Gimp y al igual que se hizo con los objetos en la primera parte del proyecto se programó con C# y UnityScript su comportamiento. Unity y UnityScript también se han empleado para crear todos los niveles (escenas) del juego, menús, control y lógica del juego y la comunicación exterior a través de la aplicación web de la tercera parte. Para las pruebas del videojuego se han empleado distintas herramientas, se ha usado Xcode y un iPad que ha permitido probar el juego en un dispositivo real. Otra herramienta muy útil ha sido Unity Remote, esta herramienta permite realizar pruebas de aplicaciones con el propio entorno Unity mientras se usa el dispositivo iOS como unidad controladora. Unity remote 20 desempeña su cometido haciendo una transmisión (streaming) del juego a la unidad iOS a través de una conexión Wifi, capturando la entrada de usuario desde la unidad iOS pasándola al entorno de Unity donde es tratada. Por último para la documentación de esta parte se han empleado las herramientas ya citadas de la primera parte. Para la tercera parte del proyecto se ha utilizado MySQL como gestor de la base de datos, ya que no se necesita una base de datos de gran tamaño, no está prevista una alta concurrencia en la modificación y en caso de darse un acceso masivo sería en lectura de datos (mostrar las puntuaciones), todo esto hace que MySQL sea el gestor idóneo. Para la aplicación web con contenido dinámico se han utilizado los lenguajes de programación PHP y JavaScript junto a la tecnología AJAX (anexo E). En las primeras fases de desarrollo se ha empleado el software MAMP (Mac Apache MySQL PHP) para la realizaciones de pruebas en un entorno local, ya que permite la gestión y control del servidor web y de la base de datos. También se ha empleado CSS para dar formato a la página de resultados, separando así, el contenido del diseño de las páginas. En la cuarta y última parte se ha creado el visor que permite unir entre sí las dos primeras partes, es decir, permitirá ver el contenido del curso (texto, vídeos y aplicaciones interactivas) y lanzar el videojuego. Para ello se ha empleado Unity 3D junto a UnityScript y Objetive-C. Por último para la creación de la aplicación a ser ejecutada en un iPad, se ha utilizado el entorno de programación Xcode, ya que es la única forma a través de la cual se puede realizar la instalación de la aplicación y poder realizar pruebas reales en un dispositivo iOS. 1.5. Ámbito del proyecto El ámbito de trabajo del proyecto reúne las siguientes características: ‣ El trabajo se ha realizado de forma remota utilizando un portátil Mac Book Pro con Mac OS X versión 10.8.3 como sistema operativo. ‣ Para las pruebas de la aplicación se ha empleado un iPad de tercera generación con sistema operativo OS X versión 6.1.3. 21 ‣ La mayor parte de las pruebas han sido de forma local, realizadas con el portátil indicado a excepción de las pruebas de comunicación que se han realizado con un servidor externo. ‣ Para los intercambios de ficheros, las revisiones de los textos, vídeos y aplicaciones se ha creado un repositorio de acceso común con el director del proyecto. ‣ Se han mantenido contactos constantes con el director del proyecto vía correo electrónico y mediante reuniones personales. 1.6. Metodología y planificación Se ha elegido como metodología de trabajo el modelo en cascada modificado (Figura 3) ya que es el que mejor se adapta a las necesidades del proyecto por su mayor flexibilidad respecto al modelo en cascada puro y a que permite desarrollar partes sencillas del proyecto sin esperar a terminar otras mas complicadas. Determinación de requisitos Análisis Diseño Implementación Pruebas Figura 3. Diagrama del modelo en cascada modificado En la figura 3 se muestra el diagrama del modelo en cascada modificado con sus cuatro fases de desarrollo. Como se observa en el diagrama desde cada una de las fases se puede volver a cualquiera de las anteriores. Antes de estas fases se ha realizado una captura de requisitos que debería tener el sistema. Estos requisitos pueden ser funcionales o no funcionales como se verán en el anexo F en el que se detalla esta fase. 22 Previo a comenzar con el desarrollo de las cuatro fases principales comentadas ha sido necesario realizar un aprendizaje sobre las herramientas, algunas tecnologías y algunos lenguajes de programación que han sido empleados en la realización del proyecto; se mencionarán en la bibliografía de la presente memoria. Este proceso de aprendizaje ha sido continuo debido al carácter multidisciplinar del proyecto. En cuanto a la planificación en el anexo F.3 se muestra la planificación inicial realizada antes de comenzar con el proyecto y la planificación real. 1.7. Estructura del documento El documento se divide en dos partes o bloques. El primer bloque es la memoria que consta de cuatro capítulos y el segundo bloque son los anexos que contienen nueve capítulos. ‣ Memoria. Parte principal del documento, está formado por los siguientes capítulos: - Capítulo 1 - Introducción: "Breve introducción al proyecto, contexto y razones por las que se ha "realizado, objetivos del mismo, estudios preliminares realizados, "tecnología empleada en su realización, ámbito, metodología empleada "y estructura del documento. - Capítulo 2 - Trabajo realizado: "Descripción del trabajo que se ha realizado durante todo el proyecto, "visión en detalle de cada una de las partes del mismo y su proceso de "desarrollo: visor, videojuego, aplicación web, vídeos y aplicaciones "interactivas. - Capítulo 3 - Conclusiones: "En este capítulo se expone el estado de consecución de objetivos, "cómo podría orientarse el desarrollo del mismo para futuras "ampliaciones y mejoras de la aplicación, perspectivas de futuro de la "misma y una valoración personal del proyecto. 23 ‣ Anexos. Información extendida de alguno de los capítulos de la memoria, consta de los siguientes anexos: - Anexo A - Estudios preliminares: "Estudios preliminares realizados sobre la situación de la industria de "los videojuegos, importancia de los dispositivos móviles en especial los "de Apple y la importancia del motor gráfico Unity 3D en el desarrollo de "videojuegos. - Anexo B - Tecnologías empleadas: "Resumen de las tecnologías empleadas para la elaboración del "proyecto. - Anexo C - Modelado de objetos con Blender: "Proceso de creación de los modelos con la herramienta Blender y "fichas empleadas para el modelado de los objetos 3D. - Anexo D - Unity 3D: "Descripción de los lenguajes empleados en el curso, aplicaciones "interactivas y creación del videojuego. - Anexo E - Tecnologías web empleadas: "Descripción de las tecnologías web usadas para la creación de la "aplicación web soporte del videojuego. - Anexo F - Documentación del proyecto: "Ampliación de la documentación surgida en el desarrollo del proyecto. - Anexo G - Manual de usuario: "Documento que contiene el manual de usuario para el uso del visor, "videojuego completo, vídeos y aplicaciones interactivas. - Anexo H - Documento de Diseño del Juego: "Ejemplo de documentos empleados durante el diseño del juego. - Anexo I - Ejemplo de capítulo del curso: "Capítulo de ejemplo del curso. 24 2. Trabajo realizado Este capítulo está dedicado a detallar todo el trabajo realizado a lo largo del Proyecto Fin de Carrera. Como se ha comentado anteriormente el proyecto parte de una idea innovadora del director, no hay aplicaciones en el mercado que sean un “todo en uno” (visor - documentación - vídeos - aplicaciones interactivas) en cuanto a formación en creación de videojuegos. Esta situación de partida permite un grado de libertad mayor frente a otro tipos de trabajos que forman parte de algún sistema ya realizado pero generan una carga de trabajo importante siendo necesario centrarse en los puntos fundamentales y desechar funcionalidades del sistema que no son primordiales. En el anexo F se encuentra la documentación de planificación del proyecto. El sistema creado se muestra en la figura siguiente: Figura 4. Visión general del sistema creado 25 "" " Figura 6. Diagrama de actividades del visor 32 2.1.6. Diseño de la interfaz A partir del análisis de requisitos y atendiendo a criterios de usabilidad se ha creado el diseño de la interfaz de usuario. Para el diseño de la interfaz se ha seguido el siguiente diagrama de navegación: Figura 7. Jerarquía de ventanas del visor En la figura 7 se observa la navegación que se permite en el visor de acuerdo al diseño comentado en el apartado anterior. Los gestos que se reconocen en la interfaz de usuario viene recogidos en el anexo G.2, en el que se describen con detalle todas las posibilidades de interacción que existen con el dispositivo. A continuación se mostrarán las capturas de pantalla de la aplicación en las que se pueden observar las características y el diseño de la interfaz de usuario. 33 Figura 8. Aspecto de la interfaz del curso con una página de texto cargada En esta pantalla (figura 8) se muestra el aspecto de la interfaz con una página del texto del curso cargada. Las interacciones permitidas con el usuario son: ‣ Pulsar en el lado derecho de la pantalla hará que se cargue la siguiente página del curso (si se llega a la última imagen, no se cargará ninguna página). ‣ Pulsar en el lado izquierdo de la pantalla hará que se cargue la página anterior (si se está en la primera página se cargará el índice de temas). ‣ Si se pulsa con dos dedos a la vez sobre la pantalla, se activa el zoom. Una vez activado el zoom, se permite el movimiento de la pantalla hasta alcanzar los límites de la hoja. Para desactivar el zoom, se pulsará de nuevo con dos dedos sobre la pantalla. 34 ‣ Otra interacción permitida es la de activar el menú de opciones, para ello se pulsará sobre la cinta de color rojo, al pulsarla se mostrará el menú de opciones de la imagen siguiente: Figura 9. Aspecto de la interfaz con el menú de opciones desplegado Como se puede observar, aparecen las opciones indicadas durante los apartados previos: ‣ Si se pulsa sobre ‘Ejemplos’, se cargará el índice con todos los vídeos del curso. ‣ Si se pulsa sobre ‘Índice’, se cargará el índice de temas. ‣ Al pulsar sobre ‘Ayuda’, se cargará la ayuda en la que se muestran instrucciones acerca del manejo de la aplicación. 35 ‣ Por último si se pulsa sobre ‘Vídeos’ se cargará el índice con todos los vídeos del curso. Este índice se puede observar en la imagen siguiente: Figura 10. Aspecto de la interfaz con el menú de vídeos cargado En la figura 10 se observa el índice de vídeos, pulsando sobre cualquiera de ellos se lanza el reproductor de vídeos (dentro de la aplicación) y se realiza la carga del video mediante streaming desde el servidor web donde se encuentran alojados. En el anexo G.2 existe documentación ampliada con ejemplos sobre la interfaz de usuario de la aplicación. 36 2.1.7. Implementación del visor Para la implementación del visor se ha empleado el patrón Modelo - Vista - Controlador (MVC). El patrón de diseño MVC adoptado se muestra en la siguiente figura: Figura 11. Diagrama del patrón de diseño Modelo - Vista - Controlador Este patrón es ampliamente empleado en la implementación de interfaces gráficas de usuario (GUI). Por ejemplo es el patrón típico con alguna variante mínima para programar todas las ventanas de una aplicación iOS programada en Xcode con Objetive-C. Atendiendo a este patrón (figura 11), cuando el usuario realiza alguna acción en la pantalla del dispositivo, como por ejemplo pulsar en la parte derecha de la pantalla, la vista envía la entrada de usuario al controlador, si el controlador determina que se debe realizar alguna modificación en el modelo, como por ejemplo es el caso, es decir, se debe pasar a la siguiente página, el controlador se comunica con el modelo para indicarle que debe actualizar los datos. Una vez que este actualiza los datos, el modelo se lo notifica a la vista, que solicitará el nuevo estado al modelo, tras esto el controlador dará la instrucción de carga a la vista actualizándose así la pantalla. El ejemplo que se acaba de describir se puede observar en el siguiente diagrama: 37 " Figura 12. Diagrama de secuencia del caso de uso avanzar página 2.2. Videojuego “La venganza de Timan” 2.2.1. Introducción El videojuego completo creado como ejemplo ha sido una de las partes que más tiempo ha consumido del desarrollo del PFC. Esto es debido a grandes rasgos a varios factores: estudio de las diferentes tecnologías necesarias para el desarrollo del videojuego, análisis y diseño del mismo, modelado y animación de los elementos del juego, programación del videojuego y pruebas. Se ha creado un juego en 3D de plataformas para iPad en el que el personaje principal interacciona con el jugador mediante pulsaciones en la pantalla. 2.2.2. Análisis y diseño Los requisitos fundamentales que se han planteado para el videojuego se listan a continuación (los requisitos se amplían en el anexo F.2). 38 Requisitos funcionales: ‣ El personaje se debe mover mediante pulsaciones por la pantalla. ‣ El personaje eliminará a los enemigos al caer encima de ellos, como ocurre en los juegos normales de plataformas. ‣ El personaje perderá una vida si entra en contacto con un enemigo por una parte que no sea la superior y también perderá una vida si se ve afectado por ciertos elementos. ‣ El juego debe tener dos niveles de dificultad. ‣ El juego debe tener tres niveles o escenas. ‣ El juego deberá tener otros elementos con los que interaccionar. ‣ El juego debe tener y gestionar un sistema de puntuaciones interno. ‣ El juego deberá almacenar máximas puntuaciones del usuario. ‣ El juego deberá mostrar estadísticas de las partidas. ‣ Se deberá mostrar una ayuda sobre la interfaz y el movimiento. ‣ El jugador podrá registrarse en el sistema. Sin registro no deberá haber acceso al juego. ‣ El juego permitirá cambiar los datos del jugador. ‣ Al terminar una partida, el juego deberá comunicar a una aplicación web la puntuación del jugador. ‣ Se deberá poder borrar todos los datos almacenados. ‣ Se permitirá volver al visor de la aplicación principal. Requisitos no funcionales: ‣ Al igual que ocurría con el visor, el videojuego debe ejecutarse en un iPad. 39 ‣ El juego debe tener alguna historia de fondo. ‣ Se deberá intentar crear ambientación adecuada para cada nivel del juego. ‣ La base de datos de las partidas debe usar el gestor MySQL. Tras determinar los requisitos más importantes se ha realizado el diagrama de casos de uso (anexo F.4.1) y el diagrama de flujo de datos (DFD) que se muestra en la figura 13. De esta forma se logra definir las entradas, procedimientos y salidas de la información del videojuego. También permite mostrar la interacción entre el videojuego y las entidades externas, en este caso el usuario. El resto de niveles del DFD se encuentran en el anexo F.4.2. En el DFD de la figura 13 se observa que el movimiento de datos se produce de la siguiente forma: ‣ El usuario proporciona al juego sus datos personales (Datos usuario). ‣ El juego muestra al usuario las estadísticas de todas las partidas jugadas (Estadísticas partidas). También se puede mostrar al usuario las máximas puntuaciones locales Máximas puntuaciones). Se ofrecen los datos de la partida actual (datos partida). Se pueden dar dos casos de error, uno debido a una incorrecta entrada de datos por parte del usuario (Error datos) y la otra porque el usuario ya exista en la base de datos al crear o modificar un usuario (Existe nombre). ‣ Validar usuario será lo que se envíe y retorne la base de datos al consultar la existencia de un usuario. ‣ Puntuación es la puntuación obtenida en la partida, se debe comprobar con la aplicación web si está dentro del top 100, si es un record se actualiza la base de datos de máximas puntuaciones. 40 " " Figura 13. Diagrama de flujo de datos de nivel 0 del juego En cuanto a las decisiones de diseño, existen gran cantidad de ellas que se han tenido que tomar, en este apartado se comentan las más importantes dejando el resto en el anexo F.4 para que el lector pueda consultarlas. Uno de los aspectos importantes a diseñar ha sido el de definir el almacenamiento de los datos del juego. Se ha hecho uso de la clase PlayerPrefs de Unity que permite almacenar información entre las sesiones de usuario y entre niveles o escenas (también se ha hecho uso de ficheros para almacenar datos entre niveles o cargar valores iniciales del juego). De esta forma se guardan de forma permanente y local todos los datos necesarios para el videojuego. Se explica su uso en el anexo F.4.3. En el momento de idear un juego se tienen que tener en cuenta cuatro aspectos fundamentales que se recogen en la figura 14. En la figura se muestran aspectos que van a ser decisivos a la hora de diseñar un juego. Al crear un videojuego este debe ser bonito, divertido, interesante y ‘jugable’ (término muy empleado en la comunidad de videojuegos para indicar que un videojuego se maneja de forma adecuada). Hay ciertos elementos que potencian estas características, por ejemplo la estética hará que el juego sea bonito, la mecánica que sea divertido, la historia que sea interesante y la tecnología que sea ‘jugable’. 41 Figura 23. Esquema del segundo nivel del videojuego Figura 24. Captura de pantalla real del segundo nivel del videojuego 48 Figura 25. Esquema del tercer nivel del videojuego 49 "" Figura 26. Captura de pantalla real del tercer nivel del videojuego 2.2.3. Modelado de objetos en 3D Es el proceso mediante el cual se han creado los modelos en 3D de los objetos que serán empleados en el juego. En los apartados previos se ha visto una pequeña muestra de los modelos realizados. El modelado de los objetos del juego, incluidos los personajes, se ha realizado casi por completo mediante el uso de Blender (ver anexo C). En la siguiente figura se presenta a ‘Timan’, el personaje principal del videojuego y el aspecto que presenta en el nivel 3, con sus alas negras. 50 """ Figura 27. Modelo del personaje principal para uno de los niveles del juego Los enemigos se han mostrado en la figura 16; corazones, cofres, estrellas y chekpoints se han mostrado en las figuras 18, 19 y 20. A continuación se muestran otras dos superficies mortales, la lava y el foso de pinchos: Figura 28. Modelo de lava con textura animada Figura 29. Modelo de foso con pinchos 51 En la figura 30, se muestra una imagen con ejemplos de las plataformas empleadas: Figura 30. Modelos de las plataformas empleadas en los tres niveles En el nivel tres se crean dinámicamente rayos durante la partida, el ejemplo de este modelo se muestra a continuación: """"" Figura 31. Modelo de rayo creado para el nivel 3 52 Otros elementos creados han servido para decorar y poblar las escenas, en la siguiente figura se muestra alguno de ellos: Figura 32. Modelos de objetos empleados como decoración de los niveles Un mayor ejemplo de los elementos creados, el proceso seguido para crearlos y las herramientas empleadas se muestra en el anexo I. 2.2.4. Implementación Para la implementación del juego se ha hecho necesario crear las clases de cada uno de los elementos mencionados en el diseño del juego. Por ejemplo para el personaje principal se han creado las de la siguiente figura: 53 Figura 33. Diagrama de las clases empleadas en el personaje principal del videojuego La clase principal es ‘LogicaPersonaje’, es la encargada de inicializar estructuras de datos para cada nivel, llevar un control de las vidas que se posee en cada momento y determinar en el nivel difícil si se ha llegado al final de partida (esto sucede cuando no quedan vidas), modificar la interfaz actualizando los datos que muestra, reproducir los efectos de sonido cuando se producen ciertos eventos, activar elementos del juego ocultos y cargar el siguiente nivel al terminal el actual. El movimiento del personaje está controlado por la clase ‘Move4_v2’. Esta clase se encarga de controlar la interacción del usuario con el dispositivo y determinar en función de ella qué hacer (mover el personaje, pararlo o saltar). Es la encargada de aplicar la fuerza de la gravedad al personaje después de realizar un salto. La clase que completa el movimiento del personaje es ‘EvitarCaidas’, esta clase lo que hace es evitar que el personaje caiga de superficies que están en movimiento. Otra clase que forma parte del personaje principal es ‘Lista de reproducción’, es la encargada de reproducir la música del juego en orden aleatorio creando ambientación en las partidas. La última clase ‘CreacionRayos’ forma parte del personaje en la última escena y es la encargada de generar rayos de forma aleatoria a lo largo del nivel. La relación entre los objetos del juego se puede ver con diagramas de secuencia como el siguiente: 54 " Figura 34. Diagrama de secuencia de la interacción entre enemigos y personaje principal En el diagrama se muestra la interacción entre el personaje principal y un enemigo, cuyo resultado es la muerte del enemigo. Este caso se produce cuando el personaje cae encima del enemigo, el enemigo detecta la colisión al recibir la llamada de la función OnTriggerEnter(), reacciona a ella enviando dos mensajes al personaje principal en los que se le indica que aumente el número de enemigos muertos y que actualice la interfaz y que a continuación emita un sonido relacionado con la muerte del enemigo. Por último el enemigo se destruye y se elimina de la escena liberando recursos. El resto de clases, su explicación y la interacción con el resto de elementos se encuentran en los anexos F.4.3 y F.4.4. Otro de los aspectos que es necesario implementar es el tratamientos de datos entre niveles y almacenamiento de la información. Esto se ha logrado gracias a la implementación de la clase ‘FinNivel’ que fijado a un objeto del juego permite determinar si el jugador ha alcanzado la zona de cambio de nivel y gestionar toda la información. Esta clase se explica en el anexo F.4.4. Por último comentar que en el anexo I se muestra el aspecto de cada uno de los niveles y otros aspectos de su creación, también se puede ver en formato vídeo en la dirección: http://ronroneos.com/PFC/Videos/t13v12.mp4 55 2.2.5. Interfaz Para explicar el diseño de la interfaz se pueden distinguir dos interfaces, una la de los menús que dan acceso a todas las partes del videojuego y la del propio videojuego. La interfaz de los menús se resume en el siguiente diagrama: Figura 35. Diagrama de navegación del menú principal Se ve como es necesario tener un usuario registrado para poder acceder al juego, si no existe se piden los datos para su creación. Se comprueba que no exista el nombre accediendo a la aplicación web, si no existe se crea el usuario y se accede al menú principal del juego. Desde el menú principal del juego se accede al resto de opciones. Para comenzar una partida, se deberá seleccionar antes la dificultad. El diagrama con la jerarquía de ventanas se muestra en el anexo F.4.5. En la figura 36 se muestra un ejemplo de la interfaz del menú principal: 56 Volver al curso Figura 36. Ejemplo de interfaz del menú principal El aspecto de la interfaz y las ventanas de los menús se muestran en los anexos G.3 e I. Una vez lanzada una partida, la interfaz del juego muestra el siguiente aspecto: 57 Figura 41. Captura de pantalla de resultados máximos ordenados por el total de estrellas En la figura 41 se muestra la ordenación de la tabla por el número de estrellas conseguidas. También se puede observar en la captura de pantalla de la figura 41 que las puntuaciones están agrupadas según el nivel de dificultad. En la imagen se muestra la dificultad nivel difícil pero pulsando sobre el botón “Ver normal” se muestran los datos para la dificultad normal. La tecnología AJAX se menciona en el E.1. 64 2.4. Resto de elementos de la aplicación En este apartado se comentará resumidamente el resto de elementos que forman parte de la aplicación. El hecho de englobarlos todos en un único apartado y mencionarlos resumidamente en esta parte de la memoria no debe restarles la importancia que se merecen, ya que el ponerlos en un mismo apartado es debido a la limitación en extensión de la memoria. La mayor parte de estos elementos se han ampliado en el anexo del PFC. 2.4.1. Textos del curso Los textos de los temas forman la parte fundamental de los conceptos que se desean explicar en el curso. Estos textos han sido preparados cuidadosamente por el autor del presente documento de forma que cumpliesen la característica de ser progresivos en cuanto a la enseñanza y dificultad, es decir, comenzar por los aspectos fundamentales de la programación de videojuegos y del motor gráfico hasta terminar con aspectos avanzados de la programación de los mismos. Se han incluido gran cantidad de ejemplos para ayudar a entender y asimilar las explicaciones de cada tema. Se ha revisado gran cantidad de documentación sobre programación de videojuegos con Unity 3D y de otras temáticas que no tenían relación directa con el curso para lograr una mejor explicación de los temas. En esta parte del trabajo se han invertido gran cantidad de horas para crear la documentación, adaptarla al formato del curso y darle el aspecto deseado para que la información ofrecida resultase sencilla de entender. El fundamento seguido para la creación de la documentación y de su explicación es que fuese lo más visual posible. Se han elaborado trece temas con un total de 1002 páginas a una resolución de 1024 x 768 pixeles. En el anexo I se ha incluido un ejemplo de capítulo del curso. 2.4.2. Vídeos Los vídeos del curso son ejemplos de aplicaciones creadas en Unity siguiendo las explicaciones de los temas. Estos ejemplos se han creado en 65 formato vídeo y no de aplicación debido a que a la altura del curso en el que han sido creados no era posible utilizarlos como aplicación (por ejemplo por la necesidad de usar un teclado físico) o porque mediante imágenes se conseguía explicar mejor ciertos aspectos del curso. En el anexo F.6 se describen los vídeos grabados para el curso. Estos vídeos como se ha comentado, han sido alojados en un servidor web, de forma que se puedan reproducir por streaming desde el reproductor de la aplicación. 2.4.3. Aplicaciones interactivas Por último se ha creado un conjunto de aplicaciones interactivas (aparte del juego) para ser ejecutadas durante la explicación de los temas. Se han creado con la intención de mostrar la capacidad de programación de videojuegos y de contenido multimedia de Unity 3D. Pretenden ser como se ha comentado en otros apartados un complemento a los textos y a los vídeos de ejemplo. No se ha abusado en cuanto al número de aplicaciones interactivas puesto que se quería dar la máxima importancia al ejemplo de videojuego completo, pero sí se quería mostrar sobre todo en los primeros temas la interactividad que se desea tenga el curso. Se van a comentar un par de aplicaciones interactivas del curso, en el anexo F.7 se indica el resto de ejemplos de aplicaciones interactivas creadas y sus objetivos. La primera aplicación interactiva que se va a mostrar (que es la primera que se muestra en el curso) es un ‘Hola Mundo’ en 3D. Con esta aplicación se muestra al alumno cómo crear un nuevo proyecto, crear una escena, añadir elementos a una escena, añadirles texturas creadas, posicionar la cámara, añadir iluminación a la escena, redimensionar y posicionar elementos, a programar un script, a asignar componentes a los objetos y a probar una aplicación haciendo uso del entorno y de un dispositivo iOS. Los resultados se muestran en la siguiente figura: 66 Figura 42. Hola Mundo 3D. Ejemplo de aplicación interactiva En la figura 42 se ve el resultado de la aplicación, gracias al script creado y asignado a la esfera que tiene asignada la textura del mundo, al ser ejecutada el mundo interacciona con el usuario. Cuando se gira el dispositivo, gira el mundo y al inclinarlo, se acerca o se aleja. También se ha añadido un botón que permite volver al curso. Otro ejemplo de aplicación interactiva se muestra en la figura 43. Esta aplicación es un ejemplo que recoge la creación de los distintos puntos de unión (joints) entre objetos. Esto permite crear un objeto que está formado por un conjunto de otros, que reaccionan como una única entidad. Para mostrar el efecto de creación de joints la aplicación permite aplicar fuerzas positivas o negativas en el eje X de la bola y del plano. Así el ejemplo aparte de mostrar los joints sirve de ejemplo de creación de física y de fuerzas sobre los objetos. 67 Figura 43. Ejemplo de aplicación de fuerzas sobre objetos 2.5. Pruebas En este punto de la memoria se analiza el proceso de pruebas llevado a cabo para la verificación y validación de todos los elementos del sistema. El objetivo principal es el de asegurar el cumplimiento de los objetivos fijados dentro del marco del PFC y asegurar el funcionamiento correcto de la aplicación en su conjunto. El plan de pruebas diseñado ha consistido en: ‣ Pruebas de caja blanca que se encarguen de realizar pruebas estructurales para la verificación del correcto funcionamiento. ‣ Pruebas de caja negra que verifique la entrada / salida de datos. 68 ‣ Pruebas de inspección de código basadas en los errores más comunes en la programación de aplicaciones informáticas. ‣ Se han realizado pruebas unitarias por cada parte principal del sistema por separado. ‣ Una vez realizadas las pruebas unitarias se han realizado pruebas de integración y de sistema para verificar el correcto funcionamiento del sistema en su conjunto. ‣ Por último se han realizado pruebas de aceptación utilizando la aplicación instalada en un dispositivo real. La descripción de las pruebas se muestran en el anexo F.5. 69 3. Conclusiones 3.1. Cumplimiento de objetivos El objetivo principal del proyecto era la creación de un curso de programación de videojuegos en Unity 3D para iPad. Para la consecución de este objetivo el proyecto se dividió en cuatro partes. La primera parte consistía en implementar un visor de documentos que presentase como característica de uso el reaccionar a interacciones del usuario con el dispositivo iOS. Estas interacciones consistían en navegar por el documento mediante pulsaciones en la pantalla, activar y desactivar el zoom, disponer de un menú de opciones que permitiese acceder a los índices del curso y a la ayuda, reproducir los vídeos de ejemplo, ejecutar las aplicaciones interactivas y el videojuego completo de ejemplo. Este visor actuaría como enlace entre todas las partes de la aplicación. La segunda parte consistía en un videojuego completo de ejemplo, que sirviese como ejemplo de aplicación de lo que se puede lograr con lo explicado en todos los temas escritos. Además debía de cumplir unos requisitos mínimos como: que tuviese tres niveles o escenas, que presentase dos niveles de dificultad, que el personaje respondiese a pulsaciones en la pantalla, que se almacenasen localmente datos de las partidas jugadas y que permitiese la creación de un usuario y posterior gestión de su información. También debía poder borrarse toda la información almacenada y sobre todo y fundamental se debía poder volver al visor de la primera parte. La tercera parte consistía en una aplicación web que debía guardar los datos de los usuarios creados en el videojuego así como crear un top 100 de las mejores partidas jugadas en dificultad normal y difícil. Esta aplicación serviría también para controlar la gestión de los usuarios e impedir que se crease un usuario ya existente en la base de datos. Esta parte serviría como ejemplo de interacción entre la aplicación (o una parte de ella) con el exterior. Además se debía poder consultar el top 100 por internet a través de una página web. La cuarta parte consistía en la creación de los ejemplos en vídeo y en formato de aplicación interactiva que complementarían las explicaciones del 70 curso. Y por último en esta cuarta parte también se crearía toda la documentación del curso que sería la base fundamental del mismo. Estos requisitos son de obligado cumplimiento para considerar el PFC como terminado, al cumplirse satisfactoriamente se puede concluir que el objetivo principal del proyecto ha sido alcanzado con éxito. 3.2. Mejoras y ampliaciones En cuanto a las mejoras, se podría realizar una implementación que fuese independiente de la resolución del dispositivo y que se adaptase a la resolución del dispositivo que tuviese cada usuario. Otra mejora podría ser la de lanzar el curso para un mayor número de plataformas destino, como Android y aplicación de escritorio (Windows, Mac, Linux). Pensando en futuros cursos y continuando con el presente curso realizado, se podría ampliar la aplicación introduciendo nuevos temas más avanzados. Esta característica se puede lograr sin muchas complicaciones debido al diseño modular realizado para la aplicación. Se podría reutilizar todo el código y con ligeras modificaciones se podría añadir nuevos temas, vídeos y aplicaciones interactivas. Otras ampliaciones podrían ser la de sacrificar la simplicidad de la interfaz introduciendo nuevas funcionalidades típicas de otros visores como por ejemplo el saltar a una determinada página de los documentos de texto. Otra ampliación podría ser la de introducir ejercicios que tuviese que realizar un alumno y que el sistema pudiese corregir y evaluar. Crear un sistema que simulase un buzón de preguntas que pudiese realizar el alumno al profesor directamente desde la aplicación. 3.3. Perspectivas de futuro del proyecto Las perspectivas de futuro del proyecto son amplias, la industria de los videojuegos mueve miles de millones al año, el sector demanda cada vez más especialistas en desarrollo de videojuegos y la introducción de la tecnología en forma de dispositivos móviles en la vida cotidiana de las 71 personas impulsa un consumo cada vez mayor de videojuegos. Esto hace que cada día haya más personas interesadas en formarse como desarrolladores de videojuegos. Estamos en una era en la que las personas demandan cada vez más formación e información gracias a la disponibilidad de la tecnología. El curso al estar realizado en formato aplicación puede tener una doble vertiente, una que sirva como medio a un profesor para la impartición de un curso y otra vía que sirva a un alumno como libro digital interactivo para seguir el curso o incluso autoformarse. La aplicación se podrá colgar para ser comprada en los mercados de aplicaciones por lo que satisfaría las necesidades recién comentadas. Además Unity comenzó una revolución dentro del sector gracias a la licencia gratuita de una de sus versiones, que permite desarrollar contenido a coste cero (respecto al motor gráfico). Gracias a su continua evolución y sus acuerdos comerciales Unity tiene cada día más peso dentro de la comunidad de desarrollo de videojuegos. Por todo esto el potencial de la aplicación es alto. 3.4. Valoración personal Dentro del mundo de los videojuegos mi experiencia había sido la de estar al otro lado de la ventana, es decir, la de ser una persona que disfrutase de la experiencia aportada por un videojuego. Durante los años de carrera, el contacto con el desarrollo de videojuegos había sido de pasada, inteligencia artificial, diseño gráfico, modelado visual y animación ... El desarrollo del proyecto me ha servido para afianzar y ampliar conocimientos adquiridos durante la carrera, lo cual valoro muy positivamente. También me ha introducido de lleno en el proceso de creación de un videojuego, tener en cuenta todas las fases que implica su desarrollo, experimentar con herramientas que desconocía y sobre todo valorar la complejidad y el esfuerzo que tiene desarrollar un buen juego. 72 A nivel laboral, debido a la creciente demanda dentro de la industria de los videojuegos, el proyecto me abre importantes posibilidades y no descarto el dedicarme en un futuro no muy lejano a su desarrollo. Con la realización de este proyecto mi visión del mundo de los videojuegos ha cambiado totalmente. He aprendido a valorar mucho más el trabajo que hay detrás de cada videojuego y puedo afirmar que me gusta mucho más formar parte del desarrollo de un videojuego que jugarlo. 73 ! Figura A.3. Ingresos por venta de videojuegos en los tres mercados más importantes (1010 dólares) de 2008 a 2017 En la figura A.4 se observa el tipo de consumos que se prevé realicen los consumidores hasta 2017. Se ve como el consumo preferente de los usuarios es el de consolas y se prevé que lo seguirá siendo hasta 2017. En 2017 los juegos en línea casi alcanzarán a las ventas de consolas, y es que este mercado se está convirtiendo poco a poco en uno de los más importantes. La mayoría de juegos, por no decir todos tienen un modo de juego en línea, eso es debido a que en general a los jugadores de videojuegos les gusta más interactuar con otras personas que solo con la máquina. El mercado de móviles también irá en aumento, debido principalmente al avance tecnológico de este tipo de dispositivos que permiten ejecutar aplicaciones cada vez más parecidas a las que se pueden encontrar en las consolas. Por último comentar que la venta de PC’s se mantendrá estancada, pero los consumidores no la abandonarán. 80 La tendencia general de los usuarios es de pasar de ‘pagar para poseer’ a ‘pagar por jugar’. " " Figura A.4. Gasto global de los usuarios por tipo de dispositivo (1010 dólares) de 2008 a 2017 En la figura A.5 se ve como las ventas en línea se incrementarán un 8% de media por año durante los cinco años próximos. Para 2017, las plataformas de juego en línea alcanzarán la paridad con la venta de consolas. Para 2017 se prevé que por cada 97 dólares que se gasten en juegos en línea se gastará 100 en consolas. 81 " " Figura A.5. Total de ingresos por juegos en línea (1010 dólares) y participación del total del segmento de videojuegos (%) de 2008 a 2017 Figura A.6. Ingresos totales (109 dólares) de la industria de los videojuegos en EE.UU. (2012) 82 En la figura A.6 se muestra un estudio de los ingresos de la industria de videojuegos en el que se compara el sector arcade3 de juegos (línea azul) respecto a consolas, PDA, PC, móviles y tabletas (línea roja). En línea verde se muestra el total de ingresos. Se puede ver la tendencia de consumo y uso de los usuarios. También se puede ver que el sector arcade estuvo dominando el mercado hasta 1992, a partir de ahí, con las nuevas tecnologías, aparición de PC y consolas y posteriormente móviles y tabletas, su uso ha caído sin acabar de desaparecer, estancándose en menos de 2.000 millones de dólares en 2012. Otros estudios realizados por la Asociación de Software del Entretenimiento (ESA) muestran los siguientes datos: ¿Quién juega videojuegos? ‣ El 58% de los americanos (EE.UU.) juegan a videojuegos. ‣ De media hay dos personas que juegan habitualmente a videojuegos en los hogares americanos (EE.UU.). ‣ De media, existe una consola, PC o smartphone dedicado a videojuegos. ‣ La edad media de los jugadores es de 30 años repartiéndose la edad de jugadores de la siguiente forma: 32% tiene menos de 18 años, 32% tiene entre 18-35 años y el 36% tiene más de 36 años. ‣ En cuanto al sexo de los jugadores, el 55% son hombres y el 45% mujeres. Las mujeres mayores de 18 años representan gran parte de la población que juega a videojuegos siendo el 31%. En cuanto a hombres, los menores de 17 años representan el 19% de la población jugadora. ¿Quién compra videojuegos y computadoras? ‣ La media de edad del comprador habitual es de 35 años. 3 Arcade es el término genérico de las máquinas recreativas de videojuegos disponibles en lugares públicos de diversión, centros comerciales, restaurantes, bares, o salones recreativos especializados. 83 ‣ De los compradores habituales, el 54% son hombres y el 46% mujeres. ¿Cómo se juega? ‣ En cuanto al tipo de juegos que se tienden a comprar en consolas, en la figura A.7 se observan los videojuegos por género que más se venden: Figura A.7. Videojuegos más vendidos por género en consolas en unidades (2012) Los tipos de juegos más vendidos son los de acción, seguidos cercanamente por los de disparos (shooter). Otro género que también se vende bastante es el de deportes. En un término medio de ventas se encuentran los de rol, carreras, aventuras y entretenimiento familiar. Entre los que generan menos interés se encuentran los ocasionales, arcades, los de entretenimiento de niños, vuelo, estrategia y lucha. En la siguiente figura, se muestra el mismo gráfico pero para los juegos de computadoras: 84 Figura A.8. Videojuegos más vendidos por género en computadoras en unidades (2012) En los videojuegos para computadoras cambian los gustos de los jugadores, el tipo de juegos más vendido es el de rol, seguido por los ocasionales y estrategia. Con un valor medio estarían los de aventura y de disparos. Y con menor interés el resto de tipo de juegos. A.2. Estudio de mercado de los dispositivos iOS En esta parte del estudio se trata de evaluar la importancia de los dispositivos iOS en el mercado actual. La comparación se realiza con los dispositivos Android siendo estos los competidores actuales. En la figura A.9 se observa la tendencia de ser iOS la plataforma que domina en cuanto a nuevos proyectos empezados, pasando de casi un 65% a principios de 2011 a mas del 70% pasado mediados de 2011. 85 Figura A.9. Distribución de nuevos proyectos en iOS Vs Android Otra comparación que se va a realizar es la de ver la relación entre el total de dispositivos activos iOS frente a los Android. Desde Apple y Samsung se han hecho oficiales los datos que confirman que Android gana la carrera en cuanto a dispositivos puestos en el mercado como se ve en la figura 10. Figura A.10. Dispositivos Android activos como porcentaje de dispositivos iOS La comparativa se hace a partir de 2009 ya que el primer dispositivo Android que salió al mercado fue en 2008. Desde 2009 hasta mediados de 2011 Apple ha dominado el mercado de dispositivos móviles, pero es a partir de esta fecha cuando pasa de manos el dominio del mercado de ventas y es 86 Android el que más dispositivos tiene en el mercado. Pese a que Android domina en dispositivos, Apple está cerca, considerándose el número de dispositivos iOS en mercado elevado. En la figura se muestra también el momento en el que se lanzaron al mercado los dispositivos. En la figura A.11 se muestra el tiempo pasado por los usuarios en aplicaciones Android respecto al tiempo pasado por los usuarios en las aplicaciones iOS. La comparación está hecha por dispositivo, ya que como se ha comentado en la figura anterior el total de dispositivos Android en el mercado es superior. Figura A.11. Total de tiempo pasado en aplicaciones por Android como porcentaje del total de tiempo en aplicaciones por iOS En la figura A.11 se observa que pese a que Android dispone de más dispositivos en el mercado, es iOS quien domina en tiempo empleado por usuario en un dispositivo. Aunque hay dos momentos en los que prácticamente se igualan, debido a la salida al mercado del iPad 2 y el iPad tercera generación iOS vuelve a distanciarse respecto de Android. 4 Fuente de los datos: Flurry Analytics. 87 Figura A.12. Países con el mayor número de dispositivos iOS y Android activos (millones) (2013) Por último en la figura A.12 se observa la distribución de países con más dispositivos iOS y Android activos en la que España está en el puesto doce. Dominando el mercado están EE.UU. y China. En Europa domina el Reino Unido, con un poco menos de la mitad que Reino Unido está Alemania y Francia. En cuanto a la importancia de los iPad como dispositivos iOS, en la figura A. 13 se muestran los millones de iPad vendidos desde el segundo cuarto de 2010 hasta el segundo cuarto de 2013. Notar que en 2013 se han vendido 57 millones de iPads. Las ventas por cuarto son oscilantes, pero una conclusión que se puede sacar de la tabla es que cada año el número de iPads vendidos se incrementa. En la tabla A.1, se hace una comparativa entre los iPad de Apple y tabletas de otras compañías. Apple pese a ver reducida las ventas respecto al segundo cuarto del año pasado, como se vio en la tabla anterior, se prevé que el total de ventas aumente. La tableta de Apple es sin duda la que más ventas registra con 14,6 millones en el tercer cuarto de 2013 con una cuota de mercado del 32% frente al rival más importante, Samsung, con 8,1 millones de ventas y una cuota de 88 mercado del 18%. Se observa que otras tabletas, como las de Samsung están teniendo un aumento considerable y puede que en un futuro sea una competidora para los iPad de Apple. """ Figura A.13. Millones de ventas de iPad (2010-2013) Otro dato importante que merece la pena comentar es el crecimiento anual de ventas de este tipo de dispositivos, aumentando casi un 60% en el global de ventas de tabletas. Vendedor 2ºQ2013 ventas 2ºQ2013 % Mercado 2ºQ2012 ventas 2ºQ2012 % Mercado Crecimiento anual Apple 14,6 32,4% 17,0 60,3% -14,1% Samsung 8,1 18,0% 2,1 7,6% 277,0% ASUS 2,0 4,5% 0,9 3,3% 120,3% Lenovo 1,5 3,3% 0,4 1,3% 313,9% Acer 1,4 3,1% 0,4 1,4% 247,9% Otros 17,5 38,8% 7,4 26,2% 136,6% Total 45,1 100,0% 28,3 100,0% 59,6% Tabla A.1. Millones de ventas de las tabletas de distintos fabricantes (2012-2013) 89 Con las aristas marcadas se crea el mapa UV en Blender, que se guardará en un formato adecuado, en el ejemplo en png. Una vez guardado se abrirá con GIMP, figura B.8. """ Figura B.8. Mapa UV en formato png importado con GIMP Tras importar el mapa UV con GIMP, se creará la textura deseada, para el ejemplo, se ha creado una textura de un monstruo con aspecto enfadado. Para ello se han utilizado distintas herramientas de GIMP así como texturas y colores ya creados. El aspecto que tiene la textura creada para el monstruo ‘Cosa’ se muestra en la figura B.9. 96 """ Figura B.9. Textura creada a partir del mapa UV Tras crearse, se importará a Blender y se aplicará la textura, mostrando el objeto 3D el aspecto final de la figura B.5. B.5. InkScape InkScape es un software libre para la edición de gráficos vectoriales. Su principal objetivo es el de dar total soporte a la implementación del formato estándar SVG (Scalable Vector Graphics). Las características principales son: ‣ Creación de objetos. ‣ Manipulación de objetos. 97 ‣ Decorar objetos. ‣ Operaciones sobre rutas. ‣ Soporte a la creación de texto. ‣ Renderizado. ‣ Importación / Exportación de imágenes. """"" Figura B.10. Logotipo de la aplicación InkScape InkScape se ha utilizado principalmente para la creación de los fondos de los niveles del juego y de otros elementos como las nubes que decoran la escena. En la figura B.11 se observa el fondo del nivel uno con las nubes, todo creado con InkScape. 98 Figura B.11. Imagen del primer nivel del videojuego. Fondo y nubes creados con InkScape 99 Anexo C Modelado de objetos con Blender Blender es un software libre para la creación de gráficos 3D para computadoras, usado para la creación de películas animadas, arte gráfico, modelos en 3D, aplicaciones interactivas en 3D y videojuegos. Entre las características de Blender se incluye el modelado en 3D, creación de un mapa UV a partir de un modelo en 3D, asignación de texturas a objetos, rigging y skinning1, simulación de humo y fluidos, simulación de partículas, animación, seguimiento de cámara, renderizado y edición de video entre otras. """"" Figura C.1. Logotipo de la aplicación Blender La mayor parte de objetos en 3D del videojuego completo se han creado utilizando Blender como herramienta. Para la creación de los modelos del personaje principal y algunos enemigos se ha seguido el proceso mostrado en la figura C.2: 1 Rigging es el proceso por el cual cuando al terminar el modelado de un objeto 3D se le crea un sistema de huesos para que pueda ser animado. 1 Skinning un modelo 3D es el proceso por el que la superficie visible del modelo es pintado y colocado sobre la malla del modelo. Es una parte del proceso de creación de un objeto que puede requerir gran cantidad de trabajo. 100 Figura C.2. Proceso de creación del personaje principal y de algunos enemigos En el anexo I (páginas 678 - 693) se muestra en detalle el ejemplo de la creación del modelo del personaje principal que sirve como ejemplo para cualquiera de los elementos del juego. Para cada modelo se recomienda hacer una plantilla como la que se muestra en la figura C.4. El modelo de plantilla se muestra en la figura C.3. El modelo es una recomendación de tipo de plantilla que muestra un boceto para cada elemento del juego. 101 " Figura C.3. Modelo de plantilla para la creación de los modelos de un videojuego " Figura C.4. Ejemplo de boceto de Timan 102 Anexo D Unity 3D El avance tecnológico tanto en computación como en la mejora de las comunicaciones junto al desarrollo de contenido en 3D multiplataforma ha abierto el camino al desarrollo de aplicaciones interactivas en 3D en una variedad de formas muy amplia, como educación, cultura, entrenamientos virtuales, turismo, comercio electrónico y videojuegos entre otras. Gracias a estos progresos, los videojuegos se están convirtiendo en algo común en la mayoría de entornos en los que nos desenvolvemos, por ello, el desarrollo de los mismos supone una actividad de gran importancia. Unity 3D es un motor gráfico multiplataforma (Mac OS X, Windows, Linux). Unity 3D se distribuye junto a un IDE (Entorno de Desarrollo Integrado) que permite desarrollar aplicaciones interactivas, animaciones en tiempo real y en 3D, visualizaciones y juegos. El destino de una aplicación desarrollada en Unity 3D puede ser múltiple, desde un navegador web, aplicaciones de escritorio (Mac, Windows, Linux), Flash, dispositivos móviles (iOS, Android) incluso consolas como PS3, Xbox 360 y Wii. Unity permite la creación de contenido 3D (especialmente videojuegos) de forma más rápida y sencilla que la mayoría de entornos existentes. Las aplicaciones desarrolladas con Unity se estructuran en escenas, cada escena puede ser cualquier parte de la aplicación. Los menús creados dentro de la aplicación, el área principal de la misma, etc ... son escenas dentro del entorno. El motor gráfico incluye también un editor de terrenos, en los que se pueden crear mapas con distintas alturas, utilizar distintas geometrías usando herramientas visuales, dotar a las escenas de distintas texturas y objetos (como arbustos, rocas, ...). También dispone de librerías que facilitan el uso de física en los objetos creados, uso de audio, control de colisiones, mensajes y eventos, incorporación de luces y mucho mas. 103 El motor gráfico Unity 3D ha provocado una revolución en el mundo del desarrollo de aplicaciones multimedia. En poco mas de cinco años de existencia ha ganado premios de revistas especializadas (Grand Prix Award). En la actualidad (principios de 2013) existen mas de 2 millones de desarrolladores que usan Unity, algunos tan importantes como Cartoon Network, Coca-Cola, Disney, Electronic Arts, LEGO, Microsoft, Nasa, U.S. Army, Warner Bros. También se ha hecho popular dentro de pequeños estudios, profesionales independientes, estudiantes y aficionados. D.1. UnityScript UnityScript no es JavaScript, es un lenguaje que presenta una similitud pero también tiene diferencias respecto a JavaScript. UnityScript es más rápido, eso es debido a que se compila, no como JavaScript que es interpretado. No hay diferencias de velocidad entre el uso de UnityScript, C# y Boo, todos lenguajes que se pueden usar para la programación en Unity. Hay otros pros y contras pero la velocidad no es uno de ellos. A continuación se indican las características más relevantes de UnityScript y C#. D.1.1. Generalidades D.1.1.1. Nombre El nombre JavaScript es un nombre genérico que se puede referir a cualquier implementación de la especificación ECMAScript. UnityScript es un lenguaje creado que no se ajusta a esa especificación y tampoco lo intenta. UnityScript es un lenguaje propietario y no sigue ninguna especificación concreta, es un lenguaje credo por los desarrolladores de Unity. UnityScript es más parecido a Microsoft JScript.NET que a JavaScript, aunque tampoco es idéntico. D.1.1.2. JavaScript se encuentra liberado del uso de clases JavaScript no tiene clases, esto es debido a que es un lenguaje basado en prototipos, la herencia ocurre entre objetos en vez de con clases. 104 UnityScript posee clases, una vez que se define una clase, esa clase existe durante la ejecución del programa. Un ejemplo de clase en UnityScript podría ser: D.1.1.3. Nombre del fichero como clase UnityScript intenta ahorrar tiempo en la escritura de código, para ello, la mayoría de ficheros representan simples clases, así automáticamente el nombre de un fichero es usado para definir una clase que el propio fichero se asume implementará. Así por ejemplo el siguiente fichero Enemigo.js: class Movimiento { !private var velocidad : int; // Variable privada !function Movimiento (x : int) { !!this.velocidad = x; !} !function MostrarVelocidad () { !!print(this.velocidad); !} } var c = new Movimiento (10); c.MostrarVelocidad(); function MostrarNombre () { !Debug.Log(“Vampiro”); } function void Wait () { !while () { !} } function Muerte () { !Application.Quit(); } 105 un entorno gestionado por un recolector de basura. Para ello se toman medidas del tipo: - Solo se admiten conversiones entre tipos compatibles. Esto es, entre un tipo y antecesores suyos, entre tipos para los que explícitamente se haya definido un operador de conversión, y entre un tipo y un tipo hijo suyo del que un objeto del primero almacenase una referencia del segundo (downcasting). - No se pueden usar variables no inicializadas. El compilador da a los campos un valor por defecto consistente en ponerlos a cero y controla mediante análisis del flujo de control del fuente que no se lea ninguna variable local sin que se le haya asignado previamente algún valor. - Se comprueba que todo acceso a los elementos de una tabla se realice con índices que se encuentren dentro del rango de la misma. - Se puede controlar la producción de desbordamientos en operaciones aritméticas, informándose de ello con una excepción cuando ocurra. Sin embargo, para conseguirse un mayor rendimiento en la aritmética estas comprobaciones no se hacen por defecto al operar con variables sino solo con constantes (se pueden detectar en tiempo de compilación) - A diferencia de Java, C# incluye delegados, que son similares a los punteros a funciones de C++ pero siguen un enfoque orientado a objetos, pueden almacenar referencias a varios métodos simultáneamente, y se comprueba que los métodos a los que apunten tengan parámetros y valor de retorno del tipo indicado al definirlos. - Pueden definirse métodos que admitan un número indefinido de parámetros de un cierto tipo, y a diferencia lenguajes como C/C++, en C# siempre se comprueba que los valores que se les pasen en cada llamada sean de los tipos apropiados. ‣ Instrucciones seguras: para evitar errores muy comunes, en C# se han impuesto una serie de restricciones en el uso de las instrucciones de control más comunes. Por ejemplo, la guarda de toda condición ha de ser una expresión condicional y no aritmética, con lo que se evitan errores por confusión del operador de igualdad (==) con el de asignación (=); y todo caso de un switch ha de terminar en un break o goto que indique cuál es la 112 siguiente acción a realizar, lo que evita la ejecución accidental de casos y facilita su reordenación. ‣ Sistema de tipos unificado: a diferencia de C++, en C# todos los tipos de datos que se definan siempre derivarán, aunque sea de manera implícita, de una clase base común llamada System.Object, por lo que dispondrán de todos los miembros definidos en esta clase (es decir, serán “objetos”). A diferencia de Java, en C# esto también es aplicable a los tipos de datos básicos. Además, para conseguir que ello no tenga una repercusión negativa en su nivel de rendimiento, se ha incluido un mecanismo transparente de boxing y unboxing con el que se consigue que solo sean tratados como objetos cuando la situación lo requiera, y mientras tanto puede aplicárseles optimizaciones específicas. El hecho de que todos los tipos del lenguaje deriven de una clase común facilita enormemente el diseño de colecciones genéricas que puedan almacenar objetos de cualquier tipo. ‣ Extensibilidad de tipos básicos: C# permite definir, a través de estructuras, tipos de datos para los que se apliquen las mismas optimizaciones que para los tipos de datos básicos. Es decir, que se puedan almacenar directamente en pila (luego su creación, destrucción y acceso serán más rápidos) y se asignen por valor y no por referencia. Para conseguir que lo último no tenga efectos negativos al pasar estructuras como parámetros de métodos, se da la posibilidad de pasar referencias a pila a través del modificador de parámetro ref. ‣ Extensibilidad de operadores: para facilitar la legibilidad del código y conseguir que los nuevos tipos de datos básicos que se definan a través de las estructuras estén al mismo nivel que los básicos predefinidos en el lenguaje, al igual que C++ y a diferencia de Java, C# permite redefinir el significado de la mayoría de los operadores (incluidos los de conversión, tanto para conversiones implícitas como explícitas) cuando se apliquen a diferentes tipos de objetos. ‣ Versionable: C# incluye una política de versionado que permite crear nuevas versiones de tipos sin temor a que la introducción de nuevos miembros provoquen errores difíciles de detectar en tipos hijos previamente desarrollados y ya extendidos con miembros de igual nombre a los recién introducidos. 113 ‣ Eficiente: en principio, en C# todo el código incluye numerosas restricciones para asegurar su seguridad y no permite el uso de punteros. Sin embargo, y a diferencia de Java, en C# es posible saltarse dichas restricciones manipulando objetos a través de punteros. Para ello basta marcar regiones de código como inseguras (modificador unsafe) y podrán usarse en ellas punteros de forma similar a cómo se hace en C++, lo que puede resultar vital para situaciones donde se necesite una eficiencia y velocidad de procesamiento muy grandes. ‣ Compatible: para facilitar la migración de programadores, C# no solo mantiene una sintaxis muy similar a C, C++ o Java que permite incluir directamente en código escrito en C# fragmentos de código escrito en estos lenguajes, sino también ofrece la posibilidad de acceder a código nativo escrito como funciones sueltas. 114 Anexo E Tecnologías web empleadas E.1. AJAX El término AJAX se presentó por primera vez en el artículo "Ajax: A New Approach to Web Applications" publicado por Jesse James Garrett el 18 de Febrero de 2005. Hasta ese momento, no existía un término normalizado que hiciera referencia a un nuevo tipo de aplicación web que estaba apareciendo. En realidad, el término AJAX es un acrónimo de Asynchronous JavaScript + XML, que se puede traducir como "JavaScript asíncrono + XML". Ajax no es una tecnología en sí mismo. En realidad, se trata de varias tecnologías independientes que se unen de formas nuevas y sorprendentes. """" Figura E.1. Logotipo de AJAX Las tecnologías que forman AJAX son: ‣ XHTML y CSS, para crear una presentación basada en estándares. ‣ DOM, para la interacción y manipulación dinámica de la presentación. ‣ XML, XSLT y JSON, para el intercambio y la manipulación de información. 115 ‣ XMLHttpRequest, para el intercambio asíncrono de información. ‣ JavaScript, para unir todas las demás tecnologías. """ Figura E.2. Tecnologías que forman parte de AJAX En las aplicaciones web tradicionales, las acciones del usuario en la página (pinchar en un botón, seleccionar un valor de una lista, etc.) desencadenan llamadas al servidor. Una vez procesada la petición del usuario, el servidor devuelve una nueva página HTML al navegador del usuario. Esta técnica tradicional para crear aplicaciones web funciona correctamente, pero no crea una buena sensación al usuario. Al realizar peticiones continuas al servidor, el usuario debe esperar a que se recargue la página con los cambios solicitados. Si la aplicación debe realizar peticiones continuas, su uso se convierte en algo molesto AJAX permite mejorar completamente la interacción del usuario con la aplicación, evitando las recargas constantes de la página, ya que el intercambio de información con el servidor se produce en un segundo plano. Las aplicaciones construidas con AJAX eliminan la recarga constante de páginas mediante la creación de un elemento intermedio entre el usuario y el servidor. La nueva capa intermedia de AJAX mejora la respuesta de la aplicación, ya que el usuario nunca se encuentra con una ventana del navegador vacía esperando la respuesta del servidor. Las peticiones HTTP al servidor se sustituyen por peticiones JavaScript que se realizan al elemento encargado de AJAX. Las peticiones más simples no requieren intervención del servidor, por lo que la respuesta es inmediata. Si la interacción requiere una respuesta del servidor, la petición se realiza de forma asíncrona mediante AJAX. En este caso, la interacción del usuario 116 tampoco se ve interrumpida por recargas de página o largas esperas por la respuesta del servidor. E.2. PHP PHP, acrónimo de "PHP: Hypertext Preprocessor", es un lenguaje de 'scripting' de propósito general y de código abierto que está especialmente pensado para el desarrollo web y que puede ser embebido en páginas HTML. Su sintaxis recurre a C, Java y Perl, y es fácil de aprender. La meta principal de este lenguaje es permitir a los desarrolladores web escribir dinámicamente y rápidamente páginas web generadas; aunque se puede hacer mucho más con PHP. """"" Figura E.3. Logotipo de MySQL El código de PHP está encerrado entre las etiquetas especiales de comienzo y final <?php y ?> que permiten entrar y salir del "modo PHP". Lo que distingue a PHP de otros lenguajes como Javascript es que el código es ejecutado en el servidor, generando HTML y enviándolo al cliente. El cliente recibirá el resultado de ejecutar el script, aunque no recibirá el código subyacente. El servidor web puede ser incluso configurado para que procese todos los ficheros HTML con PHP. Lo mejor de usar PHP es que es extremadamente simple para el principiante, pero a su vez ofrece muchas características avanzadas para los programadores profesionales. PHP está enfocado principalmente a la programación de scripts del lado del servidor, por lo que se puede hacer cualquier cosa que pueda hacer otro programa CGI, como recopilar datos de formularios, generar páginas con contenidos dinámicos, o enviar y recibir cookies. Aunque PHP puede hacer mucho más. 117 Existen principalmente tres campos principales donde se usan scripts de PHP. ‣ Scripts del lado del servidor. Este es el campo más tradicional y el foco principal. Se necesitan tres cosas para que esto funcione. El analizador de PHP (módulo CGI o servidor), un servidor web y un navegador web. ‣ Scripts desde la línea de comandos. Se puede crear un script de PHP y ejecutarlo sin necesidad de un servidor o navegador. Solamente es necesario el analizador de PHP para utilizarlo de esta manera. ‣ Escribir aplicaciones de escritorio. Probablemente PHP no sea el lenguaje más apropiado para crear aplicaciones de escritorio con una interfaz gráfica de usuario, pero si se conoce bien PHP, y se quisiera utilizar algunas características avanzadas de PHP en aplicaciones del lado del cliente, se puede utilizar PHP-GTK para escribir dichos programas. También es posible de esta manera escribir aplicaciones independientes de la plataforma. PHP-GTK es una extensión de PHP, no disponible en la distribución principal. PHP puede usarse en todos los principales sistemas operativos, incluyendo Linux, muchas variantes de Unix (incluyendo HP-UX, Solaris y OpenBSD), Microsoft Windows, Mac OS X, RISC OS y probablemente otros más. PHP admite la mayoría de servidores web de hoy en día, incluyendo Apache, IIS, y muchos otros. Con PHP, se tiene la posibilidad de utilizar programación por procedimientos o programación orientada a objetos (POO), o una mezcla de ambas. Con PHP no se está limitado a generar HTML. Entre las capacidades de PHP se incluyen la creación de imágenes, ficheros PDF e incluso películas Flash (usando libswf y Ming) generadas sobre la marcha. También se puede generar fácilmente cualquier tipo de texto, como XHTML y cualquier otro tipo de fichero XML. PHP puede autogenerar éstos ficheros y guardarlos en el sistema de ficheros en vez de imprimirlos en pantalla, creando una caché en el lado del servidor para contenido dinámico. Una de las características más potentes y destacables de PHP es su soporte para un amplio abanico de bases de datos. Escribir una página web con acceso a una base de datos es simple utilizando una de las extensiones 118 específicas de bases de datos o conectarse a cualquier base de datos que admita el estándar de Conexión Abierta a Bases de Datos por medio de la extensión ODBC. PHP también cuenta con soporte para comunicarse con otros servicios usando protocolos tales como LDAP, IMAP, SNMP, NNTP, POP3, HTTP, COM (en Windows) y muchos otros. También se pueden crear sockets de red puros e interactuar usando cualquier otro protocolo. PHP tiene soporte para el intercambio de datos complejos de WDDX entre virtualmente todos los lenguajes de programación web. Para la interconexión, PHP posee soporte para la instalación de objetos Java y usarlos de forma transparente como objetos de PHP. PHP tiene útiles características de procesamiento de texto, las cuales incluyen las expresiones regulares compatibles con Perl (PCRE), y muchas extensiones y herramientas para el acceso y análisis de documentos XML. PHP estandariza todas las extensiones XML sobre el fundamento sólido de libxml2, y amplía este conjunto de características añadiendo soporte para SimpleXML, XMLReader y XMLWriter. E.3. MySQL MySQL es un sistema de gestión de bases de datos relacional, multihilo y multiusuario. """" Figura E.4. Logotipo de MySQL MySQL es el mayor sistema gestor de bases de datos de código abierto SQL, es desarrollado, distribuido y mantenido por MySQL AB. MySQL AB es una compañía comercial, fundada por desarrolladores de MySQL. 1 Las características de PHP y MySQL se han obtenido del manual de referencia. 119 MySQL es una base de datos relacional y fue originalmente desarrollado para manejar grandes bases de datos mucho más rápido que con otras soluciones existentes y ha sido utilizada con éxito en muchos entornos de producción de alta demanda durante varios años. A pesar del constante desarrollo, el Servidor MySQL ofrece hoy en día una rica y útil serie de funciones. Su conectividad, velocidad y seguridad hacen del Servidor MySQL altamente apropiado para acceder a bases de datos en Intenet. MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor no transaccional MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia en la modificación. En aplicaciones web hay baja concurrencia en la modificación de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones. Parte de la popularidad de MySQL se debe también al hecho de que MySQL puede ser utilizada o modificada por cualquier persona o empresa sin ningún costo. El programa incorpora dos tipos de licencias: "1. La licencia GNU GPL: la cual permite a cualquier persona, empresa "o entidad usar el programa sin ninguna restricción. También se da la "libertad de modificar el producto y nuevamente redistribuirlo bajo la "misma licencia. Esta licencia se caracteriza por ser completamente "gratuita. "2. MySQL también incorpora una licencia comercial con la cual las "empresas pueden redistribuir el producto bajo sus propios términos. La "licencia sin embargo tiene un precio pero no es costosa comparada con "licencias de bases de datos comerciales como SQL Server de "Microsoft. Estos dos tipos de licencias se aplican tanto al servidor como a las interfaces y librerías clientes como el C client library, mysqladmin, MySQLCC, mysqldump, libmysqlclient, MySQL Connector/ODBC y J. Y no se aplican a la documentación producida por MySQL AB la cual está bajo la licencia de propiedad intelectual. 120 Anexo F Documentación del proyecto F.1. Estudio preliminar de visores Para poder determinar los requisitos de la aplicación, y en especial del visor se ha realizado un estudio preliminar de algunos visores existentes en el mercado de aplicaciones. La comparativa entre visores se ha realizado cargando un documento y una vez cargado se han hecho uso de las funciones disponibles. Los visores analizados han sido: Adobe Reader, GoodReader y Stanza, todos en su versión para iPad y se destacan las siguientes características detectadas: Adobe Reader: es el lector por excelencia de documentos en formato pdf. ‣ Zoom: si, con doble pulsación con un dedo se acerca y se aleja el documento. Se puede desplazar la pantalla una vez activado el zoom. ‣ Lectura: desplazando el dedo arriba y/o abajo y al revés se avanza y retrocede en el documento. También se puede avanzar y retroceder página desplazando el dedo de derecha a izquierda y viceversa o con pulsaciones en parte derecha o izquierda. ‣ Índice: no posee. Presenta la posibilidad de ir a una página concreta. ‣ Ayuda: no posee. Se descubre la funcionalidad entrando en cada opción de los menús. ‣ Interfaz: intuitiva, con pulsación en el centro se accede a las opciones del visor. En general fácil manejo. GoodReader: es un programa de propósito general, permite crear carpetas, renombrar documentos, permite cargar y descargar contenido del iPad y posee un visor de documentos al nivel de Adobe Reader. 121 Requisito Descripción RNF8 La web de puntuaciones se almacenará en el mismo servidor que la base de datos. RNF9 El videojuego completo se debe poder ejecutar en un iPad. RNF10 El videojuego debe tener alguna historia de fondo. RNF11 Se deberá intentar crear ambientación adecuada para cada nivel del juego. RNF12 Cada nivel del juego debe tener su propia historia dentro de la historia general. RNF13 Debe haber una variedad de enemigos en cuanto a aspecto externo. RNF14 Deben de existir animaciones distintas en el personaje principal y variedad de ellas en los enemigos. RNF15 Debe de existir variedad de sonidos para los efectos y para la música de ambiente. Tabla F.2. Requisitos no funcionales de la aplicación F.3. Planificación F.3.1. Planificación inicial La planificación del proyecto se realizó durante las primeras semanas de octubre de 2012. La planificación inicial se muestra en la siguiente tabla: Actividad Horas estimadas Porcentaje Aprendizaje 80 13,3 Análisis 60 10,0 Diseño 100 16,7 Implementación 200 33,3 128 Actividad Horas estimadas Porcentaje Pruebas 80 13,3 Documentación 80 13,3 Total 600 100 Tabla F.3. Planificación inicial La idea era la de programar una carga de trabajo de unas 100 horas de trabajo al mes, por lo que el proyecto debería durar unos 6 meses. Los meses se considerarían de 4 semanas, así por semana se trabajarían 25 horas. A la semana se trabajarían 5 días, por lo que la carga de trabajo al día debería ser de 5 horas. En la figura F.1 se muestra esta distribución en porcentaje. Figura F.1. Gráfica con el tiempo estimado en porcentaje 13,3% 10,0% 16,7% 33,3% 13,3% 13,3% Aprendizaje Análisis Diseño Implementación Pruebas Documentación 129 F.3.2. Planificación real A continuación se muestra la distribución real del tiempo empleado en cada una de las actividades y la representación gráfica en porcentaje: Actividad Horas reales Porcentaje Aprendizaje 140 17,5 Análisis 80 10,0 Diseño 120 15,0 Implementación 300 37,5 Pruebas 80 10,0 Documentación 80 10,0 Total 800 100 Tabla F.4. Tiempo real empleado Figura F.2. Gráfica con el tiempo real en porcentaje 17,5% 10,0% 15,0% 37,5% 10,0% 10,0% Aprendizaje Análisis Diseño Implementación Pruebas Documentación 130 Como se puede observar en las tablas F.3 y F.4, el tiempo real difiere del estimado en el tiempo destinado al aprendizaje, análisis, diseño e implementación. Los motivos de estas diferencias han sido: ‣ Comienzo del proyecto con la coincidencia de la llegada de las Fiestas del Pilar que motivaron un ligero retraso en el inicio del proyecto. ‣ En cuanto al aumento de tiempo de aprendizaje, análisis, diseño e implementación, se debió a la detección de nuevas necesidades y mejoras que hubo que analizar, diseñar, implementar y probar. Por ejemplo, se modificó el diseño de la interfaz porque la original presentaba demasiadas opciones que no aportaban una gran mejora y sí dificultaban la sencillez y la adaptación a su uso. "Otro cambio que se realizó fue el del aspecto del curso, se cambió la "paleta de colores empleada mejorando su visualización. También se "aumentó el tamaño de letra para que el curso se adaptase a una "presentación utilizando un cañón o directamente la visualización en un "iPad. "Mejora de las aplicaciones interactivas. "Se crearon nuevos temas y se ampliaron algunos para explicar la "creación del juego debido a un rediseño de escenarios, nuevos "modelos, funcionalidades del entorno, y ampliación de las opciones del "juego. "El trabajo se ha excedido también en horas debido a la novedad del "proyecto para el autor del mismo en algunos aspectos como el proceso "de modelado de objetos en 3D, creación y modificación de texturas, "creación de animaciones, en resumen, prácticamente el proceso "completo de creación de un videojuego en 3D desde cero. ‣ En el tiempo de implementación se ha incluido la creación de los textos (búsqueda de documentación, selección, adaptación al nivel del curso), la creación del visor, creación de los vídeos, creación de los ejemplos de los textos, creación de las aplicaciones interactivas y creación del videojuego completo. 131 """ Figura F.3a. Diagrama de Gantt del tiempo estimado y real del proyecto 132 """ Figura F.3b. Diagrama de Gantt del tiempo estimado y real del proyecto 133 En las figuras F.3a y F.3b se muestra mediante un diagrama de Gantt la distribución del tiempo estimado y real del proyecto. En el diagrama de Gantt con la planificación real se observa la parada durante las Fiestas del Pilar y de Navidad. También se observa que el proyecto comenzó en octubre de 2012 y finalizó en julio de 2013. F.4. Análisis y diseño del videojuego F.4.1. Casos de uso "" Figura F.4. Casos de uso del videojuego 134 En la figura F.4 se observan los casos de uso de un usuario del videojuego. Representan a un jugador interaccionando con el videojuego de distintas formas: ‣ Volviendo a la posición del curso donde se termina de explicar la realización del videojuego. ‣ Borrando todos los datos que hay en el juego, algo que provocará la solicitud de un nuevo usuario por parte del videojuego. ‣ Jugar una partida, en nivel normal o difícil. ‣ Consultar el top 5 de las mejores partidas en nivel normal y difícil. ‣ Consultar las estadísticas de todas las partidas jugadas por nivel. ‣ Ver los créditos del juego. ‣ Consultar la ayuda del juego. ‣ Gestionar los datos del usuario y modificarlos si se desea. F.4.2. Diagrama de flujo del videojuego "" Figura F.5. Diagrama de flujo de datos de nivel 0 del juego 135 Como se comentó en la memoria el DFD de la figura F.5 muestra los siguientes movimientos de datos: ‣ El usuario proporciona al juego sus datos personales (Datos usuario). ‣ El juego muestra al usuario las estadísticas de todas las partidas jugadas (Estadísticas partidas). También se puede mostrar al usuario las máximas puntuaciones locales Máximas puntuaciones). Se ofrecen los datos de la partida actual (datos partida). Se pueden dar dos casos de error, uno debido a una incorrecta entrada de datos por parte del usuario (Error datos) y la otra porque el usuario ya exista en la base de datos al crear o modificar un usuario (Existe nombre). ‣ Validar usuario será lo que se envíe y retorne la base de datos al consultar la existencia de un usuario. ‣ Puntuación es la puntuación obtenida en la partida, se debe comprobar con la aplicación web si está dentro del top 100, si es un record se actualiza la base de datos de máximas puntuaciones. En la figura F.6 se muestran todos los procesos que describen el proceso principal: ‣ ‘Tratar usuario’ es el proceso encargado de validar la entrada del usuario y de comprobar que este no existe en el sistema. ‣ ‘Jugar partida’ es el proceso que se encarga de gestionar todos los datos de la partida actual. Al terminar una partida se almacenan los datos estadísticos correspondientes y se comprueba que la puntuación sea un record local y del top 100, si es un record local se almacenan los datos localmente y si es un record del top 100, se almacenan los datos en la base de datos. ‣ El proceso ‘Mostrar información’ es el encargado de recoger los datos estadísticos y del top 5 de partidas y mostrarlos de forma adecuada al usuario. 136 Figura F.6. Diagrama de flujo de datos de nivel 1 del juego En la figura F.7 se muestra el diagrama de flujo de datos de nivel 2 para el proceso ‘Tratar usuario’, este proceso se descompone en dos: ‣ Procesar entrada: lo que hace es validar la entrada del usuario y eliminar entradas erróneas. ‣ Actualizar usuario: una vez validada una entrada se comprueba si el usuario introducido existe en la base de datos, si no existe se crea localmente y en la base de datos, si existe el nombre se indica al usuario. 137 "Método principal: - OnTriggerEnter(): al producirse la colisión lateral, se le indica al personaje que pierde una vida y que emita el sonido de contacto con el enemigo. Los diagramas de secuencia de las figura F.15 y F.16 describen la interacción entre el personaje principal y los enemigos. Plataformas: Como se observa en la figura F.12, las plataformas que se han usado en el videojuego pueden ser de varios tipos, las simples que son plataformas fijas, plataformas con desplazamiento lateral, plataformas giratorias y cajas de cartón. Figura F.12. Diagrama de clases de las plataformas A continuación se van a comentar las características principales de la clase: ‣ ActivacionCaja: detecta la entrada del personaje principal y provoca su desaparición tras 2 segundos. 144 ‣ Rotacion: realiza el giro a una determinada velocidad del objeto en 3D. ‣ Desplazamiento: realiza el movimiento de la plataforma desde una posición origen a otra destino. Estas posiciones son variables que guardan una referencia a las posiciones. También posee una variable velocidad que determina la velocidad de desplazamiento y una variable cambio que indica cuando debe de producirse el giro. Superficies mortales: Las superficies mortales se muestran en la figura F.13, se puede observar que existen dos tipos de superficies, fijas y con desplazamiento. Ambas comparten una clase LogicaEnemigos que ya se ha descrito en los enemigos. Las plataformas con desplazamiento poseen otras clases que son: Desplazamiento (también comentada), MuertePorLava y TexturaAnimada. " Figura F.13. Diagrama de clases de las superficies mortales ‣ MuertePorLava: provoca la pérdida de una vida al producirse el desplazamiento de la superficie mortal. Se muestra el diagrama de secuencia de esta clase en el siguiente apartado, figura F.17. 145 ‣ Textura animada: desplaza la textura asignada al objeto para dar la sensación de movimiento. PlayerPrefs: Esta clase se comentó que se ha utilizado para almacenar datos entre sesiones o niveles del juego. La clase PlayerPrefs se utiliza para almacenar y recuperar las preferencias de usuario, tiene los siguientes métodos: - Métodos de creación de claves: " " " PlayerPrefs.SetInt(): almacena una clave entera asociada a un " " nombre determinado. " " PlayerPrefs.SetFloat(): almacena una clave real asociada a un " " nombre determinado. " " PlayerPrefs.SetString(): almacena una clave de tipo cadena " " asociada a un nombre determinado. - Métodos de lectura de claves: " " PlayerPrefs.GetInt(): devuelve el entero guardado con el nombre " " indicado. " " PlayerPrefs.GetFloat(): devuelve el real guardado con el nombre " " indicado. " " PlayerPrefs.GetString(): devuelve una cadena guardada con el " " nombre indicado. - Método de consulta de claves: " " PlayerPrefs.HasKey(): devuelve true si existe la clave con el " " nombre proporcionado. - Método de escritura en disco de todas las claves creadas: " " PlayerPrefs.Save(): método que guarda en disco todas las " " preferencias de usuario creadas o modificadas. 146 - Método de borrado de claves: PlayerPrefs.DeleteKey(): borra la clave con el nombre proporcionado. " " PlayerPrefs.DeleteAll(): borra todas las claves almacenadas en " " disco. En el siguiente apartado mediante diagramas de secuencia se describen los objetos restantes y su comportamiento. F.4.4. Modelado dinámico En la figura F.14 se muestra el diagrama de estados que explica el movimiento del personaje principal. 147 Figura F.14. Diagrama de estados del movimiento del personaje En el diagrama se observa que el estado inicial del personaje es el de ‘Parada’. En todos los estados se ejecuta una animación mientras se esté en ese estado. Si se pulsa a la derecha del personaje, se cambia de estado y se pasa al estado ‘Mover derecha’ que provoca que el personaje se desplace hacia la derecha hasta que se detecte una nueva interacción y se cambie de estado. Si se pulsa a la izquierda del personaje este cambiará de dirección si no se encontraba en el estado ‘Mover izquierda’ y desplazará al personaje hacia la izquierda. Desde cualquiera de los estados anteriores, si se pulsa con dos dedos sobre la pantalla, se cambiará al estado ‘Salto’, al terminar se volverá al estado del que se partía. Desde el estado ‘Salto’ se puede ir también al estado ‘Salto doble’ que provoca un nuevo salto del personaje en el aire, una vez terminado se volverá al estado previo a los saltos. Solo es 148 posible dar un salto doble si ya se estaba en el aire. Por último comentar que desde cualquier estado se puede producir la muerte del personaje que se muestra en el diagrama como la salida del mismo. Al producirse la muerte del personaje, se sigue almacenando la dirección, por lo que si se estaba desplazando hacia la derecha o izquierda, al volver a aparecer el personaje este se seguirá desplazando en esa dirección. En el diagrama por simplicidad se muestra el movimiento del personaje al comienzo de la partida, pero al morir se empezará en el último estado en el que se encontraba. El siguiente diagrama que se muestra es el de interacción entre el personaje principal y un enemigo provocando la muerte de este último. " Figura F.15. Diagrama de secuencia de la interacción entre enemigos y personaje principal que provoca la muerte de un enemigo Al alcanzar por la parte superior al enemigo, se activa la función OnTriggerEnter() que hace que el enemigo envíe al personaje dos mensajes, enemigosMuertos() que aumenta en uno el número de enemigos muertos y reproducirSonido() que provoca un efecto de sonido asociado a la muerte del enemigo. Tras estos dos mensajes se elimina al enemigo de la partida. 149 " Figura F.16. Diagrama de secuencia de la interacción entre enemigos y personaje principal que provoca la pérdida de una vida del personaje En la figura F.16 se muestra la otra interacción posible entre el personaje principal y un enemigo. Si se produce un contacto lateral, el enemigo envía el mensaje perderVida() al personaje principal que le provoca la pérdida de una vida, a continuación se indica al personaje que reproduzca el sonido relacionado con el evento de pérdida de una vida. Este mismo diagrama explica la situación por la que el personaje toca una superficie mortal provocando los mismos efectos que los que se acaban de describir para el enemigo. En la figura F.17 se describe la situación por la que una superficie mortal alcanza en su desplazamiento al personaje principal, si se da esa situación, se envía el mensaje de perder una vida al personaje y la de la reproducción del sonido asociado al evento. 150 "" Figura F.17. Diagrama de secuencia que describe la situación provocada por la entrada en contacto de una superficie mortal en su desplazamiento con el personaje principal Otro tipo de interacción con objetos del juego son los que se van a mostrar a continuación, son objetos que al pasar por encima de ellos se eliminan de la partida y producen el incremento de la puntuación (figura F.18, cofres y estrellas), recuperación de vidas (figura F.19, corazones) o punto de guardado (figura F.20, checkpoint). " Figura F.18. Diagrama de secuencia que describe la interacción entre el personaje y una estrella 151 En el diagrama F.18 se muestra qué ocurre al pasar por encima de una estrella. Si el personaje entra en contacto con la estrella, se le envía el mensaje de aumentar el total de estrellas, a continuación el de reproducir el sonido que simula la recogida de la estrella y por último se destruye la estrella. " Figura F.19. Diagrama de secuencia que describe la interacción entre el personaje y corazón que recupera una vida del personaje De forma similar, en la figura F.19, el personaje al entrar en contacto con un corazón provoca que este le envíe los mensajes de aumentar el número de vidas, mostrar una vida más en la interfaz del juego y reproducir el sonido de recogida de una vida. Después del envío de los mensajes, el corazón se destruye. 152 " Figura F.20. Diagrama de secuencia que describe la interacción entre el personaje y un punto de guardado En la figura F.20 se muestra la interacción entre el personaje y un punto de guardado (checkpoint). Al activar el checkpoint, este manda al personaje los mensajes de actualizar su posición de guardado a la del checkpoint, la altura del checkpoint (para que no atraviese el suelo) y la de reproducir el sonido de activación del checkpoint. Una vez enviados los mensajes, el checkpoint desaparece. Por último y para terminar con este apartado se mostrará el diagrama de actividades que modela el comportamiento de la clase FinNivel: 153