esarrollodeunvideojuego rpg conelframework …dborrajo/pfc/tfm-francisco-lopez.pdf ·...

UNIVERSIDAD CARLOS III DE MADRID MÁSTER EN INGENIERÍA INFORMÁTICA

TRABAJO DE FIN DE MÁSTER

DESARROLLO DE UN VIDEOJUEGO RPG

CON EL FRAMEWORK LIBGDX AUTOR

FRANCISCO MANUEL LÓPEZ CONDE DIRECTOR

PROF. DANIEL BORRAJO MILLÁN

MADRID, SEPTIEMBRE 2014

2

ÍNDICE 1. INTRODUCCIÓN ............................................................................................................................ 7 1.1. VISIÓN DEL PROYECTO .............................................................................................................................. 7 1.2. DEFINICIÓN DEL DOCUMENTO ................................................................................................................. 8

2. ESTADO DEL ARTE ................................................................................................................... 11 2.1. RECURSOS SOFTWARE ........................................................................................................................... 11 2.2. AMBIENTACIÓN ....................................................................................................................................... 12

3. DEFINICIÓN DEL PROBLEMA ................................................................................................ 14 3.1. DEFINICIÓN DEL PROBLEMA REAL ....................................................................................................... 14 3.2. DEFINICIÓN DEL PROBLEMA TÉCNICO ................................................................................................. 14 3.2.1. Funcionamiento .............................................................................................................................. 14 3.2.2. Entorno .............................................................................................................................................. 15 3.2.3. Vida esperada .................................................................................................................................. 16 3.2.4. Ciclo de mantenimiento .............................................................................................................. 16 3.2.5. Competencia .................................................................................................................................... 16 3.2.6. Aspecto externo .............................................................................................................................. 16 3.2.7. Estandarización ............................................................................................................................. 17 3.2.8. Calidad y fiabilidad ....................................................................................................................... 18 3.2.9. Metodología ..................................................................................................................................... 18 3.2.10. Planificación .................................................................................................................................. 19 3.2.11. Costes ................................................................................................................................................ 22 3.2.12. Pruebas ............................................................................................................................................ 23 3.2.13. Seguridad ........................................................................................................................................ 23

4. OBJETIVOS .................................................................................................................................. 24 5. RESTRICCIONES ........................................................................................................................ 25 5.1. FACTORES DATO ...................................................................................................................................... 25 5.2. FACTORES ESTRATÉGICOS ..................................................................................................................... 25

6. RECURSOS ................................................................................................................................... 26 6.1. RECURSOS HUMANOS ............................................................................................................................. 26 6.2. RECURSOS SOFTWARE ............................................................................................................................ 26 6.3. RECURSOS HARDWARE .......................................................................................................................... 27

7. ESPECIFICACIÓN DE REQUISITOS ....................................................................................... 28 7.1. OBJETIVO DEL VIDEOJUEGO ................................................................................................................... 29 7.2. TILED MAP ............................................................................................................................................... 29 7.3. CREACIÓN DE PERSONAJES .................................................................................................................... 30 7.4. TILE BASE GRID MOVEMENT ............................................................................................................... 31 7.5. COLISIONES .............................................................................................................................................. 32 7.6. CONTROL DE LA POSICIÓN ..................................................................................................................... 33 7.7. ALGORITMO DE DETECCIÓN .................................................................................................................. 33 7.8. PANTALLA DE BATALLA ......................................................................................................................... 34 7.9. LÓGICA DE BATALLA ............................................................................................................................... 35 7.10. EVENTOS ................................................................................................................................................ 36 7.11. MENÚS .................................................................................................................................................... 37 7.12. CARGADO Y GUARDADO ...................................................................................................................... 38 7.13. CARGA DE INFORMACIÓN .................................................................................................................... 38 7.14. ANIMACIONES ....................................................................................................................................... 39 7.15. SONIDO ................................................................................................................................................... 40

8. ANÁLISIS DEL SISTEMA .......................................................................................................... 41

3

8.1. ARQUITECTURA GENERAL DEL SISTEMA ............................................................................................. 41 8.2. CASOS DE USO .......................................................................................................................................... 41 8.3. CICLO DEL VIDEOJUEGO .......................................................................................................................... 42

9. DISEÑO DEL SISTEMA ............................................................................................................. 44 9.1. VIDEOJUEGO DEMONSOUL .................................................................................................................... 45 9.2. MAIN GAME ............................................................................................................................................. 45 9.3. TILE MAP GAME ...................................................................................................................................... 46 9.4. BATTLE ALGORITHM .............................................................................................................................. 46 9.5. EVENTS ..................................................................................................................................................... 46 9.6. FOE ALGORITHM ..................................................................................................................................... 47 9.7. FOE COLLISIONS ...................................................................................................................................... 47 9.8. PLAYER COLLISIONS ............................................................................................................................... 48 9.9. FOE ............................................................................................................................................................ 48 9.10. PLAYER ................................................................................................................................................... 49 9.11. LOAD CONFIG ........................................................................................................................................ 50 9.12. PARAMETERS ........................................................................................................................................ 50 9.13. SAVE PROGRESS .................................................................................................................................... 50 9.14. BATTLE SCREEN ................................................................................................................................... 51 9.15. INFO SPLASH SCREEN .......................................................................................................................... 51 9.16. MAIN MENU SCREEN ........................................................................................................................... 52 9.17. PLAY MENU SCREEN ............................................................................................................................ 52 9.18. PLAY SCREEN ........................................................................................................................................ 52 9.19. SPLASH SCREEN .................................................................................................................................... 52 9.20. ACTOR ACCESSOR ................................................................................................................................. 52

10. DESCRIPCIÓN DE LA INFORMACIÓN ................................................................................ 53 11. PRUEBAS Y RESULTADOS .................................................................................................... 54 12. CONCLUSIONES ....................................................................................................................... 56 ANEXO I : MANUAL DE USUARIO .................................................................................................. 57 1. EJECUCIÓN DEL VIDEOJUEGO .................................................................................................................... 57 2. INICIAR NUEVA PARTIDA ........................................................................................................................... 58 3. CONTROLES .................................................................................................................................................. 58 4. MAPA DE JUEGO .......................................................................................................................................... 58 5. CARGA Y GUARDADO DE LA PARTIDA. ..................................................................................................... 59 6. ENEMIGOS Y BATALLAS .............................................................................................................................. 60 7. EVENTOS ...................................................................................................................................................... 63

ANEXO II : MANUAL DEL DESARROLLADOR ............................................................................ 65 1. INTRODUCCIÓN ........................................................................................................................................... 65 2. ALGORITMOS DE MOVIMIENTO ENEMIGO ............................................................................................... 66 3. ALGORITMOS DE BATALLA ........................................................................................................................ 66 4. OTRAS IMPLEMENTACIONES ..................................................................................................................... 66

BIBLIOGRAFÍA ................................................................................................................................... 67

ÍNDICE DE TABLAS TABLA 1 – COSTES DE PERSONAL .............................................................................................................................................. 22 TABLA 2 -‐ COSTES DE MATERIAL ............................................................................................................................................... 22 TABLA 3 -‐ FÓRMULAS DE BATALLA ........................................................................................................................................... 36 TABLA 4 -‐ FOES ........................................................................................................................................................................... 62 TABLA 5 -‐ ATAQUES JUGADOR .................................................................................................................................................... 63 TABLA 6 -‐ ESTADÍSTICAS DEL JUGADOR .................................................................................................................................... 63

ÍNDICE DE ILUSTRACIONES ILUSTRACIÓN 1 -‐ ETRIAN ODYSSEY BATTLE ............................................................................................................................ 12 ILUSTRACIÓN 2 -‐ ETRIAN ODYSSEY MAP ................................................................................................................................. 12 ILUSTRACIÓN 3 -‐ THE LEGEND OF ZELDA ................................................................................................................................ 13 ILUSTRACIÓN 4 -‐ POKEMON YELLOW ....................................................................................................................................... 13 ILUSTRACIÓN 5 -‐ CICLO DEL VIDEOJUEGO ................................................................................................................................. 15 ILUSTRACIÓN 6 -‐ METODOLOGÍA EN CASCADA ........................................................................................................................ 19 ILUSTRACIÓN 7 -‐ DIAGRAMA DE GANTT (TABLA) ................................................................................................................... 21 ILUSTRACIÓN 8 -‐ DIAGRAMA DE GANTT (GRÁFICO) ............................................................................................................... 21 ILUSTRACIÓN 9 -‐ EJEMPLO TILE BASED MAP .......................................................................................................................... 29 ILUSTRACIÓN 10 -‐ TILE MAP EDITOR 0.9.1 ............................................................................................................................ 30 ILUSTRACIÓN 11 -‐ MOVIMIENTO EN GRID ............................................................................................................................... 32 ILUSTRACIÓN 12 -‐ EJEMPLO DE TILES BLOQUEADOS .............................................................................................................. 33 ILUSTRACIÓN 13 -‐ RANGO DE VISIÓN DEL FOE ...................................................................................................................... 34 ILUSTRACIÓN 14 -‐ EJEMPLO DE PANTALLA DE BATALLA ....................................................................................................... 35 ILUSTRACIÓN 15 -‐ EJEMPLO DE ANIMACIÓN DE TILES ........................................................................................................... 39 ILUSTRACIÓN 16 -‐ EJEMPLOS DE SPRITES DEL JUGADOR DE MOVIMIENTO ......................................................................... 40 ILUSTRACIÓN 17 -‐ EJEMPLO DE SPRITES DE ANIMACIÓN DE BATALLA ................................................................................ 40 ILUSTRACIÓN 18 -‐ ARQUITECTURA GENERAL .......................................................................................................................... 41 ILUSTRACIÓN 19 -‐ CASOS DE USO DEL USUARIO ...................................................................................................................... 41 ILUSTRACIÓN 20 -‐ CASOS DE USO DEL DESARROLLADOR ....................................................................................................... 42 ILUSTRACIÓN 21 -‐ CICLO DE EJECUCIÓN DEL VIDEOJUEGO .................................................................................................... 42 ILUSTRACIÓN 22 -‐ DIAGRAMA DE RELACIÓN ENTRE LAS CLASES DEL VIDEOJUEGO ........................................................... 44 ILUSTRACIÓN 23 -‐ WORKSPACE ................................................................................................................................................ 45 ILUSTRACIÓN 24 -‐ ASSETS DENTRO DEL PROYECTO CORE .................................................................................................... 53 ILUSTRACIÓN 25 -‐ FICHEROS DE CONFIGURACIÓN .................................................................................................................. 53 ILUSTRACIÓN 26 -‐ FICHEROS DE JUEGO .................................................................................................................................... 57 ILUSTRACIÓN 27 -‐ MENÚ PRINCIPAL ........................................................................................................................................ 57 ILUSTRACIÓN 28 -‐ SCREEN DE INFORMACIÓN DE CONTROLES ............................................................................................. 58 ILUSTRACIÓN 29 -‐ MAPA DE JUEGO ........................................................................................................................................... 59 ILUSTRACIÓN 30 -‐ MENÚ DE JUEGO .......................................................................................................................................... 59 ILUSTRACIÓN 31 -‐ SPRITE PLAYER ........................................................................................................................................... 60 ILUSTRACIÓN 32 -‐ SPRITES FOES ............................................................................................................................................. 60 ILUSTRACIÓN 33 -‐ PERSECUCIÓN FOE ..................................................................................................................................... 60 ILUSTRACIÓN 34 -‐ BATALLA ....................................................................................................................................................... 62 ILUSTRACIÓN 35 -‐ EVENTOS ...................................................................................................................................................... 64 ILUSTRACIÓN 36 -‐ PROYECTO CORE ......................................................................................................................................... 65

Agradecimientos

A mis padres por darme la oportunidad.

A Elena por su apoyo en todo momento.

1. Introducción El desarrollo de videojuegos ha tenido un gran auge en estos últimos años

