Universidad Politécnica de Madrid

Escuela Técnica Superior de Ingenieros Informáticos

Grado en Ingeniería Informática

Trabajo Fin de Grado

VIDEOJUEGO de PLATAFORMAS 2D en UNITY Autor: Guillermo Bravo Gordo Tutor(a): Ángel Herranz

Madrid, Mayo de 2020

Este Trabajo Fin de Grado se ha depositado en la ETSI Informáticos de la Universidad Politécnica de Madrid para su defensa.

Trabajo Fin de Grado Grado en Ingeniería Informática Título: VIDEOJUEGO de PLATAFORMAS 2D en UNITY Mayo de 2020

Autor: Guillermo Bravo Gordo Tutor:

Ángel Herranz Lenguajes y sistemas informáticos e ingeniería de software ETSI Informáticos Universidad Politécnica de Madrid

i

Resumen Este proyecto de fin de grado está destinado a describir la metodología para el desarrollo de un videojuego de plataformas 2D en Unity.

El proyecto está dividido en tres partes. La primera parte es una introducción en la cual se explican los objetivos propuestos y las motivaciones que han llevado al desarrollo de este proyecto.

La explicación de las diferentes herramientas utilizadas y la descripción de la manera en la que se han llevado a cabo las tareas propuestas constituiría la segunda parte. En esta parte se profundizará sobre las versiones actuales de Microsoft Visual Studio, destinada al desarrollo del código en el lenguaje C#; de la herramienta Pyxel Edit; para el diseño de los distintos elementos gráficos del videojuego; del software Guitar Pro, utilizado para la composición de la banda sonora y efectos sonoros; y por último Unity, que es el programa principal que se va a encargar de la gestión e integración de todos los componentes generados por las anteriores herramientas para dar forma al videojuego. Incluirá también en detalle las mecánicas de juego y el funcionamiento del sistema de combate por turnos.

La tercera parte estaría formada por los resultados que se han obtenido, explicando más en detalle en qué consiste el videojuego creado. En este apartado se hablará sobre la historia del juego, describiendo a los personajes y enemigos que aparecen en la aventura. También se mostrará la ambientación diseñada, incluyendo los paisajes y los distintos elementos gráficos que se encontrarán. Además, se hablará sobre las distintas canciones compuestas para la banda sonora. Por último, se detallará las características gráficas del juego.

ii

Abstract

This Final Year Project is destined to describe the methodology for a 2D Platform game developed in Unity.

This project is divided in three parts. The first part is an introduction, in which the proposed goals and the motivations that have led me to the development of this project are explained.

The explanation of the different tools used, and the description of how proposed task have been carried out would constitute the second part. Here we will go deeper into the current versions of Microsoft Visual Studio, aimed at the development of the code in the language C#; the Pyxel Edit tool, used for the design of the different graphic elements of the game; the Guitar Pro software, used for the composition of the soundtrack and the sound effects; and last Unity, which is the main program that will be in charge of the management and integration of all the components generated by the previous tools to give shape to the game. It will also include in detail the game mechanics and the operation of the turn-based combat system

The third part would be formed by the results that have been obtained, explaining in more detail what the videogame created consist of. In this section, we will talk about the history of the game, describing the characters and enemies that appear in the adventure. It will also show the designed environment, including landscapes and the different graphic elements that will be found. In addition, we will talk about the different songs composed in order to make the soundtrack. Finally, the graphic characteristics of the game will be detailed.

iii

Tabla de contenidos 1 Introducción ......................................................................................1

1.1 Objetivos ............................................................................................ 1 1.2 Estado del arte ................................................................................... 2

1.2.1 Ejemplos de juegos triple A .......................................................... 4 1.2.2 Ejemplos de juegos indies ............................................................ 6

1.3 Motivaciones ...................................................................................... 8 2 Desarrollo ..........................................................................................9

2.1 Herramientas Utilizadas ..................................................................... 9 2.1.1 Microsoft Visual Studio .............................................................. 10

2.1.1.1 UnityEngine ............................................................................ 12 2.1.2 GitHub ....................................................................................... 13

2.1.2.1 SourceTree .............................................................................. 15 2.1.3 Pyxel Edit ................................................................................... 17 2.1.4 Guitar Pro 7 ............................................................................... 18 2.1.5 Unity .......................................................................................... 19

2.1.5.1 UnityHub ................................................................................ 20 2.2 Implementación ................................................................................ 21

2.2.1 Diseños y Animaciones .............................................................. 21 2.2.2 Banda Sonora ............................................................................ 24 2.2.3 Desarrollo en Unity .................................................................... 26

2.2.3.1 Escena Menú Principal ........................................................... 26 2.2.3.2 Escena Opciones ..................................................................... 32 2.2.3.3 Escena Woods ......................................................................... 34 2.2.3.4 Escena Battle .......................................................................... 42

3 Resultados y conclusiones ............................................................... 48 3.1 Contexto del videojuego .................................................................... 48 3.2 Mecánicas del juego ......................................................................... 49 3.3 Diseños y animaciones finales .......................................................... 49

3.3.1 Personajes .................................................................................. 49 3.3.2 Enemigos ................................................................................... 52 3.3.3 Escenarios/Miscelánea .............................................................. 54 3.3.4 Resultados en conjunto .............................................................. 59

3.4 Banda Sonora .................................................................................. 64 3.5 Conclusión ....................................................................................... 65

4 Bibliografía ...................................................................................... 66

1

1 Introducción El proyecto consistirá en el desarrollo de un videojuego de plataformas 2D con un sistema de combate por turnos. Será desarrollado para que pueda ser jugado en PC con teclado y ratón. 1.1 Objetivos

Dado que el desarrollo de un videojuego completo suele durar años, en el caso de una persona el desarrollo puede ser demasiado largo para este proyecto. Por ese motivo, se ha establecido como fin hacer una demostración jugable de un fragmento del videojuego. Para realizar la demostración, se han establecido los siguientes objetivos:

Introducción al entorno de diseño, programación y composición. Incluye aprender a usar las herramientas que se han elegido para el desarrollo.

Definición de la temática y la ambientación del juego. Este objetivo está relacionado con la elección de la época en la que se va a ambientar y el tipo de diseños que se van a hacer.

Desarrollo de las mecánicas del personaje, diseño del nivel y comportamiento de los enemigos. Con este objetivo se trata generalmente la parte de desarrollo de código para permitir que el juego funcione.

Diseño y animación de los entornos, los personajes principales y los enemigos. Este objetivo está centrado en la parte de diseño.

Composición de la banda sonora. Centrado en la parte de composición musical, para que la banda sonora del juego concuerde con la ambientación elegida.

Desarrollo de una demostración del juego. Puesta en común de todos los elementos.

2

1.2 Estado del arte

En la actualidad, existen un sinfín de plataformas para poder disfrutar de los videojuegos, pero las cinco principales son:

PlayStation 4: Desarrollada por Sony y sacada al mercado en 2013. Es una de las consolas con mayor éxito de Sony que, a pesar del próximo lanzamiento de su sucesora la PlayStation 5, sigue teniendo una gran popularidad y lanzamientos de videojuegos exclusivos muy importantes.

Nintendo Switch: Desarrollada por Nintendo y sacada al mercado en 2017. Es una consola innovadora que fusiona el concepto de consola portátil con una consola estacionaria. Todavía le queda mucho recorrido, pero está teniendo una gran acogida gracias a sus exclusivos.

Xbox One: Desarrollada por Microsoft y sacada al mercado en 2013. Una consola con una gran potencia pero que no ha triunfado tanto debido a la posibilidad de jugar a todos sus juegos en PC.

PC: A pesar de no estar diseñado únicamente para jugar a videojuegos, es una de las plataformas más populares para jugarlos. En cuanto a su potencia grafica es muy superior a las demás plataformas.

Móvil: Al igual que en el caso de PC, esta plataforma no fue creada en exclusiva para jugar a videojuegos, y en el caso del móvil es la plataforma con menor potencia, pero dado el uso diario del móvil y la facilidad de portabilidad, es una plataforma muy utilizada para jugar.

Ilustración 1: Logo PS4

Ilustración 2: Logo NS

Ilustración 3: Logo XO

Ilustración 4: Icono PC

Ilustración 5: Icono Móvil

3

Pese a que estas plataformas son las principales actualmente, llegará un momento en el que se queden obsoletas y llegarán otras más actualizadas que las remplazarán. En el caso del PC y el móvil, la plataforma en sí no tiene por qué cambiar, pero los requisitos de hardware aumentarán y se tendrán que mejorar las piezas que componen estas plataformas.

