desarrollo de un videojuego - ujaen.estauja.ujaen.es/bitstream/10953.1/8455/1/memoria.pdf ·...

Escu

ela

Polit

écn

ica S

up

eri

or

de J

aé

n

UNIVERSIDAD DE JAÉN

Escuela Politécnica Superior

Trabajo Fin de Grado

DESARROLLO DE UN

VIDEOJUEGO

Alumno: Oscar Ortiz Cuevas

Tutor: Prof. D. Juan Roberto Jiménez Pérez Dpto: Departamento de Informática

Septiembre, 2016

Oscar Ortiz Cuevas Desarrollo de un Videojuego

Escuela Politécnica Superior de Jaén 2

Tabla de contenido

1. INTRODUCCIÓN ......................................................................................... 6

1.1. Motivación ............................................................................................. 7

1.2. Objetivos ............................................................................................... 8

1.3. Contenidos de la memoria .................................................................... 9

2. TECNOLOGÍAS USADAS. STATE OF THE ART .................................... 10

2.1. Motor de videojuegos: Unity ................................................................ 10

2.2. Lenguaje de programación: C-Sharp (C#) .......................................... 12

2.3. Herramienta de planificación: Pivotal Tracker ..................................... 13

2.3.1. Pantalla principal .......................................................................... 14

2.3.2. Historias de usuario ...................................................................... 15

2.4. Herramienta de diseño: Visual Paradigm ............................................ 16

3. PLANIFICACIÓN ....................................................................................... 17

3.1. ¿Qué es Scrum? ................................................................................. 17

3.2. Roles en Scrum ................................................................................... 18

3.3. Fases de la metodología ..................................................................... 19

3.4. Adaptación de Scrum a este proyecto................................................. 20

3.5. Resumen de las iteraciones ................................................................ 20

3.6. Gráfico de iteraciones ......................................................................... 25

3.7. Prototipos ............................................................................................ 26

4. PRESUPUESTO ........................................................................................ 28

4.1. Recursos humanos ............................................................................. 28

4.2. Recursos materiales ............................................................................ 28

4.3. Presupuesto total ................................................................................ 29

5. ANÁLISIS INICIAL ..................................................................................... 30

5.1. Tipo de juego (High Concept Document / Game Treatment Document)

30

5.2. Resumen de la historia ........................................................................ 31

5.3. Características del personaje (Character Design Document) ............. 31

5.3.1. Estadísticas del personaje ............................................................ 31

5.3.2. Habilidades ................................................................................... 32



5.4. Equipo ................................................................................................. 33

5.4.1. Armas ........................................................................................... 33

5.4.2. Revestimiento para el arma .......................................................... 34

5.4.3. Armaduras .................................................................................... 34

5.4.4. Escudos ........................................................................................ 36

5.4.1. Emblemas ..................................................................................... 36

5.5. Objetos ................................................................................................ 38

5.5.1. Objetos consumibles .................................................................... 38

5.5.2. Objetos no consumibles (coleccionables o materiales) ................ 39

5.6. Escenarios (World Design Document) ................................................ 40

5.6.1. Aldea ............................................................................................ 40

5.6.2. Mapas ........................................................................................... 43

5.7. Misiones .............................................................................................. 44

5.7.1. Misiones de entrega de materiales ............................................... 44

5.7.2. Misiones de combate .................................................................... 44

5.8. Enemigos ............................................................................................ 45

5.9. Interfaz de usuario (User Interface Design Document) ....................... 47

5.9.1. Menú principal .............................................................................. 47

5.9.2. Interfaz durante una misión .......................................................... 48

5.9.3. Menú de pausa ............................................................................. 49

5.9.4. Pantalla de recompensa ............................................................... 50

5.9.5. Pantalla de carga .......................................................................... 50

5.9.6. Sistema de notificaciones ............................................................. 51

5.9.7. Efectos visuales ............................................................................ 51

5.9.8. Efectos sonoros ............................................................................ 52

5.10. Situaciones de juego (Flowboard) ....................................................... 53

5.11. Evolución del juego (Story and Level Progression Document) ............ 55

6. DISEÑO E IMPLEMENTACIÓN ................................................................ 56

6.1. Sistema de objetos .............................................................................. 57

6.1.1. Clase Item .................................................................................... 57

6.1.2. Clase ItemEffect ........................................................................... 58

6.1.3. Clase ItemDatabase ..................................................................... 59

6.2. Gestión del personaje ......................................................................... 60



6.2.1. Clase Player ................................................................................. 60

6.2.2. Clase IG_Player ............................................................................ 62

6.2.3. Controlador del personaje (PlayerController) ............................... 63

6.2.4. Personalización del personaje (CharacterCustomization) ............ 64

6.3. Sistema de habilidades ....................................................................... 65

6.4. Inventario y Mochila ............................................................................ 66

6.4.1. Clase Inventory ............................................................................. 66

6.4.2. Clase Bag ..................................................................................... 68

6.5. Equipamiento ...................................................................................... 69

6.5.1. Armas (Weapon) ........................................................................... 69

6.5.2. Revestimiento del arma (WeaponCoat) ........................................ 70

6.5.3. Armaduras (Armor) ....................................................................... 70

6.5.4. Escudos (Shield) ........................................................................... 71

6.5.5. Emblemas (Emblem) .................................................................... 71

6.6. Sistema de misiones ........................................................................... 72

6.6.1. Clases Quest (y subclases) y QuestCollection ............................. 72

6.6.2. Clase QuestLog ............................................................................ 74

6.6.3. Recompensa de misión (Reward) ................................................. 75

6.6.4. Controladores de misión ............................................................... 76

6.7. Enemigos ............................................................................................ 77

6.7.1. Enemy y EnemyCollection ............................................................ 78

6.7.2. EnemyInGame .............................................................................. 79

6.7.3. EnemyMovement .......................................................................... 80

6.7.4. EnemyReward .............................................................................. 81

6.8. Mercancía en la tienda y la forja (ShopAvailableStock y

ForgeAvailableStock) .................................................................................... 81

6.8.1. ShopAvailableStock ...................................................................... 81

6.8.2. ForgeAvailableStock ..................................................................... 83

6.9. Elementos de interfaz .......................................................................... 85

6.9.1. Menú principal .............................................................................. 85

6.9.2. Pantalla de carga .......................................................................... 86

6.9.3. Notificaciones ............................................................................... 87

6.9.4. Cuadros de diálogo ....................................................................... 88

6.10. Controlador de audio (SoundManager) ............................................... 89



6.11. Guardado y carga de datos ................................................................. 90

7. RECURSOS UTILIZADOS ........................................................................ 93

8. CONCLUSIONES ...................................................................................... 94

8.1. Conocimientos aplicados .................................................................... 94

8.2. Dificultades encontradas ..................................................................... 94

8.3. Resultados obtenidos .......................................................................... 95

9. TRABAJO FUTURO .................................................................................. 96

10. BIBLIOGRAFÍA ....................................................................................... 97

11. Anexo: Manual de usuario ...................................................................... 98

11.1. Menú principal ..................................................................................... 98

11.2. Pantalla de juego ................................................................................ 98

11.3. Controles ............................................................................................. 99

11.4. Consejos para la aventura .................................................................. 99



1. INTRODUCCIÓN

Durante estos últimos años, las tecnologías han experimentado un auge

tanto en su desarrollo como en su uso. Dentro de las Tecnologías de la

Información, una de las ramas que más han notado este cambio ha sido el

Desarrollo de Videojuegos.

La industria del videojuego ha evolucionado durante este tiempo, desde

que eran algo poco conocido en la sociedad, hasta ahora, que es una de las

principales formas de entretenimiento. Además cabe destacar el auge de las

competiciones profesionales de videojuegos, conocidas como E-Sports,

seguidas mundialmente por millones de personas.

Esta evolución en los videojuegos podemos apreciarla en muchos

aspectos: mejor calidad de imagen, pasando de una imagen en blanco y negro

a una en HD; o la interacción entre jugadores, siendo en los inicios inexistente,

mientras ahora pueden verse multitud de jugadores participando en la misma

partida a través de la red. En definitiva, ha pasado de ser un simple pasatiempo

a ser una forma de arte, al mismo nivel que la música o el cine.

Este progreso en la Industria del Videojuego se puede explicar desde

varios puntos de vista. Uno de ellos es sin duda el gran aumento en el uso de

los ordenadores e Internet, así como la espectacular evolución en la potencia

tanto hardware como software, permitiendo a todo el mundo consumir y

producir contenidos de todo tipo.

Otro aspecto fundamental en este tema es la gran cantidad de

información disponible, pudiendo encontrar contenido de cualquier cosa

imaginable, así como herramientas de diseño, modelado, programación o

edición de imagen y sonido, entre otros. Además, muchas de ellas son

gratuitas, lo que incita a su uso.



1.1. Motivación

Durante gran parte de mi vida he estado en contacto con el mundo de

los videojuegos, tanto jugándolos como siguiendo los medios especializados.

Por ello, estaba interesado en embarcarme en un proyecto relacionado con

este mundo.

El objetivo propuesto en este proyecto es la realización de un prototipo

de un videojuego, empezando desde cero, y tocando todas las partes del

desarrollo (programación, diseño de escenarios, inteligencia artificial,

animación, sonido, etc.).

A priori, la dificultad reside en reunir el trabajo de muchas de las

materias impartidas en el Grado de manera conjunta, es decir, aspectos como

la planificación, el diseño de clases, la implementación, la creación de modelos

y animaciones y más.

En la fase de planificación, he pensado usar la metodología Scrum, vista

en Desarrollo Ágil, ya que nos permite ir desarrollando nuestro producto, en

nuestro caso un juego, por iteraciones o etapas. Esto nos viene bien, ya que en

principio tenemos varias partes más o menos diferenciadas que podemos

desarrollar por separado, para posteriormente unirlas. En esta metodología

debemos priorizar y evaluar el coste de las tareas, y desarrollarlas en sprints de

corta duración.

En la fase de diseño e implementación he utilizado todo lo visto sobre

Programación Orientada a Objetos, como el uso de clases, herencia, uso de

patrones, polimorfismos, etc.

También he querido plasmar los conocimientos adquiridos en la

asignatura de Interacción Persona-Ordenador, para diseñar una interfaz de

usuario intuitiva y fácil de utilizar.

Para acabar, decir que he aplicado conocimientos aprendidos en Gestión de

Proyectos Software, Inteligencia Artificial, Desarrollo de Videojuegos,

Estructuras de Datos e Ingeniería de Requisitos, entre otras.



1.2. Objetivos

El objetivo de este trabajo es desarrollar un videojuego desde cero. Se

pretende construir un prototipo de juego de rol y acción en tercera persona,

intentando mezclar aspectos de ambos estilos. Por un lado cogemos

características de los juegos de rol (RPG), como un sistema de

creación/mejora/compra de objetos y equipamiento, un sistema de juego

basado en misiones o la evolución del personaje a lo largo del juego. Por otra

parte añadimos aspectos de los juegos de acción, como el sistema de lucha en

tiempo real.

La plataforma sería PC, en concreto para Windows, aunque una de las

ventajas que tiene Unity es la facilidad para portar nuestro videojuego a

múltiples plataformas, incluso móviles o consolas.

Para ello, habrá que realizar un diseño, para posteriormente pasar al

modelado y animación. Todo ello mediante el motor de juegos Unity,

ayudándonos de alguna herramienta para la planificación y diseño.

No obstante, antes de empezar tenemos el inconveniente de tener poca

experiencia en proyectos como el que nos disponemos a realizar, ya que hasta

ahora nos limitábamos a hacer prácticas en las que se nos pedían tareas más

concretas. En este caso, debemos tener en cuenta todos los aspectos de un

proyecto más profesional, como la planificación, el diseño o las pruebas, al

mismo tiempo.

Por ello, se requiere un periodo inicial de adaptación a este formato de

trabajo, afectando de cierta forma a la planificación, que se verá más adelante.

En resumen, este Trabajo Fin de Grado será mi primera experiencia en

cuanto a proyectos más complejos, más parecido a un proyecto profesional.



1.3. Contenidos de la memoria

Los contenidos expuestos en la memoria se dividen en apartados, según

el aspecto del desarrollo al que hacen referencia.

En el apartado 2 se exponen las tecnologías usadas, es decir, las

herramientas y técnicas utilizadas. Aquí entran tanto el motor de videojuegos

usado como el lenguaje de programación, y más.

En el apartado 3 se explica todo lo referente a la planificación, tanto de

la técnica usada como de la herramienta software elegida, así como un

resumen de las iteraciones y de los prototipos obtenidos.

El apartado 4 está dedicado al cálculo del presupuesto, tanto humano

como material.

El apartado 5 es muy importante, ya que en él se exponen todos los

elementos que forman parte del videojuego, desde el punto de vista del

análisis, definiendo la relación entre estas partes y el jugador.

En el apartado 6 se explica toda la parte de diseño e implementación de

lo obtenido en la etapa anterior, esto es, la estructura de clases y relaciones.

El apartado 7 está dedicado a exponer un listado con los recursos

utilizados, los cuales son de terceros.

El apartado 8 es donde se resumen mis impresiones al finalizar este

proyecto, así como una valoración de las dificultades encontradas durante el

desarrollo.

En el apartado 9 se definen las trazas para el desarrollo futuro del

proyecto, ya sean nuevas funcionalidades o mejoras de las ya existentes.

El apartado 10 está dedicado a la bibliografía, tanto de recursos escritos

como sitios web.

Por último, en el anexo viene incluido un manual de usuario, hecho

desde el punto de vista de los que se incluyen en los videojuegos comerciales.



2. TECNOLOGÍAS USADAS. STATE OF THE ART

Las tecnologías usadas en este proyecto son Unity como motor gráfico y

C-Sharp(C#) como lenguaje de programación. Para la parte de planificación

usaré la herramienta Pivotal Tracker, ya que se adapta bien a la metodología

Scrum. Por último, para la realización de diagramas de diseño optaré por Visual

Paradigm, utilizado a lo largo del Grado, siendo una de las herramientas más

potentes para este apartado.

2.1. Motor de videojuegos: Unity

A la hora de escoger un motor gráfico para nuestro proyecto, tenemos

varias alternativas interesantes, como el propio Unity, Unreal Engine,

CryEngine o Source2. [1]

- Unity (última versión Unity 5): Actualmente Unity es el motor gráfico más

usado, debido principalmente a que sus últimas versiones permiten

realizar productos compatibles con la mayoría de plataformas,

incluyendo consolas, móviles, versiones web y distintos sistemas

operativos.

Una de las claves del éxito de este motor gráfico es su modelo de

negocio. Existen dos versiones diferenciadas: la gratuita (versión

Personal), que ofrece gran variedad de opciones a la hora de desarrollar

productos; y la de pago (versión Profesional), que ofrece más

funcionalidades y facilidades para trabajar en proyectos multiplataforma.

Con la versión Personal podemos obtener beneficios con nuestros

primeros proyectos sin tener que pagar nada (hasta un límite de

100.000$ anuales, tras esto habría que adquirir la versión de pago), lo

que anima a pequeños desarrolladores a usarlo y obtener sus primeros

ingresos.

https://unity3d.com/es



- Unreal Engine (últ. versión Unreal Engine 4): Este motor desarrollado

por Epic Games destaca por su gran calidad gráfica, incluyendo

iluminación dinámica y sistemas de partículas más potentes que en

Unity.

Al igual que Unity, Unreal Engine 4 es totalmente gratuito en la

actualidad, aunque tendrás que pagar un 5% en royalties si ganas más

de 3.000$ por trimestre y juego. También tiene en común con el anterior

la relativa facilidad para los nuevos desarrolladores.

- CryEngine: CryEngine es un motor gráfico extremadamente potente,

desarrollado por Crytek. El motor está diseñado para usarse en juegos

de PC y consolas, incluyendo PlayStation 4 y Xbox One. Las

capacidades y potencia de este motor sobrepasan de largo a motores

como Unity, tan solo Unreal Engine 4 puede competir en aspectos como

las físicas, los sistemas de animación de modelos y la capacidad de

iluminar en tiempo real las escenas. Sin embargo, a diferencia de los

anteriores, este motor no es gratuito, aunque tiene un precio asumible

de 9.90$ al mes.

Uno de los inconvenientes de CryEngine es su gran curva de

aprendizaje, por lo que quizá sea mejor escoger Unity o Unreal Engine si

no tenemos entre manos un proyecto de gran calibre.

Source2: Este motor ha sido usado en varios títulos de la empresa

Valve, siendo de los más jugados en la plataforma Steam.

Al final, decidí escoger Unity como plataforma para mi Trabajo por varias

razones: es gratuito, existe gran cantidad de información (manuales web,

tutoriales, ejemplos, etc.), la interfaz me resultó muy cómoda desde el primer

momento, y el hecho de haberlo utilizado antes en alguna asignatura del

Grado.

https://www.unrealengine.com/

https://www.cryengine.com/

http://www.valvesoftware.com/news/?id=16000



2.2. Lenguaje de programación: C-Sharp (C#)

A pesar de que Unity tiene una estructura muy visual, es necesario el

uso de scripts, y para ello tenemos tres opciones a la hora de escoger un

lenguaje de programación [2]:

JavaScript: Anteriormente conocido como UnityScript, es un lenguaje

soportado por la mayoría de sistemas, y perfecto en el desarrollo web.

C-Sharp o C#: Lenguaje orientado a objetos bajo la firma de Microsoft,

forma parte de la plataforma .NET.

Boo: Lenguaje inspirado en la sintaxis de Python. Es la opción menos

usada de entre estas tres.

A la hora de escoger el lenguaje adecuado para mí, he escogido C# por

varias razones: es similar a C++, lenguaje orientado a objetos que hemos

utilizado durante todo el Grado, no teniendo que empezar a aprender la sintaxis

desde cero. Además, es el lenguaje más utilizado por los usuarios de Unity, y

por lo tanto la mayoría de información disponible usa C#.

Por otro lado, he dejado de lado JavaScript por varios motivos: la

sintaxis no me pareció tan sencilla como la de C#, debido seguramente a que

no lo he usado tanto. Por otro lado, la mayoría de información existente no

utiliza este lenguaje, incluso la proporcionada por Unity, por lo que se me haría

difícil convertir todo lo consultado a JavaScript.

Por último, Boo fue descartado de inmediato, ya que usa sintaxis de

Python, lenguaje que nunca he usado. También influye que Boo sea el lenguaje

menos usado y el menos recomendado a la hora de empezar a trabajar con

Unity.



2.3. Herramienta de planificación: Pivotal Tracker

Como he indicado anteriormente, he decidido utilizar un desarrollo

siguiendo la metodología Scrum (Ver apdo. 3). Las características de esta

metodología se resumen en la división del proyecto en iteraciones o sprints,

cada una con sus tareas correspondientes. Otros aspectos de esta

metodología son la estimación de coste (se mide tiempo o recursos) y la

prioridad (en puntos, siguiendo un baremo concreto), decidiéndose antes de

empezar la iteración y sin poder variarse una vez empecemos el sprint. Se

detallará más esta metodología en el apartado dedicado a la planificación.

Sabiendo esto, podemos elegir entre dos opciones a la hora de planificar

las tareas. O bien hacerlo a mano, calculando costes, tiempo y progreso de las

iteraciones manualmente; o bien utilizar una de las muchas herramientas

software disponibles para nuestro propósito. Me decanté por lo segundo, ya

que en la asignatura de Desarrollo Ágil pudimos ver todas las ventajas de estas

herramientas, en concreto las que encontramos en la web. Algunos ejemplos

son Kunagi, ScrumDo, IceScrum, Pango Scrum o la que usaremos en nuestro

caso, Pivotal Tracker.

Pivotal Tracker [4] es una herramienta de planificación web gratuita,

centrada en el uso de la pila de producto y medidas como la velocidad. Además

tenemos a nuestra disposición un historial, donde se reflejan todos los cambios

que hagamos en el proyecto, en caso de que queramos revertir una

modificación o simplemente controlar los cambios.

Esta herramienta también ofrece funciones muy interesantes para

proyectos en grupo, como el uso de perfiles, que controlan los privilegios de

cada miembro del grupo a la hora de crear, consultar o modificar tareas. En

nuestro caso no las necesitamos, pero nunca viene mal saber estas ventajas si

en el futuro trabajamos con más personas.

http://www.pivotaltracker.com/



2.3.1. Pantalla principal

Una vez entramos en la web (www.pivotaltracker.com) y creamos un

proyecto nuevo, nos aparecerá la pantalla principal.

Como vemos, nos aparecen las pestañas Current, Backlog y Icebox.

Current: Aquí aparecerán las tareas que forman la iteración actual.

Backlog: En esta pestaña tendremos todas las tareas de las siguientes

iteraciones, a las que ya les hemos asignado su coste.

Icebox: Aquí tenemos las tareas que todavía no hemos acabado de

estimar, y que por lo tanto no entran aún en la planificación.

Aparte de estas, tenemos la pestaña Done, en la que tenemos las tareas

acabadas.

Ilustración 1: Pantalla principal de Pivotal Tracker

www.pivotaltracker.com



2.3.2. Historias de usuario

Al crear una historia de usuario tendremos algo como esto.

La primera opción que vemos es el

Story Type, donde podemos elegir entre

Feature (requisito), Bug (arreglo de fallos),

Chore (aspectos externos al proyecto, pero

necesarios en el trascurso de éste) y

Release (hitos o entregas).

Después tenemos la opción Points,

donde asignamos el coste, siguiendo un

baremo, ya sea lineal (1,2,3…), de

Fibonacci (1,2,5,8…) o una personalizada.

La última opción a destacar es el

apartado Tasks, que son las tareas más

específicas dentro de la historia de usuario.

Una vez que la hemos terminado

pulsamos Save para guardarla en el apartado Icebox. Posteriormente, cuando

la tengamos en Backlog o Current, podremos cambiar su estado: Unstarted,

Started, Finished, Delivered, Rejected o Accepted.

Ilustración 2: Apartado de Historias de Usuario



2.4. Herramienta de diseño: Visual Paradigm

(https://www.visual-paradigm.com/)

Esta herramienta es de las más potentes a la hora de realizar diagramas

de diseño, teniendo una gran variedad de tipos de diagramas disponibles (de

clases, de flujo, de actividad, de comunicación, etc.).

En mi caso, lo he utilizado para hacer los diagramas de clases de todo

mi sistema, como veremos más adelante.

En cuanto a la interfaz de la herramienta, tenemos multitud de opciones,

quedándonos en este caso con la parte de diagramas.

Arriba vemos las pestañas, entre ellas ‘Project’ y ‘Diagram’, donde

podemos crear un proyecto nuevo y añadir diagramas nuevos,

respectivamente. En la parte izquierda vemos los iconos para añadir elementos

al diagrama de clases, como clases o relaciones.

Ilustración 3: Interfaz de Visual Paradigm

https://www.visual-paradigm.com/



3. PLANIFICACIÓN

Como ya se ha dicho anteriormente, para este proyecto se utilizará la

metodología de desarrollo ágil Scrum. Está técnica se ajusta perfectamente a

nuestro caso, y en general a cualquier desarrollo en el que tengamos una fecha

límite de entrega y una lista de requisitos más o menos improvisada. También

es muy adecuada para el trabajo en equipo, puesto que continuamente

tenemos reuniones de grupo, en las que se reparten tareas y se hace un

seguimiento del trabajo hecho y por hacer.

3.1. ¿Qué es Scrum?

La metodología Scrum [3] sigue unas pautas para el trabajo en equipo,

de manera que sea lo más eficiente posible.

En Scrum se realizan entregas parciales con cierta regularidad,

priorizando las funcionalidades incluidas según lo estipulado con el cliente. Por

esto, es recomendable usar Scrum en entornos de trabajo complejos, donde

tenemos que obtener resultados pronto, los requisitos cambian a menudo o no

están del todo claros, o en el caso de que la innovación o la improvisación sean

fundamentales.



3.2. Roles en Scrum

Dentro del equipo de trabajo de Scrum hay varios roles esenciales para

el buen funcionamiento del proyecto:

Cliente (o Product Owner): Representa a la persona o personas

interesadas en los resultados del proyecto, y actúa como interlocutor

ante el equipo, teniendo autoridad para tomar decisiones.

Define los objetivos del proyecto y dirige la lista de requisitos,

sabiendo el valor que aporta cada uno, repartiéndolos en iteraciones y

programando las entregas. En caso de ser necesario, replanifica el

proyecto en función de los requisitos que se hagan más necesarios.

Facilitador (o Scrum Master): Se encarga de liderar al equipo, de manera

que se sigan en todo momento las reglas de Scrum, y guiando la

colaboración entre los grupos de trabajo. También organiza las

reuniones de Scrum (planificación de la iteración, reuniones diarias, de

demostración y de retrospectiva).

Elimina los posibles impedimentos que pueda haber en el equipo,

ya sean externos o internos. Esto ayuda a la mayor productividad de

cada uno de los miembros.

Equipo (o Team): Grupo de personas que desarrollan el proyecto de

forma conjunta. El tamaño del equipo está entre 5 y 9 personas, ya que

con menos habría problemas en caso de que algún miembro faltase, y

con más habría problemas de comunicación y organización. En este

último caso la mejor solución es hacer subgrupos.

Se recomienda que los miembros de un mismo equipo trabajen

juntos físicamente, para mejorar la comunicación. También es

aconsejable que el equipo sea estable a lo largo del proyecto, para

aprovechar la relación adquirida entre los miembros.



3.3. Fases de la metodología

En Scrum un proyecto se divide en bloques de tiempo cortos y fijos,

llamados iteraciones, de entre dos semanas y un mes. En cada iteración

debemos obtener un resultado completo, es decir, algo que el cliente pueda ver

o probar, y comprobar que se están cumpliendo sus requerimientos.

Al principio partimos de una lista de requisitos ordenada por prioridad,

también llamada Product Backlog. Esta priorización viene dada por el cliente,

que debe tener en cuenta el valor que aporta al proyecto y su coste. Una vez

tengamos la lista, se repartirán en iteraciones y entregas.

Las actividades que se realizan en Scrum son:

Planificación de la iteración: El primer día de la iteración se convoca una

reunión para seleccionar los requisitos que el cliente quiere incluir en

esta iteración, de manera que el equipo de trabajo pueda preguntar

dudas o ajustar alguna tarea en el tiempo.

Después, el equipo estima el esfuerzo necesario de cada requisito

y se reparten las tareas.

Ejecución de la iteración: Cada día el equipo realiza una breve reunión

de sincronización, donde se ve el trabajo que cada miembro del equipo

va realizando. Cada uno expone el trabajo realizado desde la anterior

reunión, lo que va a hacer a partir de ahora y si tiene algún problema

con el trabajo que tiene asignado.

Durante la iteración, el Scrum Master se encarga de que el equipo

pueda cumplir los objetivos, resolviendo problemas externos que puedan

surgir.

Inspección y adaptación: El último día de la iteración se realiza una

reunión de revisión de la misma. En ella, el equipo muestra al cliente los

requisitos completados en la iteración. En función de los resultados

mostrados y de los posibles cambios que haya habido en el contexto del

proyecto, el cliente deberá adaptar la planificación de lo que quede de

proyecto, si es necesario.



También se lleva a cabo una reunión de retrospectiva, en la que el

equipo analiza todo lo ocurrido a lo largo de la iteración, problemas

encontrados y posibles mejoras para el futuro.

3.4. Adaptación de Scrum a este proyecto

Al aplicar esta metodología a nuestro caso, hay algunos aspectos que no

podemos utilizar. Por ejemplo, en el caso de las reuniones, al ser un trabajo

individual no tiene sentido.

Aun así, podemos seguir las demás funcionalidades de Scrum, la pila de

producto, las historias de usuario, el uso de iteraciones, etc.

3.5. Resumen de las iteraciones

1. Planteamiento inicial (2 semanas, desde el 1 de febrero hasta el 14 de

febrero): En esta iteración se definieron los aspectos iniciales del proyecto,

como es el caso de la metodología de planificación, el motor de videojuegos

a utilizar, el lenguaje de programación y las demás herramientas.

Por supuesto también se decidió el tipo de juego que se iba a

realizar, no tanto en temas artísticos, sino en cuanto a la estructura de éste,

con las posibles entidades que habría que incluir.

2. Estructura del videojuego (2 semanas, desde el 15 de febrero hasta el

28 de febrero): Aquí se generaron las primeras historias de usuario, dando

forma a las ideas adquiridas en la anterior iteración. Se decidió hacer un

sistema de misiones, con sus diferentes tipos, así como ofrecer

recompensas en forma de objetos.

Además, se ofrecería al jugador un sistema de compra de objetos y

de forja de armas y equipo usando los objetos conseguidos.



3. Diseño e implementación del sistema de objetos (2 semanas, desde el

29 de febrero hasta el 13 de marzo): Aquí se incluyen las clases de los

apartados 6.1 (objetos) y 6.4 (inventario y mochila).

4. Diseño e implementación del personaje y las habilidades (2 semanas,

desde el 14 de marzo hasta el 27 de marzo): En esta iteración se crearon

las clases para la gestión de las estadísticas del personaje (6.2) y el sistema

de habilidades (6.3). Cabe decir que en esta fase aún no se incluyó la parte

de control ni personalización del personaje, ya que eso viene en iteraciones

posteriores.

5. Diseño e implementación del equipo (1 semana, desde el 28 de marzo

hasta 3 de abril): En esta fase se decidió qué tipos de equipo distintos

habría, así como los atributos que debía tener cada uno. Estas clases están

en el apartado 6.5.

6. Diseño e implementación del sistema de misiones (2 semanas, desde

el 4 de abril hasta 17 de abril): A estas alturas ya tenía claro qué tipo de

misiones habría en el juego, de recolección de objetos o de combate contra

enemigos. De todas formas, se ha intentado desarrollar un sistema que

permita incluir otros tipos de misiones de forma sencilla, con vistas al futuro.

Todas las clases incluidas en este conjunto están en el apartado 6.6.

7. Diseño e implementación de la parte lógica de los enemigos (2

semanas, desde el 18 de abril hasta 1 de mayo): En esta iteración se

desarrollaron parte de las clases incluidas en el apartado 6.7, donde se

definen los atributos de los enemigos, así como la colección donde se

guardan los distintos tipos que hay en el juego.



8. Comienzo de la realización de la memoria (1 semana, desde el 2 de

mayo hasta el 8 de mayo): En este caso dejamos un poco de lado el

desarrollo práctico para centrarnos en la documentación, empezando por

incluir toda la información útil acerca de Unity y las demás herramientas, así

como los diagramas de clases de lo desarrollado hasta el momento,

explicando los atributos y métodos.

9. Desarrollo del sistema de guardado y carga de datos (1 semana, desde

el 9 de mayo hasta el 15 de mayo): Durante esta etapa investigué sobre

cuál era la mejor forma de guardar y cargar los datos del juego, escogiendo

finalmente la serialización. Tras esto, había que definir qué clases utilizarían

este sistema. Esto viene explicado en el apartado 6.11.

10. Comienzo de la etapa de desarrollo de interfaces (4 semanas, desde el

16 de mayo hasta el 12 de junio): A partir de esta iteración cambiamos un

poco la metodología de desarrollo, ya que anteriormente trabajábamos con

código, pasando ahora a diseñar sobre el editor de Unity. Durante esta

etapa se realizó una interfaz básica para el menú principal, la interfaz

durante una misión (indicador de salud, potenciadores de ataque y defensa,

etc.), el menú de pausa, y el acceso rápido a objetos. Posteriormente

también se hizo la interfaz para la casa del jugador, incluyendo los menús

de mochila e inventario, entre otros, así como la interfaz para la tienda y la

forja, teniendo muchos aspectos en común.

Al acabar esta iteración se generó el primer prototipo jugable,

explicado en la siguiente sección.



11. Diseño del personaje controlable (3 semanas, desde el 13 de junio

hasta el 3 de julio): Durante esta iteración traté de obtener un personaje

con diferentes movimientos, y que se manejara de manera sencilla. Para

ello empecé por buscar un modelo adecuado al tipo de juego, así como

animaciones que pudiera aplicarle.

Una vez que tenía ambas cosas, lo siguiente era generar una

máquina de estados para coordinar el control con el movimiento del

personaje, así como la parte de personalización. Todo esto viene detallado

en el apartado 6.2.

12. Diseño de los enemigos (2 semanas, desde el 4 de julio hasta 17 de

julio): Al igual que con el personaje, había que incluir modelos y

animaciones para los enemigos, obtenidos de varios sitios. Tras esto había

que definir un comportamiento de inteligencia artificial, que hiciera al

enemigo acercarse a nosotros y atacar. En el apartado 6.7 se explica con

más detalle.

13. Diseño de escenarios para misiones (2 semanas, desde el 18 de julio

hasta el 31 de julio): Una vez que tenemos todos los elementos

interactuables necesarios, nos faltan los escenarios en los que transcurrirán

las misiones. Para su creación usamos las herramientas de modelado de

terrenos de Unity, que nos permite dar relieve y aplicar texturas a la escena.

Además, he incluido elementos como rocas, árboles y agua, a los

que he añadido funcionalidades para obtener objetos de ellos. Más detalles

en el apartado 5.6.

14. Diseño del escenario de la aldea (1 semana, desde el 1 de agosto hasta

el 7 de agosto): Para esta escena se han necesitado modelos de edificios y

otros elementos, como barriles, cajas o vallados. Además se han incluido

funcionalidades para poder cambiar de escena al entrar en los distintos

establecimientos, así como personajes no controlables (NPC) con sus

respectivos diálogos.



15. Selección de elementos sonoros y gráficos (1 semana, desde el 8 de

agosto hasta el 14 de agosto): Esta fase es la última en cuanto al

desarrollo del videojuego. En ella se escogieron los recursos sonoros

(música de fondo y efectos de sonido) y gráficos (fondos para los menús,

iconos y diseños de botones).

16. Fase de pruebas (1 semana, desde el 15 de agosto hasta el 21 de

agosto): Durante esta etapa estuve probando el juego para comprobar su

rendimiento en un uso normal, así como intentar buscarle fallos que pudiera

arreglar.

17. Finalización de la memoria (2 semanas, desde el 22 de agosto hasta el

31 de agosto): Por último, solo quedaba terminar la parte de

documentación, incluyendo las valoraciones finales acerca del resultado

final del desarrollo, así como los objetivos a completar como trabajo futuro,

de cara a una futura comercialización del producto.



3.6. Gráfico de iteraciones

Ilustración 4: Gráfico resumen de las iteraciones



3.7. Prototipos

Primer prototipo: Pequeña escena donde probamos a recolectar objetos,

usarlos o consultar el estado de la mochila. Obtenido tras la iteración 10.

Segundo prototipo: Una vez que tenemos la escena de la aldea,

probamos a elegir una misión y completarla correctamente. Obtenido

tras la iteración 11

Ilustración 5: Imágenes del primer prototipo

Ilustración 6: Imágenes del segundo prototipo



Tercer prototipo (primera versión jugable): Tenemos casi todas las

escenas funcionales: menú principal, aldea, tienda, forja, casa del

jugador, puesto de misiones y un par de escenas para el transcurrir de

las misiones. Además tenemos un personaje personalizable con equipo

que conseguimos en el juego, y algunos enemigos con los que podemos

interaccionar. Obtenido tras la iteración 13.

Cuarto y último prototipo: Ya tenemos todas las escenas, con sus menús

al completo. Ya podemos desarrollar una partida normal, desde el menú

principal hasta la última misión disponible.

Ilustración 7: Imágenes del tercer prototipo

Ilustración 8: Imágenes del cuarto prototipo



4. PRESUPUESTO

4.1. Recursos humanos

Para la estimación de costes en cuanto a trabajo personal, he supuesto

una jornada de 8 horas diarias y 6 días por semana, obteniendo estos datos:

Tarea Horas

dedicadas

Precio por

hora Coste

Planificación y diseño

inicial 96 5 € 480 €

Diseño 120 8 € 960 €

Implementación 264 8 € 2112 €

Modelado 72 8 € 576 €

Animación 48 8 € 384 €

Audio y gráficos 72 5 € 360 €

Pruebas 48 4 € 192 €

Documentación 96 4 € 384 €

816 5448 €

Tabla 1: Estimación de costes en recursos humanos

4.2. Recursos materiales

En cuanto a recursos software, he apostado por usar herramientas

gratuitas en la medida de lo posible, empezando por el propio motor de

videojuegos, Unity 5.

Además también se ha utilizado Visual Paradigm para la elaboración de

diagramas, por medio de una licencia Student ofrecida por la Universidad de

Jaén, gracias a la cual he podido usar esta herramienta de forma gratuita.

También he usado Microsoft Word 2010 para la elaboración de esta

memoria, así como diversas herramientas web, como Pivotal Tracker, todas

ellas gratuitas.



Por el lado del hardware, se ha usado un PC portátil ASUS K52JU, con

procesador Intel Core i3 y sistema operativo Windows 7 Home Premium de 64

bits valorado en unos 550 €. Teniendo en cuenta la vida útil del equipo y el

tiempo que dura el proyecto, he supuesto una amortización de 110 €.

También se ha utilizado un Joystick inalámbrico NetWay NW498 cuyo

precio aproximado es de 25 €.

En total, serían unos 135 €.

4.3. Presupuesto total

En total, el coste del proyecto sería el siguiente:

Recursos humanos 5448 €

Recursos materiales 135 €

5583 €

Tabla 2: Estimación de costes totales



5. ANÁLISIS INICIAL

En el análisis inicial se recogen todos los aspectos planteados antes de

empezar el diseño, relacionados a la jugabilidad, los escenarios donde

transcurre el juego, el personaje, los objetos, etc.

5.1. Tipo de juego (High Concept Document / Game

Treatment Document)

Este juego pretende mezclar dos estilos diferentes. Por un lado, se

pretende tener características del género rol o RPG, teniendo un personaje que

evoluciona a lo largo del tiempo. Por otra parte, se quiere tener un juego de

acción en tercera persona, con momentos de lucha contra distintos enemigos,

que nos permitan superar misiones y lograr objetivos.

Durante el transcurso del juego tendremos que ir superando misiones

que se nos entregaran en una especie de poblado o aldea base, y que nos

permitirán acceder a otras misiones cada vez más complejas. A su vez

deberemos conseguir diferentes materiales con los que crear y mejorar nuestro

equipo, incluyendo armas, armaduras y otras piezas. Estos materiales se

pueden obtener de diferentes formas, ya sea acabando con enemigos,

recolectando en los escenarios o como recompensa de misiones, o

comprándolos en las diferentes tiendas.



5.2. Resumen de la historia

Llegamos a una aldea perdida en medio de la nada para ayudar a sus

habitantes a combatir a una serie de enemigos que han aparecido cerca de allí.

Ellos nos ayudarán en todo lo posible con esta dura tarea, ya que nos

proporcionarán objetos, armas y demás equipamiento.

Pero para que puedan darnos estos recursos nos hará falta dinero y

materiales, los cuales debemos conseguir en los escenarios, a los que

llegaremos a través de las misiones que deberemos aceptar en la aldea. De

esta manera podremos llegar a distintas zonas y enfrentarnos a multitud de

enemigos.

5.3. Características del personaje (Character Design

Document)

Tenemos un personaje controlable con una cámara en tercera persona.

Este personaje tiene una serie de estadísticas (stats) que definen su potencial,

tales como Puntos de Salud, Ataque o Defensa, y una serie de habilidades que

se consiguen mediante el uso de determinados equipamientos, como un

aumento de ataque permanente, mayor cantidad de Puntos de Salud o

mayores recompensas al acabar las misiones.

5.3.1. Estadísticas del personaje

PS (Puntos de salud): Es la salud máxima del personaje.

Ataque: Es el valor de ataque de nuestro arma.

Defensa: Es la suma del valor de defensa de la armadura y el escudo.

Ataque elemental: Es el valor de ataque elemental del arma.



5.3.2. Habilidades

Las habilidades son un aspecto muy a tener en cuenta a la hora de

escoger un equipamiento u otro. Una armadura puede llevar asociada unos

puntos de habilidad, que sumándose a los de las demás partes, nos puede

permitir activar una o varias habilidades, y así tener ventaja en ciertos

momentos, permitiéndonos aguantar mejor los golpes, atacar con más potencia

o recibir mejores recompensas al cumplir las misiones, entre otros usos.

En esta lista tenemos las diferentes habilidades que podremos usar en el

juego:

Nombre Puntos

necesarios Efecto

Ataque +

10 Ataque x 1.1

15 Ataque x 1.25

20 Ataque x 1.5

Defensa +

10 Defensa x 1.1

15 Defensa x 1.25

20 Defensa x 1.5

Más PS

10 PS x 1.25

15 PS x 1.5

20 PS x 2

Más ítems*

10 Núm. Ítems x 1.25

15 Núm. Ítems x 1.5

20 Núm. Ítems x 2

Más dinero**

10 Dinero x 1.5

15 Dinero x 2

20 Dinero x 3

Ataque Elemental + 10 Ataque elemental x 1.25

15 Ataque elemental x 1.5

Tabla 3: Lista de habilidades

* Items recibidos al completar una misión

** Dinero recibido al completar una misión

Los valores que se aplican en las habilidades, así como en todas las instancias

del juego, han sido obtenidos tras multitud de pruebas, haciendo hincapié en el

equilibrio, de forma que no se nos haga demasiado difícil o fácil en según qué

casos.



5.4. Equipo

El equipo lo podremos conseguir de diferentes maneras, ya sea

comprándolo en tiendas o creándolo a partir de materiales que hayamos

conseguido.

Podemos cambiar el equipo en la casa del personaje, así como ver

información detallada de las estadísticas y los puntos de habilidad.

5.4.1. Armas

Con respecto a las armas, debemos saber que son las que definen

nuestro stat de ataque. Cada arma tiene un cierto valor de ataque base,

pudiendo complementarse con un cierto valor de ataque elemental mediante un

revestimiento (ver apdo. 5.4.2), como Fuego, Agua o Veneno, afectando en

mayor o menor medida a según qué enemigos.

Estas son las armas disponibles en este prototipo:

Icono Nombre Ataque Icono Nombre Ataque

Espada de hierro 150

Espada metalizada

500

Espada oxidada 75

Espada maligna 600

Espada de madera

180

Espada de oro 1000

Espada de ébano 275

Espada divina 2500

Espada petrificada

350

Tabla 4: Lista de armas presentes en el juego



5.4.2. Revestimiento para el arma

El revestimiento es un bonus que nos permite mejorar aún más el ataque

de nuestra arma, permitiendo darle un poder elemental. Tenemos los

siguientes tipos: fuego, agua, hielo, rayo, veneno, luz y sombra.

Este extra puede llegar a ser muy importante en los combates, ya que a

cada enemigo le afectan de manera diferente los distintos tipos, y debemos

usarlo a nuestro favor. Por ejemplo, hay enemigos que son débiles al fuego,

pero resistentes al agua, por lo que sería conveniente llevar un revestimiento

de tipo fuego para derrotar a este tipo de enemigo con menor dificultad.

5.4.3. Armaduras

Por parte de las armaduras, éstas definen parte del stat de defensa de

nuestro personaje. Poseen un valor de defensa base y una serie de valores

que indican el daño que recibimos de cada tipo de ataque. También pueden

tener asociadas unos puntos de habilidad, que sumados a los que pueden

tener el escudo y el emblema equipados, nos permiten activar habilidades. Esto

nos obliga a estudiar qué armadura es mejor para luchar contra cierto enemigo,

y disponer de equipo variado a lo largo de la aventura.

En la siguiente tabla tenemos todas las armaduras disponibles en el

prototipo, junto a sus datos:

Ilustración 9: Tipos de revestimiento



Icono Nombre Defensa Puntos de habilidad

Daño elemental

Coraza de hierro

100 -

x 1

x 1

x 1

x 1

x 1

x 1

x 1

x 1

Ropas naturales

250 Ataque +: 10

x 1

x 0.5

x 1.5

x 1

x 1.5

x 1

x 0.5

x 0.2

Armadura iridiscente

300 Ataque

elemental +: 7

x 1

x 1.2

x 0.7

x 1

x 1.5

x 0.6

x 1.5

x 0.5

Armadura de Serie-MG

300 Defensa +: 12

x 0.7

x 0.5

x 1.5

x 0.1

x 1

x 1

x 1

x 1

Armadura oscura

350 Ataque +: 12

x 1

x 1.3

x 1.2

x 1

x 0.8

x 1.8

x 0.5

x 0.2

Blindaje escarlata

500 Más ítems: 10 Más dinero: 9

x 1

x 1.3

x 0.5

x 1

x 0.5

x 1

x 1.2

x 1.2

Armadura dorada

1200 Más PS: 9

Más dinero: 11

x 1

x 0.5

x 1.5

x 0.3

x 1.5

x 1

x 0.8

x 1

Armadura divina

1600 Ataque +: 14

Defensa +: 14

x 1

x 1

x 1

x 1

x 1

x 1

x 1

x 1

Tabla 5: Lista de armaduras presentes en el juego



5.4.4. Escudos

En cuanto a los escudos, cumplen una función similar a la armadura,

puesto que también tienen un valor de defensa y unos indicadores de daño

según el tipo de daño elemental que recibamos. Además, pueden llevar puntos

de habilidad.

En la siguiente página tenemos una lista con los escudos disponibles en

esta versión del juego.

5.4.1. Emblemas

Los emblemas cumplen una función muy específica dentro de nuestro

equipamiento, ya que solo nos servirán para sumar puntos de habilidad a los

que nos aportan la armadura y el escudo.

A priori puede parecer poca cosa, pero pueden ser muy importantes a la

hora de conseguir una habilidad útil para cierta misión, ya que los emblemas

sumarán puntos en habilidades difíciles de conseguir, de manera que nos

vendrá bien tener unos cuantos en nuestro inventario.



Imagen Nombre Defensa Puntos de habilidad

Daño elemental

Escudo precario 50 -

x 1

x 1

x 1

x 1

x 1

x 1

x 1

x 1

Escudo resistente 110 -

x 1

x 0.7

x 1.2

x 1

x 1.2

x 1.1

x 1

x 0.8

Escudo sellado 300 Ataque +: 7

Ataque elemental +: 9

x 1.2

x 1

x 0.5

x 0.5

x 1.8

x 1.8

x 1

x 0.1

Escudo maldito 1200

Ataque +: 1 Defensa +: 5


x 1.2

x 0.8

x 1.1

x 1.1

x 0.7

x 1.5

x 0.6

x 0.4

Escudo modular 500 Defensa +:5 Más PS: 10

Más ítems: 3

x 1

x 1.3

x 1.4

x 0.3

x 1.2

x 0.6

x 0.8

x 1

Escudo antiguo 800 Más ítems: 13

x 1

x 0.8

x 1.7

x 1.5

x 1.3

x 1

x 1

x 0.6

Escudo de oro cromado

1400 Más ítems: 12 Más dinero: 15

x 1

x 0.8

x 1.2

x 1.5

x 1

x 1

x 1

x 0.6

Escudo radiante 1000 Defensa +: 11


x 1

x 0.4

x 0.7

x 1

x 1.1

x 0.1

x 1.3

x 0.4

Tabla 6: Lista de escudos presentes en el juego



5.5. Objetos

Los objetos son una parte muy importante en el transcurso del juego,

tanto los objetos consumibles (pociones, potenciadores, etc.) como los no

consumibles (materiales y objetos clave o coleccionables). Estos objetos se

almacenan en nuestro inventario, al que tenemos acceso siempre que estemos

en la aldea. También tenemos la mochila, que nos permite llevar un número

limitado de objetos a las misiones, pudiendo transferirlos libremente entre el

inventario y ésta.

5.5.1. Objetos consumibles

Estos objetos generalmente afectan al estado del personaje, ya sea

curándonos, aumentando defensa o ataque, u otros usos. Tendremos a nuestra

disposición un menú de acceso rápido que nos permita usarlos fácilmente en

un momento de apuro.

La mayoría de estos consumibles se pueden comprar en las tiendas o

recolectar masivamente en los distintos mapas del juego.

Icono Nombre Efecto

Poción Recuperas 25 puntos de salud.

Poción + Recuperas 50 puntos de salud.

Poción máxima Recuperas todos tus puntos de salud.

Proteínas Aumenta tu ataque x 1.25 durante 1 minuto.

Proteínas + Aumenta tu ataque x 1.5 durante 4 minutos.

Vitaminas Aumenta tu defensa x 1.25 durante 1 minuto.

Vitaminas + Aumenta tu defensa x 1.5 durante 4 minutos.

Agua templada Restaura 10 puntos de salud.

Agua fresca Restaura 30 puntos de salud.

Tabla 7: Lista de objetos consumibles



5.5.2. Objetos no consumibles (coleccionables o materiales)

Los materiales son la base en la creación y mejora de nuestro

equipamiento, ya que necesitaremos unos ítems determinados cada vez que

queramos conseguir equipo mejor. A diferencia de los objetos consumibles, los

materiales son más difíciles de conseguir, ya que se obtienen de los enemigos

que derrotamos o como recompensa de las misiones superadas. No obstante,

también podemos encontrar algunos más comunes recolectando en los

escenarios o comprarlos en tiendas.

Esta dificultad a la hora de conseguir ciertos materiales hace que

debamos repetir misiones que ya hayamos superado anteriormente, si

deseamos conseguir un determinado material que se obtiene de un enemigo

concreto.

Este sistema nos ayuda a controlar la línea de dificultad del juego, ya

que a medida que vamos superando misiones más difíciles, los materiales

obtenidos son más raros, pero a su vez nos permiten mejorar el equipo.

Icono Nombre Icono Nombre

Hierro

Madera

Grafito

Madera seca

Carbón

Madera oscura

Bronce

Pez plateado

Moneda de oro

Gran pez dorado

Tabla 8: Lista de materiales (sin contar los que sueltan los enemigos)



5.6. Escenarios (World Design Document)

Dentro del juego podemos distinguir dos tipos de escenarios, la aldea y

los mapas donde se desarrollan las misiones.

5.6.1. Aldea

En la aldea tenemos varias localizaciones importantes, como nuestra

casa, con un baúl donde almacenamos objetos y equipo. Aquí podemos

cambiar el arma equipada, la armadura y el resto del equipo, así como

intercambiar objetos entre el inventario y la mochila.

También tenemos el puesto de misiones, donde aceptamos encargos

que nos asignan en la aldea; la tienda, donde compramos y vendemos ítems y

equipo; y la forja, donde podemos crear armas y equipamiento.

Además, podemos hablar con los habitantes para que nos cuenten

cosas o nos den algún consejo.

Ilustración 10: Aldea



5.6.1.1. Casa

Dentro de la casa del personaje podemos acceder a la mayoría de

opciones que afectan a éste. Podemos acceder al inventario y a la mochila,

donde podremos intercambiar objetos entre ambas, y así poder llevar los

objetos necesarios a las misiones.

También podemos cambiar nuestro equipamiento, viendo los detalles de

cada uno; y comprobar nuestras estadísticas y habilidades activas.

Ilustración 11: Menú principal de la

casa

Ilustración 12: Inventario

Ilustración 13: Pantalla de estado

5.6.1.2. Tienda

En la tienda tenemos la opción de comprar o vender tanto objetos de

nuestro inventario como equipamiento. Además, se irá desbloqueando nuevo

stock según vayamos completando misiones, pudiendo acceder a mejores

objetos.

Ilustración 14: Menú principal de la tienda

Ilustración 15: Pantalla de compra de objetos



5.6.1.3. Forja

En la forja podremos crear nuevas armas, armaduras y escudos a partir

de los materiales que consigamos en las misiones.

5.6.1.4. Puesto de misiones

El puesto de misiones es uno de los puntos importantes en el juego, ya

que es donde podremos aceptar misiones, y así progresar. Las misiones están

clasificadas por categorías, según su dificultad, y se irán desbloqueando según

vayamos completando las que haya disponibles.

Ilustración 16: Menú principal de la

forja

Ilustración 17: Menú de selección de

armadura

Ilustración 18: Mensaje de

confirmación de compra

Ilustración 19: Menú principal del

puesto de misiones

Ilustración 20: Misiones del nivel

'Principiante'

Ilustración 21: Pantalla de

confirmación de misión



5.6.2. Mapas

Los mapas son escenarios a los que accedemos cuando aceptamos una

misión en la aldea. Cada misión transcurre en un mapa concreto, y en él

encontramos determinados enemigos y podremos conseguir ítems variados al

recolectar.

En el caso de que estemos en una misión de recolección,

encontraremos uno o varios baúles donde depositar objetos.

En este prototipo tenemos tres escenarios diferentes:

La escena de tutorial, muy sencilla, tan solo con un vallado.

La estepa, donde predomina la vegetación y los árboles, y donde

podremos encontrar minerales en las rocas.

Las ruinas, donde encontraremos un paisaje más otoñal, además de una

cascada donde podremos encontrar peces y recoger agua.

Ilustración 22: Escena de tutorial

Ilustración 23: Estepa

Ilustración 24: Ruinas



5.7. Misiones

Las misiones son la base del juego. Deberemos ir cumpliendo las que

nos vayan asignando en la aldea, y poco a poco iremos desbloqueando más,

cada vez más complejas. Las misiones tendrán asignado un nivel de dificultad:

Principiante, Avanzado y Experto.

Como recompensas, recibiremos una cantidad de objetos dependiendo

de la misión, así como dinero.

Las misiones pueden ser de dos tipos:

5.7.1. Misiones de entrega de materiales

En estas misiones el objetivo será entregar una serie de ítems que

podremos conseguir en los mapas, ya sea recolectando u obteniéndolos de los

enemigos. El lugar al que deberemos llevar los objetos puede variar, aunque a

menudo será un cofre que encontraremos en el punto de comienzo de la

misión.

Suelen ser las más sencillas, y pretenden hacer ver al jugador la

importancia de conseguir objetos a lo largo de las misiones.

Ilustración 25: Baúl de entrega de objetos

5.7.2. Misiones de combate

En este tipo de misiones, deberemos vencer a una serie de enemigos,

más o menos fuertes. Estos enemigos soltarán distintos objetos al ser

derrotados, que deberemos recoger para poder usarlos en la forja.



5.8. Enemigos

Durante las misiones nos toparemos con diversos enemigos, que nos

atacarán si nos acercamos a una cierta distancia. Cada uno de ellos tiene unas

estadísticas diferentes de ataque, defensa, puntos de salud y valores de daño,

por lo que tendremos que adaptar nuestro equipo según a qué nos

enfrentemos.

Además, al ser derrotados nos entregarán algunos objetos, con los que

fabricaremos equipo en la forja.

Estos son los enemigos presentes en este prototipo (siguiente página):



Nombre e imagen Estadísticas Objetos que suelta

MG-100

Ataque: 50

Defensa: 100

Puntos de salud: 100

Placa de MG-100 60%

Batería de MG 25%

Microchip BETA 15%

MG-201

Ataque: 75

Defensa: 125


Engranaje de MG-201 50%

Batería de MG 30%

Microchip BETA 20%

MG-500

Ataque: 100

Defensa: 175

Puntos de salud:

1000

Batería de MG 30%

Microchip BETA 35%

Procesador de MG-

500 25%

Lente infrarroja 10%

Ogronius

Ataque: 130

Defensa: 90


Brazal de Ogronius 45%

Cinturon de Ogronius 35%

Intrajoya de Ogronius 15%

Alma de Ogro 5%

Ogrerion

Ataque: 95

Defensa: 125


Garra de Ogrerion 45%

Hueso de Ogrerion 35%

Mineral de Ogrerion 15%

Alma de Ogro 5%

Ografio

Ataque: 110

Defensa: 110


Diente de Ografio 45%

Craneo de Ografio 35%

Esfera de Ografita 15%

Alma de Ogro 5%

Tabla 9: Lista de enemigos



5.9. Interfaz de usuario (User Interface Design Document)

En este juego se ha intentado crear una interfaz intuitiva y que ayude al

usuario a progresar, ya sea mediante los diversos menús o proporcionando

elementos gráficos y sonoros durante la partida.

5.9.1. Menú principal

En cuanto empezamos el juego vemos el menú principal, donde

podemos elegir entre empezar una nueva partida, cargar una existente,

modificar algunas opciones o salir.

Si elegimos Nueva partida, se nos pedirá un nombre para nuestro

personaje y empezaremos la aventura.

Si por el contrario elegimos Cargar partida, continuaremos por donde lo

hubiéramos dejado la última vez.

En opciones podemos cambiar algunos parámetros, como la resolución

de pantalla, la calidad gráfica o si queremos que se nos muestren los controles

en pantalla.

Y en los créditos, toda la información acerca de la creación del juego.

Ilustración 26: Menú principal

Ilustración 27: Menú de selección

de nombre

Ilustración 28: Menú de opciones



5.9.2. Interfaz durante una misión

Una vez que empecemos una misión veremos que se añaden elementos

a la pantalla respecto a los que teníamos estando en la aldea. Éstos nos

ayudan a controlar nuestros puntos de salud, si tenemos un aumento de ataque

o defensa, o usar objetos consumibles.

5.9.2.1. Indicadores de estado

Arriba a la izquierda tenemos los indicadores de estado, que se

componen por una barra que marca los puntos de salud restantes y unos

iconos que aparecerán si tenemos un aumento de ataque o defensa.

5.9.2.2. Acceso rápido a objetos

En la parte inferior de la pantalla tenemos el acceso rápido a objetos,

que nos permite cambiar entre los objetos consumibles que tengamos y usarlos

al mismo tiempo que jugamos, sin tener que pausar el juego.

Ilustración 29: Indicador de puntos de salud

Ilustración 30: Indicador de estado con ataque y defensa aumentados

Ilustración 31: Acceso rápido a objetos (cerrado)

Ilustración 32: Acceso rápido a objetos (abierto)



5.9.3. Menú de pausa

En el juego tenemos dos menús de pausa distintos, según estemos en

una misión o en la aldea.

Si estamos en la aldea, el menú de pausa nos permite salir al menú

principal guardando nuestro progreso.

Ilustración 33: Menú de pausa en la aldea

En cambio, si estamos en una misión, el menú es más completo.

Podemos ver los objetos de la mochila, los objetivos de la misión y la opción de

abandonar la misma.

Ilustración 34: Menú de pausa durante

una misión Ilustración 35: Menú de la mochila

Ilustración 36: Objetivos de la misión



5.9.4. Pantalla de recompensa

Cuando finalizamos una misión, se nos entregan unos objetos de

recompensa, que podemos enviar al inventario o vender.

5.9.5. Pantalla de carga

La pantalla de carga está pensada para cargar los recursos en segundo

plano, pero en este caso también se han añadido consejos que ayudarán al

jugador a aprender mecánicas de juego. Estas “pistas” aparecen

aleatoriamente.

Ilustración 38: Pantalla de carga

Ilustración 37: Pantalla de recompensas



5.9.6. Sistema de notificaciones

A lo largo de la partida hay muchos eventos que el jugador debe

conocer. Para esto, se ha incluido un sistema de notificaciones, que hará

aparecer un mensaje en la esquina superior derecha.

Varios ejemplos de notificaciones son:

Al aceptar una misión, se nos informa a donde ir para comenzarla.

Cuando recogemos un objeto vemos cuál es.

Al comprar o forjar algo, se muestra un mensaje confirmándolo.

5.9.7. Efectos visuales

Se han añadido algunos efectos visuales en los menús, como los

cambios de color en los botones para distinguir con claridad el que está

seleccionado.

También hay otros elementos visuales a destacar, como un efecto de

color en la espada si llevamos un revestimiento aplicado en nuestra arma, de

manera que se iluminará de rojo si el revestimiento es de fuego, azul si es de

agua, etc.

Ilustración 40: Efecto de color del arma

Ilustración 39: Ejemplos de notificaciones



5.9.8. Efectos sonoros

En el juego hay multitud de efectos de sonido, empezando por los

menús, donde tenemos un sonido al seleccionar un botón y pulsarlo, así como

cuando abrimos o cerramos un menú, o en las notificaciones (ver apdo. 5.8.6).

Por supuesto, durante una misión tendremos audio en los enemigos,

emitiendo sonidos al entrar en su radio de visión, atacarles o caer derrotados,

además de los sonidos propios del arma al impactar.

Respecto a la banda sonora, se ha incluido música de fondo en todas las

escenas del juego, obtenida de fuentes con licencia libre [R2], aunque la

intención sería añadir música de composición propia, de cara a una futura

comercialización del producto.



5.10. Situaciones de juego (Flowboard)

Durante el transcurso del juego tendremos diferentes situaciones de

juego, en las que los controles y las posibles acciones irán variando.

Una vez iniciamos el juego, nos encontramos con el menú principal,

donde podemos navegar por los botones (ver apdo. 5.8.1), pudiendo elegir

entre las opciones.

Si elegimos iniciar una nueva partida, deberemos introducir nuestro

nombre. Tras esto iniciaremos el tutorial para conocer los controles básicos.

A continuación estaremos en la aldea, donde ya podremos controlar a

nuestro personaje, pudiendo andar o correr, así como hablar con los

personajes NPC que nos encontraremos y entrar en los edificios (casa, tienda,

etc.). También podemos pausar el juego para salir.

Al entrar en la casa, ya no podremos manejar al personaje, solo navegar

por los menús, al igual que en la tienda, la forja o el puesto de misiones. Aun

así, podremos ver a nuestro personaje moverse mediante animaciones.

Al pasar por el puesto de misiones y escoger una misión, nos tendremos

que dirigir a la salida de la aldea para empezarla. Una vez que hayamos

llegado a nuestro destino, podremos controlar a nuestro personaje con más

acciones, como son los distintos ataques y el uso de objetos. Al igual que en la

aldea, podemos pausar la partida, pero en esta ocasión tendremos más

opciones disponibles, entre ellas abandonar la misión y volver a la aldea.

Si la misión elegida es de recolección, el objetivo será entregar los

objetos que se nos pidan en el baúl de entrega. Si la misión es de combate,

deberemos acabar con los enemigos que nos pidan. En ambos casos, al

completar la misión, se nos entrega la recompensa y decidiremos si enviarla al

inventario o venderla.



Aldea

Misión

Menú principal Elegir nombre

Casa

Tienda

Forja

Puesto de misiones

Misión de recolección Misión de combate

Recompensa

Nueva partida

Cargar partida

Completar misión

Aceptar misión



5.11. Evolución del juego (Story and Level Progression

Document)

El objetivo final del juego es ir completando misiones, hasta llegar al jefe

final. En esta versión, al ser un prototipo, solo tenemos unas cuantas misiones,

mostrando los distintos tipos que hay.

Las misiones se van desbloqueando en cadena, es decir, al completar

una misión, se desbloquean otras, y así sucesivamente. Con ello, también se

van desbloqueando nueva mercancía en la tienda, y nuevas opciones para la

forja al tener acceso a nuevos materiales.

Las misiones disponibles en esta versión son:

Nombre Tipo Objetivo Nivel

Explorando la

estepa Recolección

Entregar 3 minerales Hierro y 8

trozos de Madera Principiante

Registrando las

ruinas Recolección Entregar una Moneda de oro Principiante

Maquinaria

Ligera Combate Derrotar 5 MG-100 Principiante

Escasez de metal Recolección Entregar materiales de los

enemigos Avanzado

Maquinaria

pesada Combate Derrotar al MG-500 Experto

Intrusos

nocturnos Combate Derrotar a todos los enemigos Avanzado

Tabla 10: Lista de misiones



6. DISEÑO E IMPLEMENTACIÓN

En cuanto al diseño e implementación de las clases que forman el

videojuego, se ha intentado agruparlas en módulos, según la relación o

dependencias que haya entre ellas.

En resumen, tenemos varios grupos:

- Objetos y su uso

- Gestión de las estadísticas y características del personaje

- Sistema de habilidades

- Almacenamiento de objetos (Inventario y Mochila)

- Equipamiento (armas, armaduras, etc.)

- Enemigos

- Mercancía en la tienda y la forja

- Elementos de interfaz

- Audio

- Guardado y carga de datos



6.1. Sistema de objetos

En este apartado, tenemos la clase Item, una estructura de

almacenamiento ItemDatabase, y la clase ItemEffect y subclases que

representan los distintos usos de los objetos consumibles.

Diagrama 1: Sistema de objetos

6.1.1. Clase Item

Dentro de la clase Item tenemos los atributos básicos: id, nombre,

descripción, cantidad máxima para la mochila, valor (precio de compra/venta),

una variable que dice si se puede consumir o no y el icono que se mostrará en

los menús del juego.

También se define un efecto (ver apdo. 6.1.2), que diferenciará a los

objetos consumibles de los no consumibles; y el tipo de objeto, que es más

bien informativo.



Como métodos, tenemos los getter de todos los atributos, dado que

éstos últimos son privados; el constructor, en el que le pasamos todos los datos

para la creación; y el método UseItem, que se usará en el transcurso de una

misión, y que afectará a las estadísticas del jugador, de ahí que se le pase un

objeto de tipo IG_Player (ver apdo. 6.2.2).

6.1.2. Clase ItemEffect

Esta clase es abstracta e implementa el patrón Estrategia [9], ya que

define un método abstracto UseItem, que nos obliga a redefinir en sus

subclases. Estas subclases son cada uno de los diferentes comportamientos

que podrán tener los objetos consumibles: restaurar puntos de salud o

aumentar nuestro ataque o defensa durante un tiempo determinado.

En la subclase RestoreHealth, tenemos el constructor, al que le

pasamos como parámetro los puntos de salud que recuperará el jugador al

usar el objeto.

Para las otras dos subclases, los constructores reciben como

parámetros el aumento de ataque o defensa, siendo un multiplicador mayor

que 1. Por ejemplo, un valor de 1.25 aumentará la estadística un 25%. También

le indicamos el tiempo que durará el efecto, en segundos.

En las tres subclases se redefine el método UseItem, que llamará a la

función correspondiente de la clase IG_Player (ver apdo. 6.2.2).



6.1.3. Clase ItemDatabase

Como se puede observar en el diagrama 1, esta clase está basada en el

patrón Singleton [8], cuya principal utilidad es el acceso global a una instancia

estática de ésta.

Para almacenar todos los objetos diferentes del juego usamos un

Dictionary [6], una colección que guarda pares <clave, valor>. Esto nos permite

buscar por clave de manera eficiente.

Para la búsqueda, tenemos dos métodos: GetItemWithID para buscar

por ID, que además es la clave en la colección y hará más eficiente la

búsqueda; y GetItemWithName que hará una búsqueda lineal por todas las

tuplas, por lo será usado en caso de que nos sea complicado utilizar la anterior.

Por último, tenemos la función ItemDatabaseSize, que nos devuelve el

número de tuplas de la colección.



6.2. Gestión del personaje

Para manejar la información del personaje, como son las estadísticas, el

nombre o el equipamiento actual, tenemos dos grandes clases: Player e

IG_Player (‘IG’: In-game).

La primera usa el patrón Singleton [8] y es global en todo el juego, la

segunda está asociada al GameObject del propio personaje y controla las

estadísticas durante las misiones.

6.2.1. Clase Player

Diagrama 2: Clase Player

Como se ha indicado anteriormente, esta clase implementa el patrón

Singleton, lo que permite que tengamos acceso global a la instancia desde

cualquier parte del código. En ella tenemos los atributos básicos del personaje,

como el nombre o el dinero.



Además tenemos las estadísticas de PS (Puntos de Salud), Ataque,

Ataque elemental y Defensa; cada una representada por dos variables, que se

obtienen de la siguiente manera:

stat_PS_base: Puntos de salud del personaje (por defecto, 100).

stat_Attack_base: Ataque base del personaje, obtenido del valor de

ataque del arma que lleve equipada en ese momento.

stat_ElementalAttack_base: Ataque elemental base del personaje,

obtenido del revestimiento que lleve el arma equipada (si no hay

ninguno, valdrá cero).

stat_Defense_base: Defensa base del personaje, obtenida la suma del

valor de defensa de la armadura y del escudo equipados.

totalPS: A partir de stat_PS_base, se modifica si alguna habilidad afecta

al número de puntos de salud.

totalAttack: A partir de stat_Attack_base, cambiará si una habilidad

afecta al stat de ataque.

totalElementalAttack: A partir de stat_ElementalAttack_base, cambiará si

una habilidad afecta al stat de ataque elemental.

totalDefense: A partir de stat_Defense_base, cambiará si una habilidad

afecta al stat de defensa.

Además, tenemos una referencia a cada uno de los elementos

equipables (arma, revestimiento, armadura, escudo y emblema), así como una

lista con las habilidades activas, otra lista con los puntos de habilidad, y otra

con los índices de daño para cada tipo de ataque recibido.

En cuanto a métodos, tenemos para guardar o cargar los datos de la

clase (ver apdo. 6.11), y para equipar cada una de las partes del equipo,

usando las restantes que actualizan tanto las habilidades como los índices de

daño.



6.2.2. Clase IG_Player

Este script va asignado al GameObject del personaje, es decir, se

ejecuta durante la ejecución de cada escena, usando los atributos ps, attack,

defense y elementalAttack para calcular tanto el daño que infligimos a los

enemigos como el que recibimos de ellos.

También vemos que tenemos referencias tanto al Animator como al

PlayerController, puesto que en este mismo script activamos ciertas

animaciones o comportamientos del personaje, como activar una animación

concreta al consumir un objeto.

En cuanto a los métodos, tenemos Start y Update, que son propios de

Unity [5] y nos sirven para la inicialización de variables y ejecuciones cada

frame, respectivamente. También tenemos métodos que son usados en

ItemEffect, para restaurar salud o aumentar el ataque o la defensa

temporalmente, además de una función que calcula el daño recibido por un

enemigo al contactar con nosotros, y dos más para cuando se nos acaban los

puntos de salud y tenemos que revivir.

Diagrama 3: Clase IG_Player



6.2.3. Controlador del personaje (PlayerController)

Este script va asignado al personaje en la escena, y nos permite

controlarlo con el teclado o el joystick. Dependiendo de si estamos en la aldea

o en una misión, las acciones que podemos hacer varían, ya que sólo en una

misión podemos ejecutar ataques o consumir objetos.

Tenemos controles para movernos, correr, atacar, agacharnos y

bloquear. Combinando estas acciones podemos atacar de diferentes formas. Si

estamos parados o caminando, podemos hacer un combo de tres ataques con

la espada manteniendo pulsado el botón de atacar, mientras que si vamos

corriendo, haremos un ataque en carrera. Aparte, el bloqueo nos sirve para no

recibir daño de los enemigos, adquiriendo una posición defensiva que no nos

permite movernos ni atacar.

Como detalle, el control es relativo a la cámara por lo que es bastante

intuitivo. Además, la cámara está configurada para seguir al personaje.

En cuanto a las animaciones, cada acción lleva asociado un estado, que

es el que se activará en el animador.

Ilustración 41: Máquina de estado para el personaje



6.2.4. Personalización del personaje (CharacterCustomization)

Este script se encarga de personalizar el personaje acorde al equipo que

llevemos, es decir, que cambie nuestra apariencia según cambiemos de

armadura, arma o escudo.

Esto se hace mediante dos funciones que recopilan los atributos de

apariencia de cada una de las partes del equipo y las asigna al modelo del

personaje. Estos atributos son:

Clase Armor: atributo material (tipo Material).

Clase Weapon: atributo material (tipo Material).

Clase WeaponCoat: atributo effectColor (tipo Color).

Clase Shield: atributo material (tipo Material).

Para hacer estos cambios tenemos la función UpdateMaterial, a la que

llamamos cuando cambiamos alguna parte del equipo en el menú de la casa.

Ilustración 42: Personalización del personaje



6.3. Sistema de habilidades

El sistema de habilidades se basa en el uso de una clase abstracta,

cuyos métodos deberán implementar cada una de las subclases. Estos

métodos sirven para activar la habilidad, desactivarla, mostrar sus datos en un

string y, por último, para mostrar los niveles de cada habilidad.

Cada subclase representa una habilidad distinta:

AttackBoostSkill: Aumento de ataque permanente, esto es,

multiplicamos por un cierto valor el ataque de nuestro arma.

DefenseBoostSkill: Aumento de defensa permanente, es decir,

multiplicando nuestra defensa base (armadura + escudo) por un

coeficiente.

MorePSSkill: Aumento del número máximo de Puntos de Salud.

MoreItems4RewardSkill: Con esta habilidad obtenemos más objetos

como recompensa de las misiones.

MoreMoney4RewardSkill: Con esta habilidad ganamos más dinero al

completar una misión.

ElementalAttackBoostSkill: Aumento de ataque elemental permanente.

Diagrama 4: Clase Skill y subclases



6.4. Inventario y Mochila

El inventario y la mochila nos serán muy útiles a lo largo del juego, ya

que nos permiten guardar nuestros objetos. Ambas clases implementan el

patrón Singleton [8], visto anteriormente, que nos permite acceder a ellas

desde cualquier parte del código. También tienen métodos para listar, guardar

y extraer objetos, así como guardar y cargar desde fichero (ver apdo. 6.11)

6.4.1. Clase Inventory

La clase Inventory nos permite guardar objetos, armas, revestimientos,

armaduras, escudos y emblemas en colecciones diferentes, usando SortedList

(listas ordenadas).

Los atributos *FileName sirven para especificar el nombre de los ficheros

donde guardamos y cargamos los datos.

Por otra parte, como métodos tenemos para guardar, extraer, obtener un

listado o consultar la cantidad de un objeto concreto; así como para guardar,

cargar o vaciar el inventario.



Diagrama 5: Clase Inventory



6.4.2. Clase Bag

La clase Bag solo nos permite llevar objetos a las misiones, y tiene una

capacidad limitada. Además, a diferencia del inventario, solo podremos llevar

una cantidad máxima de unidades de cada objeto, distinta en cada uno.

Al igual que en el inventario, tenemos métodos para guardar, cargar y

vaciar la mochila, así como listar, guardar o extraer objetos. También tenemos

funciones para enviar o recibir objetos del inventario.

Diagrama 6: Clase Bag



6.5. Equipamiento

El equipamiento está formado por cinco partes: arma, revestimiento,

armadura, escudo y emblema. De ellas, el revestimiento y el emblema no son

obligatorios, aunque es recomendable usarlos.

Respecto a sus clases, todas tienen en común varios atributos: ID,

nombre, descripción, valor (precio de compraventa) e icono; y como método, el

usado para equipar dicha parte del equipo.

En todos los casos, estas clases estarán relacionadas con otra clase

“colección”, al igual que pasaba en el caso de ItemDatabase (ver apdo. 6.1.3),

que nos permiten obtener objetos por ID o por nombre.

6.5.1. Armas (Weapon)

Para las armas, añadimos los siguientes atributos:

attack: El valor de ataque del arma.

material: Material asociado al arma, que afecta al color y brillo.

Diagrama 7: Clases para las armas



6.5.2. Revestimiento del arma (WeaponCoat)

En cuanto a los revestimientos del arma, añadimos los atributos:

element: Elemento que posee el revestimiento.

elementAttack: Valor de ataque elemental.

effectColor: Color que tendrá el efecto de movimiento de la espada al

usarse este revestimiento (ver apdo. 5.8.7).

Diagrama 8: Clases para los revestimientos

6.5.3. Armaduras (Armor)

Para las armaduras, tenemos los atributos:

defense: Valor de defensa.

damageRatios: Valores de daño, especificados por un número por cada

tipo de elemento, haciéndonos más resistentes si es menor que 1, y más

vulnerables si es mayor que 1.

skillPoints: Puntos de habilidad, guardados en pares <ID de la habilidad,

Puntos>.

material: Material asignado a la armadura, que define el color, brillo,

textura, etc.

También se añaden métodos para asignar los valores de daño y los

puntos de habilidad, usados después del constructor.



Diagrama 9: Clases para las armaduras

6.5.4. Escudos (Shield)

Respecto a los escudos, comparte atributos con las armaduras, así

como los métodos para asignar valores de daño y puntos de habilidad

Diagrama 10: Clases para los escudos

6.5.5. Emblemas (Emblem)

En cuanto a los emblemas, tan solo añadimos los puntos de habilidad,

que es lo único que aporta este componente del equipo.

Diagrama 11: Clases para los emblemas



6.6. Sistema de misiones

En este juego las misiones son una de las partes esenciales, por lo que

se ha dedicado mucho esfuerzo en hacer un sistema completo, que permita

crear distintas misiones, de distinto tipo, con sus objetivos respectivos.

6.6.1. Clases Quest (y subclases) y QuestCollection

Estas dos clases forman un módulo similar a otros ya vistos

anteriormente (por ejemplo, Item + ItemDatabase).

Diagrama 12: Clases para las misiones

Por un lado, la clase Quest es abstracta, y reúne los atributos básicos

para definir una misión. Tiene como subclases los tipos concretos de misión, en

este caso, de recolección (FarmQuest) y de combate (CombatQuest).

La clase Quest tiene los siguientes atributos:

id: ID de la misión.

level: Nivel o categoría de la misión.

name: Nombre.

description: Descripción de los objetivos.



reward: Objeto de tipo Reward (ver apdo. 6.6.3) que define tanto los

objetos de recompensa como el dinero recibido.

type: Tipo de misión (Recolección o Combate).

state: Estado de la misión (Bloqueada, Desbloqueada o Completada).

unlocks: Array con los IDs de las misiones que se desbloquean al

completar esta.

unlockShopPack: Conjuntos de objetos y equipo que se desbloquean en

la tienda al superar esta misión (ver apdo. 6.8.1).

Como métodos, tenemos para cambiar el estado o añadir misiones que

se desbloquearán.

Para las subclases, añadimos los siguientes atributos:

itemList: Lista con los objetos que hay que entregar. Se encuentran

repetidos, ya que de aquí se irán sacando a la hora de controlar los

objetivos de la misión de recolección.

itemList_NR: Lista con los objetos sin repetir, que sirve como auxiliar.

enemyList: Lista de enemigos a derrotar. Hay repetidos, ya que de aquí

vamos restando los objetivos de la misión de combate.

enemyList_NR: Lista auxiliar con los enemigos sin repetir.

Para ambas subclases tenemos el constructor correspondiente y un

método para añadir objetos o enemigos como objetivo.

En la clase QuestCollection usamos el patrón Singleton, usado con

anterioridad, e incluyendo métodos para obtener misiones por ID o nombre.



6.6.2. Clase QuestLog

En esta clase llevaremos un control sobre el estado de las misiones,

esto es, saber cuáles hemos completado, cuales tenemos pendientes, y cuales

aún están bloqueadas.

Volvemos a utilizar el patrón Singleton, así como una colección de tipo

Dictionary, en la que guardamos pares <ID de la misión, Estado>. También

tenemos la variable currentQuestID, que cambiará cuando aceptemos una

misión en la aldea, almacenando la ID de ésta. Además, en la variable

anyQuestAccepted tenemos un booleano que nos dice si hay una misión

pendiente, de manera que podremos salir por la puerta de la aldea sólo si

vamos a una misión.

Como métodos, tenemos los siguientes:

QuestWithLevel: Nos devuelve una lista con los IDs de las misiones

desbloqueadas (con estado Completada o Desbloqueada) del nivel que

le pasemos. Se usa en la interfaz del puesto de misiones, a la hora de

escoger nivel y misión.

CompleteQuest: Cambia el estado de la misión a completado y

desbloquea las misiones que lleve asociadas, así como nuevos objetos y

equipo para la tienda si se diera el caso.

SaveQuestLog y Save: Guardan el estado de las misiones en fichero

mediante serialización (ver apdo. 6.11).

LoadQuestLog y Load: Cargan el estado de las misiones desde fichero.

Diagrama 13: Clase QuestLog



6.6.3. Recompensa de misión (Reward)

Al completar una misión obtendremos tanto objetos como dinero de

recompensa. Estos objetos son definidos en un objeto de tipo Reward.

Diagrama 14: Clase Reward

Los atributos de esta clase son:

minObj: Mínimo número de objetos que podemos obtener.

maxObj: Máximo número de objetos.

itemIDs: Array con las IDs de los diferentes objetos posibles.

itemProbs: Array con la probabilidad (entre 0 y 100) de obtención de

cada objeto de itemIDs.

money: Dinero a recibir como recompensa.

MORE_MONEY_SKILL_BONUS: Valor que varía en función de si

tenemos activa la habilidad MoreMoney4RewardSkill. Es modificado a la

hora de activar dicha habilidad, y afecta al cálculo del dinero de

recompensa.

MORE_ITEMS_SKILL_BONUS: Valor que varía si activamos la

habilidad MoreItems4RewardSkill. Se modifica al activar esta habilidad, y

afecta al cálculo del número de objetos de recompensa.

Además, tenemos como métodos el constructor correspondiente, al que

le pasamos todos los datos, y el encargado de generar la recompensa,

devuelta como un array de int con las IDs de los objetos.



6.6.4. Controladores de misión

Durante una misión necesitamos llevar el control de los objetivos, ya

sean objetos que nos quedan por entregar o enemigos por derrotar. Para ello

tenemos los scripts IG_FarmQuestManager (para misiones de recolección) e

IG_CombatQuestManager (para misiones de combate).

Los atributos de estos scripts son los siguientes:

quest: Misión actual, que se cogerá dinámicamente una vez que

entremos en la misión.

itemsTargetList/enemyTargetList: Colección de tipo Dictionary que

almacena pares <ID del objeto/enemigo, cantidad restante>, de donde

iremos descontando a medida que vayamos progresando en la misión.

itemMaxs/enemyMaxs: Similar al anterior, pero este Dictionary

permanece intacto durante la ejecución, de manera que siempre

podamos consultar los objetivos iniciales.

rewardGUI: Referencia a la interfaz de recompensa, de forma que

podremos activarla desde aquí cuando cumplamos el objetivo.

En cuanto a métodos, tenemos los siguientes:

Start: Obtiene la misión actual de la variable currentQuestID de la clase

QuestLog (ver apdo. 6.6.2), y de ésta obtiene los objetivos para

guardarlos en los Dictionary.

CheckTarget: Comprueba que hayamos cumplido todos los objetivos, en

otras palabras, que itemsTargetList/enemyTargetList esté vacío.

Diagrama 15: Controladores de misión



DeliverItem/DefeatEnemy: Descuenta un objeto/enemigo de los

objetivos, posteriormente llama a CheckTarget.

FinishQuest: Se usa una vez que CheckTarget nos devuelve verdadero.

Tras ello registramos la misión como ‘Completada’ en QuestLog y

mostramos la pantalla de recompensa.

AbandonQuest: Nos devuelve a la aldea sin acabar la misión, por lo que

la seguiremos teniendo pendiente. Al menos podemos llevarnos los

objetos recolectados.

BackToTown: Este método es llamado desde AbandonQuest, pero está

aparte debido a que es usado desde elementos de la interfaz.

6.7. Enemigos

Para los enemigos, tenemos similitudes con clases anteriores, ya que

tenemos una clase Enemy que define las características del enemigo, y una

clase EnemyCollection que reúne a todos los enemigos del juego.

También tenemos el script EnemyIngame, que se asigna al gameObject

del enemigo y controla sus atributos durante la partida, así como generar los

objetos de recompensa al ser derrotado.

Por último, tenemos el script EnemyReward, asignado a cada uno de los

objetos de recompensa generados, y que nos permite guardar ese ítem en el

inventario al tocarlos.



6.7.1. Enemy y EnemyCollection

Diagrama 16: Clases para los enemigos

La clase Enemy tiene los siguientes atributos:

id: ID del enemigo.

name: Nombre.

attack: Ataque del enemigo, utilizado para calcular el daño que recibimos

de él.

defense: Defensa, utilizada para calcular el daño que le causamos.

healthPoints: Puntos de salud.

damageRatios: Valores de daño elemental, cumplen la misma función

que en el caso de las armaduras y escudos.

numItemsReward: Número de objetos que soltará el enemigo al ser

derrotado.

itemList: Array con los IDs de los posibles objetos de recompensa. Ej:

[0,1,20,21]

probList: Array con la probabilidad en % de cada objeto de itemList. Ej:

[30,30,25,15]

icon: Icono del enemigo, usado en los menús.

En el caso de EnemyCollection, usamos el patrón Singleton [8], y

métodos para obtener enemigos por ID o nombre, así como el tamaño de la

colección.



6.7.2. EnemyInGame

Este script controla los parámetros del enemigo durante la misión,

calculando el daño recibido de nuestros ataques y generando la recompensa al

caer derrotado.

Tiene los siguientes atributos:

en: Objeto de la clase Enemy asociado.

id: ID del enemigo, el cual tenemos que introducir desde el editor de

Unity para obtener en.

playerStats: Referencia al script del jugador, del que obtenemos el

ataque del arma (weaponAtk), ataque elemental (elemAtk) y elemento

(element).

cqManager: Referencia al script IG_CombatQuestManager (ver apdo.

6.6.4) si lo hay, para comprobar objetivos al ser derrotado.

anim: Animator del enemigo, para usar las animaciones de ‘React’ y

‘Die’.

itemPrefab: GameObject del objeto de recompensa, que se creará al

caer derrotado.

items: Referencias a todos los objetos de recompensa generados por

este enemigo.

Diagrama 17: Clase EnemyInGame



6.7.3. EnemyMovement

Este script es el encargado del movimiento del enemigo, así como de

cambiar las animaciones.

Tenemos como atributos:

character: Referencia al componente

Transform de nuestro personaje, que contiene

la posición, siendo el punto al que se dirigirá el

personaje cuando nos detecte.

anim: Componente Animator del enemigo, que

nos permitirá cambiar las animaciones cuando

camine, ataque, etc.

m: Componente NavMeshAgent, que se usa

para definir por qué zonas del escenario puede moverse el personaje, y

que ayuda mucho a la simplificación del movimiento. Simplemente le

indicamos la posición de nuestro personaje como punto de destino y el

enemigo se dirigirá allí automáticamente.

followCharacter: Booleano que nos indica si el personaje nos ha

detectado, y por lo tanto se dispondrá a atacarnos.

enemySound: Esta clase se usa para emitir sonidos propios del

enemigo, como al detectarnos, atacar, recibir ataque, etc.

También tenemos varios métodos interesantes:

Start: Aquí se inicializan las variables, y se le indica como punto de

destino nuestra posición.

Update: En este método se controla el movimiento, se moverá hacia

nosotros si entramos en su radio de visión y se quedará quieto si no.

Además, si está lo bastante cerca, empezará a atacarnos.

OnTriggerEnter: Función que se ejecuta al entrar en el radio de visión

del enemigo, lo que hará que followCharacter cambie a true.

OnTriggerExit: Cambiará la variable followCharacter a false debido a que

habremos salido del radio de visión del enemigo.

Diagrama 18: Clase EnemyMovement



6.7.4. EnemyReward

Este script está asignado a cada uno de los objetos de recompensa

generados por el enemigo.

Tiene como atributo item el propio objeto, y como método destacable,

OnTriggerEnter, que controla cuando lo tocamos y lo añade a nuestra mochila.

6.8. Mercancía en la tienda y la forja (ShopAvailableStock y

ForgeAvailableStock)

Estas dos clases definen los objetos o equipo que nos encontraremos en

la tienda y la forja, respectivamente. Ambas usan el ya repetido patrón

Singleton, así como guardado y carga mediante serialización en fichero (ver

apdo. 6.11).

6.8.1. ShopAvailableStock

Para la tienda tendremos varias listas, en las que figuran los IDs de los

ítems que podremos encontrar, de manera que podremos añadir más a medida

que vayamos progresando en el juego. También se definen packs de objetos,

de forma que a la hora de desbloquear objetos solo tendremos que llamar a

una función con el ID de un pack para incluir su contenido en la lista

anteriormente citada.

Diagrama 19: Clase EnemyReward



Diagrama 20: Clase ShopAvailableStock

Los packs de objetos se almacenan en un array doble. Por ejemplo,

tenemos 4 packs de objetos diferentes, cada uno con objetos distintos, que se

guardarían de la siguiente forma:

Ilustración 43: Ejemplo de instanciación de packs de objetos

Si quisiéramos desbloquear el pack 1, solo tendríamos que llamar a

UnlockItemPack (1), por ejemplo al completar una misión concreta. Por otro

lado, los objetos y equipo presentes en packs con índice cero estarán

disponibles desde el comienzo del juego.



6.8.2. ForgeAvailableStock

Respecto a ForgeAvailableStock, es una de las clases más complejas

del sistema, ya que no solo tenemos que almacenar qué equipo estará

disponible para crear, sino también los materiales y el dinero necesarios para

hacerlo.

Diagrama 21: Clases para la forja

Como vemos, tenemos tres colecciones de tipo Dictionary, una por cada

tipo de equipo que podemos crear, almacenando pares <ID de la instancia,

componente de creación>. Este componente de creación es un objeto de una

clase auxiliar (WeaponCreation, ArmorCreation o ShieldCreation), que define

para un arma/armadura/escudo los objetos y el dinero necesarios, así como

métodos para comprobar si cumplimos dicha condición, y crear el elemento

añadiéndolo al inventario.



Volviendo a la clase principal, posee métodos para listar los elementos

disponibles, así como obtener una lista con los objetos necesarios para crear

un elemento, y la cantidad de dicho objeto y su precio.

Para ver más claro cómo funciona este proceso, veamos el código

reducido de la función InitWeaponCreationDictionary:

Ilustración 44: Ejemplo de instanciación de armas en la forja

En ella, vemos como se generan dos armas para su creación:

El arma con ID = 0 costará 500€, así como la entrega de 10 unidades

del objeto con ID = 2.

El arma con ID = 1 costará 1500€, así como la entrega de 12 unidades

del objeto con ID = 2 y 5 unidades del objeto con ID = 20.



6.9. Elementos de interfaz

Pese a que en las nuevas versiones de Unity el diseño de interfaces se

centra más en el propio editor, aún nos hacen falta scripts para gestionar la

interacción entre elementos, así como para realizar transiciones y animaciones.

6.9.1. Menú principal

Para el menú principal del juego, tenemos varios script con funciones

públicas que serán asignadas a cada uno de los botones mediante el editor de

Unity.

Estos scripts son los siguientes:

MainMenuFunctions: Este script controla la primera pantalla del menú

principal. Activará o desactivará el botón Continuar partida según

encuentre archivos de guardado en el equipo. En el caso de que haya,

proporciona funcionalidad a dicho botón, cargando estos ficheros y

reanudando la partida.

Además, define la función para salir del juego, asociada al botón

Salir, que cierra la aplicación.

NewGame: Este script controla la pantalla de selección de nombre del

personaje, proporcionando funciones a las teclas, tanto a las alfabéticas,

como a las de Enter y Borrar. La tecla Enter asigna el nombre a nuestro

personaje y comienza la partida, después de mostrarnos una

confirmación.



6.9.2. Pantalla de carga

La pantalla de carga entre escenas es un elemento importante dentro de

la interfaz del juego, ya que permite cargar los recursos en segundo plano sin

que el usuario tenga que ver escenas a medio cargar y efectos desagradables.

Esta pantalla contiene dos scripts, LoadingScreen se dedica a la carga

asíncrona de la escena siguiente, y LoadingScreenTips permite mostrar

consejos y trucos del juego para amenizar la espera (ver apdo. 5.9.5).

En el caso de LoadingScreen tenemos los siguientes atributos y

métodos:

sceneToLoadIndex: Variable estática en la

que guardamos el ID de la escena que

vamos a cargar mientras se muestre la

pantalla de carga.

loadingScreenIndex: Aquí definimos el

índice de la escena de la pantalla de carga,

ya que Unity carga las escenas indicando un

índice según el orden que tienen en la

configuración del Editor.

async: Variable en la que se almacena el proceso asíncrono de carga en

segundo plano. De ella podemos obtener el porcentaje de carga y

conocer cuando han terminado de cargarse los recursos.

isLoaded: Booleano que indica si han terminado de cargarse los

recursos de async.

loadingText y loadedText: Son los rótulos que se muestran en la pantalla

mientras se carga la escena y una vez que ha terminado de cargar,

respectivamente.

Diagrama 22: Clase LoadingScreen



Por otro lado, en LoadingScreenTips tenemos los siguientes atributos y

métodos:

tipPrefabs: Array con todos los posibles consejos que se nos pueden

mostrar.

Método Start: En este método generamos un número aleatorio entre 0 y

el tamaño de tipPrefabs, e instanciamos el consejo que esté en esa

posición.

6.9.3. Notificaciones

Para las notificaciones (ver apdo. 5.9.6), usamos un script bastante

simple, con funciones que pueden ser llamadas en cualquier momento de

manera externa. Este script está asignado a un elemento de interfaz vacío, de

manera que al llamarse a estas funciones este elemento va almacenando

mensajes como si de una pila se tratase.

A este script debemos indicarle desde el Editor de Unity los prefab de

cada tipo de notificación. Estos prefab son elementos de interfaz preparados

para ser instanciados, e incluyen el color de fondo, del texto, un icono

representativo y un sonido.

Diagrama 23: Clase para las

notificaciones



Tenemos los siguientes tipos de notificación:

message: Notificación estándar, usada en cualquier situación.

error: Se muestra al no tener dinero o materiales en la forja en la tienda,

o en general para cualquier tipo de fallo o advertencia que el jugador

deba saber.

confirm: Mostrada al aceptar una misión, entre otros casos.

trans: Usada al comprar o vender objetos en la tienda.

save y load: Se muestra al guardar o cargar datos.

atkBoost y defBoost: Usada al consumir un objeto de aumento de ataque

o defensa, respectivamente.

restoreHealth: Mostrada al usar un objeto que restaure salud, como una

poción.

6.9.4. Cuadros de diálogo

Durante el juego nos encontraremos con algunos personajes u objetos

con los que podremos interaccionar, dándonos información y consejos. Esto es

posible mediante un sistema de diálogos.

Para ello tenemos el script NpcDialog, que contiene un array con los

mensajes que se nos mostrarán, de manera que de una forma sencilla

añadimos interacción a cualquier objeto o personaje. Aparte, si es un

personaje, emitirá un sonido como saludo y gesticulará a medida que nos vaya

hablando.

Ilustración 45: Diálogo con NPC



6.10. Controlador de audio (SoundManager)

A la hora de producir sonidos necesitamos tener una fuente de sonido,

llamada AudioSource en Unity, a la que podamos tener acceso para reproducir

cualquier sonido. Esto puede llegar a ser complicado si cada objeto de la

escena que produzca sonido tuviera que tener su propio AudioSource, de

manera que se ha optado por una fuente de sonido global, de manera que

desde cualquier parte del código podamos llamar a este SoundManager

pasándole simplemente el sonido que queremos reproducir.

Este script controla dos fuentes de audio, una principal que se usa para

reproducir efectos de sonido (menús, enemigos, voces, etc.) y otra que se usa

para la música de fondo. La razón de separarlas es el poder variar el volumen

de la música de fondo sin que afecte a la otra fuente de audio.

Como se ve en la imagen, tenemos dos objetos de tipo AudioSource, y

varios métodos:

Awake: Es similar a Start(), y se ejecuta nada más entrar en la escena,

buscando los componentes AudioSource y asignándolos a las dos

variables.

Play: Esta función reproduce un sonido en la fuente principal.

SetVolumeBGM: Cambia el volumen de la música de fondo, pasándole

un parámetro entre 0 y 1.

PauseBGM: Pausa la música de fondo.

UnPauseBGM: Reanuda la reproducción de la música de fondo.

Diagrama 24: Clase SoundManager



6.11. Guardado y carga de datos

En muchas de las clases vistas más arriba se han usado métodos para

guardar y cargar los datos. Esto es posible mediante la serialización de objetos.

Veamos como ejemplo los métodos de guardado y carga de la clase

QuestLog:

En el método de guardado de esta clase guardamos por un lado una

lista con las claves del Dictionary, y en otra los valores, siendo una limitación

de este tipo de guardado el no permitir guardar varias variables en el mismo

fichero. De todas formas son ficheros de poco tamaño, por lo que no debemos

preocuparnos demasiado por esto.

Como vemos, la ruta en la que guarda estos ficheros no es fija, ya que

depende del directorio donde Unity guarda los datos de este juego, variando

entre sistemas operativos. En Windows esta ruta es “C:/Users/(Nombre de

usuario)/AppData/LocalLow/(Nombre del desarrollador)/(Nombre del juego)”.

Ilustración 46: Ejemplo de guardado con serialización



Ilustración 47: Ejemplo de carga desde fichero

En el método de carga hacemos el proceso contrario, leyendo los datos

del fichero y almacenándolos en las variables.

Por otro lado, se ha utilizado otro método de guardado/carga basado en

PlayerPrefs. Esta clase es propia de Unity, y nos permite almacenar pares

<clave, valor>, pero solo de tipo int, float y string. Este método es mejor si solo

queremos guardar valores simples, por lo que se ha usado para almacenar los

atributos de la clase Player, de la siguiente forma:

Ilustración 48: Ejemplo de guardado mediante PlayerPrefs



Ilustración 49: Ejemplo de carga mediante PlayerPrefs

Nótese que para guardar las partes del equipo usamos su ID, de manera

que al cargar, equipamos cada una de las partes, calculándose los stats y

habilidades.

Para recopilar todas las llamadas a métodos de guardado y carga de

todas las clases se ha creado la clase SaveLoadSystem, la cual tiene solo dos

funciones:

Ilustración 50: Guardado y carga general de todas las clases



7. RECURSOS UTILIZADOS

[R1] Animaciones para el personaje y los enemigos, y modelo del enemigo

‘Robot’: [https://www.mixamo.com/]

[R2] Música: [http://incompetech.com/music/royalty-free/]

[R3] Iconos para objetos, armas, etc.: [http://game-icons.net/]

[R4] Fuente para el texto: [http://www.dafont.com/es]

[R5] Modelo del personaje:

[https://www.assetstore.unity3d.com/en/content/42454]

[R6] Pack de animaciones para el personaje:


[R7] Efectos de sonido para los menús:



[R8] Efecto visual del arma:


[R9] Efecto visual de los objetos obtenidos de los enemigos:


[R10] Voces de los enemigos:


[R11] Modelo del enemigo ‘Ogro’:


[R12] Modelos de árboles y rocas:


[R13] Modelos de construcciones para la aldea:


[R14] Modelo de cascada:


https://www.mixamo.com/

http://incompetech.com/music/royalty-free/

http://game-icons.net/

http://www.dafont.com/es

https://www.assetstore.unity3d.com/en/content/42454













[R15] Modelos para la zona del templo:


8. CONCLUSIONES

8.1. Conocimientos aplicados

Durante el desarrollo del proyecto he intentado utilizar la mayor parte de

los conocimientos adquiridos durante el Grado, sobre todo en la parte de

Diseño e Implementación.

Entre estos conocimientos, cabe destacar la técnica de planificación

Scrum, muy útil con sus iteraciones e historias de usuario. También ha sido

muy importante el diseño de clases inicial, ya que me ha facilitado todo el

trabajo de implementación posterior.

Otras técnicas más concretas que destacar son el uso de patrones de

diseño (sobre todo los patrones Singleton y Estrategia) y el uso de colecciones

de objetos, como los Dictionary o las SortedList.

8.2. Dificultades encontradas

Durante el transcurso del proyecto han surgido numerosos problemas,

que de cierta manera han afectado a la planificación inicial propuesta.

El primer obstáculo vino a la hora de implementar el sistema de

misiones, ya que fue más complejo de lo previsto el crear cada tipo de misión.

Por ello, se tuvo que optar por tener solo misiones de recolección y de

combate.




El siguiente inconveniente surgió al crear las interfaces, ya que tardé

más de lo planificado en acabar esta parte, lo que haría resentirse las

iteraciones posteriores.

Otro problema fue la parte de modelado y animación del personaje y los

enemigos, ya que la intención inicial era crearlos yo mismo, no pudiendo

hacerlo al final, debido a la falta de tiempo. Aun así, preferí coger modelos y

animaciones por separado, y hacer yo mismo los controladores y las máquinas

de estados, de manera que se adaptara a lo que yo necesitaba.

Algo similar pasó a la hora de crear los escenarios, tanto de la aldea

como de las misiones, ya que por falta de tiempo tuve que recurrir a assets de

terceros.

En todo lo demás, fue más o menos según lo previsto.

8.3. Resultados obtenidos

En cuanto al resultado final, me quedo bastante satisfecho, ya que he

obtenido una versión estable de un videojuego, objetivo al que pretendía llegar

en un principio.

Los aspectos más positivos que destaco son el sistema de misiones, que

permite añadir nuevas misiones de forma sencilla, así como nuevos tipos.

También resalto los sistemas de tienda y forja, ya que al final he conseguido

aplicarles una interfaz intuitiva y una gran utilidad.

En cuanto a aspectos negativos, destaco el control del personaje, así

como los combates. No he conseguido implementar un control fluido, debido a

la falta de tiempo principalmente. En cuanto a los combates, la inteligencia

artificial de los enemigos es demasiado simple y los ataques muy limitados.

Este sería un campo en el que dedicar bastante tiempo del desarrollo futuro.



9. TRABAJO FUTURO

Los aspectos en los que se podría trabajar a partir de ahora serían los

siguientes:

Más tipos de misiones: Añadir misiones contrarreloj, infinitas, de

exploración, etc.

Enemigos más variados: A partir de los que ya tenemos, añadir más

tipos de enemigos. También mejorar su inteligencia artificial, así como

sus movimientos.

Logros o trofeos: Implementar un sistema de recompensas por acciones

del jugador.

Estadísticas: Almacenar un historial con diferentes aspectos del juego,

como un contador de misiones, de enemigos derrotados, etc.

Añadir nuevos tipos de armas: Para ello habría que incluir nuevos

controladores, así como nuevas animaciones.



10. BIBLIOGRAFÍA

[1] Comparación entre motores gráficos: [http://www.fosfore-studios.com/que-

game-engine-elegir-para-el-desarrollo-de-un-videojuego/]

[2] Lenguajes de programación en Unity: [http://academiaandroid.com/scripts-

lenguajes-programacion-unity/]

[3] Explicación de la metodología SCRUM: [https://proyectosagiles.org/que-es-

scrum/]

[4] Información sobre Pivotal Tracker:

[https://www.adictosaltrabajo.com/tutoriales/pivotal-tracker/]

[5] Explicación de las funciones propias de Unity:

[http://www.hagamosvideojuegos.com/2014/02/unity3d-scripting-

monobehaviour.html]

[6] Documentación sobre la colección Dictionary:

[https://msdn.microsoft.com/en-us/library/xfhwa508.aspx]

[7] Información sobre cómo guardar y cargar partidas usando serialización:

[http://gamedevelopment.tutsplus.com/es/tutorials/how-to-save-and-load-your-

players-progress-in-unity--cms-20934]

[8] Explicación del patrón Singleton: [http://www.gamedev.es/unity3d-patrn-

singleton/]

[9] Explicación del patrón Estrategia: [http://www.dofactory.com/net/strategy-

design-pattern]

http://www.fosfore-studios.com/que-game-engine-elegir-para-el-desarrollo-de-un-videojuego/

http://www.fosfore-studios.com/que-game-engine-elegir-para-el-desarrollo-de-un-videojuego/

http://academiaandroid.com/scripts-lenguajes-programacion-unity/

http://academiaandroid.com/scripts-lenguajes-programacion-unity/

https://proyectosagiles.org/que-es-scrum/

https://proyectosagiles.org/que-es-scrum/

https://www.adictosaltrabajo.com/tutoriales/pivotal-tracker/

http://www.hagamosvideojuegos.com/2014/02/unity3d-scripting-monobehaviour.html

http://www.hagamosvideojuegos.com/2014/02/unity3d-scripting-monobehaviour.html

https://msdn.microsoft.com/en-us/library/xfhwa508.aspx

http://gamedevelopment.tutsplus.com/es/tutorials/how-to-save-and-load-your-players-progress-in-unity--cms-20934

http://gamedevelopment.tutsplus.com/es/tutorials/how-to-save-and-load-your-players-progress-in-unity--cms-20934

http://www.gamedev.es/unity3d-patrn-singleton/

http://www.gamedev.es/unity3d-patrn-singleton/

http://www.dofactory.com/net/strategy-design-pattern

http://www.dofactory.com/net/strategy-design-pattern



11. Anexo: Manual de usuario

11.1. Menú principal

Puedes escoger entre crear una nueva

partida, continuar una existente,

cambiar algunas opciones o ver los

créditos.

11.2. Pantalla de juego

Guardar los datos:

El juego guarda los datos automáticamente al cambiar de escena.

Indicador de salud: Se

agota al sufrir daños.

Puedes recuperarte usando

pociones y otros objetos

Acceso rápido a objetos:

Puedes usar objetos a la vez

que te mueves.



11.3. Controles

Controles del personaje:

Moverse: Teclas de dirección o stick izquierdo del joystick.

Correr: Tecla Q o botón 8 del joystick.

Atacar: Tecla D o botón 2 del joystick.

Bloquear: Tecla W o botón 1 del joystick.

Acceso rápido a objetos:

Abrir/cerrar el menú: Tecla X o botón 5 del joystick.

Moverse a izquierda/derecha: Teclas Z/C o botones 7/8 del joystick.

Tomar objeto: Tecla A o botón 4 del joystick.

Controles en los menús:

Moverse: Teclas de dirección o cruceta del joystick.

Seleccionar: Tecla S/Enter o botón 3 del joystick.

Pausa: Tecla Escape o botón 10 del joystick.

11.4. Consejos para la aventura

Habla con los aldeanos: Quizás

te den algún consejo que te ayude

en la aventura.



Recoge objetos: Te serán

útiles para poder fabricar

nuevas armas y equipo.

Consigue equipo nuevo:

Con los materiales que

obtienes puedes crear

armas y equipo mejores.

desarrollo de un videojuego - ujaen.estauja.ujaen.es/bitstream/10953.1/8455/1/memoria.pdf ·...

Documents