gracias a los grandes avances tecnológicos, la gran disponibilidad de recursos software, y el nacimiento de los Smartphone. Debido a la gran demanda, y oportunidades que ofrece el desarrollo de videojuegos, son muchas las nuevas Pymes y medianas empresas que han surgido en el mercado dedicadas exclusivamente al desarrollo de videojuegos tanto para móviles, videoconsolas y para PC. Un ejemplo de ello podría ser la famosa empresa ©King desarrolladora del juego para Smartphone Candy Crash Saga.

1.1. Visión del proyecto

De esta forma, gracias a la facilidad y las ganas por poder introducirse en el mundo de desarrollo de videojuegos, hacen que nuestro propósito se enfoque en el desarrollo de un videojuego desde la base, para poder conocer todos los pasos necesarios para su desarrollo.

El crear un juego desde cero supone el desarrollo de motores gráficos, y de movimiento. Esto hace que el grado de dificultad supere lo planificado para este tipo de trabajo, por lo que haremos uso de un framework que nos ayude a solucionar este tipo de problemas, y nos simplifique el camino a recorrer. A pesar de ello, el desarrollo de un juego desde cero supone, además del desarrollo del código, la creación de la ambientación gráfica, la creación de una historia y el uso de sonido para dar ambientación y personalidad al mismo.

Existen muchos tipos de videojuegos, pero en nuestro caso hemos querido centrarnos en un juego RPG ambientado en un mundo de fantasía, llamado Demon Soul. RPG es el término inglés Role Playing Game, lo que quiere decir, Juego de Rol.

Muchas personas no tienen conocimiento del termino “Rol” en un juego. Si miramos a juegos famosos como la saga Final Fantasy de la famosa compañía japonesa ©Square Enix, o la saga Tales of procedente de ©Namco Bandai Games, son juegos enfocados en narrar una historia específica de género fantástico, con giros argumentales y toques amorosos. Para el desarrollo de estas historias el jugador generalmente controla a uno o varios personajes carismáticos que deben “evolucionar” para completar el juego. Con el termino evolucionar nos referimos a aumentar su poder, conocimientos u objetos que poseen para poder hacer frente a retos mayores. Esta evolución generalmente viene dada por el aumento de sus

Capítulo 1 – Introducción

8

Stats o Estadísticas (aumento de fuerza, defensa, ataque especial, suerte, rapidez, etc.) que se suelen obtener tras subir de nivel combatiendo con enemigos.

La elección de este tipo de juego ha sido personal, debido a la gran afición por esta temática. Al elegir este tipo de juego, hemos tenido que restringir la plataforma en la que desarrollaríamos el juego. Debido a que estos tipos de juegos suelen necesitar un gran espacio visual para poder controlar todo los detalles que se suelen mostrar, hemos decidido desarrollarlo para PC. Esto no supone que los juegos de rol tengan que ser desarrollados para PC o videoconsolas, ya que si se desea desarrollar para Smartphone la pantalla de juego se suele adaptar para que no quede demasiado cargada.

1.2. Definición del documento

En esta sección definiremos cada uno de los apartados que serán vistos en este documento, con una breve descripción de los mismos.

Estado del arte En este apartado se tratará del estado del arte. Se describirá el lenguaje de

programación y el framework que utilizaremos para desarrollar el videojuego. Trataremos los videojuegos que se han desarrollado con esta herramienta software, y en qué tipo de videojuegos nos hemos ambientado para desarrollar nuestro proyecto.

Definición del problema En la definición del problema trataremos de informar sobre el problema al que

intentamos dar solución, diferenciando entre el problema real -‐ el problema enfocado desde el punto de vista del usuario – y el problema técnico – donde mostraremos el punto de vista del programador, tratando temas como el funcionamiento, el entorno, la vida esperada, el ciclo de mantenimiento, la competencia, el aspecto externo, la estandarización, la calidad y fiabilidad, la planificación de las tareas y las pruebas realizadas.


9

Objetivos En este capítulo nos centraremos en los objetivos fundamentales que

tendremos que llevar a cabo para el desarrollo de nuestro proyecto, descomponiéndolos y analizándolos para su entendimiento.

Restricciones En este capítulo nos centraremos en las restricciones que estableceremos al

inicio del proyecto. Estas restricciones pueden ser obligadas debido al tipo de proyecto, o decididas por los componentes del proyecto, lo que hará que pueda tomar un rumbo u otro.

Recursos En este capítulo nos centraremos en los recursos que utilizaremos para el

desarrollo de nuestro proyecto. Tanto recursos humanos, como de software y hardware.

Especificación de requisitos En este capítulo hablaremos sobre los requisitos que nuestro juego debe

cumplir. Analizaremos con detalle cada uno de ellos hablando de su funcionalidad y los objetivos que estos cumplen.

Análisis del sistema Analizaremos los casos de uso que tiene nuestra aplicación y el ciclo de

ejecución del videojuego.

Diseño del sistema Hablaremos sobre el diseño de nuestro sistema, mostrando un diagrama UML

para la relación entre clases y describiremos cada una de ellas, además de comentar las variables miembro y métodos más destacados.


10

Descripción de la Información En este capítulo trataremos los datos de entrada y salida que utilizaremos,

además de localizarlos en nuestro proyecto para el uso de futuros desarrolladores.

Pruebas y resultados Trataremos las pruebas realizadas, las soluciones aplicadas y los resultados

obtenidos. Estos datos serán descriptivos ya que todas las pruebas son en tiempo de ejecución, resultando casi imposible mostrar datos tangibles de las pruebas.

Conclusiones En este capítulo hablaremos sobre las conclusiones obtenidas tras la

realización de nuestro Trabajo de Fin de Máster

Anexo I Este anexo irá dedicado al manual de usuario. Explicará el funcionamiento del

juego desde el punto de vista del usuario, guiándolo por todos los estados posibles.

Anexo II Este segundo anexo irá dedicado al manual del desarrollador, tratando las

clases que debe tener en cuenta a la hora de desarrollar algoritmos o modificar este proyecto de alguna otra manera.

2. Estado del Arte

El estado del arte es muy importante para guiarnos sobre el camino a recorrer. Nos puede ayudar a tomar decisiones y a ver el estado actual del mercado en relación con el tema en el que vayamos a centrar nuestro proyecto.

2.1. Recursos Software

Para el desarrollo de nuestro proyecto investigamos sobre las posibilidades software que actualmente se utilizan en el mercado. Hemos tenido en cuenta tanto la facilidad de uso como el posible coste del mismo. Tras indagar un poco encontramos los siguientes recursos:

• Unity3D: Es un motor de videojuegos creado por la compañía Unity Technologies [Uni3D]. Es un motor para una gran variedad de plataformas como, Windows, OSX, Linux, Xbox 360, PS3, PSVita, Wii, WiiU, iPhone, iPad, Andorid y Windows phone. Los costes de utilización de este recurso son sinceramente caros si empezamos a desarrollar. La versión Pro te permite publicar juegos en todas las plataformas anteriormente descritas con un coste de $1500 o $75/mes. La versión free permite publicar siempre y cuando nuestra empresa no supere los $100.000 de ingresos, desarrollando tanto en Windows como en OSX. Algunos de los juegos desarrollados con este motor son:

o Warhammer 40.000: Space Wolf. Juego basado en el juego de tablero de figuras coleccionables Warhammer [War40].

o Deus Ex: The Fall. Juego shooter futurista [DeusEX].

o Migraciones de juegos a plataformas Windows [MigrJu].

• Libgdx: Es un framework Open Source para el desarrollo de videojuegos gratuito para el lenguaje de programación Java [Oeh13][BadLg]. Este framework permite la creación de videojuegos 2D para todo tipo de plataformas que soporten la máquina virtual Java, y además permite desarrollar sus aplicaciones para Android, iOS y web [DerYT]. Algunos de los videojuegos creados son:

o Meganoid: Grandpa’s Chronicles. Juego de plataformas ambientado en la exploración, al estilo de Indiana Jones [MegNo].

• Monogame: Es un software gratuito usado para hacer que juegos desarrollados en Windows y Windows Phone puedan ser implantados en otras plataformas [MonoG]. Actualmente soporta OSX, Linux,

Capítulo 2 – Estado del arte

12

Androis, iOS, PS Mobile y OUYA. El lenguaje de programación usado es generalmente C++. Algunos de los juegos creados son:

o FEZ. Un curioso videojuego diseñado con gráficos pixelados (pixel art), con el uso de plataformas [FEZ].

o Bastion. Juego de rol en tercera persona con vista aérea, con gran nivel gráfico [Bast].

Tras analizar cada una de las opciones, nos decantamos por Libgdx. Este framework, además de ser gratuito, nos ofrece una gran facilidad para manejar gráficos 2D, y nos asegura el funcionamiento del software en cualquiera de las plataformas para ordenadores que dispongan de la máquina virtual Java [Oeh13][DerYT]. Nuestro principal objetivo era facilitar el tratamiento gráfico y el control del movimiento en la jugabilidad del juego. Este framework nos proporciona estos recursos de una manera sencilla. Además, su gran comunidad y la constante evolución de la herramienta hace que el aprendizaje de la librería resulte relativamente sencillo en comparación con, por ejemplo, Unity3D.

2.2. Ambientación

La ambientación de nuestro TFM se centra en los videojuegos de tipología RPG. En concreto nos centramos en la saga Etrian Odyssey, desarrollado por la empresa ATLUS.

Ilustración 1 -‐ Etrian Odyssey Battle

Ilustración 2 -‐ Etrian Odyssey Map

Etrian Odyssey es un juego desarrollado para la plataforma de ©Nintendo, Nintendo DS y que ha ido evolucionando hasta la actual Nintendo 3DS. Es un videojuego característico por centrarse en un Rol puro, en el que a pesar de tener una historia central, su peso radica en la compleja evolución y personalización de los personajes jugables. La dificultad es un punto fuerte en este tipo de videojuego, siendo cada batalla un reto para el jugador [Ilustración 1], evitando los típicos juegos denominados “Press A to win”.

Además, este tipo de juego se caracteriza por no tener un gran desarrollo gráfico, usando sprites para el diseño de sus personajes y los enemigos del juego, obteniendo un enfoque retro. Es un juego de exploración de mazmorras [Ilustración 2] donde cada rincón puede suponer el cambio de la historia. Es por ello que las batallas y parte del mapa de nuestro TFM ha sido diseñado imitando

Capítulo 2 – Estado del arte

13

esta saga. Este tipo de batallas serán por turnos, en el que cada personaje elegirá una acción, y al finalizar el turno se obtendrán los resultados de dicha acción, siendo el objetivo de la batalla hacer que la vida de tu enemigo sea reducida a cero.

En la parte de diseño del movimiento de los personajes, además de ambientarnos en el diseño de Etrian Odyssey, también hemos querido hacer referencia a sagas de videoconsolas portátiles tan conocidas como The Legend of Zelda [Ilustración 3], o Pokemon [Ilustración 4]. El movimiento del personaje en el mapa será del tipo Tile Base Grid Movement, o lo que es lo mismo, Movimiento por Grid en el que cada paso supone un Tile del mapa.

Ilustración 3 -‐ The Legend of Zelda

Ilustración 4 -‐ Pokemon Yellow

3. Definición del Problema

En este capítulo trataremos de informar sobre el problema al que intentamos dar solución, diferenciando entre el problema real y el problema técnico, junto con un conjunto de apartados para obtener una visión global del mismo.

3.1. Definición del problema real

Nuestro TFM está desarrollado en el lenguaje de programación Java, haciendo uso de un framework para el desarrollo de videojuegos en 2D, Libgdx [BadLg]. Este framework nos permite mediante una gran colección de clases, implementar de forma fácil el entorno gráfico, colisiones con el entorno, y el movimiento de los actores.