A lo largo de los años, se ha ido mejorando las herramientas para el desarrollo de videojuegos de manera que cada vez se facilita más el trabajo a los desarrolladores. Existen una infinidad de herramientas para el desarrollo de videojuegos, tantas que generalmente las empresas de videojuegos no suelen usar las mismas. Hay empresas que han desarrollado su propio motor de juego, como es el caso de Epic Games, que desarrolló el motor Unreal Engine.

Gracias a estos avances, el desarrollo de videojuegos está al alcance de todo el mundo, ya que el software es gratuito y generalmente bastante intuitivo. Por eso cada vez se crean más empresas independientes con un pequeño grupo de desarrolladores y desarrolladores en solitario que se están dedicando a crear videojuegos para meterse en la industria.

Los juegos creados por las grandes empresas o sus filiales se consideran que son juegos “triple A”, que quiere decir que han tenido un desarrollo con un presupuesto alto y se ha invertido mucho en publicidad. Sin embargo, los juegos creados por empresas independientes o por un solo desarrollador se les llama juegos “indie”, a lo cual se refiere que son juegos que no se rigen por las mismas normas que las empresas grandes. Pero como se ha comentado anteriormente, la principal diferencia entre un juego “triple A” y un “indie” es el tamaño del equipo de desarrollo.

En las siguientes páginas se pondrán algunos ejemplos sobre juegos que han salido en los últimos años por parte de empresas y desarrolladores independientes.

4

1.2.1 Ejemplos de juegos triple A

Persona 5 Royal es una reedición que se lanzó en 2020 sobre el juego Persona 5, el cual salió en 2017. Se trata de un juego triple A desarrollado por la empresa Atlus, una empresa subsidiaria de Sega. El juego es un RPG (rol playing game) con un sistema de combate por turnos que salió en exclusiva para la PlayStation 4.

Fire Emblem: Three Houses es un juego triple A desarrollado por Intelligent Systems y Koei Tecmo en exclusiva para la Nintendo Switch en 2019. Es un RPG táctico con un sistema de combate también por turnos, pero distinto al de Persona 5.

Ilustración 6: Persona 5 Royal

Ilustración 7: Fire Emblem Three Houses

5

Gears of War es un juego triple A desarrollado por Epic Games en exclusiva para Xbox 360 en 2006 y posteriormente se lanzó en PC en 2007. El juego es un juego de acción a tiempo real.

One Piece Treasure Cruise es un juego triple A desarrollado por Bandai Namco Entertainment exclusivamente para móviles en 2015. Está basado en el anime One Piece y su jugabilidad es parecida a la de un RPG por turnos.

Ilustración 8: Gears of War

Ilustración 9: One Piece Treasure Cruise

6

1.2.2 Ejemplos de juegos indies

Undertale es un juego indie desarrollado por Toby Fox para PC en 2015, posteriormente saldría en las otras plataformas. Es un RPG por turnos como el Persona 5, pero su diseño es pixel art.

The Messenger es un juego indie desarrollado por Sabotage Studio para PC en 2018, posteriormente saldría en las otras plataformas. Es un juego de plataformas en 2D con acción a tiempo real.

Ilustración 10: Undertale

Ilustración 11: The Messenger

7

Dead Cells es un juego indie desarrollado por Motion Twin para PC en 2017, posteriormente saldría en las otras plataformas. Es un juego Roguelike en 2D, es decir, es un subgénero de los RPG que consiste en superar mazmorras de generación pseudoaleatoria.

Hotline Miami es un juego indie desarrollado por Dennation Games para PC en 2012, posteriormente saldría en las otras plataformas. Es un juego de acción en 2D con acción a tiempo real y vista cenital.

Ilustración 12: Dead Cells

Ilustración 13: Hotline Miami

8

1.3 Motivaciones Siempre me ha interesado la idea de desarrollar un videojuego, porque es un gran reto a nivel de programación. En la carrera no he cursado ninguna asignatura que utilizase Unity ni el lenguaje C#, esto aumentó mis ganas de utilizar esta herramienta para aprender el lenguaje y poder aprender a desarrollar videojuegos.

La decisión de que el juego fuese 2D vino sobre todo por la carencia de habilidades artísticas, el apartado de diseño de un juego 2D me parecía más sencillo de realizar y me ayudaba a centrar mis esfuerzos en la programación que es el objetivo principal de aprendizaje.

Al tomar esta decisión, pensé en un juego llamado Child of Light, el cual es un juego de plataformas 2D con un sistema de combate por turnos. Dado que no conozco muchos juegos con esas características, me pareció un reto interesante realizar un juego que mezclase las características de los juegos de plataformas con el sistema de combate de los RPG por turnos.

La banda sonora también es un factor importante a la hora de desarrollar un videojuego, por eso también pienso que es necesario para el desarrollo de la demostración que se va a realizar en este proyecto.

Ilustración 14 Child of Light

9

2 Desarrollo

Esta sección estará dedicada a la descripción del proceso para desarrollar el videojuego con las distintas herramientas.

2.1 Herramientas Utilizadas

Para poder realizar el proyecto, se ha tenido que escoger distintos programas para poder completar las tareas marcadas por los objetivos. A continuación, voy a describir las siguientes herramientas que he elegido para este desarrollo. Las cuales han sido:

1. Microsoft Visual Studio 2. SourceTree (GitHub) 3. Pyxel Edit 4. Guitar Pro 7 5. Unity

10

2.1.1 Microsoft Visual Studio

Ilustración 15: Logo Visual Studio

Microsoft Visual Studio es un entorno de desarrollo creado por Microsoft en 1997 y desarrollado en C# y C++ que es compatible con diversos lenguajes de programación como C#, C++, Java, Python, Visual Basic .NET, F#, PHP y Ruby.

En este IDE se han desarrollado los C# Scripts que controlan el comportamiento de los GameObjects en Unity. Para ello se ha utilizado la versión 15.8.1 de Microsoft Visual Studio Community 2017, que es la que emplea por defecto la versión escogida de Unity para el desarrollo de los Scripts.

Esta comunicación es posible dado que al crear un script en Unity y abrirlo en Microsoft Visual Studio, se crea una plantilla de script que importa la librería “UnityEngine”, que es la que se encarga de realizar las llamadas a las APIs de Unity para la comunicación con el proyecto de Unity.

Ilustración 16: Plantilla Script de Unity

11

La depuración del código se realizará en conjunto con Unity. Para ello hay que seleccionar en la interfaz de Visual Studio la opción “Asociar a Unity y Jugar” como se ve en la Ilustración 17.

Ilustración 17 Botón Asociar a Unity y Jugar

Al hacer esto, si se pone algún punto de ruptura o breakpoint en el código, cuando llegue a ese punto de la ejecución el juego parará y se podrá comprobar el estado del script en la consola de Visual Studio. Si el Visual Studio no está asociado a Unity, aunque Unity llame al Script con un breakpoint, este no se parará, ni se verá la información en la consola.

Las variables públicas que se declaren en un script podrán ser asignadas en el programa Unity antes de la ejecución de este, así como los métodos públicos podrán ser utilizados por los componentes que estén en el mismo GameObject que el script.

En el ejemplo que tenemos en las ilustraciones 18 y 19, podemos ver que en el script ChangeScene hay declarada una variable music y un método LoadNextScene ambos públicos. En la ilustración 18 podemos observar que el script y el botón están en el mismo GameObject y que el botón, en el método OnClick, utiliza el método LoadNextScene de ChangeScene. Además, la variable music está inicializada con el objeto Audio Source.

Ilustración 19 Código Ejemplo cambio escena

Ilustración 18 Unity Ejemplo cambio escena

12

2.1.1.1 UnityEngine

Es la principal librería de Unity, la cual permite que los scripts puedan implementar las funciones que nos proporciona Unity para establecer el comportamiento de los GameObjects a los que se les añade este script como componente.

La principal clase de esta librería, la cual deben llevar todos los scripts (en el caso de que existiese herencia entre clases, con que la clase padre implemente esta clase es suficiente), es la clase MonoBehaviour.

Esta clase tiene muchas funciones para facilitar el desarrollo de las funcionalidades, pero las cuatro principales que más se han utilizado durante el desarrollo de este proyecto son las siguientes:

Awake: Es la primera función a la cual se llama (si existe) en cualquier script. Se llama a esta función independientemente de si el script está habilitado o no, y solo será llamada una vez en la vida útil del GameObject.

Start: Esta función funciona de una manera similar a Awake, pero la mayor diferencia es que Start no es invocada hasta que el componente es habilitado, es decir, si un GameObject se instancia sin el componente del Script habilitado, se llamará a la función Awake, y cuando se habilite el componente se llamará a Start. Si el GameObject se instancia con el componente script habilitado, se llamará a Awake e inmediatamente a Start. Esto es útil por si se quiere hacer una configuración previa a la instancia del script. Al igual que el método Awake, la función Start será llamada una sola vez en la vida útil del GameObject.

