___________________________________
DISEÑO Y CREACIÓN DE UN
VIDEOJUEGO
___________________________________
ESCOLA TÈCNICA D’ENGINYERIA DE
TELECOMUNICACIÓ DE BARCELONA
UNIVERSITAT POLITÈCNICA DE CATALUNYA
GRAU EN ENGINYERIA DE TECNOLOGIES I SERVEIS DE
TELECOMUNCIACIÓ
Barcelona, Enero 2019
Autor:
Víctor Portabella de Pedro
Tutor:
Abstract
The video game industry is currently consolidated as one of the great innovations in the growth of Spanish economy, placing this sector among the main national digital content industries.
Videogames are specific software products, where concepts from very different fields are applied and mixed. We find professionals in the field of artificial intelligence, graphics design, mechanics programming, stage modeling, script, music, interface implementation, etc. The importance of understanding how each of these concepts is applied individually and in their relationship with the others is vital for a successful choice of the correct procedure to design and develop a video game.
It is for this reason that in this Project we have focused on analyzing some of the most relevant aspects in the creation of a videogame, in order to implement a functional prototype and document the process. Specifically, we have analyzed the work oriented to the field of design and development.
We have also decided to make a small study of some complementary concepts to the development of a software application. We have focused on backup control, studied product performance, explored the best strategies on bug management and contrasted the final product with the opinion of a user base external to the development process.
Resumen
La industria de los videojuegos se consolida actualmente como una de las grandes innovaciones del crecimiento de la economía española, situando este sector entre las principales industrias nacionales de contenido digital.
Los videojuegos son productos de software muy específicos, donde se aplican y mezclan conceptos de campos muy diferentes. Trabajan en ellos profesionales en el ámbito de la inteligencia artificial, el diseño gráfico, la programación de mecánicas, el modelado de escenarios, el guión, la música, la implementación de la interfaz, etc. La importancia de entender cómo se aplican cada uno de estos conceptos de forma individual y en su relación con los demás es vital para la elección del mejor procedimiento para el diseño y desarrollo de un videojuego.
Es por este motivo que en este Trabajo de Fin de Grado nos hemos centrado en analizar algunos de los aspectos más relevantes en el desarrollo de un videojuego, con el fin de implementar un prototipo funcional y documentar el proceso del mismo. En concreto, hemos analizado el trabajo orientado al ámbito de diseño y de programación.
También hemos decidido realizar un pequeño estudio de algunos conceptos complementarios al desarrollo de una aplicación de software. Nos hemos centrado en realizar un control de versiones, un estudio del rendimiento del producto, un análisis sobre la gestión de bugs y en contrastar el producto final con la opinión de una base de usuarios externos al proceso de desarrollo.
Resum
La indústria dels videojocs es consolida actualment com una de les grans innovacions de creixement de l‟economia espanyola, situant aquest sector entre les principals indústries nacionals de contingut digital.
Els videojocs són productes de software molt específics on s‟apliquen conceptes de camps molt dispars entre ells. Hi podem trobar professionals en l‟àmbit de la intel·ligència artificial, el disseny gràfic, la programació de mecàniques, el modelatge d‟escenaris, el guió, la música, la implementació de la interfície, etc. La importància d‟entendre com s‟apliquen cadascun d‟aquests conceptes de forma individual i la seva relació amb els demes és vital a l‟hora de triar el millor procediment per dissenyar i desenvolupar un videojoc.
És per aquest motiu que en aquest Treball de Fi de Grau ens hem centrat a analitzar alguns dels aspectes més rellevants en el desenvolupament d‟un videojoc, posant com a objectiu implementar un prototip funcional i document el procés de creació d‟aquest. En concret, hem analitzat el treball orientat a l‟àmbit de disseny i de programació.
També hem decidit realitzar un petit estudi d‟alguns conceptes complementaris al desenvolupament d‟una aplicació de software. Ens hem centrat a realitzar un control de versions, un estudi del rendiment del producte, un estudi sobre la gestió de bugs i en contrastar el producte final amb l‟opinió d„una base d‟usuaris externs al procés de desenvolupament.
Historial de revisiones y registro de aprobación
Revisión Data Objetivo0 10/12/2018 Creación del documento 1 19/12/2018 1ª Revisión del documento 2 9/01/2019 2ª Revisión del documento
3 24/01/2019 3ª Revisión y cierre del documento
Lista de Distribución
Nombre e-mail
Víctor Portabella de Pedro [email protected]
Josep Ramon Casas [email protected]
Escrito por: Revisado y aprobado por: Data 10/12/2018 Date 25/01/2019
Nombre Víctor Portabella Nombre Josep Ramon Casas Rol Autor del proyecto Rol Supervisor del proyecto
Tabla de Contenidos
Abstract ... 1
Resumen ... 2
Resum ... 3
Historial de revisiones y registro de aprobación ... 4
Tabla de Contenidos ... 5 Lista de Figuras ... 7 Lista de Tablas ... 9 1. Introducción ... 10 1.1. Declaración de objetivos... 10 1.2. Requerimientos y especificaciones ... 12 1.3. Intereses ... 13 1.4. Hitos ... 14
1.5. Diagrama de Gantt actualizado ... 15
2. Estudio de las tecnologías aplicadas ... 17
3. Desarrollo del proyecto ... 19
3.1. Documento de Diseño: ... 20
3.1.1. Economía Interna: ... 20
3.2. Desarrollo de The Dark Crown: ... 28
3.2.1. Personajes e Interacciones ... 28
3.2.2. UI Interactuable ... 37
3.2.3. Implementación del mundo ... 42
4. Ingeniería de software ... 48
4.1. Documentación del Control de Versiones ... 49
4.2. Estudio del Rendimiento de The Dark Crown ... 51
4.2.1. Introducción al estudio del rendimiento: ... 51
4.2.2. Análisis del rendimiento ... 53
4.3. Estudio de QA ... 57
4.3.1. ¿Cómo definir un bug? ... 57
4.3.2. Análisis de bugs ... 57
5. Sesiones de PlayTesting ... 61
5.1. Encuesta ... 62
5.3. Análisis de los Resultados ... 65 6. Presupuesto ... 66 7. Conclusiones ... 68 7.1. Conclusiones personales ... 68 7.2. Conclusión general ... 68 Bibliografía: ... 70 Apéndices: ... 71 Glosario: ... 72
Lista de Figuras
Figura 1.1 Diagrama de Gantt ... 16
Figura 2.1 Logo Unity ... 17
Figura 2.2 Logo Unreal Engine ... 18
Figura 3.1 CoreLoop ... 21
Figura 3.2 Gráfica Parámetros ... 24
Figura 3.3 Gráfica Relación Parámetros ... 24
Figura 3.4 Gráfica Progresión Jugador ... 26
Figura 3.5 Movimiento Personaje ... 29
Figura 3.6 Máquina de estados... 29
Figura 3.7 Objeto Cámara ... 30
Figura 3.8 Pantalla de Comandos Main Camara ... 30
Figura 3.9 Problema de oclusión ... 31
Figura 3.10 Solución problema de oclusión ... 31
Figura 3.11 Función RayCast ... 32
Figura 3.12 NavMesh y Triggers de detección ... 33
Figura 3.13 Trigger alrededor del arma ... 33
Figura 3.14 Encuentro con enemigo ... 34
Figura 3.15 Personaje atacando ... 35
Figura 3.16 Personaje defendiendose ... 35
Figura 3.17 Imagen UI de Parametros ... 36
Figura 3.18 Gestión de UI ... 37
Figura 3.19 Esquema Inventario ... 38
Figura 3.20 Inventario ... 38
Figura 3.21 Questlog ... 39
Figura 3.22 QuestGiverWindow ... 40
Figura 3.23 Animator Diálogo ... 41
Figura 3.24 Diálogo ... 41
Figura 3.25 Menú Mejoras ... 42
Figura 3.26 Pantalla de Comandos Enemy Trigger... 43
Figura 3.28 Diseño del nivel ... 45
Figura 3.29 Esquema Curso de Acción ... 46
Figura 3.30 Animation y Máquina de estados ... 47
Figura 4.1 Esquema Control Versiones ... 49
Figura 4.2 The Profiler Window... 53
Figura 4.3 CPU Usage en ejecución ... 53
Figura 4.4 Frame analizado ... 54
Figura 4.5 Jerarquía 1 ... 54
Figura 4.6 Jerarquía 2 ... 55
Figura 4.7 CPU Usage eliminando Agua de la escena ... 55
Figura 4.8 CPU Usage modificnado el agua de la escena ... 56
Figura 4.9 Escena con el agua modificada ... 56
Figura 4.10 Bug 1 ... 58
Figura 4.11 Bug 2 ... 59
Figura 4.12 Bug 3 ... 60
Lista de Tablas
Tabla 1.1 Milestones ... 14
Tabla 3.1 Tabla de Tokens ... 21
Tabla 3.2 Relaciones CoreLoop ... 22
Tabla 5.1 Resultados Encuesta... 63
Tabla 6.1 Man/Month Real ... 66
1.
Introducción
1.1. Declaración de objetivos
El proyecto “Diseño y Creación de un Videojuego” pretende enfocar el proceso de creación de un prototipo de videojuego totalmente funcional, dando énfasis en el estudio y el aprendizaje de sus diferentes partes.
Hemos de considerar que en un entorno profesional es habitual encontrar equipos de diez o más personas trabajando alrededor de 12-18 meses para producir un videojuego. En consecuencia, el objetivo principal de este proyecto no es tanto de producir un producto comercial viable, como el de conocer y estudiar todas las fases necesarias para llegar a generar uno.
Por lo tanto, los documentos y el prototipo que generaremos nos permitirán involucrarnos directamente en el estudio de sus diferentes partes, pero siempre daremos más importancia a las fases de estudio que al acabado comercial y artístico. Tendremos esto en cuenta en el momento de definir objetivos y distribuir los recursos.
Los objetivos principales sobre los cuales valoraremos los resultados al final del proyecto serán:
Creación de un HLDD: Como resultado del estudio del proceso de Diseño de un videojuego, realizaremos un High Level Design Document (HLDD). En este documento, se verán reflejadas aquellas decisiones que se han tomado a la hora de crear nuestro prototipo.
En el Apéndice 1. Pitch y en el Apéndice 2. HLDD encontraremos los documentos de diseño desarrollados en su totalidad
Creación de un Prototipo: Como resultado del estudio de la parte de Desarrollo, proponemos crear un prototipo funcional donde se ponga de manifiesto la comprensión de las diferentes técnicas utilizadas en el proceso de creación del mismo.
En el Apéndice 3. Repositorio del GitHub podemos encontrar un enlace que nos redirigirá a los archivos que contienen el código desarrollado durante el proyecto.
En el Apéndice 4. Ejecutable del Prototipo podemos encontrar un ejecutable que nos facilitará acceder a la última versión del prototipo desarrollado.
Además de los objetivos definidos anteriormente, daremos importancia a algunos aspectos que consideramos de especial interés a la hora de desarrollar un proyecto de software en este ámbito.
Control de Versiones: Analizaremos como gestionar la progresión en el desarrollo del software del trabajo, de forma que trabajemos con una metodología segura y profesional de control de versiones durante el desarrollo.
Estudio de Rendimiento: En productos software como los videojuegos, la fluidez del software es vital para conseguir una respuesta que sea agradable al jugador. Realizaremos un pequeño estudio donde podamos detectar posibles problemas y determinar si el rendimiento del prototipo es el adecuado.
Estudio de QA: Al realizar un trabajo de desarrollo de software, es importante reservar un tiempo orientado a buscar y arreglar posibles bugs. Veremos el procedimiento para poder definirlos de forma ordenada y sistemática.
Resultados Contrastados: Al tratarse de un producto de entretenimiento orientado al público, probaremos el resultado final en sesiones de juego donde recoger las opiniones de usuarios externos al desarrollo del mismo.
Hemos incluido un Glosario al final del trabajo donde se definen algunos conceptos para facilitar al lector la comprensión del proyecto. Los conceptos que se puedan consultar en este glosario estarán marcados mediante un asterisco (*).
1.2. Requerimientos y especificaciones
Requerimientos del proyecto:
Estudio del diseño:
o Plan de diseño detallado. Estudio del desarrollo:
o Prototipo funcional e interactuable. Análisis de conceptos complementarios:
o Control de versiones. o Control del Rendimiento. o Gestión de Bugs.
o Valoración externa.
Especificaciones del proyecto:
Prototipo con rendimiento superior a 60FPS*.
Con el fin de desarrollar el prototipo correctamente, será necesario disponer de un equipo con unas especificaciones concretas:
o OS: Windows 7 SP1+, 8, 10, únicamente versiones de 64 bits; macos 10.11+
o CPU: Soporte para el conjunto de instrucciones SSE2
o GPU: Tarjeta de video con capacidad para DX10 (shader modelo 4.0) Con el fin de ejecutar el prototipo correctamente, será necesario disponer de un
equipo con unas especificaciones concretas:
o OS: Windows 7 SP1+, macos 10.11, Ubuntu 12.04+, SteamOS+ o Tarjeta de video con capacidad para DX10 (Shader modelo 4.0). o CPU: compatible con el conjunto de instrucciones SSE2
Para gestionar el control de versiones, será necesario: Cuenta en GitHub
1.3. Intereses
Este proyecto se ha realizado bajo la supervisión del profesor Josep R. Casas del Grupo de Procesado de Imagen de la Universidad Politécnica de Cataluña.
La idea del proyecto nace de intereses propios del autor. Con intención de desarrollarse profesionalmente en el sector de desarrollo de juegos electrónicos, la oportunidad de realizar un proyecto centrado en este ámbito otorga la opción de iniciarse en el estudio y la investigación tanto de los procedimientos como de las tecnologías aplicadas actualmente.
El videojuego creado lo hemos titulado The Dark Crown y se trata de un juego RPG* (Role Play Game) con una cámara en 3 persona. Se trata de un proyecto nuevo e independiente que no continúa con la base académica ni con el framework desarrollado en ningún proyecto del departamento realizado anteriormente.
1.4. Hitos
Establecer una buena planificación, así como una buena metodología de trabajo, ha sido vital para poder llevar a cabo el proyecto con éxito. Hemos definido un conjunto de hitos o milestones en los cuales nos hemos basado para organizar el conjunto de trabajo. Estos milestones han sido los siguientes:
Título Milestone / entregable Fecha Planteamiento /
Propuesta y Plan de Trabajo
State of the art, planteamiento del proyecto y organización de los puntos a desarrollar 05/10/2018 Baseline / Revisión Crítica
Primera versión base del Diseño, el Desarrollo y la Validación y Pruebas
30/11/2018
Modelo Final Versión final del Diseño, el Desarrollo y
la Validación y Pruebas
10/1/2019
Tabla 1.1 Milestones
Para poder organizar el trabajo, destacamos el milestone correspondiente a la revisión crítica, donde establecemos que queremos tener la primera versión del prototipo con el fin de poder valorar donde dedicar los recursos restantes de cara a la entrega final. Con estos milestones claros, pudimos hacer una planificación de tiempo genérica, en la que establecíamos de forma aproximada cuanto tiempo dedicar a cada apartado del proyecto.
Esta planificación nos permitió establecer un Backlog aproximado de las tareas a realizar y una fecha límite para completarlas.
De cara a la metodología de trabajo, establecimos un sistema de Sprints [18] de corta duración, es decir, asignar tareas para un periodo de tiempo corto y realizar un control efectivo sobre las mismas.
Esta metodología la cumpliríamos estableciendo reuniones cada dos semanas en las que se realizaba una evaluación del trabajo completado durante el último Sprint, se revisaban las tareas prioritarias y se asignaba trabajo para el próximo Sprint.
Con este sistema, intentamos asegurar un ritmo de trabajo constante y controlado. En caso de surgir algún problema o contratiempo, se detectaría cuando aun no tuviera mucha repercusión y se podría actuar rápidamente en consecuencia. Además, fomenta la comunicación y el feedback sobre el trabajo realizado en cada uno de los Sprints.
1.5. Diagrama de Gantt actualizado
Esta sección analiza con retrospectiva los aspectos y objetivos establecidos temporalmente en el Diagama de Gantt, teniendo en cuenta los cambios sufridos y los ajustes realizados a lo largo del proyecto. En la Figura 1.1 podemos ver este Diagrama de Gantt actualizado al final del mismo.
El proyecto empezó en el mes de julio con dos semanas dedicadas a la investigación, donde se decidió que motor de videojuegos se iba a utilizar y se estudiaron las bases para aprender a utilizarlo.
Hemos de tener en cuenta que diseño y desarrollo han ido de la mano al largo de todo el proyecto, repartiendo el tiempo de tal forma que fuera posible trabajar en ambos aspectos del trabajo.
De esta forma, se dedicó un mes a especificar el concepto del prototipo y definir los pilares básicos sobre los que se basaría el diseño de todo el juego y dos meses y medio más a especificar todos los detalles que contendría.
Durante este tiempo, el apartado de desarrollo se ha subdividido en tres apartados concretos:
El desarrollo de las mecánicas. El desarrollo de la interfaz y el menú. El desarrollo de niveles.
La mayor parte de los recursos se dedicaron al desarrollo de las mecánicas sobre las que se ha completado el juego. Esto ha ocupado un total de dos meses y medio. Después, una semana dedicada a la implementación del menú. Con todo esto desarrollado, se dedicó un mes más a darle forma, acabar de pulir los detalles y crear el diseño de niveles. Finalmente, teníamos la primera versión del prototipo acabada.
Aquí nos encontramos con el milestone principal que nos ha servido para guiar el proyecto, cumpliendo con lo establecido de tener el prototipo listo para el 30 de noviembre.
Después de este milestone, se centraron los recursos en ordenar y documentar correctamente el proceso de creación del documento de diseño.
Con esta organización del tiempo, tuvimos tiempo de desarrollar los aspectos secundarios. Llegados a este punto, dimos prioridad a documentar el control de versiones, realizar un estudio del rendimiento que mejoró la fluidez del juego y realizar un control de QA mediante el cual se detectaron y consiguieron solucionar algunos bugs tanto de código como de físicas de los objetos virtuales.
Con estos aspectos desarrollados, procedimos a finalizar el último objetivo secundario, en el cual buscamos realizar sesiones de juego con usuarios externos al desarrollo del producto con el fin de obtener un resultado objetivo, y luego procedimos a analizar todo el proyecto en conjunto para establecer unas conclusiones.
Respecto a la organización inicial, hemos sido fieles a los bloques definidos al principio del proyecto. Los principales cambios han estado relacionados con la planificación temporal de estos. De esta forma, la documentación del diseño y las pruebas de bugs se han pospuesto a posteriori del milestone principal del 30 de noviembre.
2.
Estudio de las tecnologías aplicadas
Antes de empezar, vamos a realizar un estudio sobre las tecnologías más destacadas que utilizaremos a lo largo del trabajo. Es preciso enfatizar que nos centramos en las herramientas utilizadas en el apartado de programación. Como el trabajo no se centra en desarrollar el arte de un videojuego, no hablaremos de programas utilizados por estos equipos como podrían ser 3DMax, Marmoset o Photoshop. Por el contrario, hemos de destacar la importancia de los motores de videojuegos y escoger cual utilizaremos. En este apartado explicaremos brevemente qué realizan estos frameworks, la importancia de su decisión y por cual nos hemos decantado para hacer este proyecto.
¿Qué es un motor de videojuegos?
Se define como motor gráfico el conjunto de herramientas de desarrollo visual y componentes de software diseñadas para crear y desarrollar videojuegos. Estos se caracterizan por ofrecer un motor gráfico y un motor físico, que nos permiten entre otras cosas tratar el aspecto visual del videojuego, simular colisiones, gravedad, fuerzas, etc. En general, podemos decir que nos facilita la tarea de crear un videojuego. Aunque muchas empresas disponen de sus propios engines privados, los videojuegos Indie* y los desarrolladores independientes han dado paso a la existencia de otros muchos motores muy competentes de libre acceso.
Entre ellos, podemos destacar Unity y Unreal Engine 4 (UE4). Cada uno tiene una serie de ventajas e inconvenientes que debemos considerar.
Unity3D:
Unity3D es un motor de videojuegos muy orientado a ser utilizado por desarrolladoras indies y pequeñas empresas.
Sin disponer de un motor gráfico tan potente como el que podríamos encontrar en UE4, destaca por la gran cantidad de documentación que dispone [12] [14], así como por la gran cantidad de material de aprendizaje que se puede encontrar fácilmente. [9] [10] [11] Al generar código en Unity3D podemos decantarnos por un lenguaje de programación C# o JavaScript.
Otra de las características más atractivas de Unity3D es la Asset Store [16], una tienda de assets* en la cual podemos encontrar muchos objetos modelados y animados que se ofrecen de forma gratuita al usuario o por un precio asequible.
Unreal Engine 4:
Al hablar de Unreal Engine 4 (UE4) hay que destacar su increíble motor gráfico, ofreciendo unas características muy superiores a las de Unity. Tiene capacidad para gestionar iluminación dinámica, gestionar de forma muy eficiente grandes cantidades de partículas y muchas herramientas que son de gran ayuda a diseñadores y artistas. El lenguaje de programación de UE4 es C++ y ofrece un sistema de programación mediante Blueprints, cajas de código que nos permiten iteración rápida de gameplay*. Sin embargo, la curva de aprendizaje es más compleja y se trata de un engine más orientado a ser utilizado por equipos más grandes y producir juegos más exigentes, tanto a nivel técnico cómo visual.
Figura 2.2 Logo Unreal Engine
Elección de motor
Por las razones expuestas anteriormente, nos decantamos por Unity3D para realizar el proyecto. Damos prioridad a la facilidad de acceder a documentación y una curva de aprendizaje más suave por encima de las características gráficas que podríamos encontrar en UE4.
Al tratarse de un proyecto realizado por una sola persona, en la que se resta importancia al apartado visual, consideramos adecuado decantarnos por el desarrollo en dicho motor.
3.
Desarrollo del proyecto
Nos encontramos en uno de los apartados principales del documento, donde procederemos a explicar cómo se ha realizado el diseño y desarrollo del proyecto.
Dividimos esta explicación en las siguientes dos secciones: Documento de Diseño
3.1. Documento de Diseño:
Uno de los objetivos de este proyecto es realizar un documento de diseño en el que se especifiquen los conceptos básicos a desarrollar en el juego.
En el momento de realizar el estudio del diseño, nos encontramos con la necesidad de realizar dos documentos diferentes:
Pitch: Es el documento que expresa brevemente el high concept del juego, donde se refleja la idea principal del mismo. Se trata de un documento esquemático que se ha de poder leer rápido y tener una idea clara de que juego se quiere realizar.
HLDD: En el High Level Design Document (HLDD) entramos en un nivel más detallado del diseño del juego. Incluiremos explicaciones para el lector y ofreceremos una visión general de todo el sistema, identificando los componentes principales a desarrollar tanto para el producto final como para la interfaz del mismo. [1] [6]
Podemos encontrar estos documentos en el Apéndice 1. Pitch y en el Apéndice 2.
HLDD, respectivamente.
A continuación, introducimos alguno de los apartados destacados del HLDD, para ilustrar como se han definido los ajustes relacionados con la Economía Interna del juego:
--- 3.1.1. Economía Interna:
La mayoría de las reglas de un juego son parámetros numéricos. Cuando hablamos de la Economía Interna, nos referimos a las relaciones que mantienen estos parámetros entre ellos y como han sido definidos para conseguir una configuración divertida del juego.
Realizamos un procedimiento diferenciado en tres apartados: Tabla de Tokens
Core Loop
Ajuste de Parámetros
1. Tabla de Tokens:
Estudiamos los diferentes elementos que podemos encontrarnos en el juego y la relación directa entre ellos:
Lista de Tokens: Player Enemigo Npc*: Personaje no jugador Mundo PlayerCombo
Item*: Objeto que aporta una función temporal al jugador
A continuación realizamos la Tabla 3.1 donde podemos ver las reacciones del juego ante la colisión de estos elementos. Respondemos a la pregunta: “¿Qué sucede si X coincide
con Y?”. De esta forma conseguimos una visión esquematizada de la normativa y las interacciones de elementos durante el juego.
Player Enemigos Npc's Mundo PlayerCombo Item Player x Combate -> Matar enemigo Conversación o Quest COLDET (Colisión/Detecc ión) x Coger Item Enemi go Combate ->
Matar Player Nada Nada
COLDET (Colisión/Detecc
ión)
Nada (No matar PlayerCombo) Nada Npc Conversación o Quest Nada x COLDET (Colisión/Detecc ión) Conversacion x Mundo COLDET (Colisión/Detecc ión) COLDET (Colisión/Detecc ión) COLDET (Colisión/Detecc ión) x COLDET (Colisión/Detecci ón) x Player Combo x Combate ->
Matar enemigo Conversación
COLDET (Colisión/Detecc
ión)
x Coger
Item
Item Coger Item Nada x x Coger Item x
Tabla 3.1 Tabla de Tokens
2. CoreLoop:
Analizamos los bucles del juego en la Figura 3.1. En cada bucle, podemos ver qué valores o recursos ganas y pierdes. Tener una visión clara del diagrama o bucle central del juego nos proporciona la comprensión necesaria para poder ajustar los parámetros a nuestro gusto.
Figura 3.1 CoreLoop
Obtenemos un bucle de juego parecido al de los juegos RPG. Este bucle se caracteriza por la iteración de vencer enemigos y completar misiones para conseguir recompensas. Llegado cierto punto de recompensas, se permite subir de nivel. Podemos ver que derrotar enemigos requiere tener un cierto nivel de Vida, Energía y Ataque.
Añadimos variantes según la normativa del juego. Al morir, el jugador puede invertir el oro ganado durante la partida para mejorar la Vida, Energía y Ataque.
Podemos ver que, en cada parte de la iteración, el jugador puede ganar o perder recursos.
En la Tabla 3.2 se muestra de forma sintetizada la relación entre ellos:
1
Vida, Energía y Ataque necesarios para matar enemigos o completar misiones
2 Experiencia y oro otorgado por los enemigos y misiones
3 Experiencia necesaria para subir de nivel
4 Vida, Energía y Ataque conseguidos al subir de nivel
5 Oro necesario para mejora
6 Vida, Energía y Ataque conseguidos por mejora
Tabla 3.2 Relaciones CoreLoop
Trabajando con estos parámetros, ajustar la dificultad del juego resulta una tarea más sencilla.
Por ejemplo, si quisiéramos aumentar la dificultad podríamos tanto aumentar la Vida, Energía y Ataque que necesitamos para vencer enemigos como reducir el Oro y la Experiencia que obtenemos al hacerlo. Del mismo modo, reduciendo la Experiencia necesaria para subir de nivel podríamos reducir el nivel de dificultad.
3. Ajuste de Parámetros:
De acuerdo con los esquemas y relaciones obtenidas a lo largo de este apartado, nuestro objetivo será ajustar los parámetros para conseguir una experiencia divertida. Enfatizamos la importancia de la Calidad frente a la Cantidad de parámetros, siendo mucho más sencillo conseguir una experiencia de juego agradable si tenemos pocos parámetros a ajustar pero una relación clara entre ellos.
Diferenciaremos entre tres grupos de parámetros a ajustar, los cuales estudiaremos a continuación:
Vida, Ataque y Energía. Experiencia y Level Up. Oro y Improvement
3.1. Vida, Ataque y Energía:
Siguiendo esta estrategia, generamos un modelo matemático que se adapte a la experiencia que queremos transmitir:
Primero pensamos en las relaciones básicas que queremos cumplir: Ataque jugador - Vida Enemigo
Ataque Enemigo - Vida jugador
Energía jugador - Número de enemigos
Buscamos un punto de referencia para modelar estas relaciones. Decidimos que queremos que el jugador derrote al enemigo débil con tres golpes (Recordemos que hay dos tipos de enemigos principales: enemigo débil y enemigo fuerte). Estos tres golpes modelan el combo principal del jugador.
Para simplificar al máximo los números, asignamos: Vida Enemigo: 3
Ataque Jugador: 1
De la misma forma, decidimos que al recibir cuatro golpes el jugador pierde: Vida Jugador: 4
Ataque Enemigo: 1
Finalmente decidimos que nuestro jugador podrá enfrentarse fácilmente a dos enemigos a la vez. Por lo tanto, tiene que poder dar los 6 golpes antes de quedarse sin energía. Suponemos que cada golpe gasta uno de energía y asignamos:
Energía Jugador: 6
Con esto podemos establecer las relaciones básicas entre los parámetros en un nivel del personaje concreto. Ahora, ¿Cómo definimos la progresión del personaje al subir de nivel y como se plasmará y transmitirá en el juego?
Queremos mantener la relación anterior, la cual hemos definido para hacer divertido el juego. Pero si siempre se mantiene la misma relación, no habrá sensación de mejora al subir de nivel y el juego se volvería plano y aburrido.
Para solucionarlo, permitimos la posibilidad de que el jugador encuentre a la misma clase de enemigo (enemigo débil) tanto de su nivel, como superior o inferior. En concreto:
Enemigo mismo nivel: 80% probabilidad. Enemigo nivel superior: 10% probabilidad. Enemigo nivel inferior: 10% probabilidad.
Mostramos el nivel del enemigo por pantalla de forma que el jugador siempre sabe de qué nivel es su enemigo. Continuamente se está comparando contra enemigos más fuertes y más débiles, de forma que se mantiene está sensación de progresión a la vez que pivotamos sobre la relación de parámetros principal que hemos definido.
Cada vez que se sube de nivel, se multiplica la vida y el ataque por dos, y se suman tres unidades de energía. De esta forma, la relación establecida entre los parámetros al confrontar enemigos de un nivel diferente queda definida como:
Contra enemigos más fuertes es necesario aplicar dos veces la combinación de ataque básica.
Contra enemigos más débiles, no hace falta aplicar la combinación entera. A medida que se aumenta de nivel, el jugador puede hacer frente a más
De esta forma, en el gráfico de la Figura 3.2 podemos ver como evoluciona exponencialmente el valor de los parámetros pero, sin embargo, la gráfica de la Figura 3.3 nos demuestra que siempre conservamos la relación deseada entre ellos:
Figura 3.2 Gráfica Parámetros
Figura 3.3 Gráfica Relación Parámetros
0 500 1000 1500 2000 2500 0 5 10 15 Val o r Nivel
Parámetros
Vida Jugador: Ataque Jugador: Energía Jugador:Vida Enemigo Débil:
Ataque Enemigo Débil: 0 1 2 3 4 5 6 7 0 5 10 R e lac ió n Nivel
Relación parámetros diferente
Nivel
Vida Enemigo Débil / Ataque Jugador
Vida Enemigo Débil Nivel Superior / Ataque Jugador Vida Enemigo Débil Nivel Inferior / Ataque Jugador
Ya tenemos el modelo matemático generado a partir del combate básico: Vida Jugador: 3*2^(Nivel – 1)
Ataque Jugador: 1*2^(Nivel – 1) Energía Jugador: 6 + 3*(Nivel-1) Vida Enemigo Débil: 3*2^(Nivel – 1) Ataque Enemigo Débil: 1*2^(Nivel – 1)
Ahora bien, esta estrategia sigue transmitiendo una sensación de progresión limitada. Por más que avancemos, la relación será la misma. Es por esta razón que creamos un segundo tipo de enemigo, que llamaremos Enemigo Fuerte. Llegados a este punto, ¿Qué queremos transmitir?
Cuando aparece el segundo enemigo, el jugador ya ha realizado cierta progresión. En consecuencia, cuando cambia el entorno, se le induce a pensar “Este ya es un momento importante”. Para realizar esta sensación de combate importante, buscaremos alargar el tiempo de combate. Como es un combate importante, ya no puede ganar en 3 golpes. Es por eso que podemos transmitir fácilmente esta sensación limitándonos a aumentar la vida del enemigo. Esto hace que el combate sea más largo y satisface las expectativas del jugador.
Vida Enemigo Fuerte: 9*2^(Nivel – 1) Ataque Enemigo Fuerte: 1*2^(Nivel – 1)
3.2. Experiencia y Level Up
Otro factor importante a considerar es cuanta Experiencia necesita reunir el jugador para subir de nivel. Este es uno de los factores principales que nos indicará la progresión del jugador dentro del juego, así como la curva de dificultad del mismo [7].
Podemos aplicar diferentes progresiones, por ejemplo aritméticas o exponenciales. Es común diseñar un sistema que permita conseguir los primeros niveles relativamente rápido y que presente una curva de dificultad adecuada, de forma que cada vez sea más difícil subir de nivel y progresar. En este sentido, parece que una curva exponencial se adecúa a lo que deseamos implementar por encima de una progresión aritmética. Sin embargo, esta estrategia puede acabar en incrementos astronómicos a niveles elevados, pudiendo crear una sensación de frustración y desmotivación en el jugador.
Se ha comprobado que una progresión de Fibonacci [13] [17] tiende a dar buenos resultados, teniendo una curva parecida a la exponencial pero sin llegar a tener unos incrementos tan exagerados a niveles elevados. La relación que proporciona está progresión entre la experiencia necesaria entre un nivel y el siguiente produce una buena respuesta por parte de los jugadores.
Figura 3.4 Gráfica Progresión Jugador
La elección de un sistema por encima de otro resulta al final de una cuestión muy personal, pudiendo variar dependiendo de las sensaciones que se quieran transmitir al jugador. Los puntos expuestos anteriormente hacen que nos decantemos por implementar el sistema de Fibonacci.
Llegados a este punto hemos implementado numéricamente todos los parámetros del CoreLoop interno de una partida. En este punto, solo restaría regular el bucle de juego referenciado a la “muerte” del jugador; hemos definido que al morir el jugador puede invertir el oro gastado para mejorar sus parámetros tales como la Vida, la Energía y el Ataque.
La implementación de este bucle nos permite tanto transmitir la sensación de personalización del personaje por parte del jugador como evitar el estancamiento de este en alguna zona del juego y, en consecuencia, su posible frustración. Cada vez que el jugador piedra en algún punto de la partida, volverá con el personaje más fuerte y será más fácil de superar.
3.3. Oro y Improvement
Si revisamos el CoreLoop definido anteriormente (Figura 3.1), vemos que para definir este bucle hemos de decidir dos factores: Cuanto Oro necesita el jugador para mejorar los parámetros del personaje y cuánto mejoran estos.
Respecto al oro, en este caso hemos aplicado la progresión exponencial, haciendo que cada vez cueste el doble que la anterior, empezando por un valor de 10. De esta forma, favorecemos que el jugador tienda a tener un personaje equilibrado en todos los parámetros a mejorar.
Respecto a la mejora numérica de los parámetros nos encontramos con un problema particular. Como hemos aplicado una progresión exponencial de la Vida, Energía y Ataque en la subida de nivel del personaje, cada vez que el jugador muera y quiera
0 200 400 600 800 1000 1200 1400 1600 1800 0 2 4 6 8 10 12 Exp e ri e n ci a Nivel
Progresión del jugador: Experiencia
necesaria para subir de nivel
Fibonacci: Exponencial: Aritmética:
invertir Oro en mejorarlos, los valores base de los mismos podrían variar mucho. Es decir, si mejorar en 10 puntos ahora podría ser mucho, la siguiente vez podría ser muy poco. En consecuencia, y con el fin de favorecer que el jugador no se quede estancado en ningún sitio del juego, definimos un incremento proporcional de estos, de modo que tras cada inversión mejoran un 10%. De esta forma, no importa el nivel base del jugador que la mejora aplicada siempre será notoria.
3.2. Desarrollo de The Dark Crown:
En este apartado de implementación, veremos cómo se ha ejecutado el desarrollo del proyecto en alto nivel. Incluiremos una pequeña explicación de aquellos puntos interesantes, ya sea para entender cómo funciona el motor de videojuegos escogido como para explicar la solución aplicada a problemas técnicos que han ido surgiendo a lo largo del proyecto.
El apartado se distribuirá en los siguientes puntos: Personajes e Interacciones
UI* Interactuable
Implementación del mundo
3.2.1. Personajes e Interacciones
Nos encontramos al principio del desarrollo del juego. Antes que nada, nos centraremos en desarrollar las mecánicas relacionadas con el personaje principal, como se ve en pantalla, su movimiento y las relaciones que puede tener con personajes enemigos. Este apartado se desarrollará siguiendo los siguientes puntos:
Personaje: Movimiento / Máquina de estados Cámara
Enemigo: Movimiento / IA* (Inteligencia Artificial) Combate
Gestión de Parámetros
3.2.1.1. Personaje: Movimiento / Máquina de estados
Lo primero que trabajamos al empezar el proyecto es la implementación del personaje. Importamos un asset animado que cumpla con nuestras expectativas estéticas y lo incluimos en la escena. Llegados a este punto, hemos de solucionar dos frentes diferentes: ¿Cómo hacemos que se mueva por la escena y como hacemos que ejecute la animación correcta en la situación adecuada?
Mediante un script* creamos el controlador que nos permitirá recoger el Input del jugador. De esta forma, cada frame consecutivo comprobamos si el jugador pulsa alguna tecla de las establecidas (WASD) y de ser así, movemos el personaje como indica el jugador. En la Figura 3.5 podemos ver el personaje principal instanciado en el panel de control de Unity:
Figura 3.5 Movimiento Personaje
Para ejecutar la animación correcta Unity trabaja con máquinas de estados. Cada estado corresponde a una animación diferente y podemos declarar condiciones para cambiar de un estado al siguiente. Podemos declarar tanto Triggers, Booleans, Integrers o Floats, dependiendo de la condición que queramos cumplir.
En la Figura 3.6 podemos ver los diferentes estados definidos para el movimiento principal del personaje jugador. A medida que añadamos animación de ataque o defensa, deberemos introducir sus correspondientes estados en esta máquina de estados para determinar cómo se relacionan y las condiciones necesarias para activarlos.
Conociendo esto, establecemos las diferentes relaciones entre estados de forma que si el jugador presiona la tecla W, el personaje correrá (movimiento hacia delante) y si picamos la tecla S, el personaje caminará (movimiento hacia atrás). Modificamos la
velocidad de movimiento para que se ajuste a la animación y proporcione una sensación verosímil.
3.2.1.2. Cámara
Uno de los problemas más interesantes a los que nos enfrentamos al principio del proyecto es el de establecer una cámara funcional. Unity contiene un objeto Camara que nos enseñará por pantalla lo que está enfocando. Nuestro objetivo en este caso es el de crear un script que defina qué es lo que ha de enfocar la cámara en cada frame.
Como en el documento de diseño hemos establecido que queremos implementar una cámara fija detrás del jugador, procedemos a detectar una posición concreta detrás de la posición del personaje dependiendo de ciertos parámetros, entre los que podemos destacar: la distancia del jugador a la cámara, el ángulo con el que se posiciona la cámara respecto al personaje y la altura extra que insertamos para descentrar al personaje de la pantalla.
Establecemos todos estos parámetros públicos para poder configurarlos desde la pantalla de comandos, de forma que sea más fácil e intuitivo establecer el enfoque deseado. En las Figuras 3.7 y 3.8 podemos ver el resultado obtenido:
Figura 3.7 Objeto Cámara
En este punto, tenemos una cámara satisfactoria, pero nos encontramos con un grave problema. Si un objeto, por ejemplo un árbol o una casa, se sitúa entre nuestro personaje y la posición de la cámara, ocluirá por completo la visión de nuestro personaje jugador. Lo que es peor, podría ser que la posición de la cámara acabara dentro de algún otro objeto, rompiendo por completo la sensación de inmersividad que queremos transmitir al jugador.
En la Figura 3.9 podemos ver representado este problema. En la pantalla superior vemos la posición de la cámara y la pantalla inferior representa lo que estaría viendo el jugador.
Figura 3.8 Pantalla de Comandos Main Camara
En este caso, podemos comprobar que la cámara está situada detrás del cubo blanco y el jugador resulta totalmente ocluído en la vista de la cámara.
Para solucionarlo, hemos de detectar constantemente si la línea recta que une el jugador y la cámara está libre y, en caso de no estarlo, recolocar la cámara en la posición libre más cercana posible. Con el fin de conseguir ambos objetivos, trabajamos con la función Raycast, proyectando un “rayo” de la posición del jugador a la posición de la cámara. Esta función nos devolverá true o false dependiendo de si encuentra alguna colisión. En caso de detectarla, podemos recuperar la información del punto de colisión. Esto nos es de gran ayuda ya que este punto corresponde a una posición delante del objeto oclusor donde querríamos posicionar la cámara, solucionando de esta forma los dos problemas a la vez.
Podemos ver la solución satisfactoria en la Figura 3.10. En la misma situación anterior, la cámara ahora detecta la oclusión y se sitúa en consecuencia para conseguir un ángulo de visión del personaje, quizás más cercanos que el habitual, pero funcional.
Figura 3.9 Problema de oclusión
Figura 3.11 Función RayCast
3.2.1.3. Enemigo: Movimiento / IA
Para crear un enemigo, utilizamos un procedimiento parecido al ejecutado al crear el jugador. Buscamos un asset adecuado, lo importamos, y creamos la máquina de estados de las animaciones. La diferencia en este caso es que no hemos de recoger inputs del teclado para ejecutar su movimiento, sino que ha de hacerlo de forma automática en función de la posición del jugador.
Los problemas a los que nos enfrentamos en este apartado son: Como sabe el enemigo la posición del jugador.
Como sabe qué camino tomar.
Como sabe cuando acercarse al jugador.
Respecto a la posición del jugador, no encontramos demasiados problemas. Simplemente proporcionamos al objeto enemigo una referencia de nuestro objeto personaje jugador, de forma que pueda obtener en todo momento su posición.
Ahora bien, aunque sepa su posición, ¿cómo sabe el objeto enemigo qué camino tomar sin, por ejemplo, atravesar un árbol, una casa, o simplemente no detectar un desnivel y caminar por el aire?
Unity nos permite crear un objeto NavMesh a partir de la geometría del nivel, recogiendo las mallas y los terrenos a renderizar de todos los objetos del juego y procesarlos para crear una malla de navegación que se aproxima a las superficies transitables del nivel. De esta manera, definiendo nosotros parámetros como cuanto margen queremos dejar alrededor de un objeto o que desnivel puede superar, obtenemos el espacio “libre” por el cual el enemigo tendrá libertad de movimiento. Esta es una herramienta muy útil de cara a crear la IA de los personajes no jugadores.
Podemos ver en la Figura 3.12 el terreno azul correspondiente a las zonas transitables por los enemigos. Como podemos comprobar, el enemigo no puede superar el desnivel y, como hemos dicho anteriormente, definimos un margen de espacio alrededor de los obstáculos del terreno.
Si lo dejáramos aquí, tendríamos un conjunto de enemigos que podrían acercarse a nosotros caminando y lo harían por el camino correcto, ¡pero nada más ejecutar el juego vendrían todos corriendo a la vez hacia nuestra posición!
Desde luego no deseamos eso. A continuación creamos un par de triggers circulares de acuerdo a los definidos en el HLDD. Cuando el jugador atraviese el más pequeño, lo activará y el enemigo lo perseguirá. Cuando salga del radio del más grande, habrá salido del rango de visión, y el enemigo volverá a su posición inicial. En la misma Figura 3.12 podemos ver estos dos triggers en forma de círculos verdes concéntricos.
Figura 3.12 NavMesh y Triggers de detección
3.2.1.4. Combate
En este punto, estamos listos para implementar el sistema de combate. Este apartado es relativamente complejo a nivel de código, así que procedemos a explicar el comportamiento de forma simplificada.
Desde el punto de vista del personaje, establecemos que realice la animación de atacar al recibir un input del jugador, por ejemplo un clic del ratón. Para saber en qué momento exacto el jugador golpea al enemigo, hemos de crear un trigger alrededor del arma. (Figura 3.13) De esta forma, sabremos cuando golpeamos al enemigo. Ahora bien, debemos tener en cuenta que este trigger nos devolverá un valor por frame. A lo largo de un mismo golpe, el arma puede estar en contacto con el enemigo durante muchos frames consecutivos. Esto provocaría que realizaríamos un solo golpe y actuaría como si hubiéramos dado unos 60 a la vez. Tendremos que limitar a un golpe por animación. Otro aspecto que hemos de considerar es que queremos afectar a la vida del enemigo sólo mientras estemos ejecutando la animación de ataque. No nos sirve caminar alrededor del enemigo, colisionar sin querer con el arma, y provocarle daños.
Juntando todos estos puntos, diseñamos el modelo de forma que: Detecte cuando ejecuta la animación y cuando deja de ejecutarla.
Durante la animación, detecte cuando la espada colisiona con el enemigo.
Cuando la espada colisiona con el enemigo, bloquee la función hasta que se acabe la animación y se realice el siguiente ataque.
Figura 3.13 Trigger alrededor
Además, lo diseñamos de tal forma que si el jugador vuelve a clicar el botón de ataque justo después de realizar la primera animación de ataque, realizará una segunda animación que se compone de dos golpes, por lo que modificaríamos el código en este caso para poder causar daño dos veces consecutivas.
Podemos ver que los sistemas de combate con colisiones físicas cercanas provocan ciertas complejidades a nivel inferior. Como apunte interesante, en otros subgéneros de videojuego como los shooters* esta complejidad disminuye significativamente.
Reproducimos este comportamiento en el enemigo de forma que cada cierto tiempo realice la animación de atacar. Definimos dos animaciones diferentes para provocar variedad.
También definimos un sistema de defensa con el clic derecho del ratón, que hace aparecer un escudo en forma de esfera y protege al jugador. En caso de recibir un golpe en este estado, el jugador no sufrirá daño. La complejidad en este caso viene definida por el tiempo que podemos tener el escudo activado y cuanto tiempo hemos de esperar para activarlo nuevamente.
Las Figuras 3.14, 3.15 y 3.16 muestran una secuencia del personaje acercándose a un enemigo y realizando una acción de ataque y una acción de defensa, respectivamente.
Figura 3.15 Personaje atacando
Figura 3.16 Personaje defendiendose
3.2.1.5. Gestión de Parámetros
Tenemos un sistema de combate válido, pero hemos de vincularlo a un sistema de parámetros, tanto para el jugador como para los enemigos, en el que reflejemos la vida, la energía, la experiencia y el nivel. Este apartado actúa en dos niveles diferentes:
Nivel interno: cómo afecta al juego. Nivel visual: cómo se plasma en pantalla.
Nivel interno:
Jugador: El jugador empieza a nivel 1 con ciertos parámetros de fuerza, energía
y vida. Al matar enemigos consigue experiencia. Al conseguir suficiente experiencia, sube de nivel y aumenta los demás parámetros.
Al realizar un combate y recibir daño del enemigo, este nos resta la vida total. Al llegar a 0, el personaje muere y el jugador pierde la partida.
Al realizar y bloquear ataques, perdemos energía. Al estar cierto tiempo sin realizar ninguna acción, recuperamos esa energía.
Enemigos: El enemigo tiene un sistema de vida parecido al del jugador y no
estará provisto de energía, sino que, como hemos comentado en el apartado anterior, atacará cada cierto tiempo predefinido.
Respecto al nivel, implementamos un sistema más complejo. Siguiendo el contexto de diseño del juego, queremos que el jugador pueda tener cierta libertad para elegir su camino. Esto implica que, como programadores, no podemos marcar el camino mediante la fuerza de los enemigos. Para solucionarlo, aplicamos un DDA* (Dynamic Difficulty Adjustment).
Para implementarlo, creamos un sistema de parámetros parecido al del jugador. En este caso, sin embargo, al instanciar el objeto enemigo lo primero que realizará será buscar la referencia del nivel del jugador y se nivelará según lo establecido.
Esto supone que no crearemos todos los enemigos al empezar el nivel, sino que se irán instanciando a medida que nos acercamos a sus respectivas zonas. Implementar así los niveles proporciona facilidad en el control del nivelado y reduce el coste computacional total.
Nivel visual
Empezamos a trabajar la interfaz de usuario (UI). Mediante el objeto Canvas, podemos establecer imágenes que se verán fijas en una posición de la pantalla. Esto facilita crear las barras de vida, energía y experiencia, así como una referencia a un número, el nivel (Figura 3.17), que iremos actualizando a medida que avancemos en el juego.
Figura 3.17 Imagen UI de Parametros
En la Figura 3.18 podemos ver como se trabaja la UI desde la vista 2D del editor de Unity. Esta vista nos permite tener una referencia de como se verá por pantalla en todo momento. Los objetos de la UI se pueden anclar a posiciones concretas de la pantalla, de forma que si cambia la resolución de la misma, la UI se modificará de forma controlada.
Figura 3.18 Gestión de UI
3.2.2. UI Interactuable
Una vez que hemos implementado las mecánicas principales, es importante añadir aquellos elementos de Interfaz que sirven de complemento a la gameplay. Explicaremos este apartado en los siguientes puntos:
Inventario Misiones Diálogo Menú
3.2.2.1. Inventario
A continuación, trabajaremos el sistema de Inventario [2]. Queremos que el personaje pueda recoger objetos y se guarden en una bolsa. Estos objetos ha de poder utilizarlos, moverlos de casilla o eliminarlos. La bolsa ha de poder abrirla y cerrarla y, por descontado, que se vea por pantalla.
El esquema que seguiremos será el definido en la Figura 3.19: Vista 2D Unity
Figura 3.19 Esquema Inventario
De esta forma, el inventario creará un número de slots (recipientes) que habremos definido previamente y nos permitirán almacenar objetos.
Cada tipo de objeto define cuántos de estos pueden almacenarse en un mismo slot. De esta forma, diferenciamos entre los objetos que se pueden almacenar juntos y los que de forma individual ya ocupan un slot entero. En la imagen representada en la Figura 3.20 podemos diferenciar entre las botellas azules y las rojas. En las primeras, vemos como se permite almacenar múltiples en el mismo espacio, mientras que las segundas están restringidas a una por slot.
Figura 3.20 Inventario
La clase Inventario contiene una lista con todos los slots. Al recoger un objeto, comprobará si tiene algún slot con el mismo tipo de objeto donde pueda incluirlo. De no ser así, comprobará si contiene algún espació vacio.
Una vez con los ítems recogidos, nos permitirá clicar encima del objeto para usarlo, moverlo o destruirlo.
Un dato interesante es explicar cómo funciona la imagen de la bolsa del inventario que se mostrará permanentemente por pantalla. Al igual que los parámetros explicados en el apartado anterior, se trata de una imagen UI situada en el Canvas que se mantiene en una posición concreta de la pantalla. Al estar definida como Button, el propio Unity diferenciará cuando clicamos encima de la imagen del inventario de cuando clicamos en cualquier otro lugar de la pantalla. Esto es de vital importancia a la hora de diferenciar cuando queremos seleccionar un objeto de cuando queremos realizar un ataque.
1 Inventario
Items
3.2.2.2. Misiones
El sistema de misiones es un sistema complejo de implementar, pero que resulta muy importante a la hora de complementar la gameplay a medio plazo.
En este sistema queremos permitir al jugador aceptar misiones, cumplirlas y completarlas.
Estará diseñado por diferentes scripts con funciones muy singulares [15]:
Questlog: Script que contendrá la lista de misiones aceptadas. Nos mostrará por pantalla la lista de misiones aceptadas así como su respectiva descripción, el objetivo y la recompensa. Podemos ver un ejemplo en la Figura 3.21.
Quest: El objeto misión estará establecido como un Prefab. Estas misiones las iremos implementando en el juego a medida que las vayamos activando
QuesGiver: Script correspondiente al personaje que nos otorga la misión. Al hablar con él, abre la pantalla QuestGiverWindow correspondiente.
QuestGiverWindow: Pantalla donde podemos aceptar la misión y anidarla al Questlog. Aparecerán los nombres de misión y al presionarlos, la descripción y la recompensa. Al acabar cada misión, se puede completar y cobrar la recompensa. Podemos ver un ejemplo en la Figura 3.22.
3.2.2.3. Diálogo
El sistema de diálogo permite al juego comunicarse con el jugador. Queremos poder mostrar mensajes por pantalla y que el jugador pueda presionar un botón de “continuar” cuando los haya leído.
En este caso, trabajamos con 3 scripts y el sistema UI:
Creamos un script Dialogue serializado, mediante el cual podremos definir las frases que se mostrarán por pantalla en cada caso, así como el nombre del personaje.
Otro script DialogueTrigger relacionará el Dialogue definido anteriormente con el DialogueManager. Permitirá mostrar el texto adecuada cuando pasemos por puntos concretos.
En el script DialogueManager será donde trabajemos la lógica destacable de este sistema:
Mediante una Queue*, recorreremos las diferentes frases que componen cada diálogo.
Para hacer aparecer el texto del dialogo, utilizaremos un Animator. Este hará aparecer el cuadro de diálogo por la parte inferior de la pantalla. Podemos ver como se posiciona desde la vista 2D del editor de Unity en la Figura 3.23.
Un botón “continuar” estará vinculado a la función DisplayNextSentence que nos permitirá el avance en el diálogo.
Utilizamos una Coroutine para provocar el efecto de estar escribiendo las letras, y que no aparezcan todas escritas a la vez.
Al acabar el diálogo, el mismo Animator que ha hecho aparecer el cuadro de diálogo, lo hará desaparecer por el mismo lado de la pantalla.
Hemos de vigilar que no se superponga la imagen de Diálogo con la del Inventario: Cada vez que aparezca un diálogo, miraremos el estado del inventario y lo cerraremos en caso de estar abierto.
Añadimos una pequeña variante al sistema del diálogo para crear un sistema de tutorial. Este funcionará exactamente igual pero nos mostrará otro tipo de texto. En la siguiente imagen (Figura 3.24) podemos ver un ejemplo de diálogo ejecutándose por pantalla.
Figura 3.23 Animator Diálogo
Figura 3.24 Diálogo
3.2.2.4. Menú
Implementar el menú al que el jugador será redirigido entre partidas es otro de los aspectos del desarrollo del juego. En este caso, tiene una componente especial ya que desde este panel el jugador debe poder mejorar los parámetros de su personaje y que estos se vean reflejados en la siguiente partida.
Diseñamos diferentes pantallas de inferfaz, tal y como podemos ver definido en el HLDD, y vinculamos los botones con funciones que nos permite activar y desactivar los canvas correspondientes, dando la sensación de movernos por el menú.
Además, será aquí donde se establezca la relación entre el oro conseguido y la mejora de parámetros. Diferentes Botones se relacionarán con sus correspondientes funciones de comprar mejoras. Lo primero que harán será comprobar que disponemos del oro suficiente y, de ser así, restará el oro necesario y mejorará los parámetros de acuerdo a lo establecido. En la Figura 3.25 podemos ver la pantalla correspondiente a dicha característica.
Una parte importante de este apartado es gestionar estos parámetros para que se vean reflejados durante la partida. Creamos un script que trabajará con variables estáticas y que instanciaremos tanto en el menú como en la pantalla de juego. De esta forma, no se reiniciarán las variables cada vez que cambiemos entre la partida y el menú.
Al crearse el objeto jugador en una partida nueva, lo primero que hará será comprobar este script para saber cuáles son los parámetros iniciales con los que empezará en esa partida.
Figura 3.25 Menú Mejoras
3.2.3. Implementación del mundo
Con las mecánicas y la intefaz desarrolladas correctamente, procedemos a implementar el diseño de niveles. Al empezar a implementar este punto, nos encontramos con la necesidad de desarrollar diferentes aéreas para añadir fluidez en la progresión de la partida. El apartado será divido en los siguientes puntos para su explicación:
Generador de Enemigos
Relación Dialogo – Generador de Enemigos Diseño de niveles
3.2.3.1. Generador de Enemigos
Necesitamos añadir puntos de referencia para crear los enemigos. De esta forma, a medida que avancemos por el mapa iremos instanciando los conjuntos de enemigos que nos encontraremos a continuación. Esto nos ayuda a decidir su nivel y a reducir carga computacional del juego.
Creamos un Trigger con información de que objetos enemigo crear y donde hacerlo. Parecido al sistema de diálogo, trabajamos con diferentes scripts:
SpawnEnemy: Contiene información de que enemigos se generan, donde se instancian y si han de realizar alguna acción nada más instanciarse.
EnemyTrigger: Relaciona el script SpawnEnemy con el script EnemyManager. De esta forma, al pasar por un lugar concreto, activaremos el trigger y se generaran los enemigos.
EnemyManager: Instancia los enemigos.
3.2.3.2. Relación Diálogo - Generador de Enemigos
Con el fin de proporcionar cierta fluidez al juego, es interesante considerar que se establezca una cierta relación entre el sistema de dialogo y el sistema de generar enemigos. De esta forma, nos da la posibilidad de hacer aparecer enemigos justo después de activar un diálogo concreto o, al revés, activar un cierto diálogo después de vencer a algún enemigo.
Como podemos ver, esto facilita una fluidez y una continuidad en otro caso imposibles. Para conseguirlo, incluimos en la clase Dialogue una referencia a la clase SpawnEnemy y en la clase SpawnEnemy una referencia a la clase Dialogue.
Dialogue -> SpawnEnemy:
Al activar un diálogo, comprueba si este tiene alguna relación con un generador de enemigos. De ser así, al acabar el dialogo y volver a cerrarlo, llamara a la clase EnemyManager instanciando todos los enemigos
SpawnEnemy -> Dialogue
Al generar enemigos comprueba si tiene alguna relación con el sistema de diálogo. De ser así, guarda todos los enemigos generados en una lista y la comprueba cada vez que uno muere. Cuando han muerto todos los enemigos de la lista, llama al DialogueManager para que active el diálogo correspondiente.
Es importante diferenciar entre las diferentes listas de enemigos generadas, de forma que no puedan cruzarse diálogos con listas de enemigos no correspondientes.
En la Figura 3.26 podemos ver esta relación en el
comando del editor de Unity. Si nos fijamos, estamos Figura 3.26 Pantalla de Comandos Enemy Trigger
creado una lista de enemigos que contiene un objeto Goblin. A continuación, vemos una referencia a un dialogo que aparecerá cuando acabemos con dicho enemigo. Al leer el correspondiente diálogo, creamos otra referencia a dos enemigos más. De esta forma, conseguimos una fluidez de eventos constante en el juego.
3.2.3.3. Diseño de niveles
Creamos el diseño de niveles de forma que cumpla la lógica definida en el documento de diseño. Utilizamos diferentes recursos que ofrece Unity, como el uso del objeto Terrain, que permite modelar el entorno para crear depresiones geográficas, montañas, incluir árboles, etc.
Al tratarse de un prototipo, utilizamos la técnica conocida como WhiteBox. Para crear el poblado y el castillo, utilizamos cajas blancas que nos permitirán saber las dimensiones y las distancias, restándole importancia al apartado gráfico. Unity permite modelar estas estructuras, ya sea mediante cubos simples o mediante la herramienta ProBuilder (Figura 3.27), que dotará de más libertad a la hora de modelar formas concretas, como podrían ser los tejados de las casas.
Figura 3.27 ProBuilder
Podemos ver en la Figura 3.28 una vista elevada del nivel diseñado y en el esquema de la Figura 3.29 el curso de acción definido, extraido del HLDD. Al fijarnos en la estructura de este, veremos que la creación de nivel ha quedado condicionada por el curso de acción, de forma que podamos introducir todas las escenas declaradas a lo largo del nivel.
Figura 3.29 Esquema Curso de Acción Inicio/ Primeros enemigo s Encuentro con Sigrid / Enemigos camino del pueblo Enemigos Pueblo Pueblo Liberado / Área Neutral Misión Opcional Enemigos Camino Jefe Jefe Final Cambio de escena Escena Final
3.2.3.4. Animaciones dentro del juego.
Finalmente, un elemento muy importante para dotar de vida al juego y otorgarle cierta fluidez y suavidad es la introducción de animaciones en momentos importantes, como podrían ser los cambios de escena o el final de la partida.
Para realizar estas animaciones, grabaremos el movimiento mediante la herramienta Animation y luego las incluiremos en una máquina de estados para saber en qué momento exacto se han de ejecutar. Este proceso está caracterizado en la Figura 3.30. Es importante determinar bien que parámetros cambian en cada momento, ya sea la posición absoluta, el color, o simplemente algún parámetro definido dentro de un script, como podría ser la distancia de la cámara respecto al jugador o el ángulo mediante el cual lo enfoca.
4.
Ingeniería de software
En este apartado hemos realizado un estudio complementario al diseño y desarrollo del juego, explicado en la sección anterior, centrándonos en aspectos de interés a la hora de desarrollar un proyecto de software en este ámbito.
Dividimos el apartado en los siguientes puntos: Documentación del Control de Versiones Estudio del Rendimiento de The Dark Crown Estudio de QA