El problema planteado es el desarrollo de un videojuego de estilo RPG llamado Demon Soul, centrado en narrar una historia fantástica que se desarrollará mediante un movimiento en Grid (por casillas) en un mapa donde, tanto de forma aleatoria como planificada, nos encontraremos con enemigos con los que combatir para ir evolucionando, y trataremos con eventos que narrarán la historia de forma progresiva para alcanzar el objetivo marcado en ella.

El videojuego podrá ser utilizado en entornos Windows, OSX y Linux en los que dispongamos de la máquina virtual Java.

3.2. Definición del problema técnico

La definición del problema técnico estará marcado por el método de ingeniería denominado PDS (Product Design Specification), que nos permitirá realizar un análisis técnico respondiendo a una serie de cuestiones básicas planteadas.

3.2.1. Funcionamiento

Se desarrollará un videojuego RPG en el que se hará uso de un movimiento Grid, se dispondrán de eventos, y batallas por turnos para el entrenamiento del jugador. Su implementación será realizado en el lenguaje de programación Java, debido a:

• El uso del framework Libgdx desarrollado en dicho lenguaje de programación.

Capítulo 3 – Definición del problema

15

El desarrollo del videojuego debe contener un ciclo de ejecución determinado [Ilustración 5]:

Ilustración 5 -‐ Ciclo del videojuego

3.2.2. Entorno

Al analizar los entornos tendremos en cuenta distintos puntos de vista; definiremos un entorno de programación, posteriormente un entorno software, un entorno hardware y para finalizar el entorno de usuario, y entorno de desarrollador.

• Entorno de programación. El entorno que utilizaremos para desarrollar el videojuego en lenguaje Java será el entorno de desarrollo Eclipse ID for Java EE Developers, la versión Indigo Release.

• Entorno software. Para el correcto funcionamiento del videojuego Demon Soul, necesitaremos los siguiente componentes software:

o Sistema Operativo Windows/OSX/Linux.

o Máquina virtual Java.

o Entorno de desarrollo Eclipse (para desarrolladores).

• Entorno hardware. El videojuego podrá ser utilizado en cualquier ordenador actual personal, aun existiendo unos requisitos mínimos que serán tenidos en cuenta en el apartado de Recursos.

• Entorno de usuario. El videojuego Demon Soul debe ser intuitivo para que el usuario pueda utilizarlo sin ningún tipo de conocimiento sobre

Inicio

Menú de entrada

Procesamiento (Game loop)

Menú (Guardar/Salir)

Fin


16

él, y ofrecer la suficiente información que consideremos necesaria para su manejo.

• Entorno de desarrollador. El videojuego estará implementado de forma que para un desarrollador sea sencillo de aumentar su funcionalidad en el caso de que se quiera. Daremos posibilidad de añadir algoritmos de movimiento, algoritmos de batalla, nuevos enemigos, etc.

3.2.3. Vida esperada

Nuestro videojuego está desarrollado con el framework Libgdx [BadLg]. Este framework está en constante evolución por lo que nuestro desarrollo podrá ser actualizado con nuevas funcionalidades que puedan ser añadidas a dichas librerías. De esta forma futuros desarrolladores podrán tener el videojuego Demon Soul como partida para desarrollar nuevos algoritmos de movimiento o batalla, o añadir nuevas funcionalidades al mismo.

3.2.4. Ciclo de mantenimiento

Este videojuego no requiere de un ciclo de mantenimiento, ya que a no ser que se le añadan nuevas funcionalidades, el videojuego utilizará el framework de la versión en la que se desarrolló. Si dicho videojuego aumenta al ser utilizado por nuevos desarrolladores, el código puede necesitar de ajustes que se adapten a las nuevas versiones de la librería Libgdx.

3.2.5. Competencia

La industria de los videojuegos tiene una gran competencia en el mercado actual. Son muy pocos los juegos que triunfan debido a la gran cantidad de juegos que se desarrollan en período de tiempos cortos, y son muy pocos los que innovan y revolucionan el mercado. Este videojuego no tiene un fin comercial, sino didáctico (para desarrolladores) y de entretenimiento (para usuarios) gratuito, por lo que no consideramos que haya una competencia directa.

3.2.6. Aspecto externo

En este apartado, además de tener en cuenta el aspecto visual del videojuego, también tendremos en cuenta la forma de almacenamiento en la que será entregado el mismo, como el tipo de documentación entregada. Además, se comentará los archivos necesarios que tanto el usuario como el desarrollador deberán tener para la utilización del mismo.


17

• Formato de almacenamiento. El TFM, como dicta la normativa, será entregado en un CD-‐ROM que incluirá el software necesario para la ejecución del programa por un usuario como para un desarrollador. De la misma manera, incluirá la documentación generada para la comprensión de cómo ha sido desarrollado y cómo debe utilizarse para su ejecución. Además, este TFM podrá ser publicado en la página Web del director de este proyecto en el caso de que se considere oportuno.

• Ficheros disponibles. El usuario dispondrá de un fichero y dos carpetas para la correcta ejecución de la aplicación. El fichero será un archivo de extensión .jar que será el ejecutable. Dispondrá de una carpeta donde se almacenarán las librerías externas (framework Libgdx) necesarias para su correcto funcionamiento, y una carpeta de configuración necesaria para la carga de estadísticas, eventos, mapas y ficheros de guardado de la aplicación. El desarrollador dispondrá de una carpeta workspace que podrá utilizar con el entorno de desarrollo eclipse para poder implementar las funcionalidades que considere necesarias.

• Documentación. Esta estará compuesta de un Manual Técnico donde se informará a cerca del análisis, diseño, implementación y pruebas de la aplicación; El Manual de usuario proporcionará la información necesaria para la correcta ejecución y manejo del videojuego.

• Interfaz de usuario. Esta será diseñada de la forma más simple e intuitiva posible para que el usuario se sienta cómodo y no tenga dificultades para manejarla. A lo largo de la ejecución del videojuego se añadirán guías para facilitar al usuario el uso correcto del teclado y el ratón con el fin proporcionar información acerca de la jugabilidad del mismo.

3.2.7. Estandarización

La implementación del videojuego seguirá una serie de normas estándares con respecto al estilo de codificación. Debido a que este tipo de normas son extensas y de gran libertad, aplicaremos una codificación habitual utilizada para el lenguaje de programación Java, utilizando las librerías incluidas en el framework Libgdx.

A continuación listamos las reglas aplicadas en nuestro desarrollo:

• Nombres de paquetes: Deben ser lo mas breves posibles.

• Clases e Interfaces: Siempre comenzarán por letra mayúscula.


18

• Objetos, métodos, variables miembro y variables locales: Comenzarán siempre por letra minúscula.

• Cuando un nombre conste de varias palabras, la primera letra a partir de la segunda palabra escrita debe comenzar por mayúscula para facilitar su lectura.

• Las variables y los métodos deben tener nombres coherentes respecto a su funcionalidad.

• El código debe estar correctamente documentado para facilitar su posterior uso por los futuros desarrolladores.

3.2.8. Calidad y fiabilidad

La calidad y fiabilidad del videojuego desarrollado son dos factores muy importantes, por ello que se realizarán un conjunto de pruebas para validar y verificar el sistema y así reducir la probabilidad de fallo. Además, un factor a tener en cuenta es el consumo de recursos del sistema al ejecutar el juego. Es por ello que el código debe estar lo suficientemente depurado para no comprometer al sistema y que los recursos consumidos sean lo menores posibles.

3.2.9. Metodología

Para nuestro Trabajo de Fin de Máster utilizaremos una metodología de desarrollo del software en cascada [Ilustración 6]. De esta forma nuestras fases de desarrollo estarán dispuestas de forma que la finalización de una fase suponga el comienzo de la siguiente, o lo que es lo mismo, el comienzo de una fase supone la finalización de la anterior.


19

Ilustración 6 -‐ Metodología en cascada

La visión obtenida tras esta metodología nos permite planificar nuestras tareas de forma ordenada, pudiendo marcar tiempos y costes a las mismas.

3.2.10. Planificación

En este apartado trataremos las diferentes fases de planificación de nuestro Trabajo de Fin de Máster. Para ello realizaremos el diagrama de Gantt correspondiente [Ilustración 7].

• Estudio del problema y recursos. En esta fase del proyecto estudiaremos el problema que queremos plantear y los recursos disponibles en el mercado para su desarrollo. Esta tarea puede subdividirse en:

o Estudio de los posibles videojuegos a diseñar

o Elección del lenguaje de programación y frameworks a utilizar.

o Estudio del framework elegido.

o Estudio del ciclo completo de un videojuego.

o Elección de las herramientas de desarrollo gráfico a utilizar.

• Análisis de requisitos. En esta fase definiremos el comportamiento que debe tomar nuestro sistema y todos los objetos que formarán parte del mismo, así como todas las condiciones que se deben de cumplir para que su función se realice de manera correcta.

o Definición del problema.

Estudio del Problema

Análisis de Requisitos

Análisis del Sistema

Diseño del Sistema