Update: Este método será llamado una vez por fotograma, pero los fotogramas no tienen por qué procesarse en el mismo intervalo de tiempo, por lo que Update no se llama con un periodo regular. Su utilidad es para realizar cambios sobre el GameObject comprobando su estado en cada frame.

FixedUpdate: Es un método similar a Update, pero en vez de llamarse cada fotograma, se llama con un periodo regular. Es útil cada vez que se quiera hacer una comprobación que requiera una mayor precisión en el tiempo.

También se ha hecho uso de otras funciones de esta librería, pero se especificará su uso más adelante.

13

2.1.2 GitHub

GitHub es una plataforma de desarrollo colaborativo que permite la creación de repositorios para el control de versiones de un proyecto. Esto permite que varias personas trabajen sobre el mismo proyecto sin sobrescribir el trabajo y mantener versiones anteriores del código.

Hay diversos métodos para crear el repositorio y empezar a gestionar las versiones de los archivos, pero este es el que he usado yo. Lo primero que hay que hacer es crear una cuenta de GitHub en la web y, una vez hecha, crear un nuevo repositorio. Esto nos creará una carpeta virtual en la nube que nos permitirá controlar los cambios de los archivos que metamos dentro. A continuación, para pasar la carpeta al local y, hay que utilizar el comando de git “clone”, al cual habrá que pasarle la ruta del repositorio creado anteriormente y pasar por un método de autenticación. Una vez hecho esto, cualquier cambio dentro de la carpeta local se reflejará como “not staged” o no preparado, pero ya tendremos esa carpeta virtual en nuestro repositorio local.

Antes de explicar el funcionamiento de los distintos comandos de Git, hay que entender diversos conceptos de git. El primer concepto del que voy a hablar coincide con el nombre de un comando, se trata del concepto de “commit”. Commit es un objeto o versión que se crea al realizar el comando commit, que lo que hará es actualizar la versión anterior con los nuevos cambios que estén “staged” o preparados. Si realizas este comando con cambios que no han sido preparados, te dará la opción de prepararlos o omitirlos para subir la nueva versión sin esos cambios.

Teniendo claro el concepto de commit, es necesario conocer también el concepto de rama. Una rama es un puntero que contiene la dirección de memoria de un commit. Siempre que trabajemos en un repositorio Git estaremos haciendo cambios sobre la rama en la que estemos actualmente. Normalmente, se utiliza un conjunto de extensiones llamadas Git-Flow que genera unas ramas por defecto para trabajar sobre ellas. Al no conocer Git-Flow antes y solo estar trabajando una persona en este proyecto, no he realizado muchos cambios de ramas, pero estas son las dos ramas principales creadas:

Ilustración 20: Logo GitHub

14

Máster: Es la rama principal, sobre la cual debe estar la versión estable del código.

Develop: Es la rama sobre la cual se realiza el desarrollo del proyecto, esta rama tendrá una carpeta de subramas hijas llamadas Features. Dentro de esta carpeta se crearán ramas con las funcionalidades que se estén desarrollando en el momento y, cuando se haya acabado el desarrollo de esa funcionalidad, se llevará el trabajo realizado a la rama Develop.

Ya hemos hablado de los comandos clone y commit, pero, como he mencionado anteriormente, Git tiene diversos comandos que nos ayudan a gestionar las versiones.

Push: Este comando permite subir los commits realizados en local en la rama actual al repositorio remoto.

Pull: El comando Pull actualiza en local la rama a la que estemos apuntando con los posibles cambios que se hayan realizado en remoto.

Branch: Permite crear una nueva rama a partir de la que se está apuntando en el momento.

Merge: Sirve para pasar el contenido de una rama a otra.

Los comandos pueden generar conflictos en los archivos que habrá que solucionar antes de poder continuar. Un posible conflicto puede ocurrir cuando en dos ramas distintas se trabaja sobre el mismo archivo, eso ocasionará que git no pueda decidir cuál de los dos cambios debe quedarse, y tocará hacer esa decisión al usuario.

Para usar los comandos de Git en Windows es necesario tener la consola Git Bash, pero existe la alternativa de utilizar una GUI (interfaz gráfica de usuario). Existen muchas clientes de escritorio Git distintos que te permiten controlar repositorios Git, pero la que he escogido yo es SourceTree.

15

2.1.2.1 SourceTree

SourceTree es un cliente de escritorio Git y Mercurial desarrollado por Atlassian en 2013. A pesar de que también permita Mercurial, ha sido utilizado única y exclusivamente como cliente Git.

Se eligió esta herramienta debido a que es gratuita y permite trabajar sobre repositorios privados. Aparte, la interfaz es muy sencilla e intuitiva, te permite ver con facilidad el histórico de commits en las distintas ramas en la pestaña “History”.

En la pestaña “File Status” se puede ver los archivos que están preparados, cambiar su estado y realizar un commit. Como se ve en la ilustración 5, los comandos Push, Pull, Branch, etc. Se pueden realizar en el GUI pulsando el botón del comando.

Ilustración 21: Logo SourceTree

Ilustración 22 Interfaz SourceTree

16

Estos comandos se deberán usar en la rama correspondiente, por ello como se puede ver en la Ilustración 23, en la pestaña Branches podemos ver todas las ramas que tenemos en local, y para cambiar de rama simplemente se hace doble clic en la rama a la que se quiera cambiar. Para realizar un “Merge” de una rama a otra, se debe hacer clic derecho, como se puede ver en la Ilustración 24 y escoger la opción “Merge Branch into current Branch”

Por último, si se quiere utilizar el GUI y además utilizar también algunos comandos en la consola, se puede hacer clic en el botón de terminal y se abrirá la consola Git Bash como se puede ver en la Ilustración 8.

Ilustración 23 Ramas de SourceTree Ilustración 24 Merge de una rama

Ilustración 25 Consola Git Bash

17

2.1.3 Pyxel Edit

Pyxel Edit es una herramienta para realizar diseños en pixel art creada por Daniel Kvarfordt y todavía está en fase de desarrollo.

La elección de este programa fue hecha por la sencillez de su aprendizaje y por la cantidad y calidad de las herramientas, que están centradas en el diseño del pixel.

Con esta herramienta se diseñarán los entornos, objetos, personajes y las animaciones que se meterán posteriormente en Unity. Dado que el programa permite previsualizar las animaciones, se hará más sencilla la corrección de los posibles errores que vayan surgiendo.

Ilustración 26 Logo Pyxel Edit

Ilustración 27 Interfaz Pyxel Edit

18

2.1.4 Guitar Pro 7

Guitar Pro 7 es un editor de partituras y tablaturas que permite la composición de canciones con múltiples instrumentos.

E formato al que se quiere exportar es a MP3, porque es el formato de audio que coge Unity para los objetos de audio. Esta herramienta permite exportar en distintos formatos y MP3 está incluido entre ellos.

Ilustración 28 Logo Guitar Pro 7

Ilustración 29 Interfaz de Guitar Pro 7

19

2.1.5 Unity

Unity es un motor de videojuego creado por Unity Technologies en 2005 y desarrollado en C, C++ y C#. Este motor es gratuito, pero tiene una versión de pago, la cual se ha descartado en el desarrollo del proyecto.

Se ha escogido esta herramienta dado que es una de las más usadas para el desarrollo de videojuegos. Permite la creación de juegos en 2 y 3 dimensiones, pero para el proyecto solo se van a utilizar las funcionalidades hechas para 2 dimensiones.

Con esta herramienta se pone en común el trabajo entre las otras herramientas de trabajo, pudiendo incluir el código desarrollado en Visual Studio, los diseños creados en Pyxel Edit y las canciones compuestas en Guitar Pro.

Ilustración 30 Logo Unity

Ilustración 31 Interfaz de Unity

20

2.1.5.1 UnityHub

UnityHub es un programa que gestiona la descarga y el control de las versiones de Unity de los distintos proyectos que tengas. Permite actualizar tu proyecto fácilmente a una versión anterior y posterior.

Para añadir las versiones de Unity se puede hacer de manera local, incluyendo en el programa las versiones que tengas descargadas, o descargándolas directamente desde la aplicación.

Aparte de estas funcionalidades, también te permite descargar proyectos de ayuda para aprender a utilizar Unity, además de incluir tutoriales.

Para estabilizar el desarrollo del proyecto, a pesar de haber trabajado en distintas versiones, se decidió mantener la versión de Unity 2019.3.9f1.

Ilustración 32 Interfaz UnityHub

21

2.2 Implementación

En este apartado se detalla cómo se han utilizado las distintas herramientas para realizar el desarrollo del proyecto. Principalmente se detallará como se ha ido avanzando por el proyecto y los problemas que han surgido a la hora de la creación de los distintos objetos y scripts en Unity,

