Repositorio Digital

UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA CARRERA DE INGENIERÍA EN COMPUTACIÓN GRÁFICA

Diseño general, escritura, desarrollo y programación de un videojuego de rol JRPG llamado “Quito Quest”

Trabajo de titulación, modalidad Proyecto Integrador previo a la obtención al titulo de Ingeniero en Computación Gráfica.

AUTOR: Ronquillo Lugo Daniel Ignacio

TUTOR: Fis. Bayardo Gonzalo Campuzano Nieto

QUITO, 2019 DERECHOS DE AUTOR

Yo, RONQUILLO LUGO DANIEL IGNACIO en calidad de autor y titular de los derechos morales y patrimoniales del trabajo de titulación DISEÑO GENERAL, ESCRITURA, DESARROLLO Y PROGRAMACIÓN DE UN VIDEOJUEGO DE ROL JRPG LLAMADO “QUITO QUEST”, de conformidad con el Art. 114 del CÓDIGO ORGÁNICO DE LA ECONOMÍA SOCIAL DE LOS CONOCIMIENTOS, CREATIVIDAD E INNOVACIÓN, concedo a favor de la Universidad Central del Ecuador una licencia gratuita, intransferible y no exclusiva para el uso no comercial de la obra, con fines estrictamente académicos. Conservo a mi favor todos los derechos de autor sobre la obra, establecidos en la normativa citada. Así mismo, autorizo a la Universidad Central del Ecuador para que realice la digitalización y publicación de este trabajo de titulación en el repositorio virtual, de conformidad a lo dispuesto en el Art. 144 de la Ley Orgánica de Educación Superior. El autor declara que la obra objeto de la presente autorización es original en su forma de expresión y no infringe en el derecho de autor de terceros, asumiendo la responsabilidad por cualquier reclamación que pudiera presentarse por esta causa y liberando a la Universidad de toda responsabilidad.

______Daniel Ignacio Ronquillo Lugo C.I.: 1723609564 Email: [email protected]

APROBACIÓN DEL TUTOR

En mi calidad de Tutor del Trabajo de Titulación, presentado por el Sr. RONQUILLO LUGO DANIEL IGNACIO, para optar por el Grado Ingeniero Computación Grafica; cuyo título es: DISEÑO GENERAL, ESCRITURA, DESARROLLO Y PROGRAMACIÓN DE UN VIDEOJUEGO DE ROL JRPG LLAMADO “QUITO QUEST”, considero que dicho trabajo reúne los requisitos y méritos suficientes para ser sometido a la presentación pública y evaluación por parte del tribunal examinador que se designe, por lo que lo APRUEBO, a fin de que el trabajo Proyecto Integrador sea habilitado, para continuar con el proceso de titulación determinado por la Universidad Central del Ecuador.

En la ciudad de Quito, a los 6 días del mes de agosto de 2019.

______Fis. Bayardo Gonzalo Campuzano Nieto DOCENTE-TUTOR C.I.: 1708459118

iii

DEDICATORIA

A mi familia y mis amigos porque por ellos pude ser la persona que soy ahora.

Gracias por su incondicional apoyo.

AGRADECIMIENTOS

Quisiera expresar mi más sentido agradecimiento a mis compañeros, amigos y familiares y todos los que ayudaron a que este proyecto sea completado.

Gracias por siempre a todos.

CONTENIDO

DERECHOS DE AUTOR ...... ii APROBACIÓN DEL TUTOR ...... iii DEDICATORIA ...... iv AGRADECIMIENTOS ...... v CONTENIDO ...... vi LISTA DE ILUSTRACIONES ...... xiv LISTA DE TABLAS ...... xxii GLOSARIO ...... xxiv RESUMEN ...... xxvi ABSTRACT ...... xxvii INTRODUCCIÓN ...... 1 1.Capítulo I: Definición del Problema ...... 3 1.1 Antecedentes ...... 3 1.2 Planteamiento del Problema ...... 4 1.3 Justificación ...... 4 1.4 Objetivos ...... 4 1.4.1 Objetivo General ...... 4 1.4.2 Objetivos Específicos...... 4 1.5 Alcance y Limitaciones ...... 4 2.Capítulo II: Marco Referencial ...... 6 2.1 Conceptos Básicos...... 6 2.1.1 Juego de rol (RPG)...... 6 2.1.2 Videojuego de rol japonés (JRPG) ...... 7 2.1.3 Combate basado en turnos ...... 9 2.2 Marco Teórico ...... 10 2.2.1 Inteligencia artificial ...... 10 2.2.1.1 Agentes ...... 10 2.2.1.2 Inteligencia artificial en videojuegos ...... 11 2.2.1.3 El objetivo de la inteligencia artificial en los videojuegos ...... 11 2.2.1.4 Percepción ...... 12 2.2.1.4.1 Elementos de percepción ...... 12 2.2.1.5 Árbol de decisiones ...... 12 2.2.2 Componentes de un JRPG ...... 13

2.2.2.1 Escenario temático ...... 13 2.2.2.2 Narrativa dramática ...... 13 2.2.2.2.1 Desarrollo de personajes ...... 14 2.2.2.2.2 Protagonista y antagonista ...... 14 2.2.2.3 El mundo del juego ...... 15 2.2.2.3.1 Construcción del mundo ...... 15 2.2.2.4 Party ...... 16 2.2.2.4.1 Progresión de personajes ...... 16 2.2.2.5 Items ...... 16 2.2.3 Motores de desarrollo de videojuegos ...... 17 2.2.4 Unreal Engine 4 ...... 18 2.2.4.1 Por qué usar Unreal Engine 4 ...... 18 2.2.4.2 Elementos de Unreal Engine 4 ...... 19 2.2.4.2.1 Actores ...... 19 2.2.4.2.1.1 Tipos de actores ...... 19 2.2.4.2.2 Blueprints ...... 20 2.2.4.2.2.1.1 Gráfica de eventos ...... 21 2.2.4.2.2.2 Eventos ...... 21 2.2.4.2.2.3 Funciones...... 22 2.2.4.2.2.3.1 Ventajas del uso de funciones...... 23 2.2.4.2.2.4 Componentes ...... 23 2.2.4.2.2.4.1 Actor Component ...... 23 2.2.4.2.2.5 Blueprints especiales ...... 24 2.2.4.2.2.5.1 Level Blueprint ...... 24 2.2.4.2.2.5.2 Game Mode ...... 24 2.2.4.2.2.5.3 Peones ...... 24 2.2.4.2.2.5.4 Personajes ...... 24 2.2.4.2.2.5.5 Player Controller ...... 24 2.2.4.2.2.5.5.1 Mapeo de entrada 25 2.2.4.2.2.5.6 Game Instance ...... 25 2.2.4.2.2.5.7 Save Game ...... 26 2.2.4.2.2.6 Variables ...... 26 2.2.4.2.2.6.1 Tipos de datos ...... 26 2.2.4.2.2.6.2 Enumeradores ...... 27 2.2.4.2.2.6.3 Estructuras de datos ...... 28

vii

2.2.4.2.2.6.4 Tablas de datos ...... 28 2.2.4.2.3 Widgets ...... 29 2.2.4.2.4 Audio ...... 30 2.2.4.2.4.1 Actor de sonido ambiente ...... 30 2.2.4.2.4.2 Señales de sonido ...... 30 2.3 Metodología Experimental ...... 30 2.3.1 Ingeniería de software de desarrollo de videojuegos...... 30 2.3.1.1 Fase de Pre-producción ...... 31 2.3.1.1.1 Especificación de requisitos ...... 31 2.3.1.1.2 Reusabilidad ...... 32 2.3.1.1.3 Documento de diseño de juego ...... 33 2.3.1.1.3.1 Visión del juego...... 33 2.3.1.1.3.2 Audiencia del juego ...... 34 2.3.1.1.3.2.1 Demografías ...... 34 2.3.1.1.3.3 Plataformas ...... 35 2.3.1.1.3.4 Idea principal del juego ...... 35 2.3.1.1.3.5 Estilo visual ...... 36 2.3.1.1.3.6 Diseño de niveles y entorno ...... 37 2.3.1.1.3.7 Personajes e historia ...... 38 2.3.1.1.4 Herramientas de diseño ...... 39 2.3.1.1.5 Prototipo de juego ...... 39 2.3.1.2 Fase de Producción ...... 42 2.3.1.2.1 Desarrollo de activos ...... 42 2.3.1.2.1.1 Diseños: ...... 42 2.3.1.2.1.2 Elementos de interfaz grafica ...... 43 2.3.1.2.1.3 Elementos audiovisuales ...... 44 2.3.1.2.2 Diseño y producción de Niveles ...... 45 2.3.1.2.2.1 El primer nivel ...... 46 2.3.1.2.3 Programación ...... 46 2.3.1.2.3.1 Arquitectura del juego ...... 46 2.3.1.2.3.1.1 Capa de aplicación ...... 47 2.3.1.2.3.1.1.1 Lectura de entrada……………………………………... . 48 2.3.1.2.3.1.1.2 Sistema de archivos……………………………………. . 48 2.3.1.2.3.1.1.3 Manejo de memoria……………………………………. 48 2.3.1.2.3.1.1.4 Ciclo de juego………………………………………….. 48

viii

2.3.1.2.3.1.2 Capa de lógica del juego ...... 48 2.3.1.2.3.1.2.1 Estado de juego y estructura de datos 49 2.3.1.2.3.1.2.2 Física y colisiones 49 2.3.1.2.3.1.2.3 Eventos 49 2.3.1.2.3.1.2.4 Gestor de procesos 50 2.3.1.2.3.1.2.5 Interpretador de comandos 50 2.3.1.2.3.1.3 Capa de vista del juego ...... 50 2.3.1.2.3.1.3.1 Gráficos 51 2.3.1.2.3.1.3.2 Audio 51 2.3.1.2.3.1.3.3 Gestor de procesos 51 2.3.1.2.4 Implementación ...... 51 2.3.1.2.5 Alfa...... 52 2.3.1.3 Fase de Postproducción ...... 52 2.3.1.3.1 Seguro de calidad ...... 52 2.3.1.3.1.1 Beta ...... 53 2.3.1.3.1.2 Revisión final ...... 54 2.3.1.3.2 Lanzamiento ...... 54 2.3.2 Método Iterativo...... 54 2.3.2.1 Fases de desarrollo...... 55 3.Capítulo III: Diseño e Implementación ...... 57 3.1 Mecánicas del juego ...... 57 3.1.1 Historia del juego ...... 57 3.1.2 Las tres épocas ...... 57 3.1.2.1 2019 ...... 57 3.1.2.2 1999 ...... 58 3.1.2.3 1989 ...... 58 3.1.3 Party ...... 59 3.1.3.1 Party en 2019 ...... 59 3.1.3.2 Party en 1999 ...... 60 3.1.3.3 Party en 1989 ...... 60 3.1.3.4 Atributos ...... 61 3.1.4 Ítems ...... 61 3.1.4.1 Ítems importantes ...... 61 3.1.4.2 Ítems consumibles ...... 62 3.1.4.3 Atributos ...... 62

3.1.5 Estructura de niveles ...... 62 3.1.5.1 Punto de inicio ...... 63 3.1.5.2 Elementos con interactividad ...... 63 3.1.5.3 Entrada a otros niveles ...... 64 3.1.5.4 Tiendas...... 64 3.1.6 Sistemas de juego ...... 65 3.1.6.1 Sistema de progresión ...... 65 3.1.6.1.1 Misiones ...... 66 3.1.6.1.2 Objetivos ...... 66 3.1.6.2 Sistema de conversación ...... 67 3.1.6.3 Sistema de combate ...... 67 3.1.6.3.1 Juego de cartas “Cuarenta” ...... 68 3.1.6.3.1.1 Reglas del Cuarenta ...... 68 3.1.6.3.2 Cuarenta como combate ...... 70 3.1.6.4 Enemigos ...... 71 3.1.6.4.1 Atributos...... 72 3.1.7 Flujo de juego ...... 72 3.2 Implementación de mecánica y código ...... 73 3.2.1 Enumeradores ...... 73 3.2.2 Estructuras...... 75 3.2.3 Tablas de datos ...... 80 3.2.4 Widgets ...... 81 3.2.4.1 Widgets Básicos ...... 82 3.2.4.1.1 QuestObjective_Widget ...... 82 3.2.4.1.2 CharacterHealth_Widget ...... 82 3.2.4.1.3 Comportamiento de Widgets Básicos ...... 82 3.2.4.1.4 Menús por año ...... 83 3.2.4.1.4.1 Elementos ...... 83 3.2.4.1.4.2 Comportamiento de menús por año...... 84 3.2.4.1.5 QuestLog_Widget ...... 86 3.2.4.2 Widgets Simples ...... 86 3.2.4.2.1 MainMenu_Widget ...... 86 3.2.4.2.1.1 Comportamiento de MainMenu_Widget...... 87 3.2.4.2.2 LoadGame_Widget ...... 88 3.2.4.2.3 Options_Widget ...... 88

3.2.4.2.3.1 Comportamiento de Options_Widget ...... 89 3.2.4.2.4 Credits_Widget ...... 91 3.2.4.2.5 Main_Widget ...... 91 3.2.4.2.6 Pause_Widget...... 92 3.2.4.2.7 Transition_Widget ...... 93 3.2.4.2.8 LoadingScreen_Widget ...... 93 3.2.4.2.9 Dialogue_Widget ...... 93 3.2.4.2.10 Missions_Widget ...... 94 3.2.4.2.11 Items_Widget ...... 95 3.2.4.2.12 Status_Widget ...... 96 3.2.4.2.13 SaveGame_Widget ...... 96 3.2.4.2.14 Exit_Widget ...... 97 3.2.4.2.15 NextLevel_Widget ...... 97 3.2.4.3 Widgets Complejos...... 98 3.2.4.3.1 Store_Widget ...... 98 3.2.4.3.1.1 Comportamiento ...... 98 3.2.4.3.2 Combat_Widget ...... 100 3.2.4.3.2.1 Widgets auxiliares de combate ...... 101 3.2.4.3.2.2 Comportamiento ...... 103 3.2.4.3.2.2.1 Eventos ...... 103 3.2.4.3.2.2.2 Funciones ...... 105 3.2.5 Blueprints especiales ...... 109 3.2.5.1 QuitoQuestInstance ...... 109 3.2.5.1.1 Comportamiento...... 110 3.2.5.2 QuitoQuestGameMode ...... 110 3.2.5.3 QuitoQuestSaveGame ...... 111 3.2.5.3.1 Comportamiento...... 111 3.2.6 El jugador ...... 111 3.2.6.1 Entrada del juego ...... 112 3.2.6.2 MainMenu_BP...... 114 3.2.6.2.1 Comportamiento...... 114 3.2.6.3 Personaje_BP ...... 117 3.2.6.3.1 Comportamiento...... 118 3.2.6.3.1.1 Eventos ...... 118 3.2.6.3.1.2 Funciones...... 123

3.2.6.3.1.3 Sonidos en Personaje_BP ...... 127 3.2.6.3.2 Componente QuestLog ...... 128 3.2.6.3.2.1 Comportamiento ...... 128 3.2.7 Actores ...... 130 3.2.7.1.1 Personajes no jugables (NPCs) ...... 130 3.2.7.1.1.1 NPC_TypeA_BP ...... 130 3.2.7.1.1.1.1 Comportamiento ...... 130 3.2.7.1.1.2 NPC_TypeB_BP ...... 132 3.2.7.1.1.3 Enemy_BP ...... 133 3.2.7.1.1.3.1 Comportamiento ...... 133 3.2.7.2 LocationMarker_BP ...... 135 3.2.7.2.1 Comportamiento...... 135 3.2.7.3 Light_BP ...... 136 3.2.7.4 Sound_BP ...... 137 3.2.7.5 Actores Hijos ...... 137 3.2.7.5.1 LevelLoader_BP ...... 137 3.2.7.5.1.1 Comportamiento ...... 138 3.2.7.5.2 Store_BP ...... 138 3.2.7.5.2.1 Comportamiento ...... 138 3.2.7.5.3 InteractableObject_BP ...... 139 3.2.7.5.3.1 Comportamiento ...... 139 3.2.8 Sistema de tráfico ...... 144 3.2.8.1 Car_BP...... 144 3.2.8.1.1 Comportamiento...... 145 3.2.8.2 Semaforo_BP ...... 147 3.2.8.3 ClonadorCarros_BP ...... 148 3.2.8.3.1 Comportamiento...... 149 3.2.8.4 DestructorCarros_BP ...... 150 3.3 Desarrollo a gran escala ...... 150 3.3.1 Diagrama entidad relación en Quito Quest ...... 150 3.3.2 Niveles dentro Quito Quest ...... 152 3.3.2.1 Progresión entre niveles ...... 153 3.3.2.1.1 Fases en Quito Quest...... 154 3.3.2.1.2 Interconexión de niveles ...... 155 3.3.3 Elementos de niveles...... 157

xii

3.4 Pruebas y resultados ...... 160 3.4.1 Pruebas internas ...... 160 3.4.1.1 Configuración gráfica ...... 160 3.4.1.2 Movimiento de actores ...... 162 3.4.1.2.1 Personajes no jugables (NPCs) ...... 162 3.4.1.2.2 Sistema de tráfico ...... 163 3.4.1.3 Interacción con actores ...... 164 3.4.1.3.1 Sistema de misiones ...... 164 3.4.1.3.2 Conversación ...... 165 3.4.1.3.3 Tienda...... 165 3.4.1.4 Combate ...... 166 3.4.2 Pruebas externas...... 166 4.Capítulo IV: Conclusiones y recomendaciones………………………………………173 4.1 Conclusiones ...... 173 4.2 Recomendaciones ...... 173 BIBLIOGRAFÍA………………………………………………………………...……..175 ANEXOS ...... i

xiii

LISTA DE ILUSTRACIONES

Ilustración 1: Dragon Quest, el primer JRPG (Enix, 1986)______2 Ilustración 2: pedit5 (también conocido como The Dungeon), uno de los primeros videojuegos RPG, (Rutherford, 1975) ______6 Ilustración 3: The Dragon & the Princess, el primer RPG desarrollado en Japón. (Koei, 1981) ______7 Ilustración 4: The Legend of Zelda (Nintendo, 1986) ______8 Ilustración 5: Dragon Quest III: Soshite Densetsu e... (Enix, 1988) ______10 Ilustración 6: Final Fantasy IX (Square, 2000) ______10 Ilustración 7: Persona 3: FES (Atlus, 2007.) ______10 Ilustración 8: Pokémon Emerald (Pokémon Co., 2004) ______10 Ilustración 9: Ejemplo de un árbol de decisiones (Ronquillo, 2019) ______13 Ilustración 10: Logotipo de Unity (Unity Technologies, s.f.) ______17 Ilustración 11: Logotipo de GameMaker Studio 2 (YoYo Games, s.f.) ______17 Ilustración 12: Logotipo de CryEngine (Crytek, s.f.) ______18 Ilustración 13: Logotipo de RPG Maker (Kadokawa Games, s.f.) ______18 Ilustración 14: Dragon Quest XI: Echoes of an Elusive Age (Square Enix, 2017) ______19 Ilustración 15: Final Fantasy VII Remake (Square Enix, 2020) ______19 Ilustración 16: Kingdom Hearts III (Square Enix, 2019) ______19 Ilustración 17: Octopath Traveler (Nintendo, 2018) ______19 Ilustración 18: Ejemplos de actores de malla estática (Nixon, 2017) ______20 Ilustración 19: Editor de blueprints dentro de Unreal Engine 4 (Ronquillo, 2019) ______20 Ilustración 20: Nodos en la gráfica de eventos (Ronquillo, 2019) ______21 Ilustración 21: Nodos de datos en la gráfica de eventos (Nixon, 2017)______21 Ilustración 22: Los eventos BeginPlay y Tick en el gráfico de eventos (Nixon, 2017) _____ 22 Ilustración 23: Componentes en un Blueprint (Nixon, 2017) ______23 Ilustración 24: Tipos de datos de entrada en Unreal Engine 4 (Ronquillo, 2019) ______25 Ilustración 25: Algunos tipos de datos en Unreal Engine 4 (Nixon, 2017) ______26 Ilustración 26: Ejemplo de un enumerador en Unreal Engine 4 (Ronquillo, 2019) ______27 Ilustración 27: Ejemplo de una estructura de datos en Unreal Engine 4 (Ronquillo, 2019) _ 28 Ilustración 28: Ejemplo de una tabla de datos en Unreal Engine 4 (Ronquillo, 2019) _____ 29 Ilustración 29: Editor de Widgets en Unreal Engine 4 (Ronquillo, 2019) ______29 Ilustración 30: Ejemplo de la creación de una instancia de un Widget y su proyección a la pantalla de juego. (Nixon, 2017) ______29 Ilustración 31: Propiedad de sonido dentro de un actor de sonido ambiente (Nixon, 2017) 30 Ilustración 32: Nubes en Super Mario Bros. (Nintendo, 1985) ______32 Ilustración 33: Arbustos en Super Mario Bros. (Nintendo, 1985) ______32 Ilustración 34: Ejemplo de estilo grafico abstracto, Superhot (7DFPS, 2013) ______37 Ilustración 35: Ejemplo de estilo visual estilizado, Overwatch (Blizzard, 2016) ______37 Ilustración 36: Ejemplo de estilo visual realista, Battlefield 1 (Electronic Arts, 2016) ____ 37 Ilustración 37: Diseño de niveles en Super Mario Bros. (Nintendo, 1985) ______37 Ilustración 38: Ejemplo de entorno utilizando arte conceptual de God of War (Sony Interactive Entertainment, 2018) ______38 Ilustración 39: Arte conceptual de personajes en Metal Gear Solid V: The Phantom Pain (Konami, 2015) ______38

xiv

Ilustración 40: Prototipo inicial de Arms (Nintendo, 2017)______40 Ilustración 41: Versión final de Arms (Nintendo, 2017) ______40 Ilustración 42: Ejemplo de prototipo 2D, The Legend of Zelda: Breath of the Wild (Nintendo, 2017) ______41 Ilustración 43: Ejemplo de juego en 3D basado en prototipo en 2D, The Legend of Zelda: Breath of the Wild (Nintendo, 2017) ______41 Ilustración 44: Ciclo de desarrollo de un prototipo. (Schell, 2008) ______41 Ilustración 45: Ejemplo de personaje: Spritesheet the Sparkster usado en Rocket Knight Adventures (Konami, 1993) ______42 Ilustración 46: Ejemplo de objeto: Medallón usado en Resident Evil 2 (Capcom, 2019) ___ 42 Ilustración 47: Ejemplo de entorno como visto en Fislab Kids Expanded (Dominguez & Lima, 2019) ______43 Ilustración 48: Ejemplo de texturizado: Textura usada en Tommy Vercetti en Grand Theft Auto: Vice City (Rockstar, 2002) ______43 Ilustración 49: Ejemplo de un HUD, Metroid Prime (Nintendo, 2002) ______43 Ilustración 50: Ejemplo de un menú, Persona 5 (Atlus, 2016) ______44 Ilustración 51: Ejemplos de iconos dentro de un menú, Dragon Quest VIII: Journey of the Cursed King (Square Enix, 2004) ______44 Ilustración 52: Arquitectura de juego de alto nivel. (Graham & McShaffry, 2012) ______47 Ilustración 53: Subsistemas que conforman la capa de aplicación (Graham & McShaffry, 2012) ______47 Ilustración 54: Subsistemas que conforman la capa de lógica del juego (Graham & McShaffry, 2012)______49 Ilustración 55: Subsistemas que conforman la capa de vista del juego (Graham & McShaffry, 2012) ______50 Ilustración 56: Ciclo de vida de desarrollo de software según Doppler Interactive (McGrath, 2011) ______55 Ilustración 57: Descripción grafica del método iterativo. (Gutierrez, 2011) ______55 Ilustración 58: Target render de la era de 2019 en Quito Quest (Ronquillo, 2019) ______57 Ilustración 59: Target render de la era de 1999 en Quito Quest (Ronquillo, 2019) ______58 Ilustración 60: Target render de la era de 1989 en Quito Quest (Ronquillo, 2019) ______58 Ilustración 61: Ilustración de Valentina en Quito Quest (Escobar, 2019) ______59 Ilustración 62: Ilustración Joseth en Quito Quest (Escobar, 2019) ______59 Ilustración 63: Ilustración de See-yeon en Quito Quest (Escobar, 2019) ______60 Ilustración 64: Ilustración de Johanna en Quito Quest (Escobar, 2019) ______60 Ilustración 65: Ilustración de Diana en Quito Quest (Escobar, 2019) ______60 Ilustración 66: Ilustración de Jonathan en Quito Quest (Escobar, 2019) ______60 Ilustración 67: Plano de un nivel en Quito Quest (Ronquillo, 2019) ______63 Ilustración 68: Arte conceptual mostrando el punto de inicio de un nivel en Quito Quest (Ronquillo, 2019) ______63 Ilustración 69: Arte conceptual de acceso a otros niveles en Quito Quest (Ronquillo, 2019) 64 Ilustración 70: Arte conceptual de los distintos tipos de tiendas en Quito Quest (Ronquillo, 2019) ______65 Ilustración 71: Arte conceptual de la progresión de una misión en Quito Quest (Ronquillo, 2019) ______65 Ilustración 72: Esquema de funcionalidad de misiones en Quito Quest (Ronquillo, 2019)__ 66

Ilustración 73: Arte conceptual del sistema de conversación en Quito Quest (Ronquillo, 2019) ______67 Ilustración 74: Arte conceptual del combate en Quito Quest (Ronquillo, 2019) ______70 Ilustración 75: Esquema del flujo de juego en Quito Quest (Ronquillo, 2019) ______73 Ilustración 76: QuestObjective_Widget en Quito Quest (Ronquillo, 2019) ______82 Ilustración 77: CharacterHealth_Widget en Quito Quest (Ronquillo, 2019) ______82 Ilustración 78: Esquema del comportamiento de Widgets Básicos en Quito Quest (Ronquillo, 2019) ______83 Ilustración 79: Menús por año, 1989_Widget, 1999_Widget y 2019_Widget, en Quito Quest (Ronquillo, 2019) ______83 Ilustración 80: Esquema de las instrucciones del Evento Construir dentro de un menú por año en Quito Quest (Ronquillo, 2019) ______84 Ilustración 81: Esquema de la Función ChangeStatus en los menús por año en Quito Quest (Ronquillo, 2019) ______84 Ilustración 82: Esquema de la función NextButton dentro de los menús por año en Quito Quest (Ronquillo, 2019) ______85 Ilustración 83: Esquema de la función PreviousButton en los menús por año en Quito Quest (Ronquillo, 2019) ______85 Ilustración 84: QuestLog_Widget en Quito Quest (Ronquillo, 2019) ______86 Ilustración 85: MainMenu_Widget en Quito Quest (Ronquillo, 2019) ______86 Ilustración 86: Esquema de Evento Construir del MainMenu_Widget en Quito Quest (Ronquillo, 2019) ______87 Ilustración 87: LoadGame_Widget en Quito Quest (Ronquillo, 2019) ______88 Ilustración 88: Options_Widget en Quito Quest (Ronquillo, 2019) ______88 Ilustración 89: Esquema de la función NextElement dentro de Options_Widget en Quito Quest (Ronquillo, 2019) ______90 Ilustración 90: Credits_Widget en Quito Quest (Ronquillo, 2019) ______91 Ilustración 91: Main_Widget en Quito Quest (Ronquillo, 2019) ______91 Ilustración 92: Pause_Widget en Quito Quest (Ronquillo, 2019) ______92 Ilustración 93: LoadingScreen_Widget en Quito Quest (Ronquillo, 2019) ______93 Ilustración 94: Dialogue_Widget en Quito Quest (Ronquillo, 2019) ______93 Ilustración 95: Missions_Widget en Quito Quest (Ronquillo, 2019) ______94 Ilustración 96: Items_Widget en Quito Quest (Ronquillo, 2019) ______95 Ilustración 97: Status_Widget en Quito Quest (Ronquillo, 2019) ______96 Ilustración 98: SaveGame_Widget en Quito Quest (Ronquillo, 2019) ______96 Ilustración 99: Exit_Widget en Quito Quest (Ronquillo, 2019) ______97 Ilustración 100: NextLevel_Widget en Quito Quest (Ronquillo, 2019) ______97 Ilustración 101: Store_Widget en Quito Quest (Ronquillo, 2019) ______98 Ilustración 102: Esquema de la función CompraVenta, caso: compra, utilizado en Store_Widget en Quito Quest (Ronquillo, 2019) ______99 Ilustración 103: Esquema de la función CompraVenta, caso: venta, utilizado en Store_Widget en Quito Quest (Ronquillo, 2019) ______99 Ilustración 104: Combat_Widget en Quito Quest (Ronquillo, 2019) ______100 Ilustración 105: Card_Widget en Quito Quest ______101 Ilustración 106: CardBack_Widget en Quito Quest (Ronquillo, 2019) ______101 Ilustración 107: Caida_Widget en Quito Quest (Ronquillo, 2019) ______101

xvi

Ilustración 108: LlevaCarta_Widget en Quito Quest (Ronquillo, 2019) ______101 Ilustración 109: Suma_Widget en Quito Quest (Ronquillo, 2019) ______101 Ilustración 110: Secuencia_Widget en Quito Quest (Ronquillo, 2019) ______101 Ilustración 111: Limpa_Widget en Quito Quest (Ronquillo, 2019) ______102 Ilustración 112: ContarMonton_Widget en Quito Quest (Ronquillo, 2019) ______102 Ilustración 113: LevelUp_Widget en Quito Quest (Ronquillo, 2019) ______102 Ilustración 114: AddItem_Widget en Quito Quest (Ronquillo, 2019) ______102 Ilustración 115: BattleWon_Widget en Quito Quest (Ronquillo, 2019) ______102 Ilustración 116: Esquema del evento BeginPlay dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) ______103 Ilustración 117: Esquema del evento JugarCarta dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) ______103 Ilustración 118: Esquema del evento RepartirOtraVez dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) ______104 Ilustración 119: Esquema del evento EndGame dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) ______104 Ilustración 120: Esquema de las funciones PlayerMove & EnemyMove dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) ______105 Ilustración 121: Esquema de la función AddCardToTable dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) ______105 Ilustración 122: Esquema de la función Caída dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) ______106 Ilustración 123: Esquema de la función LlevaCarta dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) ______106 Ilustración 124: Esquema de la función Suma dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) ______107 Ilustración 125: Esquema de la función Secuencia dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) ______107 Ilustración 126: Esquema de la función AumentarPuntos dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) ______107 Ilustración 127: Esquema de la función MontonAPuntos dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) ______108 Ilustración 128: Esquema de la función MeasureDamage dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) ______108 Ilustración 129: Esquema de la función Damage dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) ______109 Ilustración 130: Esquema del uso de idiomas usado en Quito Quest (Ronquillo, 2019) ___ 110 Ilustración 131: Esquema del evento LoadGame utilizado en QuitoQuestInstance en Quito Quest (Ronquillo, 2019) ______110 Ilustración 132: Esquema de la función SaveGame dentro de QuitoQuestSaveGame en Quito Quest (Ronquillo, 2019) ______111 Ilustración 133: Esquema del evento BeginPlay dentro de MainMenu_BP en Quito Quest (Ronquillo, 2019) ______114 Ilustración 134: Esquema del evento PauseGame dentro de MainMenu_BP en Quito Quest (Ronquillo, 2019) ______114

xvii

Ilustración 135: Esquema de los eventos MoveLeft & MoveUp/Forward dentro de MainMenu_BP en Quito Quest (Ronquillo, 2019) ______115 Ilustración 136: Esquema de los eventos MoveRight & MoveDown/Backwards dentro de MainMenu_BP en Quito Quest (Ronquillo, 2019) ______115 Ilustración 137: Esquema del evento Interactuar/Aceptar dentro de MainMenu_BP en Quito Quest (Ronquillo, 2019) ______116 Ilustración 138: Esquema del evento Cancelar/Salir dentro de MainMenu_BP en Quito Quest (Ronquillo, 2019) ______116 Ilustración 139: Esquema del evento BeginPlay dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ______118 Ilustración 140: Esquema de los eventos Izq-Der & Atras-Alfrende dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ______119 Ilustración 141: Esquema del evento UpdateWorldEvent dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ______119 Ilustración 142: Esquema del evento Interactuar/Aceptar dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ______120 Ilustración 143: Esquema del evento Interactuar/Aceptar dentro de menús de Personaje_BP en Quito Quest (Ronquillo, 2019) ______120 Ilustración 144: Esquema del evento Objectives/Menu de Personaje_BP dentro de Quito Quest (Ronquillo, 2019) ______121 Ilustración 145: Esquema de los eventos MoveDown/Backward, MoveUp/Forward, MoveRight & MoveLeft para el control de animaciones dentro de Pesonaje_BP en Quito Quest (Ronquillo, 2019) ______121 Ilustración 146: Esquema de los eventos MoveDown/Backward, MoveUp/Forward, MoveRight & MoveLeft para navegación dentro de Widgets dentro de Pesonaje_BP en Quito Quest (Ronquillo, 2019) ______122 Ilustración 147: Esquema del evento PauseGame dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ______122 Ilustración 148: Esquema del evento Cancelar/Salir dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ______122 Ilustración 149: Esquema de la función YearMenu dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ______123 Ilustración 150: Esquema de la función OpenSubMenu dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ______123 Ilustración 151: Esquema de la función DoSomethingInSubMenu dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ______124 Ilustración 152: Esquema de la función StartQuestLog dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ______124 Ilustración 153: Esquema de la función LoadPartyData dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ______125 Ilustración 154: Esquema de la función LoadItems dentro de Personaje_BP en Quito (Ronquillo, 2019) ______125 Ilustración 155: Esquema de la función UpdateWorld dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ______126 Ilustración 156: Esquema de la función UpdateInteractableObjects dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ______126

xviii

Ilustración 157: Esquema de la función UpdateWorldLight dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ______127 Ilustración 158: Esquema de la función AddNewQuestToLog dentro del componente QuestLog en Quito Quest (Ronquillo, 2019) ______129 Ilustración 159: Esquema de la función UpdateLog dentro del componente QuestLog en Quito Quest (Ronquillo, 2019) ______129 Ilustración 160: Esquema de la función CheckLog dentro del componente QuestLog en Quito Quest (Ronquillo, 2019) ______129 Ilustración 161: Esquema del evento BeginPlay dentro de NPC_TypeA_BP en Quito Quest (Ronquillo, 2019) ______130 Ilustración 162: Esquema de los eventos EnSuperposicion & FinSuperposicion dentro de NPC_TypeA_BP en Quito Quest (Ronquillo, 2019) ______131 Ilustración 163: Esquema del evento MoveToRandomLocation dentro de NPC_TypeA_BP en Quito Quest (Ronquillo, 2019) ______131 Ilustración 164: Esquema del evento Animar dentro de NPC_TypeA_BP en Quito Quest (Ronquillo, 2019) ______131 Ilustración 165: Esquema de la función StartDialogue dentro de NPC_TypeA_BP en Quito Quest (Ronquillo, 2019) ______132 Ilustración 166: Esquema de la función SetDialogue dentro de NPC_TypeA_BP en Quito Quest (Ronquillo, 2019) ______132 Ilustración 167: Esquema de los eventos InicioPersepcion y FinPersepcion dentro de Enemy_BP en Quito Quest (Ronquillo, 2019) ______134 Ilustración 168: Esquema del evento ChasePlayer dentro de Enemy_BP en Quito Quest (Ronquillo, 2019) ______134 Ilustración 169: Esquema del evento EnSuperposicion dentro de LocationMarker_BP en Quito Quest (Ronquillo, 2019) ______135 Ilustración 170: Esquema de la función CheckLocation dentro de LocationMarker en Quito Quest (Ronquillo, 2019) ______136 Ilustración 171: Esquema de la función CheckDayTime dentro de Light_BP en Quito Quest (Ronquillo, 2019) ______136 Ilustración 172: Esquema de la función PlaySound dentro de Sound_BP en Quito Quest (Ronquillo, 2019) ______137 Ilustración 173: Esquema del evento NewLevelInteract dentro de LevelLoader_BP en Quito Quest (Ronquillo, 2019) ______138 Ilustración 174: Esquema del evento LoadLevel dentro de LevelLoader_BP en Quito Quest (Ronquillo, 2019) ______138 Ilustración 175: Esquema del evento InteractStore dentro de Store_BP en Quito Quest (Ronquillo, 2019) ______138 Ilustración 176: Esquema del evento LlenarDatos dentro de InteractableObject_BP en Quito Quest (Ronquillo, 2019) ______139 Ilustración 177: Esquema de la función Interact dentro de InteractableObject_BP en Quito Quest (Ronquillo, 2019) ______140 Ilustración 178: Esquema de la función SetNewConversation dentro de InteractableObject_BP en Quito Quest (Ronquillo, 2019) ______140 Ilustración 179: Esquema de la función DialogueCreate dentro de InteractableObject en Quito Quest (Ronquillo, 2019) ______141

xix

Ilustración 180: Esquema de la función DialogueGetLine dentro de InteractableObject_BP en Quito Quest (Ronquillo, 2019) ______142 Ilustración 181: Esquema de la función DialogueSendLine dentro de InteractableObject_BP en Quito Quest (Ronquillo, 2019) ______143 Ilustración 182: Esquema de la función GiveItem dentro de InteractableObject_BP en Quito Quest (Ronquillo, 2019) ______143 Ilustración 183: Esquema de la función CheckInteracted dentro de InteractableObject_BP en Quito Quest (Ronquillo, 2019) ______144 Ilustración 184: Esquema del evento BeginPlay dentro de Car_BP en Quito Quest (Ronquillo, 2019) ______145 Ilustración 185: Esquema del evento MoveToNextPoint dentro de Car_BP en Quito Quest (Ronquillo, 2019) ______146 Ilustración 186: Esquema de los eventos EnSuperposicion & FinSuperposicion dentro de Car_BP en QuitoQuest (Ronquillo, 2019) ______146 Ilustración 187: Esquema del evento Marcar dentro de Car_BP en Quito Quest (Ronquillo, 2019) ______147 Ilustración 188: Esquema de la función CheckDayTime dentro de Car_BP en Quito Quest (Ronquillo, 2019) ______147 Ilustración 189: Esquema del evento SwitchLightColors dentro de Semaforo_BP en Quito Quest (Ronquillo, 2019) ______148 Ilustración 190: Esquema del evento SpawnCars dentro de ClonadorCarros_BP en Quito Quest (Ronquillo, 2019) ______149 Ilustración 191: Esquema de los eventos EnSuperposicion & FinSuperposicion dentro de ClonadorCarros_BP en Quito Quest (Ronquillo, 2019) ______150 Ilustración 192: Diagrama entidad relación en Quito Quest (Ronquillo, 2019) ______151 Ilustración 193: Esquema de la fase I en Quito Quest (Ronquillo, 2019) ______154 Ilustración 194: Esquema de la fase II en Quito Quest (Ronquillo, 2019) ______154 Ilustración 195: Esquema de la fase III en Quito Quest (Ronquillo, 2019) ______155 Ilustración 196: Esquema de la fase IV en Quito Quest (Ronquillo, 2019) ______155 Ilustración 197: Esquema de la fase V en Quito Quest (Ronquillo, 2019)______155 Ilustración 198: Esquema de interconexión de niveles dentro de 2019 en Quito Quest (Ronquillo, 2019) ______156 Ilustración 199: Esquema de interconexión de niveles dentro de 1999 en Quito Quest (Ronquillo, 2019) ______156 Ilustración 200: Esquema de interconexión de niveles dentro de 1989 en Quito Quest (Ronquillo, 2019) ______157 Ilustración 201: Resultados de los cambios de la configuración gráfica para la recreación de las tres eras (Ronquillo, 2019) ______160 Ilustración 202: Resultados de cambios de la configuración grafica del juego (Ronquillo, 2019) ______161 Ilustración 203: Resultados de personajes no jugables (Ronquillo, 2019) ______162 Ilustración 204: Resultados del sistema de tráfico (Ronquillo, 2019) ______163 Ilustración 205: Resultados del sistema de misiones (Ronquillo, 2019) ______164 Ilustración 206: Resultados del sistema de conversación (Ronquillo, 2019) ______165 Ilustración 207: Resultados del sistema de tienda (Ronquillo, 2019) ______165 Ilustración 208: Resultado del sistema de combate (Ronquillo, 2019) ______166

Ilustración 209: División de grupos de edades del grupo de prueba (Ronquillo, 2019) ___ 167 Ilustración 210: División por genero del grupo de prueba (Ronquillo, 2019) ______167 Ilustración 211: Plataforma preferida para jugar en el grupo de prueba (Ronquillo, 2019) ______168 Ilustración 212: Experiencia con RPGs o JRPGs en el grupo de prueba (Ronquillo, 2019) 168 Ilustración 213: Interés por el concepto del juego en el grupo de prueba (Ronquillo, 2019) ______169 Ilustración 214: Factibilidad de desarrollar juegos de rol en el país (Ronquillo, 2019) __ 169 Ilustración 215: Interés por ver el juego terminado por el grupo de prueba (Ronquillo, 2019) ______170 Ilustración 216: Gusto por el sistema de conversación en el grupo de prueba (Ronquillo, 2019) ______170 Ilustración 217: Gusto por el sistema de tienda en el grupo de prueba (Ronquillo, 2019) _ 171 Ilustración 218: Gusto por el sistema de combate en el grupo de prueba (Ronquillo, 2019) ______171 Ilustración 219: Factibilidad del sistema de combate implementado en un juego entero por el grupo de prueba (Ronquillo, 2019) ______172

xxi

LISTA DE TABLAS

Tabla 1: Ejemplos de combate basado en turno. (Ronquillo, 2019) ...... 10 Tabla 2: Motores de desarrollo de videojuegos de uso publico (Ronquillo, 2019) ...... 18 Tabla 3: Ejemplos de JRPGs desarrollados en Unreal Engine 4 (Ronquillo, 2019) ...... 19 Tabla 4: Tipos de datos esenciales dentro de Unreal Engine 4 (Nixon, 2017) ...... 27 Tabla 5: Fases de desarrollo de un videojuego. (Aleem, Capretz, & Ahmed, 2016) ...... 31 Tabla 6: Ejemplos de reusabilidad de gráficos en videojuegos. (Ronquillo, 2019) ...... 32 Tabla 7: Ejemplos de estilos visuales (Ronquillo, 2019) ...... 37 Tabla 8: Ejemplo de diferencia de calidad entre juego prototipo y versión final de un videojuego. (Ronquillo, 2019)...... 40 Tabla 9: Ejemplo mostrando prototipo en 2D para un juego en 3D. (Ronquillo, 2019) ...... 41 Tabla 10: Ejemplos de distintos activos de diseño. (Ronquillo, 2019) ...... 43 Tabla 11: Ejemplos de elementos de interfaz grafica (Ronquillo, 2019) ...... 44 Tabla 12: Personajes dentro del party de 2019 (Ronquillo, 2019) ...... 59 Tabla 13: Personajes dentro del party en 1999 (Ronquillo, 2019) ...... 60 Tabla 14: Personajes dentro del party en 1989 (Ronquillo, 2019) ...... 60 Tabla 15: Atributos de los personajes en Quito Quest (Ronquillo, 2019)...... 61 Tabla 16: Atributos de los ítems en Quito Quest (Ronquillo, 2019) ...... 62 Tabla 17: Puntos adicionales según cartas en el montón en el juego de “Cuarenta” (Cardsgames) ...... 70 Tabla 18: Atributos de los enemigos en Quito Quest (Ronquillo, 2019) ...... 72 Tabla 19: Estados del enumerador MainMenu_Enum en Quito Quest (Ronquillo, 2019) ..... 73 Tabla 20: Estados del enumerador CurrentYear_Enum en Quito Quest (Ronquillo, 2019)... 73 Tabla 21: Estados del enumerador ItemTypes_Enum en Quito Quest (Ronquillo, 2019) ...... 73 Tabla 22: Estados del enumerador PlayerStatus_Enum en Quito Quest (Ronquillo, 2019) .. 74 Tabla 23: Estados del enumerador DateTime_Enum en Quito Quest (Ronquillo, 2019) ...... 74 Tabla 24: Estados del enumerador PlayerFacing_Enum en Quito Quest (Ronquillo, 2019) . 74 Tabla 25: Estados del enumerador GameLanguage_Enum en Quito Quest (Ronquillo, 2019) ...... 74 Tabla 26: Estados del enumerador ObjectiveType_Enum en Quito Quest (Ronquillo, 2019) 75 Tabla 27: Estados de enumerador SemaforoEstados_Enum en Quito Quest (Ronquillo, 2019) ...... 75 Tabla 28: Estados del enumerador Combat_Enum en Quito Quest (Ronquillo, 2019) ...... 75 Tabla 29: Variables dentro del Item_Struct en Quito Quest (Ronquillo, 2019) ...... 76 Tabla 30: Variables dentro del PartyMember_Struct en Quito Quest (Ronquillo, 2019)...... 76 Tabla 31: Variables dentro del Party_Struct en Quito Quest (Ronquillo, 2019) ...... 76 Tabla 32: Variables dentro del QuestData_Struct en Quito Quest (Ronquillo, 2019) ...... 77 Tabla 33: Variables dentro del WidgetData_Struct en Quito Quest (Ronquillo, 2019) ...... 77 Tabla 34: Variables dentro del WorldLight_Struct en Quito Quest (Ronquillo, 2019) ...... 77 Tabla 35: Variables dentro de Time_Struct en Quito Quest (Ronquillo, 2019) ...... 77 Tabla 36: Variables dentro de QuestTime_Struct en Quito Quest (Ronquillo, 2019)...... 78 Tabla 37: Variables dentro NPCTime_Struct en Quito Quest (Ronquillo, 2019) ...... 78 Tabla 38: Variables dentro Cards_Struct en Quito Quest (Ronquillo, 2019) ...... 78 Tabla 39: Variables dentro de ObjectiveData_Struct en Quito Quest (Ronquillo, 2019)...... 78 Tabla 40: Variables dentro de Character_Struct en Quito Quest (Ronquillo, 2019) ...... 78

xxii

Tabla 41: Variables dentro de SimpleDialogue_Struct en Quito Quest (Ronquillo, 2019) .... 79 Tabla 42: Variables dentro de Character_Struct en Quito Quest (Ronquillo, 2019) ...... 79 Tabla 43: Variables dentro de ConversationObjective_Struct en Quito Quest (Ronquillo, 2019) ...... 79 Tabla 44: Variables dentro de Enemy_Struct en Quito Quest (Ronquillo, 2019) ...... 80 Tabla 45: Variables dentro de QuestObjectiveEnemy_Struct en Quito Quest (Ronquillo, 2019) ...... 80 Tabla 46: Variables dentro de Levels_Struct dentro de Quito Quest (Ronquillo, 2019) ...... 80 Tabla 47: Variables dentro de MontonPuntos_Struct en Quito Quest (Ronquillo, 2019) ...... 80 Tabla 48: Widgets auxiliares de combate en Quito Quest (Ronquillo, 2019) ...... 102 Tabla 49: Atributos en la blueprint QuitoQuestInstance en Quito Quest (Ronquillo, 2019) 110 Tabla 50: Acciones dentro de Quito Quest (Ronquillo, 2019) ...... 113 Tabla 51: Ejes en Quito Quest (Ronquillo, 2019) ...... 113 Tabla 52: Variables dentro de MainMenu_BP en Quito Quest (Ronquillo, 2019) ...... 114 Tabla 53: Componentes de Personaje_BP en Quito Quest (Ronquillo, 2019) ...... 117 Tabla 54: Variables dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ...... 118 Tabla 55: Asignación de acciones a sonidos dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) ...... 128 Tabla 56: Variables del componente QuestLog en Quito Quest (Ronquillo, 2019) ...... 128 Tabla 57: Componentes dentro de NPC_TypeA_BP en Quito Quest (Ronquillo, 2019) ...... 130 Tabla 58: Variables dentro de NPC_TypeB_BP en Quito Quest (Ronquillo, 2019)...... 130 Tabla 59: Componentes únicos de Enemy_BP en Quito Quest (Ronquillo, 2019) ...... 133 Tabla 60: Variables dentro de Enemy_BP en Quito Quest (Ronquillo, 2019) ...... 133 Tabla 61: Variables de InteractableObject_BP en Quito Quest (Ronquillo, 2019) ...... 139 Tabla 62: Componentes dentro de Car_BP en Quito Quest (Ronquillo, 2019) ...... 144 Tabla 63: Variables dentro de Car_BP en Quito Quest (Ronquillo, 2019) ...... 145 Tabla 64: Variables dentro de Semaforo_BP en Quito Quest (Ronquillo, 2019) ...... 147 Tabla 65: Variables dentro de ClonadorCarros_BP en Quito Quest (Ronquillo, 2019) ...... 149 Tabla 66: Relaciones entre tablas en Quito Quest (Ronquillo, 2019) ...... 152 Tabla 67: Niveles dentro de Quito Quest (Ronquillo, 2019) ...... 153 Tabla 68: Listado de elementos dentro de niveles en Quito Quest (Ronquillo, 2019) ...... 158 Tabla 69: Distribución de elementos dentro de niveles en Quito Quest (Ronquillo, 2019) .. 159

xxiii

GLOSARIO

 Ultima: Serie de videojuegos de rol inspirados en la fantasía, considerado uno de los videojuegos de computadora más importantes, y uno de los pilares del género RPG.  Wizardry: Serie de videojuegos de rol, uno de los juegos con más influencia su época temprana, notado como influencia directa de títulos japoneses como Dragon Quest o Final Fantasy.  PlayStore: Una plataforma de distribución digital de aplicaciones móviles, incluye la distribución de programas recreativos, además de videojuegos.  Android: Sistema operativo móvil de código abierto, desarrollado por Google.  PlayStation: Serie de consolas de sobremesa, desarrollados por la empresa Sony.  Sprites: Un término de gráficos por computadora utilizado para describir un mapa de bits bidimensional incluido en una escena. Utilizados predominantemente en juegos en 2D.  Jury Box: Juego de mesa popular en los Estados Unidos en los años 30, predecesor de los juegos de misterio y juegos de rol.  Tactics II: El primer juego de guerra en tener éxito comercial, conocido por popularizar el género.  Calabozos y Dragones: Juego de rol de fantasía lanzado en 1974, generalmente conocido como el padre del juego de rol moderno.  Wizardry: Proving Grounds of the Mad Overlord: Primer título de la serie Wizardry.  Koei: Compañía de desarrollo japonesa, conocida por popularizar los juegos de simulación en Japón.  Hydlide: Uno de los primeros ARPGs populares, lanzado en Japón en 1984 por T & Soft.  DragonSlayer: Otro de los primeros ejemplos de ARPG, generalmente nombrado pauta en la edad temprana del género.  The Legend of Zelda: Primer título de una larga serie de juegos de aventura que no usa elementos RPG.  Enix: Empresa de desarrollo de videojuegos japonesa, principalmente conocida por el desarrollo de la serie Dragon Quest.  Famicom: Conocida como Nintendo Entertainment System fuera de Japón, la primera consola de Nintendo y la más popular en la segunda mitad de la década de los 1980.  Weekly Shonen Jump: La más popular revista de novelas gráficas en Japón, extremadamente popular con adolescentes.  Cinemáticas: Es una secuencia dentro de un juego que no es interactiva. Son utilizadas para enseñar elementos de historia al jugador, así como para enseñar mecánicas.  Cuadro: También conocido como “Fotograma”, es cuantas veces se actualiza el juego durante un segundo, permitiendo una simulación.  Bugs: Es un problema que puede causar que un programa colapse o tenga un comportamiento inesperado.  Super Mario Bros.: Un juego de plataformas lanzado en 1985, uno de los videojuegos más conocidos e importantes.

xxiv

 Fallout: Juego de rol occidental lanzado en 1997, conocido por su escenario post apocalíptico y violento.  Render: Un término usado en computación para referirse al proceso de generar imágenes por computadora.

xxv

TITULO: Diseño general, escritura, desarrollo y programación de un videojuego de rol JRPG llamado “Quito Quest” Autor: Ronquillo Lugo Daniel Ignacio Tutor: Fis. Bayardo Gonzalo Campuzano Nieto

RESUMEN El Ecuador no es un país a la vanguardia dentro del desarrollo de videojuegos, mucho menos uno de sus géneros más específicos como son los JRPGs, sin embargo, esta clase de videojuegos son de los más rentables, jugados y longevos en el todo el mundo, además de ser con mejor potencial de explotación local, ya que suelen tener un gran énfasis en la creación de mundos interesantes y grandes historias, componentes esenciales de la cultura ecuatoriana no muy presentes fuera de sus fronteras. El siguiente proyecto integrador ha desarrollado un juego en 3D en el motor de desarrollo de videojuegos Unreal Engine 4 orientado a computadoras de casa para demostrar que efectivamente, un juego de rol puede ser desarrollado en el Ecuador. Ya que no existe una metodología centrada en el desarrollo de videojuegos se utilizó la metodología iterativa para el desarrollo de software, donde el videojuego y su funcionalidad mejora en varias iteraciones, adicionalmente se utilizó ingeniería de software de desarrollo de videojuegos, tomando en clave las distintas etapas para el desarrollo de uno, así como los conceptos esenciales a tomar en cuenta durante el diseño, de tal forma que se obtenga un juego de calidad, no solo funcione correctamente, sino que también sea divertido. El juego fue puesto en práctica a 12 estudiantes del Taller de Verano de Desarrollo de Videojuegos que tomó lugar en el Centro de Física de la Universidad Central del Ecuador en agosto de 2019, obteniendo resultados relativamente favorables en la implementación de sistemas de juego y su funcionalidad.

PALABRAS CLAVE: VIDEOJUEGOS/ JUEGOS DE ROL/ JRPG/ UNREAL ENGINE 4/ PROGRAMACIÓN/ DISEÑO DE VIDEOJUEGOS.

xxvi

TITLE: Overall design, spelling, development and coding of a JRPG videogame named “Quito Quest” Author: Ronquillo Lugo Daniel Ignacio Tutor: Fis. Bayardo Gonzalo Campuzano Nieto

ABSTRACT Ecuador is not a country among the leaders, regarding videogames development, much less on one of its most specific genres, such as JRPGs; nevertheless, this type of videogames is one the top selling, played and long standing worldwide, as well as the one with the highest potential of local development, with a big stress on interesting worlds and amazing stories, vital components of Ecuadorian culture, which are not very well known outside local borders. This integrating project has developed a 3D JRPG game within the videogame development engine Unreal Engine 4 targeted to the PC platform, in order to show that JRPGs can, be developed in Ecuador. As there is no specific methodology for videogame development, using iterative methodology for software development, where videogame and its functionality are improved upon iterations. Additionally, videogames development software was used, taking into account diverse steps to develop a videogame, as well as essential concepts to be considered for the design, so as to get a good quality game, properly working and fun. The game was tested with 12 students of the summer workshop for videogame development, taking place in the Physics Center of Universidad Central del Ecuador last August 2019, with relatively favorable results in the implementation of the videogames and functionality.

KEYWORDS: VIDEOGAMES/ ROLE PLAYING GAMES/ JRPG/ UNREAL ENGINE 4/ PROGRAMING/ VIDEO GAME DESIGN.

xxvii

INTRODUCCIÓN

El nombre videojuego se aplica a una gran gama de distintas cosas. Existe una infinidad de distintos tipos de videojuegos y cada uno puede funcionar como su forma única de entretenimiento. Al no existir una definición concreta para cada tipo, sino solo descripciones muy generales de género, se suele decir que todo medio de entretenimiento virtual es un videojuego. Pueden ser un deporte dentro de una computadora, programas de televisión o películas interactivas, juegos de mesa o de cartas digitales incluso pueden ser simulaciones de la vida real. Algunos videojuegos son expresiones de trabajo artístico o trabajos creados solo con un propósito financiero. (Owen, 2016) Actualmente los videojuegos cubren una gama tan variada, lo que los ha convertido en el medio de entretenimiento más rentable y popular del mundo (D' Argenio, 2018), el número de videojuegos, géneros y métodos de disponibilidad es tan grande que se puede decir que existe un videojuego del agrado de casi cualquier persona en el planeta. En la época más temprana del desarrollo de videojuegos (desde 1973 hasta finales de los años 1980) el desarrollo principal ocurría en dos países, Japón y Estados Unidos, con cada país desarrollando juegos únicos. Por lo general, los videojuegos japoneses más populares no suelen tener un enlace a alguna esencia de la cultura japonesa o ideales nacionales de ese país, en lugar usa la idea de venderse a un mercado en particular. Consecuentemente, esta estructura hizo que la cultura del juego japonés creara uno de los géneros más particulares en todo el ámbito de los videojuegos, el juego de rol japonés, o más comúnmente llamado, JRPG (Picard, 2013) Un RPG es un juego donde un jugador controla a uno o más personajes, generalmente diseñados por el mismo jugador, y los guía por una serie de aventuras o misiones. Crecimiento de personajes en poder y habilidad es usualmente, pero no necesariamente, una característica clave del género. Las siglas RPG vienen del término en inglés “role playing game”, que significa juego de rol. El nombre tiene orígenes en obras de teatro, donde un actor pretende ser algo que no es, o, en otras palabras, asume un rol. (Adams, 2014) El término JRPG nace con Dragon Quest en 1986, un RPG que combinó y simplificó los aspectos más populares de los RPGs desarrollados en occidente, en particular, uniendo el vasto mundo para explorar visto en Ultima1 con la lógica de juego y combate visto en Wizardry2. La combinación resulto un éxito total, con el juego resonando con la audiencia en Japón de esa época, creando una serie y un género que son extremadamente populares aun 30 años después. (Parish, 2016)

1 Ultima: Serie de videojuegos de rol inspirados en la fantasía, considerado uno de los videojuegos de computadora más importantes, y uno de los pilares del género RPG. 2 Wizardry: Serie de videojuegos de rol, uno de los juegos con más influencia su época temprana, notado como influencia directa de títulos japoneses como Dragon Quest o Final Fantasy. 1

Ilustración 1: Dragon Quest, el primer JRPG (Enix, 1986)3 El nombre JRPG se usa para distinguir a los RPGs desarrollados en Japón, ya que aun cuando este tipo de juegos posee todas las características presentes en un RPG, también tienen suficientes diferencias para ser únicos, la J de las siglas RPG viene a que este tipo de juegos fueron predominantemente definidos en Japón. Más que otro tipo de videojuegos un JRPG se caracteriza por influenciar o “jugar” con la emoción del jugador y en crear la ilusión de ser parte de una gran aventura ya que suelen tener un enfoque en historia y exploración, tanto en grande y pequeña escala, desde historias entre guerras de dioses e imperios hasta ser un estudiante de secundaria. (Schreier, 2012) Este documento detalla el desarrollo de un videojuego JRPG para computadoras, desde el desarrollo inicial de la mecánica básica del juego, el desarrollo de su historia y su mundo hasta la realización virtual del material creado.

3 (Giant Bomb, 2008) 2

1. Capítulo I: Definición del Problema

1.1 Antecedentes Como referencia al desarrollo de videojuegos a nivel nacional se buscó otras tesis desarrolladas dentro de la carrera de Ingeniería en Computación Grafica y videojuegos desarrollados de forma industrial en el país, adicionalmente se buscó trabajos internacionales que puedan servir de pauta para desarrollo de este tipo de videojuego. “Creación de un videojuego multiplataforma 2.5D en Unity 3D y Blender” un videojuego que permite al usuario ser un pequeño héroe que rescata a su princesa; este navega con personajes creados en 3D en un mundo 2D. (Arruelas, 2017) “Programación del videojuego La Dama” un videojuego como una herramienta de promoción de la cultura nacional, dando una orientación correcta a los diferentes elementos que lo conforman, con un enfoque atractivo y funcional, permitiendo que el manejo sea lo más intuitivo posible. (Santillán, 2016) El juego fue lanzado en abril de 2016 en la PlayStore4 y retirado en junio de 2018. “Inteligencia artificial aplicada al videojuego LLumpak desarrollado en plataforma Android” es un videojuego desarrollado en ambiente 3D, para dispositivos de plataforma Android5. La base del videojuego está enfocada en el problema social denominado Contaminación Ambiental. LLUMPAK considera múltiples actos que afectan al medio ambiente y al mismo tiempo genera algunas opciones para combatirla. (Andagoya, 2016) El juego fue lanzado en julio de 2016 en la PlayStore, ya no está disponible. “To Leave” videojuego desarrollado en plataforma 2D para PlayStation6 4 por la empresa ecuatoriana Freaky Creations. Narra la historia de Harm, quien lucha por escapar de la agobiante ciudad y de su vida a través de su puerta que le permite surcar los cielos. To Leave fue lanzado en el mes de junio del 2014. (Freaky Creations, 2014) “Guardián de tu Cuadra” es un pequeño juego en ambiente 2D que se encuentra en la página oficial de EMASEO, donde el personaje principal es un guardia que alerta a sus vecinos de no arrogar fundas de desechos fuera del contenedor asignado por EMASEO, es manejado con la barra espaciadora y las flechas de dirección. (Emaseo, 2012) “Fislab Kids” un juego que enseña los conceptos básicos de física a niños de 10 a 12 años, por medio de niveles donde se desarrollan temáticas como fuerza, masa, gravedad, poleas y máquinas simples poniendo a prueba habilidades motrices, de coordinación, sensoriales y cognitivas para superar cada nivel. (Dominguez & Lima, 2019)

4 PlayStore: Una plataforma de distribución digital de aplicaciones móviles, incluye la distribución de programas recreativos, además de videojuegos. 5 Android: Sistema operativo móvil de código abierto, desarrollado por Google. 6 PlayStation: Serie de consolas de sobremesa, desarrollados por la empresa Sony. 3

1.2 Planteamiento del Problema El país ha quedado atrasado en el medio de los videojuegos, ya que el desarrollo es muy escaso y de los pocos creados, la calidad no es comparable con productos internacionales, por lo que es un campo casi sin explotar localmente. Sin embargo, es uno con posibilidades de expansión. Una vez conocido el problema: ¿Es posible y factible desarrollar un JRPG en el país?

1.3 Justificación Este trabajo se realiza para probar que esta clase de videojuegos se pueden crear en el país, y pueden ser atractivos si tienen relación cultural con el mismo. Adicionalmente se propone que es la mejor forma de plasmar las aptitudes que un Ingeniero en Computación Gráfica tiene al concluir con el ciclo académico. El aporte de este proyecto será demostrar que esta clase de proyectos se pueden realizar localmente y servirá a aficionados de videojuegos, así como a aspirantes a desarrollarlos. En la práctica, el siguiente paso sería publicar en una tienda virtual o física, llamando la atención del consumidor e inversionistas para recaudar fondos y establecer una industria sostenible a gran escala.

1.4 Objetivos 1.4.1 Objetivo General Desarrollo de la mecánica, diseño y programación de un demo de un videojuego de rol del subgénero JRPG que tiene lugar en la ciudad de Quito. 1.4.2 Objetivos Específicos  Conocer los beneficios y limitaciones que se pueden tener al desarrollar videojuegos.  Conocer y aplicar metodologías que existen actualmente en el desarrollo de videojuegos.  Desarrollar un combate basado en turnos con relación a la historia del juego.  Crear una mecánica central del juego que sea innovadora e interesante.  Realizar mecánicas que complementen la mecánica central, además de diseño de niveles, personajes e historia, todo en relación con la mecánica central.  Desarrollar un videojuego que sea atractivo a una audiencia especifica.  Escribir una historia interesante con personajes llamativos y que generen empatía.

1.5 Alcance y Limitaciones Se desarrolló un videojuego semi 3D para la plataforma de Windows, consta con un mundo modelado en 3D y personajes como sprites7 2D. Estos elementos fueron implementados en Unreal Engine 4.20.1, para la creación del juego como tal se utilizó Blueprints lo que permite dar el comportamiento a todos los elementos del juego.

7 Sprites: Un término de gráficos por computadora utilizado para describir un mapa de bits bidimensional incluido en una escena. Utilizados predominantemente en juegos en 2D. 4

El juego consta tres personajes principales en tres épocas distintas, cada tiene su propia historia y personajes únicos. Este video juego pertenece a los juegos RPG del sub genero basado en turnos y siguiendo la pauta de este tipo de juego según son desarrollados en Japón, dentro del juego el jugador controla a cada personaje principal máximo 3 veces y puede explorar máximo 5 áreas del juego con cada uno, no es un juego de mundo abierto, cada área tiene una entrada y salida determinada además de solo poder ser explorada al cumplir ciertas condiciones. Cada personaje brinda mayoritariamente cambios estéticos sin cambiar necesariamente la mecánica del juego.

2. Capítulo II: Marco Referencial

2.1 Conceptos Básicos 2.1.1 Juego de rol (RPG) Adams define a un RPG como:

Un juego donde un jugador controla a uno o más personajes, generalmente diseñados por el mismo, y los guía por una serie de aventuras o misiones. Crecimiento de personajes en poder y habilidad es usualmente, pero no necesariamente una característica clave del género. (Adams, 2014) Technopedia indicó que un RPG tradicional tiene 3 elementos esenciales.  El personaje tiene características que pueden ser mejoradas en el transcurso de juego. (Technopedia, s.f.)  El combate utiliza menús para su funcionamiento. (Technopedia, s.f.)  Existe un fin bien definido a través de la historia. (Technopedia, s.f.) En la actualidad los RPGs modernos no tienen estos 3 elementos necesariamente, pero suelen usar uno o dos de ellos en combinación con elementos de otros géneros de videojuegos. La historia del RPG tiene sus raíces en obras de teatro y recreaciones históricas, juegos de mesa como Jury Box8 y Tactics II9 sirvieron como precursores de la temática de los RPGs originales. En 1974 Dave Arneson y Gary Gygax crearon Calabozos y Dragones10, estableciendo los conceptos básicos del RPG incluyendo puntos de ataque, combate basado en turnos, atributos, equipamiento, clases y la creación de personajes dentro de la historia. (Ramdas, 2017) Para 1975 estudiantes universitarios estaban adaptando las ideas de Calabozos y Dragones a videojuegos, los primeros juegos eran extremadamente primitivos, pero incluían todos los conceptos planteados por Arneson y Gygax. (Brewer, 2016)

Ilustración 2: pedit5 (también conocido como The Dungeon), uno de los primeros videojuegos RPG, (Rutherford, 1975)11

8 Jury Box: Juego de mesa popular en los Estados Unidos en los años 30, predecesor de los juegos de misterio y juegos de rol. 9 Tactics II: El primer juego de guerra en tener éxito comercial, conocido por popularizar el género. 10 Calabozos y Dragones: Juego de rol de fantasía lanzado en 1974, generalmente conocido como el padre del juego de rol moderno. 11 (Giant Bomb, 2010) 6

El mercado de la computadora casera permitió el nacimiento de los entonces llamados RPGs para computadoras (CRPGs) fue aquí donde se lanzaron los juegos anteriormente mencionados como Wizardry: Proving Grounds of the Mad Overlord12 y Ultima en 1981, estos títulos y sus secuelas popularizaron este género en las distintas computadoras caseras, y luego consolas, de la época. Con el lanzamiento de Dragon Quest en 1986 nace el JRPG y se genera una división entre los RPGs, ya que el oriente y occidente comenzaran a crear juegos que, a pesar de tener los mismos conceptos básicos, son utilizados de forma muy distinta, aquí aparece el termino western RPG (WRPG) para denominar a los RPGs desarrollados en el occidente. (Ramdas, 2017)

2.1.2 Videojuego de rol japonés (JRPG) En definición simple, un JRPG es RPG desarrollado en Japón, sin embargo, esto lleva varias connotaciones, ya que generalmente todo género de videojuegos fue popularizado en una región determinada y luego llevados a otras regiones. Otros géneros no hacen esta clase de distinción, por ejemplo, los juegos de plataforma fueron popularizados en Japón y posteriormente llevados a Estados Unidos, mientras que los juegos de disparos en primera persona fueron popularizados en Estados Unidos y después llevados al resto del mundo, a pesar de dicho proceso, no existe el subgénero de juego de plataformas americano ni juego de disparos japonés, ya que ambos tipos de juegos siguen las pautas de la región donde fueron creados originalmente. Esto, sin embargo, no es así en los RPGs. (Extra Credits, 2012) Para mediados de los años 1980 los RPGs aún no eran populares para el público en general, solo para los entusiastas por la computación, esto aplicaba tanto para occidente como para Japón. La popularidad de Wizardry y Ultima también se sentía en Japón, donde los desarrolladores japoneses también crearon empezaron a crear RPGs, así en 1981 la compañía japonesa Koei13 lanzó The Dragon & Princess, el primer RPG desarrollado en Japón.

Ilustración 3: The Dragon & the Princess, el primer RPG desarrollado en Japón. (Koei, 1981)14 Sin embargo, desde 1984 hasta 1987 el interés de los desarrolladores japonés cambiaría a lo denominado Action RPG (ARPG), un ARPG se diferencia de un RPG al no contar con combate basado en turnos, el jugador tiene el control directo de los personajes en combate de tiempo

12 Wizardry: Proving Grounds of the Mad Overlord: Primer titulo de la serie Wizardry. 13 Koei: Compañía de desarrollo japonesa, conocida por popularizar los juegos de simulación en Japón. 14 (Giant Bomb, 2014) 7 real. (How to make RPGs, s.f.) Siguiendo la pauta de títulos como Hydlide15 y DragonSlayer16 este fue el subgénero más popular durante esa época, incluso influenciando a títulos que no son considerados RPGs, pero que servirían también de influencia al género y ayudarían a su popularidad nacional e internacionalmente, como sería el caso con The Legend of Zelda17 en 1986, un título que no es un RPG ni JRPG, pero es considerado un título importante para el género al ayudar a la popularización de este.

Ilustración 4: The Legend of Zelda (Nintendo, 1986)18 En 1985 la compañía Enix19, que para entonces se enfocaba en el desarrollo de juegos para computadoras caseras, comenzaría a desarrollar para la Famicom20, que era en ese entonces la consola de sobremesa más popular en Japón, originalmente con planes con crear un juego de acción, el género más popular en el sistema en esa época, pero dos empleados de la compañía: Yuji Horii y Koichi Nakamura estaban interesados en crear un RPG después de quedar fascinados al ver Wizardry y Ultima en el Apple Fes ’83. Los ejecutivos de la compañía accedieron a esta petición asignando a Horii como director creativo del proyecto, él quería replicar la experiencia de los juegos que lo inspiraron, pero también simplificar su estructura para hacerlos atractivos al público en general, haciéndolos fáciles de entender y que no sea necesario tener experiencia en otros RPGs para poder disfrutarlos. (Takizawa, 1990) El juego fue lanzado en Japón el 27 de mayo de 1986 como Dragon Quest, inicialmente el juego tuvo ventas mediocres, pero después de una campaña de promoción en la popular revista Weekly Shonen Jump21 su popularidad subió considerablemente convirtiéndose en un enorme éxito con más de 1.5 millones de copias vendidas en Japón, fue tan popular el juego que transcendió grupos de edades, no solo fueron los adolescentes quienes jugaban, sino sus padres también. Así Japón no solo se enamoró del juego sino del género mismo. (Takizawa, 1990) Su y varias secuelas no sería ignorado por el resto de la industria japonesa, y siguieron varios otros juegos siguieron las pautas marcadas por Dragon Quest, de tal manera que el género RPG en Japón gano una identidad única que ha sido desarrollada mucho más y más al pasar de los

15 Hydlide: Uno de los primeros ARPGs populares, lanzado en Japón en 1984 por T & Soft. 16 DragonSlayer: Otro de los primeros ejemplos de ARPG, generalmente nombrado como pauta en la edad temprana del género. 17 The Legend of Zelda: Primer título de una large serie de juegos de aventura que no usa elementos RPG. 18 (Giant Bomb, 2008) 19 Enix: Empresa de desarrollo de videojuegos japonesa, principalmente conocida por el desarrollo de la serie Dragon Quest. 20 Famicom: Conocida como Nintendo Entertainment System fuera de Japón, la primera consola de Nintendo y la más popular en la segunda mitad de la década de los 1980. 21 Weekly Shonen Jump: La más popular revista de novelas gráficas en Japón, extremadamente popular con adolecentes. 8 años, de tal forma que para la época de los 90 los RPGs desarrollados en Japón y los desarrollados en occidente eran muy distintos. (Takizawa, 1990) Para fines del presente proyecto, la mayor diferencia entre los dos es que un JRPG da mayor enfoque a su historia y personajes, a diferencia de RPGs occidentales el personaje principal no es necesariamente una proyección del jugador, el personaje tiene su propia personalidad historia y motivaciones, no es un lienzo en blanco que el jugador llena con las cualidades que quiera, esta división entre jugador y personaje permite crear una historia cuidadosamente elaborada (De Pablos) Un JRPG cuenta una historia, un RPG hace que el jugador viva una.

2.1.3 Combate basado en turnos Según Panumate, Xiong e Iida, es una modalidad del juego donde el flujo se divide en una parte explícita, llamada turno. Donde los jugadores tendrán un tiempo limitado o ilimitado para pensar antes de tomar una decisión. Luego, el sistema de juego procesará la acción del jugador y el siguiente jugador será el propietario del siguiente turno, repitiendo el ciclo hasta cumplir algún objetivo. (Panumate, Xiong, & Iida, 2015) Esta es por lo general es una de las rupturas de inmersión más aceptadas, ya que logra dar orden a lo que en otro caso sería el caos y al darle reglas de jugabilidad. Cómo funciona el combate suele ser uno de los aspectos que definen un JRPG. (TVTropes, s.f.) El combate basado en turnos es derivado del combate basado en menús visto en los primeros videojuegos RPGs, ya que en estos juegos todas las acciones se realizaban a base de comandos por menús, incluyendo el movimiento básico de los personajes en el juego, aunque el combate basado en menús sería mejor ejemplificado por primera vez en el juego ya muchas veces mencionado anteriormente, Wizardry en 1981. (Pepe, 2017) Los RPGs occidentales seguirían utilizando el combate basado en turno hasta la mitad de la década de los 1990 cuando estos títulos comenzaron a utilizar combate en tiempo real con más y más frecuencia, en palabras de Findley esto fue porque:

Creo que esos juegos [los primeros RPGs] siempre quisieron ser juegos de acción. Creo que todos esos juegos basados en turno fueron así porque eso es todo lo que la tecnología permitía en ese entonces. (Findley, 2011) El abandono del combate basado en turnos por los RPG occidentales coincidió con la explosión de popularidad internacional de los JRPGs, juegos que utilizaron combate basado en turnos entonces y lo siguen haciendo actualmente, de tal forma que combate JRPG prácticamente se ha convertido en sinónimo con combate basado en turnos. (Pepe, 2017) Una de las características que definen un JRPG es su combate, ya que este suele ser uno de los sistemas del juego que resalta más que los demás. Si bien casi todos los RPGs siguen la pauta de Dragon Quest varios de ellos hacen algo distinto con la formula, ya sea cambiar la perspectiva del combate, hacer que el combate se base en un tiempo de recarga, que el personaje principal no sea el que pelee, o una combinación de varios de estos elementos. Además de ser basado en turnos el combate no tiene una característica en particular por lo que distintos

9 desarrolladores han hecho sistemas bastantes distintos entre ellos a partir de esta idea. (Hamilton, 2013)

Ilustración 5: Dragon Quest III: Soshite Ilustración 6: Final Fantasy IX (Square, Densetsu e... (Enix, 1988)22 2000)23

Ilustración 7: Persona 3: FES (Atlus, Ilustración 8: Pokémon Emerald 2007.)24 (Pokémon Co., 2004)25

Tabla 1: Ejemplos de combate basado en turno. (Ronquillo, 2019)

2.2 Marco Teórico 2.2.1 Inteligencia artificial Inteligencia artificial, abreviado I.A., en un videojuego, se refiere a las técnicas utilizadas para producir la ilusión de inteligencia en el comportamiento de los personajes no jugables. Es un agente electrónico que parece que puede pensar, evaluar y actuar en ciertos principios de la optimización y la coherencia para cumplir con una meta o propósito. Específicamente la percepción y acciones de un elemento dentro del mundo. (De la Cruz, 2016)

2.2.1.1 Agentes Dentro de la inteligencia artificial un agente se refiere a todo objeto que puede percibir y tomar acciones. Un agente recibe datos de su entorno por medio de un sistema de percepción basado en una variedad de posibles sensores (auditivos, visuales, entre otros) según la

22 (Giant Bomb, 2008) 23 (Giant Bomb, 2008) 24 (Giant Bomb, 2013) 25 (Giant Bomb, 2008) 10 información dada al agente puede decidir en tomar una variedad de posibles acciones. (Yu, 2018) Más directamente en los videojuegos, un agente es un personaje dentro del mundo del juego que tiene percepción de su entorno (el nivel donde se encuentra) y actúa (se puede mover, atacar al jugador, evadir obstáculos, entre otras acciones) según esa percepción. El agente suele ser representado por un avatar gráfico, como un modelo o una imagen. (Yu, 2018)

2.2.1.2 Inteligencia artificial en videojuegos Los agentes virtuales usados en los videojuegos por lo general no son considerados verdadera inteligencia artificial, y los que se mayormente se utilizan actualmente, técnicamente no lo son. (Yu, 2018) Frecuentemente, un agente virtual de un videojuego sigue una lista de reglas de tal forma que aparenta tener un nivel de inteligencia, pero su comportamiento rara vez es verdadera inteligencia artificial, simplemente sigue una lista de guías definidas. Aun cuando un agente aparente tener un nivel de alta complejidad, donde, por ejemplo, este pudiera caminar, dormir, comer, seguir al jugador, y simular emociones humanas, esta clase de agentes virtuales suelen seguir una serie de reglas condicionales que pueden ser implementadas por cualquier programador, aun cuando este no tenga experiencia con inteligencia artificial. (Yu, 2018)

2.2.1.3 El objetivo de la inteligencia artificial en los videojuegos El objetivo principal de la inteligencia principal en un videojuego no es ganarlo, es ayudar al diseñador a maximizar la diversión y satisfacción que el jugador experimenta. Por lo que el agente no debe de ser diseñado para jugar perfectamente, ni para vencer al jugador, sino el agente debe ser un obstáculo o un apoyo al jugador, es decir, sirve como balance a la dificultad del juego tal que este sea satisfactorio. (Yu, 2018) Esta es la razón es por la cual la inteligencia artificial dentro de los videojuegos no se la considera verdadera inteligencia artificial, en un sistema de verdadera inteligencia artificial cada agente está diseñado para poder cumplir el objetivo del sistema al que pertenece, mientras que un agente dentro de un videojuego suele ir en contra de este principio, el agente no trata de ganar el sistema, trata de hacer que ganarlo sea más interesante y satisfactorio para un jugador. (Yu, 2018) Según Brown una buena inteligencia artificial debe de contar con los siguientes elementos, dependiendo del juego: 1. Permitir al jugador hacer trampa, pero no en maneras que él pueda saberlo, sutilmente poner el balance del juego a favor del jugador de tal forma que parezca ser más justo para él. (Brown, 2017) 2. Permitir que el jugador sepa que está pensando, esta técnica sirve para que la inteligencia artificial parezca ser más inteligente de lo que es al comunicar información al jugador. Como se implementa puede variar altamente según el tipo de juego y puede ser mostrada también de muchas maneras. (Brown, 2017)

3. Ser predecible, al menos hasta cierto punto, debe de tener cierta consistencia en sus acciones, de tal forma que según que haga el jugador este pueda esperar que el agente responda de cierta manera. (Brown, 2017) 4. Responder a las acciones del jugador de alguna manera. (Brown, 2017)

2.2.1.4 Percepción Un agente se define por su habilidad de percibir y actuar, en los videojuegos la percepción del actor crea la ilusión que este tiene sentidos similares a los de una persona o animal; es aparentar que el agente tiene una especie de limites cognoscitivos, aun cuando por ser un programa de computadora siempre sabe dónde está el jugador y que está haciendo. (Yu, 2018) Un agente que siempre sabe dónde está el jugador no serviría para un juego interesante, por lo cual los agentes tienen una percepción limitada, indirectamente haciendo que sea menos inteligente. (Yu, 2018)

2.2.1.4.1 Elementos de percepción Los elementos de percepción de un agente, también llamados módulo de sentidos y percepción o módulo de conciencia, incluye los siguientes elementos:  Conciencia de su entorno  Separación de aliados y enemigos.  Seguimiento de objetivos (¿Cuál es la posición del objetivo?)  Línea de visión (¿Puede el agente ver al objetivo si este está detrás de un obstáculo?)  Angulo de visión.  Identificación de objetos (¿Puede el agente identificar objetos dentro del mundo, elementos como ítems, armas?)  Rango de ataque (de ser el caso)  Visión

2.2.1.5 Árbol de decisiones Brid lo describe como una herramienta de apoyo que usa un modelo de decisiones con sus posibles consecuencias, resultados, costos y utilidades. Es una manera de graficar un algoritmo que únicamente utiliza sistemas de control. (Brid, 2018) Dentro de los videojuegos un árbol de decisión ayuda a un agente a decidir sobre qué acción tomar en base a ciertas condiciones o eventos. Dado que el proceso de decisión del agente puede tener una alta complejidad un árbol de decisión puede ser extremadamente extenso y complejo. (Yu, 2018)

Inicio

¿Se satisface la condicion A?

Si No

Realizar una ¿Se satisface la accion condicion B?

Si No

Realizar una Realizar una accion accion

Ilustración 9: Ejemplo de un árbol de decisiones (Ronquillo, 2019) Un árbol de decisión puede tener un numero n de condiciones según requiera el sistema, para un programador aplicar este sistema es relativamente simple ya que solo requiere de condicionales y no necesita de conocimiento de verdadera inteligencia artificial. (Yu, 2018)

2.2.2 Componentes de un JRPG 2.2.2.1 Escenario temático No refiere a los escenarios virtuales, incluye la historia del juego y de su mundo, su geografía, las distinta razas, culturas y religiones que lo pueden habitar, así como las tradiciones y leyendas de este. Un RPG está diseñado para que el jugador pueda verse inmerso en un mundo ficticio y el escenario es el conjunto de todos los elementos del mundo. (LevelSkip, 2016) Dependiendo de cuál sea la inspiración del mundo (ya sea basado en fantasía o algo en la vida real) se determina que tanto deben ser explorados y detallados son estos elementos. Este es uno de los principales elementos que diferencian a los juegos de este género y uno de los pilares que hacen que un RPG sea único. (LevelSkip, 2016) Los conceptos principales del juego deben de verse reflejados en su escenario, sea creado a base de esos conceptos o viceversa. (LevelSkip, 2016)

2.2.2.2 Narrativa dramática También conocida más simplemente como la historia del juego. Como ya se ha mencionado anteriormente los RPGs suelen ser caracterizados por tener un enfoque en su historia, en especial en los JRPGs donde se les da más importancia a los personajes. Por lo general en un JRPG el jugador tiene un desafío de altas proporciones, es importante que sea acompañado por una historia para así crear una mayor inmersión del jugador. (LevelSkip, 2016) Staats define a la narrativa dramática de un RPG en 3 principios: 13

1. Mantener un sentido de asombro a través de la historia: Siempre debe haber una sorpresa esperando al jugador, sirve para hacer que la historia, y el mundo sean únicos. (Staats) 2. Debe ser entretenido: Un RPG puede tener excelentes mecánicas, pero si tiene una mala historia puede hacer que toda la experiencia sea mala, la historia no tiene que ser extremadamente larga o compleja, pero debe mantener el interés del jugador. (Staats) 3. Debe recompensar al jugador, así como a sus personajes: El personaje sirve como el avatar del jugador en el mundo, pero este personaje, así como los demás del personaje, son sus propios seres dentro de la historia; una buena narrativa dramática en un JRPG se desarrolla de una forma que es coherente para los personajes y satisfactoria para el jugador. (Staats) La historia puede ser relatada por cinemáticas26 o por interacciones con los elementos y sistemas del juego, principalmente con los personajes del juego. Pueden también existir sub- historias dentro, removidas de la historia principal, que involucran a los demás personajes del juego. (LevelSkip, 2016)

2.2.2.2.1 Desarrollo de personajes Indica que tan formado y complejo es un personaje. Dentro de un JRPG pueden ya estar desarrollados o se desarrollan durante los eventos del juego, por lo general los personajes que utiliza el jugador suelen ser simples, de tal forma que la experiencia del juego sea nueva para ellos y para el jugador. Mientras que otros, como los de apoyo y los antagonistas, suelen empezar más desarrollados, ya con características bien establecidas que no suelen cambiar en el transcurso de la historia. (Janovsky, 2018) Un personaje sirve para extender la narrativa, y pueden existir de distintas clases; toda historia debe de tener uno o más personajes principales, son los que más afectan a la historia según sus acciones y son los más afectados por sus actos. (Janovsky, 2018) En un JRPG es común que exista un grupo de personajes principales unidos por el bien de la historia, puede existir un personaje que tiene más importancia en la historia que otros, rara vez existe solo un personaje principal. Trabajo en equipo y el poder de la amistad suele ser un cliché usado de forma constante en los JRPGs. (Janovsky, 2018)

2.2.2.2.2 Protagonista y antagonista El protagonista genera la acción de la historia y genera el interés y empatía del jugador, casi siempre es el personaje que el jugador controla directamente, aunque pocos, no son desconocidos JRPGs donde el protagonista de la historia no es el personaje controlado por el jugador. (Janovsky, 2018) A su opuesto existe el antagonista, que suele ser el obstáculo final y/o principal través de la historia del juego. Por lo general es la fuente del conflicto dentro de la historia. Comúnmente,

26 Cinemáticas: Es una secuencia dentro de un juego que no es interactiva. Son utilizadas para enseñar elementos de historia al jugador, así como para enseñar mecánicas. 14 pero no siempre, un antagonista es el villano de la historia del juego, su derrota suele marcar el fin de la historia y el fin del juego. (Janovsky, 2018)

2.2.2.3 El mundo del juego El mundo del juego es el universo artificial diseñado por los desarrolladores donde ocurren todos los eventos del juego, este es presentado al jugador mediante elementos audiovisuales, como son elementos en 2D/3D, música y efectos de sonido. (Adams, 2014) Uno de los objetivos del mundo es ser entretenido para el jugador por sí mismo, dándole la oportunidad de tener un espacio en donde explorar e interactuar. Es otra característica fundamental de un RPG ya que esta clase de videojuegos suelen dar libertad al jugador para explorar y poder sumergirse en el mundo. (Adams, 2014) El diseño del mundo debe basarse en el concepto del juego, así como el entorno temático y su historia. El mundo está conformado por los niveles y debe de ser definido según ciertas propiedades, o más comúnmente llamadas dimensiones, que según Adams son:  Dimensión física: Define en cuantas dimensiones existe el juego, si es en 2D o 3D además de que tan grande será el mundo del juego; en que escala está, la velocidad en la que se pueden mover objetos dentro de él y que límites físicos tiene. (Adams, 2014)  Dimensión temporal: Define si el pasar del tiempo tiene importancia en el mundo, y de ser el caso como este lo afecta, es decir cómo se modifica el mundo a través del tiempo, por ejemplo: que cambios pueden suceder de pasar del día a la noche. (Adams, 2014)  Dimensión ambiental: Define el cómo se ve el juego, tiene que ver con el entorno y con el estilo visual del juego, determina detalles estéticos, cómo estos se derivan del escenario temático y cómo se interrelacionan entre sí. (Adams, 2014)  Dimensión emocional: Detalla si alguna emoción en particular es importante en la historia y cómo esta afecta a los personajes y al mundo, además de buscar una respuesta emocional del jugador. (Adams, 2014)  Dimensión ética: Define qué es considerado correcto e incorrecto en el mundo del juego, si existe algún conflicto en el mundo y que parte tiene el jugador en él. Mundos de juegos más complejos pueden dar libertad al jugador en tomar decisiones éticas. (Adams, 2014)

2.2.2.3.1 Construcción del mundo Es el proceso de fabricar un mundo ficticio y presentárselo al jugador, más puntualmente es el acto de crear y diseñar universos ficticios donde conviven varias historias. La construcción del mundo es un componente esencial en un RPG ya que es uno de los elementos que le permiten al jugador sumergirse en el juego. En un mundo bien construido el jugador no le dará importancia al hecho de que el mundo ficticio no tiene sentido en relación con el mundo real. (Schrier, Torner, & Hammer, 2018) La construcción del mundo principalmente indica cómo se le explica el mundo del juego al jugador, sea detalles como: la historia del mundo, su diseño, culturas, personajes, entre otros. Interacciones con otros personajes, diseño de ciertos elementos del entorno, diseños de los

15 personajes mismos, y partes en la historia del juego son utilizados tal que el jugador aprenda detalles del mundo de forma sutil e indirecta. (Schrier, Torner, & Hammer, 2018) El diseñador debe construir el mundo durante el diseño y desarrollo, luego el jugador lo vuelve a interpretar para sí mismo mientras juega. (Schrier, Torner, & Hammer, 2018)

2.2.2.4 Party Incluye a todos los personajes que pueden ser controlados por el jugador. Por lo general los miembros de este grupo tienen sus propias historias y personalidades fuera de la historia del personaje principal y son uno de los componentes más importantes del juego, ya que son el apoyo principal del jugador a través de la historia, y frecuentemente las interacciones con los otros miembros del grupo son una de las partes más memorables del juego. (TVTropes, s.f.)

2.2.2.4.1 Progresión de personajes Los miembros del party deben cambiar en el transcurso del juego, y no solo mediante la historia de este. Se puede ser dar de varias maneras, los RPGs permiten al jugador ver atributos de los personajes, que por lo general incluyen datos como fuerza, inteligencia, actividad, puntos de vida, puntos de magia, entre otros, dependiendo del juego. (LevelSkip, 2016) Los JRPGs no solo permiten que el jugador vea estos tributos, sino también permiten que el jugador los modifique en el transcurso del juego. La forma en que estos valores se alteran puede ser implementada en un sin número de maneras, y como hacerlo es otro rasgo que diferencia a un JRPG de otro. (LevelSkip, 2016) Una de las mecánicas más simples para demostrar progresión de personajes es por medio de sus niveles. Cada vez que el jugador cumple una acción dentro del mundo (vencer a un enemigo, completar un nivel, entre otros) este puede ganar una cierta cantidad de puntos de experiencia, cuando estos puntos llegan a cierto total el personaje sube de nivel y sus atributos cambian de alguna manera y/o gana una nueva habilidad que pueda servir dentro del juego, por lo general esto es considerado uno de los elementos más satisfactorios del género (LevelSkip, 2016)

2.2.2.5 Items En un videojuego un ítem es un elemento que el jugador puede coleccionar, los RPGs son un género donde son un elemento muy importante, ya que su colección puede ser uno de los objetivos principales y son una mecánica usada durante su totalidad, además de ser uno de los géneros donde son más numerosos. (Rogers, 2014) Se pueden clasificar a los ítems dentro de un RPG de dos maneras.  Items importantes: Elementos de alta importancia en la historia o mundo del juego, el jugador, por lo general, no puede usarlos normalmente durante el juego, solo en situaciones muy específicas, no es poco común ver en RPGs, principalmente en los desarrollados más tempranamente, que el coleccionar un numero de ítems sea el objetivo principal del juego. (Rogers, 2014)

 Items consumibles: Son ítems que el jugador puede usar normalmente en el juego, por lo general son fáciles de conseguir y muy numerosos, esta clase de ítems pueden modificar temporal o permanentemente los distintos atributos de los personajes del juego. (Rogers, 2014)

2.2.3 Motores de desarrollo de videojuegos Un motor de desarrollo de videojuegos es la arquitectura que los desarrolladores usan para que el juego funcione, por lo general un motor suele contar con las siguientes características:  Sistema de física  Sistema de datos entrada  Representación visual del juego  Programación  Inteligencia artificial Es importante porque se lo usa para construir el marco de referencia del juego dándoles tiempo al equipo de desarrollo para enfocarse en elementos como los modelos, sus texturas y la interacción de los objetos en el mundo del juego. Los motores de desarrollo son usados a través de toda la industria de videojuegos en la actualidad, de no ser por ellos el desarrollo de videojuegos sería una tarea que tardaría mucho más tiempo y sería mucho más difícil. (GameDesign, 2019) En la actualidad varias compañías crean sus propios motores para desarrollo interno; las características, e incluso los nombres de varios de estos motores no son revelados al público, pero también existen compañías enfocadas en el desarrollo y soporte de los motores de videojuego para uso público y comercial, estos motores suelen ser usados por compañías sin recursos para crear los suyos o los que deciden no hacer ese proceso, según sus necesidades. (GameDesign, 2019) Unity Motor multiplataforma que permite crear contenido interactivo con facilidad, suele ser usado en juegos relativamente simples, y como introducción al desarrollo de Ilustración 10: Logotipo de Unity (Unity videojuegos, no es común verlo en Technologies, s.f.) desarrollo de alto nivel.

GameMaker Studio Popular recientemente ya que permite el desarrollo de videojuegos sin la necesidad de tener conocimiento en programación, pero mucho más limitado que otros Ilustración 11: Logotipo de GameMaker motores. Igual que Unity es usado como Studio 2 (YoYo Games, s.f.) introducción al desarrollo de videojuegos.

CryEngine Un motor de alta capacidad, usado para grandes producciones, con especialización en la realidad virtual. Por la capacidad del Ilustración 12: Logotipo de CryEngine motor tiene una alta curva de aprendizaje. (Crytek, s.f.) RPG Maker Permite la creación de un juego completo, pero es muy limitado, perfecto para principiantes, pero no lo sufrientemente Ilustración 13: Logotipo de RPG Maker avanzado para expertos. Como su nombre (Kadokawa Games, s.f.) lo indica está especializado en la creación de RPGs, de hecho, es el único tipo de juegos que se pueden crear en el motor. Tabla 2: Motores de desarrollo de videojuegos de uso publico (Ronquillo, 2019)

2.2.4 Unreal Engine 4 Es un motor de desarrollo de videojuegos, es decir lo que es un programa especializado para el desarrollo de un videojuego, desarrollado por Epic Games. (Epic Games, s.f.) Unreal es un conjunto de herramientas de desarrollo diseñadas para cualquier persona que trabaje con tecnología en tiempo real. Permite la creación de aplicaciones desde empresariales y experiencias cinematográficas hasta juegos de alta calidad en PC, consola, móvil, VR y AR. (Epic Games, s.f.)

2.2.4.1 Por qué usar Unreal Engine 4 Unreal Engine es un potente motor de desarrollo que es de uso gratuito desde el lanzamiento de Unreal Engine 4 en 2015. El motor permite el desarrollo de videojuegos de todo nivel de complejidad y de todo género, su versatilidad ha permitido ser usado desde desarrollos independientes hasta los más grandes videojuegos, así como ser aplicado fuera del campo de los videojuegos, para la creación de simulaciones en tiempo real en el campo científico. Cuenta con una calidad gráfica muy alta, la más alta de entre todos los motores de uso público, además de incluir sistemas de iluminación dinámica y uso de partículas de forma gratuita. Este motor tiene una curva de aprendizaje alta ya que está pensado para desarrolladores más avanzados, es necesario tener cierta experiencia con otros motores para utilizarlo y aun así se necesitará una instrucción adicional para su uso correcto. Unreal Engine 4 ha sido adoptado por los desarrolladores en Japón y varios de los JRPGs más populares de los últimos años han sido desarrollados con este motor por lo que se prueba que es factible realizar este tipo de juegos en un este motor.

Ilustración 14: Dragon Quest XI: Echoes Ilustración 15: Final Fantasy VII of an Elusive Age (Square Enix, 2017)27 Remake (Square Enix, 2020)28

Ilustración 16: Kingdom Hearts III Ilustración 17: Octopath Traveler (Square Enix, 2019)29 (Nintendo, 2018)30

Tabla 3: Ejemplos de JRPGs desarrollados en Unreal Engine 4 (Ronquillo, 2019)

2.2.4.2 Elementos de Unreal Engine 4 2.2.4.2.1 Actores Es cualquier objeto que se puede agregar a un nivel dentro de Unreal, tengan comportamientos o no y pueden ser tanto objetos visibles para el jugador, como objetos de control sin apariencia física. (Nixon, 2017)

2.2.4.2.1.1 Tipos de actores  Actor de malla estática: Es el actor más común dentro del juego. Son usados para construir los niveles dentro del editor. Una malla es un término de modelado 3D, y se refiere a objetos dentro de una escena virtual. El termino estático se refiere a que estos

27 (Giant Bomb, 2016) 28 (IGN, 2017) 29 (IGN, 2017) 30 (Giant Bomb, 2018) 19

actores no tienen ningún tipo de comportamiento, no pueden afectar al juego ni pueden moverse. (Nixon, 2017)

Ilustración 18: Ejemplos de actores de malla estática (Nixon, 2017)

 Actores de luz: Una luz es un actor que genera luz en el nivel, no representan el objeto que genera luz, solo la luz misma. Dentro de Unreal también se pueden utilizar luces añadiendo un componente de luz a un actor. (Nixon, 2017)  Blueprints: Objetos con comportamiento, incluyen al jugador, así como los personajes y sistemas de apoyo, explicado con más detalle posteriormente.

2.2.4.2.2 Blueprints Dentro de Unreal un blueprint representa un actor dinámico o sistema dentro del juego. Permiten crear comportamientos para distintos actores y sistemas del juego, sea un movimiento físico dentro del juego o un sistema abstracto como los puntos de vida del jugador. Todo objeto dinámico dentro del juego en Unreal es un blueprint. (Tran, 2017)

Ilustración 19: Editor de blueprints dentro de Unreal Engine 4 (Ronquillo, 2019) Es el sistema de programación de Unreal Engine 4, pero en lugar de escribir código el programa se lo crea de forma enteramente visual, seleccionando nodos, dándoles propiedades y conectándolos entre sí para crear sistemas. Más claramente, y definido directamente por Epic Games:

El sistema lenguaje de escritura visual Blueprint en Unreal Engine es un sistema completo es escritura de juego estructurado en el concepto de usar una interfaz basada en nodos para crear elementos del juego dentro del editor. Este sistema es extremadamente flexible y eficaz ya que provee la habilidad a los diseñadores de usar prácticamente todos los conceptos y herramientas antes solo disponibles para programadores. (Epic Games, s.f.)

2.2.4.2.2.1.1 Gráfica de eventos Es la parte de un blueprint donde se programa la lógica del actor, funciona por medio de un lenguaje visual en base a C++ sin la necesidad de programar directamente, está conformada por nodos de ejecución, de datos y enlaces entre ellos. (Nixon, 2017)  Nodos de ejecución: Son todos los elementos que guardan la lógica del programa y pueden tomar distintas formas, desde sistemas complejos de eventos y funciones, así como elementos básicos de programación y toda clase de variables. (Nixon, 2017)

Ilustración 20: Nodos en la gráfica de eventos (Ronquillo, 2019)

 Nodos de datos: Se utilizan para pasar información de un nodo a otro. Igual que los nodos de ejecución, solamente guardan datos, no tienen comportamientos programados. (Nixon, 2017)

Ilustración 21: Nodos de datos en la gráfica de eventos (Nixon, 2017)

2.2.4.2.2.2 Eventos Es un nodo que se ejecuta cuando se cumple una acción dentro del mundo del juego, puede ser llamado al cumplirse una condición, así como por otro actor, este nodo puede estar conectado a un sin número de nodos adicionales que ejecutan una acción en el mundo del juego. (Nixon, 2017) Los eventos se diferencian de las funciones, no solo por su etiqueta roja dentro del gráfico de eventos, y porque se pueden ejecutar varios a la vez, además porque se pueden poner retrasos de ejecución entre los nodos que conforman el evento, si no es necesario que todo se ejecute a la vez y porque los eventos no pueden tomar datos de entrada ni devolver datos al ejecutarse. (Nixon, 2017)

Todo blueprint comenzará con dos eventos elementales que son:  BeginPlay: Este evento es llamado cuando se inicia un nivel, es utilizado para aplicar cambios a actores al momento que se carga el nivel. (Nixon, 2017)  Tick: Este evento se ejecuta una vez cada cuadro31 mientras el blueprint este activo en el mundo de juego. Se utiliza cuando se necesita revisar condiciones constantemente, de tal forma que al momento de ser cumplidas el juego pueda ejecutar ciertas acciones. (Nixon, 2017)

Ilustración 22: Los eventos BeginPlay y Tick en el gráfico de eventos (Nixon, 2017) Se pueden crear varios eventos distintos dentro de un blueprint según sea necesario, se pueden llamar entre sí, pueden llamar a funciones y pueden llamar a eventos y funciones de otros actores. (Nixon, 2017)

2.2.4.2.2.3 Funciones Una función es un procedimiento o rutina destinado a llevar a cabo una o más tareas. Su uso no es necesario dentro de Unreal Engine 4, ya que prácticamente todo lo que realiza una función puede ser realizada por un evento, pero hay situaciones donde usar una función puede ser una mejor opción, depende finalmente del programador. (Nixon, 2017) El mejor uso de una función es la encapsulación de un proceso largo y/o complejo fuera de la gráfica de eventos principal, ya que cada función cuenta con su propia grafica de eventos, dentro de esta se puede llamar a toda la función con un solo nodo sin tener que preocuparse por los detalles dentro. Lo que permite un mejor control dentro de blueprints muy extensos, así como llamar fácilmente más de una vez a una instrucción de ser necesario. (Nixon, 2017)

31 Cuadro: También conocido como Frame, es cuantas veces se actualiza el juego durante un segundo, permitiendo una simulación. 22

2.2.4.2.2.3.1 Ventajas del uso de funciones. Nixon propone cuatro ventajas al uso de funciones en Unreal. 1. Reusabilidad: Si se necesita utilizar el mismo proceso dentro de un blueprint, el uso de métodos facilita esta configuración, ya que no hay que colocar los mismos nodos una y otra vez. (Nixon, 2017) 2. Editabilidad: Es muy fácil realizar modificaciones en una función, si este presenta errores, al modificar el método se arreglan problemas que pueden suceder en todas las instancias en las que es llamado. (Nixon, 2017) 3. Confiabilidad: Si se utiliza una función una y otra vez se puede comprobar que funciona correctamente, pero de no ser el caso, al modificar la función se modifican todas sus instancias a través de todo el blueprint solucionando varios posibles errores a la vez. (Nixon, 2017) 4. Legibilidad: Una función puede tener docenas, cientos, o hasta miles de nodos, pero sin importar su número estos siempre se encapsulan en el nodo de la función al ser llamados externamente, ayuda mucho en el proceso de lectura de código. (Nixon, 2017)

2.2.4.2.2.4 Componentes Los componentes son varios objetos o funcionalidades que se las pueden agregar a los blueprints, incluyendo a otros actores o blueprints, por ejemplo, se puede agregar un componente de malla estática o un componente de luz. (Nixon, 2017)

Ilustración 23: Componentes en un Blueprint (Nixon, 2017)

2.2.4.2.2.4.1 Actor Component Es un actor que se puede agregar otros actores como componente, define un comportamiento a utilizar en varios actores distintos agilitando el proceso de desarrollo. Esta clase de

23 componentes puede tener sus propias variables, y como mencionado anteriormente, también sus propios métodos y eventos. (Nixon, 2017)

2.2.4.2.2.5 Blueprints especiales 2.2.4.2.2.5.1 Level Blueprint Guarda los datos e instrucciones de un nivel en particular y solo de ese nivel. Dependiendo de cómo se haya estructurado el videojuego se pueden usar, pero no es necesario su uso. Generalmente usado para eventos únicos que no son utilizados en el resto del juego y para los que crear blueprints adicionales sería un desperdicio de tiempo y recursos. (Nixon, 2017)

2.2.4.2.2.5.2 Game Mode Un game mode, o modo de juego, es un actor que se puede usar para definir y hacer cumplir las reglas del juego. Este actor se lo puede crear por nivel, pero también se lo puede reutilizar en varios niveles o hasta en todo el juego según sea necesario. De hecho, es recomendable que de ser necesario un game mode para el juego, este sea utilizado en más de un nivel, ya que el Level Blueprint está diseñado para ser usado de forma única por nivel. Un juego puede tener varios game modes, pero solo se puede usar uno por nivel. (Nixon, 2017) El game mode se lo crea como cualquier otro blueprint, solamente se debe especificar que es de clase Game Mode. Puede ser llenado con variables, métodos y eventos según sea necesario. (Nixon, 2017)

2.2.4.2.2.5.3 Peones Son actores que pueden ser controlados, sea por el jugador o por la misma computadora. Se utilizan para el actor que controlara el jugador dentro del juego, así como todos los personajes dentro del mismo, amigos y enemigos. (Nixon, 2017)

2.2.4.2.2.5.4 Personajes Son un tipo de actor que tiene toda la funcionalidad de los peones con unas funciones adicionales, en particular esta clase esta mejor configurada para el movimiento de personajes dentro del juego (de ahí su nombre) y por lo general es recomendado usar la clase de blueprints de personajes a la de peones. (Nixon, 2017)

2.2.4.2.2.5.5 Player Controller Dentro de Unreal, solo un actor puede aceptar datos de entrada del jugador se lo denomina Player Controller y que puede ser referenciado por cualquier blueprint dentro del juego. (Nixon, 2017)

2.2.4.2.2.5.5.1 Mapeo de entrada Unreal Engine permite asignar a interacciones que el jugador haga con el control del juego como un evento que se dispara dentro del juego, de tal manera que cuando se presione un botón, esta acción sea un evento que pueda ser llamado por el Player Controller. Unreal tiene la facilidad de permitir hacer cambios globales a que acciones disparan estos eventos, esto facilita configurar el juego a distintos dispositivos de entrada, sean controles, teclados, entre otros, al realizar un simple cambio global. (Nixon, 2017) Unreal Engine permite dos tipos de datos de entrada, llamados asignación de acciones y asignación de ejes. (Nixon, 2017)

Ilustración 24: Tipos de datos de entrada en Unreal Engine 4 (Ronquillo, 2019)

 Asignación de acciones: Se utilizan cuando se necesita que se ejecute un evento al presionar un botón, sin importar por cuanto tiempo. Un ejemplo de su uso seria utilizarlos para que un personaje salte. (Nixon, 2017)  Asignación de ejes: Utilizados cuando mantener presionado el botón es necesario para acciones dentro del juego, como que un personaje camine dentro del mundo. Estos tipos de datos de entrada tienen un valor que indican la magnitud de su eje. Al utilizar una asignación de ejes para que un personaje camine entonces el valor de esta magnitud determina que tan rápido se puede mover dentro del mundo. (Nixon, 2017) Estos datos de entrada son guardados como eventos dentro de Unreal, de tal forma que puedan ser llamados por todo blueprint dentro del juego, pero solo pueden ser ejecutados por el blueprint asignado como Player Controller. (Nixon, 2017)

2.2.4.2.2.5.6 Game Instance Una instancia de juego es un blueprint que tiene persistencia a través de todos los niveles de este, es decir es un actor que estará activo en todo nivel sin la necesidad de tener que agregarlos manualmente. Son utilizados para enviar información de un nivel a otro. (Wadstein, Youtube, 2015) Similar al Player Controller y el Game Mode, este blueprint puede ser llamado por cualquier blueprint de un nivel, pero a diferencia de esos objetos se puede usar más de un Game Instance en un nivel a la vez, si fuese necesario. (Wadstein, Youtube, 2015)

2.2.4.2.2.5.7 Save Game Es el objeto que permite guardar y cargar datos del juego desde disco. Se lo utiliza en conjunto al Game Instance para que el juego tenga persistencia de datos, para que el jugador pueda jugar por un tiempo, guardar y cerrar el juego para luego regresar y seguir desde el punto en el que termino la primera instancia. (Wadstein, Youtube, 2015) Save Game funciona como cualquier otro blueprint con sus propias variables, métodos y eventos, a diferencia de los demás tiene un par de eventos únicos utilizados para sus acciones específicas, es decir, guardar y cargar datos. Este objeto no existe en el mundo del juego por defecto, para su uso primero debe de ser instanciado. (Wadstein, Youtube, 2015) Se puede utilizar, aunque no es recomendado, varios de estos objetos dependiendo de las necesidades del programador, este objeto permite grabar datos a distintos registros, así el juego puede tener varias ranuras de guardado un solo objeto puede guardar la partida de varios jugadores. (Wadstein, Youtube, 2015)

2.2.4.2.2.6 Variables Son usadas por los blueprints para guardar información. Un blueprint puede tener una gran variedad de distintas variables, incluidas unas que pueden ser creadas específicamente para el juego en desarrollo. (Nixon, 2017)

2.2.4.2.2.6.1 Tipos de datos Es lo que define qué clase de información puede contener una variable, Unreal facilita las cosas identificando a cada variable con un color único (Nixon, 2017)

Ilustración 25: Algunos tipos de datos en Unreal Engine 4 (Nixon, 2017)

Tipo de Nombre de dato Descripción dato Guarda únicamente los valores lógicos de Boolean Lógico verdadero o falso. Pueden guardar distintos valore de números, utilizan distinto espacio de memoria según Byte, Integer, Float Numérico su complejidad, los más usados son los tipo Integer, que guardan números enteros, y los tipo Float que guardan decimales. Guardan datos te texto, son los que pueden ser más extensos y ocupan más memoria, una variable de tipo String permite ser Name, String, Text Caracteres modificados, más las otras dos no aceptan modificaciones, pero ocupan menos espacio en memoria. Cada uno es una colección que alberga 3 Vector, Rotator, Transform Ubicación valores de tipo float, sirven para describir valores de posición, escala y rotación. Tabla 4: Tipos de datos esenciales dentro de Unreal Engine 4 (Nixon, 2017)

2.2.4.2.2.6.2 Enumeradores Es una lista de datos, se utilizan cuando se necesita tener una lista de opciones como una variable para selección rápida. Se usan en particular cuando un blueprint tiene varias opciones de acciones definidas, puede definir cada una de ellas de modo que cuando el blueprint tenga que elegir que hacer pueda referirse a esta lista de posibles acciones. (Wadstein, Youtube, 2015) También son útiles ya que el número de posibles valores, así como qué son, pueden ser modificados fácilmente sin hacer daños a las instrucciones dentro de un blueprint. (Wadstein, Youtube, 2015) Puede ser utilizado como un tipo de dato, pero este no guarda datos, solo es una lista con valores de texto que no pueden ser modificados en tiempo de ejecución. (Wadstein, Youtube, 2015)

Ilustración 26: Ejemplo de un enumerador en Unreal Engine 4 (Ronquillo, 2019)

2.2.4.2.2.6.3 Estructuras de datos Es una manera de organizar variables, puede llamarse también una variable formada a partir de varias otras. Son creadas por un programador según sea necesario, por lo general utilizadas para el mejor manejo de objetos que utilizan un gran número de variables, o cuando varios blueprints necesitan el mismo grupo de ellas. (Wadstein, Youtube, 2015)

Ilustración 27: Ejemplo de una estructura de datos en Unreal Engine 4 (Ronquillo, 2019)

2.2.4.2.2.6.4 Tablas de datos Como su nombre lo indica es una tabla compuesta de datos dentro de Unreal, como una tabla en Excel está conformada por filas llenas de variables de cierto tipo según este dado por un grupo de columnas. (Wadstein, Youtube, 2017) Estos objetos son creados en base de una estructura de datos, donde cada campo en la estructura pasa a ser un cabecero de columna dentro de la tabla de datos. Las tablas pueden ser creadas dentro del motor o pueden también ser importadas con forma de un archivo separado por comas (.csv) permitiendo la creación y modificación de estos objetos fuera del motor. (Wadstein, Youtube, 2017) Son usados para tener un listado de ciertos elementos del juego, como los personajes, junto con una lista de atributos: nombre, descripción, ubicación, entre otros. Al tener un sistema complejo con varios elementos una tabla de datos facilita el control de estos elementos. (Wadstein, Youtube, 2017)

Ilustración 28: Ejemplo de una tabla de datos en Unreal Engine 4 (Ronquillo, 2019)

2.2.4.2.3 Widgets Son blueprints que contienen todos los posibles elementos de interfaz gráfica que se pueden implementar dentro de Unreal Engine. A diferencia de otros motores de desarrollo de videojuegos la interfaz gráfica no es un elemento dentro del juego, Unreal permite la creación de un sin número de Widgets que pueden ser instanciados y eliminados según sea conveniente en el juego, además de la posibilidad de anidarlos dentro de otros, para mejor uso de recursos. (Nixon, 2017)

Ilustración 29: Editor de Widgets en Unreal Engine 4 (Ronquillo, 2019) Para que un Widget sea visible este debe de ser instanciado por algún blueprint activo en el juego, esto no solo hará la interfaz gráfica visible en el juego, sino que instanciara otro blueprint que puede tener sus propias variables y métodos para un mejor control de los sistemas del juego. También por esto un Widget puede ser instanciado, pero no necesariamente proyectado a la pantalla, todo depende de las necesidades del programador. (Nixon, 2017)

Ilustración 30: Ejemplo de la creación de una instancia de un Widget y su proyección a la pantalla de juego. (Nixon, 2017)

2.2.4.2.4 Audio 2.2.4.2.4.1 Actor de sonido ambiente Al colocar un archivo de audio dentro de un nivel en Unreal automáticamente se creará lo que es llamado el actor de sonido ambiente, el actor creado tendrá la propiedad de sonido. (Nixon, 2017)

Ilustración 31: Propiedad de sonido dentro de un actor de sonido ambiente (Nixon, 2017) Por defecto, al empezar el juego, o cuando se cree una instancia de este actor reproducirá el sonido que tenga una vez, pero puede ser configurado para que se repita continuamente, esta clase de actores son usados, como su nombre lo indica, para poner sonidos de fondo y música dentro de un nivel. (Nixon, 2017)

2.2.4.2.4.2 Señales de sonido Las señales de sonido son sonidos que se crean a partir de la combinación de otros sonidos, puede ser utilizado para reproducir varios sonidos a la vez o para dar más dinamismo a un sonido agregándole otros, la señal de sonido también crea un actor de sonido ambiente al ser colocada en el editor. (Nixon, 2017)

2.3 Metodología Experimental 2.3.1 Ingeniería de software de desarrollo de videojuegos. El proceso de desarrollo de videojuegos es de naturaleza multidisciplinaria que combina sonido, arte, sistemas de control, inteligencia artificial y factores humanos, esto hace que sea un practica distinta al desarrollo de software tradicional. La complejidad de los videojuegos ha causado varios desafíos y problemas en el proceso de la ingeniería de desarrollo ya que incluye diversas actividades en distintas disciplinas artísticas. Esta diversidad crea un dominio muy fragmentado desde la perspectiva de la teoría subyacente y la metodología de diseño. (Aleem, Capretz, & Ahmed, 2016) Aun cuando se pueden utilizar diferentes metodologías en el desarrollo de un videojuego, (Aleem, Capretz, & Ahmed, 2016) lo dividen en tres fases principales.

Incluye la fiabilidad de cumplir los Pre-producción objetivos del juego, requerimientos de estrategia de marketing. Incluye la planificación, documentación e Producción implementación de los escenarios, sonidos y gráficos del videojuego. Incluye el testeo, marketing y promoción Post-producción del videojuego. Tabla 5: Fases de desarrollo de un videojuego. (Aleem, Capretz, & Ahmed, 2016) No existe una sola forma para el desarrollo de videojuegos, y varios desarrolladores han buscado sus propias prácticas de desarrollo. Blitz game studio propuso que el desarrollo se realice 6 fases: Propuesta (diseño inicial y concepto del juego), pre-producción (documento de diseño del juego), producción principal (implementación de conceptos del juego), Alfa (testeo interno), Beta (testeo externo) y fase master (lanzamiento del juego) (Blitz game studio, s.f.). Mientras que Hendrick propuso una de 5 fases consistiendo en: El prototipo (diseño inicial), preproducción (documentos de diseño), producción (creación de objetos, programación e integración), Beta (retroalimentación de usuarios) y finalmente la fase libre (lanzamiento). (Hendrick, 2009) Chandler extendió el trabajo de Aleem, Capretz & Ahmed al extender la producción a 4 fases, separando el testeo de la post-producción (Chandler, 2010). Y el proceso de desarrollo más reciente, propuesto por Ramadan & Widyani es una expansión del proceso de Chandler en 6 fases: Iniciación (concepto básico), pre-producción (creación del diseño del juego y prototipo), producción (detalles formales, refinamiento e implementación), testeo (reporte de bugs32, cambios), Beta (testeo externo) y lanzamiento. (Ramadan & Widyani, 2013)

2.3.1.1 Fase de Pre-producción 2.3.1.1.1 Especificación de requisitos Una de las principales diferencias entre el desarrollo de software tradicional y el ciclo de vida del proceso de desarrollo de videojuegos es la fase de especificación de requisitos. El proceso de desarrollo de software requiere la consideración de varios factores, ya sean emocionales, ontología de lenguaje, licitación, retroalimentación y emergencia. En particular, los desarrolladores deben comprender estos requisitos básicos no funcionales junto a los requisitos de juego e incorporarlos al desarrollar juegos. Los principales desafíos en la identificación de suelen ser: a) Comunicación entre diversos factores de fondo. b) Incorporación de requisitos no funcionales con los requisitos del juego, como integración de medios y tecnología. c) Validación de requisitos no funcionales, como el factor de diversión, algo muy complejo ya que depende enteramente del público objetivo.

32 Bugs: Es un problema que puede causar que un programa colapse o tenga un comportamiento inesperado. 31

La fase de especificación de requisitos debe abordar tanto los requisitos funcionales como los no funcionales del juego. (Aleem, Capretz, & Ahmed, 2016)

2.3.1.1.2 Reusabilidad La reusabilidad de un software es el uso de activos ya creado dentro del proceso de desarrollo. Más que solamente el código, los activos son productos y derivados del ciclo de vida del desarrollo de software e incluyen cosas como otros productos, diseños, documentación, y en el caso específico de videojuegos elementos como modelos, ilustraciones, música y efectos de sonido. (Lombard Hill Group) Hay varias razones por la que se utiliza reusabilidad en el desarrollo de software, esto incluye subir la productividad, ya que al reusar trabajo bajan los costos y tiempos de desarrollo, con esto se consigue reducir el tiempo entre concepción hasta el lanzamiento de un producto. Además, incluye la mejora a la calidad de software, ya que activos que han sido reutilizados suelen poseer menos defectos que los componentes recién codificados, esto lleva a consistencia e interoperabilidad a través de productos o partes de los productos. Tal vez la principal razón para reutilizar es el bajar el riesgo en el desarrollo, ya que se usan componentes ya probados y se puede aprovechar al máximo las habilidades técnicas y de conocimiento y hace sencillo mejorar la funcionalidad de un programa (Lombard Hill Group) Dentro del desarrollo de software la reusabilidad crece con la estandarización de los motores de desarrollo de videojuegos, su uso extendido tuvo una reducción marcada en el ciclo de vida del desarrollo de un videojuego, tanto costos como tiempo y subió considerablemente los estándares de calidad y productividad. (Neto, Lima, Fernandes, & De Souza, 2010) En la época temprana del desarrollo de videojuegos, estos eran programados en lenguaje ensamblador, de tal forma que el programador trabajaba directamente con el hardware y era el único en hacerlo, los personajes y la música del juego eran programadas dentro del juego por un pequeño grupo de personas, de manera que las mismas técnicas de programación eran reutilizadas para el mejor uso del tiempo y uso de memoria, un gran problema en ese entonces. Por ello se reutilizaban frecuentemente los efectos de sonido y gráficos a través de varios juegos en ese entonces, uno de los ejemplos más famosos es el original Super Mario Bros.33 donde se reutiliza el grafico de nubes para los arbustos. (Neto, Lima, Fernandes, & De Souza, 2010)

Ilustración 32: Nubes en Super Mario Ilustración 33: Arbustos en Super Mario Bros. (Nintendo, 1985)34 Bros. (Nintendo, 1985)35

Tabla 6: Ejemplos de reusabilidad de gráficos en videojuegos. (Ronquillo, 2019)

33 Super Mario Bros.: Un juego de plataformas lanzado en 1985, uno de los videojuegos más conocidos e importantes. 34 (Ronquillo, 2019) 35 (Ronquillo, 2019) 32

La creación de los motores de desarrollo de videojuego permitió que el desarrollo de activos (modelos, animaciones, gráficos, música, entre otros) se lo haga en programas de externos de tal manera que los mismos activos pudieran ser reutilizados en varios juegos sin ser creados desde cero para cada proyecto, la versatilidad de los motores de desarrollo de videojuegos inclusive permite que estos activos puedan ser utilizados en varios motores.

2.3.1.1.3 Documento de diseño de juego El documento de diseño de juego es un elemento muy importante en la fase de pre- producción. Consiste en una coherente descripción de los componentes básicos del juego, sus interrelaciones, direcciones y un vocabulario común para el desarrollo eficiente. (Aleem, Capretz, & Ahmed, 2016) Describe la visión general para el juego, un documento hecho correctamente deberá de incluir detalles como la audiencia a la que se dirige, la plataforma, el género, diseño de niveles y entornos, la idea principal, el estilo visual, los personajes y la historia, descritos todos a detalle. Sirve como guía para todo el equipo de desarrollo, de forma que todos entiendan y trabajen según la visión del director. Además, a nivel empresarial estos documentos incluyen temas como miembros de equipo de trabajo, tecnología a utilizarse, presupuesto y un cronograma. (StemChallenge, s.f.) Es importante utilizar material visual para dejar lo más claro posible los elementos de cada juego, desde arte conceptual, maquetas, bosquejos y mapas conceptuales u otros esquemas.

2.3.1.1.3.1 Visión del juego Es un breve resumen o descripción del juego, detalla los objetivos que se quiere cumplir, las mecánicas, sus elementos y todos aquellos elementos que hacen que el juego sea único. El objetivo de la visión dentro del documento de diseño es vender al proyecto, es decir, obtener financiamiento. (StemChallenge, s.f.) Como ejemplo, la visión de juego de Fallout36 según Taylor

Mega niveles de violencia. (Es mejor que nos den una calificación de solo audiencias maduras de una vez.)

Puedes dispararle a todo en este juego, personas, animales, edificios y paredes. Puedes hacer lo que llamamos “called shots” en gente, tal que les puedes disparar en los ojos o en su entrepierna, Los called shots pueden hacer más daño, dejar inconsciente al objetivo o tener otros efectos. Cuando la gente muere, no solo muere, son partidos a la mitad, se funden, explota, o muchas otras cosas dependiendo que armas se use. Cuando uso mi lanzacohetes sobre podres e indefensos ciudadanos, ellos lo sabrán (¡Y sus vecinos pasarán semanas limpiando la sangre!)

36 Fallout: Juego de rol occidental lanzado en 1997, conocido por su escenario post apocalíptico y violento. 33

Esto es un páramo. La vida no vale nada y la violencia gobierna toda. Vamos a tomar al jugador y dejarle bien en claro esto. (Taylor, 1995)

2.3.1.1.3.2 Audiencia del juego Un juego siempre es desarrollado con una audiencia en particular, el documento detalla quién es esta audiencia y por qué estaría interesada en el juego. (StemChallenge, s.f.) Es necesario que el diseñador pueda proyectarse a la mente del jugador, debe de tratar convertirse en el jugador, ver lo que él ve, escuchar lo que el escucha y pensar en lo que él piensa. Al ser parte del equipo de desarrollo es fácil que el diseñador piense que está por encima jugador y olvidar su opinión. Cuando se está desarrollando un juego para una audiencia de la que el diseñador es parte, se puede usar su propia experiencia como miembro de esa audiencia en el desarrollo, así como usar los elementos que le gustan o no. (Schell, 2008) Pero si el diseñador está trabajando en un juego en el cual no es parte de la audiencia, se debe utilizar una táctica distinta, debe pensar en personas que pueda conocer que sean parte de esa audiencia. Similar a un antropólogo, debe pasar tiempo con miembros de la audiencia, hablar con ellos, observarlos, e imaginar cómo sería ser parte de ellos. Si el diseñador puede convertirse en cualquier tipo de jugador, se podrá expandir la audiencia de sus juegos, ya que sus diseños podrán incluir a audiencias que otros pueden ignorar. (Schell, 2008)

2.3.1.1.3.2.1 Demografías Cada individuo es único, pero al crear algo para una gran audiencia se tiene que agrupar a las personas. Estos grupos se llaman demografías, o también llamados segmentos de mercado. Según Schell las demografías de edad suelen ser las más importantes y al crear el juego el diseñador debe de tener en cuenta los siguientes grupos:  0-3 años (infante): Niños en esta edad suelen estar interesados en juguetes, pero la complejidad y resolución de problemas dentro de los videojuegos suele ser demasiado para ellos. (Schell, 2008)  4-6 años (preescolar): En esta edad es cuando los niños comienzan a mostrar interés por los juegos. Suelen jugar juegos simples en compañía de sus padres, ya que ellos suelen cambiar las reglas del juego para hacerlo más divertido para ellos. (Schell, 2008)  7-9 años (niños): A esta edad los niños pueden resolver problemas más complicados. Suelen generar su propio interés por juegos a esta edad. También es en esta etapa cuando comienza a hacer sus propias decisiones sobre qué clase de juegos les gusta, más que jugar lo que sus padres le indiquen. (Schell, 2008)  10-13 años (preadolescente): Los niños a esta edad pasan por un periodo de gran cambio neurológico y son capaces de pensar más profundamente en las cosas que los apasionan. (Schell, 2008)  13-18 años (adolescentes): En esta etapa los intereses de los dos géneros comienzan a divergir, los adolescentes están interesados en experimentar con nuevas experiencias, y algunas pueden verse dentro de los juegos. (Schell, 2008)  18-24 años (jóvenes adultos): El primer grupo de adultos, un periodo de transición. Por lo general los adultos juegan menos que los niños, durante esta etapa, en base a las

experiencias en la época adolescente, tienen gustos establecidos de sus medios de entretenimiento. Los jóvenes adultos suelen tener tiempo y dinero, por lo que son grandes consumidores. (Schell, 2008)  25-35 años (veinte y treinta): Para esta etapa el tiempo libre suele ser escaso, por lo que estos adultos son más consumidores casuales. Aunque, aun así, los que consideran a los videojuegos una afición seria suelen hacer grandes gastos. (Schell, 2008)  35-50 años (treintas y cuarentas): Suelen buscar experiencias que toda su familia pueda disfrutar, gastan en videojuegos, pero más por proxy, ya que son sus hijos los que más juegan. (Schell, 2008)  50+ (50 en adelante): Suelen tener mucho tiempo libre, algunos regresan a juegos que disfrutaron en su juventud o a nuevas experiencias. (Schell, 2008) Un buen diseñador debe de preguntarse a sí mismo las siguientes preguntas sobre las personas que jugarán su juego.  ¿Qué les gusta?  ¿Qué no les gusta? ¿Por qué?  ¿Qué esperan ver en el juego?  De estar en su lugar, ¿Qué quisiera ver en el juego? Siempre se debe de estar pensando en el jugador, y él debe estar en primer lugar. Se debe pensar en el jugador, la experiencia del juego y su mecánica, todo al mismo tiempo. Si bien es útil pensar en el jugador, verlos jugar es aún más útil. Al observar a los jugadores se puede predecir con mayor facilidad que clase de cosas disfrutan. (Schell, 2008)

2.3.1.1.3.3 Plataformas Detalla para que plataforma o plataformas se está desarrollando el juego, se suele indicar junto a la audiencia del juego si es que la plataforma es utilizada por esa audiencia, además de detallar si el juego utilizara alguna capacidad especial de la plataforma para la cual que se está desarrollando. (StemChallenge, s.f.) Dentro del actual desarrollo de videojuegos se incluyen las siguientes plataformas:  Consolas  Computadoras  Dispositivos para realidad virtual  Dispositivos para realidad aumentada  Plataformas web  Dispositivos móviles.

2.3.1.1.3.4 Idea principal del juego La sección describe en detalle cómo se siente jugar. Suele ser la sección más extensa del documento. Se deben detallar:  Mecánica principal: Describe que hace el jugador. Por lo general los videojuegos son una combinación de varias mecánicas, pero la mecánica central es la que hace que un

juego sea único. Un juego bien planteado tiene a todos los demás elementos de forma tal que refuerzan a la mecánica principal. (StemChallenge, s.f.)  Metas: Describe qué es lo que el jugador quiere cumplir, es decir en qué estado se gana el juego, y como el jugador puede fallar llegar a ese estado. Dependiendo del tipo de juego este puede ser tal y como terminar el nivel o terminar la historia. (StemChallenge, s.f.)  Componentes: Describe que elementos existen en el juego, detalla datos como enemigos, ítems, poderes, puntos, niveles y demás. Por qué están en el juego, de que sirven y como apoyan a la mecánica principal. (StemChallenge, s.f.)  Controles: Describen como el jugador interactúa con el mundo del juego, como se mueve el personaje, que hacen los distintos botones, que habilidades especiales se pude tener dentro del juego. (StemChallenge, s.f.)  Flujo de juego: Detalla cómo se progresa en el juego, que pasos debe cumplir el jugador, que clase de ventanas serán visibles para el jugador, la estructura de los niveles, como el jugador puede moverse dentro del mundo del, suele ir mano a mano con las metas. (StemChallenge, s.f.)

2.3.1.1.3.5 Estilo visual Es uno de los detalles más importantes del desarrollo, ya que juega un papel significativo en la experiencia del jugador, y es uno de los detalles que hace al juego interesante y divertido. A través de la historia de su historia han existido muchos métodos para visualizar el contenido de los juegos, y al usar distintas tecnologías los desarrolladores y artistas han creado varios resultados en la apariencia de ellos. Estos estilos visuales son más comúnmente llamados estilos gráficos, y son la presentación del contenido del mundo del juego, todo lo que es visible para el jugador. (Keo, 2017) Se puede desglosar los estilos gráficos de los videojuegos en tres campos:  Abstracto: Un estilo grafico que se centra en la representación de los objetos del juego como figuras y formas geométricas en lugar de utilizar personajes definidos. Utilizado más en la era temprana de los videojuegos donde formas geométricas fue todo lo que dejaba la tecnología de la época, no es muy usado actualmente pues el diseño tiende a ser muy simple. (Keo, 2017)  Estilizados: Los gráficos estilizados representan a personas u objetos exagerando los rasgos más destacados. Este tipo de estilo grafico viene desde la edad temprana de los videojuegos y puede implementarse en varias maneras, y existe una gran gama de representaciones artística. (Keo, 2017)  Realistas: Gráficos realistas tratan de emular, a los personajes, objetos y ambientes tan cercanamente a la realidad como sea posible. Este estilo grafico creció en popularidad en la década de los 1990s al mejorar la tecnología grafica de los videojuegos. Los juegos de las empresas de desarrollo más grande suelen tratar de llegar a una imagen fotorrealista y es el estilo gráfico de preferencia de los videojuegos más vendidos actualmente. (Keo, 2017)

Ilustración 35: Ejemplo de estilo Ilustración 34: Ejemplo de estilo grafico visual estilizado, Overwatch (Blizzard, abstracto, Superhot (7DFPS, 2013)37 2016)38

Ilustración 36: Ejemplo de estilo visual realista, Battlefield 1 (Electronic Arts, 2016)39

Tabla 7: Ejemplos de estilos visuales (Ronquillo, 2019)

2.3.1.1.3.6 Diseño de niveles y entorno Detalla la estructura de los niveles dentro del juego, si bien no hace falta describir en detalle cada nivel del juego de forma individual se debe describir por lo menos uno donde sea visible todas las mecánicas del juego y la idea principal. Incluye bosquejos mostrando donde estarán distintos detalles de los niveles. (Ryan, 1999)

Ilustración 37: Diseño de niveles en Super Mario Bros. (Nintendo, 1985)40

37 (Giant Bomb, 2015) 38 (Giant Bomb, 2015) 39 (Giant Bomb, 2019) 40 (Nintendo, 2015) 37

Entorno es una descripción de los detalles de fondo del nivel, elementos que sirven para dar ambiente al juego, pero no son esenciales para la mecánica del juego, se utilizan para dar mejor inmersión al jugador y mostrar aun de mejor manera el estilo visual del juego. Suele ser demostrado por arte conceptual. (Ryan, 1999)

Ilustración 38: Ejemplo de entorno utilizando arte conceptual de God of War (Sony Interactive Entertainment, 2018)41

2.3.1.1.3.7 Personajes e historia Se describe la historia del juego en una breve sinopsis. Dependiendo del videojuego la historia puede ser el elemento principal, y los demás elementos del juego se desarrollan a base de la historia, o puede ser el elemento final, de forma que la historia sirve como una red en la que todos los elementos del juego caen, es decir la historia funciona en base a los elementos del juego. (Slopper, 2015) Se detalla también los personajes principales del juego y sus roles en la historia, se describe en detalle la personalidad de cada uno, una historia de fondo e interrelaciones con otros personajes. (Slopper, 2015)

Ilustración 39: Arte conceptual de personajes en Metal Gear Solid V: The Phantom Pain (Konami, 2015)42 La sección suele estar acompañada por arte conceptual de los personajes y storyboards de la historia.

41 (Iamag) 42 (Konami, 2016) 38

2.3.1.1.4 Herramientas de diseño Las herramientas de diseño son usadas como ayuda a los desarrolladores a crear descripciones de los efectos y eventos del juego en detalle sin la necesidad de habilidades de programación. Estas herramientas también permiten la reusabilidad de componentes existentes y reducir el tiempo total en el proceso de creación del juego. (Aleem, Capretz, & Ahmed, 2016) El esquema MDA según Hunicke, Zubek & Leblanc divide las herramientas en tres partes: 1. Mecánicas: Son las acciones, comportamientos y control de sistemas que se le da al jugador dentro del juego, junto al contenido del juego (modelos, niveles, música, entre otros) las mecánicas derivan a las herramientas dinámicas. (Hunicke, Zubek, & Leblanc, 2004) 2. Dinámicas: Describe el comportamiento de las mecánicas en tiempo real, como afectan al jugador y como el jugador las afecta a ellas. Las herramientas dinámicas sirven para crear las herramientas estéticas. (Hunicke, Zubek, & Leblanc, 2004) 3. Estéticas: Se describe la respuesta emocional que se quiere conseguir del jugador cuando interactúa con los sistemas del juego. (Hunicke, Zubek, & Leblanc, 2004)

La estética necesita un vocabulario más preciso, incluyendo la siguiente taxonomía:

 Sensación: El juego como placer a los sentidos.  Fantasía: El juego como una ilusión.  Narrativa: El juego como una historia.  Desafío: El juego como un obstáculo.  Compañía: El juego como una construcción social.  Descubrimiento: El juego como territorio inexplorado.  Expresión: El juego como autodescubrimiento.  Sumisión: El juego como pasatiempo.

Cada videojuego puede ser descrito por uno o más de estos términos estéticos. (Hunicke, Zubek, & Leblanc, 2004)

2.3.1.1.5 Prototipo de juego Ayuda al desarrollador a clarificar las mecánicas fundamentales. Es considerado importante porque se usa para transmitir mecánicas de juego y ayuda en la evaluación de la experiencia del jugador. Los prototipos también pueden ser usados para identificar fallas en la funcionalidad, así los desarrolladores pueden hacer cambios rápidos. (Aleem, Capretz, & Ahmed, 2016) El prototipo rápido es considerado crucial en el ciclo de desarrollo, ya que se necesita tener claro los conceptos del juego antes de avanzar a la etapa de producción, por lo que el desarrollador debe de tener en cuenta lo siguiente al momento de la creación un prototipo: 1. Debe contestar una pregunta. Los prototipos deben de responder preguntas. Cuáles son deben estar bien planteado por los desarrolladores para aprovechar de mejor manera el tiempo. Una de las preguntas a contestar puede ser. (Schell, 2008)

 ¿Cuántos elementos pueden estar en un nivel según nuestro alcance tecnológico?  ¿Es el concepto principal divertido, se mantiene divertido por largo tiempo?  ¿Los personajes y los niveles encajan bien estéticamente?  ¿Qué tan grande tiene que ser un nivel? No debe ser demasiado grande, y su enfoque en el desarrollo debe ser responder las preguntas planteadas. 2. La calidad no importa Al desarrollar un prototipo todo lo que importa es responder la o las preguntas planteadas, mientras más rápido se pueda hacer mejor, aun cuando el prototipo apenas funcione y no se vea muy bien. Ya que el objetivo del prototipo es encontrar problemas de forma temprana, desarrollarlo demasiado puede ser contraproducente ya que podría esconder algunos de los errores. (Schell, 2008)

Ilustración 40: Prototipo inicial de Arms Ilustración 41: Versión final de Arms (Nintendo, 2017)43 (Nintendo, 2017)44

Tabla 8: Ejemplo de diferencia de calidad entre juego prototipo y versión final de un videojuego. (Ronquillo, 2019) 3. No todos los conceptos iniciales sirven La primera versión del producto no será la versión final, algún elemento del juego se suele perder en el desarrollo del prototipo ya que siempre se descubre que algún sistema del juego no sirve. El prototipo se debe realizar con la idea de que es temporal, que lo único que importa es contestar la pregunta y pensar en este como una oportunidad de aprendizaje para los sistemas finales. Al final solo debe quedar lo mejor de la idea original. (Schell, 2008) 4. No tiene por qué ser digital Se puede hacer un prototipo como un juego de mesa, el llamado prototipo de papel u offline, ya que es una forma eficaz de trabajar tempranamente y pueden transmitir el concepto principal. Esto puede permitir encontrar problemas de forma más temprana. (Schell, 2008) Si bien el prototipo de papel no es compatible con todos los tipos de juegos, y será necesario crear un prototipo virtual, es una buena forma de empezar el desarrollo. (Schell, 2008)

43 (GDC Vault, s.f.) 44 (GDC Vault, s.f.) 40

Ilustración 42: Ejemplo de prototipo 2D, Ilustración 43: Ejemplo de juego en 3D The Legend of Zelda: Breath of the Wild basado en prototipo en 2D, The Legend of (Nintendo, 2017)45 Zelda: Breath of the Wild (Nintendo, 2017)46

Tabla 9: Ejemplo mostrando prototipo en 2D para un juego en 3D. (Ronquillo, 2019) 5. Se debe iterar de forma rápida. El prototipo se cambia de forma continua y rápida, se necesita de un proceso eficaz para realizar cambios y probarlos en el juego, por lo que no se utiliza el bucle normal de desarrollo de software, se podría definir los pasos para el desarrollo de un prototipo de forma que: (Schell, 2008)

Correr el juego

Navegar dentro del Hacer cambios mundo hacia necesarios. la parte que se quiere probar

Probar elemento del juego.

Ilustración 44: Ciclo de desarrollo de un prototipo. (Schell, 2008)

45 (GDC Vault, s.f.) 46 (GDC Vault, s.f.) 41

2.3.1.2 Fase de Producción 2.3.1.2.1 Desarrollo de activos Los activos son todos los elementos del juego que el jugador puede ver y escuchar, es decir son los gráficos y los sonidos del juego. En un videojuego, según Bounani, estos objetos cuentan como activos:

2.3.1.2.1.1 Diseños:  Personajes: Se realizan los personajes creados en la fase de preproducción, dependiendo del tipo de juego esto incluye la ilustración y animación de personajes en 2D o el modelado, rigging y animación de personajes en 3D. (Bounani, 2015)  Objetos: Incluyen objetos dentro del mundo del juego con los que el jugador pueda interactuar o pueda usar, estos elementos suelen tener comportamientos dentro del mundo y posiblemente animaciones, al igual que los personajes dependiendo de en qué dimensión sea el juego pueden ser imágenes o modelos. (Bounani, 2015)  Entornos: Son todos los objetos dentro del mundo con los que el jugador no puede interactuar, sirven para dar más vida a los niveles, considerados objetos de fondo. Si tienen alguna clase de animación suele ser algo simple que se mueve en un bucle. (Bounani, 2015)  Texturas y materiales: Las texturas son imágenes aplicadas a objetos 3D. Son responsables de que los modelos sean coloridos e interesantes, los materiales son los contenedores de las texturas y sirven para dar más características graficas a los objetos, como transparencia o reflejo. (Geig, 2013)

Ilustración 45: Ejemplo de personaje: Ilustración 46: Ejemplo de objeto: Spritesheet the Sparkster usado en Rocket Medallón usado en Resident Evil 2 Knight Adventures (Konami, 1993)47 (Capcom, 2019)48

47 (Spriters Resource, s.f.) 48 (Capel, 2019) 42

Ilustración 47: Ejemplo de entorno como Ilustración 48: Ejemplo de texturizado: visto en Fislab Kids Expanded (Dominguez Textura usada en Tommy Vercetti en Grand & Lima, 2019) Theft Auto: Vice City (Rockstar, 2002)49

Tabla 10: Ejemplos de distintos activos de diseño. (Ronquillo, 2019)

2.3.1.2.1.2 Elementos de interfaz grafica  Menús: Elementos de interfaz que le permiten al jugador hacer cambios, desde un menú principal donde pueda iniciar o cerrar el juego, hasta submenús donde pueda hacer elecciones a tomar dentro del mismo. Siempre son interactivos, con botones y otros elementos. (Schell, 2008)  HUD: Heads up Display por sus siglas en inglés, son los elementos de la interfaz que sirven para dar información al jugador, datos como sus puntos de vida, objetivos, mapas, entre otros. El jugador no puede interactuar con estos elementos. (Schell, 2008)  Iconos: Ilustraciones como apoyo para dar más información al jugador, se usan para describir objetos que no existen en el mundo del juego o a los que se les puede dar más detalle, dependiendo del juego pueden ser ilustraciones de personajes, ilustraciones de ítems, ilustraciones de lugares, entre otros. Los iconos suelen ser usados dentro de los menús y los HUDs. (Schell, 2008)

Ilustración 49: Ejemplo de un HUD, Metroid Prime (Nintendo, 2002)50

49 (Texture Resource, s.f.) 50 (Gamefaqs, s.f.) 43

Ilustración 50: Ejemplo de un menú, Persona 5 (Atlus, 2016)51

Ilustración 51: Ejemplos de iconos dentro de un menú, Dragon Quest VIII: Journey of the Cursed King (Square Enix, 2004)52

Tabla 11: Ejemplos de elementos de interfaz grafica (Ronquillo, 2019)

2.3.1.2.1.3 Elementos audiovisuales  Música: Incluye toda la música que se usa en el videojuego, esta puede ser original o usarse bajo licencia, actualmente la música puede ser dinámica de forma que una canción puede tener alteraciones dependiendo de lo que esté pasando en el juego. Por lo general la música debe de estar planeada para sonar en un bucle ya que la misma canción puede ser reproducida por horas según el jugador desee. (Hancock, 2002)  Efectos de sonido: Sonidos simples que se reproducen al cumplirse una condición, sirven para reforzar la inmersión del jugador dentro, ayudando a dar más vida al juego. Pueden ser sonidos dentro de los menús, pasos de personajes moviéndose en el mundo, entre otros. (Hancock, 2002)  Cinemáticas: Es una secuencia donde el jugador pierde el control del personaje dentro del juego, pueden ser usadas para una variedad de fines, como mostrarle al jugador un punto importante, darle alguna recompensa, o su uso más común, avanzar la historia. Su nombre viene al usar ángulos de cámara más cinemáticos al quitarle al jugador el control de cámara. Actualmente vienen en dos variedades, las realizadas dentro del mismo juego, o las pre renderizadas, donde la cinemática es creada en otro software y el motor de juego solo la reproduce. (Hancock, 2002)

51 (Giant Bomb, 2016) 52 (Giant Bomb, 2008) 44

El desarrollo de activos abarca todo el proceso de desarrollo, inicialmente se crean activos planeados en la etapa de pre-producción, pero su mayor desarrollo se basa en lo planeado en la etapa de creación de niveles. Esta etapa es muy volátil donde se pueden hacer grandes cambios según avanza el diseño de juego y gran parte del trabajo realizado en esta etapa puede no aparecer en el juego final. (Schell, 2008)

2.3.1.2.2 Diseño y producción de Niveles Un nivel, también llamado mapa, área, escenario, pista, piso, zona, fase, misión, episodio o curso, es el espacio total que tiene un jugador mientras está tratando de cumplir uno o más objetivos. Dentro de un videojuego los niveles pueden seguir una secuencia lineal o no lineal, es decir un nivel solo será disponible para el jugador después de completar otro, o el jugador podrá explorar a través de los niveles según el crea conveniente. (Schell, 2008) Cada nivel debe de presentar nuevo contenido y nuevos desafíos para mantener el interés del jugador. Además, la idea principal del juego debe de estar presente en cada nivel, si bien un nivel puede tener conceptos únicos para sí, este aún debe de seguir la idea principal planteada en el juego. (Schell, 2008) Al llegar a la etapa de producción la idea general del juego ya está bien planteada y para entonces ya se debe de tener una idea del flujo de niveles, así como el diseño básico de alguno de ellos. Es un proceso muy volátil donde pasan cambios constantemente, por ello sucede durante todo el proceso de desarrollo, así se sigan haciendo cambios menores. Similar al desarrollo de activos, no está fuera de lo común que niveles enteros creados no estén en el juego final, o que sean completamente distintos en su estado final a su estado inicial. Por ello el diseño de nivel se desarrolla conjunto al desarrollo de activos. (Schell, 2008) Oxland describe los pasos a seguir en el diseño y producción de niveles.  Se debe ubicar las características más grandes del nivel, esto incluye a edificios, montañas, túneles, entre otros. Todos los elementos de entorno del nivel, en este espacio es donde el jugador y los demás personajes se podrán mover. (Oxland, 2004)  Determinar condiciones del entorno, como la iluminación del nivel (luz, noche) y condiciones climáticas (de implementarse). (Oxland, 2004)  Determinar las reglas básicas del nivel, hay que indicar que puede hacer el jugador dentro del nivel, con qué elementos empieza el jugador, que clase de personajes habrá, límites de tiempo, entre otros. (Oxland, 2004)  Determinar regiones dentro del nivel donde puedan suceder ciertas actividades, indica en que parte del nivel podría suceder una cinemática, en que parte del nivel se puede cargar otro nivel, en que parte pueden suceder ciertos sistemas del juego. (Oxland, 2004)  Determinar partes no estáticas del nivel, indica donde estarían elementos interactivos, donde habrá puertas u otros mecanismos, según necesite el juego. (Oxland, 2004)  Determinar la posición de entidades, donde estarán personajes amistosos, donde estarán enemigos, donde estarán ítems que ayuden al jugador, entre otros. (Oxland, 2004)  Determinar las posibles entradas y salidas del nivel. (Oxland, 2004)  Determinar sistemas estéticos, música, efectos de sonido, entre otros. (Oxland, 2004)

 Determinar eventos, que puede hacer el jugador que cambia al nivel, o en donde puede dar dicho cambio. (Oxland, 2004)

2.3.1.2.2.1 El primer nivel El primer nivel es el nivel más importante del juego, en palabras de Miyamoto:

Tu primer nivel (o tutorial, o secuencia o como quieras llamarlo) debe servir como un prólogo para el resto del juego. Debería de introducir muchos de los conceptos con el que el jugador va a interactuar a través del resto del juego y debe de hacerlo de una manera que no espante al jugador. (Miyamoto, 1989) Miyamoto indica que el siempre diseña el primer nivel de sus juegos al final, tal que todos los conceptos del juego están desarrollados y finalizados para que el primer nivel sea la mejor introducción de los sistemas del juego. El primer nivel debe estar diseñado de tal forma que el jugador aprende las reglas del juego de forma natural, sin tener que forzar conceptos sobre él, sin tener que mostrar mensaje de texto indicándole los sistemas, ni peor aún, que tenga que buscar información fuera del juego para entender cómo funciona. (Miyamoto, 1989) El primer nivel es como un chiste, si se tiene que explicar, es porque está mal hecho. (Miyamoto, 1989)

2.3.1.2.3 Programación La base de la etapa de programación se la realiza en el prototipo del juego, ya en la fase de producción, la programación incluye el refinamiento de sistemas ya creados y la creación de los faltantes, además de su planeación para implementación a gran escala. (Graham & McShaffry, 2012) La programación se encarga de implementar las reglas de juego diseñadas al juego real, así como darles comportamiento a todos los elementos del juego, puede funcionar separado a las etapas de diseño de niveles y desarrollo de activos ya que el trabajo viene planteado desde la etapa de pre-producción con conceptos ya definidos, aun así, suele ser un proceso volátil por las posibles eventualidades a pasar. Es trabajo del programador adaptarse a lo que los diseñadores crearon o tratar de trabajar con ellos en el diseño de los sistemas de juego. (Graham & McShaffry, 2012) Por diseño, los sistemas creados en esta parte están ocultos al jugador, aun cuando son una parte vital del juego. Además de crearlos los programadores deben de unirlos de una forma coherente para la funcionalidad del juego. (Graham & McShaffry, 2012)

2.3.1.2.3.1 Arquitectura del juego Existen muchas formas de ensamblar los subsistemas de un juego, como ya se ha mencionado antes, no hay una forma definitiva de desarrollar videojuegos, por lo que esto varía mucho de videojuego a videojuego. Aun así, se pueden dividir los sistemas de juego en tres categorías: la capa de aplicación, la capa de lógica del juego y la capa de vista de juego. Este

46 tipo de arquitectura es generalmente usado a alto nivel, pero se puede aplicar a juegos pequeños también. (Graham & McShaffry, 2012)

Capa de aplicación

Lógica Vista del juego Del juego

Ilustración 52: Arquitectura de juego de alto nivel. (Graham & McShaffry, 2012)

2.3.1.2.3.1.1 Capa de aplicación Se ocupa de la interacción entre el juego con hardware y el sistema operativo sobre el que este está corriendo. Principalmente de como el jugador puede interactuar con el juego utilizando distintos dispositivos de entrada o salida, además de sistemas de interconexión, como comunicación por redes con otros equipos, y finalmente, operaciones de inicialización y cierre del juego, como programa. (Graham & McShaffry, 2012)

Capa de aplicación

Sistema Vida del Dispositivos Operativo juego

Librerias Entrada Lenguaje principales

Ciclo de Archivos DLL juego

Inicializacion RAM Threads y cierre

Tiempo Network

Ilustración 53: Subsistemas que conforman la capa de aplicación (Graham & McShaffry, 2012)

2.3.1.2.3.1.1.1 Lectura de entrada Los videojuegos tienen una gran gama de dispositivos para leer datos del jugador, desde los simples controles hasta guitarras u otros periféricos. Algunas acciones de estos dispositivos pueden ser traducidos a comandos dentro del juego y podrían ser enviados a su lógica. Este sistema puede ser dinámico, ya que se debe dar libertad al jugador decidir cómo jugar según su habilidad, aun cuando el juego sea diseñado con un sistema de control en mente. (Graham & McShaffry, 2012)

2.3.1.2.3.1.1.2 Sistema de archivos Permiten que el juego pueda leer y escribir archivos del hardware donde corre, incluye que el videojuego pueda cargar sus propios activos como modelos, música o imágenes, así como sistemas un poco más complicados como el poder guardar y cargar datos que alteran los cambios al estado de juego que realiza al jugador. (Graham & McShaffry, 2012)

2.3.1.2.3.1.1.3 Manejo de memoria El manejo de memoria es un sistema esencial en un videojuego, dependiendo del dispositivo en el que se ejecute el juego. Los activos y sistemas pueden utilizar demasiada memoria en el dispositivo, así sea memoria RAM o memoria de video, dentro del proceso de desarrollo se debe optimizar el juego según el dispositivo para no abordar su memoria que afecte negativamente el rendimiento. (Graham & McShaffry, 2012)

2.3.1.2.3.1.1.4 Ciclo de juego Por lo general, el software espera que el usuario haga algo antes de ejecutar alguna función. Pero esto no se aplica mucho a los videojuegos, que suelen tener sistemas que viven por sí mismos, sin necesidad de que el jugador interactúe con ellos. El sistema que controla estas actividades continuas es conocido como el ciclo de juego, que cuenta con tres componentes principales. (Graham & McShaffry, 2012)  Esperar y atrapar acciones del jugador.  Mandar las acciones del jugador a la lógica del juego.  Presentar el estado del juego en la vista del juego. Simplificando todo el proceso de la capa de aplicación, lo que esta capa realiza es cargar y crear las capas de lógica y vista del juego y asignarle a cada una parte del poder de procesamiento del dispositivo para puedan hacer su trabajo. (Graham & McShaffry, 2012)

2.3.1.2.3.1.2 Capa de lógica del juego Es el juego mismo, completamente separado del dispositivo donde este corriendo o como se lo muestra al jugador. Define el mundo del juego, que sistemas existen dentro del mundo y como pueden interactuar entre sí. Además de como el juego puede cambiar según las acciones del jugador. (Graham & McShaffry, 2012)

Capa de logica del juego

Estado del juego Gestor de Interpretador de y estructuras de Fisica Eventos procesos comandos datos

Ilustración 54: Subsistemas que conforman la capa de lógica del juego (Graham & McShaffry, 2012)

2.3.1.2.3.1.2.1 Estado de juego y estructura de datos El estado de juego es la descripción de un objeto en un punto de tiempo específico, el jugador u otro objeto pueden alterar el estado, que es representado como una estructura de datos dentro del objeto. (Graham & McShaffry, 2012) Todo juego tiene un contenedor para sus objetos, los juegos simples suelen utilizar una lista para contarlos, pero juegos más complejos utilizan sistemas flexibles y optimizados para búsqueda y carga. Es necesario poder encontrar a un objeto especifico de forma rápida y precisa para realizar cambios a su estado. Los objetos deben de tener propiedades para identificarlos y modificarlos, esta clase de datos se los guarda en estructuras de datos. (Graham & McShaffry, 2012)

2.3.1.2.3.1.2.2 Física y colisiones La física cae como reglas del mundo de juego y es un miembro fundamental de la lógica de este, define factores incluyendo el cómo los personajes se pueden relacionar físicamente dentro del mundo y que pasa cuando objetos entran en contacto unos con otros. Un sistema de física complejo no es necesario para todo juego, pero es necesario la presencia de uno. Dependiendo de la visión, el sistema de física no tiene que ser realista necesariamente, ya que si se tiene un sistema un poco más abstracto se puede ignorar completamente las representaciones realistas, y aun si se quiere ser realista, un sistema de física nunca será completamente exacto. (Graham & McShaffry, 2012)

2.3.1.2.3.1.2.3 Eventos Cuando sucede un cambio en el estado del juego, como instanciar un objeto o mover a un personaje, un numero de sistemas deberán de responder realizando cambios adicionales. Son la pieza fundamental de la arquitectura ya que dictan los cambios dentro del juego, cuando la capa de aplicación capta una entrada, subsistemas mandan estos datos a la capa de lógica de juego para que se disparen los eventos necesarios, funciona de tal manera que solo pasara lo que el programador quiera cuando él quiera que pase. (Graham & McShaffry, 2012)

2.3.1.2.3.1.2.4 Gestor de procesos Cualquier simulación en un juego están hechas aparte de simples sistemas describiendo simples acciones, la complejidad viene en la posibilidad que un objeto tenga varias posibles acciones según un numero de variables. Dependiendo de estas variables los objetos se pueden dividir en clases. (Graham & McShaffry, 2012) Este es el núcleo de otro subsistema importante, el gestor de procesos. Este tiene una lista de todos los procesos corriendo en el juego y los ejecuta en un orden según este definido en el ciclo del juego, permite que los procesos que puedan realizar los objetos dentro del juego puedan seguir un orden lógico, y que un objeto pueda solo realizar una acción a la vez. (Graham & McShaffry, 2012)

2.3.1.2.3.1.2.5 Interpretador de comandos La lógica del juego debe responder a comandos externos, el interpretador de comandos captura los comandos que llegan desde la capa de aplicación y los traduce de tal forma que la lógica del juego sepa qué hacer con ellos, es decir, ejecutar un evento. (Graham & McShaffry, 2012)

2.3.1.2.3.1.3 Capa de vista del juego Incluye a los sistemas responsables en mostrar el estado del juego al jugador, así como mostrar como la forma en que las acciones del jugador cambian al juego. Son todos los activos, los modelos, interfaces y activos audiovisuales, toda información que se le da al jugador por medio del juego mismo. (Graham & McShaffry, 2012) Esta capa puede tener distintas aplicaciones, ya que se le puede mostrar al jugador sus acciones de distintas formas, mostrando el juego en una pantalla, por medio de efectos de sonido, vibración de controles, entre otros. (Graham & McShaffry, 2012)

Capa de vista del juego

Interpretador Gestor de Graficos Audio Opciones de entrada procesos

Escenas en 2D Efectos de o 3D sonido

Interfaz Musica grafica

Videos Dialogos

Ilustración 55: Subsistemas que conforman la capa de vista del juego (Graham & McShaffry, 2012)

2.3.1.2.3.1.3.1 Gráficos Son todos los elementos que crean una escena dentro de un juego, incluyen todos los elementos 2D o 3D, así como la interfaz gráfica, o de ser el caso, una cinemática. La calidad gráfica suele ser uno de los obstáculos más importante en la etapa de desarrollo ya que es uno de los sistemas que usan más recursos del hardware, dentro de la parte de programación se debe optimizar el uso de recursos para el mejor funcionamiento, esto incluye cambiar valores de resolución de pantalla, nivel de detalle en los modelos, calidad de luces y sombras, entre muchos otros. Al desarrollar para PC estos parámetros se suelen dejar libres para la gran variedad de hardware existente, de tal forma que el mismo jugador pueda calibrar el juego para la configuración de su computadora. Pero para desarrollo de consolas o dispositivos móviles se debe optimizar para su mejor rendimiento dentro de un hardware más limitado. (Graham & McShaffry, 2012)

2.3.1.2.3.1.3.2 Audio El audio de un juego se puede dividir en tres áreas: efectos de sonido, música y diálogos, el programador trabaja junto al equipo de audio viendo que todo se reproduzca correctamente y que unos sonidos no ahoguen a otros. (Graham & McShaffry, 2012) Los efectos de sonido son elementos simples que no ocupan mucho espacio de procesamiento ni espacio en disco, son reproducidos por un evento para dar más vida al juego. (Graham & McShaffry, 2012) La música puede ser algo mucho más complejo, si bien no de forma técnica, el trabajo del programador por la parte de música será ver que la música se reproduzca correctamente y que su volumen no distraiga de los demás elementos. (Graham & McShaffry, 2012) De ser usado, los diálogos pueden ser el sistema más complicado, ya que suelen reproducirse junto a animaciones, es trabajo del programador hacer que la animación del personaje y su dialogo se sincronicen. (Graham & McShaffry, 2012)

2.3.1.2.3.1.3.3 Gestor de procesos Cumple la misma función que el gestor de procesos de la capa de lógica de juego, atrapa los datos de entrada de la capa de aplicación y ejecuta eventos dentro de esta capa, son procesos mucho más simples que los de la capa de lógica de juego, generalmente siendo elementos de presentación, como animación de elementos en la interfaz gráfica, la reproducción de sonido, entre otros. (Graham & McShaffry, 2012)

2.3.1.2.4 Implementación La última parte de la fase de producción consiste en unir todos los demás elementos para la creación del juego, se implementan los activos creados en el motor y se usan para armar los niveles diseñados. Finalmente se aplica todo lo desarrollado en la etapa de programación para darle lógica y funcionalidad al juego. Esta parte es repetida varias veces durante el desarrollo ya que todo el equipo prueba que el juego se está desarrollando correctamente. (Graham & McShaffry, 2012)

Aquí es cuando se deciden cambios a realizarse por alguna eventualidad, un modelo podría ser rediseñado si es que después de probarlo no da los resultados requeridos, o puede ser demasiado complejo para el hardware a utilizarse, los activos pueden ser cambiados si al probarse no satisfacen las condiciones necesarias o puedan tener errores al verse dentro del motor de desarrollo. (Graham & McShaffry, 2012)

2.3.1.2.5 Alfa La etapa alfa es cuando toda la funcionalidad del juego ha sido implementada pero ciertos detalles (niveles, activos) faltan por terminar o se están reevaluando. Se llega a esta etapa cuando ya se puede jugar y todos los sistemas están implementados y funcionando. Si bien algunos sistemas pueden ser agregados o eliminados, lo único por desarrollar son partes menores. Un alfa por general está lleno de errores y bugs, ya que, si bien el juego está completo, aun no se lo ha probado correctamente. (Chandler, 2010)

2.3.1.3 Fase de Postproducción 2.3.1.3.1 Seguro de calidad Consiste en la revisión completa del alfa en busca de todos los errores, bugs, y glitches que puedan existir. El equipo de seguro de calidad (que consiste en miembros del resto del equipo de desarrollo) generan una lista de los errores para que puedan ser arreglados. (Bates, 2004) Graham & McShaffry definen categorías de posibles errores:  Clase AA: Error extremadamente grave, puede hacer que todo el juego deje de funcionar, su arreglo es prioridad máxima. (Graham & McShaffry, 2012)  Clase A: Si bien el error no puede dañar los sistemas del juego, es lo suficientemente grave como para que el juego no esté en estado de ser lanzado, suelen ser errores que no permiten al jugador avanzar por el juego. (Graham & McShaffry, 2012)  Clase B: Un error que no corrompe al juego, pero los jugadores no tendrán problema en encontrarlo, son errores menores como que un objeto no esencial pueda desaparecer dentro de un nivel. (Graham & McShaffry, 2012)  Clase C: Arreglar este error no hará diferencia para el jugador, pero es notable para el equipo de desarrollo, como que la música incorrecta se reproduzca en un nivel. (Graham & McShaffry, 2012) Oxland indica que no existe una metodología estándar para el seguro de calidad, esto es principalmente ya que cada tipo de genero debe de ser evaluado de una manera distinta. Sin embargo, las distintas metodologías siguen ciertos pasos a la hora del aseguramiento de calidad, por lo general se incluyen los siguientes pasos: 1. Identificación: La funcionalidad incorrecta es analizada e identificada como una falla por el equipo de prueba. (Oxland, 2004) 2. Reportaje: Se reporta el error al equipo de desarrollo, no solamente el mismo, también las circunstancias para su aparición, es importante que el reporte de la falla sea bastante detallado para su arreglo. (Oxland, 2004)

3. Análisis: El desarrollador a cargo del área donde ocurre el error (sea problemas en diseño, activos o programación) revisa las características de la falla y trata de solucionarlo. (Oxland, 2004) 4. Verificación: Con el error solucionado, el equipo de prueba verifica que ya no pueda pasar, dependiendo su complejidad pueda que solo se lo haya mitigado, en esta etapa el equipo decide, según su categoría, si vale la pena arreglarlo completamente o no. (Oxland, 2004) Varios aspectos del juego deben de ser probados, entre ellos, los más importantes, según Oxland son los siguientes:  Pruebas de funcionalidad: Como su nombre lo indica, se prueba la funcionalidad de todos los sistemas del juego, no solo de parte técnica sino también de la parte creativa, así que se prueba la correcta funcionalidad de elementos desde la interfaz gráfica hasta las mismas mecánicas del juego. (Oxland, 2004)  Pruebas de conformidad: Fuera del juego mismo estas pruebas se las hacen por las plataformas a las que va a ser lanzado el juego, para que sea aceptado por las distintas plataformas (dispositivos inteligentes, consolas, computadoras) este debe cumplir con una normativa dada por el dueño de esa plataforma, esto puede incluir que el juego siga ciertos requerimientos técnicos e incluso requerimientos legales (como el uso de material bajo derechos de autor). Estas pruebas ocurren de forma interna y externa ya que el mismo equipo prueba el juego, así como un equipo de evaluación de calidad en la plataforma en la que se desea lanzar el juego. (Oxland, 2004)  Pruebas de compatibilidad: Se prueba el funcionamiento del juego a través de distintas configuraciones de hardware, no solo donde corre el juego sino también dispositivos de entrada, que tan extensa es esta etapa depende de las plataformas de desarrollo, un juego de consolas solo necesita de pruebas en una configuración, pero un juego para PC o dispositivos móviles puede necesitar de decenas de pruebas. (Oxland, 2004)  Pruebas de localización: Cuando un juego es lanzado en un idioma distinto al que fue escrito originalmente, este pasa por una prueba para revisar que la traducción y localización del juego haya sido realizada correctamente. (Oxland, 2004)  Pruebas de secado: En el contexto de los videojuegos, significa dejarlo correr por un largo periodo de tiempo. En particular se prueba que pasa con cada etapa del videojuego sin acciones del jugador por un largo tiempo. Pueden detectar errores que solo pasan a largo tiempo, como uso inadecuado de memoria. (Oxland, 2004)  Prueba de peso: Incluye probar los límites de los sistemas de juego, como cuantos personajes pueden estar en el mundo al mismo tiempo o probar un sistema con varios jugadores a la vez. (Oxland, 2004)

2.3.1.3.1.1 Beta La versión beta es cuando un videojuego ya tiene todos sus sistemas finales funcionando, todos sus activos finales integrados, y ya paso por una revisión de calidad; es decir, es la versión alfa después de ser corregida. (NEXT Generation, 1996)

Una versión beta aun va a tener varios errores, pero para esta etapa los errores son de clase B & C con mínimos errores de clase A. Al llegar a esta etapa el juego está listo para su última revisión y lanzamiento. (NEXT Generation, 1996)

2.3.1.3.1.2 Revisión final Después de que el juego haya llegado a beta hay una segunda prueba de calidad antes de la aprobación final del juego, al llegar a la beta la revisión ahora se la realiza en dos etapas, una segunda interna con el equipo de desarrollo y una externa realizada por un tercero. (Oxland, 2004)  Testeo Interno: Sigue la misma pauta que la revisión inicial.  Testeo Externo: Se utiliza un equipo externo al equipo de desarrollo para pruebas del juego, ya que es necesaria una revisión imparcial. Dependiendo de cómo se desee, esta revisión se la puede hacer sin el equipo de desarrollo, o en conjunto. Para juegos con servicios online no está fuera de lo común hacer una beta limitada con los mismos jugadores, llamado la open beta. (Oxland, 2004)

2.3.1.3.2 Lanzamiento Cuando la beta pasa por la segunda revisión y se aplican los cambios necesarios el juego pasa al estado conocido como candidato de lanzamiento, o versión oro, que es la versión final del juego. (NEXT Generation, 1996) En esta etapa el equipo de desarrollo decide que el juego ha llegado a su etapa final, y no habrá cambios adicionales, dependiendo de la escala de desarrollo esta etapa debe ser terminada varios meses antes del lanzamiento oficial para poder enviar al juego a certificación final con los dueños de las plataformas donde se lanzará el juego, así como para su producción física. En juegos de menor escala se puede terminar el día anterior a su lanzamiento oficial si es que este proceso no es necesario. (Graham & McShaffry, 2012)

2.3.2 Método Iterativo Se utilizó el método de desarrollo iterativo, como lo describe Gil y Alberto es un método de construcción de productos cuyo ciclo de vida está compuesto por un conjunto de iteraciones, las cuales tienen como objetivo entregar versiones del software. Cada iteración se considera un subproyecto que genera productos de software, permitiendo al usuario tener puntos de verificación y control más rápidos e induciendo un proceso continuo de pruebas y de integración desde las primeras iteraciones. (Gil & Alberto, 2004) El ciclo de vida del desarrollo del juego (GDLC, por sus siglas en inglés) es una guía que abarca el proceso de desarrollo del juego. Varios tipos han sido propuestos por diferentes organizaciones, pero ninguno de ellos aborda adecuadamente cómo garantizar las cualidades y entregar con éxito juegos de buena calidad. (Ramadan & Widyani, 2013) Aun así, el ciclo de vida que mejor se acopla al método iterativo de desarrollo sería el propuesto por Doppler Interactive, que según indica McGrath, consta de 6 pasos:

Diseño Desarrollo Evaluacion Prueba Revisión Lanzamiento

Ilustración 56: Ciclo de vida de desarrollo de software según Doppler Interactive (McGrath, 2011) La etapa de diseño incluye la creación del diseño inicial del juego, así como el desarrollo del documento de diseño del juego, con las ideas claras se pasa a la etapa de desarrollo donde se crea al juego y se lo evalúa en un ciclo hasta que el juego esté listo para ser probado internamente y poder encontrar y revisar errores, como penúltimo paso se lo pasa a una revisión externa para encontrar más inconsistencias, estos cinco pasos se iteran hasta que el juego esté listo para su lanzamiento. (Ramadan & Widyani, 2013) Cada iteración refina lo realizado en la iteración anterior. De esta forma se produce una dinámica en la que se van mejorando los productos entregables obtenidos en la iteración anterior. Eventualmente se realizarán todas las iteraciones planificadas, o se llegará al nivel de refinamiento deseado. (Gutierrez, 2011)

Ilustración 57: Descripción grafica del método iterativo. (Gutierrez, 2011)

2.3.2.1 Fases de desarrollo Larman y Basili describen a las fases de desarrollo como:  Fase de inicio: Se define el alcance de la iteración, se debe detallar que se hará y que no se hará en la iteración, es útil para establecer un límite claro y no hacer demasiado trabajo. Requerimientos (funcionales y no funcionales) y riesgos. Debe ser muy breve ya que solo tiene como objetivo la visión de la iteración. (Larman & Basili, 2003) Fase de elaboración: El objetivo principal es abordar los factores de riesgo y establecer y validar una arquitectura del sistema. Comúnmente incluye la creación de diagramas de uso de caso, diagramas conceptuales y diagramas de paquete según sea necesario. El fin de la fase de elaboración es de desarrollar un plan para la fase de construcción. (Larman & Basili, 2003)

 Fase de construcción: La fase más grande de la iteración, se aplica el plan formulado en la fase de elaboración, en la cual se modifica o se añade sistemas al juego, dentro de las fases de desarrollo esta fase puede ser iterada hasta que los objetivos planteados hayan sido completados. (Larman & Basili, 2003)  Fase de transición: El proceso de desarrollo fue terminado, los cambios realizados en la iteración son evaluados y preparados para la siguiente iteración. (Larman & Basili, 2003)

3. Capítulo III: Diseño e Implementación

3.1 Mecánicas del juego 3.1.1 Historia del juego Durante finales del año 2019 el juego de cuarenta ha cobrado una inusual popularidad en la ciudad de Quito. Valentina, una estudiante de colegio de 16 años, nota como cosas extrañas comienzan a suceder, en particular, nota a un gran número de personas exhaustas en la calle. Junto a su amiga Joseth, investiga las causas de lo que está sucediendo y encuentran una serie de cintas de VHS grabadas en 1999 que cuentan la historia de See-yeon, una estudiante universitaria de 23 años de descendencia coreana, que, junto a su hermanastra Johanna, descubrió que una organización estaba utilizando a las personas para construir una estructura en el subterráneo de la ciudad. Después que la misma familia de Valentina se viera implicada en esta organización buscaron más información sobre ella, encuentra fotografías de 1989 en su casa que relatan la historia de Diana, una oficinista de 36 años que, junto a su hijo Jonathan, descubrieron los planes de una organización que utilizaba el juego de cartas de cuarenta para controlar la mente de las personas. Valentina se guiará de las pistas dejadas por las demás para poder liberar a su familia y poner fin a los planes de la organización.

3.1.2 Las tres épocas La historia del juego se desarrolla a través de tres pocas, cada una de cuenta con su propia narrativa individual, sus propios personajes, y algunos niveles únicos. Más que contar una historia larga el juego consta con tres que no están relacionadas directamente. Adicionalmente cada era consta con su propio estilo visual que sirve para dar más variedad y dinamismo al juego, además de elementos complementarios dentro del mundo que diferencien más claramente las épocas, como los buses, el cabello de los personajes en cada, entre otros. Otro propósito de las tres eras es la reutilización de niveles bajo distintos estilos visuales, permitiendo más fácilmente agrandar el mundo y duración del juego.

3.1.2.1 2019

Ilustración 58: Target render de la era de 2019 en Quito Quest (Ronquillo, 2019) La principal era del juego, la más extensa y la única visitada más de una vez. Es la época actual y alberga a los personajes más importantes de la historia, el estilo visual de esta era es

57 simple sin procesar la imagen del juego, es decir, usa el render53 nativo empleado en Unreal Engine 4. Los menús de cada era cumplen la misma funcionalidad, pero tienen estilos distintos, para 2019 el menú es un smartphone de la actualidad, como se puede observar en la ilustración 58. Adicionalmente el tipo de letra utilizado en los menús de cada era también es único y tiene relación a la era a la que pertenece.

3.1.2.2 1999

Ilustración 59: Target render de la era de 1999 en Quito Quest (Ronquillo, 2019) La primera época visitada después de 2019, se puede acceder luego de encontrar las cintas de VHS, See-yeon y Johanna son los personajes jugables en esta parte del juego. Para la era de 1999 se utilizó una manipulación de la imagen del juego de tal forma que la imagen generada simule ser una cinta de VHS, o un video siendo reproducido por un televisor CRT, ambos elementos habiendo sido muy populares en esa época. Para crear este efecto se agregó una capa ruido a la imagen, así como barras de escaneo y una leve distorsión a los canales de color. Los menús de la era asemejan los celulares utilizados a fines de la época de los 90s, puntualmente tratando de emular el Nokia 8210, y el tipo de letra para los menús es de un estilo digital, el usado en esos celulares.

3.1.2.3 1989

Ilustración 60: Target render de la era de 1989 en Quito Quest (Ronquillo, 2019)

53 Render: Un término usado en computación para referirse al proceso de generar imágenes por computadora. 58

La última época visitada en el juego, se puede acceder luego de encontrar un álbum de fotografías, Diana y Jonathan son los personajes jugables en esta parte del juego. La imagen es manipulada de tal forma que el juego cobra la apariencia de una fotografía desgastada tomada por una cámara con rollo, se utiliza una fotografía como el elemento por usar ya que se utiliza video para la época de 1999. Los efectos que generan la imagen incluyen cambiar los colores del mundo para que tomen un tono sepia con una muy leve distorsión a los canales de color, así como una cubierta para simular a la fotografía. Los menús de esta etapa asemejan a una libreta con un tipo de letra que tenga la apariencia ser escrito por una máquina de escribir.

3.1.3 Party El grupo de personajes controlables será de máximo dos por cada era, con un personaje principal y un personaje de apoyo en cada parte. Dentro del mundo del juego el jugador solo tendrá control directo sobre uno, con el segundo personaje siguiéndolo, este personaje no interactuará con el mundo, pero servirá como apoyo en la exploración y combate.

3.1.3.1 Party en 2019

Valentina El personaje principal del juego y de la época de 2019, estudiante de secundaria de 16, rebelde y temeraria.

Ilustración 61: Ilustración de Valentina en Quito Quest (Escobar, 2019)

Joseth Personaje de apoyo para la época de 2019, la mejor amiga de Valentina también es estudiante secundaria y tiene la misma edad, de actitud mucho más calmada y articulada.

Ilustración 62: Ilustración Joseth en Quito Quest (Escobar, 2019)

Tabla 12: Personajes dentro del party de 2019 (Ronquillo, 2019)

3.1.3.2 Party en 1999

See-yeon El personaje principal de la era de 1999, estudiante universitaria de descendencia coreana, con actitud tranquila.

Ilustración 63: Ilustración de See-yeon en Quito Quest (Escobar, 2019)

Johanna Personaje de apoyo de 1999, hermanastra de See-yeon, también estudiante universitaria, con actitud relajada y aventurera.

Ilustración 64: Ilustración de Johanna en Quito Quest (Escobar, 2019)

Tabla 13: Personajes dentro del party en 1999 (Ronquillo, 2019)

3.1.3.3 Party en 1989

Diana Personaje principal para 1989, una oficinista de 30 años que esta aburrida con su vida.

Ilustración 65: Ilustración de Diana en Quito Quest (Escobar, 2019)

Jonathan Personaje de apoyo para 1989, hijo de Diana, adolescente, no se lleva muy bien con su madre.

Ilustración 66: Ilustración de Jonathan en Quito Quest (Escobar, 2019)

Tabla 14: Personajes dentro del party en 1989 (Ronquillo, 2019)

3.1.3.4 Atributos Cada party tendrá un atributo general, el dinero del grupo, los personajes del juego podrán ganar dinero al vencer a enemigos dentro del combate y lo podrán usar para comprar ítems que facilitara el progreso dentro del juego, como funcionan estos sistemas se detalla más adelante. Adicionalmente cada personaje tiene una lista de atributos. Son los puntos de vida con los que cuenta el personaje en algún momento, con un valor entre 0 y el valor máximo de puntos de vida. Puntos de El valor de este atributo puede aumentar al consumir ítems que regresan vida actuales puntos de vida y se pierden cuando el personaje es atacado dentro del combate. De llegar a cero el personaje oes noqueado y el jugador pierde el combate y debe cargar su juego desde el último punto guardado. Indica el valor máximo que los puntos de vida actuales pueden tener en Puntos de cualquier momento dentro del juego, su el valor de los puntos de vidas vida totales totales dependerá del nivel del personaje y aumentará según el jugador progrese. La fuerza del personaje determina cuánto daño puede hacer el jugador Puntos de dentro del combate, puede subir cuando el personaje sube de nivel o ataque cuando utiliza un ítem que sube el valor de este atributo. No puede bajar de valor. Determina cuánto daño recibe un personaje dentro del combate, puede Puntos de subir cuando el personaje sube de nivel o cuando se utiliza un ítem que lo defensa aumenta. No puede bajar de valor. La recompensa del jugador por vencer en el combate, al llegar a ciertos Puntos de valores totales el jugador podrá subir de nivel. Únicamente aumenta al experiencia ganar un combate. El nivel del jugador en algún momento, su valor determina que tanto ha avanzado el jugador dentro del juego. Cuando el valor total de puntos de Nivel experiencia llega a ciertos valores, el jugador subirá de nivel y todos los atributos anteriores, a excepción de los puntos de experiencia y puntos de vida actuales, subirán permanentemente. Tabla 15: Atributos de los personajes en Quito Quest (Ronquillo, 2019)

3.1.4 Ítems 3.1.4.1 Ítems importantes Los ítems importantes son entregados al jugador por un personaje no jugable al completar un objetivo dado o serán encontrados dentro del mundo del juego, en cuyo caso conseguirlos es un objetivo. Coleccionar ítems no es uno de los objetivos principales del juego, pero se utilizan para avanzar la historia dentro del mismo. Como su nombre lo indica estos ítems tienen importancia dentro del mundo del juego y su historia. Por lo general estos ítems no pueden ser utilizados por el jugador, únicamente sirven para indicar al jugador cuanto a progresado, así como darle pistas de que hacer y a donde ir. Los ítems importantes que puede usar el jugador incluyen cintas de VHS y fotografías, como indicado en la historia, pero solo pueden ser utilizados en lugares y situaciones específicas, no cuando el jugador quiera usarlos.

3.1.4.2 Ítems consumibles Los miembros del party pueden subir sus atributos al utilizar ítems consumibles. Dentro del juego el jugador puede conseguir este tipo de ítems en cantidades limitadas al interactuar con personajes del juego, también al vencer en el combate, el jugador ocasionalmente es recompensado con ítems consumibles además de puntos de experiencia y dinero. Finalmente, puede conseguirlo de forma ilimitada en distintas tiendas repartidas dentro de los niveles, si bien estos ítems están en cantidades ilimitadas ya que a una tienda nunca se le acabaran los ítems, el jugador solo puede comprar ítems según la cantidad de dinero que tenga. Existen tres tipos de ítems consumibles, cada uno con la capacidad de alterar solo un atributo de un personaje:  Ítems regenerativos: Regeneran los puntos de vida de un personaje, hay una gran variedad de estos ítems repartido por el juego con distintos precios y distinta eficiencia, según su precio regeneran más puntos de vida.  Ítems que suben fuerza: Suben los puntos de ataque de un personaje, estos ítems existen en poca variedad dentro del juego y tienen alto precio, los más caros de esta clase suben la fuerza en poca cantidad.  Ítems que suben la defensa: Prácticamente idénticos a los ítems que suben fuerza solo que esta clase sube los puntos de defensa, de poca variedad y alto precio, suben la defensa en poca cantidad.

3.1.4.3 Atributos Igual que con cada personaje dentro del party los ítems tienen una lista de atributos que define su funcionalidad dentro del juego. Nombre Atributo que identifica al ítem, cada uno debe de tener un nombre único. Identifica el tipo de ítem, puede ser un ítem importante o uno de los 3 Tipo ítems consumibles. Solo aplica a ítems consumibles, es el valor en el que el ítem aumentara Valor el atributo del personaje. Es el precio por el que el ítem estará en una tienda, es decir el precio por Precio compra el que el jugador compra el ítem. Además de comprar ítems el jugador podrá vender los ítems Precio venta consumibles devuelta a una tienda según necesite, el precio de venta siempre será menor al precio de compra. Tabla 16: Atributos de los ítems en Quito Quest (Ronquillo, 2019)

3.1.5 Estructura de niveles Cada nivel dentro del juego tiene un diseño relativamente único, sin embargo, la mayoría de los niveles compartirán una estructura que será usada a través del juego en donde varios elementos se verán repetidos en varios niveles.

Ilustración 67: Plano de un nivel en Quito Quest (Ronquillo, 2019)

3.1.5.1 Punto de inicio Marcado como una X dentro de una casilla en la ilustración 67. Incluido en todos los niveles del juego, es la posición en donde empieza el jugador cuando carga un nivel, es un punto permanente y su ubicación raramente cambia. Este punto está en una ubicación de tal forma que hay un elemento en plena vista que captará la atención del jugador tan pronto inicie el nivel, esto incentiva al jugador a explorar y poder conseguir pistas sobre qué hacer después.

Ilustración 68: Arte conceptual mostrando el punto de inicio de un nivel en Quito Quest (Ronquillo, 2019)

3.1.5.2 Elementos con interactividad Marcados como una X en la ilustración 67. Son la mayoría de los elementos con los que el jugador puede interactuar dentro del juego, en particular, otros personajes, objetos y enemigos.

 Otros personajes: Interactuar con otros personajes inicia una conversación entre el party actual y el personaje con el que se está interactuando, el contenido y duración de varía mucho a través del juego, ciertos personajes obsequiaran ítems al jugador al terminar de hablar, si se satisfacen algunas condiciones. Si bien conversar con algunos personajes puede ser un objetivo dentro del juego la mayoría de las interacciones sirve para la exposición de la historia al jugador, así como para la construcción del mundo y que el juego pueda ser más interesante.  Objetos: Ciertos objetos dentro del mundo de juego poseen interactividad, cuando el jugador trate de interactuar con ellos también se iniciará una conversación, pero solo entre los miembros del party actual donde comentarán sobre el objeto en cuestión. Interactuar con objetos también puede ser un objetivo dentro del juego, por lo general el jugador obtendrá un ítem al interactuar con un objeto.  Enemigos: Los enemigos serán los únicos elementos activos dentro del mundo del juego además del jugador, todos los demás elementos permanecerán inmóviles (objetos y personajes), se moverán por un camino determinado, o se moverán aleatoriamente dentro de un espacio determinado (personajes). Sin embargo, los enemigos cazan al jugador dentro del nivel e iniciaran el combate cuando entran en contacto.

3.1.5.3 Entrada a otros niveles Marcado como bloques sombreados en la ilustración 67. Son otros objetos en un nivel con interactividad. Cuando el jugador interactúe con estos elementos será llevado a otro nivel. Cada uno posee por lo menos una salida, pero la mayoría de ellos contara con varias salidas.

Ilustración 69: Arte conceptual de acceso a otros niveles en Quito Quest (Ronquillo, 2019) Un JRPG suele abrirse al jugador de tal forma que este pueda explorar según desee, por lo que niveles no deben seguir una estructura lineal, aun cuando el sistema de progresión si sea lineal.

3.1.5.4 Tiendas Marcado como cruces dentro de cajas en la ilustración 67. Como sea mencionado anteriormente las tiendas serán los lugares dentro del juego donde el jugador podrá comprar y vender ítems consumibles.

El juego contara con tres tipos de tiendas, cada una con ciertos ítems disponibles.  Tienda pequeña: Las más comunes dentro del juego y presentes en casi todo nivel, por lo general solo venden ítems consumibles regenerativos de bajo costo.  Tienda grande: Menos común presente en pocos niveles, venden toda clase de ítems consumibles regenerativos, de todos los costos.  Farmacia: Más común que una tienda grande pero menos común que una tienda pequeña, venden únicamente ítems consumibles de defensa y ataque.

Ilustración 70: Arte conceptual de los distintos tipos de tiendas en Quito Quest (Ronquillo, 2019)

3.1.6 Sistemas de juego 3.1.6.1 Sistema de progresión El sistema de progresión dicta la funcionalidad de los demás sistemas del juego ya que todos estos pueden cambiar de estado según el progreso del jugador dentro del juego.

Ilustración 71: Arte conceptual de la progresión de una misión en Quito Quest (Ronquillo, 2019) Como se mencionó anteriormente la estructura de niveles del juego le permiten al jugador explorar al mundo de una manera no lineal, sin embargo, la estructura de progresión del juego es estrictamente lineal permitiendo que el jugador logre progresar a través de la historia del juego únicamente al cumplir ciertos objetivos en un orden especifico.

3.1.6.1.1 Misiones La arquitectura del sistema de progresión utiliza un modelo basado en misiones, es decir, una serie de objetivos que se deben cumplir en un orden especifico. Similar a los objetivos dentro de cada misión, estas también deben ser completadas en un orden en particular, por lo que el jugador solo puede iniciar una misión al terminar otra y solo si la misión cumplida precede a la misión que este quiere iniciar. Una misión puede tener un número N de objetivos y será considerada completada una vez que el último objetivo haya sido completado.

Misión 1 Missión 2 ... Misión n

•Objetivo 1 •Objetivo 1 •Objetivo 1 •Objetivo 2 •Objetivo 2 •Objetivo 2 •... •... •... •Objetivo n •Objetivo n •Objetivo n

Ilustración 72: Esquema de funcionalidad de misiones en Quito Quest (Ronquillo, 2019) 3.1.6.1.2 Objetivos Los objetivos son los verdaderos ladrillos que arman el sistema de progresión del juego, con las misiones sirviendo como bloques para agruparlos, por ello son estos los que dictan el estado de los demás elementos del juego y al ser completados pueden modificar al mundo del juego, cambiando la posición de elementos dentro del mundo, así como la configuración de luces del nivel entre otros. Existen dos posibles objetivos que el jugador debe de completar para cumplir una misión:  Objetivos de marcador: Completados cuando el jugador llega a un marcador dentro del mundo, es decir, cuando llegue a una ubicación en particular. Por lo general el jugador será llevado a un lugar en específico cuando se necesite que este complete otras acciones en este lugar o haga falta enseñarle algo importante dentro del mundo del juego.  Objetivos de interacción: Completados cuando el jugador interactúa con un elemento dentro del mundo, sea un objeto o un personaje, estos pueden dar más contexto a las acciones actuales del jugador, así como darle pistas de que hacer y adonde ir después de cumplir este objetivo. Los objetivos pueden ser opcionales y obligatorios, con solo lo obligatorios siendo necesarios completar para cumplir una misión y seguir el progreso del juego. Los objetivos opcionales sirven para darle más información al jugador, mientras que los objetivos obligatorios deben de necesariamente ser cumplidos en el orden establecido que se le da al jugador, por ejemplo: aun cuando el jugador satisfaga la condición de un objetivo #4, este no es considerado completado sin completar primero los objetivos #1 – #3, si bien esto da una estructura un poco rígida al sistema de progresión permite tener un control más directo dentro de los demás sistemas de juego.

3.1.6.2 Sistema de conversación Como se mencionó anteriormente, cuando el jugador interactúe con un objeto o un personaje dentro del mundo se inicia un sistema de conversación, esto es representado por medio de una interfaz gráfica donde se muestra una conversación entre dos o más personajes del juego, generalmente miembros del party actual, así como el personaje con el que se interactuó y ocasionalmente otros personajes.

Ilustración 73: Arte conceptual del sistema de conversación en Quito Quest (Ronquillo, 2019) Por medio de este sistema es como al jugador se le enseña las mecánicas principales, así también cómo se desarrolla la historia, como se desarrollan los personajes tanto principales como secundarios y una de las maneras del cómo el jugador construirá el mundo del juego. Es uno de los sistemas más importantes y está presente de principio a fin en todo el transcurso del juego. Que conversación se ejecuta depende con que personaje u objeto esta interactuando con el jugador, así como cuales objetivos a completado, de tal forma que cuando el jugador interactúe con un personaje u objeto en un punto se realice una conversación, pero después de completar algún objetivo puede que al interactuar con este personaje u objeto se pueda ejecutar una conversación distinta. Es el sistema que más claramente muestra el progreso del jugador a través del juego, ya que las conversaciones indican las acciones pasadas del jugador y como estas afectan el mundo, así como el sistema más importante en guiar al jugador a través de la historia, dándole pistas del siguiente nivel al que ir y la siguiente acción a tomar.

3.1.6.3 Sistema de combate En lugar de utilizar una pauta vista en varios otros JRPGs, donde los miembros del party y personajes se atacan directamente, se utilizó el tradicional juego de cartas “Cuarenta”, con el objetivo que el juego tenga un combate único y resalte más del juego.

3.1.6.3.1 Juego de cartas “Cuarenta” Es un juego desarrollado y practicado en el Ecuador, generalmente considerado como el juego de cartas más popular en el país, teniendo una popularidad particular en las ciudades de Quito y Cuenca. Considerado un juego pasivo, ya que no utiliza esfuerzo físico, únicamente esfuerzo mental. El objetivo del juego, como su nombre lo indica, es llegar a los 40 puntos, la condición de ganar el juego y también el número de cartas usadas en una partida. Se puede jugar con dos jugadores o en parejas de dos jugadores con un máximo total de cuatro jugadores. (Barros, Rodriguez, & Barros, 2015)

3.1.6.3.1.1 Reglas del Cuarenta Martínez y Welty desglosan al juego como:  Los jugadores: Como se mencionó anteriormente el cuarenta se puede jugar de 2 a 4 jugadores, de ser el caso de cuatro, estos se dividen en equipos de dos donde los miembros del mismo equipo se sientan opuestos los unos de los otros. Un miembro colectará los puntos del equipo mientras que otro colectará las cartas que el equipo gana durante la mano. (Martinez, 2018)  La baraja: Se utiliza 40 cartas de una baraja estándar de 52 cartas, las cartas de 8, 9 y 10 no son utilizadas dentro del juego, pero pueden servir para contar los puntos. El juego utiliza las cartas del 2 al 7, con el as teniendo el valor de 1 y utilizando las cartas de Jack, rey y reina sin valor numérico. (Welty, 2008)  Repartición inicial: Al iniciar el juego cada jugador retirará una carta aleatoria de la baraja, el que saque la carta con mayor valor repartirá la primera mano, una vez que se hayan jugado las 40 cartas el jugador a la derecha de este repartirá la siguiente mano, y así sucesivamente hasta culminar el juego. Se repartirán 5 cartas a cada jugador en cada mano. (Martinez, 2018)  Manos especiales: Después de repartir las cartas hay la posibilidad que uno de los jugadores tenga una mano de cartas especial, en este juego existen dos, y tienen distintos efectos dentro del juego. (Welty, 2008) o Cuatro de un tipo: Si cualquier jugador tiene las 4 cartas de un tipo, el equipo al que pertenece el jugador gana el juego inmediatamente. (Welty, 2008) o Ronda: Si cualquier jugador tiene 3 cartas de un mismo tipo es llamado ronda y el equipo recibe dos puntos. (Welty, 2008)  El juego: El juego empieza con el jugador a la derecha del repartidor en dirección en contra las agujas del reloj. Durante cada turno el jugador pondrá una carta en la mesa, dependiendo de qué carta haya usado y que cartas haya en la mesa pueden ocurrir las siguientes situaciones. (Welty, 2008) o Caída: Si el jugador usa una carta del mismo tipo que el jugador anterior utilizó y esta sigue en la mesa se denomina caída, el equipo es recompensado con 2 puntos y conserva las dos cartas. Por ejemplo: Si el jugador anterior lanzó un 3 y el jugador actual lanza otro 3 es una caída y su equipo se queda con las 2 cartas. (Welty, 2008) o Suma: Si el jugador usa una carta que es el resultado de la suma de dos cartas en la mesa este conservara las 3 cartas. Esto únicamente se puede hacer con cartas con valores numéricos, por lo que las cartas de Jack, reina y rey no pueden

ser utilizadas. Por ejemplo: Si hay un 2 y un 3 en la mesa y el jugador lanza un 5 este jugador se llevará las 3 cartas. (Welty, 2008) o Secuencia: Después de realizar cualquier de las acciones anteriores, si en la mesa hay cartas con mayor valor a la carta usada por el jugador este podrá llevarse todas esas cartas también, en este caso si cuentan las cartas Jack, reina y rey, por lo que la secuencia completa de cartas es As-2-3-4-5-6-7-Jack-Reina- Rey. Por ejemplo: Si en la mesa están las cartas 2, 3, 4, 5, Jack, y el jugador juega un 2 este podrá llevarse todas las cartas hasta el 5, pero también si el jugador juega un 7 este podrá llevarse el 2, el 5 y el Jack. (Welty, 2008) o Limpia: Si al completar cualquiera de las acciones anteriores la mesa se queda sin cartas esto se considera una limpia y el equipo que la realizo se llevara 2 puntos. (Welty, 2008) o Si al usar una carta el jugador no logra ninguna de estas acciones la carta se quedará en la mesa y será turno del siguiente jugador. (Welty, 2008) Después de jugar las primeras 20 cartas se repartirán las demás 20 y seguirá el juego, en este punto el primer jugador no podrá hacer una caída, aun si lanza una carta del mismo tipo a la carta usada en el último turno de la mano anterior. (Welty, 2008)  Montón: El grupo de cartas que cada equipo colecta a través de una mano es llamado montón, estas cartas son contabilizadas después de jugar las 40 cartas, y dependiendo de cuantas tenga cada equipo estos podrán obtener puntos adicionales. (Martinez, 2018)  Puntuación: Como se mencionó anteriormente cada equipo ganara 2 puntos al realizar una caída o una limpia, dependiendo de cómo se decidan las reglas si una caída y una limpia suceden en el mismo turno el equipo obtendría 4 puntos, pero también se puede decidir que en este escenario solo se obtengan dos puntos. (Welty, 2008) Además de esta forma, la otra forma de sumar puntos es contando el montón al final de cada mano, si un equipo tiene 20 cartas en su montón a este se le agregaran 6 puntos y un punto adicional por cada carta más que tenga, tal que si un equipo tiene 21 o 22 cartas obtienen 7 y 8 puntos adicionales, respectivamente. (Welty, 2008)

Cartas en el montón Puntos adicionales 20 6 21 7 22 8 23 9 24 10 25 10+1 26 10+1 27 10+2 28 10+2 29 10+3 30 10+3 31 10+4 32 10+4 33 20 34 20 35 20+1 36 20+1 37 20+2 69

38 20+2 39 20+3 40 20+3 Tabla 17: Puntos adicionales según cartas en el montón en el juego de “Cuarenta” (Cardsgames) Si un equipo llega a 38 puntos se puede aplicar la regla “38 que no juega” donde solamente contaran los puntos realizados al hacer una caída, de tal forma que el equipo solo podrá ganar de esa manera, ya no contaran rondas, limpias ni cartas del montón. (Welty, 2008)

3.1.6.3.2 Cuarenta como combate Los enemigos buscan al jugador, ya que el juego de Cuarenta es como la organización gana miembros de forma inconsciente, sin embargo, esta es una espada de doble filo, ya que al ser vencidos en el mismo juego los seguidores de la organización salen de su control. Las reglas de Cuarenta usadas dentro del juego serán lo más simples posibles, no se emplea la regla de “38 que no juega” y una caída y limpia vale 2 puntos cada uno, de tal forma que, si el jugador hace las dos en un turno, tiene 4 puntos en total. Al iniciar el combate uno de los participantes es elegido de manera aleatoria para jugar la primera mano, se juega en parejas donde el jugador controla a los dos miembros del party actual contra un par aleatorio de enemigos, el jugador controla a cada miembro de forma individual según su turno.

Ilustración 74: Arte conceptual del combate en Quito Quest (Ronquillo, 2019) Cada participante en el combate cuenta con sus puntos de vida, estos puntos muestran el control que tiene la organización sobre dicho personaje, cuando los puntos de vida del jugador llegan a cero es porque han caído bajo control de la organización y pierden el conocimiento, mientras que sí lo mismo sucede a los enemigos es porque han sido liberados del control de la organización, e igualmente, pierden el conocimiento y quedan inactivos por el resto del combate. Una pelea termina una vez que cualquiera de los miembros de un equipo pierda el conocimiento sea por puntos de vida o por perder en el juego de cartas. Los personajes pierden el conocimiento ya que al bajar sus puntos de vida ellos mentalmente pierden, aun cuando el juego no se haya terminado, y caen o se liberan de la influencia de la organización.

Por la larga duración que puede tener un juego de cuarenta, para poder vencer a un enemigo no será necesario jugar un juego entero, solo poder noquear a los oponentes, sin embargo, el party actual conseguirá más puntos de experiencia al llegar a los cuarenta puntos. Un personaje hará daño a otro personaje al hacer una caída o una limpia, haciendo daño mayor si se lleva cartas adicionales, el daño que un personaje hace a otro dependerá del valor de los puntos de vida del personaje que ataca y los puntos de defensa del personaje que recibe daño. Ya que una caída y una limpia son los únicos movimientos capaces de hacer daño cada personaje solo podrá atacar al personaje a su izquierda dentro del combate. A ser su turno el jugador podrá realizar tres acciones:  Usar una carta: El jugador puede seleccionar una carta de su mano y realizar un movimiento con ella, los resultados dependerán de la carta que use y las cartas en la mesa.  Usar un ítem: Dentro del combate el jugador puede utilizar los ítems consumibles regenerativos que tenga el party actual, el jugador puede usar el ítem en cualquier miembro del party no solo del que esté utilizando, pero una carta aleatoria de su mano será enviada al montón del equipo contrario y terminará su turno, es decir, el jugador podrá hacer solo un movimiento en su turno, cualquiera que sea.  Tratar de escapar: El jugador puede tratar de escapar del combate en su turno si lo desea, las probabilidades de escape dependerán de la diferencia de niveles entre el party actual y el grupo enemigo, de ser exitosa la acción el jugador regresará el mundo de juego y podrá continuar explorando, de fallar, una carta aleatoria de su mano será enviada al montón del equipo contario y finalizará su turno. De ser victorioso en el combate el jugador será recompensado con puntos de experiencia, dinero y, de vez en cuando, con ítems consumibles, antes de regresar al mundo de juego, cuantos puntos, cuánto dinero y el valor del ítem dependerán del nivel del enemigo, mientras más alto sea, será mejor la recompensa. Caso contrario el jugador será llevado al menú principal del juego, y para poder continuar deberá cargar el juego desde la última vez que guardó, perdiendo todo su progreso desde entonces hasta el combate donde perdió.

3.1.6.4 Enemigos Como ya se ha mencionado, cuando un enemigo dentro del mundo entre en contacto con el jugador se iniciará un combate, al ocurrir esto se llama a una lista de posibles enemigos para hacer el equipo contrario al jugador dentro del combate. La apariencia física del enemigo dentro del mundo del juego no tiene relación con los enemigos a combatir. Existe una lista de posibles enemigos con distintos valores de puntos de vida, fuerza, defensa y experiencia que dan al jugador en caso de vencerlos, así como de distintos niveles. Cuando el jugador complete un objetivo en particular el nivel mínimo de enemigos que puedan ser llamados dentro del sistema de combate subirá de tal forma que el desafío del combate crezca según el jugador avance dentro del juego, esto también sirve para animarlo a entrar en combate y subir los atributos del party actual, manteniendo un desafío interesante durante el juego.

3.1.6.4.1 Atributos Nombre Cada enemigo tiene un nombre único para identificarlo. Hay varios enemigos con distintos niveles que subirán según el Nivel jugador avance durante el juego. Similar a los puntos de vida del jugador, cada enemigo tiene una cantidad de puntos de vida totales, que, al llegar a cero el juego determina al enemigo como derrotado y termina el Puntos de vida combate. A diferencia del jugador los enemigos no pueden recuperar sus puntos de vida. Mientras más alto sea el nivel del enemigo, mayor el valor de sus puntos de vida. Determinan cuánto daño podrá realizar el enemigo en caso de Puntos de fuerza atacar al jugador. Mientras más alto sea el nivel del enemigo, mayor el valor de sus puntos de fuerza. Determinan cuanto puede bloquear un ataque del jugador en Puntos de defensa caso de ser atacado. Mientras más alto se al nivel del enemigo, mayor el valor de sus puntos de defensa. En caso de cargar un ítem, el enemigo le da un ítem consumible Ítem al jugador al terminar el combate. Son los puntos de experiencia que el enemigo le dará al party actual al terminar el combate, los puntos totales que recibe el Puntos de party actual son la suma de los puntos de experiencia de los dos experiencia enemigos. Mientras más alto sea el nivel del enemigo, mayor el valor de los puntos de experiencia que otorga. Tabla 18: Atributos de los enemigos en Quito Quest (Ronquillo, 2019)

3.1.7 Flujo de juego Dentro del juego el jugador puede realizar una gran variedad de acciones, como ya se describió en el sistema de progresión, para avanzar dentro del juego se debe cumplir una serie de misiones y objetivos. Que son estos objetivos varia dentro del juego, pero se puede definir al flujo del juego como: 1. Exploración a. El jugador debe explorar el mundo del juego buscando pistas de que hacer y a donde ir. b. Como objetivo principal está encontrar al personaje que le asigne una nueva misión. 2. Cumplimiento de objetivos a. Con una misión asignada el objetivo principal del jugador es completar dicha misión por lo que debe cumplir los objetivos de esta. b. Va en conjunto con la etapa de exploración ya que ciertos objetivos darán pistas sobre donde ir después y con qué elementos interactuar. 3. Enfrentar enemigos a. El jugador debe enfrentarse a enemigos mientras explora y cumple objetivos para mantener un buen nivel durante el transcurso del juego. b. Si bien esta etapa es técnicamente opcional, no es recomendable que el jugador no mantenga un buen nivel dentro del juego ni que trate de experimentar dentro del combate, algo que se le indica dentro de la etapa de exploración.

Explorar

Completar Conseguir la misión una misión

Cumplir los objetivos Enfrentarse de la a enemigos mision

Ilustración 75: Esquema del flujo de juego en Quito Quest (Ronquillo, 2019)

3.2 Implementación de mecánica y código 3.2.1 Enumeradores Esta sección detalla los enumeradores usados en el desarrollo del juego, incluyendo su uso y sus posibles estados.  MainMenu_Enum: Define las acciones que se pueden realizar en el menú principal. Estado Descripción None Ninguno de los menús principales está activo. MainMenuActive El menú principal está activo. InLoad El menú de cargar juego está activo. InOptions El menú de opciones está activo. InCredits La ventana de créditos está activa. Tabla 19: Estados del enumerador MainMenu_Enum en Quito Quest (Ronquillo, 2019)

 CurrentYear_Enum: Define la época actual en la que se encuentra el jugador, usado como variable en el actor Personaje_BP. Estado Descripción 2019 Define la era actual como 2019. 1999 Define la era actual como 1999. 1989 Define la era actual como 1989. Tabla 20: Estados del enumerador CurrentYear_Enum en Quito Quest (Ronquillo, 2019)

 ItemType_Enum: Define los posibles tipos de ítems dentro del juego, utilizado como variable en Item_Struct y referenciado en todos los casos que se usen ítems. Estado Descripción HealthItem Define si es un ítem que regenera puntos de vida. StrengthItem Define si es un ítem que sube los puntos de fuerza. DefenseItem Define si es un ítem que sube los puntos de defensa. KeyItem Define si es un ítem importante. Tabla 21: Estados del enumerador ItemTypes_Enum en Quito Quest (Ronquillo, 2019)

 PlayerStatus_Enum: Define el estado actual del jugador y que acciones podrá tomar en un momento en particular. Estado Descripción Define si el jugador está actualmente moviéndose por el Moving mundo de juego. InConversation Define si el jugador está actualmente en una conversación. Define si el jugador está actualmente navegando por InMenus menús. InStore Define si el jugador está actualmente en una tienda. Define si el jugador está actualmente seleccionando en ir a ChoosingLevel otro nivel. InCombat Define si el jugador está actualmente en combate. Tabla 22: Estados del enumerador PlayerStatus_Enum en Quito Quest (Ronquillo, 2019)

 DateTime_Enum: Define la configuración de luz del juego según distintas partes del día. Estado Descripción Configuración utilizada en la mañana, las luces tomaran un tono Dawn azul claro. Configuración utilizada al medio día, las luces tomaran un Noon amarillo suave. Configuración utilizada en el ocaso, las luces toman un tono rojo Sunset suave. Configuración utilizada en la noche, la luz global es desactivada Night utilizando solo luces dentro de la escena. Tabla 23: Estados del enumerador DateTime_Enum en Quito Quest (Ronquillo, 2019)

 PlayerFacing_Enum: Define la dirección en la cual el jugador está mirando actualmente. Estado Descripción Indica si el personaje que controla el jugador está mirando a FacingLeft su izquierda. Indica si el personaje que controla el jugador está mirando a FacingRight su derecha. Indica si el personaje que controla el jugador está mirando la FacingForward cámara. Indica si el personaje que controla el jugador está mirando FacingBackwards en la dirección opuesta a la cámara. Tabla 24: Estados del enumerador PlayerFacing_Enum en Quito Quest (Ronquillo, 2019)

 GameLanguage_Enum: Define el idioma a utilizarse dentro del juego. Estado Descripción English El idioma del juego se configura para ingles Español El idioma del juego se configura para el español. Tabla 25: Estados del enumerador GameLanguage_Enum en Quito Quest (Ronquillo, 2019)

 ObjectiveType_Enum: Define las posibles clases de objetivos en una misión.

Estado Descripción El objetivo es una ubicación dentro de un nivel a la que el Location personaje debe llegar El objetivo es un elemento del mundo con el que el jugador debe Interact interactuar. Tabla 26: Estados del enumerador ObjectiveType_Enum en Quito Quest (Ronquillo, 2019)

 SemáforoEstados_Enum: Define los posibles estados del actor Semaforo_BP, utilizado como variable en ese acto, es referenciado en el actor Car_BP y todas sus instancias. Estado Descripción Rojo Usado si la luz del semáforo es roja. Verde Usado si la luz del semáforo es verde. Amarillo Usado si la luz del semáforo es amarilla. Tabla 27: Estados de enumerador SemaforoEstados_Enum en Quito Quest (Ronquillo, 2019)

 Combat_Enum: Define las posibles acciones del actor a realizar dentro del combate. Estado Descripción Indica que el jugador se puede mover en el menú SelectingMainOption principal del combate. SelectingCard Indica que el jugador está seleccionando una carta a usar. SelectingItem Indica que el jugador está seleccionando un ítem a usar. Indica que el jugador está seleccionando sobre que SelectingPartyMember miembro del party actual usar el ítem seleccionado. Indica que el enemigo está escogiendo una carta, utilizada EnemyAttacking para que el jugador no pueda hacer nada mientras un enemigo esté actuando. Tabla 28: Estados del enumerador Combat_Enum en Quito Quest (Ronquillo, 2019)

3.2.2 Estructuras Esta sección detalla las estructuras utilizadas en el juego, similar a la sección de enumeradores detalla el nombre de cada variable en una estructura, su tipo y una descripción de la función que cumple.  Item_Struct: Define los ítems dentro del juego. Variable Tipo Descripción ItemID Texto Identificador único del ítem. Nombre del ítem en inglés, este ItemNameEng Texto valor es el que es mostrado al jugador dentro del juego. Nombre del ítem en español, este ItemNameEsp Texto valor es el que es mostrado al jugador dentro del juego. Valor indica si el ítem es un ítem IsKeyItem Booleano importante o consumible.

Ilustración del ítem, usada para ItemPortrait Textura 2D mostrar de manera gráfica al jugador que es el ítem. Descripción del ítem en inglés, este ItemDescriptionEng Texto valor es mostrado al jugador dentro del juego. Descripción del ítem en español, ItemDescriptionEsp Texto este valor es mostrado al jugador dentro del juego. Tipo de ítem según el valor del ItemType ItemType_Enum ItemType_Enum Valor numérico del ítem cuando es ItemValue Integer usado. Como cuantos puntos de vida sube el ítem. Precio de compra del ítem, es decir, PrecioCompra Float el valor del ítem en una tienda. PrecioVenta Float Precio del ítem al venderlo. Tabla 29: Variables dentro del Item_Struct en Quito Quest (Ronquillo, 2019)

 PartyMember_Struct: Define los atributos de un personaje individual dentro del party. Variable Tipo Descripción Name Texto Nombre del personaje. Level Integer Nivel actual del personaje. Experience Integer Puntos de experiencia totales del personaje. CurrentHP Integer Puntos de vida actuales del personaje. TotalHP Integer Puntos de vida totales del personaje. Strength Integer Puntos de fuerza totales del personaje. Defense Integer Puntos de defensa totales del personaje. Tabla 30: Variables dentro del PartyMember_Struct en Quito Quest (Ronquillo, 2019)

 Party_Struct: Define el party actual usado dentro de cada nivel, es interesante ya que utiliza a otras estructuras como variables. Variable Tipo Descripción Guarda los datos del personaje MainMember PartyMember_Struct principal del party. Guarda los datos del personaje SecondMember PartyMember_Struct secundario del party. Money Float Dinero total del party. Tabla 31: Variables dentro del Party_Struct en Quito Quest (Ronquillo, 2019)

 QuestData_Struct: Define las misiones que el jugador puede realizar dentro del juego. Variable Tipo Descripción Nombre en inglés de la misión, este QuestName Texto dato es mostrado al jugador dentro del juego. Nombre en español de la misión, QuestNombre Texto este dato es mostrado al jugador dentro del juego.

Nombre (en inglés) de la misión que QuestPrerequisite Texto debe de ser completada para que esta misión pueda ser activada. Descripción de la misión en inglés, QuestDescription Texto este valor es mostrado al jugador dentro del juego. Descripción de la misión en español, QuestDescripcion Texto este valor es mostrado al jugador dentro del juego. Array de Objetivos por completar para QuestObjective ObjectiveData_Struct terminar la misión. Valor indica si la misión ha sido QuestIsComplete Boolean completada. Tabla 32: Variables dentro del QuestData_Struct en Quito Quest (Ronquillo, 2019)

 WidgetData_Struct: Define el texto permanente que se encuentra en cada Widget, guarda los datos en inglés y español para cada elemento de cada Widget. Variable Tipo Descripción WidgetName Texto Identificador único de cada interfaz. Identificador único de cada elemento de cada ElementName Texto interfaz. SpanishText Texto Texto en español del elemento. EnglishText Texto Texto en ingles del elemento. Tabla 33: Variables dentro del WidgetData_Struct en Quito Quest (Ronquillo, 2019)

 WorldLight_Struct: Guarda los elementos esenciales que guardan los datos de iluminación global de todo nivel dentro del juego, usado para cambiar la configuración de luz. Variables Tipo Descripción Luz Elemento de luz direccional, esencial que DirectionalLight direccional se crea en cada nivel por defecto. Niebla Elemento de niebla atmosférica, esencial AtmosphericFog atmosférica que se crea por defecto en cada nivel. Elemento de luz del cielo, se crea por SkyLight Luz del cielo defecto en cada nivel. BP Sky Elemento de SkySphere, se crea por SkySphere Sphere defecto en cada nivel. Tabla 34: Variables dentro del WorldLight_Struct en Quito Quest (Ronquillo, 2019)

 Time_Struct: Determina la hora, fecha y configuración de luces a utilizar dentro del juego. Variable Tipo Descripción TimeID Texto Identificador único de la estructura. Fecha actual del juego, este valor es Date Texto mostrado al jugador. Hora actual del juego, este valor es Time Texto mostrado al jugador. Parte del día de la estructura, debe de tener DayTime DayTime_Struct relación con los valores anteriores. Tabla 35: Variables dentro de Time_Struct en Quito Quest (Ronquillo, 2019)

 QuestTime_Struct: Vincula las misiones y la configuración de luces del juego, tal que al completar ciertos objetivos la configuración de luces del nivel cambie. Variable Tipo Descripción QuestId Texto Nombre de la misión en inglés. ObjectiveID Integer Número del objetivo. TimeID Texto Identificador único de un Time_Struct. Tabla 36: Variables dentro de QuestTime_Struct en Quito Quest (Ronquillo, 2019)

 NPCTime_Stuct: Vincula a personajes no jugables dentro del nivel con el cambio de la configuración de luces, de tal forma que al cambiar la configuración de luz el actor cambie de posición. Variable Tipo Descripción TimeID Texto Identificador único de un Time_Struct NPCID Texto Identificador único de un objeto con interactividad Valor booleano que indica si el actor debe estar Active Booleano activo con el TimeID actual. Vector que determina la posición dentro del nivel del Position Vector actor según el TimeID actual. Tabla 37: Variables dentro NPCTime_Struct en Quito Quest (Ronquillo, 2019)

 Cards_Struct: Guarda los elementos que define cada carta dentro del combate. Variable Tipo Descripción CardID Texto Identificador único de cada carta. CardValue Integer Valor numérico de cada carta. CardPortrait Textura 2D Ilustración de cada carta. Tabla 38: Variables dentro Cards_Struct en Quito Quest (Ronquillo, 2019)

 Objective_Struct: Define los objetivos que el jugador debe de completar en cada misión. Variable Tipo Descripción Descripción en ingles del objetivo, este Description Texto dato es mostrado al jugador dentro del juego. Descripción en español del objetivo, Descripcion Texto este dato es mostrado al jugador dentro del juego. Type ObjectiveData_Enum Define el tipo de objetivo a completar. IsOptional Booleano Define si el objetivo es opcional. Define si el objetivo ha sido IsComplete Booleano completado. El identificador único del actor que es TargetName Texto el objetivo. Tabla 39: Variables dentro de ObjectiveData_Struct en Quito Quest (Ronquillo, 2019)

 Character_Struct: Define las características más básicas de personajes dentro del juego. Variable Tipo Descripción Name Texto Identificador único del personaje. Portrait Textura2D Ilustración del personaje. Tabla 40: Variables dentro de Character_Struct en Quito Quest (Ronquillo, 2019) 78

 SimpleDialogue_Struct: Define los posibles diálogos simples dentro del juego. Variable Tipo Descripción NPCName Texto Identificador único del personaje. QuestName Texto Nombre de la misión que define el dialogo. Número del objetivo dentro de la misión que QuestObjective Integer define el dialogo. DialogueEsp Texto Dialogo en español. DialogueEng Texto Dialogo en inglés. Tabla 41: Variables dentro de SimpleDialogue_Struct en Quito Quest (Ronquillo, 2019)

 Dialogue_Struct: Define todas las posibles conversaciones dentro del juego. Variable Tipo Descripción Identificar del actor que guarda NPC_ID Texto conversaciones. Identificador único de cada conversación de Conversation_ID Integer ese actor. Identificador único de cada línea dentro de Line_ID Integer cada conversación. CharacterNameEsp Texto Nombre en español del personaje hablando. CharacterpNameEng Texto Nombre en inglés del personaje hablando. DialoguEng Texto Línea de dialogo en inglés. DialogueEsp Texto Línea de dialogo en español. Tabla 42: Variables dentro de Character_Struct en Quito Quest (Ronquillo, 2019)

 ConversationObjective_Struct: Define que conversación debe de ser reproducida y en que actor según qué objetivo ha completado el party actual Variable Tipo Descripción Nombre de la misión que alberga el objetivo a QuestName Texto cumplir ObjectiveID Texto Número del objetivo a cumplir Identificador del actor que guarda la NPCID Texto conversación. Conversación por reproducir al cumplir el Conversation_ID Integer objetivo. Tabla 43: Variables dentro de ConversationObjective_Struct en Quito Quest (Ronquillo, 2019)

 Enemy_Struct: Define a los enemigos dentro del combate. Variable Tipo Descripción EnemyID Texto Identificador único del enemigo. Level Integer Nivel del enemigo. Nombre en inglés del enemigo, este dato es EngName Texto mostrado al jugador. Nombre en español del enemigo, este dato es EspName Texto mostrado al jugador. CurreptHP Integer Puntos de vida actuales del enemigo. MaxHP Integer Puntos de vida totales del enemigo. Strength Integer Dato de fuerza del enemigo. Defense Integer Dato de defensa del enemigo.

Experiencia que da el enemigo al ser vencido en Experience Integer combate. Determina si el enemigo entrega un ítem al ser HoldsItem Booleano vencido en combate. ItemID Texto Item que da el jugador si es vencido en combate. Money Float Dinero que otorga el enemigo al ser vencido. Tabla 44: Variables dentro de Enemy_Struct en Quito Quest (Ronquillo, 2019)

 QuestObjectiveEnemy_Struct: Guarda los datos que determina que enemigos encontrara el jugador dentro de combate según qué objetivos haya completado. Variable Tipo Descripción QuestName Texto Identificador de la misión ObjectiveID Integer Identificador del objetivo cumplido. Nivel mínimo de enemigo a aparecer en EnemyLevelLow Texto combate. Nivel máximo de enemigo a aparecer en EnemyLevelMax Texto combate. Tabla 45: Variables dentro de QuestObjectiveEnemy_Struct en Quito Quest (Ronquillo, 2019)

 Levels_Struct: Define los atributos de los niveles de los personajes del party, cuantos puntos experiencia son necesarios para llegar a cada nivel y como se mejoran los atributos del personaje al llegar. Variable Tipo Descripción Name Texto Nombre del personaje que controla el jugador. Experiencia mínima necesaria para subir a Experience Integer nivel. Level Integer Nivel al que se desea subir. Valor por el cual los puntos de vida totales del HPIncrease Integer personaje subirán si este sube de nivel. Valor por el cual los puntos de fuerza del StrengthIncrase Integer personaje subirán si este sube de nivel. Valor por el cual los puntos de defensa del DefenseIncrease Integer personaje subirán si este sube de nivel. Tabla 46: Variables dentro de Levels_Struct dentro de Quito Quest (Ronquillo, 2019)

 MontonPuntos_Struct: Define los puntos que se le añada a un equipo dentro del combate según las cartas en su montón. Variable Tipo Descripción CartasEnMonton Integer Numero de cartas en montón. Puntos por añadir según el número de cartas en Puntos Integer montón. Tabla 47: Variables dentro de MontonPuntos_Struct en Quito Quest (Ronquillo, 2019)

3.2.3 Tablas de datos Se utilizaron tablas de datos dentro del juego para almacenar una gran cantidad de datos que puedan ser llamados por distintos actores en distintas situaciones, esta sección describe que uso recibe cada tabla dentro de Quito Quest:

 Item_List: Lista de Items_Struct, guarda los datos de todos los ítems que el jugador puede obtener dentro del juego, en cualquier instancia donde se muestren los datos de un ítem al jugador (nombre, imagen, tipo, entre otros) esos datos son llamados desde esta tabla.  Time_List: Lista de Time_Struct, guarda los datos de todos los “tiempos” dentro del juego, cada fecha, cada hora y cada configuración de luz para cada uno.  QuestTime_List: Lista de QuestTime_Struct, tabla auxiliar usada para enlazar un objetivo con un Time_Struct. Cuando el juego revisa si debe de actualizar la configuración de luces al cumplirse un objetivo, se revisa esta tabla.  NPCTime_List: Lista de NPCTime_Struct, tabla auxiliar usada para enlazar a los personajes con interactividad con un Time_Struct, cuando el juego revisa si debe actualizar el estado de estos actores, se revisará esta lista.  Widgets_List: Lista de Widgets_Struct, guarda todos los valores de texto permanente de todos los Widgets dentro del juego, cuando uno es dibujada en pantalla, se llama esta tabla para revisar los valores de texto cada elemento del Widget.  Cards_List: Lista de Cards_Struct, guarda los valores de todas las cartas usadas en el combate.  Character_List: Lista de Character_Struct, guarda los datos de todos los personajes, cuando el juego muestra el nombre o imagen de un personaje al jugador se llama a esta lista.  SimpleDialogue_List: Lista de SimpleDialogue_Struct, tabla guarda los diálogos simples dentro del juego, cuando un nivel inicia cada actor que utiliza esta estructura llama a esta lista y revisa el último objetivo cumplido por el jugador para asignar el dialogo al personaje.  Dialogue_List: Lista de Dialogue_Struct, guarda todas las conversaciones, cuando un nivel inicia, todos los actores con los que se pueden conversar llaman a esta lista y cargan las conversaciones donde se incluyen.  ConversationObjective_List: Lista de ConversationObjective_Struct, esta tabla auxiliar une a la tabla Dialogue_List y a los objetivos tal que la conversación que se reproduce depende del último objetivo que el jugador haya cumplido.  Enemy_List: Guarda los datos de todos los posibles enemigos a encontrar dentro del combate.  QuestObjectiveEnemy_List: Controla el nivel de los enemigos que podrán aparecer en combate según el último objetivo completado. El nivel de los enemigos sube según el jugador cumpla objetivos, independientemente de cómo suban de nivel los personajes del party actual.  Levels_List: Guarda los datos que definen el nivel de cada miembro el party según sus puntos de experiencia totales, así como el valor en el que suben sus atributos al subir de nivel.  MontonPuntos_List: Guarda la cantidad de puntos que se le da a un equipo dentro del combate según el número de cartas en su montón al terminar una mano.

3.2.4 Widgets Esta sección describe la función que cumple cada Widget, es decir, para que es utilizada cada interfaz gráfica y cómo funcionan.

Unreal Engine 4 permite insertar Widgets creados dentro de otros, de tal forma que, si es necesaria repetir una interfaz gráfica relativamente compleja dentro del juego varias veces, esta se la puede crear una sola vez y ser insertada tantas veces sea necesario. Cada Widget dentro de Unreal Engine 4 también es un blueprint. Dentro de este proyecto, aun con una gran variedad de diseños, el comportamiento se ve repetido a través del juego. Por el alto número de Widgets, el comportamiento de la mayoría de estos no se detallará, únicamente enfocándose en el comportamiento más general. Se dividió a los Widgets en tres grupos: el primer tipo fue denominado Widgets básicos, Widgets que se agregaran a otros, con simple comportamiento, mientras que el segundo grupo es Widgets simples, Widgets independientes con comportamiento de baja y mediana complejidad y el último grupo Widgets complejos, Widgets independientes con complejidad alta.

3.2.4.1 Widgets Básicos 3.2.4.1.1 QuestObjective_Widget Utilizado para mostrar el estado de un objetivo al jugador. Este Widget consta de dos elementos, un checkbox y una caja de texto. En la caja de texto se ubica la descripción del objetivo, mientras que el checkbox muestra si el objetivo se ha cumplido o no.

Ilustración 76: QuestObjective_Widget en Quito Quest (Ronquillo, 2019)

3.2.4.1.2 CharacterHealth_Widget Utilizado para mostrar los puntos de vida actuales de cada miembro del party actual al jugador. Tiene 4 elementos, una imagen, dos cajas de texto y una barra de progreso. La imagen es un retrato del personaje, las cajas de texto muestran el nivel y nombre, y la barra de progreso es una representación visual de sus puntos de vida.

Ilustración 77: CharacterHealth_Widget en Quito Quest (Ronquillo, 2019)

3.2.4.1.3 Comportamiento de Widgets Básicos El único comportamiento de estos elementos es cambiar el tipo de letra de sus elementos de texto según la época en la que se encuentre el jugador.

El blueprint dentro de cada Widget posee también los eventos BeginPlay y Tick, pero, en lugar BeginPlay lleva el nombre de Construir. Ya que una interfaz no necesariamente se dibuja en pantalla cuando inicie un nivel, lo que hace es ejecutar una serie de instrucciones en el momento en el Widget sea dibujado.

CurrentYear_Enum = Ajustar el tipo de letra de 1989 elementos a 1989_Font

Llamar a Ajustar tipo de letra de Evento Construir CurrentYear_Enum de CurrentYear_Enum=1999 elementos a 1999_Font Personaje_BP

Dejar la letra al valor por CurrentYear_Enum=2019 defecto (Roboto)

Ilustración 78: Esquema del comportamiento de Widgets Básicos en Quito Quest (Ronquillo, 2019)

3.2.4.1.4 Menús por año Dentro de los Widget simples existen tres que tienen funcionalidad prácticamente idéntica pero una apariencia distinta, denominados menús por año. Cada uno utilizado en una época en particular.

Ilustración 79: Menús por año, 1989_Widget, 1999_Widget y 2019_Widget, en Quito Quest (Ronquillo, 2019)

3.2.4.1.4.1 Elementos  Hora actual: Una caja de texto que muestra la hora actual al jugador según el último objetivo completado. Este elemento no está presente en 1989_Widget.  Fecha actual: Otra caja de texto, muestra la fecha actual al jugador según el último objetivo completado.  Caja de opciones: De mismo funcionamiento, pero distinta apariencia en cada menú: en 1989_Widget es una lista vertical, en 1999_Widget es una caja de desplazamiento

permitiendo que solo 3 opciones sean visibles a la vez, con las demás opciones siendo visibles según el jugador navegue por el menú, y en 2019_Widget es una cuadricula de 3x2 con icono identificado a cada opción. Según la selección del jugador un menú distinto se abre, como funciona cada uno de estos se explicará en la sección de Widgets simples.

3.2.4.1.4.2 Comportamiento de menús por año A pesar de su distinta apariencia cada menú por año tiene la misma funcionalidad. El único propósito de estos menús es mostrar al jugador una representación de otros Widgets que puede acceder. Estos menús no abren a los otros menús por sí mismos, solo muestran al jugador que puede seleccionar, y en caso de realizar una selección otro Widget es dibujado en pantalla. El comportamiento es más complejo que el de los Widgets mencionados anteriormente, pero aun así es muy simple.

Crear la matriz Botones con los 6 Evento Construir Función ChangeStatus elementos de la caja de opciones.

Ilustración 80: Esquema de las instrucciones del Evento Construir dentro de un menú por año en Quito Quest (Ronquillo, 2019) Cuando se cargue el Widget se crea un array o matriz con los elementos que forman la caja de opciones, que son estos elementos varia de Widget a Widget, en 1989 y 1999 es una simple caja de texto, pero en 2019 es un borde que incluye una imagen y una caja de texto, estos elementos se guardan en una variable llamada Botones. Posteriormente se ejecuta la función ChangeStatus.

Obtener el elemento Función ChangeStatus Cambiar la apariencia de "CurrentElement" del array ese elemento "Botones"

Llamar a Personaje_BP y For Loop: Obtener todos los asignar la variable elementos distintos a Cambiar la apariencia de "CurrentMenuElement" "CurrentElement" del array esos elementos con el valor de la variable "Botones" "CurrentElement"

Ilustración 81: Esquema de la Función ChangeStatus en los menús por año en Quito Quest (Ronquillo, 2019) Como su nombre lo indica la función ChangeStatus modifica el estatus de un elemento del array Botones, más puntualmente altera su apariencia según el valor de una variable numérica llamada CurrentElement que tiene un valor inicial de 0 y puede tener valores de entre 0 y 5. Según el valor de esta variable un elemento dentro de Botones cambiara de apariencia de tal

84 forma que aparente estar activo mientras que todos los demás cambiaran para parecer estar desactivados.

Revisar el valor de Función NextButton Si “CurrentElement” “CurrentElement” es igual a 5

Si “CurrentElement” CurrentElement = 0 está entre 0 y 4

CurrentElement = Función CurrentElement + 1 ChangeStatus

Ilustración 82: Esquema de la función NextButton dentro de los menús por año en Quito Quest (Ronquillo, 2019) NextButton aumenta el valor de la variable CurrentElement y ejecuta a la función ChangeStatus, permitiendo al jugador acceder al siguiente elemento del Widget, es decir, el elemento a la derecha o debajo del elemento actual. Hace una revisión de tal forma que, si CurrentElement ha llegado a su valor máximo, este es reseteado.

Función Revisar el valor de Si “CurrentElement” PreviousButton “CurrentElement” es igual a 0

Si “CurrentElement” CurrentElement = 5 está entre 1 y 5

CurrentElement = Función CurrentElement - 1 ChangeStatus

Ilustración 83: Esquema de la función PreviousButton en los menús por año en Quito Quest (Ronquillo, 2019) Lo opuesto a la función NextButton disminuye el valor de la variable CurrentElement menús permitiendo al jugador navegar dentro de los menús, de tal forma que el jugador pueda acceder al anterior elemento, el que se encuentra a la izquierda o encima del elemento actual. Estas tres funciones tienen su origen en los menús por elemento, pero están presente en todos los menús donde el jugador pueda navegar. Puede que otros Widgets utilicen nombres distintos para sus variables y CurrentElement tener rangos distintos, sin embargo, la lógica de

85 su comportamiento es prácticamente la misma. Que menús utilizan funciones similares es explicado con más detalle más adelante. 3.2.4.1.5 QuestLog_Widget

Ilustración 84: QuestLog_Widget en Quito Quest (Ronquillo, 2019) Este Widget contiene los datos de la misión que el jugador este realizando actualmente, no tiene comportamiento, únicamente da información al jugador, consta de los siguientes elementos: 1. Pantalla: Los elementos dentro de este cuadro son los que ver el jugador, solo lo que esté dentro de esta área es dibujado en la pantalla. 2. Blackground blur: Este Widget tiene un elemento poco común, un panel de difuminación, tiene baja opacidad, siendo casi transparente, permitiendo al jugador ver el mundo cuando este activo, solo que, en un estado borroso, de tal forma que la atención del jugador este en los elementos de este Widget. 3. Panel de misión: Una caja vertical, tiene dos elementos por defecto, el nombre y descripción de la misión actual, además de espacio para apilar todos sus objetivos, que serán representados por medio de una serie de QuestObjective_Widget.

3.2.4.2 Widgets Simples 3.2.4.2.1 MainMenu_Widget

Ilustración 85: MainMenu_Widget en Quito Quest (Ronquillo, 2019)

Este es el menú principal que el jugador ver al iniciar el juego, consta con las opciones más básicas al momento que el juego inicia. Detallando más claramente los elementos de este Widget. 1. Pantalla: Los elementos dentro de este cuadro son los que ve el jugador, solo lo que esté en esta área es dibujado en la pantalla. 2. Logo del juego: Logotipo del juego, aparece en la pantalla por medio de una animación poco después de que cargue el Widget. 3. Presione iniciar: Texto permanente, cuando cargue el logo del juego este ítem aparece y se desvanece por una animación repetitiva, indicando al jugador que hacer para iniciar el juego. 4. Borde de fondo: Un borde al fondo del Widget, detrás de los demás elementos, cuando cargue el Widget ese elemento se desvanece mostrando una escena dentro del juego. 5. Menú principal: El menú del Widget, se activa cuando el jugador siga la instrucción de presionar inicio entrando a la pantalla por una animación. Este menú tiene el mismo fin y comportamiento que los menús por año, es un menú que abre otros menús.

3.2.4.2.1.1 Comportamiento de MainMenu_Widget

Aparecer logo de juego Desvanecer borde de Evento Constuir fondo.

Aparecer presione iniciar

Desvanecer presione iniciar

Ilustración 86: Esquema de Evento Construir del MainMenu_Widget en Quito Quest (Ronquillo, 2019) El evento construir ejecuta una serie de animaciones, el fondo se desvanece y a continuación aparece el logo del juego junto al texto de presione iniciar que aparece y se desvanece en un bucle. Cuando se inicie el juego, el menú del juego se activa, el comportamiento de este menú es idéntico al de los menús por años, incluyendo versiones idénticas de las funciones NextButton, PreviousButton y ChangeState. Tres de las 5 opciones de este menú abre otros menús, sin embargo, las opciones Nuevo Partida y Salir del Juego no lo hacen, como sus nombres lo indican, Nueva Partida empezara el juego desde su inicio, y Salir del Juego simplemente lo cierra, que hacen los otros menús se explica más adelante.

Si el jugador desea abrir otro menú, el elemento menú principal sale de pantalla de la misma manera que entra.

3.2.4.2.2 LoadGame_Widget

Ilustración 87: LoadGame_Widget en Quito Quest (Ronquillo, 2019) Dentro de este Widget el jugador puede cargar un juego previamente grabado y seguir jugando. Únicamente podrá hacerlo dentro hacerlo aquí, su comportamiento es como antes descrito, utiliza las funciones NextButton y PreviousButton para navegación, carga un juego según el SaveSlot seleccionado. 1. Pantalla: Los elementos dentro de este cuadro son los que ve el jugador, solo lo que esté en esta área es dibujado en la pantalla. 2. Slots: Definen que juego será cargado según cual sea seleccionado, Quito Quest utiliza únicamente 3 slots para guardar datos.

3.2.4.2.3 Options_Widget

Ilustración 88: Options_Widget en Quito Quest (Ronquillo, 2019) Este Widget consta con los elementos de configuración gráfica, es la única parte del juego donde se puede modificar la configuración, así como el idioma en el que se mostrarán los elementos del juego, detallando los elementos más claramente. 3. Pantalla: Los elementos dentro de este cuadro son los que ve el jugador, solo lo que esté en esta área es dibujado en la pantalla.

4. Caja de opciones: Objeto que contiene a todos los demás elementos del Widget, cuando este Widget es dibujado en pantalla este objeto entra a la pantalla por medio de una animación, solo cubre la mitad de la pantalla de tal forma que parte del mundo del juego siempre esta visible al jugador, para que pueda ver en tiempo real cambios en la configuración gráfica. 5. Caja de elementos: Una caja que contiene a elementos de texto que muestran al jugador que puede modificar dentro de este menú.  DisplayMode: La configuración de la ventana del juego, si es en pantalla completa o con bordes.  Resolution: La resolución a la que corre el juego.  Graphical Quality: Calidad gráfica del juego.  Postprocessing: Elementos de post procesamiento del juego.  Anti-aliasing: Componente de anti-aliasing del juego.  Shadow quality: Calidad de sombras dentro del juego.  Framerate: Cuadros por segundo al que corre el juego.  Language: Idioma del juego.  Controls: Controles del juego. 6. Caja de modificación: Elementos que el jugador puede modificar, dependiendo de en cual se encuentre pueden cambiar la configuración de la siguiente manera:  Display Mode: Pantalla completa o pantalla con bordes:  Resolution: El juego soporta 8 resoluciones, todas en formato widescreen (16:9), desde 1024x576 hasta 3840x2160.  Graphical Quality, Postprocessing, Anti-aliasing y Shadow Quality: Todas poseen las mismas opciones de configuración, LOW, MEDIUM, HIGH y ULTRA, cambiando la configuración de cada elemento desde la más baja hasta la más alta calidad.  Framerate: El juego soporta 4 posibles configuraciones de cuadros por segundo, 15fps, 30fps, 60fps y 144fps.  Language: Inglés y español  Controls: No es una opción de configuración, solo se le indica al jugador que botón hace que acción dentro del juego. El juego soporta dos tipos de controles, teclado y gamepad.

3.2.4.2.3.1 Comportamiento de Options_Widget Options_Widget también reúsa las funciones ChangeStatus, PreviousButton y NextButton para su navegación básica, estos métodos permiten moverse verticalmente por la caja de opciones para que el jugador vea que está modificando. También contiene dos métodos únicos para configurar cada opción detallada anteriormente.

Si Cambiar juego a CurrentElement = 0 pantalla completa

Si CurrentElement Aumentar resolución = 1

Si CurrentElement Aumentar calidad = 2 grafica

Si CurrentElement Aumentar calidad de = 3 postprocesamiento

Si CurrentElement Mejorar componente = 4 de anti-aliasing Verifica el valor de Función NextElement “CurrentElement”

Si CurrentElement Aumentar calidad de = 5 sombras

Si CurrentElement Aumentar cuadros = 6 por segundo máximos

Si CurrentElement Cambiar idioma a = 7 ingles

Si CurrentElement Mostrar colores para = 8 gamepad

Ilustración 89: Esquema de la función NextElement dentro de Options_Widget en Quito Quest (Ronquillo, 2019) Está función incrementa la calidad del elemento seleccionado, cuando el jugador cambia el valor de algún elemento se aplica el cambio de manera automática, de tal forma que es capaz de ver en tiempo real la configuración que se está realizando. También existe una función opuesta a NextElement, llamada PreviousElement, su comportamiento es idéntico a la otra función, solo que, en lugar de mejorar la calidad gráfica, este la empeora.

3.2.4.2.4 Credits_Widget

Ilustración 90: Credits_Widget en Quito Quest (Ronquillo, 2019) Contiene los créditos del juego. No tiene comportamiento, al abrirlo el jugador únicamente puede ver el equipo de desarrollo del juego, detallando los elementos más claramente. 1. Pantalla: Los elementos dentro de este cuadro son los que ve el jugador, solo lo que esté en esta área es dibujado en la pantalla. 2. Créditos: Parte principal del Widget, similar a los Widgets anteriores, cuando el Widget sea dibujado este objeto entrara a la pantalla por medio de una animación. Está conformado por cajas de texto mostrando el rol y el nombre del equipo de desarrollo de juego.

3.2.4.2.5 Main_Widget

Ilustración 91: Main_Widget en Quito Quest (Ronquillo, 2019) Presente en todo momento y en todos los niveles, a excepción del nivel que guarda el menú principal. También es el Widget con más elementos y más funciones cumple, se detalla como: 1. Pantalla: Los elementos dentro de este cuadro son los que ve el jugador, solo lo que esté en esta área es dibujado en la pantalla. 2. Menú y datos de party: Una caja vertical que muestra los datos del party actual al jugador, por medio de dos CharacterHealth_Widgets y uno de los tres menús por año, según la época actual en la que se encuentre el jugador.

3. Panel de quests: Un panel que alberga un QuestLog_Widget, podría albergar todos los elementos presentes en ese Widget, se dividieron sus funciones para simplificar su funcionamiento. 4. Filtro: Ya que este Widget siempre está presente este guarda un filtro que se utilizara para recrear la reproducción de una cinta de VHS o una fotografía, dependiendo de en qué año este el jugador. 5. Panel de nueva misión: Cuando se le es dada una nueva misión al jugador este panel entra y sale de pantalla por medio de una animación. Utilizado para darle más información al jugador. 6. Panel de objetivos completados: Una vez que el jugador haya cumplido una misión este panel entra y sale de pantalla por medio de una animación para transmitir al jugador esa información. 7. Panel de objetivo completado: Cuando el jugador haya cumplido un objetivo no opcional de una misión este panel entra y sale de pantalla por medio de una animación, para transmitir al jugador esa información. 8. Panel de nuevo ítem: Cuando el jugador adquiera un nuevo ítem este panel entra y sale de pantalla por medio de una animación para transmitir al jugador esa información, este panel es dinámico y muestra al jugador el nombre y la imagen correspondiente del ítem obtenido. No tiene comportamiento y no hace nada por sí mismo, solo guarda una serie de animaciones para sus distintos elementos, a ser reproducidas según las acciones del jugador dentro del juego.

3.2.4.2.6 Pause_Widget

Ilustración 92: Pause_Widget en Quito Quest (Ronquillo, 2019) Es dibujado en pantalla cuando el jugador pausa el juego, al suceder esto el jugador no puede tomar otra acción más que volver a resumir el juego, no puede abrir otros Widgets ni moverse dentro del mundo. Consta con los siguientes elementos: 1. Pantalla: Los elementos dentro de este cuadro son los que ve el jugador, solo lo que esté en esta área es dibujado en la pantalla.

2. Texto indicador: Texto permanente del Widget que dice “En Pausa” o “Paused” dependiendo del idioma del juego. Se reproduce en un bucle por medio de una animación de fundido y desaparición. 3. Background blur: Cumple la misma función que el elemento en QuestLog_Widget.

3.2.4.2.7 Transition_Widget Solo consta de un elemento, un panel con un color que ocupa toda la pantalla. Utilizado para ocultar los cambios en la configuración de luces del juego, cuando es dibujado en pantalla reproduce una animación de fundido y desaparición. Al momento en que la pantalla esté completamente negra el mundo de juego es actualizado, alterando la configuración de luces, así como la posición de los actores dentro del mundo, una vez que la animación haya terminado este es eliminado de la pantalla.

3.2.4.2.8 LoadingScreen_Widget

Ilustración 93: LoadingScreen_Widget en Quito Quest (Ronquillo, 2019) Utilizado cuando el jugador pasa de un nivel a otro, mientras el juego carga el siguiente nivel este Widget es dibujado en pantalla para indicando se está cargando, consta de una simple animación que se reproduce en un bucle mientras tanto. El momento que el nuevo nivel ha sido cargado es borrado de la pantalla.

3.2.4.2.9 Dialogue_Widget

Ilustración 94: Dialogue_Widget en Quito Quest (Ronquillo, 2019)

Está activo mientras el jugador este dentro de una conversación, no posee comportamiento, simplemente muestra al jugador información enviada por actores dentro del juego. Contiene a los siguientes elementos: 1. Pantalla: Los elementos dentro de este cuadro son los que ve el jugador, solo lo que esté en esta área es dibujado en la pantalla. 2. Texto conversación: La línea actual de la conversación será visible dentro de esta casilla. 3. Nombre miembro party: Cuando un miembro del party esté hablando su nombre es visible en esta casilla, si ningún miembro del party está hablando la casilla aparece vacía. 4. Nombre otro personaje: Cuando un personaje que no sea miembro del party esté hablando su nombre aparece en esta casilla, si algún miembro del party está hablando esta casilla aparece vacía. 5. Ilustración miembro del party: Cuando un miembro del party esté hablando una ilustración de ese personaje es visible en este recuadro, si un personaje que no sea integrante del party esté hablando esta casilla contiene una ilustración del último miembro del party en hablar detrás de un panel negro poco opaco. 6. Ilustración otro personaje: Cuando un personaje que no sea miembro del party esté hablando, una ilustración de ese personaje es visible en este recuadro, si este personaje no está hablando su ilustración es visible detrás de un panel negro poco opaco.

3.2.4.2.10 Missions_Widget

Ilustración 95: Missions_Widget en Quito Quest (Ronquillo, 2019) Es dibujado en pantalla cuando el jugador seleccione la opción de misiones dentro de un menú por año. Su propósito es mostrar un listado de todas las misiones que el party actual haya completado, útil para que el jugador sepa que fue lo último que realizo y puede servir como pista para su siguiente acción. Sus componentes son: 1. Pantalla: Los elementos dentro de este cuadro son los que ve el jugador, solo lo que esté en esta área es dibujado en la pantalla. 2. Listado de misiones: Una caja vertical que muestra un listado de las misiones que el party actual ha completado, esta sección únicamente muestra el nombre de todas las misiones.

3. Detalle de misión: Otra caja vertical que muestra detalles de la misión seleccionada, consta de dos elementos: una caja de texto con la descripción, y otra caja vertical donde se apilan los objetivos de dicha misión, utilizando QuestObjective_Widget. El comportamiento es muy simple, utiliza las funciones NextButton, PreviousButton y ChangeStatus, son utilizadas para la navegación por el listado de misiones, mientras que los datos de detalle de misión, depende del valor de CurrentElement.

3.2.4.2.11 Items_Widget

Ilustración 96: Items_Widget en Quito Quest (Ronquillo, 2019) Muestra un listado de los ítems que tiene el party actual, además de la opción de utilizar los ítems consumibles. Consta de los siguientes elementos: 1. Pantalla: Los elementos dentro de este cuadro son los que ve el jugador, solo lo que esté en esta área es dibujado en la pantalla. 2. Listado de ítems importantes: Caja de desplazamiento donde los ítems importantes del party están listados. 3. Listado de ítems consumibles: Caja de desplazamiento donde los ítems consumibles están listados, se divide a los dos tipos de ítems en casillas para su más sencillo acceso. 4. Detalle de ítems: Una caja vertical que muestra los detalles del ítem seleccionado, similar al Detalle de misiones, muestra el nombre del ítem, su imagen respectiva y una descripción. 5. Caja de selección: Cuando el jugador trate de utilizar un ítem consumible esta caja es visible, aquí podrá seleccionar sobre que miembro del party usar el ítem. También consta con los atributos del personaje al que se aplicara el ítem y como se altera ese atributo. El comportamiento de este Widget también es sencillo, utilizando el mismo comportamiento visto en Misiones_Widget, utilizando las funciones NextButton, PreviousButton y ChangeState para navegación dentro del menú, así como la caja de selección.

3.2.4.2.12 Status_Widget

Ilustración 97: Status_Widget en Quito Quest (Ronquillo, 2019) Ese Widget muestra los atributos del party, así como de cada miembro de este, al jugador. Widget extremadamente simple sin ningún comportamiento, solo es para dar información al jugador.

3.2.4.2.13 SaveGame_Widget

Ilustración 98: SaveGame_Widget en Quito Quest (Ronquillo, 2019) Widget con apariencia similar a LoadGame_Widget. Está encargado de guardar los datos actuales del jugador a disco, cuando dibujado en pantalla el jugador puede seleccionar un Save Slot en donde guardar su progreso, según donde haya guardado, después puede cargar esos datos. Quito Quest admite sobreescritura de datos, de tal forma que el jugador puede grabar su juego cuantas veces crea necesario, además puede ser llamado en cualquier ocasión fuera del combate, de tal forma que también se puede grabar cuando y donde le parezca.

3.2.4.2.14 Exit_Widget

Ilustración 99: Exit_Widget en Quito Quest (Ronquillo, 2019) Permite al jugador regresar al menú principal desde cualquier nivel. Cuando este Widget sea dibujado en pantalla el jugador puede elegir entre regresar al menú principal, o cerrar el Widget y seguir dentro del nivel actual.

3.2.4.2.15 NextLevel_Widget

Ilustración 100: NextLevel_Widget en Quito Quest (Ronquillo, 2019) Es dibujado en pantalla cuando el jugador interactúe con un objeto que pueda cargar otro nivel. Similar al Exit_Widget, presenta dos opciones al jugador, la de cargar el siguiente nivel o continuar en el nivel actual, si el jugador elige cargar otro nivel, el juego dibuja Loading_Widget en pantalla y carga el siguiente nivel, caso contrario este Widget es eliminado de pantalla y continua el juego.

3.2.4.3 Widgets Complejos 3.2.4.3.1 Store_Widget

Ilustración 101: Store_Widget en Quito Quest (Ronquillo, 2019) Es la representación visual del sistema de tiendas, se dibuja en pantalla cuando el jugador interactué con un actor de tienda dentro. Es donde el jugador podrá comprar y vender ítems consumibles. Consta de los siguientes elementos: 1. Pantalla: Los elementos dentro de este cuadro son los que ve el jugador, solo lo que esté en esta área es dibujado en la pantalla. 2. Menú de tienda: Una caja vertical que contiene a varios elementos: una caja de texto con diálogos del vendedor, una imagen del vendedor, un menú con las opciones a realizar dentro de la tienda: comprar, vender y salir, y el dinero total del party actual. 3. Listado de ítems: Una caja de desplazamiento que tiene un listado de ítems según la opción que el jugador escoja dentro del menú de tienda, si quiere comprar, está un listado de los ítems que posee la tienda, y si escoge vender un listado de los ítems consumibles que posee el party actual. Se pueden vender únicamente ítems consumibles 4. Detalle de ítem: Elemento idéntico al Detalle de ítem encontrado en Items_Widget, adicionalmente incluye el precio de compra y venta del ítem seleccionado.

3.2.4.3.1.1 Comportamiento También utiliza las funciones NextButton, PreviousButton y ChangeStatus. Es utilizado para navegar dentro del menú de tienda y dentro del listado de Widgets. El comportamiento único de este Widget viene en las acciones de comprar y vender ítems, para esto, utiliza la función CompraVenta, que es una de las funciones más extensas y complejas presentes en el juego. Para simplificar el esquema de esta función, y poder explicar su funcionamiento más claramente, se lo explica en dos casos, caso compra y caso venta.

El party posee Agregar ítem dinero suficiente seleccionado a ítems del party

Revisar si el party Restar dinero total del Función actual tiene dinero party con el valor de CompraVenta suficiente para la compra del item compra

Llamar a El party no posee Main_Widget dinero suficiente

Animar panel de Cancelar venta nuevo ítem en Main_Widget

Ilustración 102: Esquema de la función CompraVenta, caso: compra, utilizado en Store_Widget en Quito Quest (Ronquillo, 2019) Cuando el jugador trate de comprar un ítem, lo primero que hace el juego es revisar si puede comprarlo o no, es decir, revisar si tiene el dinero suficiente, de no ser el caso se cancela la venta y no sucede nada, caso contrario, el ítem comprado es agregado al party actual, el dinero total es actualizado, restando el valor del ítem comprado, y se llama a Main_Widget para que reproduzca la animación de un nuevo ítem. Cada tienda solo carga a ciertos ítems, pero están de manera ilimitada, es decir el jugador podrá comprar el mismo ítem de una tienda mientras pueda pagarlo.

Sumar el previo de Función Eliminar ítem venta del ítem al seleccionado de los CompraVenta dinero total del ítems del party party

Ilustración 103: Esquema de la función CompraVenta, caso: venta, utilizado en Store_Widget en Quito Quest (Ronquillo, 2019) Este proceso es más sencillo, cuando el jugador vende un ítem consumible este es eliminado de sus ítems y se le da dinero por la venta, cualquier tipo de ítem consumible puede ser vendido en cualquier tienda, aun cuando, la tienda no venda el ítem que el jugador le quiere vender. De misma forma cuando el jugador vende un ítem a una tienda este ítem no es agregado a los ítems que puede vender la tienda, solo eliminado del listado de ítems que posee el party actual.

3.2.4.3.2 Combat_Widget

Ilustración 104: Combat_Widget en Quito Quest (Ronquillo, 2019) Este es el Widget con más elementos y más complejo del juego. Es donde el jugador entra en combate con enemigos por medio del juego de “Cuarenta”. Sus elementos incluyen: 1. Pantalla: Los elementos dentro de este cuadro son los que ve el jugador, solo lo que esté en esta área es dibujado en la pantalla. 2. Mesa: La mesa del juego, dibuja una imagen de fondo donde se ponen las cartas, este elemento rota según el turno de cada personaje que controle el jugador, de tal forma, que el jugador vea desde la perspectiva de ese personaje. 3. Cartas en mesa: Una cuadricula, alberga a todas las cartas que estén en la mesa en cualquier momento, es hijo del elemento mesa. 4. Turno: Caja de texto, indica el nombre del jugador con el turno actual. 5. Puntuación: Alberga los datos del combate, el número de puntos y cartas en montón en cualquier momento. 6. Menú de control: Alberga los datos que el jugador puede controlar dentro de su turno, incluyendo a menús a navegar, datos del party y la mano del personaje que este controlando. 7. Datos de party: Un par de CharacterHealth_Widgets, muestran los puntos de vida de los miembros del party en todo momento, este elemento es hijo del elemento menú de control. 8. Menús: En su turno el jugador puede seleccionar una carta a lanzar, usar un ítem, y tratar de escapar. Si desea lanzar una carta, debe de elegirla y si quiere usar un ítem sobre que miembro del party usarlo, este elemento es hijo del elemento menú de control. 9. Mano actual: Muestra las cartas de la mano del personaje que el jugador esté controlando, este elemento es hijo del elemento menú de control. 10. Mano enemigo 1: Representación de las cartas en la mano del enemigo 1, aparecen boca abajo, el jugador no puede ver las cartas del enemigo, es hijo del elemento mesa.

100

11. Mano compañero: Representación de las cartas de la mano del personaje que no esté controlando el jugador, aparecen boca abajo, el jugador únicamente puede ver esas cartas cuando este controlando ese personaje. 12. Mano enemigo 2: Representación de las cartas en la mano del enemigo 2, aparecen boca abajo, el jugador no puede ver las cartas del enemigo, es hijo del elemento mesa.

3.2.4.3.2.1 Widgets auxiliares de combate Según que esté pasando dentro del combate, Combat_Widget dibuja a otros Widgets en pantalla, de tal forma que le sea más claro al jugador saber que está pasando. Necesario por la velocidad a la que pueda ser el combate, además de para hacerlo más satisfactorio, mostrando claramente las acciones del jugador, así como de los enemigos. Estos Widgets pueden ser denominados Widgets simples, ya que únicamente muestran información al jugador con mínimo comportamiento. Sin embargo, ya que son llamados únicamente dentro del combate se los denomino “Widgets auxiliarles de combate”.

Ilustración 105: Card_Widget en Quito Ilustración 106: CardBack_Widget en Quito Quest Quest (Ronquillo, 2019)

Ilustración 107: Caida_Widget en Quito Ilustración 108: LlevaCarta_Widget en Quest (Ronquillo, 2019) Quito Quest (Ronquillo, 2019)

Ilustración 109: Suma_Widget en Quito Ilustración 110: Secuencia_Widget en Quest (Ronquillo, 2019) Quito Quest (Ronquillo, 2019)

101

Ilustración 111: Limpa_Widget en Quito Ilustración 112: ContarMonton_Widget en Quest (Ronquillo, 2019) Quito Quest (Ronquillo, 2019)

Ilustración 114: AddItem_Widget en Quito Ilustración 113: LevelUp_Widget en Quito Quest (Ronquillo, 2019) Quest (Ronquillo, 2019)

Ilustración 115: BattleWon_Widget en Quito Quest (Ronquillo, 2019)

Tabla 48: Widgets auxiliares de combate en Quito Quest (Ronquillo, 2019) 1. Card_Widget: Son utilizados dentro de los elementos mano actual y cartas en mesa de Combat_Widget. No tienen comportamiento únicamente muestra información. 2. CardBack_Widget: Utilizados en los elementos mano compañero, mano enemigo 1 y mano enemigo 2 en Combat_Widget. No tienen comportamiento, muestran la misma imagen. 3. Caida_Widget: Utilizado cuando sucede una caída dentro del combate, muestra las dos cartas que intervienen en la caída. Su comportamiento es recibir a las cartas a mostrar y luego animarlas. 4. LlevaCarta_Widget: Utilizado cuando una es llevada de la mesa, pero no fue una caída. Igual a Caida_Widget su comportamiento es recibir las cartas a mostrar y luego animarlas. 5. Suma_Widget: Utilizado cuando suceda una suma en el combate. Similar a los Widgets anteriores su comportamiento es recibir las 3 cartas a mostrar y animarlas. 6. Secuencia_Widget: Si después de una caída, lleva carta o suma hay una secuencia de cartas se utiliza este Widget. Muestra las cartas en secuencia y las anima. 7. Limpia_Widget: Si al final de cualquier movimiento ya no hay cartas en la mesa, se utiliza este Widget, muestra la palabra “¡Limpia!” sin mostrar cartas.

102

8. ContarMonton_Widget: Luego de que se jueguen 40 cartas se utiliza este Widget para contar las cartas en el monto de cada equipo y asignar los puntos respectivos. 9. LevelUp_Widget: Este Widget muestra los atributos de cada miembro del party actual al terminar el combate, indicando cuantos puntos de experiencia son necesarios para el siguiente nivel, y de aplicar el caso, como mejoran sus atributos al subir de nivel. 10. AddItem_Widget: Este Widget muestra los ítems que se le da al jugador al terminar el combate, de aplicar el caso. 11. BattleWon_Widget: Si el jugador vence en el combate se utilizará este Widget, se utiliza dos LevelUp_Widget para mostrar los datos de cada personaje, así como un AddItem_Widget, de ser necesario.

3.2.4.3.2.2 Comportamiento 3.2.4.3.2.2.1 Eventos

Elegir a Evento Elegir Repartir repartidor BeginPlay enemigos mano inicial inicial

Evento JugarCarta

Ilustración 116: Esquema del evento BeginPlay dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) Al iniciar el combate se escogen a dos enemigos aleatorios según el último objetivo que el jugador haya completado, luego se escoge el repartidor inicial según un grupo de cartas aleatorias y se reparten las cartas. Finalmente se ejecuta el evento JugarCarta para empezar el juego.

Si el turno Revisar Si turnos Evento Función actual es de número total totales es 20 JugarCarta EnemyMove un enemigo de turnos o 40

Si turnos Evento Siguiente totales es RepartirOtra turno cualquier Vez otro valor

Ilustración 117: Esquema del evento JugarCarta dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) Este evento es utilizado para controlar las acciones de los enemigos dentro del combate. Revisa si el turno actual es turno enemigo y de ser el caso ejecuta la función EnemyMove, luego revisa en que turno está el juego, de ser el turno 20 o 40, es decir en el caso de que los

103 participantes no tengan cartas para seguir jugando, ejecuta el evento RepatirOtraVez, caso contrario, ejecuta la función NextTurn.

Si número de Repartir Evento Evento turnos totales cartas RepartirOtraVez JugarCarta es 20 restantes

Si número de Vaciar Función Repartir turnos totales cartas en MontonA nuevamente es 40 mesa Puntos

Ilustración 118: Esquema del evento RepartirOtraVez dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) Este evento es llamado cuando todos los participantes se queden sin cartas para jugar. En caso de que hayan pasado 20 turnos, es decir, aún quedan cartas por repartir, se reparten las cartas restantes y se ejecuta el evento JugarCarta. Si el número de turnos es 40 se quitan todas las cartas que permanezcan en la mesa y se ejecuta la función MontonAPuntos, luego se reparte nuevamente y se ejecuta la función JugarCarta.

Dibujar Evento Si gana el Finalizar BattleWon_Widget EndGame jugador combate en pantalla

Regresar al Si gana el menú enemigo principal

Ilustración 119: Esquema del evento EndGame dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) Este evento es ejecutado cuando cualquiera de los equipos haya ganado en el juego de 40. Si gano el jugador se muestra el BattleWon_Widget y se regresa al mundo de juego. Si fuese a ganar el enemigo se regresa al menú principal y todo el progreso del jugador desde la última vez que haya grabado es eliminado.

104

3.2.4.3.2.2.2 Funciones

Si número de Función Función Evento PlayerMove AddCardToTable turnos totales es RepartirOtraVez 20 o 40

Si turnos totales Evento es cualquier otro JugarCarta valor

Si número de Función Función Evento turnos totales es EnemyMove AddCardToTable RepartirOtraVez 20 o 40

Ilustración 120: Esquema de las funciones PlayerMove & EnemyMove dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) Funciones con comportamiento casi idéntico. EnemyMove es ejecutada por JugarCarta en caso de que sea turno de un enemigo, llama a la función AddCardToTable y luego verifica si debe ejecutar al evento RepartirOtraVez. PlayerMove es llamado cuando el jugador seleccione una carta de su mano, luego sigue las mismas instrucciones de EnemyMove, solo que, al revisar el número de turnos totales, sino debe de ejecutar al evento RepartirOtraVez, llamará al evento JugarCarta.

Función Función Revisar si debe de Debe agregar AddCardToTable Caida añadir carta a mesa carta

Si ya no hay Función No debe de agregar Agregar carta a cartas en mesa Damage carta a mesa mesa

Función Dibujar Limpia_Widget AumentarPuntos en pantalla

Ilustración 121: Esquema de la función AddCardToTable dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) Este evento es ejecutado cuando el jugador o un enemigo juegue una carta. Inicia por ejecutar a la función Caída, luego revisa, según información de la función Caída, si debe o no agregar la carta jugada a la mesa. De hacerlo agrega la carta a la mesa, caso contrario ejecuta la función Damage, revisa si existen cartas en mesa, si ya no hay cartas ejecuta la función AumentarPuntos y dibuja a Limpia_Widget en pantalla.

105

Si la carta jugada es Función Función Dibujar de igual valor a la Caída AumentarPuntos Caida_Widget última carta en mesa en pantalla

Función Aumenta LlevaCarta cartas a montón

Función No agregar Secuencia cartas a mesa

Ilustración 122: Esquema de la función Caída dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) Es ejecutada por la función AddCardToTable, verifica si al jugar una carta hubo una caída, de ser el caso ejecuta la función AumentarPuntos, dibuja a Caida_Widget en pantalla, aumenta las cartas de la caída a montón y verifica si debe ejecutar la función Secuencia. Sino fue una caída ejecuta la función LlevaCarta, luego ejecuta la función Secuencia, si hay secuencia se dibuja a Secuencia_Widget en pantalla y se indica que no se debe agregar la carta jugada en mesa.

Si el valor de la Revisa todas Aumentar Función carta jugada es las cartas en la cartas a LlevaCarta igual a cualquier mesa monton carta en mesa

Función Caso Dibujar Suma contrario LlevaCarta_Widget en pantalla

Función No agregar Secuencia carta a mesa

Ilustración 123: Esquema de la función LlevaCarta dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) Esta función es ejecutada por la función Caída en caso de que no haya caída. Verifica de entre todas las cartas en mesa si la carta jugada es igual a una de ellas, en cuyo caso aumenta las cartas a montón, dibuja a LlevaCarta_Widget en pantalla y ejecuta la función Secuencia, caso contrario ejecuta la función Suma.

106

Función Revisa todas Si la carta jugada es Aumentar Suma las cartas en la la suma de dos cartas a mesa cartas en la mesa monton

Dibujar a Agregar carta Caso Suma_Widget a mesa contrario en pantalla

Función No agregar Secuencia carta a mesa

Ilustración 124: Esquema de la función Suma dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) Este evento es ejecutado por la función LlevaCarta en caso de que no pueda llevarse una carta, es la última comprobación de que al jugar una carta se deben llevar cartas de la mesa. Verifica si la carta jugada es la suma de dos cartas en mesa, en cuyo caso agrega las cartas al montón, dibuja a Suma_Widget en pantalla y ejecuta la función Secuencia, caso contrario agrega la carta jugada a la mesa.

Función Revisa todas Si encuentra Aumentar Secuencia las cartas en la una cartas a mesa secuencia montón

Dibujar Secuencia_Widget en pantalla

Ilustración 125: Esquema de la función Secuencia dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) En caso de que las funciones Caída, LlevaCarta o Suma fuesen exitosas se ejecuta esta función. Revisa todas las cartas en mesa en busca de una secuencia con la carta jugada, si la encuentra agrega todas esas cartas a montón y dibuja a Secuencia_Widget en Pantalla.

Revisa de Aumentar Función AumentarPuntos quien es el puntos jugador turno más 2

Aumentar Si puntos totales Evento jugador o enemigo puntos EndGame enemigos más 2 son 40

Ilustración 126: Esquema de la función AumentarPuntos dentro de Combat_Widget en Quito Quest (Ronquillo, 2019)

107

Esta función es ejecutada por la función AddCardToTable y Caida en caso de caída o limpia, aumenta los puntos del equipo que haya realizado dicha acción por 2. En caso de que los puntos totales juego de ser aumentados sea 40 se ejecuta el evento EndGame.

Función Compara el montón de cada Aumenta los puntos de equipo según los datos de la cada equipo según los MontonAPuntos tabla MontonPuntos_List valores encontrados

Evento Si puntos totales EndGame jugador o enemigo son 40

Ilustración 127: Esquema de la función MontonAPuntos dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) Esta función es ejecutada por el evento RepartirOtraVez si los turnos totales son igual a 40, compara los valores del montón de cada equipo con los valores de la tabla MontonPuntos_List, luego aumenta los puntos de cada equipo según el valor encontrado, y si los puntos totales de cualquier equipo son igual a 40 ejecuta al evento EndGame.

Realizar cálculo de daño según fuerza del atacante y defensa del atacado. 퐷퐸퐹 퐴푇푇 − ቀ퐴푇푇 − ቁ 퐷퐴푀 = 2 Función 2 MeasureDamage Donde:

 DAM: Daño realizado.  ATT: Fuerza del atacante.  DEF: Defensa del atacado.

Ilustración 128: Esquema de la función MeasureDamage dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) Es ejecutada dentro de la función Damage, se encarga de calcular cuánto daño hizo un personaje a otro según los atributos de fuerza del atacante y defensa del atacado. La fórmula utilizada para ese cálculo es la misma vista en el primer Dragon Quest, las operaciones utilizadas permiten que los personajes se hagan un daño mínimo de 1, aun cuando haya una gran diferencia entre ataque y defensa de los personajes.

108

Aplicar daño calculado Revisar que Función Función al personaje a la personaje lanzo Damage MeasureDamage izquierda del personaje la carta que lanzo la carta

Marcar a Evento Si puntos de vida personaje como Endgame de ese personaje derrotado llegaron a cero

Ilustración 129: Esquema de la función Damage dentro de Combat_Widget en Quito Quest (Ronquillo, 2019) Se encarga de aplicar el daño calculado por la función MeasureDamage al personaje que cuenta como atacado, dicho personaje siempre será el que este a la izquierda del personaje que jugo una carta. Si después de ser atacado los puntos de vida actuales de llegaron a cero, ese equipo es denominado como derrotado y se ejecuta el evento Endgame que termina el combate.

3.2.5 Blueprints especiales 3.2.5.1 QuitoQuestInstance Se creó una Game Instance personalizada para uso de todo el juego y se la llamó QuitoQuestInstance, tiene como propósito principal almacenar los datos del jugador y enviarlos de un nivel a otro. Posee únicamente un evento y una función, de tal forma que tiene un mínimo comportamiento. Sus datos son llamados por actores según sea necesario, por ello QuitoQuestInstance consta con los siguientes atributos: Variable Tipo Descripción La misión que el party de 2019 esté 2019ActiveQuest Quest_Struct completando. Lista de todas las misiones en la que ha 2019Quests Array de Quest_Struct participado el party de 2019. La misión que el party de 1999 esté 1999ActiveQuest Quest_Struct completando. Lista de todas las misiones en la que ha 1999Quests Array de Quest_Struct participado el party de 1999. La misión que el party de 1989 esté 1989ActiveQuest Quest_Struct completando. Lista de todas las misiones en la que ha 1989Quests Array de Quest_Struct participado el party de 1989. 2019Party Party_Struct Datos del party de 2019. 1999Party Party_Struct Datos del party de 1999. 1989Party Party_Struct Datos del party de 1989. Listado de ítems que posee el party de 2019Items Array de Item_Struct 2019. Listado de ítems que posee el party de 1999Items Array de Item_Struct 1999.

109

Listado de ítems que posee el party de 1989Items Array de Item_Struct 1989. GameLanguage GameLanguage_Enum Idioma del juego. Tabla 49: Atributos en la blueprint QuitoQuestInstance en Quito Quest (Ronquillo, 2019) Se guardan 3 versiones de todas las variables, de tal forma que el juego en todo momento tiene almacenado datos del party para las tres épocas, además de almacenar el idioma a utilizar el juego.

3.2.5.1.1 Comportamiento QuitoQuestInstance es la única blueprint donde se guarda la selección de idioma del juego, por lo que en todos los casos en los que el juego llame datos de texto, estos antes de enviados a pantalla pasan por un filtro donde, según el valor de la variable GameLanguage en QuitoQuestInstance, se enviará el texto final a ser mostrado en pantalla.

De ser el caso enviar texto en español Revisar valor de Función Filtrar valores segun GameLanguage en SetGameLanguage interfaz/variable QuitoQuestInstance De ser el caso enviar texto en ingles

Ilustración 130: Esquema del uso de idiomas usado en Quito Quest (Ronquillo, 2019) QuitoQuestInstance es el blueprint que carga datos desde disco y luego los envía al blueprint que controla el jugador, según la época en que este el party a cargar, el blueprint almacena datos para todas las épocas. Para la esta tarea la blueprint QuitoQuestInstance utiliza el evento LoadGame, que es ejecutado por el Evento BeginPlay tan pronto inicie el juego.

Asignar los datos cargados Evento LoadGame Leer datos de disco a las variables de QuitoQuestInstance

Ilustración 131: Esquema del evento LoadGame utilizado en QuitoQuestInstance en Quito Quest (Ronquillo, 2019)

3.2.5.2 QuitoQuestGameMode Se creó un modo de juego que es utilizado en todos los niveles a excepción del nivel que alberga el menú principal. El uso del modo de juego es dibujar Main_Widget en pantalla cuando se inicie un nivel y servir como el objeto a ser llamado siempre que se necesite realizar acciones dentro de ese Widget.

110

3.2.5.3 QuitoQuestSaveGame Como su nombre lo indica es el objeto encargado de la permanencia de datos, es decir, guardar una sesión de juego al disco para que el jugador pueda guardar su progreso, cerrar el juego, y poder continuar en otra ocasión. QuitoQuestSaveGame consta de los mismos atributos que tiene QuitoQuestInstance ya que son esos datos los que se deben guardar a disco.

3.2.5.3.1 Comportamiento

Asignar los datos, según la época, a QuitoQuestInstance

Llamar datos Asignar todos los atributos de Evento SaveGame del jugador QuitoQuestInstance a actual QuitoQuestSaveGame

Guardar estos datos a disco.

Ilustración 132: Esquema de la función SaveGame dentro de QuitoQuestSaveGame en Quito Quest (Ronquillo, 2019) Este evento es disparado cuando el jugador elija un slot de juego sobre el cual guardar. Al ser iniciado, llama a los datos actuales del jugador y sobrescribe los datos de QuitoQuestInstance de tal forma que se obtienen los datos más recientes, la sobreescritura de estos datos es la misma que sucede cuando el jugador va de un nivel a otro, como se explicará en detalle más adelante. Con los atributos de QuitoQuestInstance actualizados, QuitoQuestSaveGame utiliza esos atributos para actualizar a sus atributos y guardarlos en disco, cuando QuitoQuestInstance cargue datos desde disco, carga los atributos de QuitoQuestSaveGame.

3.2.6 El jugador Está sección detalla la funcionalidad de los actores que el jugador controla dentro del juego, así como el cómo es que el jugador controla esos actores, es decir, como el juego toma datos de entrada y los procesa. Existen dos tipos de actores controlados por el jugador, un actor que solo es controlado en el menú principal, y el actor que es controlado en todos los demás niveles del juego.

111

3.2.6.1 Entrada del juego Como se explicó anteriormente Unreal Engine 4 permite la asignación de ciertos botones a acciones dentro del mundo de juego, dentro de un blueprint esto permite disparar un evento cuando el jugador interactúe con un dispositivo de entrada de alguna manera. Dentro de Quito Quest el jugador puede realizar las siguientes acciones:  Interactuar con un actor: Cuando el jugador esté cerca de un actor puede interactuar con él, según qué tipo de actor sea se puede iniciar una conversación, activar una tienda, entre otros.  Aceptar comandos dentro de Widgets: Cuando el jugador este dentro de un Widget puede ejecutar una acción dentro de ese Widget, esto incluye utilizar ítems, ir a otros niveles, avanzar una conversación, entre otros.  Abrir y cerrar menú por año: Dentro del juego el jugador puede abrir y cerrar el menú por año según crea conveniente, al abrir este menú, el jugador podrá ejecutar otras acciones, así como revisar la misión actual.  Navegación dentro del mundo y Widgets: El jugador puede moverse dentro del mundo, así como navegar dentro de los elementos de un Widget.  Pausar el juego: El jugador puede poner y quitar pausa al juego. Unreal Engine permite la asignación de ejes, así como de acciones, ambas asignaciones ejecutan eventos cuando se interactúe con el dispositivo de entrada que le sea asignada, las asignaciones de eje permitiendo también el uso de la variable numérica asignada. Nombre asignación Botón asignado Descripción Permite interactuar con En Teclado: actores dentro del mundo, Tecla E Interactuar/Aceptar así como aceptar En Gamepad: comandos dentro de Gamepad_FaceButton_Bottom Widgets. En teclado: Permite abrir y cerrar el Tecla Q menú por año actual, así Objectives/Menu En Gamepad: como revisar los objetivos Gamepad_FaceButton_Top de la misión actual. En teclado: Navegación dentro de Tecla W Widgets, permite moverse MoveUp/Forward En Gamepad: a un elemento que este Gamepad_DPad_Up arriba o a la izquierda del Gamepad_LeftStick_Up elemento seleccionado. En teclado: Navegación dentro de Tecla S Widgets, permite moverse MoveDown/Backward En Gamepad a un elemento que este Gamepad_DPad_Down abajo o a la derecha del Gamepad_LeftStick_Down elemento seleccionado. En teclado: Navegación dentro de Tecla D Widgets, permite moverse MoveRight En Gamepad a un elemento que esté Gamepad_DPad_Right después a otro elemento, es Gamepad_LeftStick_Right decir, hacia abajo o

112

derecha del elemento actual. Navegación dentro de En teclado: Widgets, permite moverse Tecla A a un elemento que esté MoveLeft En Gamepad antes a otro elemento, es Gamepad_DPad_Left decir, hacia arriba o Gamepad_LeftStick_Left izquierda del elemento actual. En teclado: Tecla Enter y Tecla Escape PauseGame Pausa y resume el juego. En Gamepad Gamepad_Special_Right En teclado: Tecla F Cancela acciones dentro de Cancelar/Salir En Gamepad un Widget. Gamepad_FaceButton_Right Tabla 50: Acciones dentro de Quito Quest (Ronquillo, 2019) En una acción, cuando el botón asignado sea presionado se ejecuta un evento, en un eje se ejecuta mientras el botón este presionado, esto permite ejecutar una acción a través del tiempo es por eso por lo que existe esta distinción entre la entrada en Unreal Engine 4, dentro del juego, los ejes asignados son: Nombre eje Valor Botón asignado Descripción En teclado: Tecla D Navegación dentro del 0.4 En Gamepad mundo de juego, cuando el Gamepad_DPad_Right valor es positivo el personaje Gamepad_LeftStick_Right Izq-Der se mueve hacia la derecha de En teclado: la cámara, cuando el valor sea Tecla A negativo se mueve hacia la -0.4 En Gamepad derecha. Gamepad_DPad_Left Gamepad_LeftStick_Left En teclado: Tecla S 0.4 En Gamepad Navegación dentro del Gamepad_DPad_Down mundo de juego, cuando el Atrás- Gamepad_LeftStick_Down valor es positivo el jugador se Alfrente En teclado: mueve hacia la cámara, Tecla W cuando sea negativo se aleja -0.4 En Gamepad: de la cámara. Gamepad_DPad_Up Gamepad_LeftStick_Up Tabla 51: Ejes en Quito Quest (Ronquillo, 2019)

113

3.2.6.2 MainMenu_BP Es el actor que el jugador controla dentro del nivel donde se dibuja MainMenu_Widget en pantalla, no tiene apariencia física y su único componente es una cámara con la que se renderiza la escena. Está encargado de abrir, cerrar y navegar por los menús principales, de carga de juego y opciones. No tiene funciones y sus únicos eventos son los generados por las acciones que realiza. Variable Tipo Descripción Define qué tipo de acción está realizando MenuState MainMenu_Enum el actor. Variable controla las funciones realizadas MainMenuWidget MainMenu_Widget por MainMenu_Widget Variable controla las funciones realizadas LoadWidget LoadGame_Widget por LoadWidget Variable controla las funciones realizadas OpcionesWidget Options_Widget por Options_Widget Variable controla las funciones realizadas CreditsWidget Credits_Widget por Credits_Widget Tabla 52: Variables dentro de MainMenu_BP en Quito Quest (Ronquillo, 2019)

3.2.6.2.1 Comportamiento Como se mencionó anteriormente este Widget no utiliza funciones ni eventos únicos, todo su comportamiento está basado en las acciones según botones y el evento BeginPlay.

Permitir que el Dibujar Evento Cargar acto reciba MainMenu_Widget configuración BeginPlay entrada en pantalla gráfica

Aplicar configuración gráfica

Ilustración 133: Esquema del evento BeginPlay dentro de MainMenu_BP en Quito Quest (Ronquillo, 2019) Tan pronto inicie el juego se activa la entrada del actor, para que cuando el jugador presione botones este actor pueda procesarlas. Luego se dibuja MainMenu_Widget en pantalla, se carga y aplica la configuración gráfica del juego, si el jugador ya ha configurado este aspecto del juego se carga la configuración realizada, caso contrario se cargan los valores por defecto.

MainMenu_Widget InputAction Si inicia el menú PauseGame MenuState=None principal.

Ilustración 134: Esquema del evento PauseGame dentro de MainMenu_BP en Quito Quest (Ronquillo, 2019)

114

Cuando el jugador dispare el evento PauseGame y si ningún menú está activo, se activa el menú principal de MainMenu_Widget, caso contrario el evento no realiza ninguna instrucción.

Si MenuState=None No realizar nada InputAction MoveLeft Ejecutar la función Si PreviousButton en Revisa el valor de MenuState=InLoad LoadGame_Widget MenuState

Ejecutar la función InputAction Si PreviousButton en MoveUp/Forward MenuState=InOptions Options_Widget

Ejecutar la función Si PreviousButton en MenuState=InCredits Credits_Widget

Ejecutar la función Si PreviousButton en MenuState=MainMenuActive MainMenu_Widget

Ilustración 135: Esquema de los eventos MoveLeft & MoveUp/Forward dentro de MainMenu_BP en Quito Quest (Ronquillo, 2019) Los eventos de MoveUp/Forward y MoveLeft activan la misma secuencia de instrucciones. Se revisa el estado de MoveState y según ese se ejecuta la función PreviousButton en el menú que este activo según ese estado.

Si MenuState=None No realizar nada InputAction MoveRight Ejecutar la función Si NextButton en Revisa el valor MenuState=InLoad LoadGame_Widget de MenuState

Ejecutar la función InputAction Si NextButton en MoveDown/Backward MenuState=InOptions Options_Widget

Ejecutar la función Si NextButton en MenuState=InCredits Credits_Widget

Ejecutar la función Si NextButton en MenuState=MainMenuActive MainMenu_Widget

Ilustración 136: Esquema de los eventos MoveRight & MoveDown/Backwards dentro de MainMenu_BP en Quito Quest (Ronquillo, 2019)

115

El opuesto al esquema anterior, los eventos MoveDown/Backwards y MoveRight ejecutan la función NextButton dentro del menú que este activo según el valor de MenuState.

Si Iniciar Juego CurrentElement=0

Revisar el valor de “CurrentElement” Si Dibujar LoadGame_Widget en CurrentElement=1 en pantalla MainMenu_Widget

Si Dibujar Options_Widget CurrentElement=2 InputAction Si MenuState = en pantalla Interactuar/Aceptar MainMenuActive

Si Dibujar Credits_Widget CurrentElement=3 en pantalla

Si Cerrar el juego CurrentElement=4

Ilustración 137: Esquema del evento Interactuar/Aceptar dentro de MainMenu_BP en Quito Quest (Ronquillo, 2019) Cuando el jugador desee interactuar con uno de los elementos del menú principal se pueden ejecutar varias acciones, desde abrir los otros menús, iniciar el juego desde el principio y cerrar el juego. Una versión casi idéntica de este evento es utilizada cuando jugador este dentro de LoadGame_Widget en donde el jugador podrá seleccionar que juego desea cargar.

Revisar el valor de Si Eliminar “CurrentElement” CurrentElement=1 LoadGame_Widget de pantalla en MainMenu_Widget

Si Eliminar CurrentElement=2 Options_Widget de InputAction Si MenuState = pantalla Cancelar/Salir MainMenuActive

Si Eliminar Credits_Widget de CurrentElement=3 pantalla

Ilustración 138: Esquema del evento Cancelar/Salir dentro de MainMenu_BP en Quito Quest (Ronquillo, 2019) Si otro menú además del principal está activo en pantalla ese eliminado y el jugador regresa al menú principal donde puede realizar otra acción. Cuando el jugador cierre el menú de opciones, las opciones que haya modificado son grabadas en disco.

116

3.2.6.3 Personaje_BP Este es el actor que el jugador controla dentro del juego, por ser el actor principal también es el más complejo de todos, teniendo el mayor número de variables, funciones y eventos de todo el juego. Sus componentes incluyen: Nombre Descripción Flipbook que reproduce las animaciones del personaje MainSprites principal. Componente auxiliar que ayuda en la rotación del personaje secundario, cuando el jugador se mueva por el mundo este PivoteSecondCharacter objeto rotará de tal forma que el personaje secundario siempre se vea correctamente. Flipbook que reproduce las animaciones del personaje SecondSprites secundario. Colisionador, contiene datos de colisión al actor de tal forma Box que para que no pueda atravesar objetos. Objeto auxiliar dentro del desarrollo, utilizado para ajustar CamaraPivote más fácilmente la posición y ángulo de la cámara. Componente de cámara, es la que renderiza el juego, es decir, Camara lo que ve esta cámara es lo que ve el jugador. Componente auxiliar, similar a PivoteSecondCharacter, cuando el personaje se mueva por el mundo este objeto rotará MiraPivote de tal forma que el objeto mira siempre esté en la cara del personaje. Colisionador suave, cuando el jugador quiera interactuar con un objeto, el personaje solo lo hará cuando este componente este colisionando con ese objeto, de tal forma que el personaje Mira dentro del juego debe estar mirando a ese objeto. Sirve para que al iniciar una interacción el personaje no le dé la espalda al objeto con el que esta interactuando. Componente creado durante el desarrollo, sirve como apoyo QuestLog en el sistema de misiones, su funcionalidad se detallará más adelante. Tabla 53: Componentes de Personaje_BP en Quito Quest (Ronquillo, 2019) Este actor también posee una gran cantidad de variables, varias de ellas pueden alterar las características de cada nivel y pueden ser llamadas por otros actores, entre ellas se incluyen: Variable Tipo Descripción Variable controla la configuración de luces TimeID Texto y posición de otros actores en el juego. Party Party_Struct Variable guarda los datos del party actual. Variable usada para controlar la WorldLight WorldLight_Struct configuración de luces del nivel. Otra variable utilizada para controlar la CurrentDayTime DayTime_Struct configuración de luces del nivel. Items Array de texto Variable guarda los ítems del party actual. Variable usada para controlar las acciones Status PlayerStatus_Struct del jugador.

117

Variable usada para controlar la época en la CurrentYear CurrentYear_Struct que está el jugador. Variable usada para controlar si el actor InSubMenu Boolean está en un submenú (Widget que puede ser iniciado por un menú por año). Variable controla las funciones realizadas QuestLogWidget QuestLog_Widget por QuestLog_Widget Variable controla las funciones realizadas 1989Widget 1989_Widget por 1989_Widget Variable controla las funciones realizadas 1999Widget 1999_Widget por 1999_Widget Variable controla las funciones realizadas 2019Widget 2019_Widget por 2019_Widget Variable controla las funciones realizadas CurrentSubMenu Widget por los Widgets que pueden ser llamados desde los menús por año. Variable controla las funciones realizadas StoreWidget Store_Widget por Store_Widget Variable controla las funciones realizadas NewLevel NextLevel_Widget por NextLevel_Widget Tabla 54: Variables dentro de Personaje_BP en Quito Quest (Ronquillo, 2019)

3.2.6.3.1 Comportamiento 3.2.6.3.1.1 Eventos

Evento Permitir que el Función Función BeginPlay actor reciba YearMenu StartQuestLog entrada

Función Evento Función Función SetFlipbooks UpdateWorld LoadItems LoadPartyData

Ilustración 139: Esquema del evento BeginPlay dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) Cuando cargue un nivel con este actor este ejecuta una secuencia, una serie de funciones que inicializa sus variables, que hace cada una de estas funciones y eventos se explican más adelante.

118

Si Mover actor en el InputAxis Izq-Der Status=Moving vector adelante según el valor del eje

Si Mover actor en el InputAxis Atrás-Alfrente Status=Moving vector derecho según el valor del eje

Ilustración 140: Esquema de los eventos Izq-Der & Atras-Alfrende dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) Este evento controla el movimiento del personaje dentro del mundo, si el personaje se puede mover entonces se mueve en una dirección según el eje que se ejecute, que tan rápido se mueve depende del valor de ese eje.

Realizar un Si la variable Evento recorrido por TimeID de un UpdateWorldEvent Time_List elemento de la tabla es igual a TimeID

Ejecutar función Ajustar CurrentDayTime Dibujar CheckDayTime en con la variable Transition_Widget todos los actores CurrentDayTime del en pantalla Car_BP elemento de Time_List

Función Función Función UpdateInteractableObjects UpdateNPCs UpdateWorldLight

Ilustración 141: Esquema del evento UpdateWorldEvent dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) Actualiza el mundo del juego, comienza por revisar a la tabla Time_List para saber si debe actualizar el mundo y luego ejecuta una serie de funciones que alteran la ubicación de actores dentro del mismo, así como la configuración de luces del nivel. Este evento es ejecutado desde la función UpdateWorld, que a su vez es llamada por otros actores en ciertas circunstancias, el jugador no tiene control directo de cuando se ejecutan estas instrucciones.

119

InputAction Si Status = Si Mira está en Interactuar/Aceptar Moving o colisión con un actor InConversation con diálogos

Ejecutar Función Interact en el Ajustar Status a actor con el que hay colision. InConversation

Ilustración 142: Esquema del evento Interactuar/Aceptar dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) Si el jugador interactúa con un objeto con el que se pueda interactuar, su estado cambia y se ejecuta una función. La ilustración 140 es un ejemplo de lo que sucede con un personaje que tiene diálogos, pero el evento funciona de forma idéntica cuando se interactúa con un actor de tienda o con un actor que carga otro nivel, su estado cambia a InStore y ChoosingLevel respectivamente y se inicia un evento dentro de ese actor, que realiza cada evento en cada actor será explicado más adelante.

InputAction Si Status = Si InSubMenu Función Interactuar/Aceptar InMenu es verdadero DoSomethingInSubMenu

Revisar valor de InSubMenu

Si InSubMenu Ajustar InSubMenu Función es falso a verdadero OpenSubMenu

Ilustración 143: Esquema del evento Interactuar/Aceptar dentro de menús de Personaje_BP en Quito Quest (Ronquillo, 2019) Dentro de un menú la funcionalidad de este evento cambia, aquí podrá abrir o realizar una acción dentro de un menú según el estado de la variable InSubMenu, el control de que Widget abrir, así como de qué hacer en un Widget son controladas por otras funciones explicadas más adelante.

120

InputAction Revisar valor de Si Ajustar Status a Objectives/Menu Status Status=Moving InMenus

Si Ajustar Status a Agregar QuestLog_Widget Status=InMoving Moving a Main_Widget

Desactivar y borrar todos los Widgets Activar menu menos Main_Widget por año

Ilustración 144: Esquema del evento Objectives/Menu de Personaje_BP dentro de Quito Quest (Ronquillo, 2019) Este evento permite al jugador abrir el menú por año, así como cerrarlo para seguir moviéndose dentro del mundo. De ser activado dentro de un submenú, este se cierra automáticamente.

InputAction MoveDown/Backward

InputAction MoveUp/Forward

Si Ajustar animación Rotar MiraPivote y Status=Moving del personaje PivoteSecondCharacter InputAction principal MoveRight

Ajustar animación personaje secundario InputAction MoveLeft

Ilustración 145: Esquema de los eventos MoveDown/Backward, MoveUp/Forward, MoveRight & MoveLeft para el control de animaciones dentro de Pesonaje_BP en Quito Quest (Ronquillo, 2019) Según qué acción se ejecute, los flipbooks del personaje secundario, principal y el pivote que controla la rotación del personaje secundario son modificados, los primeros dos cambian a la animación que muestran actualmente y el pivote rota en ángulos de 90 grados de tal forma que los personajes se vean correctamente según el botón presionado. Que animación se reproduce, así como a que ángulo rota el pivote depende de dicho botón.

121

InputAction MoveLeft Si Status=InMenus o InCombat o Ejecutar la Función ChoosingLevel o PreviousButton en InputAction InStore el Widget activo MoveUp/Forward

InputAction MoveRight Si Status=InMenus o InCombat o Ejecutar la Función ChoosingLevel o NextButton en el InStore Widget activo InputAction MoveDown/Backward

Ilustración 146: Esquema de los eventos MoveDown/Backward, MoveUp/Forward, MoveRight & MoveLeft para navegación dentro de Widgets dentro de Pesonaje_BP en Quito Quest (Ronquillo, 2019) Si algún Widget está activo y se ejecutan los mismos eventos, el jugador podrá navegar dentro de esos Widgets siempre y cuando estos cuenten con comportamiento y usen las funciones NextButton y PreviousButton.

Revisar si el InputAction El juego esta juego esta Quitar pausa PauseGame pausado pausado

Borrar a El juego no está Pause_Widget de pausado pantalla

Dibujar Pause_Widget Pausar juego en pantalla

Ilustración 147: Esquema del evento PauseGame dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) Evento pausa o resume el juego, según su estado, dibuja o borra el Pause_Widget de pantalla.

Si Status = InStore o InMenus InputAction Cierra el menú o ChoosingLevel o InSubmenu Cancelar/Salir actual es verdadero

Ilustración 148: Esquema del evento Cancelar/Salir dentro de Personaje_BP en Quito Quest (Ronquillo, 2019)

122

Si hay un submenú activo lo cierra y regresa al menú por año, si se ejecuta nuevamente en este estado cierra también a ese menú y resume el juego. El ser ejecutado dentro de Store_Widget o NextLevel_Widget los cierra también.

3.2.6.3.1.2 Funciones

Si Agregar 1989_Widget CurrentYear=1989 a Main_Widget

Función Revisar Si Agregar 1999_Widget YearMenu CurrentYear CurrentYear=1999 a Main_Widget

Si Agregar 2019_Widget CurrentYear=2019 a Main_Widget

Ilustración 149: Esquema de la función YearMenu dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) Ejecutada por el evento BeginPlay cuando inicia el juego, determina que menú por año es agregado a Main_Widget, según el valor de la variable CurrentYear.

Dibuja Si CurrentElement = 0 Missions_Widget en pantalla

Dibuja Si CurrentElement = 1 Items_Widget en pantalla

Dibuja Status_Widget Revisar el valor de Si CurrentElement = 3 Función en pantalla OpemSubmenu CurrentElement del menu por año

Dibuja Si CurrentElement = 4 SaveGame_Widget en pantalla

Dibuja Si CurrentElement = 5 Exit_Widget en pantalla

Ilustración 150: Esquema de la función OpenSubMenu dentro de Personaje_BP en Quito Quest (Ronquillo, 2019)

123

Ejecutada por el evento Interactuar/Aceptar si la variable InSubMenu es falsa. Según el valor de la variable CurrentElement, presente en el menú por año que se esté utilizando, dibuja un submenú en pantalla.

Ejecuta función Función Selection en el Widget DoSomethingInSubMenu en pantalla

Ilustración 151: Esquema de la función DoSomethingInSubMenu dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) Función ejecutada por el evento Interactuar/Aceptar si la variable InSubMenu es verdadera. Ejecuta la función Selection del Widget que este abierto. Usado para utilizar y comprar ítems, así como seleccionar entre opciones de siguiente nivel y guardado de juego.

Sobrescribir datos de misión con Si CurrentYear = datos de 1989 QuitoQuestIntance de 1989 Función Llamar datos de StartQuestLog QuitoQuestInstance Sobrescribir datos de misión con Si CurrentYear = Revisar datos de 1999 CurrentYear QuitoQuestIntance de 1999

Sobrescribir datos de misión con Si CurrentYear = datos de 2019 QuitoQuestIntance de 2019

Ilustración 152: Esquema de la función StartQuestLog dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) Función ejecutada por el evento BeginPlay, inicializa los datos de misión del jugador con los datos guardados en QuitoQuestInstance según la época en la que esté el jugador. Las variables que están siendo sobrescritas están dentro del componente creado, QuestLog, cuáles son esas variables es explicado con más detalle posteriormente.

124

Sobrescribir datos de party con datos Si CurrentYear = de 1989 QuitoQuestIntance de 1989 Función Llamar datos de LoadPartyData QuitoQuestInstance Sobrescribir datos de party con datos Si CurrentYear = de 1999 Revisar QuitoQuestIntance CurrentYear de 1999

Sobrescribir datos de party con datos Si CurrentYear = de 2019 QuitoQuestIntance de 2019

Ilustración 153: Esquema de la función LoadPartyData dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) Ejecutada desde el evento BeginPlay, similar a la función StartQuestLog, sobrescribe los datos del party actual con los datos guardados en QuitoQuestInstance, según la época en la que este el jugador.

Sobrescribir datos de los items con Si CurrentYear = datos de 1989 QuitoQuestIntance de 1989 Función Llamar datos de LoadItems QuitoQuestInstance Sobrescribir datos de los items con Si CurrentYear = Revisar datos de 1999 CurrentYear QuitoQuestIntance de 1999

Sobrescribir datos de los ítems con Si CurrentYear = datos de 2019 QuitoQuestIntance de 2019

Ilustración 154: Esquema de la función LoadItems dentro de Personaje_BP en Quito (Ronquillo, 2019) Ejecutada por el evento BeginPlay, prácticamente idéntica a las dos funciones anteriores, se encarga de sobrescribir los ítems del jugador según datos guardados en QuitoQuestInstance y la época en la que se encuentre.

125

Realizar un Si la variable QuestID de Llamar a la Función recorrido de la un registro de la tabla es misión más UpdateWorld tabla igual a QuestName en la reciente QuestTime_List misión llamada

Ajusta la variable TimeID del actor Si ObjectiveID en un registro de la Realizar un con lel registro tabla es igual al número de un recorrido de los TimeID de la objetivo en la misión llamada y ese objetivos de la tabla llamada. objetivo ha sido completado. misión llamada

Evento UpdateWorldEvent

Ilustración 155: Esquema de la función UpdateWorld dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) Actualiza el valor de la variable TimeID según la revisión de otras variables, inicia con una revisión de la tabla QuestTime_List en comparación a la misión más recientemente agregada, si la variable QuestName de esa misión es igual a la variable QuestID en un registro de la tabla entonces se realiza otra revisión, ahora de los objetivos de dicha misión, dentro de esta revisión si el número del objetivo es igual a ObjectiveID dentro del registro obtenido y ese objetivo se ha completado entonces se ajusta el valor de la variable TimeID del actor con el valor de la variable TimeID de ese registro, finalmente se ejecuta el evento UpdateWorld_Event. Esta función no es ejecutada directamente por el jugador, sino por otros actores cuando el jugador completa un objetivo.

Realizar un Si el valor de la Función recorrido de la variable TimeID en un UpdateInteractableObjects tabla registro de la tabla es NPCTime_List igual a la variable TimeID

Cambiar la posición Si el valor de la variable del padre de ese actor NPC_ID en un actor Llamar a todos los según el valor de la llamado es igual a la actores de la clase variable Position del variable NPC_ID del InteractableObject_BP registro llamado registro llamado

Ilustración 156: Esquema de la función UpdateInteractableObjects dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) Ejecutada por evento BeginPlay y por otros actores dentro del juego, actualiza la posición de distintos actores dentro del juego según el valor de la variable TimeID, esta función siempre es ejecutada después de la función UpdateWorld ya que ella actualiza el valor de la variable

126

TImeID. También hace un recorrido de una tabla, en este caso la tabla NPCTime_List. Si un registro de esa tabla tiene como valor de la variable TimeID el mismo valor de la variable TimeID en Personaje_BP se hace una revisión de todos los actores del nivel y si alguno de ellos tiene a su variable NPC_ID con el mismo valor que la variable NPC_ID del registro llamado se modifica la posición del padre de ese actor dentro del nivel según el valor de la variable Position del registro llamado.

Si Alterar CurrentDayTim configuración de e=Dawn luces a mañana

Si Alterar CurrentDayTime configuración de Revisar el valor Función =Noon luces a medio día de UpdateWorldLight CurrentDayTme

Si Alterar CurrentDayTime configuración de =Sunset luces a ocaso

Si Alterar CurrentDayTime configuración de =Night luces a noche

Ilustración 157: Esquema de la función UpdateWorldLight dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) Esta función cambia la configuración de luces del nivel según el valor de la variable CurrentDayTime, es ejecutada por la función BeginPlay, además de otros actores dentro del juego, el esquema es una simplificación ya que la alteración de la configuración de luces con las variables dentro de la variable WorldLight. La configuración de luces incluye el cambio al ángulo de la luz direccional, cambios al color del componente de luz, de material del cielo, densidad de nubes y fuerza de niebla atmosférica, que valores toman estas variables depende de que parte del día se desea simular.

3.2.6.3.1.3 Sonidos en Personaje_BP Este es uno de los actores que reproduce efectos de sonido dentro del juego. Quito Quest utiliza una banda sonora relativamente simple, el juego posee un actor que controla la música y sonidos de fondo de un nivel. Además de esto el actor que controla el jugador posee la habilidad de producir simples efectos de sonido según las acciones del jugador. Acción Condición Descripción Status es igual a Reproduce el sonido de InputAction Interactuar/Aceptar InCombat, aceptar/interactuar si el jugador InMenus o InStore está activo dentro de un Widget. Reproduce el sonido de Juego no está InputAction Objectives/Menu abrir/cerrar menú si el juego no pausado esté pausado.

127

InputAction MoveUp/Forward InputAction Status es igual a Reproduce el sonido de MoveDown/Backward InCombat, navegación si el jugador está InputAction MoveRight InMenus o InStore activo dentro de un Widget. InputAction MoveLeft Reproduce el sonido de pausa InputActon PauseGame Ninguno juego. Status es igual a Reproduce el sonido de InputAction Cancelar/Salir InCombat, cancelar si el jugador está InMenus o InStore activo en un Widget. Tabla 55: Asignación de acciones a sonidos dentro de Personaje_BP en Quito Quest (Ronquillo, 2019) Se reproduce una variedad de sonidos 2D cuando el jugador navegue dentro de Widgets y pause el juego, que sonido que se reproduce no solo depende de que acción haya realizado el jugador sino también en que época se encuentre actualmente. Estos sonidos son extremadamente cortos, con una duración máxima de dos segundos, utilizados para crear mayor satisfacción del jugador al navegar los menús de juego, creando retroalimentación de sus acciones.

3.2.6.3.2 Componente QuestLog Se creó un componente para manejar las misiones del jugador, es usado únicamente en Personaje_BP, guarda las misiones totales y la misión actual del party actual, utilizado para simplificar el comportamiento de Personaje_BP al repartir funciones que estarían en ese actor a otro elemento. Variable Tipo Descripción Un listado que guarda todas las misiones que el jugador ha cumplido, así como la QuestsData Array de QuestData_Struct misión actual mientras se está cumpliendo. Variable guarda los datos de la misión ActiveQuestData QuestDatStruct actual que está cumpliendo el jugador, puede estar vacía. Tabla 56: Variables del componente QuestLog en Quito Quest (Ronquillo, 2019) En cualquier ocasión en la que se deban verificar los datos de las misiones del jugador, o cambiar esos valores, todo actor que realice ese cambio llama a este componente después de llamar a Personaje_BP.

3.2.6.3.2.1 Comportamiento Este componente no utiliza eventos, únicamente funciones, cumpliendo los objetivos más básicos, añadir una nueva misión al listado, actualizarlo y revisarlo.

128

Obtener misión Función Añadir misión a de objeto con AddNewQuestToLog QuestsData interactividad

Ilustración 158: Esquema de la función AddNewQuestToLog dentro del componente QuestLog en Quito Quest (Ronquillo, 2019) Es llamada por actores que guardan misiones, cuando el jugador interactúe con ellos y revise si el jugador puede o no recibir la misión se ejecuta este método y se añade esa misión al listado de misiones del jugador.

Si el valor de la variable QuestName de un Función Revisar elemento de QuestsData es igual al valor de la UpdateLog QuestsData variable QuestName de ActiveQuestData

Actualizar las variables de ese elemento con las variables de ActiveQuestData

Ilustración 159: Esquema de la función UpdateLog dentro del componente QuestLog en Quito Quest (Ronquillo, 2019) También es llamada por actores que son objetivos de misiones. Al cumplirse un objetivo, actualizan a la variable ActiveQuestData y ejecutan esta función. Luego revisan el listado de misiones, cuando encuentran la misión con el mismo nombre que la misión en ActiveQuestData actualiza los datos en el listado con la misión actual.

Función Revisar Buscar si la misión ActiveQuestData está CheckLog QuestsData dentro de QuestData

Regresa el valor booleano de la búsqueda, si se encuentra es verdadero, caso contrario es falso

Ilustración 160: Esquema de la función CheckLog dentro del componente QuestLog en Quito Quest (Ronquillo, 2019) Revisa si la misión que el jugador está cumpliendo actualmente consta en el listado de misiones totales. Función auxiliar del juego, controla que el sistema de misiones esté funcionando correctamente.

129

3.2.7 Actores 3.2.7.1.1 Personajes no jugables (NPCs) 3.2.7.1.1.1 NPC_TypeA_BP Los únicos personajes no jugable con los que no puede interactuar, solo existen dentro para poblar al mundo de juego y hacerlo más interesante, tienen un comportamiento muy simple y muestran una simple línea de dialogo. Nombre Descripción Flipbook Flipbook, muestra las animaciones del personaje. Colisionador suave, detecta si el jugador está cerca del personaje y Box ejecuta acciones según esa información. Imagen, renderiza una imagen que demuestra gráficamente al Bubble jugador que clase de NPC es este actor. Imagen de un dialogo de texto, utilizada para mostrar más DialogueImage fácilmente el dialogo de personaje, por defecto no es visible. DialogueText Texto, es el dialogo del personaje, por defecto no es visible. Tabla 57: Componentes dentro de NPC_TypeA_BP en Quito Quest (Ronquillo, 2019)

Nombre Tipo Descripción NPC_Name Texto Identificador único de este actor. Variable booleana, define si este actor puede Movable Booleano moverse dentro del mundo. Define la velocidad a la que se puede mover WalkSpeed Float este actor. Array de Un listado de todos los posibles diálogos de MisDialogos SimpleDialogue_Struct este actor. Tabla 58: Variables dentro de NPC_TypeB_BP en Quito Quest (Ronquillo, 2019)

3.2.7.1.1.1.1 Comportamiento Tienen una colección de eventos y funciones que permiten realizar sus tareas, asignar un dialogo y moverse dentro del mundo.

Evento Función Si Movable es Evento BeginPlay StartDialogue verdadero MoveToRandomLocation

Ilustración 161: Esquema del evento BeginPlay dentro de NPC_TypeA_BP en Quito Quest (Ronquillo, 2019) Al iniciar el nivel este personaje ejecuta la función StartDialogue, si el valor de la variable Movable es verdadero, ejecuta el evento MoveToRandomLocation, que hacen estas instrucciones es explicado más adelante.

130

Si el actor Hacer Evento Hacer componentes sobrepuesto es componente EnSuperposicion DialogueImage y Personaje_BP Bubble invisible DialogueText visibles

Si el actor Hacer Hacer componentes Evento sobrepuesto es componente DialogueImage y FinSuperposicion Personaje_BP Bubble visible DialogueText invisibles

Ilustración 162: Esquema de los eventos EnSuperposicion & FinSuperposicion dentro de NPC_TypeA_BP en Quito Quest (Ronquillo, 2019) Estos eventos son ejecutados cuando un actor entra y finaliza contacto con el componente Box, revisa que el actor en contacto es Personaje_BP y luego procede a cambiar la visibilidad de los componentes Bubble, DialogueImage y DialogueText, de tal forma que el dialogo de los personajes solo es visible cuando el jugador esté en proximidad. Esos valores son luego reiniciados cuando Personaje_BP termina su contacto.

Obtener un punto Evento aleatorio en rango Moverse a MoveToRandomLocation navegable ese punto

Evento MoveToRandomLocation Esperar

Ilustración 163: Esquema del evento MoveToRandomLocation dentro de NPC_TypeA_BP en Quito Quest (Ronquillo, 2019) Permite el movimiento del actor, es ejecutado por el evento BeginPlay. Al iniciar busca un punto aleatorio hacia donde moverse y se mueve hacia ese punto, una vez que llega ahí, espera por un momento y se vuelve a ejecutar. MoveToRandomLocation es un evento recursivo ya que se llama a sí mismo, creando un bucle infinito ya que el personaje se mueve mientras el juego este abierto.

Revisar el Ajustar flipbook Evento Si Movable valor de ha animación Animar es falso Movable por defecto

Si Movable Ajustar la animación de es verdadero flipbook según la dirección en la que se mueve el actor

Ilustración 164: Esquema del evento Animar dentro de NPC_TypeA_BP en Quito Quest (Ronquillo, 2019)

131

Ejecutado por evento Marcar, de tal forma que se ejecuta continuamente durante el juego. Define que animación del personaje reproduce el flipbook según la dirección en la que se esté moviendo el actor. Si no se mueve reproduce una animación por defecto de forma continua.

Revisa los elementos Función Si el valor de la variable StartDialogue de la tabla NPC_Name de un elemento de la SimpleDialogue_List tabla es el mismo a NPC_Name de este actor

Al terminar la Agrega a todas estas revisión de toda instancias a la variable la tabla MisDialogos

Función SetDialogue

Ilustración 165: Esquema de la función StartDialogue dentro de NPC_TypeA_BP en Quito Quest (Ronquillo, 2019) Ejecutada por el evento BeginPlay, llena la variable MisDialogos con todos los posibles diálogos que puede dar el personaje según su identificador único. Al terminar la revisión de toda la tabla ejecuta la función SetDialogue.

Si un objetivo ha sido Revisa los valores Revisa todos los completado y la variable Función QuestName de su misión SetDialogue dentro de objetivos de todas MisDialogos las misiones es igual a QuestName de un registro de MisDialogos

Ajustar el valor de DialogueText con la el dialogo respectivo.

Ilustración 166: Esquema de la función SetDialogue dentro de NPC_TypeA_BP en Quito Quest (Ronquillo, 2019) Asigna los distintos diálogos del personaje al componente DialogueText. Revisa las misiones y objetivos completados por el jugador, y según qué objetivo fue completado el actor llama a uno de sus posibles diálogos guardados en la variable MisDialogos.

3.2.7.1.1.2 NPC_TypeB_BP Casi idéntico a NPC_TypeA_BP, utilizando los exactos mismos componentes y variables. Su propósito cargar al actor con el que el jugador puede interactuar, es decir, es padre de otro actor con interactividad, pero por sí mismo no realiza ninguna acción. Son los actores que el jugador buscará para interactuar dentro del mundo.

132

Son necesarios ya que tienen ciertas diferencias fundamentales con NPC_TypeA_BP, el complemento Bubble de este actor tiene una apariencia distinta, mostrando claramente al jugador que son actores diferentes, además de tener un valor estático en DialogueText, dándole instrucciones al jugador de que acción realizar cuando este cerca de este actor. Por esa misma razón este actor no utiliza los eventos StartDialogue ni SetDialogue, pero emplea a todos los demás eventos vistos en NPC_TypeA_BP.

3.2.7.1.1.3 Enemy_BP Son los enemigos del jugador, tienen varias similitudes con los actores explicados anteriormente, reutilizando muchos de sus componentes, variables, eventos y funciones, pero tienen también características que los hace únicos, ya que son los únicos actores que buscan interacción con el jugador en lugar de moverse pasivamente. Nombre Componente Componente auxiliar, rota según el actor se mueva dentro mundo, de tal MiraPivote forma que el componente Mira siempre esté al frente del actor. Componente de percepción del actor, permite que el actor pueda ver al Mira jugador. Tabla 59: Componentes únicos de Enemy_BP en Quito Quest (Ronquillo, 2019) Utiliza varios de los componentes vistos en los anteriores actores, excluyendo a DialogueImage y DialogueText ya que este no utiliza diálogos. Tiene un componente auxiliar que rota cuando se mueve el actor y otro mucho más interesante, percepción. Todos estos actores son inteligencias artificiales, es decir, son agentes. Tiene la capacidad de percibir al jugador con el componente Mira. Los enemigos pueden ver al jugador si este pasa frente a ellos en un rango definido, al detectar al jugador lo persiguen con el objetivo de iniciar el combate. Variable Tipo Descripción EnemyID Texto Identificador único del actor. WalkSpeed Float Velocidad a la que se mueve el actor. InChase Booleana Define si el actor está persiguiendo al jugador. PlayerHit Booleana Define si el actor ha hecho contacto con el jugador. Tabla 60: Variables dentro de Enemy_BP en Quito Quest (Ronquillo, 2019) Utiliza variables ya presentes en los actores anteriores, con dos valores booleanos únicos que definen si está en persecución del jugador y si ya lo ha alcanzado. Los enemigos siempre estarán en movimiento por lo que no utilizan la variable Movable.

3.2.7.1.1.3.1 Comportamiento También utiliza mucho del comportamiento definido en NPC_TypeA_BP, utilizando los eventos Animar y MoveToRandomLocation de forma casi exacta, así como las instrucciones del evento BeginPlay. Sin embargo, a diferencia de ese actor este no utiliza ninguna función, por lo que BeginPlay no utiliza la función StartDialogue, y ya que este actor puede perseguir al jugador, no

133

únicamente moverse aleatoriamente, tiene una revisión dentro del evento MoveToRandomLocation, antes de que se llame así mismo, según el valor de la variable InChase, verifica si debe de seguir moviéndose de forma aleatoria. Por su objetivo de seguir al jugador, este actor tiene unos cuantos eventos únicos.

Si el actor Evento Evento percibido es Ajustar InChase a InicioPersepción ChasePlayer Personaje_BP verdadero

Si el actor Evento percibido es Esperar Ajustar InChase a falso FinPersepcion Personaje_BP

Evento MoveToRandomLocation

Ilustración 167: Esquema de los eventos InicioPersepcion y FinPersepcion dentro de Enemy_BP en Quito Quest (Ronquillo, 2019) Estos eventos tienen comportamientos similares a los eventos de EnSuperposicion y FinSuperposicion en NPC_TypeA_BP. Cuando el actor detecta a Personaje_BP ajusta el valor de la variable InChase a verdadero, rompiendo el bucle del evento MoveToRandomLocation y ejecutando el evento ChasePlayer. Una vez que el actor deja de percibir al jugador, espera 10 segundos y reinicia el bucle de MoveToRandomLocation, el retraso antes de reiniciar el bucle es para que persiga al jugador por un poco más de tiempo luego de perderlo de vista, y para que sea posible que lo pueda ver nuevamente, dando la apariencia de tener más inteligencia.

Moverse a la Evento Si InChase es Evento posición actual ChasePlayer verdadero ChasePlayer del jugador

Ilustración 168: Esquema del evento ChasePlayer dentro de Enemy_BP en Quito Quest (Ronquillo, 2019) Otro evento recursivo, se ejecuta cuando el actor percibe a Personaje_BP. El actor se mueve hacia la posición del jugador, luego revisa si InChase es verdadero y de ser el caso se llama a sí mismo, formando otro bucle infinito. Que se rompe cuando el actor deja de percibir al jugador, en cuyo caso InChase es falso y se reinicia el evento de MoveToRandomLocation.

134

3.2.7.2 LocationMarker_BP Estos objetos pueden ser objetivos de ciertas misiones, no son visibles al jugador, son marcadores que cubren áreas de ciertos niveles, cuando el jugador entra en contacto con ellos verifican si son objetivos de la misión actual y ejecutan una serie de instrucciones. Utiliza únicamente un componente, una esfera que detecta si el jugador ha entrado en contacto. El actor también utiliza una variable, un identificador único, LocationName, utilizado para verificar que el actor es un objetivo.

3.2.7.2.1 Comportamiento Tiene un evento que se ejecuta cuando el actor entra en contacto con el jugador y una serie de funciones que verifican si el objeto es un objetivo, si puede ser marcado como cumplido y que cambian variables del jugador.

Si el actor Evento Función Si CheckLocation sobrepuesto es EnSuperposicion CheckLocation es verdadero Personaje_BP

Si Función Función Ajustar ActiveQuestData UpdateWorld de UpdateLog de ActiveQuestData fue completada Personaje_BP QuestLog de QuestLog

Anima el panel de Restaurar Caso objetivo completado en ActiveQuestData contrario Main_Widget

Anima el panel de objetivos completados en Main_Widget

Ilustración 169: Esquema del evento EnSuperposicion dentro de LocationMarker_BP en Quito Quest (Ronquillo, 2019) Se ejecuta cuando el jugador entra en contacto con el actor, luego llama la función CheckLocation que revisa si el actor es un objetivo, actualiza los valores de ActiveQuestData y llama funciones dentro de QuestLog para que se actualice el listado de misiones y la función UpdateWorld en Personaje_BP para actualizar el nivel, finalmente si la misión actual ha sido completada con este objetivo, la variable ActiveQuestData regresa a sus valores por defecto, es decir, se vacía.

135

Si el valor de la variable Si el objetivo anterior Función Revisa todos los target en algún objetivo a ese no es opcional y CheckLocation objetivos de ActiveQuestData es igual a LocationName ha sido completado

Marcar objetivo como Retornar valor de completado y actualizar verdadero ActiveQuestData

Ilustración 170: Esquema de la función CheckLocation dentro de LocationMarker en Quito Quest (Ronquillo, 2019) Esta función es ejecutada por el evento de EnSuperposicion, revisa todos los objetivos de ActiveQuestData y compara el valor de la variable Target con su variable LocationName para verificar si es un objetivo de la misión actual, luego revisa que el objetivo anterior a ya se haya cumplido o sea opcional en cuyo caso marca al objetivo actual como cumplido y regresa el valor de verdadero para la revisión del evento EnSuperPosicion.

3.2.7.3 Light_BP Cumplen la misma función que los actores NPC_TypeA_BP, es decir, son principalmente utilizados para poblar el mundo de juego, sin embargo, también se usan para generar más luz dentro de los niveles, representan postes de luz, lámparas y focos. Utiliza dos componentes, una malla estática, que toma distintas formas según el objeto al que se está representando, y un componente de luz. Es especial y en comparación a la mayoría de los actores mencionados anteriormente ya que en su forma más básica nunca es usado dentro del juego, únicamente instancias con distintas propiedades. Para cada objeto que represente la malla estática utilizada será distinta, además de la ubicación, intensidad y color del componente de luz que utiliza. Para cada uno de estos objetos se creó una distinta instancia del actor, todos teniendo el mismo, simple, comportamiento. Tan simple que este actor no utiliza variables y únicamente una función.

Revisa variable Función Si Activar CurrentDayTime CheckDayTime CurrentDayTime componente de de Personaje_BP es Night luz

Si CurrentDayTime Desactivar tiene cualquier otro componente de valor luz

Ilustración 171: Esquema de la función CheckDayTime dentro de Light_BP en Quito Quest (Ronquillo, 2019) Es ejecutada por el evento BeginPlay, y también por Personaje_BP cuando se actualiza el mundo de juego. Revisa el valor de la variable CurrentDayTime dentro de Personaje_BP, si

136 esa variable tiene el valor de Noche el componente de luz es activado, caso contrario es desactivado.

3.2.7.4 Sound_BP Manejan la música y sonidos de fondo de un nivel. Solo existe uno de estos actores por nivel, reproducen, en un bucle, un par de pistas de audio, dándole más vida a todos los niveles del juego. Poseen dos componentes de audio y dos variables, que guardan pistas de audio. Cada componente de audio reproducirá una de las variables asignadas, realizando así la función antes explicada.

Reproducir Función Reproducir audio audio de PlaySound de sonido de música fondo

Ilustración 172: Esquema de la función PlaySound dentro de Sound_BP en Quito Quest (Ronquillo, 2019) Llamada por el evento BeginPlay, inicia la reproducción de las dos pistas de audio cargadas en el actor. El nodo que reproduce estas pistas permite cambiar de forma individual el volumen de cada una, así como asignar un fundido de entrada, de tal forma que estas no empiezan de forma abrupta. Las pistas se repiten automáticamente dentro del nivel de una forma imperceptible, el fundido solo es ejecutado cuando el nivel inicia por primera vez. El juego consta con una colección de pistas de música y sonido de fondo que son utilizados en los distintos niveles, cada nivel no consta con música y audio de fondo únicos, pero existen suficientes variaciones para las diferentes situaciones dentro de los niveles como se planeó.

3.2.7.5 Actores Hijos Esta sección detalla a la funcionalidad de los actores hijos, es decir, actores que son hijos de otros actores. Ninguno de ellos actores tiene apariencia física y poseen únicamente un componente de colisión que detecta cuando el jugador trata de interactuar con ellos. Cumplen varias funciones del juego, desde el sistema de conversación, dar misiones al jugador, sistema de tienda y poder moverse entre niveles.

3.2.7.5.1 LevelLoader_BP Es hijo de actores tipo Car_BP. Permite navegar de un nivel a otro. Posee dos variables, una llamada LevelName, que guarda el nombre del nivel al que puede acceder, escrito de forma idéntica como aparece dentro del explorador en el editor de Unreal Engine 4 y otra llamada LevelText, que es una variable de texto con el nombre del nivel a ser mostrado al jugador.

137

3.2.7.5.1.1 Comportamiento

Dibuja Enviar variable Evento NextLevel_Widget LevelText a NewLevelInteract en pantalla NextLevel_Widget

Ilustración 173: Esquema del evento NewLevelInteract dentro de LevelLoader_BP en Quito Quest (Ronquillo, 2019) Se ejecuta cuando el jugador interactúa con este actor, dibuja a NextLevel_Widget en pantalla y envía el nombre del nivel a ese Widget, que luego es mostrado al jugador.

Evento Sobrescribir las variables respectivas de Dibujar LoadLevel QuitoQuestInstance con los variables Loading_Widget actuales del jugador en pantalla

Cargar nivel descrito en LevelName

Ilustración 174: Esquema del evento LoadLevel dentro de LevelLoader_BP en Quito Quest (Ronquillo, 2019) Se ejecuta cuando el jugador seleccione la opción si dentro de NextLevel_Widget. Sobrescribe los datos en QuitoQuestInstance con los datos actuales del jugador, luego dibuja a Loading_Widget en pantalla y carga el nivel respectivo.

3.2.7.5.2 Store_BP Es hijo de actores NPC_TypeB_BP. Permite al jugador interactuar con una tienda, guarda los ítems que son vendidos por dicho elemento. Posee únicamente una variable, un array de texto llamado Items, que guarda los nombres de los ítems que la tienda puede vender.

3.2.7.5.2.1 Comportamiento

Evento Dibuja a Envia variable InteractStore Store_Widget items a en pantalla Store_Widget

Ilustración 175: Esquema del evento InteractStore dentro de Store_BP en Quito Quest (Ronquillo, 2019) Es ejecutado cuando el jugador interactúa con este actor. Dibuja a Store_Widget en pantalla y envía su variable de ítems hacia el Widget.

138

3.2.7.5.3 InteractableObject_BP El segundo actor más complejo después de Personaje_BP, utilizado como hijo NPC_TypeB_BP. Maneja el sistema de diálogos del juego, además de asignar misiones al jugador, un objetivo de una misión y dar un ítem al jugador. Variable Tipo Descripción NPC_ID Texto Identificador único del actor. QuestData Quest_Struct Misión que el actor puede dar al jugador. Array de MyDialogye Guarda todos los diálogos asignados al actor. nombres Valor numérico de la línea actual de la LineCurrent Integer conversación en el sistema de dialogo. Valor numérico de la conversación actual del ConversationID Integer sistema de dialogo. Valor numérico que identifica en que ItemAtConversation Integer conversación el actor da un ítem al jugador. HoldsItem? Booleano Define si el actor puede dar un ítem o no. Nombre del ítem que el actor puede dar al ItemName Texto jugador. Tabla 61: Variables de InteractableObject_BP en Quito Quest (Ronquillo, 2019) Posee variables que ayudan en el cumplimiento de su funcionalidad, desde el sistema de dialogo, sistema de misiones y en darle un ítem al jugador.

3.2.7.5.3.1 Comportamiento Por todas las funciones que este actor cumple dentro del juego, posee un comportamiento complejo, dividido en varios eventos y funciones.

Extrae todos los registros Evento Revisa la de la tabla donde Añade esos LlenarDatos tabla NPC_ID en la tabla sea registros a Dialogue_List igual a NPC_ID MyDialogue

Ilustración 176: Esquema del evento LlenarDatos dentro de InteractableObject_BP en Quito Quest (Ronquillo, 2019) Es ejecutado por el evento BeginPlay, carga todos los diálogos asignados al actor y los guarda en la variable MyDialogue.

139

Ajusta velocidad Evento Función LineCurrent = del actor padre a Interact SetNewConversation LineCurrent +1 cero

Si ActiveQuestData Función Ajustar valores esta vacío o la AddNewQuestToLog de Función misión prerrequisito DialogueCreate de QuestLog ActiveQuestData de QuestData ha con QuestData sido completada

Animar panel de nueva misión en Main_Widget

Ilustración 177: Esquema de la función Interact dentro de InteractableObject_BP en Quito Quest (Ronquillo, 2019) Se inicia cuando el jugador interactúa con este actor. Baja a cero el valor de la velocidad del actor padre, tal que, si el jugador interactuó con el actor mientras se movía su padre, este se queda quieto, luego ejecuta la función SetNewConversation, aumenta el valor de la variable LineCurrent por uno. Continúa llamando a DialogueCreate, si el jugador puede aceptar la misión del actor esta es ajustada como su misión actual. El comportamiento de las funciones SetNewConversation y DialogueCreate se explicará más adelante.

Si, dentro de un registro de la tabla, las variables Función Revisa la tabla NPC_ID y QuestName son SetNewConversation ConversationObjectives_List iguales a las variables NPC_ID del actor y QuestID de ActiveQuestData

Ajustar Si el numero de un ConversationID con objetivo es igual a Revisa los objetivos el valor de ObjectiveID del registro de ActiveQuestData ConversationID del obtenido y ese objetivo registro obtenido. ha sido completado.

Ilustración 178: Esquema de la función SetNewConversation dentro de InteractableObject_BP en Quito Quest (Ronquillo, 2019) Asigna el valor la variable ConversationID según el último objetivo completado por el jugador en comparación de la tabla ConversationObjectives_List. Se revisa esa tabla y se busca por un registro donde las variables NPC_ID y QuestName sean iguales a NPC_ID del actor y QuestID de la misión actual, al encontrarse ese registro se hace una segunda búsqueda dentro de la misión actual hasta que se encuentre un objetivo con el mismo valor de ObjectiveID del registro de la tabla y se haya completado. Al encontrarse este registro se asigna su valor de ConversationID a ConversationID del actor.

140

Función Revisa el estado de La conversación DialogueCreate la conversación. acaba de empezar

Dibujar La conversación Dialogue_Widget ya ha empezado. en pantalla

Función Función DialogueGetLine DialogueSendLin e Ilustración 179: Esquema de la función DialogueCreate dentro de InteractableObject en Quito Quest (Ronquillo, 2019) Es ejecutada por el evento Interact, como todas las instrucciones en ese evento, se llama cada vez que el jugador interactúa con el actor. Se encarga de inicializar y actualizar el sistema de diálogos, cuando el jugador interactúa con el actor por primera vez dibuja Dialogue_Widget en pantalla y ejecuta las funciones que procesan los diálogos. Si la conversación ya fue inicializada únicamente ejecuta esas instrucciones.

141

Función Revisa la Extrae el registro donde variable DialogueGetLine ConversationID y LineCurrent sean MyDialogue iguales en el registro y en el actor

Envía esos registros Si la Eliminar a Al terminar la a la funcion conversación Dialogue_Widget revisión. DialogueSendLine terminó de pantalla

Ajustar Función Si GiveItem es LineCurrent a valor GiveItem verdadero Revisa el valor de original GiveItem

Ajustar velocidad de actor padre a Si GiveItem es valor original falso

Ajustar Status en Función Función Personaje_BP a Función UpdateLog de UpdateWorld de Moving CheckInteracted QuestLog Personaje_BP

Anima el panel de Si Restaurar objetivos completados ActiveQuestData ActiveQuestData en Main_Widget fue completada

Anima el panel de Caso objetivo completado en contrario Main_Widget

Ilustración 180: Esquema de la función DialogueGetLine dentro de InteractableObject_BP en Quito Quest (Ronquillo, 2019) La función más extensa de todo el juego, se divide en dos partes generales, en primer lugar, hace un recorrido de la variable MyDialogue y extrae el dialogo a mostrar según los valores de ConvesationID y LineCurrent. Al terminar esa revisión hace otras, si la conversación ya terminó elimina a Dialogue_Widget de pantalla, comprueba si es un actor que puede dar un ítem, de ser el caso ejecuta la función GiveItem y continúa reiniciando la variable LineCurrent, lo mismo que hace si GiveItem es falso. Luego restaura la velocidad del actor padre, permite al jugador volver a moverse y termina ejecutando una serie de funciones que revisan si el actor es un objetivo de misión, actualiza el listado de misiones y el mundo del juego.

142

Envía la línea de Revisa de quien Función Recibe los datos de DialogueSendLine DialogueGetLine dialogo a es la línea de Dialogue_Widget dialogo.

Enviar nombre del Oscurecer retrato Si el dialogo es Si el dialogo es personaje no de miembro del de un de un miembro jugable a party personaje no del party Dialogue_Widget jugable

Oscurecer retrato Enviar nombre del de personaje no personaje a jugable Dialogue_Widget

Ilustración 181: Esquema de la función DialogueSendLine dentro de InteractableObject_BP en Quito Quest (Ronquillo, 2019) Es ejecutada por la función DialogueCreate. Luego de filtre un dato a ser mostrado al jugador, procesa como ese dialogo enviado a pantalla. Inicia recibiendo los datos filtrados y envía la línea de dialogo a Dialogue_Widget, luego revisa a que personaje le pertenece ese dialogo, si es uno de los miembros del party, el nombre de ese personaje es enviado al Widget y el retrato del otro personaje se oscurece. De no ser el caso hace el proceso opuesto, oscurece el retrato del miembro del party y envía el nombre del personaje a Dialogue_Widget. Estas 4 funciones son las que realizan los procesos del sistema de dialogo dentro del juego.

Función Si GiveItemAtConversation Agregar Ítem a listado de GiveItem = ConversationID ítems de Personaje_BP

Animar el panel de nuevo item en Main_Widget

Ilustración 182: Esquema de la función GiveItem dentro de InteractableObject_BP en Quito Quest (Ronquillo, 2019) Es ejecutada por DialogueGetLine después de procesar que línea de dialogo enviar y de revisar si el actor puede dar un ítem. Revisa si el valor de la conversación actual y de la variable GiveItemAtConversation son iguales, de ser el caso se le da ese ítem al jugador y se llama a Main_Widget para que reproduzca la animación del elemento que notifica al jugador que ha obtenido un nuevo ítem.

143

Si el valor de la variable Si el objetivo anterior Función Revisa todos los target en algún objetivo a ese no es opcional y CheckInteracted objetivos de ActiveQuestData es igual a NPC_ID ha sido completado

Marcar objetivo como Retornar valor de completado y actualizar verdadero ActiveQuestData

Ilustración 183: Esquema de la función CheckInteracted dentro de InteractableObject_BP en Quito Quest (Ronquillo, 2019) Casi idéntica a la función CheckLocation dentro de LocationMarker_BP, en InteractableObject_BP es ejecutada por la DialogueGetLine y cumple el mismo propósito que en el ese actor. Revisa todos los objetivos de ActiveQuestData y compara el valor de la variable Target con su variable NPC_ID para verificar si es un objetivo de la misión actual, luego revisa que el objetivo anterior ya se haya cumplido o sea opcional, en cuyo caso lo marca como cumplido.

3.2.8 Sistema de tráfico El juego consta con una simple simulación de tráfico, su propósito es similar a los actores NPC_TypeA_BP, ya que solo dan más vida al mundo de juego, cumpliendo una función meramente estética. Para la simulación el sistema utiliza un grupo de actores que cumplen distintos roles en el sistema.

3.2.8.1 Car_BP Actor principal de la simulación, como su nombre lo indica es el actor que simula un auto, o más abiertamente, un vehículo. Su forma más básica nunca es usada dentro del juego, únicamente instancias con distintas propiedades. Componente Descripción Guarda la malla estática principal del vehículo, es decir su carcasa. En distintas instancias de este actor la malla variaría, Malla estática permitiendo crear varios vehículos con el mismo comportamiento desde el mismo actor. Rodea a la malla estática, de tal forma que otros actores no puedan Colisionador duro atravesarla. Situado en la parte frontal del actor, detecta si esta colisionando Colisionador suave. con otros actores. Un par de focos de luz situados en la parte frontal del actor, Luces frontales simulan las luces delanteras de un auto. Cuatro mallas estáticas usados para simular las llantas del Llantas vehículo Tabla 62: Componentes dentro de Car_BP en Quito Quest (Ronquillo, 2019)

144

Utiliza una malla estática, la representación visual del vehículo, cual utiliza depende de que vehículo representa. Para que otros actores no puedan pasar a través de estos actores este tiene un colisionador duro, que varía de forma según la malla estática utilizada, además de un colisionador suave utilizado para detectar colisiones con otros actores, finalmente consta con un par de focos de luz utilizados para simular las luces delanteras del vehículo, así como sus llantas. La posición de todos estos actores cambia según la malla estática utilizada. Son cambios que deben ser aplicados manualmente durante el desarrollo del juego, ya que sería demasiado complejo cambiar estos valores de forma dinámica, por ello se crearon instancias de este actor para los distintos vehículos. Variable Tipo Descripción Movable Booleana Define si el actor se puede mover o no. Speed Float Define la velocidad a la que se mueve el actor. Define la ruta que seguirá el actor al moverse, Array de TargetPoints estos actores siempre siguen una ruta puntos determinada, no se mueven aleatoriamente. CurrentPoint Integer Valor del TargetPoint actual. Indica después de que TargetPoint está un SemaforoDespuesDe Integer objeto de clase Semaforo_BP Semáforo Semaforo_BP Objeto de clase Semaforo_BP Tabla 63: Variables dentro de Car_BP en Quito Quest (Ronquillo, 2019) Las variables Movable y Speed definen si el actor se puede mover o no, y de poder moverse a qué velocidad se mueve. Posee también un array de puntos que definen la ruta en la que se mueve el actor, estos actores no se mueven de forma aleatoria como los anteriores, siguen un camino determinado, conformado por estos puntos. Para una mejor simulación de transito el juego emplea semáforos, dentro de Car_BP se asigna un actor de clase Semaforo_BP y se le da una posición dentro de su ruta, de tal forma que, dependiendo del valor del semáforo cuando el actor este en ese punto su comportamiento puede cambiar.

3.2.8.1.1 Comportamiento Tiene un comportamiento relativamente simple para completar sus tareas, utilizando una serie de eventos y funciones para poder realizarlas correctamente.

Evento Función Si Movable Ajustar vida BeginPlay CheckDayTime es del actor verdadero

Evento MoveToNextPoint

Ilustración 184: Esquema del evento BeginPlay dentro de Car_BP en Quito Quest (Ronquillo, 2019)

145

Cuando el nivel inicie, este actor ejecuta unas instrucciones de inicialización. Empezara ejecutando la función CheckDayTime, luego revisa si la variable Movable es verdadera, de ser el caso utiliza un nodo único, que es ajustar la vida del actor, todos los demás actores están de forma permanente dentro de un nivel, así el jugador no los vea, mientras que estos tienen un ciclo de vida limitado, y al cumplirlo son eliminados. Finalmente ejecuta el evento MoveToNextPoint.

Obtiene el Mueve al actor Evento elemento hacia ese MoveToNextPoint CurrentPoint de elemento TargetPoints

Revisar variable Compara CurrentPoint Si son Si son Estado de la con iguales distintos variable Semaforo SemaforoDespuesDe

Si Estado CurrentPoint = es Verde CurrentPoint + 1

Si Estado es Evento Rojo o Amarillo MoveToNextPoint

Ilustración 185: Esquema del evento MoveToNextPoint dentro de Car_BP en Quito Quest (Ronquillo, 2019) Maneja el movimiento del actor dentro del mundo, es ejecutado por BeginPlay y se ejecuta a si mismo al acabar cada instrucción, lo que lo convierte en otro evento recursivo. Obtiene un punto de TargetPoints según el valor de CurrentPoint (inicialmente cero), luego mueve a ese actor hacia ese punto y hace una revisión. Si en ese punto de control se encuentra un semáforo revisa el valor del semáforo, y según su valor aumenta el valor de CurrentPoint y se llama a sí mismo, o hace una segunda revisión luego de realizar esa acción. Si a ese punto no está asignado un semáforo entonces aumenta el valor de la variable CurrentPoint. Cuando la variable CurrentPoint no es aumentada antes de la llamada entonces el objeto trata de moverse hacia el punto donde ya se encuentra, o, en otras palabras, no se moverá.

Si el actor sobrepuesto Ajustar Evento es Personaje_BP o EnSuperposicion velocidad del Car_BP actor a cero.

Si el actor sobrepuesto Evento Restaurar el valor FinSuperposicion es Personaje_BP o de velocidad del Car_BP actor

Ilustración 186: Esquema de los eventos EnSuperposicion & FinSuperposicion dentro de Car_BP en QuitoQuest (Ronquillo, 2019)

146

Son ejecutados cuando un actor entra o finaliza contacto con el colisionador suave. Verifica que el actor en contacto sea otro actor Car_BP o el jugador, en cuyo caso cambia el valor de la velocidad del actor a cero. Una vez que uno de estos actores termine el contacto ese valor regresa al normal y el actor sigue moviéndose. Utilizados para que no arrastren al jugador contra su voluntad en el mundo del juego y para evitar que grupos de estos actores se atoren entre sí.

Evento Si la velocidad del Rotar Marcar actor es mayor componentes de que cero llantas

Ilustración 187: Esquema del evento Marcar dentro de Car_BP en Quito Quest (Ronquillo, 2019) Dentro de este actor el evento Marcar es utilizado para controlar la rotación de los componentes llantas, mientras el actor se esté moviendo las llantas rotar, caso contrario, quedan inmóviles

Revisar el valor de la Función variable Si CurrentDayTime Activar luces CheckDayTime CurrentDayTime de es Noche frontales Personaje_BP

Si CurrentDayTime Desactivar tiene cualquier otro luces frontales valor

Ilustración 188: Esquema de la función CheckDayTime dentro de Car_BP en Quito Quest (Ronquillo, 2019) Es ejecutada por el evento BeginPlay y también por el actor Personaje_BP, cuando se debe actualizar el mundo. Revisa el valor de la variable CurrentDayTime de Personaje_BP, si su valor es noche activa las luces frontales del actor, si tiene cualquier otro valor, las desactiva. Utilizado para adaptar al actor a la configuración de luces del nivel.

3.2.8.2 Semaforo_BP Actor que controla el tráfico, conformado por una malla estática y un juego de luces de colores. Según qué luz este activa define el comportamiento de actores Car_BP. Variable Tipo Descripción Estado Semaforo_Enum Define el estado del semáforo. Define el tiempo de espera entre cambios de WaitingTime Float estado. Tabla 64: Variables dentro de Semaforo_BP en Quito Quest (Ronquillo, 2019)

147

Las variables definen el estado en el que está el semáforo, es decir, que luz esta visible. Además de un tiempo de espera entre los cambios de estado.

Revisar Esperar según Evento Si estado variable la variable SwitchLightColor es Rojo s de Estado WaitingTime

Si estado Ajustar estado es verde a verde

Esperar según la variable WaitingTime*2/3

Esperar según la Ajustar estado Ajustar estado variable a rojo a amarillo WaitingTime*1/3

Ilustración 189: Esquema del evento SwitchLightColors dentro de Semaforo_BP en Quito Quest (Ronquillo, 2019) Es ejecutado cuando por el evento BeginPlay al iniciar el nivel. Un evento recursivo que define el valor de la variable Estado, así como el color de la luz del actor. Pasa por todos los posibles valores de Estado en forma cíclica, tomando un tiempo de espera entre cambios según la variable WaitingTime. Tratando de simular el comportamiento de un semáforo real, el actor espera el valor entero de la variable WaitingTime si la luz esta roja, espera 2/3 del valor de WaitingTime si la variable esa en verde, y el tiempo más corto, solo 1/3 del valor de WaitingTime si está en amarillo.

3.2.8.3 ClonadorCarros_BP Utilizado para instanciar a actores de clase Car_BP de forma dinámica, de tal forma que, sin importar cuanto tiempo pase el jugador dentro del nivel, siempre habrá tráfico en las calles del nivel, y estos elementos no siempre serán los mismos. Variable Tipo Descripción Define la ruta por la que los actores que este objeto Array de TargetPoints instancia se mueven, todos los actores creados por puntos uno de estos actores seguirán la misma ruta. Semaforo Semaforo_BP Objeto de clase Semaforo_BP Variable auxiliar utilizada para instanciar actores de Car Car_BP clase Car_BP Indica después de que TargetPoint está un objeto de SemaforoDespues Integer clase Semaforo_BP Define si el actor debe instanciar a más actores de Spawning Booleana clase Car_BP

148

Tiempo mínimo de espera entre la instancia de un LowerTime Float nuevo actor y otro. Tiempo máximo de espera entre la instancia de un MaxTime Float nuevo actor y otro. Array de Un listado de las posibles instancias de Car_BP que Carros peones este actor creará dentro del nivel. Tabla 65: Variables dentro de ClonadorCarros_BP en Quito Quest (Ronquillo, 2019) Comparte variables con los actores Car_BP, esto se debe ya que se necesita la información de la ruta por la que se van a mover, por lo que, cuando este actor instancia a actores Car_BP asigna esas variables a las variables Car_BP, permitiéndole movimiento. Instancia a actores en un intervalo de tiempo aleatorio, para no sobrellenar el nivel de actores, además de realizar una comprobación si debe o no instanciar más actores. Finalmente tiene un listado de las posibles instancias de Car_BP para añade al mundo de juego.

3.2.8.3.1 Comportamiento El ultimo actor con comportamiento medianamente complejo, el principal propósito del actor es instanciar a otros actores, adicionalmente tiene una serie de eventos que revisa cuando debe realizar esa tarea.

Revisar el Si Evento Evento valor de Spawning Esperar SpawnCars SpawnCars Spawning es falso

Obtener un elemento Ajustar variable Car Si Spawning aleatorio de la con elemento es verdadero variable Carros obtenido

Ajustar variables de Esperar un valor aleatorio Instanciar Car Car con las variables de entre LowerTime y en el mundo del ClonadorCarros_BP MaxTime juego respectivas

Ilustración 190: Esquema del evento SpawnCars dentro de ClonadorCarros_BP en Quito Quest (Ronquillo, 2019) Ejecutado por el evento BeginPlay, se encarga de instanciar a los vehículos. Revisa el valor de la variable Spawning, de ser falsa espera un momento y se llama a sí mismo, caso contrario llama a un elemento aleatorio de la variable Carros y la utiliza para sobrescribir la variable auxiliar de tipo Car_BP. Luego asigna las variables TargetPoints, SemaforoDespues y Semaforo de ClonadorCarros_BP a las variables pertinentes, para luego instanciar a ese objeto dentro. Finalmente espera un valor aleatorio entre LowerTime y MaxTime y se llama a sí mismo.

149

Si el actor Ajustar Evento Evento sobrepuesto es Spawning EnSuperposicion SpawnCars Car_BP a falso

i el actor Ajustar Evento Evento Spawning a FinSuperposicion sobrepuesto es SpawnCars Car_BP verdadero

Ilustración 191: Esquema de los eventos EnSuperposicion & FinSuperposicion dentro de ClonadorCarros_BP en Quito Quest (Ronquillo, 2019) Revisan si termino o inicio contacto con actor Car_BP, de ser el caso, cambia el valor de la variable Spawning a falso, rompiendo el bucle de instancias de SpawnCars. Cuando el contacto termina el valor de Spawning es restaurado y el bucle en SpawnCars se reinicia continúa. Estos eventos revisan si un actor Car_BP está dentro del clonador, impidiendo que instancie a otro actor en la misma posición, lo que podría generar errores dentro del juego.

3.2.8.4 DestructorCarros_BP Último elemento del sistema de tráfico y el más simple, actor opuesto a ClonadorCarros_BP, ya que, si ese crea actores, este los destruye. Consta de un simple comportamiento, cuando un actor tipo Car_BP entra en contacto, lo es eliminado del mundo de juego. Es utilizado como actor de control, ya que elimina a elementos innecesarios de memoria.

3.3 Desarrollo a gran escala 3.3.1 Diagrama entidad relación en Quito Quest El conjunto de tablas de datos y enumeradores empleados en el juego se pueden considerar como una base de datos relacional, ya que cada uno de estos elementos cumple con las características que definen las definen, como identidad referencial, claves primarias y foráneas y relaciones entre ellas. Estas bases de datos pueden ser representadas por un diagrama entidad relación, donde se puede observar gráficamente como sus entidades (tablas) están relacionadas entre sí. Dentro de Quito Quest este diagrama es representado como:

150

Ilustración 192: Diagrama entidad relación en Quito Quest (Ronquillo, 2019) Como se puede observar en el diagrama, las tablas Levels_List, MontonPuntos_List, Widget_List y Card_List no tienen relación con las demás, las relaciones entre las tablas restantes se explican cómo: Relación Descripción La tabla NPCTime_List hereda el componente TimeID de Time_List – Time_List, por ello todos NPCID de NPCTime_List NPCTime_List deben de estar presentes en Time_List La tabla QuestTime_List hereda el componente TimeID Time_List – de Time_List, por ello todos los elementos NPCID de QuestTime_List QuestTIme_List deben de estar presentes en Time_List La tabla SimpleDialogue_List hereda el componente Character_List – NPCID a Character_List, por ello todos los elementos SimpleDialogue_List NPCID de SimpleDialogue_List deben de estar presentes en Character_List

151

La tabla Dialogue_List hereda el componente NPCID de Character_List – Character_List, por ello todos los elementos NPCID de Dialogue_List Dialogue_List deben de estar presentes en Character_List Relación más compleja de todas, la tabla QuestTime_List, ConversationObjectives hereda todos sus componentes de Dialogue_List, Character_List otras tablas, QuestName y ObjectiveID son heredados de – QuestTime_List, NPCID es heredado de Character_List y ConversationObjectives_List Conversation ID es heredado de Dialogue_List La tabla Enemy_List hereda su variable ItemID de la Item_List – Enemy_List variable ItemID de Item_List, por ello todos los ItemID de Enemy_List deben estar presentes en Item_List La tabla QuestObjectiveEnemy_List hereda sus variables QuestTime_List – QuestName y ObjectiveID de la tabla QuestTime, por lo QuestObjectiveEnemy_List que el nivel de los enemigos cambiara de la misma forma que cambia el tiempo en el juego. La tabla QuestObjectiveEnemy_List hereda sus variables Enemy_List – de EnemyLevelLow y EnemyLevelMax de la variable QuestObjectiveEnemy_List level de Enemy_List, de tal forma que los niveles de los enemigos a determinar deben estar dentro de Enemy_List. Tabla 66: Relaciones entre tablas en Quito Quest (Ronquillo, 2019)

3.3.2 Niveles dentro Quito Quest El juego consta con un grupo relativamente alto de niveles para cumplir el objetivo de duración y poder dar suficientes áreas para explorar. Como se mencionó en la historia, y por su nombre, el juego toma lugar en la ciudad de Quito. El escenario del juego no solo fue seleccionado para realizar un juego dentro del país, también fue seleccionado para bajar los tiempos de diseño y desarrollo. Cada nivel toma lugar en un sitio en particular dentro de la ciudad, el diseño de niveles, así como el modelado de sus objetos está basado en cómo es esa locación, por lo que no fue necesario diseñar niveles desde cero. Si bien los niveles están basados en esos sitios, no se trata de recrearlos de forma exacta, utilizando una mera aproximación, tomando los elementos que más resalten, por lo que en varios niveles se omiten edificios o hasta calles enteras. Varios de los niveles del juego se repiten a través de las distintas épocas, facilitando aún más el desarrollo del juego al permitir realizar pequeños cambios a niveles, para simular las distintas ubicaciones en las distintas épocas, aumentando el contenido del juego de una manera relativamente sencilla. Nivel Época Descripción Primer nivel del juego, basado en el barrio de Carcelén al norte de Quito, utilizado para enseñar las mecánicas básicas al jugador, Carcelén 2019 también es el nivel más visitado a través del juego sirviendo como una especia de centro de operaciones al jugador. Nivel solo presente en la época de 2019, basado en el diseño más Colegio 2019 común de colegios en Quito, es donde los personajes principales de esa época estudian. Casa del personaje principal de la era, único nivel con diseño Casa 2019 original dará más contexto a lo que está pasando en el mundo de

152

juego, será desde este nivel donde el jugador podrá acceder a la época de 1999. Basado en la plaza grande en el centro de la ciudad, nivel Plaza 2019 visitado varias veces, alberga un personaje central en la historia del juego. Basado en el teatro universitario de la Universidad Central del Ecuador, alberga más personajes importantes en la historia, será Teatro 2019 desde este nivel donde el jugador podrá acceder a la época de 1989. Basado en la basílica del voto nacional en el centro de la ciudad, Basílica 2019 albergara personajes importantes en la historia del juego. Basado en el monumento a la mitad del mundo a las afueras de la ciudad, es el único nivel con una entrada, pero sin una salida, Mitad 2019 alberga a momentos importantes en la historia y solo puede ser visitado bajo ciertas condiciones. Nivel inicial para la época de 1999, basado en la facultad de ingeniería ciencias físicas y matemática de la Universidad Facultad 1999 Central del Ecuador, es donde los personajes principales de esa época estudian. Versión distinta del nivel teatro visto en 2019, alberga a más Teatro 1999 personajes importantes en la historia de 1999. Basado en la zona de la Iñaquito en el norte de la ciudad, alberga Iñaquito 1999 momentos importantes dentro de la historia de 1999. Versión reducida del nivel de 2019, utilizado por propósitos de Carcelén 1999 historia, es el nivel más pequeño del juego. Versión distinta del nivel casa visto en 2019, alberga a la familia de los personajes principales de la época, el diseño del nivel es Casa 1999 casi idéntico al visto en 2019, pero los elementos dentro del mismo son muy distintos. Versión del nivel mitad de 2019, funciona de la misma manera y Mitad 1999 cumple la misma función. Versión del nivel plaza de 2019, comparte la misma función. Plaza 1999 Este nivel es casi idéntico al de 2019, con mínimos cambios. Basado en la iglesia de San Francisco en el centro de la ciudad, Iglesia 1989 es el punto de partida para le poca de 1989. Versión del nivel basílica de 2019, alberga momentos Basílica 1989 importantes en la historia de 1989. Versión del nivel Iñaquito de 1999, contiene a personajes Iñaquito 1989 importantes dentro de la historia de 1989. Versión del nivel mitad visto en 2019 y 1999, funciona de la Mitad 1989 misma manera y cumple la misma función. Versión del nivel plaza visto en 2019 y 1999. Nivel casi idéntico Plaza 1989 a las dos épocas anteriores. Tabla 67: Niveles dentro de Quito Quest (Ronquillo, 2019)

3.3.2.1 Progresión entre niveles El jugador podrá explorar los niveles del juego según le parezca, no habrá una estructura lineal ya que los niveles del juego no pueden ser “ganados”, ya que esa estructura no sirve en

153 los JRPG, Sin embargo, si existirán algunas condiciones en situaciones específicas para que el jugador pueda entrar a ciertos niveles. Al inicio del juego el jugador solo tiene tres niveles a su disponibilidad, con el resto de los niveles de 2019 abriéndose luego de que el jugador cumpla ciertos objetivos. Esta limitante es aplicada para poder enseñarle al jugador las reglas del juego en un ambiente controlado, y para que este se adapte a cómo funciona el mundo juego su navegación antes de empezar correctamente. Demasiada libertad al inicio podría ser abrumadora y el jugador puede perderse. El nivel Mitad, como mencionado en la tabla de niveles, solo se abre al jugado al cumplirse ciertos objetivos, es usado como el fin del juego, o el punto de no regreso en las distintas épocas, ya que es el único nivel con una entrada, pero sin ninguna salida. Es el área más emblemática del juego, y en donde los elementos más importantes de la historia toman lugar, por lo que se le asignara poco uso, de tal forma que cada visita sea lo más interesante posible. De igual manera cada época solo será disponible al jugador luego de cumplir ciertos objetivos, al entrar a una, el jugador podrá luego de cumplir ciertos objetivos dentro de esa la época donde este. Esta división permitió dividir al juego en lo que llamados fases durante el desarrollo.

3.3.2.1.1 Fases en Quito Quest

Carcelen 2019 Plaza 2019 Teatro 2019 Carcelen 2019

•Colegio 2019 •Casa 2019 •Casa 2019

Ilustración 193: Esquema de la fase I en Quito Quest (Ronquillo, 2019) La fase introductoria del juego en mecánicas e historia. El jugador permanecerá “atrapado” en los primeros tres niveles (Carcelén, Colegio y Casa) hasta cumplir ciertas condiciones para que se habrá el resto del mundo. Aquí se le da pistas al jugador de dónde ir, y luego de que abra el juego este puede explorar libremente el mundo buscando más pistas. Puntualmente el jugador debe de visitar los niveles Plaza y Teatro, donde consigue misiones importantes y conoce a otros personajes importantes. Al cumplir estos objetivos el jugador debe regresar a los niveles iniciales, donde la segunda fase del juego empieza.

Facultad 1999 Iñaquito 1999 Carcelen 1999 Mitad 1999

•Casa 1999

Ilustración 194: Esquema de la fase II en Quito Quest (Ronquillo, 2019) En la fase II la historia del juego empieza en verdad, introduciendo a los antagonistas y aumentando la tensión. Ya que para esta época el jugador ya debe de estar acostumbrado a las mecánicas del juego, el mundo de 1999 está abierto desde el principio. De igual manera hay varios objetivos que cumplir, pero los más importantes a cumplir están en los niveles Facultad

154 e Iñaquito. La historia de 1999 no es dada de forma completa, es dejada inconclusa a propósito para dejar más intriga al jugador y motivarlo a seguir jugando.

Carcelen 2019 Plaza 2019 Basilica 2019 Teatro 2019

•Casa 2019 •Colegio 2019

Ilustración 195: Esquema de la fase III en Quito Quest (Ronquillo, 2019) Luego de completar los objetivos en 1999 el jugador regresa a 2019, la historia del juego ahora está en pleno apogeo y el número de enemigos dentro del mundo es grande. Con la información obtenida de 1999 el jugador busca más información sobre la organización que está afectando la ciudad, iniciando la era de 1989.

Iglesia 1989 Basilica 1989 Plaza 1989 Mitad 1989

Ilustración 196: Esquema de la fase IV en Quito Quest (Ronquillo, 2019) La segunda época de juego sirve para desarrollo en la historia más que nada, cambiando el contexto de esta e introduciendo a nuevos personajes y elementos, es la fase más corta del y de similar manera a la fase II, la historia de 1989 queda deliberadamente inconclusa.

Teatro 2019 Iglesia 2019 Plaza 2019 Mitad 2019

Ilustración 197: Esquema de la fase V en Quito Quest (Ronquillo, 2019) Última fase del juego, introduce los enemigos a los personajes e introduce los últimos aspectos de la historia. Termina parcialmente la historia del juego, pero deja el final ambiguo.

3.3.2.1.2 Interconexión de niveles Esta sección detalla como los niveles estas interconectados dentro de cada época, como se mencionó anteriormente el jugador podrá explorar de forma libre luego de cumplir una serie de objetivos.

155

Teatro 2019 Mitad 2019

Plaza 2019 Carcelén 2019

Basílica 2019 Casa 2019 Colegio 2019

Ilustración 198: Esquema de interconexión de niveles dentro de 2019 en Quito Quest (Ronquillo, 2019) Los niveles Casa 2019 y Colegio 2019 están únicamente disponibles desde el nivel Carcelén 2019, y el nivel Mitad 2019 está disponible desde el nivel Plaza 2019 al cumplir una serie de objetivos, fuera de esas excepciones el jugador puede ir desde cualquier nivel a cualquier otro nivel, de tal forma que el jugador puede elegir como explorar el mundo del juego.

Iñaquito Mitad 1999 1999

Carcelén Plaza 1999 1999

Facultad Teatro 1999 Casa 1999 1999

Ilustración 199: Esquema de interconexión de niveles dentro de 1999 en Quito Quest (Ronquillo, 2019) Igual que en 2019 el nivel Casa 1999 solo está disponible desde el nivel Carcelén 1999, de igual manera el nivel Facultad 1999 solo está disponible desde el nivel Teatro 1999 y el nivel Mitad siempre está disponible desde el nivel Plaza 1999 al cumplirse ciertas condiciones. El mundo de juego de esta época está disponible desde que el jugador llega.

156

Iñaquito Mitad 1989 1989

Plaza 1989 Basílica 1989

Iglesia 1989

Ilustración 200: Esquema de interconexión de niveles dentro de 1989 en Quito Quest (Ronquillo, 2019) El nivel Iglesia 1989 solo está disponible desde Basílica 1989, siendo el único disponible desde otro en esta época, además del nivel Mitad 1989 sigue la misma logia en las demás épocas. 1989 la más corta del juego, y por ello también usa el número de niveles menor.

3.3.3 Elementos de niveles Cada nivel del juego está conformado por unos elementos, estos incluyen a los distintos actores descritos en el capítulo anterior, así como otros elementos presentes en Unreal Engine 4, además de las siempre presentes mallas estáticas. Elemento Descripción Volúmenes que cubren los distintos niveles, son espacios Volumen de navegación que definen donde las inteligencias artificiales pueden moverse. Alteran la configuración visual de la escena, permiten alterar la imagen del juego de tal forma que se pueda Volumen de postproducción recrear la imagen de una fotografía antigua o la de un video de VHS Volúmenes que bloquean el movimiento de actores, usado para bloquear ciertas partes del nivel para el jugador, así Volumen de bloqueo como para bloquear interacción entre ciertos actores dentro del juego, como la de los personajes no jugables y los actores que conforman el sistema de tráfico Personaje Actor que controla el jugador. NPC_Type_A Personaje no jugable más simple de todos. NPC_TypeB_BP nunca estará solo dentro de un nivel, siempre cargara un actor hijo, en este caso este es un NPC_TypeB_BP personaje no jugable con el que se puede conversar, es decir tiene al actor InteractableObject_BP Enemy_BP Enemigos dentro del juego. LocationMarker Marcadores de objetivos dentro de niveles. Light Actores que generan luces dentro de niveles.

157

Actores que reproducen los sonidos y música de fondo Sound dentro de niveles. LevelLoader Actores que pueden llevar al jugador a otros niveles. Store Actores que albergan tiendas dentro del juego. Un sistema en lugar de un actor, los actores que Sistema de tráfico conforman un sistema de tráfico nunca están por sí solos, siempre se utiliza el sistema entero dentro de un nivel. Tabla 68: Listado de elementos dentro de niveles en Quito Quest (Ronquillo, 2019)

158

Sistema Sistema tráfico de

Store

LevelLoader

Sound

Light

Location Marker

Enemy

NPC_Type_B

NPC_Type_A

Personaje

Volumen Volumen de bloqueo

Volumen de de Volumen postproducción

Volumen Volumen de navegación

Casa 2019 Casa 1999 Casa

Plaza 2019 Plaza 1999 Plaza 1989 Plaza

Mitad 2019 Mitad 1999 Mitad 1989 Mitad

Teatro 1999 Teatro

Teatro 2019 Teatro

Iglesia 1998 Iglesia

Colegio 2019 Colegio

Basílica 2019 Basílica 1989 Basílica

Iñaquito 1999 Iñaquito 1989 Iñaquito

Facultad 1999 Facultad

Carcelén 2019 Carcelén 1999 Carcelén

Tabla 69: Distribución de elementos dentro de niveles en Quito Quest (Ronquillo, 2019)

159

3.4 Pruebas y resultados 3.4.1 Pruebas internas 3.4.1.1 Configuración gráfica

Ilustración 201: Resultados de los cambios de la configuración gráfica para la recreación de las tres eras (Ronquillo, 2019) Se pudo realizar la configuración grafica para recrear las tres eras de manera exitosa, la ilustración superior contiene dos ejemplos mostrando la configuración para 1989, 1999 y 2019 respectivamente. El uso de volumen de post procesamiento, así como modificación a Main_Widget dio los resultados esperados, aun cuando el efecto puede ser considerado demasiado fuerte. También se puede observar como el menú por año cambia según la época en la que este el jugador, funcionando tal y como fue desarrollado.

160

Ilustración 202: Resultados de cambios de la configuración grafica del juego (Ronquillo, 2019) La ilustración superior muestra la configuración de gráficos del juego al colocar a los distintos componentes todos en LOW, HIGH y ULTRA respectivamente, se puede apreciar claramente como mejoran los gráficos del juego al subir la configuración. Como fue mencionado anteriormente estos cambios se guardan de forma automática y aplican a todo el juego, de tal forma que al cambiar la configuración desde este menú todo el juego se verá con esa configuración. Vale recalcar que todos los resultados después de este punto fuero obtenidos con la configuración grafica en ULTRA, de tal forma que muestran el juego en su mejor estado gráfico posible.

161

3.4.1.2 Movimiento de actores 3.4.1.2.1 Personajes no jugables (NPCs)

Ilustración 203: Resultados de personajes no jugables (Ronquillo, 2019) Todos los personajes no jugables también exhibieron el comportamiento deseado, con los actores NPC_TypeA_BP y NPC_TypeB_BP moviéndose de forma aleatoria dentro del mundo de juego, los actores tipo NPC_TypeB_BP también reactuaron únicamente a interacción con el jugador quedando inmóviles mientras se reproduce una conversación. Los actores Enemy_BP también exhibieron el comportamiento deseado, buscando al jugador dentro del nivel, y en caso de percibirlo tratando de perseguirlo para inicializar el combate. Los actores hacen caso omiso los unos de los otros, aun en un ambiente con varios actores, los actores Enemy_BP solo persiguen al jugador, y los actores NPC_TypeB_BP hacen caso omiso a contacto o interacción con cualquier otra clase de actor.

162

3.4.1.2.2 Sistema de tráfico

Ilustración 204: Resultados del sistema de tráfico (Ronquillo, 2019) Los resultados del sistema de tráfico también fueron favorables, con todos sus actores funcionando de forma correcta. Los vehículos siguen su ruta designada, no colisionan entre sí ni con el jugador y obedecen a los estados de los semáforos, además los actores ClonadorCarros_BP y DestructorCarros_BP también cumplen sus funciones satisfactoriamente, instanciando a vehículos de forma aleatoria y eliminando respectivamente. Se pudo observar, sin embargo, ciertos estragos donde el tráfico quedaba completamente inmóvil por cierto tiempo, pero debido al tiempo de vida de los actores Car_BP esto se solucionaba solo, ya los actores desaparecen.

163

3.4.1.3 Interacción con actores 3.4.1.3.1 Sistema de misiones

Ilustración 205: Resultados del sistema de misiones (Ronquillo, 2019) El sistema de misiones, así como sus sistemas asociados, funcionaron de forma correcta, el jugador puede iniciar una misión al cumplir ciertas condiciones y debe de cumplir sus objetivos en orden, al cumplir una misión podrá obtener otra misión siempre y cuando esa misión sea la siguiente. Dentro de la ilustración superior se puede apreciar este proceso, también se ve como cuando al cumplir un objetivo la configuración de luces del mundo fue modificada, este elemento funcionó en todos los casos, así como la posición de otros actores al cumplir ciertos objetivos. También se puede observar a Missions_Widget en pantalla, mostrando los datos de las misiones cumplidas. Se probó que se pueda abrir, cerrar y navegar por todas las interfaces del juego, obteniendo resultados positivos en todas las ocasiones.

164

3.4.1.3.2 Conversación

Ilustración 206: Resultados del sistema de conversación (Ronquillo, 2019) El sistema de conversación también dio resultados favorables después de varias pruebas, se pudo observar cómo se reproducía una conversación de varias líneas tal y como fue desarrollado, así como que conversación debe de reproducirse según los objetivos que haya completado el jugador. El comportamiento de Dialogue_Widget también fue el esperado, desplegando siempre el texto correcto, así como identificando claramente al personaje que está hablando.

3.4.1.3.3 Tienda

Ilustración 207: Resultados del sistema de tienda (Ronquillo, 2019) El sistema de tiendas también funcionó de manera correcta, se pudo comprar y vender ítems según se quiso, con Store_Widget siempre mostrando los datos correctos del ítem seleccionado,

165 además se pudo utilizar ítems y cambiar atributos sin ningún problema. Se pudo comprobar de igual manera que no se pueda usar ni vender a ítems importantes, con todo el sistema, como fue descrito anteriormente, funcionando tal como había sido planeado. 3.4.1.4 Combate

Ilustración 208: Resultado del sistema de combate (Ronquillo, 2019) Por ser el sistema más complejo y extenso del juego fue donde se necesitaron también más pruebas y correcciones. Después de varias modificaciones se obtuvieron resultados óptimos, con el sistema de combate funcionando tal y como se planeó, repartiendo las cartas iniciales para definir quien las repartirá en el primer turno, permitiendo que el jugador como los enemigos puedan jugar e identificando correctamente caídas, llevada de cartas, sumas, secuencias y limpias. También se pudo contabilizar el montón de cada equipo de manera exitosa, así como de subir el nivel de los miembros del party actual al terminar el combate, si fuese el caso.

3.4.2 Pruebas externas Se realizó una encuesta con un grupo de prueba que consistió en 12 estudiantes del Taller de Verano de desarrollo de videojuegos, que tomo lugar en el Centro de Física de la Universidad Central del Ecuador durante agosto de 2019. El objetivo de esta encuesta fue conocer opiniones del juego fuera del equipo de desarrollo, además de obtener opiniones sobre el diseño de los sistemas del juego más que su funcionalidad.

166

A que grupo pertenece de edad pertenece

25% 15-20 años 42% 20-25 años 25-30 años 33%

Ilustración 209: División de grupos de edades del grupo de prueba (Ronquillo, 2019) La mayor parte del grupo de prueba pertenece a la demografía donde los JRPGs son más populares, por lo menos en Japón, donde esta clase de juegos es más popular con audiencias jóvenes, en particular estudiantes, sea de secundaría o universidad. Debido al compromiso que estos juegos requieren (por su larga duración) suelen perder popularidad a mayor edad.

Con que género se identifica

25% Masculino Femenino 75%

Ilustración 210: División por genero del grupo de prueba (Ronquillo, 2019) Los JRPGs tienen popularidad con ambos géneros, si bien, cierto tipo de JRPGs pueden ser más popular en un género que en otro (en particular según su estilo gráfico) ambos géneros disfrutan esta clase de juegos. El grupo de encuesta encaja en la clase de audiencia que disfruta un JRPG, en edad y género.

167

Plataforma preferida para jugar

DISPOSITIVOS CONSOLA CONSOLA PORTÁTIL COMPUTADORA MÓVILES

Ilustración 211: Plataforma preferida para jugar en el grupo de prueba (Ronquillo, 2019) Por la mayor parte de su historia los JRPGs más populares fueron desarrollados para consolas y consolas portátiles, no llegando a computadores caseras ni dispositivos móviles hasta años más recientes y donde no tienen la misma popularidad, aún con más plataformas los JRPGs se mantienen más populares en consolas en occidente y en consolas portátiles en Japón. Los resultados aquí no fueron tan favorables, ya que la mayor parte del grupo de encuesta prefiere jugar en computadora, y ninguno de ellos prefiere utilizar una consola portátil.

Experiencia con RPGs o JRPGs

25% 25% Mucha Media Poca 17% Ninguna 33%

Ilustración 212: Experiencia con RPGs o JRPGs en el grupo de prueba (Ronquillo, 2019) Experiencia en JRPGs no es enteramente necesaria para disfrutar este juego, pero sirve para que se pueda apreciar los sistemas de juego de mejor manera, al tener una referencia. El grupo de encuesta tuvo una buena división entre las personas que tienen y no tienen experiencia con este tipo de juego, de tal forma que se obtuvieron resultados desde ambas perspectivas.

168

Que tan interesante le pareció el concepto del juego 0%

17% Mucho Medio 50% Poco 33% Nada

Ilustración 213: Interés por el concepto del juego en el grupo de prueba (Ronquillo, 2019) Después de terminar las preguntas para obtener información sobre el grupo de prueba, se empezó a preguntar sobre su opinión de los distintos sistemas del juego. La mayoría de los encuestados dio resultados positivos al concepto del juego, con más de la mitad tener mucho interés por él.

Que tan factible le parece desarrollar juegos de rol en el país

0% 25% Mucho 33% Medio Poco Nada 42%

Ilustración 214: Factibilidad de desarrollar juegos de rol en el país (Ronquillo, 2019) Luego de tener experiencia con el juego, la mayor parte del grupo de encuesta dio resultados positivos sobre el desarrollo de más juegos de rol localmente, se puede apreciar que la misma cantidad que afirma que es poco factible desarrollar más juegos de rol son el mismo que afirmó no tener ninguna experiencia con juegos de rol. Puede ser el caso que se grupo de personas no fueron convencidas por la demostración del juego.

169

Que tanto le interesa ver el juego terminado

17% 0% Mucho 41% Medio Poco 42% Nada

Ilustración 215: Interés por ver el juego terminado por el grupo de prueba (Ronquillo, 2019) El interés por ver el juego terminado fue uno de los resultados más positivos, con solo una pequeña minoría afirmando poco interés por el juego. Debido a la duración que pueden tener esta clase de juegos, y el trabajo necesario para su desarrollo este resultado es muy importante en, ya que nos dice que el diseño de juego es correcto y sirve para motivación de seguir trabajando.

Que tanto le gusto el sistema de conversación

0% 25% Mucho Medio Poco 67% Nada

Ilustración 216: Gusto por el sistema de conversación en el grupo de prueba (Ronquillo, 2019)

170

Que tanto le gusto el sistema de tienda

8% 0% Mucho 34% Medio Poco 58% Nada

Ilustración 217: Gusto por el sistema de tienda en el grupo de prueba (Ronquillo, 2019) Los resultados sobre que tanto le gusto los distintos sistemas del juego a los encuestados dio resultados relativamente similares, con la mayoría de ellos expresando tener un gusto medio sobre los sistemas de conversación y tienda. Sin embargo, los resultados son aún positivos ya que solo un 8%, en ambos casos, expresaron tener poco gusto por dichos sistemas.

Que tanto le gusto el sistema de combate

0% Mucho 42% Medio 50% Poco Nada 8%

Ilustración 218: Gusto por el sistema de combate en el grupo de prueba (Ronquillo, 2019) Finalmente, en las preguntas por el sistema de combate, los resultados fueron muy polarizantes, si bien un 50% de los encuestados expresaron mucho gusto por el sistema de combate dentro del juego, un porcentaje cercano de 42% expresaron poco gusto por este sistema.

171

Cree que es factible utilizar el sistema de combate en un juego entero

0% 25% Mucho 33% Medio Poco Nada 42%

Ilustración 219: Factibilidad del sistema de combate implementado en un juego entero por el grupo de prueba (Ronquillo, 2019) Estos resultados son similares a los vistos en las ilustraciones 210 & 212, con un 25% de los encuestados dando resultados negativos. Se puede considerar que es el grupo que no tiene experiencia con RPGs y puede que no haya disfrutado del combate en base a turnos, mientras que los que tienen experiencia con JRPGs, y probablemente tienen experiencia con ese combate, dieron resultados favorables.

172

4. Capítulo IV: Conclusiones y recomendaciones

4.1 Conclusiones  La curva de aprendizaje de Unreal Engine 4 fue más fuerte de los esperado, termino siendo un gran obstáculo ya que produjo que el desarrollo, en su etapa temprana, fuera hecho de forma muy lenta. Sin embargo, la facilidad del motor permitió que una vez que se entró en ritmo con su funcionalidad se pudo agilitar mucho el trabajo. Por ejemplo, desarrollar el sistema entero de conversaciones tomo más de un mes, sin embargo, al final del desarrollo, el sistema de combate, que es el sistema más complejo del juego, tomo únicamente 2 semanas.  Se sobreestimó la dificultad en desarrollar un juego JRPG en el tiempo dado, no solo en diseñar todos los sistemas sino también implementarlos dentro del programa y hacer la experiencia interesante para el jugador. El problema apareció ya que esta clase de juegos tiene relaciones tan complejas entre sus sistemas que fue abrumador durante el desarrollo, de tal forma que no se pudieron obtener los resultados óptimos.  Si bien la implementación del juego de cartas 40 como combate en un juego JRPG fue una idea novedosa, se encontraron problemas al momento de probar los sistemas. Ya que el juego depende de suerte además de habilidad, hubo partidas que duraban demasiado y se podría volver aburrido al jugarlo por mucho tiempo.  La implementación de utilizar tres eras dio resultados favorables al momento de alargar la duración del juego, si bien los cambios fueron menores, el cambio visual es lo suficientemente interesante para mitigar.  Los resultados de las pruebas de los sistemas de juego estuvieron por debajo de lo esperado, al platicar con el grupo de encuesta mencionaron que si bien los sistemas funcionaron correctamente las interfaces eran demasiado simples y planas, se esperaría para futuro poder mejorar la estética del juego, particularmente en ese campo.  La velocidad del juego en algunos casos fue demasiado rápida, con algunos usuarios teniendo problemas controlando a los personajes o tratando de interactuar con elementos del mundo de juego. Hubo también problemas donde los jugadores se perdían, no sabían que hacer dentro del juego para continuar.

4.2 Recomendaciones  Durante el transcurso de este proyecto se aprendió a utilizar Unreal Engine 4 mientras se desarrolló el juego, como se mencionó anteriormente esto causó problemas. Es recomendable ganar conocimientos del programa de desarrollo, así como de su flujo de trabajo anteriormente, además de trabajar con un equipo adecuado para el desarrollo, en especial un monitor de gran tamaño y buena resolución.  Otro problema encontrado es que después de semanas de desarrollo una buena cantidad de trabajo tuvo que ser descargada y reiniciado ya que su funcionalidad era incompatible con la funcionalidad de otros sistemas de juego desarrollados posteriormente, si bien esto continua con el punto anterior, también es recomendable esquematizar bien como funcionara el programa antes de desarrollarlo, mucho trabajo tuvo que ser desperdiciado por falta de planeamiento durante este proyecto.

173

 Tener una ambición más clara es otra gran recomendación, inicialmente se esperaba realizar muchas más tareas durante este proceso, pero por falta de tiempo y conocimiento muchas de ellas tuvieron que ser desperdiciadas durante el desarrollo.  Optimizar el uso de recursos, así como grabar constantemente es otra gran recomendación, en ocasiones la computadora de desarrollo se colgó por el gran peso del motor que genera cuando está trabajando, y muchas otras ocasiones el programa colapso, perdiendo horas de valioso progreso.  Ser más tolerante a las críticas, algunos de los resultados de la encuesta pudieron ser notados en la etapa temprana de desarrollo, sin embargo, por no hacer caso a críticas negativas al proyecto los resultados finales fueron debajo de lo esperados.

174

BIBLIOGRAFÍA

Adams, E. (2014). Fundamentals of Game Design. 3. In E. Adams, Fundamentals of Game Design. 3 (p. 251). Berkley, California: Peachpit. Aleem, S., Capretz, L., & Ahmed, F. (2016). Game development software engineering process life cycle: a systematic review. Journal of Software Engineering Research and Development, 4-6. Andagoya, S. (2016). Desarrollo del modelado, animación y texturizado de los diferentes actores y escenarios que intervienen en el videojuego Llumpak. Quito: UCE. Arruelas, E. (2017). Creación de un videojuego multiplataforma 2.5d en unity 3d y blender. Quito: UCE. Barros, R., Rodriguez, L. d., & Barros, C. (2015). El juego del cuarenta, una opción para la enseñanza de las matemáticas y las ciencias sociales en Ecuador. Revista Universidad y Sociedad Volumen 7, 137-144. Bates, B. (2004). Game Design (2nd ed.). Boston, Estados Unidos: Thomson Course Technology. Blitz game studio. (n.d.). Blitz game studio. Retrieved from Game Development: http://www.blitzgamesstudios.com/blitz_academy/game_dev Bounani, O. (2015, Julio 24). envatotuts+. Retrieved from How to Fund Your Games By Creating and Selling Game Assets: https://gamedevelopment.tutsplus.com/articles/how-to-fund-your-games-by-creating- and-selling-game-assets--cms-24380 Brewer, N. (2016, Julio 7). InSight. Retrieved from GOING ROGUE: A BRIEF HISTORY OF THE COMPUTERIZED DUNGEON CRAWL: https://insight.ieeeusa.org/articles/going-rogue-a-brief-history-of-the-computerized- dungeon-crawl/ Brid, R. (2018, Octubre 25). Medium. Retrieved from Introduction to Decision Trees: https://medium.com/greyatom/decision-trees-a-simple-way-to-visualize-a-decision- dc506a403aeb Brown, M. (2017, Mayo 31). Youtube. Retrieved from What Makes Good AI? | Game Maker's Toolkit: https://www.youtube.com/watch?v=9bbhJi0NBkk Capel, C. (2019, Enero 25). GameWatchers. Retrieved from RESIDENT EVIL 2 REMAKE DISCARD ITEMS - WHEN CAN YOU SAFELY DISCARD ITEMS?: https://www.gamewatcher.com/guides/resident-evil-2-remake-discard-items-when- can-you-safely-discard-items Cardsgames. (n.d.). Manual de Cuarenta. Retrieved from Cardsgames: http://cardsgames.htmlplanet.com/manual.html Chandler, H. (2010). Game Production Handbook. Sudbury, Canada: Johns and Bartletts.

175

Crytek. (n.d.). CryEngine. Retrieved from CryEngine: https://www.cryengine.com/ D' Argenio, A. (2018, Julio 10). GameCrate. Retrieved from STATISTICALLY, VIDEO GAMES ARE NOW THE MOST POPULAR AND PROFITABLE FORM OF ENTERTAINMENT: https://www.gamecrate.com/statistically-video-games-are-now- most-popular-and-profitable-form-entertainment/20087 De la Cruz, D. (2016). Inteligencia artificial aplicada al videojuego Llumpak desarrollado en plataforma android. Quito: UCE. De Pablos, T. (n.d.). Exclusive mechanics: History of the Videogame industry and its relation with cultural distinctions between Game Genres. Barcelona, España: Universitat Autónoma de Barcelona. Dominguez, E., & Lima, F. (2019). Desarrollo de un videojuego 3D para el aprendizaje de los movimientos y fuerzas para. Quito: UCE. Emaseo. (2012). Emaseo. Retrieved from Guardian de tu cuadra: http://www.emaseo.gob.ec/index.php/guardian-de-tu-cuadra Epic Games. (n.d.). Unreal Engine. Retrieved from Features: https://www.unrealengine.com/en-US/features Epic Games. (n.d.). Unreal Engine 4 Documentation. Retrieved from Blueprints Visual Scripting: https://docs.unrealengine.com/en-US/Engine/Blueprints/index.html Escobar, E. (2019). Desarrollo del modelado de escenarios, animacion de sprites 2.5D, música y efectos de sonido para un video juego de rol llamado "Quito Quest". Quito: UCE. Extra Credits. (2012, Mayo 20). Youtube. Retrieved from Western RPGs vs. JRPGs- I: What makes them different?: https://www.youtube.com/watch?v=l_rvM6hubs8 Findley, M. (2011, Mayo 14). How RPGs Were A 30-Year Detour: Matt Findley On Hunted: The Demon's Forge. (C. Nutt, Interviewer) Freaky Creations. (2014). Freaky Creations. Retrieved from Freaky Creations: https://freakycreations.net/ GameDesign. (2019, Junio 2). The Top 10 Video Game Engines. Retrieved from GameDesign: https://www.gamedesigning.org/career/video-game-engines/ Gamefaqs. (n.d.). Gamefaqs. Retrieved from Metroid Prime – Images: https://gamefaqs.gamespot.com/gamecube/447244-metroid-prime/images/27 GDC Vault. (n.d.). GDC Vault. Retrieved from 'ARMS': Building 'Mario Kart 8' Insights into a Showcase Nintendo Switch Fighter: https://www.gdcvault.com/play/1024907/- ARMS-Building-Mario-Kart GDC Vault. (n.d.). GDC Vault. Retrieved from Change and Constant: Breaking Conventions with 'The Legend of Zelda: Breath of the Wild': https://www.gdcvault.com/play/1024562/Change-and-Constant-Breaking- Conventions

176

Geig, M. (2013, Diciembre 2019). InformIt. Retrieved from Working with Models, Materials, and Textures in Unity Game Development: http://www.informit.com/articles/article.aspx?p=2162089&seqNum=2 Giant Bomb. (2008, Julio 31). Giant Bomb. Retrieved from Dragon Warrior's Galleries: https://www.giantbomb.com/images/1300-422140 Giant Bomb. (2008, Julio 24). Giant Bomb. Retrieved from The Legend of Zelda's galleries: https://www.giantbomb.com/images/1300-269366 Giant Bomb. (2008, Agosto 1). Giant Bomb. Retrieved from Dragon Warrior III's galleries: https://www.giantbomb.com/images/1300-439822 Giant Bomb. (2008, Julio 23). Giant Bomb. Retrieved from Pokémon Emerald's galleries: https://www.giantbomb.com/images/1300-252036 Giant Bomb. (2008, Julio 21). Giant Bomb. Retrieved from Dragon Quest VIII: Journey of the Cursed King's galleries: https://www.giantbomb.com/images/1300-200312 Giant Bomb. (2010, Abril 20). Giant Bomb. Retrieved from pedit5's galleries: https://www.giantbomb.com/images/1300-1343262 Giant Bomb. (2013, Agosto 31). Giant Bomb. Retrieved from Shin Megami Tensei: Persona 3 FES's galleries: https://www.giantbomb.com/images/1300-2538663 Giant Bomb. (2014, Enero 28). Giant Bomb. Retrieved from The Dragon & Princess' galleries: https://www.giantbomb.com/images/1300-2595636 Giant Bomb. (2015, Enero 6). Giant Bomb. Retrieved from Superhot's galleries: https://www.giantbomb.com/images/1300-2714867 Giant Bomb. (2015, Agosto 2). Giant Bomb. Retrieved from Overwatch's galleries: https://www.giantbomb.com/images/1300-2770838 Giant Bomb. (2016, Mayo 5). Giant Bomb. Retrieved from Persona 5's galleries: https://www.giantbomb.com/images/1300-2848765 Giant Bomb. (2016, Agosto 6). Giant Bomb. Retrieved from Dragon Quest XI: Echoes of an Elusive Age's galleries: https://www.giantbomb.com/images/1300-2875620 Giant Bomb. (2018, Abril 25). Giant Bomb. Retrieved from Octopath Traveler's galleries: https://www.giantbomb.com/images/1300-3016874 Giant Bomb. (2019, Enero 24). Giant Bomb. Retrieved from Battlefield 1's galleries: https://www.giantbomb.com/images/1300-3077337 Gil, C., & Alberto, R. (2004). Estructura básica del proceso unificado de desarrollo de software. Universidad ICESI. Graham, D., & McShaffry, M. (2012). Game Coding Complete, Fourth Edition . Boston, Estados Unidos: Delmar Cengage Learning. Gutierrez, D. (2011). Métodos de desarrollo de software. Mérida, Venezuela: Universidad de los Andes.

177

Hamilton, K. (2013, Marzo 15). Kotaku. Retrieved from Turn-Based Combat Is The Best Kind Of Combat: https://kotaku.com/turn-based-combat-is-the-best-kind-of-combat- 5990831 Hancock, H. (2002, Abril 2). Gamasutra. Retrieved from Better Game Design Through Cutscenes: https://www.gamasutra.com/view/feature/131410/better_game_design_through_.php Hendrick, A. (2009, Junio 26). MMO Tidbits. Retrieved from How MMOs Designed Away Social Gameplay: https://mmotidbits.com/2009/06/ How to make RPGs. (n.d.). How to make RPGs. Retrieved from What is an Action RPG?: http://howtomakeanrpg.com/a/what-is-an-action-rpg.html Hunicke, R., Zubek, R., & Leblanc, M. (2004). MDA: A Formal Approach to Game Design and Game Research. Proceedings of the Challenges in Games AI Workshop, Nineteenth National Conference of Artificial Intelligence. San Jose, Estados Unidos: AAAI Press. Iamag. (n.d.). Iamag. Retrieved from THE ART OF GOD OF WAR 4 : 30 CONCEPT ART AND CHARACTER DESIGNS: https://www.iamag.co/the-art-of-god-of-war-4-30- concept-art-and-character-designs/ IGN. (2017, Febrero 18). IGN. Retrieved from https://www.ign.com/articles/2017/02/18/new- kingdom-hearts-3-final-fantasy-vii-remake-screenshots-revealed: https://www.ign.com/articles/2017/02/18/new-kingdom-hearts-3-final-fantasy-vii- remake-screenshots-revealed Janovsky, A. (2018, Marzo 9). Study. Retrieved from Character in Literature: Definition, Types & Development: https://study.com/academy/lesson/character-in-literature- definition-types-development.html Kadokawa Games. (n.d.). RPG Maker. Retrieved from RPG Maker: http://www.rpgmakerweb.com/ Keo, M. (2017). Graphical Style in Video Games. Hämeenlinna, Finlandia: Häme University of Applied Sciences. Konami. (2016). The Art of Metal Gear Solid V. Milwaukie, Estados Unidos: Dark Horse Books. Larman, C., & Basili, V. (2003). Iterative and incremental developments a brief history. Computer (Volume 36, Issue 6), 2-11. LevelSkip. (2016, Abril 14). LevelSkip. Retrieved from What Makes a Great Role-Playing Video Game?: https://levelskip.com/rpgs/good-rpg Lombard Hill Group. (n.d.). Lombardhill. Retrieved from What is Software Reuse?: http://lombardhill.com/what_reuse.htm Martinez, A. (2018, Noviembre 26). Fiestas de Quito: ¿Cómo jugar 40 (Cuarenta)? Retrieved from MetroEcuador:

178

https://www.metroecuador.com.ec/ec/entretenimiento/2018/11/26/fiestas-de-quito- como-jugar-cuarenta.html McGrath, J. (2011, Abril 3). Doppler Interactive. Retrieved from The Game Development Lifecycle - A theory for the extension of the Agile project methodology": http://blog.dopplerinteractive.com/2011/04/gamedevelopment- Miyamoto, S. (1989). Discussion Between Miyamoto & Horii. (Y. Horii, Interviewer) Neto, B., Lima, C., Fernandes, L., & De Souza, J. (2010). Developing Digital Games through Software Reuse. Journal of Information Processing Systems, 219-234. NEXT Generation. (1996). The Next Generation 1996 Lexicon A to Z. NEXT Generation, 30. Nintendo. (2015, Septiembre 14). Youtube. Retrieved from Nintendo Digital Event @ E3 2015: https://www.youtube.com/watch?v=C73f618-3pk Nixon, D. (2017). Unreal Engine 4 for Beginners. Luquinox. Owen, P. (2016, Marzo 9). The Wire. Retrieved from What Is A Video Game? A Short Explainer: https://www.thewrap.com/what-is-a-video-game-a-short-explainer/ Oxland, K. (2004). In K. Oxland, Gameplay and design (pp. 128-139). Boston, Estados Unidos: Addison Wesley. Panumate, C., Xiong, S., & Iida, H. (2015). An Approach to Quantifying Pokemon's Entertainment Impact with Focus on Battle. 2015 3rd International Conference on Applied Computing and Information Technology/2nd International Conference on Computational Science and Intelligence (ACIT-CSI), (pp. 60-66). Parish, J. (2016, Junio 7). USGamer. Retrieved from The History of RPGs: How Dragon Quest Redefined a Genre: https://www.usgamer.net/articles/the-history-of-rpgs-how- dragon-quest-redefined-a-genre Pepe, F. (2017, Septiembre 22). Gamasutra. Retrieved from The Art of Turn-Based RPGs I: Menu-based battles: https://www.gamasutra.com/blogs/FelipePepe/20170922/305783/The_Art_of_TurnBa sed_RPGs_I_Menubased_battles.php Picard, M. (2013). The Foundation of Geemu: A Brief History of Early Japanese video games. Game Studies: the international journal of. Volume 13, Issue 2, 13. Retrieved from The Foundation of Geemu: A Brief History of Early Japanese video games. Ramadan, R., & Widyani, Y. (2013). Game development life cycle guidelines. 2013 International Conference on Advanced Computer Science and Information Systems (ICACSIS) (pp. 95-100). Bali, Indonesia: IEEE. Ramdas, S. (2017, Mar 16). Youtube. Retrieved from The History of RPGs Ep. 1 Remastered | Dragon Quest (Dragon Warrior) Analysis (1986): https://www.youtube.com/watch?v=qBnkTMqQfb0 Rogers, S. (2014). Level Up! The Guide to Great Video Game Design. Hoboken, Estados Unidos: John Wiley & Sons.

179

Ronquillo, D. (2019). DISEÑO GENERAL, ESCRITURA, DESARROLLO Y PROGRAMACION DE UN VIDEOJUEGO DE ROL JRPG LLAMADO QUITO QUEST. Quito: UCE. Ryan, T. (1999, Octubre 19). Gamasutra. Retrieved from The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and Proposal: https://www.gamasutra.com/view/feature/3384/the_anatomy_of_a_design_document_ .php Santillán, L. (2016). Programación del videojuego la dama. Quito: UCE. Schell, J. (2008). The Art of Game Design: A Book of Lenses. Boca Raton, Estados Unidos: CRC Press. Schreier, J. (2012, Junio 29). Kotaku. Retrieved from Why Do People Care About JRPGs?: https://kotaku.com/why-do-people-care-about-jrpgs-5921080 Schrier, K., Torner, E., & Hammer, J. (2018). Worldbuilding in Role-Playing Games. In S. Deterding, & J. Zagal, Role-Playing Game Studies (pp. 349-363). Nueva York, Estados Unidos: Routledge. Slopper, T. (2015, Agosto). Sloperama. Retrieved from Sample outline for a Game Design Document: http://www.sloperama.com/advice/specs.html Spriters Resource. (n.d.). Spriters Resource. Retrieved from Rocket Knight Adventures: https://www.spriters-resource.com/genesis_32x_scd/rocketkadventures/sheet/29167/ Staats, R. (n.d.). Designing RPG Scenarios. Columbus, Estados Unidos: Zhalindor. StemChallenge. (n.d.). StemChallenge. Retrieved from Game Design Documents: https://stemchallenge.org/resources/game-design-documents/# Takizawa, H. (1990). Dragon Quest e no Michi. Tokyo, Japón: Enix. Taylor, C. (1995). FALLOUT. Technopedia. (n.d.). Technopedia. Retrieved from Role Playing Game: https://www.techopedia.com/definition/27052/role-playing-game-rpg Texture Resource. (n.d.). Texture Resource. Retrieved from Grand Theft Auto: Vice City: https://www.textures- resource.com/playstation_2/grandtheftautovicecity/texture/6772/?source=genre Tran, T. (2017, Enero 17). Unreal Engine 4 Tutorial for Beginners: Getting Started. Retrieved from Raywenderlich: https://www.raywenderlich.com/771-unreal-engine-4- tutorial-for-beginners-getting-started TVTropes. (n.d.). TVTropes. Retrieved from Turn-Based Combat: https://tvtropes.org/pmwiki/pmwiki.php/Main/TurnBasedCombat Unity Technologies. (n.d.). Unity. Retrieved from Unity: https://unity.com/es Wadstein, M. (2015, Diciembre 9). Youtube. Retrieved from WTF Is? Volume - Nav Mesh Bounds in Unreal Engine 4: https://www.youtube.com/watch?v=hE7aMBeT53o

180

Wadstein, M. (2015, Octubre 28). Youtube. Retrieved from WTF Is? A Struct: https://www.youtube.com/watch?v=2-tCCtkX1sk Wadstein, M. (2015, September 28). Youtube. Retrieved from WTF Is? Blueprint Interface: https://www.youtube.com/watch?v=G_hLUkm7v44 Wadstein, M. (2015, Noviembre 1). Youtube. Retrieved from HTF do I? Use the GameInstance Object in Unreal Engine 4: https://www.youtube.com/watch?v=5w594D3qtLs Wadstein, M. (2015, Octubre 26). Youtube. Retrieved from HTF do I? Use the SaveGame Object in Unreal Engine 4: https://www.youtube.com/watch?v=_4usRrTiqak Wadstein, M. (2015, Septiembre 21). Youtube. Retrieved from WTF Is? An Enum: https://www.youtube.com/watch?v=yVx8sTO43gc Wadstein, M. (2017, Abril 27). Youtube. Retrieved from WTF Is? Data Table in Unreal Engine 4 ( UE4 ): https://www.youtube.com/watch?v=nt1hlJO-DPo Welty, P. (2008, Junio 15). Cuarenta. Retrieved from Pagat: https://www.pagat.com/fishing/cuarenta.html YoYo Games. (n.d.). YoYo Games. Retrieved from YoYo Games: https://www.yoyogames.com/ Yu, D. (2018). Game A.I. Made Easy: Designing Agents: With Unity3D Examples. Publicacion independiente.

181

ANEXOS ANEXO A: Requisitos técnicos ANEXO B: Secuencia de eventos en Quito Quest ANEXO C: Diseño de niveles en Quito Quest ANEXO D: Listado de misiones en Quito Quest ANEXO E: Listado de objetivos en Quito Quest ANEXO F: Capturas de desarrollo de Quito Quest ANEXO G: Capturas de juego empaquetado ANEXO H: Capturas del juego publicado ANEXO I: Encuesta realizada

ANEXO A: Requisitos técnicos Característica Requisitos mínimos Requisitos recomendados Sistema operativo Windows 10 64-bits Windows 10 64-bits Procesador AMD FX-4350 / Intel i5-3210 AMD Ryzen 3 1200 / Intel i5-6400 Memoria RAM 4GB 8GB AMD Radeon R7 260X (2GB Radeon RX 470 (4GB de VRAM) Tarjeta de video de VRAM) / NVIDIA GeForce / NVIDIA GeForce GTX 1050 GTX 750 (2GB de VRAM) (4GB de VRAM) DirectX Versión 11 Versión 11 Espacio en disco 5GB 5GB

ANEXO B: Secuencia de eventos en Quito Quest Fase 1 28 de noviembre 2019 Niveles Eventos

El juego empieza con Valentina y Joseth yendo a clases, en la entrada Carcelén 2019 del colegio se encuentra con su amigo Álvaro, que le pide busque a su amiga Belén. Antes de ello se encuentra con otra compañera, Ana, que le da más instrucciones sobre la ubicación de Belén. Cuando la encuentran también se encuentran con una persona de apariencia Colegio 2019 cansada, que demanda jugar cuarenta con ellas.

Dentro del colegio platican con más compañeros y profesores, notando que varios de ellos están cansados. Uno de sus profesores, Camilo, no Casa 2019 está en ese estado, pero está tratando de averiguar qué está pasando.

29 de noviembre 2019 En medio de la noche es despertada por un ruido, al tratar de investigar Casa 2019 es atacada y pierde el conocimiento.

Valentina despierta el día siguiente, su familia parece exhausta y no tienen recolección de lo que paso el día anterior. Carcelén 2019 Frustrada trata de buscar información junto a Joseth, esto las lleva por un viaje a través de la ciudad hasta que encuentran a un anciano en la Plaza Grande llamado Oscar, que les indica que sucedió algo similar en Plaza 2019 1999 y 1989. Las pone en ruta de otras personas que también trataron de averiguar qué paso. Esto las lleva a la Universidad Central, donde se encuentran con María Belén, una docente que les indica que en 1999 unas amigas de ella investigaron lo sucedido y que sus evidencias se Teatro 2019 encuentran en un blog, que tiene pistas sobre dónde encontrar una serie de cintas de VHS. Fase II 6 de octubre 1999

Facultad 1999 See-yeon y Joanna son estudiantes de la facultad de ingeniería de la UCE en 1999, dentro de la facultad se encuentran con un par de amigos, que les comentan un número de personas cansadas que hay en la ciudad. Teatro 1999 Más tarde se encuentran con unos amigos en el teatro universitario, incluyendo a una joven María Belén, el grupo de amigos decide Iñaquito 1999 encontrase nuevamente en la zona Iñaquito.

Carcelén 1999 Tarde en la noche regresan a casa y notan que sus padres no están, preocupadas salen a buscarlos y se encuentran con un bus saliendo de Carcelén. Casa 1999 El bus las lleva al monumento de la mitad del mundo, donde hay un gran número de personas que parecen “zombificadas”, al tratar de investigar Mitad 1999 más pierden el conocimiento. 7 de octubre 1999 El día siguiente despiertan en su casa junto a sus padres, quienes no Casa 1999 tienen recolección de lo que paso, tratan de regresar a la mitad del mundo, pero no hay manera, sin embargo, encuentran una pista, puede que haya alguien en la plaza grande que las pueda ayudar. Carcelén 1999 Encuentran a un Oscar más joven, que les dice algo similar a lo que les dirá a Valentina y Joseth, cuando tratan de buscar más información, son Plaza 1999 escoltadas fuera de la plaza por una protesta. Sin poder hacer nada regresan a su casa. 8 de octubre 1999 Casa 1999 El día siguiente van a clases y notan a muchos de sus compañeros, Carcelén 1999 incluyendo a sus amigos nombrados anteriormente, cansados. Decididas Facultad 1999 en averiguar qué está pasando encuentran una manera de regresar a la mitad del mundo. Mitad 1999 Fase III 30 de noviembre 2019

Casa 2019 Al terminar de ver las cintas, Valentina y Joseth planean volver a hablar con Oscar y María Belén, pero antes deben de ir a clases donde Carcelén 2019 encuentran a sus amigos, también con aspecto de cansados.

Oscar ya no recuerda mucho de lo que paso, pero vagamente les da una Colegio 2019 pista de lo que paso en 1989, algo que María Belén refuerza, por lo que van en camino a la basílica. Plaza 2019 En la iglesia encuentran una fotografía con lo que dijeron Oscar y María Belén, esta fotografía contiene instrucciones sobre donde está un álbum Teatro 2019 entero. Logran encontrar las fotografías, y las llevan con María Belén para Basílica 2019 poder revisarlas.

iii

Fase IV 7 de agosto 1989 Iglesia 1989 Diana y Jonathan están en la iglesia de San Francisco de paseo, luego de hablar con personas en el área deciden regresar a casa por el dia. En Basílica 1989 camino se encuentran con compañeros de trabajo de Diana quienes Iñaquito 1989 notan al numero de personas cansadas en la calle. 8 de agosto 1989 Iñaquito 1989 El dia siguiente deciden ir a la Plaza Grande donde encuentran a un Plaza 1989 Oscar aun mas joven, de aquí deciden ir a la Mitad del Mundo, donde termina el álbum. Mitad 1989 Fase V 30 de noviembre 2019 Teatro 2019 Al terminar de revisar el álbum deciden investigar hablar con Oscar otra Plaza 2019 vez, pero sin más opciones se dirigen a la mitad del mundo, a revisar que paso después de que se terminaron las cintas de VHS y fotografías. Mitad 2019

ANEXO C: Diseño de niveles en Quito Quest

ANEXO D: Listado de misiones planeadas para Quito Quest # Época Nombre misión Descripción El primer 1 2019 Inicia una nueva aventura objetivo. Álvaro no quiere que Belén siga llegando tarde a clases, Haz que Belén 2 2019 cree que puede estar con Ana, él dice que ella suele vaya a clase comer un helado antes de ir a clases. Averigua que Camilo está intrigado de porque tanta gente está 3 2019 está pasando en cansada, habla con algunos estudiante y profesores para el colegio. ver que está pasando. Otro día 4 2019 Es tarde, regresa a casa para no tener problemas. termina. Averigua que es Hay un extraño ruido que no te está dejando dormir, ve a 5 2019 ese ruido ver qué está pasando. ¿Pero qué paso Habla con tu familia para saber qué es lo que paso 6 2019 anoche? anoche. Hay algo Trata de averiguar con personas del barrio para saber 7 2019 extraño en esta qué es lo que paso el día anterior. ciudad. Un anciano en la Un anciano en la plaza grande puede saber que está 8 2019 plaza grande. pasando, encuéntralo y habla con él. 9 2019 Hacia la Central Encuentra a María Belén para saber que paso en 1999. Un blog de 20 Regresa al cyber de Carcelén y busca el blog perdido en 10 2019 años el tiempo. 11 1999 Back in 1999 Encuentra las cintas y revísalas. ¿Y qué hacemos 12 1999 ¡Se acabaron las clases! ¿Qué hacemos ahora? ahora? Vamos a salir con unos amigos está noche, veamos a 13 1999 Vamos de joda donde vamos a ir. 14 1999 Party time Vamos a desestresarnos Hora de regresar 15 1999 Es demasiado tarde, hora de regresar a casa. a casa

Una misteriosa ¿Dónde están todos? Carcelén está muy silencioso y solo 16 1999 desaparición. hay un bus en todo el barrio. De una película ¿Pero, que está pasando aquí? Algo muy extraño está 17 1999 de terror ocurriendo en la mitad del mundo. Locuras están Averigua que fue lo que paso anoche, debería de haber 18 1999 pasando en esta muchos testigos. ciudad En busca de ayuda en el ¿Una persona en la plaza grande puede saber que está 19 1999 corazón de la pasando? Es mejor averiguarlo personalmente. ciudad 20 1999 Regresa a casa. No podemos hacer más aquí, vámonos. Hay que ir al Esto ha salido de manos, debemos ir a la mitad del 21 1999 fondo de esto mundo y ponerle fin a esto. ¿Y qué paso Las cintas no dieron suficientes respuestas, ve con Oscar 22 2019 después? y María Belén para obtener más información Esto ha ocurrido por décadas, y puede que alguien hace En busca de una 23 2019 30 años haya encontrado algo, ve a la basílica donde fotografía puede haber respuestas. Es una pequeña Encuentra el resto del álbum y regresa con María Belén 24 2019 parte de un para revisarlo. álbum Tiempo de 25 1989 ¿No es esto divertido? Tiempo de calidad con Jonathan calidad ¿Y ahora a 26 1989 Piensa en el siguiente destino de este viaje. dónde? Algo extraño está pasando en la ciudad, trata de obtener 27 1989 ¿Una epidemia? información sobre lo que está ocurriendo. Un misterio en Parece que el secreto de todo está en la mitad del mundo, 28 1989 la mitad del incluyendo a la persona misteriosa, hay que averiguar mundo qué está pasando. El fin del 29 2019 Ve a la mitad del mundo y resuelve el misterio. misterio

ANEXO E: Listado de objetivos planeados para Quito Quest # Nombre misión Descripción objetivo 1 El primer objetivo. ¡Despierta! Es un hermoso día Haz que Belén vaya a 2 Habla con Ana clase Haz que Belén vaya a 3 Encuentra a Belén y has que vaya a clase. clase Haz que Belén vaya a 4 Ve a clases. clase Averigua que está Ese Marvin suele ser un metido, tal vez sepa algo, 5 pasando en el colegio. suele estar por el bar. Averigua que está 6 Habla con Álvaro pasando en el colegio. Averigua que está El Dr. Paz suele saber que está pasando, es buena 7 pasando en el colegio. idea preguntarle a él. vii

Averigua que está 8 Habla con Ana pasando en el colegio. Averigua que está Belén es la favorita de Camilo, sería buena idea 9 pasando en el colegio. hablar con ella. Averigua que está 10 Repórtate con Camilo pasando en el colegio. 11 Otro día termina. Regresa a casa 12 Otro día termina. Ve a dormir. Sigue el ruido, parece que viene del parqueadero 13 Averigua que es ese ruido del colegio. 14 ¿Pero qué paso anoche? Habla con la madre de Valentina 15 ¿Pero qué paso anoche? Habla con Sofía 16 ¿Pero qué paso anoche? Habla con tu otra hermana 17 ¿Pero qué paso anoche? Habla con el padre de Valentina Hay algo extraño en esta 18 Trata de hablar con Marvin ciudad. Hay algo extraño en esta 19 Tal vez Alvaro nos pueda ayudar. ciudad. Hay algo extraño en esta Camilo nos ha pedido mucha ayuda estos días, tal 20 ciudad. vez él nos pueda ayudar ahora Un anciano en la plaza 21 Ve a la plaza grande grande. Un anciano en la plaza 22 Habla con uno de los viejos grande. Un anciano en la plaza 23 Habla con uno de los viejos grande. Un anciano en la plaza 24 Encuentra y habla con alguien que pueda ayudar. grande. 25 Hacia la Central Ve al teatro universitario 26 Hacia la Central Busca información de Mabe Encuentra y habla con la persona que menciono 27 Hacia la Central Oscar. 28 Un blog de 20 años Regresa a Carcelén 29 Un blog de 20 años Ve al cyber de Carcelén 30 Un blog de 20 años Busca el blog y obtén información 31 Back in 1999 Busca en el patio de casa por la cinta 32 Back in 1999 Mira el contenido de la cinta en la televisión 33 ¿Y qué hacemos ahora? Termina las clases por el día. 34 Vamos de joda Habla con tus amigos sobre donde ir 35 Vamos de joda Llega al teatro Encuéntrate con el resto de tus amigos en el teatro 36 Vamos de joda universitario. 37 Vamos de joda Encuéntrate con tus amigos donde acordaron. 38 Party time Encuentra a Bryan, el conoce buenos lugares. 39 Party time Encuentra a Joel, suele ser el alma de la fiesta. Adaly es la silenciosa, vamos a tratar de cambiar 40 Party time eso esta noche. 41 Party time Regresa con Mabe y decide a donde ir. 42 Hora de regresar a casa Regresa a Carcelén

viii

43 Hora de regresar a casa Ve a casa Una misteriosa 44 Investiga tu casa desaparición. Una misteriosa 45 Investiga al único bus estacionado en Carcelén desaparición. 46 De una película de terror Habla con una de las personas 47 De una película de terror Habla con una de las personas 48 De una película de terror Investiga el monumento de la mitad del mundo Locuras están pasando en Habla con el padre de See-yeon sobre lo que paso 49 esta ciudad anoche Locuras están pasando en Habla con la madre de Johanna sobre lo que paso 50 esta ciudad anoche Locuras están pasando en 51 Pregunta a la policía lo que pudo haber pasado esta ciudad En busca de ayuda en el 52 Ve a la plaza grande corazón de la ciudad En busca de ayuda en el 53 Pregunta sobre Oscar corazón de la ciudad En busca de ayuda en el 54 Pregunta sobre Oscar corazón de la ciudad En busca de ayuda en el Encuentra a Oscar y pregunta sobre lo que está 55 corazón de la ciudad pasando 56 Regresa a casa. Regresa a Carcelén 57 Regresa a casa. Ve a dormir, no hay nada que se pueda hacer Hay que ir al fondo de Se puede llegar a la mitad del mundo desde la 58 esto plaza grande, ¡vayamos por un bus allá! Hay que ir al fondo de Ve a la mitad del mundo, tenemos que averiguar 59 esto bien que está pasando Hay que ir al fondo de 60 Pregunta en el monumento que está pasando esto Hay que ir al fondo de 61 Investiga el monumento de la mitad del mundo esto Hay que ir a hablar con María Belén, pero es 62 ¿Y qué paso después? tarde, ve a dormir por ahora. 63 ¿Y qué paso después? Ve al teatro universitario Regresa al teatro universitario a hablar con María 64 ¿Y qué paso después? Belén 65 ¿Y qué paso después? Ve a la Plaza Grande. Pregúntale a Oscar que más recuerda sobre lo que 66 ¿Y qué paso después? paso En busca de una 67 Ve a la basílica en busca de esa fotografía fotografía En busca de una 68 Busca información sobre la fotografía fotografía Es una pequeña parte de Ve a la plaza grande en busca del álbum de 69 un álbum fotografías Es una pequeña parte de 70 Encuentra el álbum de fotografías un álbum Es una pequeña parte de 71 Revisa el álbum junto a María Belén un álbum

72 Tiempo de calidad Sal de paseo con Jonathan 73 ¿Y ahora a dónde? Habla con las personas presentes sobre donde ir. 74 ¿Y ahora a dónde? Ve al lugar donde quedaron. Habla con tus compañeros de trabajo sobre lo que 75 ¿Una epidemia? está pasando 76 ¿Una epidemia? Ve a casa Un misterio en la mitad 77 Investiga el monumento de la mitad del mundo del mundo 78 El fin del misterio Ve hacia la mitad del mundo Ve hacia el edificio conde desaparecieron Diana y 79 El fin del misterio Jonathan

ANEXO F: Capturas de desarrollo de Quito Quest

xii

ANEXO G: Capturas de juego empaquetado

xiii

xiv

ANEXO H: Capturas del juego publicado

Enlace de descarga: https://dironquillo.itch.io/quito-quest

xvi

ANEXO I: Encuesta realizada Encuesta 1) ¿A qué grupo de edad pertenece?

 10 – 15 años  15 – 20 años  20 – 25 años  25 – 30 años  Más de 30 años

2) ¿Con que genero se identifica?

 Masculino  Femenino  Otro  Prefiero no decir

3) ¿En qué plataforma prefiere jugar videojuegos?

 Dispositivos moviles (celulares, tablets, etc.)  Consolas de sobermesa (PlayStation 4, Xbox One, etc.)  Consolas portátiles (Nintendo Switch, Nintendo 3DS, etc.)  Computadora

4) ¿Tiene experiencia con RPGs o JRPGs?

 Mucho  Medio  Poco  Nada

5) ¿Qué tan interesante le pareció el concepto del juego?

 Mucho  Medio  Poco  Nada

6) ¿Qué tan factible le parece que se puedan desarrollar juegos de rol dentro del país?

 Mucho  Medio  Poco  Nada

xvii

7) ¿Qué tanto le interesaría jugar el juego terminado?

 Mucho  Medio  Poco  Nada

8) ¿Qué tanto le gusto el sistema de conversación?

 Mucho  Medio  Poco  Nada

9) ¿Qué tanto le gusto el sistema de tienda?

 Mucho  Medio  Poco  Nada

10) ¿Qué tanto le gusto el sistema de combate?

 Mucho  Medio  Poco  Nada

11) ¿Cree que este sistema de combate sea factible en un juego entero?

 Mucho  Medio  Poco  Nada

12) Sus recomendaciones para el juego final:

xviii