Codi{icación

Pruebas


20

o Definición de los objetivos que se quieren alcanzar.

o Definición de las funcionalidades que se desean implementar.

o Validación del análisis realizado.

o Definición de personajes, historia y ambiente gráfico.

• Análisis del sistema. En esta fase estudiaremos las partes de las que se compondrán nuestro sistema y los diagramas de secuencia que nuestro videojuego deberá poseer.

• Diseño del sistema. En esta fase estudiaremos la arquitectura que deberemos implementar para el desarrollo de nuestro videojuego, teniendo una visión específica de nuestro diagrama de relación de clases.

• Codificación. Desarrollo del videojuego con las herramientas proporcionadas en la primera fase y la información adquirida en la segunda fase.

o Implementación del entorno gráfico. (mapas, menús, etc.)

o Desarrollo de la lógica de movimiento.

o Desarrollo de lógica de colisiones.

o Desarrollo de los algoritmos de movimiento y de batalla.

o Desarrollo de eventos.

o Diseño gráfico del mapa, el screen de batalla y de los actores del juego.

o Adición de efectos sonoros.

o Integración del hilo argumental.

• Pruebas. En esta fase se realizarán los casos de prueba considerados para la fiabilidad y calidad del software desarrollado.

o Depuración del software.

o Pruebas que certifiquen que la versión a entregar es una versión estable del sistema.

• Documentación. Desarrollo del Manual Técnico y de Usuario mediante toda la información adquirida a lo largo del proyecto.


21

Ilustración 7 -‐ Diagrama de Gantt (tabla)

Ilustración 8 -‐ Diagrama de Gantt (gráfico)

Esta planificación [Ilustración 8] supone un total de 440 horas, que tras un calendario estándar supone un comienzo el día 1 de Julio del 2014 y una finalización el 15 de septiembre de 2014. Como podemos observar se trata de una


22

metodología en cascada a excepción de la documentación del proyecto, que se realiza de forma paralela al resto de fases.

3.2.11. Costes

Este proyecto no ha supuesto ningún coste real, ya que todo el material y los recursos utilizados o pertenecían inicialmente al autor del proyecto, o eran gratuitos. Aun así hemos querido estimar costes ficticios proporcionando la información suficiente para que empresas de desarrollo conozcan los costes de implantación de este juego, que a priori, puedan suponer. Hemos dividido los costes en dos tipos. Costes de personal y costes de material amortizable (Hardware y Software).

El coste de personal se muestra en la siguiente tabla [Tabla 1] con un gasto por hora de 16.72€.

Fase Horas Coste (€)

Estudio y Análisis del proyecto 96 1605.12 Diseño y Desarrollo 304 5082.88 Pruebas de la aplicación 28 468.16 Documentación 12* 200.64

Total 7356.8 Tabla 1 – Costes de personal

*La documentación comienza al inicio del proyecto, por lo que se trata a la vez que el resto de fases. Las 12 horas asignadas son las horas adicionales tras todo el desarrollo.

Los costes referentes al gasto de material amortizable se tratan a continuación

[Tabla 2].

Tipo Producto Precio (€) Amortización (meses)

Amortización (€/mes)

Uso en el proyecto (meses)

Coste (€)

HW Mac Book Pro 2014 – 15’ 2,2 GHz

2029.00 75 27.53 2.5 68.83

HW

Impresora Multifunción Lexmark X1250

39.95 3 13.32 2.5 33.3

SW MS Office 2013 519.00 105 9.94 2.5 24.85

SW Gimp 2.4.0 0 -‐ -‐ -‐ 0 SW Tile Map 0.9.1 0 -‐ -‐ -‐ 0 SW OpenProj 1.4 0 -‐ -‐ -‐ 0

SW Eclipse Indigo 3.7 0 -‐ -‐ -‐ 0

SW Libgdx 1.3.1 0 -‐ -‐ -‐ 0 Total 126.98

Tabla 2 -‐ Costes de material


23

Así vemos que los gastos directos hacen un total de 7483.78€. Para los gastos indirectos, como luz y agua, hemos supuesto un 4% de los gastos directos, haciendo un total de 299.35€. Si tenemos en cuenta el IVA del 21% (1634,45€), tendríamos un coste total del proyecto de 9417.59€.

3.2.12. Pruebas

Se realizarán los casos de prueba considerados para la fiabilidad y calidad del software desarrollado.

• Pruebas unitarias:

o Pruebas de movimiento.

o Pruebas de colisión.

o Pruebas algorítmicas de movimiento y de batalla.

o Pruebas de sonido.

o Pruebas de carga y guardado.

• Pruebas integradas:

o Pruebas de casos de uso.

3.2.13. Seguridad

Uno de los temas a tratar es la seguridad de nuestro sistema mientras la aplicación esté en ejecución, asegurando que no se realice ninguna actividad ajena a su funcionalidad. Por otra parte, no tendremos que tener en cuenta la Ley de Protección de Datos ya que la ejecución del videojuego no solicita datos de ningún tipo al usuario, y toda la información necesaria solo hace referencia a la propia aplicación sin necesidad de información externa.

4. Objetivos

En este apartado trataremos los distintos objetivos marcados para este Trabajo de Fin de Máster.

El principal objetivo de este proyecto, es el desarrollo de un videojuego RPG para PC, en el cual tengamos que hacer uso de teclado y ratón para su uso. La idea de este videojuego es centrarnos en el desarrollo del un mapa encasillado, por el que el personaje y los enemigos se moverán por turnos, ocupando las casillas de dicho mapa. Además, el videojuego contendrá batallas por turnos, y menús por los que navegar. Los RPG se caracterizan por contener una historia que contar, por lo que nuestro videojuego narrará una historia de fantasía.

Este videojuego debe ser multi-‐plataforma. Como será desarrollado en el leguaje de programación Java, todo ordenador que posea una máquina virtual Java podrá ejecutar dicho juego. La elección del framework [BadLg] que utilizaremos no es arbitraria, ya que nos facilitará su implementación en ordenador, y nos dará la posibilidad de en un futuro implementar dicho juego para Android o iOS.

El diseño gráfico y el apartado de sonido son objetivos importantes en este proyecto. Queremos dar al videojuego un aspecto vistoso, por ello un objetivo es el diseño de los personajes y entornos del mismo. El sonido será un objetivo necesario de introducir pero no de producir, es decir, se utilizará sonidos gratuitos [Oga09].

Otro objetivo es la creación de algoritmos de movimiento y de detección de enemigos. Estos algoritmos serán configurables, pudiendo configurar algoritmos completamente nuevos.

Un objetivo pensado en el futuro de la aplicación consiste en conseguir que nuestro videojuego sea fácilmente configurable. Los desarrolladores podrán incluir nuevos algoritmos de movimiento, de búsqueda y de batalla. Además, podrán alterar el curso de la historia, inventar historias nuevas e incluso añadir nuevos personajes y enemigos.

Por último, pero no menos importante, el objetivo de entretenimiento al usuario. Este tipo de videojuegos intentan proporcionar diversión mediante la intriga del relato de la historia, siendo la única manera de conocerla con la evolución de nuestro personaje mediante batallas.

5. Restricciones

En este capítulo trataremos las distintas restricciones que tendremos a la hora de desarrollar nuestro videojuego y de realizar la documentación del mismo. Para ello trataremos dos tipos de factores: factores dato y factores estratégicos.

5.1. Factores dato

Los factores dato son condicionantes impuestas desde el exterior y que no pueden ser cambiados a lo largo del proyecto. Los factores dato implicados son los siguientes:

• Los recursos software y hardware son los disponibles por el autor del proyecto. Al ser un Trabajo de Fin de Máster el presupuesto del que se dispone es limitado, por lo que se utilizarán las herramientas de las que se disponen inicialmente.

• Al ser necesario el uso del framework Libgdx, uno de los factores dato es el uso del lenguaje de programación Java, y el entorno JDK, junto con su entorno de desarrollo Eclipse.

5.2. Factores estratégicos

Los factores estratégicos son aquellos que tienen la posibilidad de variar el diseño del proyecto en función de la elección tomada entre una gran variedad. Esto hará que la elección de un factor estratégico pueda alterar el proceso de desarrollo y el resultado obtenido. Es por ello que es necesario analizar las distintas posibilidades existentes en las primeras etapas del proyecto. A continuación se listan los factores estratégicos considerados y los motivos de su elección:

• El videojuego a desarrollar estará estructurado en el modelo Modelo-‐Vista-‐Controlador para facilitar la organización de las clases a desarrollar, de los datos a manejar y las vistas creadas en la medida de lo que sea posible, ya que siempre es difícil establecer una línea perfecta de separación en estos desarrollos.

• Para el diseño gráfico se utilizará la herramienta de diseño gratuita Gimp 2.4.0 para Windows.

• Para el desarrollo de la documentación utilizaremos Microsoft Office Word 2011 para OSX.

6. Recursos

En este capítulo trataremos todos los recursos necesarios para el desarrollo de nuestro Trabajo de Fin de Máster. Entre ellos podemos encontrar las personas que intervendrán en el proyecto y los recursos materiales necesarios (recursos software y hardware).

6.1. Recursos humanos

Este Trabajo de Fin de Máster será supervisado por el director de proyecto Prof. Cat. Daniel Borrajo Millán, perteneciente al departamento de Informática de la Universidad Carlos III de Madrid.

El autor del proyecto, Francisco Manuel López Conde será el encargado de la planificación y posterior desarrollo del videojuego a realizar, así como las pruebas necesarias y la generación de la documentación del mismo.

6.2. Recursos software

Se utilizaran los recursos disponibles por el autor del proyecto:

• Sistema Operativo Apple, Mac OS Lion y Windows 7 Home Edition.

• JDK Versión 7 (Java Development Kit). Entorno de desarrollo del lenguaje de programación Java de Sun MicroSystems.

• Eclipse IDE for Java EE Developers, Indigo 3.7.

• Framework Libgdx 1.3.1.

• Adobe Acrobat Reader.

• Microsoft Office Word, OSX versión 2013.

• Gimp 2.4.0 para el diseño de personajes y el tile map.

• OpenProj 1.4, OSX versión para la creación del planificador de tareas.

• Tile Map Editor 0.9.1, para la creación de mapas.

Capítulo 6 -‐ Recursos

27

6.3. Recursos hardware

Se utilizaran los recursos disponibles por el autor del proyecto: • Portátil Macbook pro:

o Procesador Core i7 Intel de cuatro núcleos a 2,2GHz.

o 4GB de memoria RAM.

o 500GB de disco duro.

o Pantalla 15”.

• Impresora Multifunción Lexmark X1250.

7. Especificación de requisitos

En este apartado se tratará todo lo relacionado con el comportamiento que nuestro videojuego debe tener y los requisitos a cumplir.

Nuestro objetivo es el desarrollo de un videojuego en el lenguaje de programación Java y utilizando el framework de desarrollo de videojuegos Libgdx [BadLg]. Es por ello que uno de los principales requisitos consiste en adquirir los conocimientos necesarios en relación con las librerías que da a nuestra disposición Libgdx [Oeh13][DerYT], así como un estudio global del funcionamiento de un videojuego para tener una visión amplia de nuestro futuro desarrollo.

Tras este estudio, podemos listar los requisitos funcionales, listado por grado de importancia y orden a desarrollar, que trataremos en los siguientes apartados con más precisión:

1. Objetivo del videojuego.

2. Tiled Map.

3. Creación de los personajes.

4. Tile Base Grid Movement.

5. Colisiones.

6. Control de la posición.

7. Algoritmo de Detección.

8. Pantalla de Batalla.

9. Lógica de batalla.

10. Eventos.

11. Menús.

12. Carga y Guardado.

13. Carga de información.

14. Animaciones.

15. Sonido.

Capítulo 7 – Especificación de requisitos

29

7.1. Objetivo del videojuego

Todo videojuego debe tener un objetivo que motive al jugador a jugarlo. Es por ello que hemos listado los objetivos principales del videojuego:

• Subir de nivel al personaje: Muchas son las personas que se divierten haciendo subir de nivel a sus personajes y ver como “acaban con todos” los enemigos en pocos turnos.

• Eliminar a todos los FOE: Otro objetivo claro es limpiar el mapa de los enemigos mas fuertes llamados FOE.

• Encontrar todos los eventos: Otro objetivo es encontrar todos los eventos para así conocer toda la historia y desbloquear a su vez eventos secretos.

• Derrotar al enemigo final: Este videojuego tendrá un enemigo final al que se deberá derrotar para finalizar la partida.

7.2. Tiled Map

En este apartado trataremos el enfoque que queremos dar al desarrollo del mapa de juego donde se desarrollará el movimiento de los personajes y la trama de la historia. Para el diseño del mapa utilizaremos recursos gratuitos [Oga09]. Los primeros consisten en una imágenes de formato png llamadas Tile Based Map que representan un conjunto de secciones de la misma temática para crear mapas [Der01]. La unión de los distintos tiles en una malla pueden construir verdaderos mapas. A continuación mostramos un ejemplo de lo que se puede conseguir:

Ilustración 9 -‐ Ejemplo Tile Based Map


30

Como podemos ver en la sección superior izquierda, disponemos de una plantilla dividida en tiles, cada uno de estos tiles se utilizan como impresiones que realizaremos en nuestro mapa para construirlo.

Para esto utilizaremos un software gratuito llamado Tile Map Editor [Ilustración 10]. Con este software crearemos nuestro mapa para el RPG que queremos desarrollar. Además de añadir tiles a nuestro mapa, también podemos dar propiedades mediante etiquetas. Estas etiquetas podrán ser identificadas en nuestro programa de forma que los personajes del videojuego puedan distinguir entre una pared, o cualquier otro objeto que queramos definir.

Ilustración 10 -‐ Tile Map Editor 0.9.1

Como hemos visto, el mapa estará dividido en pequeños tiles [Der02]. Cada tile supondrá una posición para los personajes del juego. De esta manera podremos identificar en qué posición se encuentra cada personaje, y podremos aplicar los distintos algoritmos de movimiento que desarrollemos o desarrollen en un futuro.

Por lo tanto, nuestro requisito consistirá en el diseño e implementación de un mapa con un ángulo de visión aéreo en el que los personajes ocuparán posiciones fijas definidas por los tiles del mismo mapa, no pudiendo quedar los personajes entre dos tiles.

Además, incluiremos tiles de animación [Der06] y tiles de bloqueo [Oga09], de forma que los personajes no puedan superarlos, restringiendo el camino a recorrer y dando lógica a la visión del mapa.

7.3. Creación de personajes

En este proyecto se tienen tres requisitos relacionados con los personajes del juego. Los personajes del juego se compondrán tanto del propio jugador como de los enemigos del juego. A continuación mostramos los tres personajes que necesitamos implementar en nuestro videojuego:


31

• Jugador: Será un personaje representado gráficamente en el mapa mediante sprites, con movimiento mediante teclado, y del tamaño de un tile de mapa. Este personaje tendrá libre movimiento por el mapa, colisionando con paredes y animaciones (por ejemplo, objetos situados en el suelo) [Der02].

• Enemigo (FOE): Los enemigos llamados FOE serán enemigos representados visualmente mediante sprites. Al igual que el jugador, tendrán movimiento libre por el mapa de juego, colisionando, de la misma forma que el jugador, con el entorno. El sprite de un FOE eliminado desaparecerá del mapa, debido a que este tipo de personajes son únicos.

• Enemigos Aleatorios: Los enemigos aleatorios no son representados gráficamente en el mapa, y solo aparecerán con una probabilidad determinada. Esto hará que siempre haya enemigos disponibles en el juego, y por ello, estos enemigos serán más débiles que los denominados FOE.

7.4. Tile Base Grid Movement

Tile Base Grid Movement es un tipo de movimiento [Der05] característico de los juegos RPG. Como ya hemos comentado, el mapa de nuestro juego está compuesto por tiles. Estos tiles pueden verse como una gran malla (Grid) en la que cada tile supone una posición en el mapa. El movimiento planteado en este juego es un movimiento encasillado. Tanto el jugador como los FOE que interfieren en el juego se mueven de forma sistemática a casillas adyacentes, sin tener posibilidad de posicionarse entre dos casillas. Esto es debido a que nuestro videojuego estará estructurado en turnos. Cada turno el usuario podrá desplazarse una casilla, y a su vez, los enemigos en cada turno se desplazarán también una casilla tras el movimiento inicial del usuario.

El movimiento planteado para el jugador es de 1x1 en forma vertical y horizontal [Ilustración 11], como el movimiento de la torre en el ajedrez y de la misma forma se moverán los enemigos.


32

Ilustración 11 -‐ Movimiento en Grid

Si un jugador intenta un movimiento no permitido, como intentar ir hacia un tile bloqueado, el jugador no perderá el turno ya que no se moverá, pero en el caso de que un FOE “elija” un movimiento no permitido, dicho FOE no se moverá perdiendo dicho turno. Veamos movimientos no permitidos como:

• Movimiento a posiciones inaccesibles.

• Movimiento a posiciones donde está situado otro FOE.

• Movimiento a una posición donde otro FOE va a moverse.

7.5. Colisiones

En nuestro juego, como en cualquier otro, las colisiones desempeñan un papel muy importante en el funcionamiento del mismo [Der04]. Las colisiones con el entorno permiten que el movimiento del jugador sobre nuestro escenario o mapa tenga un sentido lógico y parecido a la realidad. De la misma forma que una persona no podría atravesar una pared, o podría tocar un objeto, con las colisiones pretendemos imitar esta funcionalidad de la vida real.

En nuestro caso, las colisiones tanto del jugador como del enemigo estarán relacionadas con los tiles de nuestro mapa que tengan una característica de bloqueo. De esta forma podremos añadir esta característica a tantos tipos de tiles como deseemos, y nuestros personajes al interactuar con ellos, lo reconocerán e identificarán que ese tipo de tile no puede ser ocupado [Ilustración 12].


33

Ilustración 12 -‐ Ejemplo de tiles bloqueados

Como podemos ver en el ejemplo anterior, los tiles marcados con un recuadro rojo son tiles con la característica de bloqueo. Es por ello que al interactuar el jugador con ellos, el movimiento del mismo se detendrá situándose en la posición más cercana posible a dicho tile inaccesible.

7.6. Control de la posición

Las colisiones con el entorno no son suficientes para el funcionamiento de nuestro videojuego. Al ser un juego por turnos, cada turno nuestros personajes se establecerán en una posición determinada. Estas posiciones deben ser registradas y controladas para tratar la funcionalidad del juego.

La primera y más importante consiste en el enfrentamiento entre el jugador y los FOEs. Cuando un jugador o un FOE se mueve hacia la posición del contrario, debe producirse un enfrentamiento. Es por esto que el control de cada posición y su registro es fundamental para identificar al FOE al que debemos enfrentarnos.

Otra razón de controlar la posición, viene dada por la necesidad de desarrollar algoritmos de detección del jugador por los FOEs, que hablaremos en un apartado posterior.

Además, nuestro juego debe disponer de opciones de guardado y cargado. Por ello estas posiciones deben registrarse para tener disponibilidad en todo momento de estos datos.

7.7. Algoritmo de detección

Este algoritmo será básico para nuestro videojuego. Se trata de un algoritmo de detección de jugadores, en nuestro caso, del jugador. De esta forma, si un jugador se acerca lo suficiente a un enemigo, este cambiará su estado normal a un


34

estado de alerta. Cuando un FOE pasa a estado de alerta persigue al jugador hasta que este consigue salir de su visión.

Para desarrollar el rango de visión utilizaremos la distancia de Manhattan de nivel 2 [Ilustración 13].

Ilustración 13 -‐ Rango de visión del FOE

La distancia de Manhattan de nivel 2 permite observar a dos casillas de distancia en horizontal y vertical y a una de distancia en diagonal. Debido a que nuestros personajes no pueden moverse de forma diagonal, el FOE deberá moverse dos casillas para acceder a un jugador que esté en su diagonal directa.

7.8. Pantalla de batalla

Las batallas de los RPG suelen ser pantallas en las que se muestran a los personajes del jugador, y los enemigos a los que se enfrentan. Estas pantallas suelen estar diseñadas con animaciones, y con un menú de batalla donde poder tomar decisiones y planificar la estrategia a realizar dependiendo del enemigo al que nos enfrentemos.

En nuestro juego, cuando el jugador y el FOE colisionan, se producirá un enfrentamiento. Este enfrentamiento deberá producirse en una pantalla de juego distinta del mapa. Deberá contener elementos gráficos que representen al jugador y al FOE y un menú donde poder tomar las elecciones a desempeñar. Tras reducir la vida del FOE, el control del juego regresará al mapa de juego, mientras que si es el jugador el que ve su vida reducida a cero, el control del juego no volverá y la siguiente pantalla que se mostrará será el menú de inicio del juego.

El control de la pantalla de batalla se dará con el ratón, y tendrá que tener un aspecto visual parecido al siguiente ejemplo:


35

Ilustración 14 -‐ Ejemplo de pantalla de batalla

Como podemos observar habrá que diseñar un fondo, unos enemigos y un personaje. El menú se encontrará en la parte inferior de la pantalla y constará de cuatro botones: Ataque, Magia, Defensa y Escapar.

Cada una de estas opciones tendrá una funcionalidad diferente que trataremos en el apartado siguiente. Además incluiremos una línea de información que nos comunicará el estado de la batalla en cada momento, nombre de la acción producida, vida perdida, daño producido, etc.

7.9. Lógica de batalla

Las batallas estarán determinadas por lógicas dependiendo de la acción que se desempeñe. Además, tendremos que tener en cuenta un factor del que no hemos hablado hasta el momento, las estadísticas de los personajes.

Los personajes deben tener un conjunto de estadísticas que determinarán el poder de los mismos. Estas estadísticas se listan a continuación:

• Ataque: Referente al poder de ataques físicos

• Magia: Referente al poder de ataque mágico.

• Defensa: Referente a la resistencia ante ataques físicos.

• Defensa mágica: Referente a la resistencia ante ataques mágicos.

• Rapidez: Referente a la velocidad de ataque.

• Suerte: Referente a la probabilidad de escapar de una batalla.


36

• Experiencia: Experiencia recogida por el jugador para subir de nivel.

• Nivel: Nivel de personaje.

• Experiencia dada: Experiencia que da un FOE al ser derrotado por el jugador.

Con la definición de estos datos podremos determinar la lógica de la batalla. En ella habrá 4 tipos de acciones:

• Ataque: Esta opción listará un conjunto de ataques a elegir.

• Magia: Esta opción listará un conjunto de magias a elegir.

• Defensa: Esta opción reforzará la defensa reduciendo el daño.

• Escapar: Esta opción te permitirá escapar de la batalla con una probabilidad.

Las fórmulas utilizadas para el cálculo de daño recibido o enviado, y la fórmula de probabilidad de escape serán las que se muestran a continuación [Tabla 3].

Acción Fórmula Ataque ((poderAtaque/dificultad)*ataque) -‐ defensa Magia (poderMagia/dificultad)*ataqueEspecial) -‐ defensaEspecial