Primero se va a realizar una explicación acerca de cómo se ha utilizado la herramienta Pyxel Edit para realizar los diseños y las animaciones. A continuación, se detallará como se ha empleado el programa Guitar Pro 7 para el diseño de la banda sonora. Por último, debido a su gran importancia y extensión, se va a profundizar sobre cómo ha sido el desarrollo en Unity incluyendo también la realización de los scripts de C# realizados en Microsoft Visual Studio.

2.2.1 Diseños y Animaciones

Lo primero que debemos tener en cuenta a la hora de crear un documento, es a que tamaño vamos a diseñar los entornos del videojuego, es decir, en que resolución vamos a trabajar. La resolución en la que se va a realizar el videojuego es 640 x 360 pixeles, pero a la hora de diseñar cosas más pequeñas, vamos a reducir el tamaño por comodidad tanto a la hora de diseñar como a la de exportar. Para explicar el funcionamiento del programa de una manera más sencilla y reducida, se va a hacer un diseño desde “0”. Por lo tanto, vamos a empezar por crear un documento. Al crearlo nos saldrá un recuadro en el cual, como en este ejemplo se va a realizar una animación de cinco fotogramas, habrá que seleccionar 5 columnas y una sola fila de 48x48 px y nos generará lo siguiente:

Ilustración 33: Plantilla para el diseño

22

Lo siguiente que se va a hacer es crear capas para diferencias las distintas partes del diseño. En este ejemplo se va a crear una antorcha, por lo cual se necesitarán tres capas. Una para la antorcha y las otras dos para añadir efectos de luz.

A la antorcha se le dejará los ajustes por defecto, mientas que a los efectos se les bajará la opacidad para que se mezclen con el entorno.

El siguiente paso es crear una paleta de colores para el diseño. A la hora de elegir los colores, siempre surge el problema de que no casen bien los unos con los otros, pero el programa nos facilita una herramienta que nos permite elegir colores equivalentes haciendo clic derecho en el sombreado, brillo, contraste o matiz. Usando esta técnica se creará una paleta de colores, y con esto ya se podría empezar el diseño. En la ilustración 34 se verá la creación de los cinco fotogramas de cada capa y a continuación la unión de estas. Por último, solo falta animarlo, para ello simplemente hay que crear una animación, darle un nombre y una velocidad y seleccionar los tiles usando la herramienta de animación. Con esto hecho ya se podría previsualizar la animación.

Ilustración 34: Diseño de la antorcha por capas y completo

23

A continuación, hay que exportar el diseño y aumentarle el tamaño para que esté en la resolución de 640 x 360 pixeles. Después de esto, se llevará la imagen resultante a Unity para realizar la animación. Para hacer esto hay que abrir el objeto y en el inspector seleccionar el Sprite Mode a Multiple, esto permite que se pueda separar en distintos fotogramas. Tras hacer esto, hay que abrir el Sprite Editor y hacer un Slice seleccionando el campo tipo como GridByCellSide y separar el objeto en cinco partes iguales poniendo el tamaño en ancho dividido entre cinco y el tamaño alto el que viene en la imagen. Este procedimiento se puede ver en la ilustración x.

Tras hacer esto hay que crear una animación seleccionando los cinco sprites generados y dividirlos en el tiempo dependiendo de la velocidad que se quiera dar a la animación. Para que la animación se repita infinitamente hay que activar el flag Loop Time.

A continuación, se crea un AnimatorController al cual se le añade la animación al estado principal, dado que es la única animación que va a tener.

Ilustración 35: Separación en distintos sprites

Ilustración 36: Animación antorcha

24

Por último, se crea un objeto vacío al que se le añade un Sprite renderer con uno de los fotogramas de la antorcha y un objeto animator al que se le añadirá el AnimatorController creado anteriormente. Con esto hecho ya tendríamos la animación lista en Unity.

2.2.2 Banda Sonora

Para desarrollar una canción lo primero que hay que hacer es crear un nuevo archivo en Guitar Pro 7. A continuación, elegir los instrumentos que se quieren utilizar dando clic en el botón + que aparece en la ilustración 38.

Una vez hecho esto, se debe completar la tablatura de cada instrumento:

Ilustración 37: Animator de la antorcha

Ilustración 38: Panel de instrumentos agregados

25

Una vez completadas las tablaturas, se podrá ver en la ilustración 40 que se ha rellenado la barra de cada instrumento con los compases que están escritos.

Esto quiere decir que hasta el compás nueve, en la canción sonarán todos los instrumentos, mientras que en el 10 y en el 12, el Drum kit no sonará. Esto depende de los instrumentos que se quieran utilizar en cada momento de la canción.

Ilustración 39: Ejemplo de tablatura

Ilustración 40: Compases de los instrumentos

26

De este modo podríamos completar la canción y, una vez hecho, se tiene que exportar en formato MP3 para luego incluirlo en los objetos Audio Source de Unity.

2.2.3 Desarrollo en Unity

Para explicar cómo se ha realizado el desarrollo se va a separar en las distintas escenas que se han creado para el juego.

2.2.3.1 Escena Menú Principal

Lo primero que se ha hecho es el menú principal del juego. Para ello se ha creado una nueva escena llamada MainMenu, la cual incorporaba el objeto Main Camera que permite que el jugador pueda ver el contenido en pantalla. Esto es debido a que la escena es un plano tridimensional, a pesar de estar trabajando en 2D, y la cámara está situada en el eje z mirando en dirección al eje z negativo. Como podemos ver en la ilustración 42, la cámara apunta en una dirección, y su proyección es lo que se puede ver en pantalla. En este caso, la cámara está posicionada en el punto z = -10, eso implica que todo lo que esté en un punto inferior no se va a ver en pantalla. Dado que el caballero está en el punto z = 0, se puede ver en el recuadro “Camera Preview” que se visualiza en pantalla. Este objeto Main Camera estará presente en todas las escenas que se creen, pero cambiará en las que precisen de movimiento, como se verá más adelante.

Ilustración 41 Contenido MainMenu

27

A la escena Main Menu también se le añadirá el GameObject EventSystem, que se encargará de enviar eventos a los objetos de una escena dependiendo de la entrada que reciba, ya sea teclado, ratón, mando, etc.

Otro objeto que se ha añadido AudioSource que, como los anteriores, es un objeto predefinido por Unity al cual le puedes incorporar una pista de audio para que se reproduzca en la escena. Dado que queremos que esta pista se reproduzca también en la siguiente escena que se va a explicar, se ha desarrollado un script que permite que el objeto AudioSource permanezca entre las escenas Main Menu y Options, pero que se destruya si se carga cualquier otra escena. Esto da pie a comentar que al cerrar una escena y cargar otra, se eliminaran todos los GameObjects que hubiese en esta a no ser que se use el método DontDestroyOnLoad, que permitirá que ese objeto permanezca entre escenas. Gracias a esta función se va a permitir guardar una persistencia entre escenas, lo cual nos será muy útil en un futuro.

A continuación, para poder empezar a poner los elementos que quieren mostrar en el menú principal, se ha creado un objeto canvas, que es un área donde se incluyen elementos de interfaz, como imágenes o botones. En este caso se va a incluir un objeto imagen, el cual permite incluir un archivo con una imagen, otro canvas para realizar una transición de fade para suavizar la carga inicial de la escena, y tres objetos botón. Al objeto imagen se le va a añadir el fondo que se quiere mostrar. Un objeto botón es aquel que, si el usuario realiza la acción de pulsarlo, recibe el evento y actúa en consecuencia. Los tres botones que va a tener el menú principal son los siguientes:

Ilustración 42 Plano Visión Cámara

28

Play Button: Este botón se encargará de enviar al usuario al nivel jugable,

es decir, se encargará de cargar la siguiente escena. Esto se conseguirá creando un script que tenga un método que haga un cambio de escena y poniendo en el evento OnClick del botón la llamada al método Load NextScene para que realice el cambio con parámetro el nombre de la escena “Woods”. Tendrá un GameObject hijo Text que contendrá el texto “Play” que se mostrará en el botón.

Options Button: Es el botón que cambiará a la escena Options al ser pulsado. El funcionamiento es similar al anterior, pero mandando el parámetro “Options”. Tendrá un GameObject hijo Text que contendrá el texto “Options” que se mostrará en el botón.

Exit Button: Realizará la función de cerrar la aplicación. Para ello se realizará el mismo procedimiento que con los otros botones, pero el método al que llamará el evento OnClick será al ExitAplication, que se encontrará también en el mismo script y hará que la aplicación se cierre. Tendrá un GameObject hijo Text que contendrá el texto “Exit” que se mostrará en el botón.

