Generación procedural de niveles en un videojuego de plataformas

Generaci´ on procedural de niveles en un videojuego de plataformas Raso V´ azquez, Ander Tutor: Villama˜ ne Giron´ es, Mikel 25 de julio de 2021 Resumen En el mundo del desarrollo de videojuegos la generaci´ on procedural de contenido es una t´ ecnica que se usa tanto para ahorrar trabajo en la creaci´ on de niveles como para aumentar la rejugabilidad. Es com´ un verla utilizada por estudios de desarrollo independientes para ahorrar tiempo y dinero en los dise˜ nos de niveles. En este proyecto se van a estudiar t´ ecnicas de generaci´ on procedural para crear un juego de plataformas en el que cada partida ser´ a diferente de la anterior. El jugador se mover´ a por tres niveles llenos de enemigos y recursos que obtener. Podr´ a combinar los objetos obtenidos para crear equipamiento m´ as potente y lo usar´ a para vencer al jefe final en el nivel 4. Abstract In the world of video game development, procedural content generation is a technique used to save work effort on level creation and to increase replayability. It is common to see it used by independent development studios in order to save time and money on level designs. In this project, procedural generation techniques will be studied to create a platform game where each playthrough will be different from the previous one. The player will move through three levels full of enemies and resources to obtain. He will be able to combine the items obtained to create i more powerful equipment and use it to defeat the final boss at level 4. Laburpena Bideo-jokoen garapenaren munduan, edukia prozedurala sortzea lana aurrezteko eta berriro jokatzea dibertigarriago izateko erabiltzen den teknika bat da. Ohikoa da garapen-estudio independenteek erabiltzea, mundu diseinuetan denbora eta dirua aurrezteko. Proiektu honetan, eduki prozedurala sortzeko teknikak aztertuko dira, plataforma-joko bat sortzeko, non partida bakoitza aurrekoaren desberdina izango den. Aurkariz eta baliabidez betetako hiru mundutan mugituko da jokalaria. Lortutako objektuak konbinatu ahal izango ditu ekipamendu indartsuagoa sortzeko, eta 4. munduko azken burua garaitzeko erabiliko du. ii ´ Indice general 1. Introducci´on 1 1.1. Origen del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Motivaciones para la elecci´ on del proyecto . . . . . . . . . . . . 2 1.3. Situaci´ ondeltrabajo........................ 2 2. Planteamiento inicial 3 2.1. Objetivos.............................. 3 2.2. Alcance............................... 4 2.2.1. Diagrama de la estructura de la descomposici´ on del trabajo 5 2.2.2. Descripci´ ondelastareas.................. 6 2.3. Planificaci´ ontemporal....................... 34 2.4. Gesti´ onderiesgos ......................... 36 2.4.1. Plan de seguimiento de riesgos . . . . . . . . . . . . . . 45 2.5. Evaluaci´ on econ´ omica ....................... 47 2.5.1. Recuperaci´ on de la inversi´ on................ 47 3. Antecedentes 49 iii ´ INDICE GENERAL ´ INDICE GENERAL 3.1. Situaci´ onActual .......................... 49 3.2. Decidir el motor de desarrollo . . . . . . . . . . . . . . . . . . . 50 3.2.1. Unity............................ 51 3.2.2. UnrealEngine ....................... 51 3.2.3. Godot ........................... 52 3.2.4. Decisi´ on .......................... 53 3.3. Generaci´ on procedural de contenido . . . . . . . . . . . . . . . . 53 3.3.1. Perlinnoise......................... 53 3.3.2. Plantillas.......................... 56 3.3.3. Decisi´ on .......................... 58 4. Captura de requisitos 59 4.1. Jerarqu´ ıadeactores ........................ 59 4.2. Diagramas de casos de uso . . . . . . . . . . . . . . . . . . . . 59 4.2.1. Casos de uso no relacionados al movimiento del personaje 60 4.2.2. Casos de uso relacionados al movimiento del personaje . . 61 5. An´alisis y dise˜no 63 5.1. PT1. Creaci´ ondeniveles...................... 63 5.2. PT2. Elementos interactuables . . . . . . . . . . . . . . . . . . 66 5.3. PT3. Implementaci´ on de interfaces . . . . . . . . . . . . . . . . 68 5.4. PT4. Objetos utilizables . . . . . . . . . . . . . . . . . . . . . . 69 5.5. PT5. Creaci´ ondeenemigos .................... 70 5.5.1. Herencia VS Composici´ on................. 72 iv ´ INDICE GENERAL ´ INDICE GENERAL 5.5.2. Soluci´ onfinal........................ 73 6. Desarrollo 74 6.1. Inicio del proyecto: Arte del juego . . . . . . . . . . . . . . . . . 74 6.1.1. Entorno .......................... 76 6.2. PT1. Creaci´ ondeniveles...................... 77 6.2.1. Ejemplos de niveles . . . . . . . . . . . . . . . . . . . . 78 6.2.2. C´ omo elegir el componente randomizado . . . . . . . . . 79 6.2.3. Problemas ......................... 80 6.3. PT2. Elementos interactuables . . . . . . . . . . . . . . . . . . 81 6.4. PT3. Implementaci´ on de interfaces . . . . . . . . . . . . . . . . 82 6.4.1. Problemas con la creaci´ on de objetos . . . . . . . . . . . 83 6.5. PT4. Objetos utilizables . . . . . . . . . . . . . . . . . . . . . . 86 6.6. PT5. Creaci´ ondeenemigos .................... 89 6.6.1. Comportamiento de los enemigos . . . . . . . . . . . . . 89 6.6.2. Implementaci´ on ...................... 90 6.6.3. Ejemplo del funcionamiento de un componente . . . . . . 93 7. Verificaci´on y evaluaci´on 94 7.1. Elementos notables . . . . . . . . . . . . . . . . . . . . . . . . 98 8. Conclusiones y trabajo futuro 99 8.1. Objetivos.............................. 99 8.1.1. Im´ agenes del juego terminado . . . . . . . . . . . . . . . 100 v ´ INDICE GENERAL ´ INDICE GENERAL 8.2. Gesti´ onderiesgos .........................101 8.3. Revisi´ on de la estimaci´ oninicial..................103 8.3.1. Fecha de finalizaci´ on....................105 8.4. Trabajofuturo ...........................105 A. Manuales 107 A.1.Controles..............................107 A.2. Ordenar inventario de objetos . . . . . . . . . . . . . . . . . . . 108 A.3.Combinaciones...........................108 A.3.1. C´ omo combinar objetos . . . . . . . . . . . . . . . . . . 108 Bibliograf´ıa 109 vi ´ Indice de figuras 2.1. EDT ................................ 5 2.2. DiagramadeGantt......................... 35 3.1. Imagen del prototipo inicial. . . . . . . . . . . . . . . . . . . . . 49 3.2. LogotipodeUnity.......................... 51 3.3. Logotipo de Unreal Engine. . . . . . . . . . . . . . . . . . . . . 51 3.4. Logotipo de Godot Engine. . . . . . . . . . . . . . . . . . . . . 52 3.5. Representaci´ on del ruido Perlin. . . . . . . . . . . . . . . . . . . 54 3.6. Monta˜ nasenMinecraft....................... 55 3.7. Cuevas en Terraria. . . . . . . . . . . . . . . . . . . . . . . . . 56 3.8. Conexi´ on de salas en Spelunky. . . . . . . . . . . . . . . . . . . 57 3.9. Cuevas en Caveblazers. . . . . . . . . . . . . . . . . . . . . . . 58 4.1. Casos de uso parte 1. . . . . . . . . . . . . . . . . . . . . . . . 60 4.2. Casos de uso parte 2. . . . . . . . . . . . . . . . . . . . . . . . 61 5.1. PT1. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . 64 5.2. PT1. Diagrama de secuencia de la creaci´ on del nivel. . . . . . . . 65 vii ´ INDICE DE FIGURAS ´ INDICE DE FIGURAS 5.3. PT2. Diagrama de clases. . . . . . . . . . . . . . . . . . . . . . 66 5.4. PT2. Diagrama de secuencia de la activaci´ on de los objetos interactuables............................. 67 5.5. PT3. Diagrama de clases que tienen que ver con el inventario. . . 68 5.6. PT4. Diagrama de clases para utilizar objetos. . . . . . . . . . . 69 5.7. PT4. Diagrama de secuencia de activaci´ on de un objeto al hacer clickderecho............................. 70 5.8. PT5. Diagrama inicial de clases de enemigos. . . . . . . . . . . . 71 6.1. Dibujo del personaje jugable. . . . . . . . . . . . . . . . . . . . 75 6.2. Ejemplo de una animaci´ on utilizando las capas que se han exportadodelaimagen.......................... 75 6.3. Dibujos de los enemigos ordenados por niveles en los que aparecen. Nivel 1 (skeleton, moth), nivel 2 (slime, slime fast), nivel 3 (goblin, goblin mage), nivel 4 (ogre). . . . . . . . . . . . . . . . 76 6.4. Ejemplo de uso de un Tileset. . . . . . . . . . . . . . . . . . . . 77 6.5. Nivel 1: Bosque verde. . . . . . . . . . . . . . . . . . . . . . . . 78 6.6. Nivel 2: Bosque de champi˜ nones. ................. 79 6.7. Nivel 3: Castillo. . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.8. Nivel 4: Batalla final . . . . . . . . . . . . . . . . . . . . . . . . 79 6.9. Objetos interactuables. . . . . . . . . . . . . . . . . . . . . . . . 81 6.10. Men´ udepausa. .......................... 83 6.11. Antigua interfaz de creaci´ on de objetos. . . . . . . . . . . . . . . 84 6.12. Interfaz del jugador durante el nivel cuando pulsa la tecla TAB . . 85 6.13. Objetos que pueden usarse en el juego. . . . . . . . . . . . . . . 87 viii Cap´ıtulo 2 Planteamiento inicial 2.1. Objetivos El objetivo principal de este proyecto es crear un videojuego en el que cada partida sea diferente de la anterior. Para lograrlo, los niveles se generar´ an proceduralmente. Esto quiere decir que en cada partida nueva la estructura del nivel, la localizaci´ on de los recursos y los enemigos ser´ a aleatoria, pero seguir´ a un conjunto de normas b´ asicas para tener cierto orden. Otro objetivo es adquirir nuevos conocimientos en el mundo del desarrollo de los videojuegos. Ya que este videojuego es el proyecto m´ as ambicioso en el que me he embarcado hasta ahora, espero que resolver los problemas que vayan apareciendo me permita aprender nuevas t´ ecnicas que poder emplear en futuros proyectos. Por ´ ultimo, quiero demostrar que se puede crear un juego utilizando ´ unicamente software de c´ odigo abierto. Es decir, software cuyo c´ odigo est´ a disponible a la vista de todo el que quiera verlo. 3 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 2.2. Alcance Ahora que se han definido los objetivos, se necesitan definir las tareas que ser´ an necesarias realizar para cumplirlos. Como es habitual en los ciclos de desarrollo de videojuegos, se ha decidido realizar el dise˜ no primero y dividir la parte de implementaci´ on en peque˜ nos prototipos (PT). Primero se dise˜ nar´ an las funciones, despu´ es se dibujar´ an los recursos y por ´ ultimo se realizar´ a la implementaci´ on de los prototipos. Estos prototipos pasar´ an por una fase de pruebas y por ´ ultimo se realizar´ a la correcci´ on de los errores encontrados. De esta manera, cada prototipo acercar´ a m´ as al desarrollo a la visi´ on final que se ha conformado del mismo. Adem´ as, realizar una fase de pruebas por cada prototipo permite detectar errores pronto que podr´ an ser subsanados antes de pasar a implementar otras funciones. Recordemos que en el estado inicial de este TFG se dispone ya de un personaje capaz de moverse. Los siguientes prototipos que se han definido a˜ nadir´ an funciones a lo que ya se tiene: PT1. Creaci´on de niveles: consiste en a˜ nadir la l´ ogica de generaci´ on procedural del nivel. Esto quiere decir que al finalizar este prototipo, al iniciar la partida el personaje aparecer´ a en un nivel de plataformas que debido a la aleatoriedad introducida, ser´ a diferente cada vez. PT2. Elementos interactuables: consiste en a˜ nadir a la generaci´ on de nivel elementos con los que el jugador podr´ a interactuar. Por ejemplo ´ arboles que se podr´ an cortar, plantas que recolectar y minerales que minar. PT3. Implementaci´on de interfaces: consiste en a˜ nadir la interfaz que muestre la vida del jugador, el inventario de los objetos en su posesi´ on, las combinaciones posibles entre sus objetos 1y los men´ us necesarios para empezar a jugar, pausar y terminar el juego. PT4. Objetos utilizables: ahora que ya se dispone de una interfaz para visualizar objetos, se implementar´ an los objetos que el jugador podr´ a utilizar. Esto incluye herramientas para talar ´ arboles, minar minerales o da˜ nar enemigos, poci´ on para restaurar salud y armaduras. 1Un ejemplo de combinaci´ on de objetos podr´ ıa ser combinar una hierba con miel para producir una poci´ on con la que el jugador podr´ a restaurar parte de su salud 4 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance PT5. Creaci´on de enemigos:´ ultima fase del proyecto. Se a˜ nadir´ an enemigos que atacar´ an al personaje y que al ser debilitados soltar´ an objetos que el jugador podr´ a utilizar. En resumen, al finalizar el proyecto se tendr´ a un videojuego en el que se controlar´ a a un personaje que el jugador mover´ a por niveles ´ unicos. Ser´ a capaz de utilizar los recursos del entorno para construir objetos ´ utiles y esto le permitir´ a derrotar a los enemigos con m´ as facilidad. 2.2.1. Diagrama de la estructura de la descomposici´on del trabajo Figura 2.1: EDT 5 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 2.2.2. Descripci´on de las tareas Documentaci´on 1.1 Memoria Paquete de trabajo: 1. Documentaci´ on Responsable: Ander Raso V´ azquez Duraci´on: 50 horas Descripci´on Se plasmar´ a toda la informaci´ on del proyecto en una memoria. Entradas N/A Salidas/Entregables La memoria de este TFG en formato PDF. Recursos necesarios Un PC con acceso a Internet para entrar a la p´ agina Overleaf, ya que se utilizar´ a para formatear el documento mediante Latex Precedencias N/A Tabla 2.1: 1.1 Memoria 6 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 1.1 Manual de usuario Paquete de trabajo: 1. Documentaci´ on Responsable: Ander Raso V´ azquez Duraci´on: 10 horas Descripci´on Para que el jugador sepa qu´ e es lo que puede hacer en el juego, se escribir´ a un manual de usuario que le indique los controles con los que mover al personaje y las combinaciones que puede realizar con los objetos. Entradas N/A Salidas/Entregables Un PDF con la informaci´ on de c´ omo se juega. Recursos necesarios Un PC con acceso a Internet para entrar a la p´ agina Overleaf, ya que se utilizar´ a para formatear el documento mediante Latex Precedencias 4.5.3 Tabla 2.2: 1.1 Manual de usuario 7 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance An´alisis y dise˜no 2.1 Captura de requisitos Paquete de trabajo: 2. An´ alisis y dise˜ no Responsable: Ander Raso V´ azquez Duraci´on: 3 horas Descripci´on Se crear´ an diagramas de casos de uso para identificar la jerarqu´ ıa de actores y los requisitos que se deber´ an implementar. Entradas N/A Salidas/Entregables Diagramas de casos de usos. Recursos necesarios Un PC con acceso a Internet a PlantUML, la p´ agina con la que se crear´ an los gr´ aficos. Precedencias N/A Tabla 2.3: 2.1 Captura de requisitos 8 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 2.2 Dise˜no de interfaces Paquete de trabajo: 2. An´ alisis y dise˜ no Responsable: Ander Raso V´ azquez Duraci´on: 3 horas Descripci´on Dise˜ no de las interfaces que necesitar´ a el jugador para empezar partida, pausar el juego, salir del juego, combinar objetos y ver su inventario. Entradas N/A Salidas/Entregables Diagramas de clase y de secuencia. Recursos necesarios Un PC con acceso a Internet a PlantUML, la p´ agina con la que se crear´ an los gr´ aficos. Precedencias N/A Tabla 2.4: 2.2 Dise˜ no de interfaces 9 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 2.3 Dise˜no de mapas Paquete de trabajo: 2. An´ alisis y dise˜ no Responsable: Ander Raso V´ azquez Duraci´on: 3 horas Descripci´on L´ ogica para generar niveles de forma procedural. Se deber´ a investigar qu´ e m´ etodo de generaci´ on aleatorio es el m´ as id´ oneo para este proyecto y crear los diagramas necesarios para implementarlo. Entradas N/A Salidas/Entregables Diagramas de clase y de secuencia. Recursos necesarios Un PC con acceso a Internet a PlantUML, la p´ agina con la que se crear´ an los gr´ aficos. Precedencias N/A Tabla 2.5: 2.3 Dise˜ no de mapas 10 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 2.4 Dise˜no de elementos interactuables Paquete de trabajo: 2. An´ alisis y dise˜ no Responsable: Ander Raso V´ azquez Duraci´on: 10 horas Descripci´on Incluye el dise˜ no de los elementos con los que el jugador puede interactuar. ´ Arboles, hierbas en el suelo, setas en el suelo, panales de miel y minerales (hierro y oro). Entradas N/A Salidas/Entregables Diagramas de clase y de secuencia. Recursos necesarios Un PC con acceso a Internet a PlantUML, la p´ agina con la que se crear´ an los gr´ aficos. Precedencias N/A Tabla 2.6: 2.4 Dise˜ no de elementos interactuables 11 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 2.5 Dise˜no de objetos utilizables Paquete de trabajo: 2. An´ alisis y dise˜ no Responsable: Ander Raso V´ azquez Duraci´on: 10 horas Descripci´on Incluye el dise˜ no de los objetos que podr´ a utilizar el jugador. Armaduras (hierro, oro), espadas (hierro, oro), picos (madera, hierro), madera, hierbas cortadas, setas recogidas, pepitas de minerales (hierro y oro), trozo de miel, poci´ on que recupera salud. Entradas Diagramas de clase de los objetos interactuables para decidir qu´ e objetos utilizables le dar´ an al personaje. Salidas/Entregables Diagramas de clase y de secuencia. Recursos necesarios Un PC con acceso a Internet a PlantUML, la p´ agina con la que se crear´ an los gr´ aficos. Precedencias 2.4 Tabla 2.7: 2.5 Dise˜ no de objetos utilizables 12 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance Prototipos 4.1.1 Implementaci´on de la creaci´on del nivel Paquete de trabajo: 4. Prototipos Responsable: Ander Raso V´ azquez Duraci´on: 10 horas Descripci´on Se utilizar´ an los diagramas para realizar la implementaci´ on procedural del nivel. Entradas Diagramas de clase, de secuencia y los tilesets de los mapas. Salidas/Entregables C´ odigo que implementa los diagramas y una lista de las pruebas a realizar. Recursos necesarios Un PC con el motor de juego Godot Engine instalado. Precedencias 2.3, 3.1 Tabla 2.14: 4.1.1 Implementaci´ on de la creaci´ on del nivel 19 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 4.1.2 Beta testing de la creaci´on del nivel Paquete de trabajo: 4. Prototipos Responsable: Ander Raso V´ azquez Duraci´on: 3 horas Descripci´on Se comprobar´ a si se crean los niveles como se ha definido. Entradas Juego a probar y una lista de los elementos a probar. Salidas/Entregables Informe de errores. Recursos necesarios Un PC con el juego instalado. Precedencias 4.1.1 Tabla 2.15: 4.1.2 Beta testing de la creaci´ on del nivel 20 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 4.1.3 Correcci´on de errores en la creaci´on del nivel Paquete de trabajo: 4. Prototipos Responsable: Ander Raso V´ azquez Duraci´on: 3 horas Descripci´on Correcci´ on de los errores obtenidos en el informe. Entradas Informe de errores. Salidas/Entregables C´ odigo arreglado. Recursos necesarios Un PC con el motor de juego Godot Engine instalado. Precedencias 4.1.2 Tabla 2.16: 4.1.3 Correcci´ on de errores en la creaci´ on del nivel 21 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 4.2.1 Implementaci´on de elementos interactuables Paquete de trabajo: 4. Prototipos Responsable: Ander Raso V´ azquez Duraci´on: 20 horas Descripci´on Se utilizar´ an los diagramas para realizar la implementaci´ on de los elementos interactuables. Entradas Diagramas de clase, de secuencia y los dibujos de los elementos interactuables. Salidas/Entregables C´ odigo que implementa los diagramas y una lista de las pruebas a realizar. Recursos necesarios Un PC con el motor de juego Godot Engine instalado. Precedencias 2.4, 3.2 Tabla 2.17: 4.2.1 Implementaci´ on de elementos interactuables 22 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 4.2.2 Beta testing de elementos interactuables Paquete de trabajo: 4. Prototipos Responsable: Ander Raso V´ azquez Duraci´on: 3 horas Descripci´on Se comprobar´ a si la interacci´ on con los elementos del nivel se realiza de la forma correcta. Entradas Juego a probar y una lista de los elementos a probar. Salidas/Entregables Informe de errores. Recursos necesarios Un PC con el juego instalado. Precedencias 4.2.1 Tabla 2.18: 4.2.2 Beta testing de elementos interactuables 23 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 4.2.3 Correcci´on de errores en elementos interactuables Paquete de trabajo: 4. Prototipos Responsable: Ander Raso V´ azquez Duraci´on: 4 horas Descripci´on Correcci´ on de los errores obtenidos en el informe. Entradas Informe de errores. Salidas/Entregables C´ odigo arreglado. Recursos necesarios Un PC con el motor de juego Godot Engine instalado. Precedencias 4.2.2 Tabla 2.19: 4.2.3 Correcci´ on de errores en elementos interactuables 24 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 4.3.1 Implementaci´on de las interfaces Paquete de trabajo: 4. Prototipos Responsable: Ander Raso V´ azquez Duraci´on: 25 horas Descripci´on Se utilizar´ an los diagramas para realizar la implementaci´ on de las interfaces. Entradas Diagramas de clase y de secuencia. Salidas/Entregables C´ odigo que implementa los diagramas y una lista de las pruebas a realizar. Recursos necesarios Un PC con el motor de juego Godot Engine instalado. Precedencias 2.2 Tabla 2.20: 4.3.1 Implementaci´ on de las interfaces 25 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 4.3.2 Beta testing de las interfaces Paquete de trabajo: 4. Prototipos Responsable: Ander Raso V´ azquez Duraci´on: 3 horas Descripci´on Se comprobar´ a si las interfaces funcionan de la forma definida. Entradas Juego a probar y una lista de los elementos a probar. Salidas/Entregables Informe de errores. Recursos necesarios Un PC con el juego instalado. Precedencias 4.3.1 Tabla 2.21: 4.3.2 Beta testing de las interfaces 26 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 4.3.3 Correcci´on de las interfaces Paquete de trabajo: 4. Prototipos Responsable: Ander Raso V´ azquez Duraci´on: 5 horas Descripci´on Correcci´ on de los errores obtenidos en el informe. Entradas Informe de errores. Salidas/Entregables C´ odigo arreglado. Recursos necesarios Un PC con el motor de juego Godot Engine instalado. Precedencias 4.3.2 Tabla 2.22: 4.3.3 Correcci´ on de las interfaces 27 Cap´ ıtulo 2. Planteamiento inicial 2.2. Alcance 4.4.1 Implementaci´on de objetos utilizables Paquete de trabajo: 4. Prototipos Responsable: Ander Raso V´ azquez Duraci´on: 20 horas Descripci´on Se utilizar´ an los diagramas para realizar la implementaci´ on de los objetos utilizables. Entradas Diagramas de clase, de secuencia y dibujos de los objetos utilizables. Salidas/Entregables C´ odigo que implementa los diagramas y una lista de las pruebas a realizar. Recursos necesarios Un PC con el motor de juego Godot Engine instalado. Precedencias 2.5, 3.3 Tabla 2.23: 4.4.1 Implementaci´ on de objetos utilizables 28 Cap´ ıtulo 2. Planteamiento inicial 2.3. Planificaci´ on temporal Figura 2.2: Diagrama de Gantt 35 Cap´ ıtulo 2. Planteamiento inicial 2.4. Gesti´ on de riesgos 2.4. Gesti´on de riesgos En un mundo ideal, los desarrollos se dise˜ nar´ ıan, se implementar´ ıan y se probar´ ıan tranquilamente. Sin embargo, en el ciclo de vida de un proyecto, con toda probabilidad surgir´ an contratiempos inesperados que invaliden las estimaciones que se han realizado o que incluso puedan destruir definitivamente el proyecto. Es por eso que es necesario llevar una correcta gesti´ on de los riesgos para poder ser capaces de identificarlos, actuar si se producen y que de esa manera no se materialicen en consecuencias no deseadas. A continuaci´ on se muestran los tipos de riesgos que han sido identificados: RP: Riesgos del personal. RH: Riesgos del hardware, el equipo con el que se trabaja. RD: Riesgos del desarrollo. 36 Cap´ ıtulo 2. Planteamiento inicial 2.4. Gesti´ on de riesgos RP1. Contagiarse de COVID-19 Descripci´on Viviendo en ´ epoca de pandemia mundial de COVID-19 es necesario tomar las medidas sanitarias adecuadas de prevenci´ on, adem´ as siendo una persona asm´ atica es posible que los efectos sean mayores. Prevenci´on Se seguir´ an atentamente las indicaciones del personal sanitario y se verificar´ a la informaci´ on que se obtenga de agentes externos para no caer en las t´ ıpicas mentiras que circulan por Internet. Ejemplos de medidas a tomar: Llevar mascarilla correctamente colocada. Utilizar gel hidroalcoh´ olico para lavarse las manos frecuentemente. Mantener distancia interpersonal de 1.5 metros. Plan de contingencia Seguir las indicaciones del personal sanitario para una correcta recuperaci´ on de la salud. Probabilidad Probable. La tasa de infecci´ on est´ a siendo muy alta, sobre todo en personas j´ ovenes. Impacto Muy alto. Los testimonios de las personas a mi alrededor que lo han padecido nos hace una media de 3 semanas para una completa recuperaci´ on, pero var´ ıa de persona a persona. Tabla 2.29: RP1. Contagiarse de COVID-19 37 Cap´ ıtulo 2. Planteamiento inicial 2.4. Gesti´ on de riesgos RP2. Otras enfermedades Descripci´on Si bien es cierto que a d´ ıa de hoy el foco est´ a en la pandemia COVID-19, se pueden contraer otras enfermedades que afecten al progreso del desarrollo. Prevenci´on Siguiendo las medidas de RP1 se eliminan probablemente de la ecuaci´ on las t´ ıpicas enfermedades estacionales como la gripe. Con otro tipo de enfermedades la incertidumbre es demasiado grande para poder hacer una prevenci´ on s´ olida. Plan de contingencia Seguir las indicaciones del personal sanitario para lograr una correcta recuperaci´ on. Probabilidad Improbable. Una de las consecuencias de que todos usemos mascarilla es que la transmisi´ on de las enfermedades ha disminuido mucho. Impacto Medio. Dependiendo de la enfermad pero se estima una media de 3 d´ ıas de inactividad. Tabla 2.30: RP2. Otras enfermedades 38 Cap´ ıtulo 2. Planteamiento inicial 2.4. Gesti´ on de riesgos RP3. Poco tiempo disponible Descripci´on Estudiar y trabajar a la vez deja muy poco tiempo disponible para dedicarle al proyecto. El cansancio puede provocar que no se tengan la energ´ ıa suficiente para continuar el desarrollo. Prevenci´on Gestionar el tiempo del d´ ıa en un calendario y respetar lo que se ha decidido hacer. Planificar descansos para que no se produzca burnout. Plan de contingencia Si se pierde demasiado tiempo ser´ a necesario sacrificar tiempo libre para ponerse al d´ ıa con el proyecto. Probabilidad Muy probable. Impacto Muy alto. En el peor de los casos, en un periodo de ex´ amenes se estima que puede haber un retraso de 4 semanas. Tabla 2.31: RP3. Poco tiempo disponible 39 Cap´ ıtulo 2. Planteamiento inicial 2.4. Gesti´ on de riesgos RH1. Aver´ıa del equipo de trabajo Descripci´on El equipo de trabajo puede sufrir una aver´ ıa debido a varios factores y es posible que se pierda el c´ odigo del proyecto. Prevenci´on Utilizar un control de versiones que sincronice los cambios en un repositorio online, para tener siempre una copia de seguridad. Realizar backups frecuentes al repositorio, con cada cambio. No comer ni beber cerca del equipo de trabajo. No dejar el equipo de trabajo en lugares de los que se pueda caer y romperse. Plan de contingencia Recuperar las copias de seguridad y utilizar otro equipo de trabajo. Probabilidad Poco probable. Impacto Muy alto. Perder los datos significar´ ıa que no se puede continuar el desarrollo. El impacto ser´ ıa cr´ ıtico. Tabla 2.32: RH1. Aver´ ıa del equipo de trabajo 40 Cap´ ıtulo 2. Planteamiento inicial 2.4. Gesti´ on de riesgos RH2. Robo del equipo de trabajo Descripci´on Sobre todo en lugares p´ ublicos, dejar el port´ atil sin vigilancia puede desembocar en un robo del mismo. Si no se han realizado copias de seguridad, se perder´ ıa por completo el proyecto. Prevenci´on Nunca dejar el port´ atil sin vigilancia en un lugar p´ ublico. Utilizar un control de versiones que sincronice los cambios en un repositorio online, para tener siempre una copia de seguridad. Realizar backups frecuentes al repositorio, con cada cambio. Plan de contingencia Recuperar las copias de seguridad y utilizar otro equipo de trabajo. Probabilidad Poco probable. Impacto Muy alto. Perder los datos significar´ ıa que no se puede continuar el desarrollo. El impacto ser´ ıa cr´ ıtico. Tabla 2.33: RH2. Robo del equipo de trabajo 41 Cap´ ıtulo 2. Planteamiento inicial 2.4. Gesti´ on de riesgos RD1. Perfeccionismo innecesario Descripci´on El perfeccionismo puede llevar a alargar una tarea demasiado tiempo o incluso a la par´ alisis completa del trabajo por percibir que no se est´ a haciendo en las condiciones ideales. El perfeccionismo y la procrastinaci´ on van unidos de la mano. Prevenci´on Respetar las horas que se han estimado. Si ya se ha conseguido un producto m´ ınimo viable en el tiempo acordado se dar´ a por terminada y se pasar´ a a la siguiente. Ser consciente de que las condiciones ideales no existen y que es mejor tener algo hecho medio bien que no tener nada hecho por no ser perfecto. Plan de contingencia Se recuperar´ a tiempo quit´ andoselo a otras tareas si es posible, pero esto provocar´ a que la calidad de ellas sea menor al esperado. Probabilidad Probable. Impacto Alto. Un perfeccionismo excesivo podr´ ıa llevar a reimplementar una y otra vez funcionalidades que podr´ ıan llevar hasta 3 semanas de retraso. Tabla 2.34: RD1. Perfeccionismo innecesario 42 Cap´ ıtulo 2. Planteamiento inicial 2.4. Gesti´ on de riesgos RD2. Errores en la planificaci´on Descripci´on Si se estiman mal las tareas se provocar´ a un aumento del tiempo total necesario para completar el desarrollo. Prevenci´on Hacer un an´ alisis con calma, estudiando las posibles dificultades que ser´ an necesarias hacer frente para terminar la tarea. Ser consciente de las limitaciones de uno mismo, ser´ a necesario aprender muchas cosas nuevas para completar el proyecto. Plan de contingencia Se recuperar´ a tiempo quit´ andoselo a otras tareas si es posible, pero esto provocar´ a que la calidad de ellas sea menor al esperado. Probabilidad Probable. Impacto Alto. 2 semanas de retraso. Tabla 2.35: RD2. Errores en la planificaci´ on 43 Cap´ ıtulo 2. Planteamiento inicial 2.4. Gesti´ on de riesgos RD3. Bugs en el motor de desarrollo Descripci´on Un bug es un error en el funcionamiento de un software. Es posible que ciertas tareas que se quieran implementar no funcionen correctamente por un error en el propio motor de desarrollo. Prevenci´on Investigar en Internet si es posible realizar la tarea de la forma en la que se ha pensado hacerla. Estar al d´ ıa de las noticias del motor de desarrollo de juegos seleccionado para saber si hay alg´ un bug cr´ ıtico. Actualizar a la ´ ultima versi´ on del motor, ya que tendr´ a las ´ ultimas correcciones. Plan de contingencia Se pedir´ a ayuda en el foro del motor de desarrollo. Probabilidad Improbable. Impacto Medio. Posiblemente se pueda realizar la tarea si se busca otra forma de implementarla. Se estima que el retraso pueda ser de 1 semana. Tabla 2.36: RD3. Bugs en el motor de desarrollo 44 Cap´ ıtulo 3. Antecedentes 3.2. Decidir el motor de desarrollo 3.2.1. Unity Figura 3.2: Logotipo de Unity. Si hablamos de motores, no podr´ ıamos empezar por otro que no fuera el l´ ıder de ellos, Unity[4]. A d´ ıa de hoy es uno de los m´ as usados del mundo y aparte de juegos en tres dimensiones, tambi´ en se han realizado multitud de juegos de plataformas en dos dimensiones con ´ el como el que se pretende hacer. Lenguaje de programaci´on: C#. Precio: Su uso es gratuito hasta que se alcanzan los 100.000$en ingresos durante los ´ ultimos 12 meses. Plataforma: Windows. Requerimientos del sistema: Medios. Tutoriales: Gran cantidad de tutoriales. 3.2.2. Unreal Engine Figura 3.3: Logotipo de Unreal Engine. Unreal Engine es el motor de videojuegos m´ as potente que existe para realizar videojuegos en tres dimensiones. Su capacidad es tal que hasta se usa en Hollywood para hacer efectos especiales. 51 Cap´ ıtulo 3. Antecedentes 3.2. Decidir el motor de desarrollo Lenguaje de programaci´on: C++ y Blueprints (m´ etodo para definir la l´ ogica sin programar). Precio: 5 % de los royalties cuando se monetice el juego y los ingresos hayan alcanzado 1.000.000$. Plataforma: Windows. Requerimientos del sistema: Altos. Tutoriales: Gran cantidad de tutoriales. 3.2.3. Godot Figura 3.4: Logotipo de Godot Engine. Es un motor de c´ odigo abierto que se ha hecho muy popular ´ ultimamente al ofrecer un entorno de trabajo muy intuitivo en el que los componentes se organizan por Nodos. Su capacidad para desarrollo en tres dimensiones es limitada pero en dos dimensiones est´ a a la par con Unity. Lenguaje de programaci´on: GDScript y C#. Precio: Totalmente gratuito. Plataforma: Windows/Mac/Linux. Requerimientos del sistema: Bajos. Tutoriales: Poca cantidad de tutoriales. 52 Cap´ ıtulo 3. Antecedentes 3.3. Generaci´ on procedural de contenido 3.2.4. Decisi´on Como se quiere desarrollar un videojuego en dos dimensiones se descarta Unreal Engine. Para dos dimensiones la decisi´ on estar´ ıa entre Unity y Godot Engine. Ya que uno de los objetivos es utilizar herramientas de c´ odigo abierto, Godot ser´ ıa una buena elecci´ on, por su licencia MIT y porque permite un desarrollo desde Linux. Su lenguaje de desarrollo GDScript es similar a Python as´ ı que ya dispongo de unos conocimientos b´ asicos de desarrollo y la organizaci´ on del proyecto mediante nodos es muy intuitiva para los que desarrollamos con programaci´ on orientada a objetos. Por lo tanto, se va a utilizar Godot aunque haya menor cantidad de tutoriales. Si se encuentran problemas se acudir´ a a la comunidad para intentar resolver las dudas. 3.3. Generaci´on procedural de contenido Cada partida a este videojuego debe generar una estructura del nivel diferente a la partida anterior. Para ello, se van a estudiar diferentes m´ etodos que se utilizan en otros videojuegos. 3.3.1. Perlin noise Uno de los algoritmos t´ ıpicos a la hora de generar contenido de forma procedural es el ruido Perlin. Un algoritmo que dado un conjunto de par´ ametros produce una serie de n´ umeros del 0,0 al 1,0. Si se interpretase una escala de grises siendo 0 negro y 1 blanco se podr´ ıa dibujar una imagen como la siguiente: 53 Cap´ ıtulo 3. Antecedentes 3.3. Generaci´ on procedural de contenido Figura 3.5: Representaci´ on del ruido Perlin. Los par´ ametros que se le dan al algoritmo determinar´ ıan la cantidad de blanco sobre negro, lo agrupados que estar´ ıan los puntos blancos entre s´ ı, la escala, etc. La utilizaci´ on es muy sencilla, ya que viene incluido en la mayor´ ıa de motores de desarrollo de videojuegos. Se le pasa como par´ ametro la coordenada y el algoritmo devolver´ ıa un float del 0,0 al 1,0. Para asegurarse que la generaci´ on inicial siempre es aleatoria, se inicia con una semilla aleatoria. Es decir, el n´ umero inicial que usar´ a para empezar a generar sus resultados. Si se le da la misma semilla siempre generar´ a el mismo output. Minecraft En el juego Minecraft se utiliza para la generaci´ on de monta˜ nas y cuevas. Como puede apreciarse en la siguiente imagen, si nos imaginamos la escala de grises como la altura del suelo se generar´ ıa lo siguiente: 54 Cap´ ıtulo 3. Antecedentes 3.3. Generaci´ on procedural de contenido Figura 3.6: Monta˜ nas en Minecraft. Terraria Terraria es un juego en dos dimensiones m´ as similar al proyecto que se quiere realizar que Minecraft. Aqu´ ı tambi´ en se utiliza para la generaci´ on de cuevas, pero no se utiliza la escala de grises para la altitud si no que se utiliza para crear caminos bajo tierra. 55 Cap´ ıtulo 3. Antecedentes 3.3. Generaci´ on procedural de contenido Figura 3.7: Cuevas en Terraria. 3.3.2. Plantillas Este m´ etodo no tiene nada que ver con el anterior. Se utiliza cuando se quiere tener un mayor control de los tipos de estructuras que se quieren generar. Spelunky El juego Spelunky utiliza plantillas de texto para generar proceduralmente sus niveles [3]. Cada letra representa un tipo de elemento en el juego (bloque, probabilidad de que haya enemigo, escaleras...etc) y juntando diferentes plantillas aleatoriamente una junto a otra se va generando el nivel. Aqu´ ı tenemos el ejemplo de una plantilla: 11000000000 21000000000 31000000000 41000000000 51001111100 56 Cap´ ıtulo 3. Antecedentes 3.3. Generaci´ on procedural de contenido 61001222100 71002222000 81111111111 Si a la hora de dibujar el mapa se interprentan los 0 como espacio libre y los 1 como bloque s´ olido se construir´ ıa algo aproximado a la primera sala de la imagen a continuaci´ on. Los 2 podr´ ıan ser bloques s´ olidos que no tendr´ ıan un 100 % de probabilidad de aparecer. En resumen, dependiendo de la interpretaci´ on que se le quiera dar a la letra o n´ umero de la plantilla se generar´ a algo espec´ ıfico en el mapa. Figura 3.8: Conexi´ on de salas en Spelunky. Caveblazers Otro ejemplo de un juego que combina las plantillas aleatoriamente para generar las estructuras del nivel. 57 Cap´ ıtulo 3. Antecedentes 3.3. Generaci´ on procedural de contenido Figura 3.9: Cuevas en Caveblazers. 3.3.3. Decisi´on La generaci´ on de niveles mediante plantillas aporta un mayor control del tipo de nivel que se quiere crear. Es menos aleatorio que el ruido Perlin y dependiendo de la plantilla, da un aspecto m´ as ordenado al nivel. Puedo imaginarme perfectamente usando este m´ etodo para generar las plataformas, el suelo, los recursos que se pueden recolectar, los enemigos con los que luchar, etc. Sin lugar a dudas, creo que es el m´ etodo adecuado para este proyecto y es el que se intentar´ a implementar. 58 Cap´ıtulo 4 Captura de requisitos En este cap´ ıtulo se detallan los requerimientos que tiene que cumplir el proyecto que se va a desarrollar. Se van a mostrar en diagramas de casos de uso las necesidades de los actores y se va a explicar cada caso uno de ellos. 4.1. Jerarqu´ıa de actores Solo hay un agente externo al sistema ”juego”, el jugador. Por lo tanto, no hay una jerarqu´ ıa de la que otros actores puedan heredar funcionalidades, solo tendremos al jugador. 4.2. Diagramas de casos de uso He decidido separar los casos de uso en dos im´ agenes diferentes para que se distingan mejor sobre el papel. Los he separado en los casos que est´ an relacionados con el movimiento del jugador sobre el nivel y los que no lo est´ an. 59 Cap´ ıtulo 4. Captura de requisitos 4.2. Diagramas de casos de uso 4.2.1. Casos de uso no relacionados al movimiento del personaje Figura 4.1: Casos de uso parte 1. Pausar juego: el jugador debe ser capaz de pausar el juego. Ganar juego: cuando el jugador cumpla la condici´ on para ganar la partida ”Vencer al jefe final”, se debe mostrar al jugador que ha terminado la partida. Recibir da˜no: debe ser capaz de recibir da˜ no de los enemigos. Morir: si se ha recibido el suficiente da˜ no y los puntos de salud bajan a una cantidad menor o igual a cero, el jugador morir´ a. Mover objeto en inventario: usando el rat´ on, el jugador tiene que ser capaz de reordenar los objetos que se encuentran en su inventario. 60 Cap´ ıtulo 5. An´ alisis y dise˜ no 5.2. PT2. Elementos interactuables reimplementar´ a la funci´ on activate para que produzcan sus propios efectos cuando se interact´ ue con ellos. Tienen una lista de loot (bot´ ın), es decir, los objetos que soltar´ an cuando se haya interactuado con ellos. A continuaci´ on se muestra de forma m´ as visual la l´ ogica de los effective groups. Figura 5.4: PT2. Diagrama de secuencia de la activaci´ on de los objetos interactuables. 67 Cap´ ıtulo 5. An´ alisis y dise˜ no 5.3. PT3. Implementaci´ on de interfaces 5.3. PT3. Implementaci´on de interfaces Consiste en a˜ nadir la interfaz que muestre la vida del jugador, el inventario de los objetos en su posesi´ on, las combinaciones posibles entre sus objetos 1y los men´ us necesarios para empezar a jugar, pausar y terminar el juego. Aparte de las nuevas interfaces, lo que m´ as destacar´ ıa es la creaci´ on de 3 clases nuevas que almacenar´ an informaci´ on de los objetos: Figura 5.5: PT3. Diagrama de clases que tienen que ver con el inventario. Slot: representa una casilla del inventario. Inventory: conjunto de Slots, contiene la l´ ogica para a˜ nadir o eliminar slots. RecipeManager: dado un conjunto de objecos, devuelve una lista de los elementos que se pueden crear. 1Un ejemplo de combinaci´ on de objetos podr´ ıa ser combinar una hierba con miel para producir una poci´ on con la que el jugador podr´ a restaurar parte de su salud. 68 Cap´ ıtulo 5. An´ alisis y dise˜ no 5.4. PT4. Objetos utilizables 5.4. PT4. Objetos utilizables Ahora que ya se dispone de una interfaz para visualizar objetos, se implementar´ an los objetos que el jugador podr´ a utilizar. Esto incluye herramientas para talar ´ arboles, minar minerales o da˜ nar enemigos, poci´ on para restaurar salud y armaduras. En este caso no se ha precisado de una base de datos, ya que la informaci´ on de los objetos se ha decidido guardar en un simple fichero JSON que cargar´ a el singleton ObjectInfo. Al principio se hab´ ıa pensado en implementar una clase para cada objeto, pero si simplemente se cambia la imagen y el identificador del objeto ya deber´ ıa ser suficiente. De tal forma que con una sola clase se pueden representar todos los objetos. Figura 5.6: PT4. Diagrama de clases para utilizar objetos. Pickable: representa un objeto que se puede coger del suelo. Utiliza a ObjectInfo para saber que icono mostrar en el juego. Inventory: ahora tiene que tener en cuenta el objeto que est´ a seleccionado, para que el jugador pueda extraer esa informaci´ on. Player: el jugador puede realizar la acci´ on primaria o secundaria del objeto dependiendo si hace click izquierdo o derecho del rat´ on. Utiliza a Inventory para saber que objeto lleva equipado y para a˜ nadir los nuevos objetos que 69 Cap´ ıtulo 5. An´ alisis y dise˜ no 5.5. PT5. Creaci´ on de enemigos recoge del suelo. Para saber que tiene que hacer con el objeto obtiene la informaci´ on de ObjectInfo, esto permite que a˜ nadir objetos o modificarlos se haga solamente desde este singleton. Figura 5.7: PT4. Diagrama de secuencia de activaci´ on de un objeto al hacer click derecho. 5.5. PT5. Creaci´on de enemigos ´ Ultima fase del proyecto. Se a˜ nadir´ an enemigos que atacar´ an al personaje y que al ser debilitados soltar´ an objetos que el jugador podr´ a utilizar. El dise˜ no inicial de las clases era el siguiente: 70 Cap´ ıtulo 5. An´ alisis y dise˜ no 5.5. PT5. Creaci´ on de enemigos Figura 5.8: PT5. Diagrama inicial de clases de enemigos. Goblin: duende. GoblinMage: duende mago. Skeleton: esqueleto. Moth: polilla. Slime: babosa. SlimeFast: babosa r´ apida. A primera vista puede parecer un dise˜ no inicial v´ alido, ya que cumplir´ ıa los requisitos de lo que tienen que hacer los enemigos. Sin embargo, hay un problema que no se ve a simple vista: es un sistema demasiado r´ ıgido. Los enemigos dependen demasiado entre s´ ı. ¿Qu´ e pasar´ ıa si cambian los requisitos y quisi´ eramos que el Skeleton saltase como lo hacen los Slimes? Habr´ ıa que asegurarse que los enemigos que dependen de ´ el no se vieran afectados por los cambios. ¿O que pasar´ ıa si quisi´ eramos que los Slime usen magia como el GoblinMage? No habr´ ıa forma de reutilizar funcionalidades. Es resumen, cada cambio en un enemigo podr´ ıa afectar en cascada al resto y extender el n´ umero de enemigos ser´ ıa cada vez m´ as dif´ ıcil. Por lo tanto, es un mal dise˜ no. 71 Cap´ ıtulo 5. An´ alisis y dise˜ no 5.5. PT5. Creaci´ on de enemigos 5.5.1. Herencia VS Composici´on Uno de los principios SOLID es favorecer la composici´ on sobre la herencia. Esto quiere decir que es preferible que las clases contengan instancias de otras clases que implementan una funcionalidad espec´ ıfica, en lugar de heredar esa funcionalidad mediante la herencia. ¿Y si en lugar de implementar la funcionalidad directamente en la clase del enemigo y reusarla mediante la herencia se sacara absolutamente todo aparte? A continuaci´ on se muestra una tabla en la que se han detallado los diferentes comportamientos que construyen a los enemigos. Componente SK GB GM MT SM SF OG PlayerDetector x x x x - x x AnimationPlayer x x x x x x x CanDie x x x x x x x DamageReceiver x x x x x x x DamageDealer x x x x x x x FacePlayer x x x - - - - FaceJumpDirection - - - - x x - FollowNode x x - - - x x FollowNodeFlying - - - x - - - Health x x x x x x x Magic - - x - - - - HealthInfo x x x x x x x HumanoidBody x x x - - - - SlimeBody - - - - x x - MothBody - - - x - - - OgreBody - - - - - - x Jump - - - - - x - JumpPrecipice - x - - - - - JumpRandom - - - - x x - KnockBack x x x x x x - LootTable x x x x x x - Tabla 5.1: Tabla de componentes de enemigos. SK=Skeleton, GB=Goblin, GM=GoblinMage, MT=Moth, SM=Slime, SF=SlimeFast, OG=Ogre. 72 Cap´ ıtulo 5. An´ alisis y dise˜ no 5.5. PT5. Creaci´ on de enemigos 5.5.2. Soluci´on final Se va a crear una clase b´ asica cuya ´ unica funci´ on es la capacidad de sentir la gravedad del planeta. La gravedad que sienten es modificable por instancia as´ ı que no se ha sacado fuera por ahorrarme el paso de a˜ nadir ese componente a todos. Cada enemigo que se cree heredar´ a de esa clase y se le a˜ nadir´ an de uno en uno los componentes que necesite. Esta soluci´ on ha arreglado el problema de que los enemigos dependieran de otros enemigos y ha proporcionado libertad absoluta para personalizar su comportamiento sin miedo a introducir fallos en otros enemigos. No solo eso, gracias a la forma de a˜ nadir componentes del motor Godot, construir enemigos se hace sin escribir una sola l´ ınea de c´ odigo (si el componente ya existe). Como explicar´ e en el siguiente cap´ ıtulo, esta fue la mejor decisi´ on de todo el proyecto. 73 Cap´ıtulo 6 Desarrollo Una vez realizado todo el an´ alisis de requisitos y los diagramas iniciales que se pensaba que se iban a utilizar, me puse manos a la obra con el proyecto. 6.1. Inicio del proyecto: Arte del juego Una de las decisiones m´ as dif´ ıciles a tomar cuando se realiza un videojuego, es elegir el tipo de arte que se va a usar. Ya que en este proyecto lo que quiero mostrar son mis habilidades para resolver problemas de ingenier´ ıa de software m´ as que las art´ ısticas que pudiera tener, he decidido usar dise˜ nos minimalistas usando el arte pixelado. La mayor´ ıa de los dibujos los he realizado dentro de cuadros de 32x32 o 16x16 p´ ıxeles. Para dibujar decid´ ı usar el programa Aseprite, la mejor herramienta de c´ odigo abierto que he probado hasta ahora para realizar este tipo de arte. Adem´ as, tiene la habilidad de separar las capas del dibujo en archivos individuales, lo que permitir´ a animar m´ as adelante cada parte de los personajes. 74 Cap´ ıtulo 6. Desarrollo 6.1. Inicio del proyecto: Arte del juego Figura 6.1: Dibujo del personaje jugable. Figura 6.2: Ejemplo de una animaci´ on utilizando las capas que se han exportado de la imagen. 75 Cap´ ıtulo 6. Desarrollo 6.1. Inicio del proyecto: Arte del juego 1# Exportar las capas en im´ agenes individuales 2aseprite.exe -b archivo.ase --save-as carpeta/{layer}.png Lo mejor de haber dividido la imagen por estas capas, es que para los enemigos humanoides puedo reutilizar las animaciones que he hecho. De esta forma, solo hay que sustituir las im´ agenes por las del personaje que corresponda y reutilizar las animaciones que se le quieran poner. Para los enemigos que no tienen una estructura humanoide hay que crear animaciones propias para los tipos de monstruos que sean. Figura 6.3: Dibujos de los enemigos ordenados por niveles en los que aparecen. Nivel 1 (skeleton, moth), nivel 2 (slime, slime fast), nivel 3 (goblin, goblin mage), nivel 4 (ogre). 6.1.1. Entorno Para dibujar los entornos utilic´ e los Tileset, una herramienta que permite crear niveles usando los cuadraditos de una imagen. Dependiendo de como se pinten los cuadraditos por la pantalla y de qu´ e otros cuadraditos tenga a su alrededor, el Tileset sabe que cuadrado poner espec´ ıficamente para que las conexiones entre ellos queden bien. 76 Cap´ ıtulo 6. Desarrollo 6.4. PT3. Implementaci´ on de interfaces Figura 6.10: Men´ u de pausa. No hubo un retraso significativo al desarrollar la parte de modificar el volumen porque en Godot en pocas l´ ıneas se puede implementar: 1# Funci´ on que se activa al deslizar el slider del volumen 2func _on_HSliderVolume_value_changed(value): 3AudioServer.set_bus_volume_db(AudioServer.get_bus_index("Master"), value) 6.4.1. Problemas con la creaci´on de objetos Al principio quer´ ıa desarrollar un men´ u que mostrase los objetos a la izquierda y los combinaciones que se pod´ ıan hacer a la derecha. 83 Cap´ ıtulo 6. Desarrollo 6.4. PT3. Implementaci´ on de interfaces Figura 6.11: Antigua interfaz de creaci´ on de objetos. Pronto desech´ e esta idea porque no me gustaba nada como se ve´ ıa y adem´ as tapaba el nivel. Decidir empezar de nuevo a crear la interfaz fue una decisi´ on dif´ ıcil de tomar, pues retrasar´ ıa el avance y no garantizar´ ıa que me fuera a gustar m´ as que esta primera soluci´ on. Despu´ es de tomar como referencia otros videojuegos, decid´ ı implementar una interfaz similar al videojuego Terraria. En la que la creaci´ on de objetos se muestra abajo a la izquierda. 84 Cap´ ıtulo 6. Desarrollo 6.4. PT3. Implementaci´ on de interfaces Figura 6.12: Interfaz del jugador durante el nivel cuando pulsa la tecla TAB . 1: Muestra la informaci´ on del personaje. hp (puntos de vida), mg (puntos de magia), df (defensa). 2: equipamiento que puede llevar el personaje (casco, pechera o escudo). 3: lista de objetos que se pueden crear con los objetos que se poseen en el inventario (6). 4: lista de objetos que se consumir´ an del inventario al crear el objeto seleccionado en la lista (3). 5: lista de objetos que se pueden poner en la mano. Moviendo la rueda del rat´ on se van seleccionando o pulsando un n´ umero del 1 al 6. 6: lista de objetos del inventario. Se pueden mover entre la lista de objetos a tener en la mano o apilar los objetos del mismo tipo siempre que no sean herramientas o armadura. 7: papelera para depositar objetos que no se necesitan. 8: informaci´ on que sale al pasar el cursor sobre un objeto. La informaci´ on de las recetas se guardan en un diccionario. En total hay 17 recetas, a continuaci´ on muestro el ejemplo de 2: 85 Cap´ ıtulo 6. Desarrollo 6.5. PT4. Objetos utilizables 1_recipes ={ 2"gold_sword": { 3"gold":1, 4"wood":1 5}, 6"potion_health": { 7"herb":1, 8"honey":1 9} 10 } Para obtener la lista de las recetas que se pueden hacer se pasa la lista de los objetos del inventario del jugador al RecipeManager, el gestor de recetas. Este va mirando receta a receta las que se puedan hacer y devuelve una lista con las que son posibles. Esa lista es la que se muestra en el punto 3 de la imagen anterior. 6.5. PT4. Objetos utilizables En el PT2, elementos interactuables, se hab´ ıan implementado los recursos con los que el jugador pod´ ıa interactuar pero no aparec´ ıan los objetos que el jugador pod´ ıa recoger en el mapa. Esta parte se ha decidido hacer despu´ es de implementar las interfaces para poder equipar estos objetos en el inventario y facilitar las pruebas. Es m´ as sencillo probar los objetos si ya se dispone de un inventario con varias casillas donde ir almacen´ andolos. Hacer que los objetos aparezcan en el mapa es trivial. Lo hace la clase Stage cuando recibe la se˜ nal de que hay que hacer que aparezca un objeto. Recibe el nombre del objeto y crea el objeto pas´ andole el identificador. Esto hace que el propio objeto pregunte por la imagen que necesita mostrar al gestor de objetos. Cuando el jugador se acerca al objeto se a˜ nade a su inventario. Estos son los objetos que existen: 86 Cap´ ıtulo 6. Desarrollo 6.5. PT4. Objetos utilizables Figura 6.13: Objetos que pueden usarse en el juego. Herramientas: pico (A6) y pico de hierro (B6). Sirven para minar minerales. Objetos combinables: seta (A1), miel (B1), hierba (C1), madera (D1), gelatina (A5). Tambi´ en est´ an los n´ ucleos (B5, C5), que sirven para combinarlos con minerales para crear armaduras. Armadura de hierro: (B2, C2, D2) cada parte incrementa un punto la defensa. Armadura de oro: (B3, C3, D3) cada parte incrementa dos puntos la defensa. Espadas: hierro (C4) +4 de ataque, oro (B4) +6 de ataque. Magia: (C6) lanza una bola de energ´ ıa si se tiene puntos de magia suficientes. Lanzamientos: tenemos un arco (D5) y una flecha (D6), pero tambi´ en una lanza (A7). Pociones: poci´ on de salud (A4) recupera 5 puntos de vida, poci´ on de magia (B4) recupera 5 puntos de magia. 87 Cap´ ıtulo 6. Desarrollo 6.5. PT4. Objetos utilizables La implementaci´ on de los efectos de los objetos se ha realizado mediante las animaciones. Lo primero que se hace es mirar el objeto que se tiene equipado, por ejemplo el bast´ on de magia. Por lo tanto, al pulsar el click derecho del rat´ on para activar su efecto, se selecciona esa animaci´ on y se ejecuta la funci´ on de activar el efecto, que en este caso es lanzar una bola de magia. Figura 6.14: Ejemplo de activaci´ on de un objeto. Como se puede comprobar, hay una pista en la animaci´ on que invoca la funci´ on activate secondary action effect(). Si se tiene equipado un bast´ on de magia intentar´ a lanzar magia, si tiene una poci´ on intentar´ a recuperarse vida, si tiene un arco intentar´ a lanzar una flecha...etc. Es un sistema muy sencillo que se podr´ ıa ampliar en el futuro con facilidad. 88 Cap´ ıtulo 6. Desarrollo 6.6. PT5. Creaci´ on de enemigos 6.6. PT5. Creaci´on de enemigos Esta parte ha sido la m´ as divertida de implementar. Como he explicado en el cap´ ıtulo del an´ alisis y dise˜ no, decid´ ı crear una entidad b´ asica a la que solo le afectaba la gravedad. La idea principal era crear enemigos a˜ nadi´ endole comportamientos o componentes a esa entidad. Hacerlo de esta manera en lugar de un ´ arbol extenso de herencia ha permitido una gran flexibilidad para crear enemigos ´ unicos, pero que son capaces de compartir comportamientos con otras entidades. 6.6.1. Comportamiento de los enemigos Figura 6.15: Dibujos de los enemigos ordenados por niveles en los que aparecen. Nivel 1 (skeleton, moth), nivel 2 (slime, slime fast), nivel 3 (goblin, goblin mage), nivel 4 (ogre). Skeleton: cuando detecta al jugador se va acercando hacia ´ el para intentar tocarle y as´ ı disminuir su vida. Moth: mismo comportamiento que el esqueleto pero se acerca volando. Por lo tanto, aunque el jugador salte para escapar la polilla podr´ a seguirle. Slime: salta aleatoriamente hacia los lados y resbala mucho en el suelo. SlimeFast: igual que el Slime pero si detecta al jugador saltar´ a hacia ´ el. 89 Cap´ ıtulo 6. Desarrollo 6.6. PT5. Creaci´ on de enemigos Goblin: si detecta al jugador lo perseguir´ a y si est´ a muy cerca le atacar´ a con su cuchillo. Adem´ as, cuando detecta que se va a caer de una plataforma salta primero para realizar una ca´ ıda espectacular. GoblinMage: cuando detecta al jugador le atacar´ a desde lejos lanz´ andole magia. Ogre: cuando detecta al jugador se abalanza peri´ odicamente hacia ´ el, quit´ andole gran cantidad de vida. Adem´ as, mueve la cabeza haciendo como que est´ a mirando al jugador. Para todos los enemigos que son capaces de detectar al jugador, si el jugador se aleja lo suficiente dejar´ an de seguirle e intentar atacarle. 6.6.2. Implementaci´on Los componentes se escuchan entre s´ ı para realizar comportamientos determinados. Adem´ as, cada componente es parametrizable para ajustar las preferencias que queramos que tengan las entidades (velocidad, rango de detecci´ on... etc). A continuaci´ on se va a mostrar un ejemplo del uso de componentes para construir un Goblin, ya que es la entidad m´ as compleja del juego: Figura 6.16: Ejemplo de los componentes que tiene un goblin. 90 Cap´ ıtulo 6. Desarrollo 6.6. PT5. Creaci´ on de enemigos CollisionShape2D: sirve para que detecte el suelo y las paredes. HealthComponent: lleva la cuenta de la vida. Est´ a suscrito a DamageReceiverComponent para saber cuando le est´ an haciendo da˜ no y gestiona la vida que le quitan. Adem´ as, manda una se˜ nal cuando la vida cambia. DamageReceiverComponent: detecta las colisiones con las cosas que puede detectar como por ejemplo las armas del personaje. Env´ ıa una se˜ nal cuando detecta que algo ha entrado a ´ el. AnimationPlayerComponent: se encarga de reproducir las animaciones. Escucha al nodo de la entidad principal y dependiendo de su vector de movimiento decide que animaci´ on usar: •Si el vector es (0, 0) ejecuta la animaci´ on de descansar. •Si el vector tiene el componente ycomo 0 pero el xes distinto a 0 ejecuta la habilidad de andar. •Si el vector tiene un componente ydistinto a 0 interpreta que est´ a en el aire y ejecuta la animaci´ on de salto. ShadowComponent: detecta donde est´ a el suelo para poner una sombra. HumanoidSkeleton: cuerpo del personaje. DamageDealerComponent: un ´ area capaz de ser detectada por otras ´ areas. En este caso corresponde al cuerpo, es decir, que si el jugador toca esta ´ area sufrir´ a da˜ no. DamageDealerComponentWeapon: ´ area que corresponde al cuchillo, si el jugador detecta esta ´ area le quitar´ a vida. PlayerDetectorComponent: corresponde al ´ area azul m´ as grande de la imagen. Se encarga de detectar al jugador y env´ ıa una se˜ nal cuando lo hace con su informaci´ on. FacePlayerComponent: est´ a escuchando a PlayerDetectorComponent para cambiar la direcci´ on a la que mira al personaje. KnockbackComponent: escucha a DamageReceiverComponent y provoca un retroceso cuando recibe la se˜ nal de que ha recibido da˜ no. LootTableComponent: guarda la informaci´ on de los objetos que tiene que soltar al morir. 91 Cap´ ıtulo 6. Desarrollo 6.6. PT5. Creaci´ on de enemigos CanDieComponent: escucha a HealthComponent y cuando recibe la se˜ nal de que ha muerto se encarga de hacer que aparezcan los objetos en el mapa y de que desaparezca el personaje. JumpOnPrecipiceComponent: escucha a PrecipiceDetectorComponent para hacerle saltar en el momento preciso. PrecipiceDetectorComponent: manda una se˜ nal cuando detecta que va a llegar a un precipicio. PlayAnimationOnPlayerDetectedComponent: escucha a un AnimationPlayerComponent, en este caso a PlayerDetectorComponentClose, para ejecutar una animaci´ on cuando detecte al personaje. Esto permite que el goblin pueda atacar con el cuchillo cuando detecte al personaje cerca. PlayerDetectorComponentClose: detecta al personaje. Es la cajita azul mediana de la imagen. HealthInfoComponent: escucha a HealthComponent, cuando recibe la se˜ nal de que la vida ha cambiado ense˜ na un n´ umero de la cantidad de vida que ha perdido. HitEffectComponent: escucha a DamageReceiverComponent, pinta el cuerpo de color blanco por un momento, sirve como feedback para que el jugador sepa que ha provocado da˜ no al enemigo. FollowNodeHorizontallyComponent: escucha a PlayerDetectorComponent, cuando recibe la se˜ nal de que se ha detectado al jugador hace que se mueva hacia la direcci´ on de lo que ha detectado. Los dem´ as enemigos poseen variaciones m´ as sencillas que el goblin. Las babosas por ejemplo tienen un componente de salto, la polilla tiene un componente para moverse por el aire (y su gravedad se ha ajustado a cero), el ogro tiene un componente para abalanzarse sobre el jugador y el jugador tiene un componente para detectar las teclas del teclado para poder moverlo. Lo m´ as interesante de estos componentes es que se desarrollan por separado. Al construir los enemigos solo hay que a˜ nadirlos a la entidad base e indicar a qu´ e otros componentes tienen que escuchar. He exportado cada variable que necesitan al editor y esto permite que no haya que escribir c´ odigo para crear enemigos. Con arrastrar el componente a la variable es suficiente. 92 Cap´ıtulo 8 Conclusiones y trabajo futuro Este trabajo de fin de grado ha sido el proyecto m´ as grande que he hecho nunca. Ha puesto al l´ ımite todos los conocimientos que he adquirido durante la carrera y ha hecho que vaya un paso m´ as all´ a para que diera lo mejor de m´ ı. Estoy muy satisfecho con el trabajo realizado y me he quedado con ganas de seguir trabajando en ello. No cabe duda de que continuar´ e puliendo este proyecto. 8.1. Objetivos El objetivo principal de este proyecto era crear un videojuego en el que cada partida fuera diferente de la anterior. Para ello, los niveles se ten´ ıan que generar proceduralmente y es lo que se ha hecho. Cada partida genera niveles diferentes y coloca los recursos/enemigos aleatoriamente, as´ ı que debido a la gran variedad de posibilidades, no se van a jugar dos partidas iguales. Otro objetivo era adquirir nuevos conocimientos en el mundo del desarrollo de los videojuegos. La investigaci´ on que se ha tenido que llevar a cabo para cumplir los requisitos del proyecto han hecho que haya tenido que aprender much´ ısimo, sobre todo de buenas pr´ acticas de dise˜ no y ´ algebra vectorial. Y como objetivo adicional tambi´ en quer´ ıa demostrar que se puede crear un juego utilizando ´ unicamente software de c´ odigo abierto. He utilizado Godot, Aseprite y un Port´ atil con Linux as´ ı que como podemos ver en las im´ agenes a continuaci´ on, es posible. 99 Cap´ ıtulo 8. Conclusiones y trabajo futuro 8.1. Objetivos 8.1.1. Im´agenes del juego terminado Figura 8.1: Nivel 1: Bosque verde con el inventario abierto. Figura 8.2: Nivel 2: Bosque de champi˜ nones con el inventario cerrado. 100 Cap´ ıtulo 8. Conclusiones y trabajo futuro 8.2. Gesti´ on de riesgos Figura 8.3: Nivel 3: Castillo. Figura 8.4: Nivel 4: Batalla final. 8.2. Gesti´on de riesgos A continuaci´ on, se va a evaluar el ´ exito de los planes de prevenci´ on y contingencia definidos. 101 Cap´ ıtulo 8. Conclusiones y trabajo futuro 8.2. Gesti´ on de riesgos 1. RH1. Aver´ıa del equipo de trabajo: tuve mucho cuidado de no acercar comida o bebida cerca del port´ atil y nunca lo puse en lugares inestables desde donde pudiera caerse. Adem´ as, con cada cambio que hice en el proyecto resguard´ e copias de seguridad en el repositorio de c´ odigo. A d´ ıa de hoy, no concibo trabajar sin un programa de control de versiones donde resguardar el c´ odigo as´ ı que en el futuro seguir´ e utiliz´ andolo para futuros proyectos. 2. RH2. Robo del equipo de trabajo: nunca tuve la necesidad de sacar el equipo de casa y siempre cerr´ e con llave la puerta de casa antes de dormir, as´ ı que las probabilidades de que el port´ atil fuera robado disminuyeron mucho. 3. RP3. Poco tiempo disponible: un riesgo que se termin´ o cumpliendo, ya que ir a la universidad, trabajar, ir a la academia y despu´ es estudiar en casa me quitaba la mayor parte del tiempo disponible del d´ ıa. El plan de prevenci´ on consist´ ıa en gestionar el tiempo en el calendario, respetarlo y planificar descansos. Sin embargo, en ´ epoca de ex´ amenes, las horas de estudio eclipsaron el tiempo disponible para el desarrollo de este proyecto. Al final tuve que recurrir al plan de contingencia que consist´ ıa en sacrificar el tiempo libre, principalmente fines de semana, para continuar el progreso. El problema fue que muchos fines de semana tambi´ en ten´ ıa que estudiar y despu´ es de trabajar en el proyecto no ten´ ıa pr´ acticamente tiempo libre, lo que produjo que acabase muy agobiado. Es cierto que el plan de contingencia funcion´ o, pero si tuviera que hacer este proyecto de nuevo, si tuviera tan poco tiempo libre hubiera rebajado el alcance para tener menos tareas que hacer o hubiera definido menos horas por semana aunque se retrasase mucho la fecha de finalizaci´ on. 4. RP1. Contagiarse de COVID-19: termin´ e contagi´ andome a pesar de tomar todas las medidas de prevenci´ on recomendadas. Probablemente por las aglomeraciones que se producen en el transporte p´ ublico, donde mantener la distancia de seguridad es complicado y hay poca ventilaci´ on. El plan de contingencia consist´ ıa en cumplir las indicaciones sanitarias para recuperarme lo antes posible y lo hice, con la suerte de que mi enfermedad fue leve. Si volviera a verme en esta situaci´ on intentar´ ıa no usar el transporte p´ ublico. 5. RD1. Perfeccionismo innecesario: el plan consist´ ıa en no dedicar m´ as horas de las estimadas si ya se ten´ ıa un producto m´ ınimo viable. Si bien es cierto que se me ocurrieron varias mejoras para varios sistemas, al ser ya funcionales no les dediqu´ e m´ as tiempo del necesario y di las tareas por 102 Cap´ ıtulo 8. Conclusiones y trabajo futuro 8.3. Revisi´ on de la estimaci´ on inicial concluidas. En el futuro volver´ e a utilizar esta forma de trabajo, ya que ha permitido que pudiera avanzar con un producto funcional en lugar de retrasar el avance por la reimplementaci´ on de sistemas que aunque no sean perfectos, cumplen con su prop´ osito. 6. RD2. Errores en la planificaci´on: tuve errores en la planificaci´ on sobre todo en el dise˜ no de las interfaces, porque no me gustaba como qued´ o el men´ u de combinaci´ on de objetos, y en el desarrollo de los enemigos, porque para cumplir los requisitos de los enemigos tuve que crear m´ as componentes de los que hab´ ıa imaginado. Para que no vuelva a pasar, deber´ ıa haber pasado m´ as tiempo pensando en todos los tipos de componentes que iban a hacer falta. Por ejemplo, no hab´ ıa pensado en los componentes que mostraban los puntos de vida que se restan a los enemigos al atacarlos, ni el componente que cambia el color del enemigo al recibir ataques para que el jugador sepa que les est´ a haciendo da˜ no. 7. RD3. Bugs en el motor de desarrollo: Siempre investigu´ e primero si la soluci´ on que hab´ ıa pensado pod´ ıa implementarse en el motor antes de ponerme con la tarea y por suerte no hubo ning´ un bug en Godot que me impidiera continuar. 8. RP2. Otras enfermedades: a parte de COVID-19, no me enferm´ e de nada notorio. Imagino que al usar la mascarilla y cumplir las medidas de prevenci´ on evit´ e enfermarme de enfermedades estacionales. 8.3. Revisi´on de la estimaci´on inicial Al final se ha tardado 26,5 horas m´ as en terminar el proyecto, ascendiendo a un total de 304,5 horas frente a las 278 que se hab´ ıan estimado. 103 Cap´ ıtulo 8. Conclusiones y trabajo futuro 8.3. Revisi´ on de la estimaci´ on inicial Figura 8.5: Tiempo estimado VS tiempo real. Gastos asociados al proyecto en AC Descripci´on Total ASUS GL552VW 25,8AC Aseprite 16,79AC Salario (22AC/hora) 304,5 * 22 = 6699 AC TOTAL 6741,59 Tabla 8.1: Gastos asociados al proyecto. La diferencia de gastos real contra la estimada: 6741,59 - 6152,86= 588,73. Hay un sobrecoste del 9,5 %, lo que significa que habr´ ıa que vender 140 copias m´ as de las esperadas para cubrir los gastos del proyecto. Es decir, antes de empezar a generar beneficios tendr´ ıan que venderse 1629 copias. 104 Cap´ ıtulo 8. Conclusiones y trabajo futuro 8.4. Trabajo futuro 8.3.1. Fecha de finalizaci´on Debido a las semanas de retraso por haber padecido COVID-19, el poco tiempo sobrante que ten´ ıa despu´ es de trabajar y estudiar para los ex´ amenes, la fecha final se ha retrasado mucho. La idea principal era trabajar 2 horas cada d´ ıa laboral de la semana pero al final se ha trabajado sobre todo durante el fin de semana por la falta de tiempo. Haciendo que la fecha de finalizaci´ on del desarrollo alcance el 29 de junio. 8.4. Trabajo futuro Durante el desarrollo me he encontrado con varios errores de ejecuci´ on por errores de tipado. GDScript, el lenguaje de desarrollo de Godot, usa tipado din´ amico y no avisa si se asignan valores con el tipo incorrecto hasta que se da el error en tiempo de ejecuci´ on. Es cierto que en futuras versiones est´ an implementando tipado opcional pero no es tan seguro como podr´ ıa ser el tipado est´ atico. Por esa raz´ on me plantear´ ıa usar C# para futuros proyectos con este motor de videojuegos. Otra cosa importante ser´ ıa la utilizaci´ on de bases de datos para almacenar la informaci´ on. Si bien es cierto que con la poca cantidad de objetos que hay no merec´ ıa la pena, si se sigue trabajando en el proyecto esto ayudar´ ıa a escalar m´ as f´ acilmente. M´ as de una vez me he confundido poniendo el id de los objetos en los JSON relacionados y han fallado cosas porque no encontraba el id. Una mejora interesante ser´ ıa utilizar el nodo de Godot VisibilityNotifier2D. Este nodo permite que no se procesen los objetos si no est´ an dentro de la c´ amara. Ser´ ıa una buena optimizaci´ on y adem´ as har´ ıa que al llegar a las ´ ulitmas salas del nivel 2, las babosas no estuvieran todas ya en el suelo, por los saltos que han ido dando hasta que el jugador ha llegado. Tambi´ en ha sido muy constructivo pedir feedback a la gente que quer´ ıa probar este juego. Me han dado ideas muy buenas con las que mejorar, como: La magia es demasiado poderosa porque de un solo ataque puedes acabar con todos los enemigos del suelo, ya que la magia traspasa enemigos y paredes. Habr´ ıa que aumentar la fricci´ on contra el suelo del personaje para que 105 Cap´ ıtulo 8. Conclusiones y trabajo futuro 8.4. Trabajo futuro desacelere m´ as r´ apido al moverse. Puede dar una sensaci´ on como andar sobre el hielo tal como est´ a. Si te mueves durante las animaciones de ataque los pies no se mueven as´ ı que parece que vuelas. Al crear cosas como flechas estar´ ıa bien poder crear varias a la vez en lugar de tener que ir de una en una. A˜ nadir personalizaci´ on al personaje, para cambiarle el g´ enero, color de piel, pelo o ropa. En resumen, el esfuerzo invertido ha merecido la pena con el producto final que se ha obtenido. Me produce mucha alegr´ ıa haber acabado mi etapa universitaria con un proyecto as´ ı. 106 Anexo A Manuales Condici´on para ganar: avanzar por los niveles hasta llegar al nivel final y derrotar al jefe final. Condici´on para perder: los puntos de vida del personaje llegan a cero. Si esto ocurre la partida se termina y se de opci´ on de empezar de nuevo o salir. A.1. Controles Se utiliza el teclado y el rat´ on. A D : mover al personaje izquierda o derecha. W: pasar a la siguiente pantalla cuando se ha llegado al final del nivel. Espacio : saltar, dos pulsaciones para doble salto. Tab : abrir/cerrar inventario. N´umeros del 1al 6o rueda del rat´on: sujetar un objeto concreto entre los disponibles en la barra de acci´ on. Mover el rat´on: mueve la c´ amara. Click izquierdo del rat´on: ataque principal. 107 Anexo A. Manuales A.2. Ordenar inventario de objetos Click derecho del rat´on: ataque secundario que varia dependiendo del arma. A.2. Ordenar inventario de objetos Despu´ es de abrir el inventario con Tab : Reordenar objetos: clic sobre el objeto para cogerlo y click sobre otra casilla para dejarlo o intercambiarlo por el objeto que halla. Apilar objetos: dejar un objeto sobre otro del mismo tipo. Dividir objetos: con un objeto agarrado pulsar click derecho sobre la casilla deseada para dejar el objeto de uno en uno. Eliminar objeto: dejar un objeto sobre la casilla con el icono de cubo de la basura. A.3. Combinaciones Las combinaciones de objetos permiten obtener objetos nuevos. Realizar combinaciones es vital para obtener equipo m´ as defensivo, realizar m´ as da˜ no a los enemigos u obtener pociones curativas. A.3.1. C´omo combinar objetos Hay que pulsar TAB para abrir el inventario. Si se poseen objetos capaces de combinarse aparecer´ a una lista con los resultados de las combinaciones posibles debajo del inventario. Al clickar sobre una combinaci´ on se restar´ an autom´ aticamente los objetos necesarios para crearlo y tendremos el resultado agarrado, que podremos posicionarlo en el hueco deseado del inventario. 108