Defensa ((poderAtaque ó poderMagia)/dificultad)*(ataque ó

ataqueEspecial) Escapar Si random + suerte > 50

Tabla 3 -‐ Fórmulas de batalla

La elección de ataques formulados por los FOE estarán diseñados bajo probabilidades de ocurrencia. No vamos a tratar como requisito el desarrollo de un algoritmo que “piense” qué acción perjudica más al usuario y beneficia al enemigo. Sin embargo, dejaremos abierta la posibilidad de desarrollar este tipo de algoritmos a futuros desarrolladores interesados en la temática.

7.10. Eventos

En nuestro videojuego deberán producirse los denominados eventos. Los eventos son revelaciones que se producen bajo ciertas circunstancias. De esta forma podemos decir que un evento consiste en una entrega de información al jugador cuando se cumplen ciertas condiciones.

Nosotros tendremos dos clases de eventos: Eventos de batalla y eventos de historia.


37

Los eventos de batalla se centrarán simplemente en establecer batallas sin que exista un FOE establecido en el mapa. Serán batallas aleatorias que se producirán al recorrer el mapa con una cierta probabilidad. En nuestro caso la probabilidad de batalla aleatoria estará establecida en un 5%. Esto quiere decir que de cada 100 pasos o turnos de movimiento, se producirán 5 batallas aleatorias. Las batallas aleatorias solo podrán darse contra enemigos que no están disponibles en el mapa, serán batallas contra enemigos débiles, y no contra FOEs.

El segundo tipo de evento será el evento de historia. Este evento podrá darse por dos razones.

• El evento de historia podrá producirse por el acceso del jugador a una casilla determinada. De esta manera si nos situamos en una posición establecida, podremos narrar la historia llegados a ese punto.

• El evento de historia podrá producirse al cumplir unos objetivos. Si durante el curso del juego hemos logrado acceder a cierta cantidad de eventos, se desbloquearán nuevos eventos.

Los eventos de historia siempre irán seguidos de un evento de batalla. Este evento de batalla será configurable, es decir, podremos establecer contra qué enemigo luchar, ya sea enemigo aleatorio o un FOE. De esta manera podremos configurar batallas contra jefes únicos (finales o secretos).

7.11. Menús

En nuestro videojuego dispondremos de dos tipos de menú. Un menú principal y un menú de juego.

El menú principal aparecerá tras iniciar la aplicación, y constará de las siguientes partes:

• Un botón de inicio de partida. Este botón iniciará la partida desde cero.

• Un botón de carga de partida. Este botón cargará los datos guardados. En caso de que no haya datos guardados, no realizará ninguna función.

• Un botón de salida. Este botón hará que podamos salir de la aplicación correctamente.

El menú de juego aparecerá tras pulsar la tecla Enter del teclado, y constará de las siguientes partes:

• Un botón de guardado. Este botón guardará el progreso actual del juego sobrescribiendo cualquier guardado anterior.


38

• Un botón de retorno al juego. Este botón devolverá el control del personaje en el mapa, saliendo así del menú de juego.

• Un botón de salida. Este botón reiniciará el juego y nos hará ir al menú principal.

Además, en el menú del juego se mostrarán las estadísticas actuales del jugador.

7.12. Cargado y Guardado

El videojuego tendrá que tener la funcionalidad de cargar y guardar datos.

Los datos que se cargarán y se guardarán son datos necesarios para almacenar el avance del juego. A continuación listamos los más destacados, pero entendemos que en el transcurso de desarrollo del videojuego podrán incluirse más información a tratar:

• Posición del Usuario