El canvas para realizar la transición está formado por una imagen en negro y un componente Animator. Este componente permitirá que el objeto tenga animaciones. La animación que se ha creado hace que el objeto imagen empiece con la componente de color A igual a 1, y en un intervalo de un segundo, baja gradualmente a 0 y, al llegar a 0, desactiva la imagen. El componente A se encarga de reflejar la visibilidad de una imagen, cuando tiene valor 1 la imagen se ve perfectamente, a medida que va bajando se hace más transparente hasta que llegar el punto, en 0, que no se puede seguir viendo. Esta animación sucederá al entrar a la escena.

Ilustración 43 Imagen Fade Out t = 0

29

Ilustración 44: Animación Fade Out t = 0

Ilustración 15 Imagen Fade Out t = 0.5

Ilustración 46 Animación Fade Out t = 0.5

30

El último objeto que va a tener esta escena es un GameObject Party, cuyos hijos son dos GameObjets que representarán a los personajes Allard y Maira. Este objeto está creado en esta escena para la inicialización de los personajes, pero no para su instanciación, es decir, en la escena no estarán instanciados. Se decidió incluirlo aquí debido a que es necesario mantener una persistencia de las estadísticas de los personajes.

Mantener persistencia en este proyecto ha sido uno de los mayores retos, debido a que la vida, el maná y la experiencia de los personajes se tiene que mantener entre escenas. Al no hacer esto, después de cada combate los personajes recuperarían toda la vida y el maná perdido y no recibirían ningún punto de experiencia, así que realmente es como si el combate no se hubiese ocasionado.

Para que este objeto funcione correctamente y no moleste en el resto de las escenas, se ha creado un script que contiene un método propio de Unity llamado

Ilustración 47 Imagen Fade Out t = 1

Ilustración 48 Animación Fade Out t = 1

31

OnSceneLoaded. Este método se invoca cuando se carga una nueva escena. A este método se le ha incluido el siguiente código:

private void OnSceneLoaded (Scene scene, LoadSceneMode mode) { if (scene.name == "MainMenu") { SceneManager.sceneLoaded -= OnSceneLoaded; Destroy(this.gameObject); } else { this.gameObject.SetActive(scene.name == "Battle"); } }

Este código hará que el objeto se destruya en la escena MainMenu y que en las demás esté creado pero que solo esté activo en la escena Battle.

El GameObject Party tendrá también como componente otro script, pero al estar relacionado con la escena de batalla, se comentará su utilidad cuando se explique esa escena.

Los hijos de este objeto serán los que contengan la información de cada personaje jugable. Cada uno tendrá como componente un Sprite Renderer, al cual se le pasará un diseño del personaje para mostrarlo en combate, un Animator, que controlará las transiciones entre las distintas animaciones de los personajes, y dos scripts. Por último, tendrán un tag Player, su utilidad se verá en la explicación del sistema de combate.

El primer script funcionará como una base de datos donde se guardará la información sobre las estadísticas de cada personaje. Además, tendrá funciones que se usarán en el combate. El segundo script contendrá la diferenciación a la llamada de ataques físicos y mágicos, aparte de la actualización de la información mostrada en el HUD del combate.

Estos son los objetos que forman la escena MainMenu, cuya visualización sería la de la ilustración 49, a la cual se le ha escondido el objeto de Fade para poder visualizarla ya que, como hemos visto anteriormente, la imagen del objeto Fade tapa la pantalla.

32

Ilustración 49: Escena Menú Principal

2.2.3.2 Escena Opciones

La escena de opciones es a la que se irá cuando el usuario pulse el botón Options en el menú principal.

Como se puede ver, al igual que en la escena Main Menu, tiene un objeto Main Camera y un EventSystem, que serán iguales que en la otra escena.

Ilustración 50 Contenido Options

33

Sin embargo, esta escena tiene dos objetos canvas que podrían haber estado en el mismo objeto, pero se separaron por mayor claridad. El primero lleva la imagen de fondo y un botón aceptar que cambiará los cambios de la configuración y volverá a la escena MainMenu. El segundo lleva un texto en el que pone volumen y una slider, que es un objeto que permite dar un valor en un rango desplazando el botón de un lado a otro.

Esta slider controlará el volumen de la música del juego. Para que esto sea posible, se ha creado un Audio Mixer llamado Game Music, que permite crear un grupo de Audio para controlar todas las pistas que se incluyan en él, y se han añadido todas las canciones a este AudioMixer. La slider controla el campo MusicVolume de Game Music, haciendo que, si la slider está a la derecha del todo, el valor es máximo, haciendo que el volumen sea el más alto posible, y si está a la izquierda del todo el valor es el mínimo, haciendo que no se escuche.

Ilustración 51: Slider para el volumen

Ilustración 52: Escena Opciones

34

2.2.3.3 Escena Woods

Woods es el nivel principal del juego, donde se realizará la acción de plataformas y se podrá controlar libremente al personaje principal. En esta escena el ratón no tiene ninguna interacción.

El objeto EventSystem se mantiene igual que en las otras escenas, y el objeto Audio Source solo modificará la pista que se reproduce.

El objeto Main Camera es distinto al de las demás escenas dado que ahora debemos cambiar su posición a medida que el jugador se mueva por el nivel. Para ello se le ha añadido un componente C# script a la cámara que calcula en cada fotograma la posición de jugador y, si se acerca a uno de los márgenes de

Ilustración 53: Contenido Woods

35

la pantalla, mueve la cámara en esa dirección para que el personaje no salga nunca de la pantalla.

Para añadir el fondo, se ha creado un GameObject Canvas que incluye las dos imágenes que se van a utilizar para el fondo. Como la cámara está en movimiento, hay que marcar el modo de renderizado a Screen Space – Camera y seleccionar la cámara de la escena como cámara de renderizado. Esto provoca que las imágenes se mantengan fijas en la cámara, así que no importa cuánto se mueva el jugador que siempre estará el fondo en pantalla. Las imágenes están ordenadas para que esté una sobre la otra.

El objeto Miscellaneous es un objeto padre cuyos hijos son pequeños objetos decorativos. Estos objetos están en una capa distinta para que no interfiera con el movimiento del jugador, es decir, para que solo sean elementos estéticos. La mayoría de estos objetos solo tienen un Sprite Renderer con la imagen del objeto, pero algunos como Torch o Bonfire tienen una animación que se ejecuta constantemente.

Player es el GameObject más complejo de la escena Woods. Empezando por los componentes físicos del GameObject, se ha establecido una etiqueta “Player” para el objeto, la cual permitirá comprobar si otros objetos están en contacto con Player. Además, se la ha añadido un componente Rigidbody 2D, el cual implementa las físicas del motor al GameObject añadiendo, entre otros elementos, una fuerza gravitatoria y que hace que el objeto caiga. Esto resultará útil para poder saltar y caer sobre el suelo. Por último, se ha añadido un

Ilustración 54: Fondo renderizado en cámara

36

componente Box Collider 2D, cuyo cometido es hacer que el objeto pueda colisionar con otros objetos. La utilidad de este componente es, por ejemplo, que el personaje pueda entrar en contacto con el suelo dado que, sin este componente, Player no tocaría el suelo y, en vez de posarse sobre él, caería al vacío.

En la parte visual, lleva un componente Sprite Renderer con el diseño de Allard (el caballero) y otro componente Animator con un Animator Controller asociado para gestionar las distintas animaciones de Allard. Los cambios de transición se realizan a través de dos variables booleanas IsRunning e IsJumping que se irán cambiando en los scripts. El diagrama de transiciones entre animaciones se puede ver en la ilustración x. El personaje tendrá tres animaciones:

Idle: Es la animación del personaje cuando está en reposo. El personaje empezará con esta animación al entrar a la escena y se repetirá en bucle hasta que haya una transición a otra animación.

Run: Esta animación representa la acción de correr y se activa con un movimiento horizontal, es decir, cuando la variable IsRunning sea igual a true se mantendrá en bucle hasta que deje de serlo o IsJumping sea true.

Jump: La animación de salto que se activa cuando la variable IsJumping es igual a true A esta animación se puede acceder desde cualquier otra, pero desde la animación solo se puede transitar al estado Idle.

37

Para finalizar con Player, se han añadido el script Player_Controller y el script Player_Movement.

void Update() { if (Input.GetAxisRaw("Horizontal") != 0) { anim.SetBool("IsRunning", true); if (Input.GetAxisRaw("Horizontal") > 0) { movement = speed; if (!facingRight) { player.GetComponent<Transform>().Rotate(0f, 180f, 0f); facingRight = true; } } else { movement = -speed; if (facingRight) { player.GetComponent<Transform>().Rotate(0f, 180f, 0f); facingRight = false; } } } else {

Ilustración 55: Diagrama de Animaciones de Allard

38

anim.SetBool("IsRunning", false); movement = 0; } if (Input.GetButtonDown("Jump")) { anim.SetBool("IsJumping", true); jump = true; } } private void FixedUpdate() { playerMovement.Movement(movement, jump); jump = false; }

En este fragmento de código se encuentran las funciones Update y FixedUpdate del script Player_Controller. La función FixedUpdate hace una llamada al método Movement del script Player_Movement con los parámetros movement, al cual le asignaremos el parámetro speed que es la velocidad a la que queremos que se mueva en positivo si avanza a la derecha y en negativo si avanza a la izquierda, y jump, que será una variable booleana que será true cuando el jugador quiera saltar. Como podemos ver, en el método Update se comprueba con la función Input.GetAxisRaw("Horizontal") si el jugador ha pulsado la tecla “A” o la “D”. Antes de comprobar si el jugador que tecla ha pulsado el jugador, si ha pulsado una tecla se activará la animación de correr asignando la variable booleana IsRunning a true. Si el jugador ha pulsado la tecla “A”, su intención es moverse a la izquierda y la función GetAxisRaw devolverá un número negativo, por lo que habrá que asignar un valor negativo a movement. Si ha pulsado la tecla ”D”, su intención es moverse a la derecha y la función GetAxisRaw devolverá un valor positivo, así que movement se asignará al valor positivo de speed. Si no ha pulsado ninguna de esas teclas, GetAxisRaw devolverá un 0, por lo cual se asignará a false el booleano IsRunning para que vuelva a la animación Idle y movement se asignará a 0.

Además, también hay que comprobar si el usuario estaba mirando a la izquierda o a la derecha, dado que habrá que cambiar la orientación de las animaciones para que, por ejemplo, el personaje no se mueva a la izquierda y en la animación esté corriendo hacia la derecha. Para ello está la variable facingRight, la cual será true si está mirando a la derecha y si, intenta moverse a la izquierda, se hará una rotación del personaje para que mire hacia la izquierda y se asignará la variable facingRight a false para que, si intenta moverse a la derecha, se vuelva a rotar.

La función Input.GetButtonDown("Jump")) comprobará si se ha pulsado la tecla “Espacio”. Si se ha pulsado se activarán las variables booleanas IsJumping, para activar la animación de salto, y jump, para realizar la acción de saltar.

Player_Movement realizará el movimiento dependiendo de los valores que reciba del FixedUpdate de Player_Controller. Tiene 6 posibles estados:

39

1. Movement = 0 y Jump = false: El personaje no se moverá en ninguna dirección. Pero igualmente se creará el vector de movimiento sin dirección.

2. Movement = positivo y Jump = false: El personaje se moverá a la derecha con la animación de correr. Para ello se creará un vector que moverá al personaje en dirección al eje X positivo con la velocidad speed. Para suavizar el movimiento, se ha utilizado la función SmoothDamp, la cual hace que la velocidad disminuya progresivamente al dejar de pulsar el botón.

3. Movement = negativo y Jump = false: Es el mismo caso que el anterior, pero moviéndose a la izquierda en vez de a la derecha, es decir, moviéndose en dirección al eje X negativo.

4. Movement = 0 y Jump = true: El personaje realizará un salto vertical sin moverse horizontalmente, es decir, en el eje Y positivo. Para que esto sea posible, la variable booleana IsGrounded tendrá que ser true, y esto solo se dará en el caso en el que el jugador esté en contacto con un objeto con el Tag Ground. Esto evita que se puedan realizar saltos en el aire. Si se cumple esta condición, al vector creado se le añadirá una fuerza vertical que se asignará como variable pública en el script Player_Movement. Esta acción se realizará con la animación de salto y, al caer al suelo, se asignará la variable IsJumping a false para volver a la animación Idle.

5. Movement = positivo y Jump = true: Funciona de la misma manera, solo que el salto se realizará en diagonal, dado que el vector se moverá en los ejes X e Y positivos. La animación que se utilizará será la de salto.

6. Movement = negativo y Jump = true: Igual que la anterior, pero el movimiento se realizará en el eje X negativo y en el eje Y positivo.

Volviendo con los demás elementos de la escena, se puede encontrar un objeto grid que contiene el objeto tilemap. Estos dos objetos componen el escenario del nivel.

40

Para construir un escenario con Tilemap se necesita crear el objeto Grid con el hijo Tilemap y posteriormente crear una paleta donde añadir los tiles como la que se puede ver en la ilustración x. Cada cuadrado es un Tile por lo que, para generar el escenario, se debe ir cogiendo los tiles y pintándolos con la brocha en el Tilemap.

Creado el Tilemap, ya estaría listo el escenario, a falta de añadir un Collider para que el Player pueda apoyarse en el suelo. Por eso se ha añadido un Tilemap Collider 2D. También se le ha añadido un Tag Ground para poder comprobar que el jugador está tocando el suelo.

Ilustración 56: Fragmento de escenario

Ilustración 16: Fragmento deescenario separado en Tiles

Ilustración 59: Paleta de Tiles de Suelo

Ilustración 58: Tilemap

41

Para finalizar de comentar el contenido de esta escena, se hablará de los objetos generadores SkelletonGenerator, OwlGenerator y FungusGenerator. Cada uno de estos GameObjects tendrá su Sprite Renderer con su diseño y un Animator con la animación de Idle que le corresponda a cada uno. La importancia de estos objetos es el script GenerateEnemy que tienen asociado. Este script recibe un objeto enemyParty que, al igual que el objeto Party comentado en la escena MainMenu, contiene la información sobre los distintos enemigos. La diferencia es que enemyParty es un objeto prefabricado que no ha sido inicializado ni instanciado. Cada objeto generador tendrá asociado una “Party” que incluirá uno o dos enemigos distintos.

El script tendrá un método Start que hará que el objeto no se destruya entre escenas. También tendrá un método onTriggerEnter2D, el cual se lanzará cuando el enemigo entre en colisión con otro objeto. Si el objeto con el que entra en contacto tiene la etiqueta Player, carga la escena de batalla y activa un booleano para que el otro método pueda instanciar la enemyParty. El último método que tiene este script es OnSceneLoaded, que será invocado cuando se cargue una nueva escena y, si la escena es Battle, creará una instancia de enemyParty para la batalla y eliminará el objeto generador.

Ilustración 60: Fragmento de la Escena Woods

42

2.2.3.4 Escena Battle

Battle es la última escena que se ha desarrollado y la que mayor carga de trabajo ha tenido, dada la necesidad del planteamiento del sistema de combate.

Como las demás escenas, tiene un componente Main Camera, EventSystem y Audio Source. Main Camera será fija, por lo que será igual que en Main Menu y Options. EventSystem se mantendrá como en las demás escenas. Mientras que Audio Source en esta escena también tendrá una canción distinta.

Como se puede observar, tiene un objeto HUDCanvas y un objeto Canvas. Canvas solo contiene una imagen, la cual es el background del escenario de batalla. El objeto HUDCanvas contiene la información de las unidades aliadas y las posibles acciones que se podrán realizar. El objeto imagen contiene el background que se ha diseñado para el HUD. El objeto info contiene la información en el momento de las estadísticas Health y Mana de los personajes.

Ilustración 61: Contenido Battle

43

HUDCanvas tiene también un objeto hijo Actions, el cual incluye las acciones que podrá realizar cada personaje principal en su turno. Las acciones están representadas por estos cuatro botones:

Attack: Es el botón que representa la acción de ataque físico a un enemigo. Contiene un script que llama a la selección de unidad enemiga con el parámetro de ataque físico para realizar el ataque.

Magic: Botón que realiza un ataque mágico a un enemigo. Estos ataques implican gasto de mana. El componente script que lleva llama al script SelectUnit al igual que el botón anterior, pero el parámetro que se envía es el de ataque mágico.

Defend: Esta acción da a los aliados +1 de defensa para el resto del combate. Contiene un script que aumenta el parámetro defenseInBattle de los aliados.

Flee: Este botón permite a los jugadores escapar del combate. El script que contiene carga la escena Woods.

También tiene un objeto hijo EnemyMenu, cuyos hijos se generarán cuando se decida realizar un ataque físico o mágico. Este objeto contendrá los posibles objetivos para realizar el ataque, y para seleccionar el objetivo que desea, el usuario deberá hacer clic sobre la imagen del enemigo que aparece en el HUD.

El objeto BattleSystem contiene el script que controla el sistema de combate por turnos para que se pueda realizar correctamente. Para explicar el script se va a detallar como se ha querido plantear el sistema de combate.