• Posición de los FOEs

• Número total de FOEs vivos.

• Número de eventos pendientes.

• Identificadores de eventos pendientes.

• Nivel del jugador.

7.13. Carga de información

Con este apartado queremos hacer referencia a la carga de datos estática. Nuestro juego debe ser capaz de cargar configuraciones fijas establecidas. Estos datos no variarán a lo largo del juego, pero serán necesarios para su funcionalidad. Listamos los datos considerados, aunque como en el apartado anterior, pueden variar a lo largo del desarrollo por necesidades:

• Estadísticas iniciales del jugador.

• Estadísticas de FOEs y enemigos aleatorios.

• Habilidades del jugador.

• Habilidades de FOEs y enemigos aleatorios.


39

• Posiciones de eventos.

• Información de eventos.

• Mapa de posicionamiento.

• Diseños de Screens.

• Diseños de mapa.

• Diseños de sprites del jugador y enemigos.

• Sonido.

7.14. Animaciones

Las animaciones en nuestro videojuego tienen un papel importante para la presentación del mismo. El diseño de animaciones hará que el jugador se sienta visualmente atraído por el videojuego.

Por ello hemos distinguido tres tipos de animaciones a desarrollar:

• Animación del tile: Esta animación será una animación sobre el propio mapa [Der06]. De la misma forma que podemos poner tiles con forma de rocas, tierra, agua, etc, también podemos crear pares de tiles que se alternaran en el tiempo imitando el movimiento. Así podremos imitar por ejemplo el movimiento de una flor [Ilustración 15].

Ilustración 15 -‐ Ejemplo de animación de tiles

• Animación de personajes: Este tipo de animación también se dará sobre el mapa. Cuando el jugador se mueva, su personaje deberá imitar la acción de andar o correr, al igual que los propios enemigos. Por ello, deberemos diseñar un conjunto de sprites [Ilustración 16] que representen dicho movimiento [Der03][Der05].


40

Ilustración 16 -‐ Ejemplos de sprites del jugador de movimiento

• Animación de batalla: Durante las batallas, el juego representará el movimiento tanto del jugador como del enemigo a enfrentarse. Esto puede constar de una serie de sprites que superpuestos generen movimiento, de la misma forma que los frames sobre un video o un gif [Ilustración 17].

Ilustración 17 -‐ Ejemplo de sprites de animación de batalla

7.15. Sonido

En nuestro Trabajo de Fin de Máster no tenemos como requisito la creación de sonidos propios, pero sí es necesario saber añadir sonidos y efectos a nuestro videojuego, por ello que utilizaremos sonidos free para el desarrollo de nuestro juego [Oga09]. Dispondremos de tres clases de sonido:

• Sonido de botones: Los botones deberán reproducir un sonido de efecto al clicar sobre ellos. Este sonido debe ser de aprobación en caso de que nuestra acción sea adecuada, o de negación en caso de que la acción que intentemos desempeñar no se pueda realizar.

• Sonido de efectos: Los sonidos de efectos se reproducirán en ciertas circunstancias, como por ejemplo al golpear o ser golpeados por los enemigos.

• Banda sonora: Nuestro videojuego deberá reproducir canciones en bucle dentro de los menús, del mapa de juego y de la batalla, acordes a la situación.

8. Análisis del sistema

En este capítulo se tratará el estudio realizado del futuro sistema a desarrollar. Para ello hablaremos sobre los distintos casos de uso que tendrá nuestro sistema tanto para el usuario como para el desarrollador. Además, mostraremos el ciclo funcional que nuestro videojuego poseerá para posteriormente diseñar nuestro sistema acorde a nuestros objetivos y requisitos.

8.1. Arquitectura general del sistema

Nuestro proyecto estará dedicado a la creación de un videojuego bajo el framework Libgdx implementado en Java, por lo que se ejecutará bajo una máquina virtual de dicho lenguaje [Ilustración 18].

Ilustración 18 -‐ Arquitectura general

8.2. Casos de uso

Los caso de uso que trataremos serán de dos tipos: Para usuario y para desarrollador [Ilustración 19 y 20].

Ilustración 19 -‐ Casos de uso del usuario

Videojuego

Lenguaje Java

Framework Libgdx

Máquina Virtual Java

Capítulo 8 – Análisis del sistema

42

Ilustración 20 -‐ Casos de uso del desarrollador

Como vemos son bastante simples. El usuario solo podrá ejecutar el videojuego y jugar con él, mientras que el desarrollador podrá implementar nuevos algoritmos y personajes para el videojuego.

8.3. Ciclo del videojuego

El ciclo de funcionamiento del videojuego lo mostramos en la siguiente ilustración:

Ilustración 21 -‐ Ciclo de ejecución del videojuego

A continuación describimos los pasos que realiza la ejecución del videojuego desde el punto de vista del usuario:

1. Ejecución: El usuario ejecutará la aplicación.

2. Splash Intro: El videojuego mostrará un screen de entrada durante dos segundos. Es un screen de créditos.

Capítulo 8 – Análisis del sistema

43

3. Main Menu: El usuario llegará al menú principal de la aplicación, donde podrá salir (8), comenzar una nueva partida (4), o cargar una partida guardada (5).

4. Splash Info: El usuario al comenzar una nueva partida, se encontrará con un screen que le mostrará los controles del juego durante dos segundos.

5. Play Screen: El usuario se encontrará en el mapa del juego, pudiendo desplazarse sobre él.

6. Battle Screen: En ocasiones el usuario tendrá que enfrentarse a enemigos. Esta pantalla está directamente comunicada con la pantalla de juego (5).

7. Play Menu: En cualquier momento, el usuario puede pulsar “Enter” para acceder al menú de juego, con tres posibilidades, Guardar el juego, Volver al juego (5), salir del juego (2) volviendo al inicio.

9. Diseño del sistema

En este capítulo detallaremos cada una de las clases que será necesario implementar para desarrollar nuestro videojuego. Estas clases están sacadas de los datos recogidos en la especificación de requisitos, el ciclo de ejecución y la propia definición del problema. En la siguiente figura, podremos ver un diagrama con la relación existente entre las clases que componen nuestro sistema [Ilustración 22].

Ilustración 22 -‐ Diagrama de relación entre las clases del videojuego

Para la descripción de cada una de las clases, distinguiremos los siguientes apartados:

• Nombre de la clase: Nombre identificativo que se le asignará a la clase. Este nombre debe ser descriptivo, de manera que proporcione información acerca del funcionamiento general que tendrá dicha clase.

• Descripción general de la clase: Se indicará cuál es el objetivo principal de la clase, explicando dicho objetivo junto con cualquier información

Capítulo 9 – Diseño del sistema

45

adicional que pudiera resultar de interés para el entendimiento de la clase.

• Variables miembro de la clase: Nombraremos y detallaremos aquellos atributos que creamos importantes y que la clase necesitará para guardar la información que necesita para desempeñar su funcionalidad de manera correcta, indicando su tipo y las principales características a destacar.

• Métodos de la clase: Se analizarán todos aquellos métodos definidos por la clase.

9.1. Videojuego DemonSoul

En este apartado detallaremos cada una de las clases diseñadas para nuestro proyecto. En nuestro workspace encontraremos dos proyectos reglamentados por el framework Libgdx. Uno llamado Desktop donde encontraremos la clase Main, y otro llamado Core donde encontraremos el resto de clases [Ilustración 23].

Ilustración 23 -‐ Workspace