Al cargar la escena, aparte de los objetos explicados, se instanciará el objeto Party creado en Main Menu con los dos hijos que representan a los personajes principales, con el Tag Player como se ha mencionado anteriormente. También se instanciará el objeto Party de los enemigos, para que quede más claro en el ejemplo vamos a decir que este objeto se llama OwlParty y que contiene dos hijos, un Objeto que representará a un enemigo Owl y otro a un enemigo Skelleton. Ambos contendrán los mismos componentes, lo único que cambiará serán las estadísticas, el Sprite render y las animaciones. Los componentes que tendrán serán un Animator, un Sprite Renderer, un script UnitStats similar al de los personajes principales, un script KillEnemy que eliminará el objeto cuando su vitalidad sea igual o inferior a 0, un script Enemy Action con las posibles acciones del enemigo y por último un script Create Enemy Menu, que

Ilustración 62: Visualización Objeto Info

44

permitirá rellenar el objeto EnemyMenu del HUDCanvas para poder seleccionar al enemigo como objetivo del ataque.

Para controlar el sistema por turnos, se va a crear una lista ordenada por la estadística velocidad de todos los objetos que tengan el tag Player o el tag Enemy. Esto generará una lista como la siguiente:

La lista funcionará como una fila, es decir, tendrá un funcionamiento LIFO (Last In First Out). Por ello, cuando un personaje termine su turno, se le sacará de la lista y se le volverá a incluir, lo que hará que los turnos siempre estén ordenados de la misma manera en el combate. Cada vez que termine un turno, se enviará un evento para que se pase al siguiente turno y se actualice la tabla.

En su turno, cada jugador principal podrá realizar las acciones simbolizadas por los botones del HUDCanvas. Por lo que el jugador, en el turno de uno de sus personajes, tendrá que pulsar el botón con la acción que quiera realizar y, si es una acción de ataque físico o mágico, elegir el objetivo. En el turno de los enemigos, siempre se realizará un ataque a un personaje principal aleatorio, si el ataque es mágico o físico dependerá de la configuración del enemigo.

Cuando un enemigo o un aliado sean derrotados, se eliminará la instancia del combate. Esto hará que desaparezcan de la lista de turnos de manera que, si en la tabla anterior el enemigo Owl fuese derrotado, la lista se transformaría en la siguiente:

El sistema de combate será un bucle infinito que funcionará pasando los turnos de la manera anteriormente explicada. Se tiene que dar una de las siguientes condiciones para que el combate pare:

Todos los enemigos han sido derrotados. Esto hará que el combate haya tenido éxito, y los personajes recibirán la experiencia por haber acabado con los enemigos. Además, subirán de nivel si llegan a la experiencia

Posición 1: Maira

Posición 2: Owl

Posición 3: Allard

Posición 4: Skelleton

Posición 1: Maira

Posición 2: Allard

Posición 3: Skelleton

45

necesaria. Subir de nivel incrementará las estadísticas. Al realizarse esto, se regresará a la escena de Woods para continuar la aventura.

Todos los aliados han sido derrotados. Esta condición provocará que la demostración del juego acabe y se vuelva al Main Menu.

Se ha pulsado la acción Flee. Lo cual implicará que se salga del combate sin recibir experiencia.

Este es el planteamiento del sistema de combate, pero para que pueda funcionar se han tenido que crear diversos scripts que permitan este funcionamiento.

Como se ha mencionado anteriormente, el script BattleSystem del objeto BattleSystem es el que se encarga de gestionar los turnos, así que vamos a explicar su funcionamiento.

Tiene un método Start el cual inicializará los valores de información del objeto Info del HUDCanvas, estableciendo la vida y el maná actual de los personajes principales. También se encargará de inicializar el parámetro defenseInCombat para poder aumentar la defensa de los aliados solo en el combate. A continuación, buscará los objetos con tag Player o Enemy en la escena para meterlos en una lista y después los ordenará dependiendo de la estadística Speed de cada uno. Por último, llamará a su propio método nextTurn, al cual se llamará al final de cada turno.

El método nextTurn comprobará si existen enemigos y si existen aliados. Si no existen enemigos, comprobará el objeto EnemyParty para coger el parámetro experiencia y la sumarlo a la experiencia de los aliados. Si los aliados suben de nivel, aumentará sus estadísticas dependiendo del personaje. Está acción se hace llamando al método giveExp del script CollectExperience. Tras hacer esto, secargará la escena Woods para continuar el juego. Si existen aliados y enemigos, lo primero que hace es eliminar al primero de la lista y comprobar si ha muerto. Si ha muerto se vuelve a llamar a nextTurn para volver a comprobar si existen aliados y enemigos. Si sigue vivo, se añade a la lista en la última posición. Por último, se comprueba si la unidad es Player o Enemy. Si es Player se mantiene a la espera de realizar una acción. Si es Enemy, llama al método act de su script Enemy Action, el cual selecciona un Player aleatorio y lo ataca llamando al método Attack del script AttackTarget, el cual calculará el daño multiplicando la estadística ataque del Enemy por un valor aleatorio de 0 a 1, siendo el daño máximo el valor de ataque. Al hacer esto, activa la animación de ataque del enemigo. A este daño se le resta la defensa del objetivo, y tras hacer esto se realiza una llamada al método damage del script UnitStats del objetivo del ataque para reducir su vida con el resultado del ataque y, si su vida es menor o igual a 0, se activa una variable booleana Dead a true, la cual se comprueba en el método isDead() de nextTurn. Por último, se mostrará en pantalla el daño recibido a través de la impresión de un texto encima del aliado dañado. El código de nextTurn es el siguiente:

46

public void nextTurn() { GameObject[] enemies = GameObject.FindGameObjectsWithTag("Enemy"); if (enemies.Length == 0) { this.enemyParty.GetComponent<CollectExperience>().giveExp(); SceneManager.LoadScene("Woods"); } GameObject[] players = GameObject.FindGameObjectsWithTag("Player"); if (players.Length == 0) { SceneManager.LoadScene("MainMenu"); } UnitStats actualUnitStats = unitsStats[0]; unitsStats.Remove(actualUnitStats); if (!actualUnitStats.isDead()) { GameObject currentUnit = actualUnitStats.gameObject; unitsStats.AddLast(actualUnitStats); if (currentUnit.tag == "Player") {

this.party.GetComponent<SelectUnit>().selectCurrentUnit(currentUnit.gameObject);

} else { currentUnit.GetComponent<EnemyAction>().act(); GameObject unitAllard = GameObject.Find("Allard") as GameObject; GameObject allardHealth = GameObject.Find("Allard Health") as GameObject; allardHealth.GetComponent<Text>().text = Math.Round(unitAllard.GetComponent<UnitStats>().health).ToString(); GameObject allardMana = GameObject.Find("Allard Mana") as GameObject; allardMana.GetComponent<Text>().text = Math.Round(unitAllard.GetComponent<UnitStats>().mana).ToString(); GameObject unitMaira = GameObject.Find("Maira") as GameObject; GameObject mairaHealth = GameObject.Find("Maira Health") as GameObject; mairaHealth.GetComponent<Text>().text = Math.Round(unitMaira.GetComponent<UnitStats>().health).ToString(); GameObject mairaMana = GameObject.Find("Maira Mana") as GameObject; mairaMana.GetComponent<Text>().text = Math.Round(unitMaira.GetComponent<UnitStats>().mana).ToString(); } } else { this.nextTurn(); } }

47

Cuando el turno es de un aliado y pulsa el botón de ataque o magia, desaparecerán los botones y en su lugar aparecerá una imagen con cada enemigo en el combate, el jugador deberá hacer clic sobre una de las imágenes para confirmar el objetivo del ataque. Al hacer esto, se realizará el mismo procedimiento que en el caso de los enemigos, llamando al método Attack del script AttackTarget, calculando el daño y activando la animación de ataque físico o mágico. Después se llamará al método damage del script UnitStats del objetivo para reducir su vida y comprobar si el objetivo ha muerto o no.

Por último, el animator de los personajes principales será igual, y las animaciones que no sean la de Idle tendrán el mismo nombre, eso permitirá la activación de la animación desde el método Attack del script AttackTarget. El de los enemigos también será igual, pero solo tendrán la animación de Idle y la de ataque. Las transiciones son unidireccionales porque no se va a cambiar de animación dependiendo de una variable, sino que se va a invocar directamente la variable con el método Play del objeto Animator, pasando como parámetro el nombre de la animación.

Ilustración 63: Animator de Maira en Battle

48

3 Resultados y conclusiones

El resultado ha sido satisfactorio, se han cumplido todos los objetivos propuestos, terminando con la creación un de archivo ejecutable con la demostración completa del juego. El ejecutable se podrá iniciar en ordenadores Windows, Mac y Linux, con una resolución fija de 640x360.

En la ilustración 64 se podrá ver como es el diagrama de transición entre las distintas clases, es decir, los cambios de escena que se realizarán según las acciones del usuario.