Las clases detalladas a continuación tendrán una simbología para clasificar las variables miembro y método por pública (+), privada (-‐) o protegida (#).

9.2. Main Game

• Nombre: MainGame • Descripción: Clase Main del sistema.


46

9.3. Tile Map Game

• Nombre: TileMapGame • Descripción: Clase inicial que llama a la primera pantalla de juego. En

nuestro caso a SplashScreen.

9.4. Battle Algorithm

• Nombre: BattleAlgorithm • Descripción: Clase dedicada al algoritmo de batalla. • Variables miembro:

o + damage: daño producido o recibido. o -‐ difficult0-‐1-‐2: Dificultad del FOE en la batalla. o + foeId: identificador del FOE. o + foeType: Tipo de FOE.

• Métodos: o + attackOrMagic(): Elección del FOE de ataque físico o mágico. o + attackToFoe(int,int,int,int): Secuencia de ejecución de ataque

al FOE. o + attackToPlayer(int,int,int,int): Secuencia de ejecución de

ataque al jugador. o + defenseAtk(int, int, int, int): Defensa frente un ataque físico. o + defenseMag(int, int, int, int): Defensa frente un ataque mágico. o + foeIDToBattle(): Identificar el id del FOE a combatir. o + getAttackMagicId(): Obtener el id del ataque físico o mágico. o + getExperience(int, int, int, int): Obtiene la experiencia que va a

ganar el jugador tras vencer al enemigo. o + getFoeTypeToBattle(): Obtiene el tipo de enemigo a combatir. o + getFoeTypeToRandomBattle(): Obtiene un enemigo aleatorio

de entre dos posibilidades. o + heal(): Mágia que cura la vida del jugador. o + magicToFoe(int, int, int, int): Secuencia de ejecución de ataque

mágico al jugador. o + magicToPlayer(int, int, int, int): Secuencia de ejecución de

ataque mágico al enemigo. o + run(): Intento de escapar de la batalla.

9.5. Events

• Nombre: Events


47

• Descripción: Clase dedicada a tratar los eventos que se producen en el mapa del juego.

• Variables miembro: o + foeType: Tipo de FOE al que vamos a enfrentarnos tras el

evento. • Métodos:

o + callEvent(int, int): Llamada a los eventos normales del juego. o + callSpecialEvent(int, int): Llamada a los eventos secretos del

juego. o + endEvent(int, int): Llamada al evento final del juego. o + eventS(int): Tratamiento del evento corriente, el flujo del

evento. o + eventSpecial(): Flujo de evento especial. o + loadEvents(String): Carga de evento. o -‐ toArrayListInteger(String): Función auxiliar de transformación.

9.6. Foe Algorithm

• Nombre: FoeAlgorithm • Descripción: Clase dedicada al algoritmo de persecución del FOE frente

al jugador, y del tipo de movimiento. • Variables miembro:

o -‐ firstMovement: movimiento anterior del FOE. o -‐ foeId: identificador del FOE. o -‐ move: variable de control de movimiento.

• Métodos: o + FoeAlgorithm(int): constructor del algoritmo. o -‐ algorithmToMove(): algoritmo de detección del jugador. o -‐ chooseMovement(int): algoritmo de elección de movimiento. o + getMovement(): obtener el tipo de movimiento.

9.7. Foe Collisions

• Nombre: FoeCollisions • Descripción: Clase dedicada a la colisión de los FOE con el entorno y el

jugador. • Variables miembro:

o + battleDirection: dirección de movimiento donde se produciría una batalla.

o + direction: dirección elegida.


48

o + tileHeight & tileWidth: tamaño del tile. • Métodos:

o + FoeCollisions(int, float, float) & FoeCollisions(String, int, float, float): Constructores parametrizados.

o + foeCollisionsAlgorithm(): Algoritmo de colisión. o + foePlayerCollisionsAlgorithm(): Algoritmo de colisión con el

jugador.

9.8. Player Collisions

• Nombre: PlayerCollisions • Descripción: Clase dedicada a la colisión del jugador con el entorno y los

Foe. • Variables miembro:

o + battleDirection: dirección de movimiento donde se produciría una batalla.

o + direction: dirección elegida. o + tileHeight & tileWidth: tamaño del tile.

• Métodos: o + PlayerCollisions(String, int, float, float): Constructor

parametrizado. o + PlayerCollisionsAlgorithm(): Algoritmo de colisión.

9.9. Foe

• Nombre: Foe • Descripción: Clase dedicada a la instanciación y parametrización de un

FOE. • Variables miembro:

o -‐ animation: animación del FOE. o -‐ collisionBattle: colisión de batalla. o -‐ collisionLayer: colisión con el entorno. o -‐ collisionWithFoe: colisión con un FOE. o -‐ direction: dirección a tomar. o -‐ down, up, right, left: control de direcciones. o -‐ foeId: identificador del FOE. o -‐ texture: textura del FOE. o -‐ positionX: posición en el eje X del mapa. o -‐ positionY: posición en el eje Y del mapa. o -‐ random: variable aleatoria.


49

o -‐ step: pasos de control del FOE. o -‐ velocity: velocidad de movimiento.

• Métodos:

o + Foe(int, TextureAtlas, TextureAtlas, TextureAtlas, TiledMapTileLayer, float, float): Constructor parametrizado del FOE.

o + draw(): refrescar el pintado del FOE. o + getFoeId(): devuelve el ID del FOE. o -‐ refreshBattleSprite(): Recargar el sprite de batalla. o -‐ refreshSprite(): Recargar el sprite del mapa. o -‐ update(): actualización constante del estado del FOE.

9.10. Player

• Nombre: Player • Descripción: Clase dedicada a la instanciación y parametrización del

jugador. • Variables miembro:

o -‐ animation: animación del jugador. o -‐ playerCollision: colisión del jugador con los FOEs. o -‐ collisionLayer: colisión con el entorno. o -‐ direction: dirección a tomar. o -‐ down, up, right, left: control de direcciones. o -‐ listenerDown, listenerUp, listenerRight, listenerLeft: control de

direcciones al pulsar tecla. o -‐ texture: textura del jugador. o -‐ positionX: posición en el eje X del mapa. o -‐ positionY: posición en el eje Y del mapa. o -‐ press: control de tecla de dirección presionada. o -‐ velocity: velocidad de movimiento.

• Métodos: o + Player(TextureAtlas, TextureAtlas, TiledMapTileLayer, float,

float): constructor parametrizado del jugador. o -‐ actualizarPosicionPlayerMap(float, float, String): actualiza la

posición del jugador en la matriz de control de posición. o -‐ autorizarMovimientoFoe(): autoriza el movimiento del FOE. o -‐ autorizarMovimientoPlayer(): autoriza el movimiento del

jugador. o + draw(): refrescar el pintado del jugador. o -‐ event(): llama a un evento.


50

o -‐ randomBattleOrFoeMovement(): elección entre batalla o paso a movimiento enemigo.

o -‐ refreshSprite(float): Refresca el sprite del jugador. o -‐ update(): actualiza la situación del jugador.

9.11. Load Config

• Nombre: LoadConfig • Descripción: Clase dedicada a cargar los parámetros de entrada del

videojuego. • Variables miembro:

o + foePositionX: posición eje X del FOE en el mapa. o + foePositionY: posición eje Y del FOE en el mapa. o + playerPositionX: posición eje X del jugador en el mapa. o + playerPositionY: posición eje Y del jugador en el mapa. o + foe: foes del mapa. o + foeType: tipos de los FOEs cargados. o + loadGame: Carga de juego guardado. o + newGame: Carga de nuevo juego. o + tileMap: tile del mapa. o + height, width: tamaño del tile.

• Métodos: o + LoadConfig(int, int, String): constructor de carga de datos. o + loadConfiguration(): carga de datos. o -‐ loadMapPosition(int, int): carga de posiciones en el mapa. o -‐ loadPlayerStats(): carga de stats del jugador.

9.12. Parameters

• Nombre: Parameters • Descripción: Clase dedicada a variables globales de control del

videojuego.

9.13. Save Progress

• Nombre: SaveProgress • Descripción: Clase estática que guarda el progreso. • Métodos:

o + SaveProgress(): guarda el progreso.


51

9.14. Battle Screen

• Nombre: BattleScreen • Descripción: Clase que trata la carga, estructura y funcionalidad de la

pantalla de batalla. • Variables miembro:

o + attack: ataque del jugador. o + defense: defensa del jugador. o + magic: magia del jugador. o + luck: suerte del jugador. o + spAttack: ataque especial del jugador. o + spMagic: ataque mágico especial del jugador. o + hp: vida del jugador. o + pm: magia del jugador. o + Speed: rapidez del jugador. o + level: nivel del jugador. o + attackAbility: ataques del jugador. o + attackPower: poder de los ataques del jugador. o + costMagic: coste de magia. o + magicAbility: magias del jugador. o + magicPower: poder de los ataques mágicos del jugador. o + foeStadistics: estadísticas del FOE.

• Métodos: o -‐ loadAttacks(): carga de ataques del jugador. o -‐ loadBattleTable(): carga de la tabla de ataques. o -‐ loadFoeAttack(int): carga de ataques del FOE. o -‐ loadFoeMagic(int): carga de magias del FOE. o -‐ LoadFoeStats(): carga de stats del FOE. o -‐ LoadAttacks(): carga ataques del jugador. o -‐ LoadMagics(): carga magias del jugador. o -‐ LoasPlayerStats():carga de stats del jugador. o -‐ returnPowerAttack(int): devuelve el daño realizado. o -‐ returnPowerMagic(int):devuelve el daño realizado.

9.15. Info Splash Screen

• Nombre: InfoSplashScreen • Descripción: Clase de transito entre el menú de entrada y el nuevo

juego.


52

9.16. Main Menu Screen

• Nombre: MainMenuScreen • Descripción: Clase de menú de inicio del juego.

9.17. Play Menu Screen

• Nombre: PlayMenuScreen • Descripción: Clase de menú de juego.

9.18. Play Screen

• Nombre: PlayScreen • Descripción: Clase de mapa de juego donde se desarrolla la historia. • Variables miembro:

o -‐ battleSound: efecto de sonido de batalla. o -‐ BattleSprite: sprite de intro de batalla. o -‐ camera: cámara del juego. o -‐ eventSprite: sprite diseñado para los eventos. o -‐ foe: FOEs del juego. o -‐ map: mapa del juego. o -‐ mapSound: sonido en el mapa del juego. o -‐ newLine: texto de eventos. o -‐ player: jugador. o -‐ skin: skin de fuente de letras.

• Métodos: o + render(): renderiza el mapa.

9.19. Splash Screen

• Nombre: SplashScreen • Descripción: Clase de transito al inicio del juego como créditos.

9.20. Actor Accessor

• Nombre: ActorAccessor • Descripción: Clase auxiliar para la funcionabilidad de los splash screens.

10. Descripción de la información

Nuestro proyecto requiere un conjunto de datos que para el desarrollador es fácil de tratar si se disponen en ficheros de entradas ordenados y clasificados. Estos datos pueden ser datos estáticos, incluidos en el jar de nuestro videojuego, o datos de configuración que pueden ir variando a lo largo de la historia.

La decisión de haber utilizado ficheros de tipo properties fue tomada por la facilidad de editar estos ficheros de texto. Si hubiéramos cargado los datos en variables estáticas finales dentro del código, futuros desarrolladores tendrían que modificarlo, por lo que pensamos en el futuro del videojuego para su reusabilidad.

A continuación mostramos las carpetas incluidas dentro del proyecto core. Estos documentos son sprites, datos, ilustraciones y sonidos que utilizaremos en el juego [Ilustración 24].

Ilustración 24 -‐ Assets dentro del proyecto Core

Los siguientes ficheros que mostramos son los de configuración. Estos podrán ser fácilmente editados por los futuros desarrolladores y se encontrarán fuera del jar ejecutable [Ilustración 25].

Ilustración 25 -‐ Ficheros de configuración

11. Pruebas y resultados En este apartado trataremos las pruebas realizadas para demostrar la

fiabilidad y la calidad de nuestro videojuego. Nuestras pruebas están definidas como unitarias, probando partes puntuales del software, e integradas, donde probaremos el ciclo completo del mismo.

La demostración de estas pruebas resulta compleja porque los resultados obtenidos son en tiempo de ejecución y no disponemos de datos físicos. Es por ello que comentaremos el tipo de prueba y los problemas que nos surgieron en cada momento en el caso de que sucedieran.

• Pruebas unitarias:

o Pruebas de movimiento. Las pruebas de movimiento eran visuales, para que tanto el jugador como el FOE permaneciesen dentro del tile, y no ocupasen dos tile a la vez.

§ El gran problema fue encontrar la solución para que el movimiento de cada turno fuese cuadriculado. El jugador solía quedarse en posiciones erróneas (entre dos tile). La solución consistía en cuadrar las comprobaciones de posición mediante el resto de la división del tamaño total del mapa, con el tamaño el tile del personaje, cuando se consiguió que fuese cero, corregimos el problema.

o Pruebas de colisión. Las pruebas de colisión consistieron en probar las distintas colisiones tanto con el mapa como con los FOE.

§ Muchos de los fallos producidos eran visuales, en los que el jugador al colisionar con los muros, seguía simulando el movimiento de andar.

§ Con respecto a los FOE no tuvimos problema, ya que planteamos un sistema de control de posición mediante una matriz de enteros.

o Pruebas algorítmicas de movimiento y de batalla. Estas pruebas consistían en ver si el comportamiento de los algoritmos era el adecuado:

§ El algoritmo de movimiento enemigo consiste en que el enemigo al “ver” al jugador persigue a este de forma continua hasta que sale de su rango de visión. Solo

Capítulo 11 – Pruebas

55

encontramos problemas puntuales de control de la matriz de posición generada para calcular las posiciones que el enemigo puede ver.

§ Las pruebas de batalla consistían en ver el ciclo natural de una batalla, controlando que ningún paso era saltado y que no se producían incongruencias o resultados de daño producido o recibido que no tuvieran sentido.

§ En la batalla también realizamos muchas pruebas para calibrar las fórmulas de daño que utilizábamos.

o Pruebas de sonido. Estas pruebas solo consistían en ver el correcto funcionamiento del sonido, tanto en las pantallas, como menús y haciendo click sobre botones.

o Pruebas de carga y guardado. Pruebas de lectura y escritura de los ficheros properties de carga y guardado. Los principales problemas radicaban en errores de rutas o no disponibilidad de ficheros. La solución era establecer una buena configuración y controlar los errores mediante los módulos try-‐catch.

• Pruebas integradas:

o Pruebas de casos de uso. En estas pruebas nos situamos en el punto de vista del usuario. Se basaban en repetir los distintos ciclos de uso que el usuario podría realizar jugando. La mayoría de los problemas nos surgía en el cambio de pantallas, siendo la solución corregir la relación entre las mismas.

12. Conclusiones Tras la realización de nuestro proyecto podemos decir que todos los objetivos

que marcamos inicialmente se han cumplido. La planificación marcada inicialmente se ha realizado con éxito cumpliendo los tiempos marcados.

Las pruebas realizadas sirvieron para solventar los distintos problemas encontrados a lo largo del desarrollo de nuestro videojuego, no quedando ningún error que hayamos podido reproducir.

Uno de los principales objetivos que consistía en permitir a futuros desarrolladores la reutilización del código del proyecto para implementar nuevos algoritmos y enemigos personalizables se ha cumplido, detallándolo en el Anexo II de este documento.

Como conclusión podemos comentar la gran experiencia de construir este tipo de proyecto desde cero. De esta forma hemos podido aprender el desarrollo de un videojuego, desde la creación del entorno, el diseño de personajes, la codificación de motores de movimiento y colisiones, y algoritmos de ayuda para implementar lógicas de batalla y movimiento de los personajes. Los resultados obtenidos son gratificantes ya que este tipo de proyecto es muy visual, y permite ver de manera directa el esfuerzo dedicado en su desarrollo.

Anexo I : Manual de usuario

En este primer anexo daremos información al usuario sobre el videojuego desarrollado, guiándolo desde la ejecución hasta el guardado de partida, pasando por los distintos aspectos del juego relevantes para su jugabilidad.

1. Ejecución del videojuego

Antes de ejecutar el videojuego tenemos que estar seguros de que la máquina virtual java está instalada en nuestro sistema. Si no lo está debemos acceder al siguiente enlace y descargar e instalar el paquete descargado:

https://www.java.com/es/download/

Una vez instalado podemos comenzar con la ejecución del videojuego. El usuario encontrará dos carpetas y un archivo de extensión .jar [Ilustración 26].

Ilustración 26 -‐ Ficheros de juego

La carpeta “demonSoul_lib” contiene las librerías necesarias para el funcionamiento de la aplicación. La carpeta “cfg” contiene la configuración del videojuego y los datos de guardado, y por último, el ejecutable “demonSoul.jar” será el que debemos ejecutar para acceder al mismo. Tras su ejecución se nos abrirá una nueva ventana y tras varios segundos nos encontraremos en el menú principal del juego [Ilustración 27].

Ilustración 27 -‐ Menú principal

Anexo I – Manual de usuario

58

2. Iniciar nueva partida

Para iniciar una nueva partida, una vez ejecutada la aplicación, tenemos que hacer click sobre el botón New Game del menú principal con el botón izquierdo del ratón.

3. Controles

Los controles de este videojuego son tres:

• Movimiento del personaje: Utilizaremos los botones de dirección del teclado.

• Menú del juego: Para acceder al menú del juego simplemente tenemos que pulsar el botón Enter del teclado.

• Control de batalla y menús: Tanto en la pantalla de batalla como de los dos menús del juego utilizaremos el ratón para interactuar con los distintos botones disponibles [Ilustración 28].

Ilustración 28 -‐ Screen de Información de controles

4. Mapa de juego

El mapa de juego es donde se desplazará nuestro jugador. Las zonas oscuras son zonas inaccesibles y las puertas no están diseñadas para atravesarlas. A continuación mostramos el mapa utilizado:


59

Ilustración 29 -‐ Mapa de juego

5. Carga y guardado de la partida.

Para cargar una partida guardada simplemente tenemos que hacer click sobre el botón Load Game del menú principal con el botón izquierdo del ratón.

Para salvar la partida tendremos que acceder al menú de juego y pulsar sobre el botón Save Game [Ilustración 30].

Ilustración 30 -‐ Menú de juego


60

6. Enemigos y batallas

El jugador llamado Dae, estará representado por los siguientes sprites:

Ilustración 31 -‐ Sprite Player

Los FOE (enemigos) estarán representados en el mapa como bolas de humo. Habrá tres tipos de FOEs que variarán dependiendo del nivel de dificultad. La dificultad va de menor a mayor con los colores verde, naranja y morado:

Ilustración 32 -‐ Sprites FOEs

Si te acercas lo suficiente a un FOE, este cambiará su color a rojo y te perseguirá de forma constante hasta que te atrape o lo esquives:

Ilustración 33 -‐ Persecución FOE

A continuación se muestran los FOEs y enemigos comunes junto a sus estadísticas y consejos para derrotarlos [Tabla 4].

Nombre y diseño Estadísticas Consejos Cat Demon

Attack=5 Defense=10 SpAttack=3 SpDefense=5 Speed=8 Luck=5 HP=50 PM=25 Level=2 Exp=25

Cat Demon es débil a los ataques físicos y mágicos. Es fácil de derrotar a niveles bajos. Level necesario para vencer: Cualquiera


61

Moring


Moring es débil a ataques mágicos y fuerte contra ataques físicos. Level necesario para vencer: Cualquiera

King Moring


King Moring es débil a ataques mágicos y fuerte contra ataques físicos. Es el FOE más débil, pero no debes confiarte. Level necesario para vencer: 5

Demoness


Demoness es débil contra ataques físicos y fuerte contra ataques mágicos. Es un FOE de nivel intermedio. Level necesario para vencer: 10

Wolf


Wolf es fuerte contra ataques físicos y mágicos. Es el FOE mas fuerte de los que puedes encontrar en el mapa. Se requiere un nivel alto. Level necesario para vencer: 15


62

Dragon


Dragon es el Jefe final del juego. Es débil contra ataques mágicos. Se requiere un nivel alto. Level necesario para vencer: 19

Lia


Lia es el jefe secreto del juego. Es fuerte contra ataques mágico y débil contra ataques físicos. Es el enemigo mas fuerte del juego. Level necesario para vencer: 21

Tabla 4 -‐ FOEs

Las batallas [Ilustración 34] se producirán de dos maneras. De forma aleatoria o colisionando con un FOE del mapa. Al finalizar la batalla, volveremos el mapa del juego. Si somos derrotados, volveremos al menú principal.

Ilustración 34 -‐ Batalla


63

El jugador obtendrá más ataques conforme vaya subiendo de nivel [Tabla 5]. A continuación mostramos la lista de ataques por nivel:

Nivel Ataque Poder Coste

1 Cut 5 -‐ Cure 10 5

2 Sword Thrust 10 -‐ Fire 10 5

5 Sword Dance 15 -‐ Flamethrower 20 15

9 Quick Claw 20 -‐ Light Arrow 30 20

13 Silver Arrow 25 -‐ Cure+ 35 25

17 Bomb Flower 35 -‐ Hammer Blow 40 30

20 Master Sword Thrust 45 -‐ Triforce Punch 50 50

Tabla 5 -‐ Ataques jugador

Las estadísticas iniciales del jugador [Tabla 6] se irán incrementando al subir de nivel. Las estadísticas iniciales son:

Jugador Estadísticas Iniciales (Level 1) Dae

Attack=5 Defense=10 SpAttack=3 SpDefense=5 Speed=8 Luck=2 HP=100 PM=100 Level=1 TotalExp=0 NextLevel=100 Nota: Las estadísticas del jugador van incrementando linealmente con el nivel.

Tabla 6 -‐ Estadísticas del jugador

7. Eventos

Los eventos [Ilustración 35] se producen cuando te sitúas en ciertas posiciones del mapa. Para avanzar en la conversación de un evento, utiliza el ratón pulsando Next sobre el botón inferior derecho que aparecerá sobre el mapa.


64

Ilustración 35 -‐ Eventos

En algunos eventos conseguirás trozos de pergamino. Cuando consigas siete, se activará un evento secreto en un punto oculto del mapa.

Anexo II : Manual del desarrollador

En este segundo anexo daremos información al desarrollador sobre las secciones del videojuego que podrá ampliar, guiándolo por los distintos tipos de algoritmos que podrá implementar e indicarle qué parte del código tratar.

1. Introducción

Todo desarrollador que tenga interés en la implementación de algoritmos de movimiento enemigo, algoritmos de batalla, o adición de tipos de enemigos, modificación de estadísticas, eventos o historia del juego, tendrá que tratar con el proyecto encontrado en el workspace llamado Core [Ilustración 36].

Ilustración 36 -‐ Proyecto Core

Anexo II– Manual de desarrollador

66

2. Algoritmos de movimiento enemigo

Los algoritmos de movimiento de batalla se encuentran en el paquete “algorithms”. Para añadir algoritmos debemos modificar la clase FoeAlgorithm.java. Esta clase devuelve únicamente un String con la dirección que debe tomar el enemigo.

Gracias a los parámetros globales de la clase Parameters.java del paquete “resources”, tendremos a disposición una gran variedad de información del videojuego, como posiciones de personajes tanto el jugador como enemigos, y el mismo mapa del juego. Estos parámetros podrán ser utilizados en nuestros algoritmos para programarlos y obtener nuevas lógicas de movimiento.

3. Algoritmos de batalla

Los algoritmos de batalla deben ser tratados en el mismo paquete “algorithms” del apartado anterior. Utilizaremos la clase BattleAlgorithm.java. En esta clase tendremos que crear nuevos métodos que tomen decisiones sobre, por ejemplo, qué acciones realizan los enemigos, dependiendo del estado del jugador, para hacer su victoria más difícil, ya que actualmente la elección del ataque enemigo, es aleatorio.

También tendremos que tratar la clase BattleScreen.java del paquete “screens”. Aquí añadiremos los nuevos métodos que creemos, los nuevos algoritmos, en la parte del código donde el enemigo ataca.

4. Otras implementaciones

Otras implementaciones del juego son las relacionadas con la configuración del mismo, utilizando la carpeta de configuración mostrada en el apartado 10 de este documento. Implementaciones posibles:

• Nuevos enemigos. • Nuevas estadísticas. • Nuevas localizaciones de los enemigos y el jugador. • Nuevos eventos. • Nuevas historias.

Bibliografía

[Oeh13] Andreas Oehlke. Learning Libgdx Game Development. ISBN 978-‐1-‐78216-‐604-‐7. Birmingham. Packt Publishing Ltd. Septiembre 2013.

[BadLg] Bad Logic Games. Framwork Libgdx. http://libgdx.badlogicgames.com. Consultado el 1 de Julio del 2014.

[MonoG] Monogame. Monogame Official page. http://www.monogame.net/ . Consultado el 1 de Julio del 2014.

[Uni3D] Unity 3D. Unity 3D Official page. https://unity3d.com/es . Consultado el 2 de Julio del 2014.

[FEZ] Monogame framwork. FEZ. http://www.monogame.net/showcase/. Consultado el 3 de Julio del 2014.

[Bast] Monogame framwork. Bastion. http://www.monogame.net/showcase/. Consultado el 3 de Julio del 2014.

[MigrJu] Unity 3D. Migraciones de juegos a Windows. http://unity3d.com/es/pages/windows . Consultado el 3 de Julio del 2014.

[DeusEx] Unity 3D Game. Deus Ex. https://unity3d.com/es/showcase/case-‐stories/nfusion-‐eidosmontreal-‐deusex-‐thefall. Consultado el 3 de Julio del 2014.

[War40] Unity 3D Game. Warhammer 40.000. http://spacewolf-‐game.com/ . Consultado el 4 de Julio del 2014.

[MegNo] Libgdx framwork. Meganoid: Grandpa’s Chronicles. http://badlogicgames.com/forum/viewtopic.php?f=16&t=9666 . Consultado el 4 de Julio del 2014.

[DerYT] Dermetfan. Perfil de un desarrollador de juegos Java/Libgdx en Youtube. http://www.youtube.com/user/dermetfan/featured. Consultada el 2 de Julio de 2014.

[Der01] Dermetfan. Java Tiled Map Game (LibGDX) | Episode 1 – creating Tiled Maps. http://www.youtube.com/watch?v=qik60F5I6J4. Consulta el 3 de Julio de 2014.

[Der02] Dermetfan. Java Tiled Map Game (LibGDX) | Episode 2 – rendering tile maps(ortogonal and isometric). http://www.youtube.com/watch?v=zckxJn751Gw .Consulta el 5 de Julio de 2014.

Bibliografía

68

[Der03] Dermetfan. Java Tiled Map Game (LibGDX) | Episode 3 – creating the Player and applying gravity. http://www.youtube.com/watch?v=NsxNE9uk1ew. Consulta el 8 de Julio de 2014.

[Der04] Dermetfan. Java Tiled Map Game (LibGDX) | Episode 4 – collision detection. http://www.youtube.com/watch?v=DOpqkaX9844. Consulta el 9 de Julio de 2014.

[Der05] Dermetfan. Java Tiled Map Game (LibGDX) | Episode 5 -‐ moving the player. http://www.youtube.com/watch?v=QokDomVnTZg. Consulta el 10 de Julio de 2014.

[Der06] Dermetfan. Java Tiled Map Game (LibGDX) | Episode 6 – animated tiles. http://www.youtube.com/watch?v=xubOtuq2cEo. Consulta el 11 de Julio de 2014.

[Oga09] Open Game Art. Free, legal art for open source and indie video games. http://opengameart.org. Consulta el 1 de Julio de 2014.

esarrollo*deun*videojuego rpg con*el*framework …dborrajo/pfc/tfm-francisco-lopez.pdf ·...

Documents

esarrollodeunvideojuego rpg conelframework …dborrajo/pfc/tfm-francisco-lopez.pdf ·...