3.1 Contexto del videojuego

Knight´s Hope es un juego de plataformas y role-playing game (RPG) en 2D de “scroll lateral”.

La historia te sitúa en un mundo medieval fantástico en el cual controlas a Allard, un caballero retirado que, debido a la supuesta muerte de su familia, decide salir al mundo en busca del culpable de la situación.

Ilustración 64: Diagrama Escenas

49

El juego comienza con el incendio de la granja en la que vive la familia de Allard, provocando que Allard crea que su familia ha muerto. Pero ve a lo lejos a un caballero montado a caballo que parece que se aleja de la granja como si estuviese escapando. Esto empuja a Allard a perseguir al caballero y provocar que se inicie la aventura.

La demostración se sitúa en un punto del juego en el cual Allard se ha reencontrado con su hija Maira, la cual es hechicera. Juntos tienen que atravesar un bosque repleto de enemigos para llegar a una caverna, en la cual se rumorea que se ha visto a un niño pequeño y que está custodiada por el jefe del bosque Fungus. El motivo de querer ir a esa caverna es que piensan que el niño puede ser el hijo de Allard, Godwin, el aprendiz de cazador.

3.2 Mecánicas del juego

Se ha cumplido con el desarrollo de las mecánicas de juego planteadas. En la escena Woods, el jugador puede mover libremente al personaje y saltar.

La principal mecánica del juego, es decir, el sistema de combate por turnos se ha desarrollado también correctamente, como se ha ido describiendo en el apartado de desarrollo. Sin duda ha sido el mayor reto que ha tenido este proyecto.

En las demás escenas solo se puede pulsar los botones que aparecen y, en el caso de Options, subir y bajar el volumen.

3.3 Diseños y animaciones finales

En este apartado se mostrará el conjunto de diseños y animaciones que se han realizado para el proyecto. Se va a dividir en cuatro apartados: Personajes, Enemigos, Escenarios/Miscelánea y Resultados en conjunto

3.3.1 Personajes

El primer personaje del que se va a enseñar los diseños es Allard, el caballero protagonista del juego. Este personaje tiene seis animaciones, tres de ellas para la escena Woods y las otras tres para Battle.

Ilustración 65: Animación Idle de Allard en la escena Woods

50

Ilustración 66: Animación Run de Allard en la escena Woods

Ilustración 67: Animación Jump de Allard en la escena Woods

Ilustración 68: Animación Idle de Allard en la escena Battle

Ilustración 17: Animación Attack de Allard en la escena Battle

Ilustración 70: Animación Magic de Allard en la escena Battle

51

Maira la hechicera, hija de Allard, será el siguiente personaje del cual se va a mostrar las animaciones. Se han desarrollado cuatro animaciones para el combate.

Ilustración 72: Animación Idle de Maira en la escena Battle

Ilustración 73: Animación Attack de Maira en la escena Battle

Ilustración 74: Animación Magic de Maira en la escena Battle

Ilustración 75: Animación Defend de Maira en la escena Battle

Ilustración 71: Animación Defend de Allard en la escena Battle

52

3.3.2 Enemigos

Se han desarrollado tres enemigos para esta demostración. Los tres tendrán dos animaciones para la escena de Battle y para la de Woods utilizarán la misma animación de Idle. El primero que se va a mostrar es el búho (Owl).

El siguiente enemigo que se va a mostrar es el esqueleto (Skelleton).

Ilustración 76: Animación Idle de Owl

Ilustración 77: Animación Attack de Owl en la escena Battle

Ilustración 78: Animación Idle de Skelleton

Ilustración 79: Animación Attack de Skelleton en la escena Battle

53

Por último, se va a mostrar las animaciones de Fungus, el esqueleto gigante y jefe del nivel.

Ilustración 80: Animación Idle de Fungus

Ilustración 18: Animación Attack de Fungus en la escena Battle

54

3.3.3 Escenarios/Miscelánea

Esta sección incluye todos los demás diseños que se han realizado para el proyecto.

Ilustración 82: Fondo de la escena Main Menu

Ilustración 83: Fondo de la escena Options

55

Ilustración 84: Fondo de la escena Woods

Ilustración 19: Fondo superpuesto de la escena Woods

56

Ilustración 86: Conjunto de Tiles para el suelo de Woods

Ilustración 88: Conjunto de arbustos

Ilustración 87: Animación de antorcha encendida

Ilustración 89: Cofre

57

Ilustración 90: Animación de una hoguera

Ilustración 91: Conjunto de vallas

Ilustración 92: Conjunto de Jarrones

58

Ilustración 95: Botones de Acciones de combate

Ilustración 93: Fondo de la escena Battle

Ilustración 20: Diseño del HUD de combate

59

3.3.4 Resultados en conjunto

Ilustración 97: Animación de correr en la escena Woods

Ilustración 96: Inicio Escena Woods

60

Ilustración 99: Final de la escena Woods

Ilustración 98: Animación de salto en la escena Woods

61

Ilustración 101: Escena de combate

Ilustración 100: Selección de objetivo en la escena de combate

62

Ilustración 102: Animación de ataque y muesta de daño en la escena de combate

Ilustración 103: Animación ataque mágico y muestra de daño en la escena de combate

63

Ilustración 104: Animación defensa en la escena de combate

Ilustración 105: Animación ataque de Fungus y daño recibido en la escena de combate

64

3.4 Banda Sonora

La banda sonora del juego se ha realizado para apoyar la ambientación del juego. Aunque se respete la estética medieval del juego, se han incluido instrumentos tanto actuales como antiguos en la composición.

3.4.1 Title Theme

Canción que se reproducirá al abrir el juego y permanecerá en las escenas Main Menu y Options. Para esta canción se han utilizado instrumentos con sonidos más suaves para simbolizar el comienzo de una historia.

3.4.2 Woods Theme

“Woods Theme” es la canción que sonará mientras se juega en la escena Woods. La intención de esta canción es mezclar la estética típica de las canciones de los juegos de plataformas con la de los juegos de rol.

3.4.3 Battle Theme

La canción “Battle Theme” sonará cuando se entre en combate normal. En esta canción se ha intentado imitar el estilo musical de los juegos Castlevania pero adaptándolo a una canción típica de juegos de rol.

3.4.4 Fungus Battle Theme

Esta canción sonará cuando se entre en combate con el jefe del nivel Woods, Fungus. El tema está inspirado en la canción “The Decisive Battle” del juego Final Fantasy VI, dado que es una gran canción de batalla contra jefe y, como parte de la ambientación del juego es medieval, casan bastante bien los elementos inspirados en esa canción que contiene la canción “Fungus Battle Theme”.

65

3.5 Conclusión

He podido aprender un montón de las herramientas que he utilizado, pero sobre todo me quedo con haber aprendido realmente como funciona la herramienta Unity para desarrollar juegos en 2D y el haber podido programar en un lenguaje que no había tocado nunca, como es C#.

El proyecto ha sido duro y he tenido un montón de obstáculos que superar, pero principalmente lo que más dolores de cabeza me ha dado ha sido el sistema de combate y la persistencia de las estadísticas de los personajes. Pero superar esos obstáculos ha hecho que me interese aún más el tema del proyecto.

Ha sido una experiencia muy positiva y me ha hecho darme cuenta de la dificultad del desarrollo de videojuegos y el por qué los tiempos de desarrollo suelen durar unos años, sobre todo en los casos de videojuegos hechos completamente por una persona.

66

4 Bibliografía

[1] Unity. Documentación de Unity 2D

https://docs.unity3d.com/es/2019.3/Manual/Unity2D.html

[2] Pyxel Edit. Learn Pyxel Edit

https://pyxeledit.com/learn.php

[3] Guitar Pro 7.5. Guitar Pro 7.5 User Guide

https://static.guitar-pro.com/gp7/manual/GuitarPro7-user-guide.pdf

[4] SourceTree. Getting Started with SourceTree

https://confluence.atlassian.com/get-started-with-sourcetree

[5] Brackeys. Make a videogame

http://brackeys.com

[6] Microsoft Visual Studio. Documentación de Visual Studio.

https://docs.microsoft.com/en-us/visualstudio/get-started/visual-studio-ide?view=vs-2017

[7] C#. Documentación de C#

https://docs.microsoft.com/es-es/dotnet/csharp/

[8] The Difference Between Working in Indie and AAA Game Development. Raka Mahesa.

https://hub.packtpub.com/difference-between-working-indie-and-aaa-game-development/

Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,

C=ES

Fecha/Hora Mon Jun 29 18:35:46 CEST 2020

Emisor delCertificado

EMAILADDRESS=camanager@fi.upm.es, CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES

Numero de Serie 630

Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (AdobeSignature)