Universidad Politécnica de Madridoa.upm.es/58280/1/TFG_FRANCISCO_DEL_REAL_ESCUDERO.pdfLa trama del juego sigue un argumento parecido a muchos juegos de escape: los dos personajes

Universidad Politécnicade Madrid

Escuela Técnica Superior deIngenieros Informáticos

Grado en Matemáticas e Informática

Trabajo Fin de Grado

Historias del Laberinto

Autor: Francisco del Real EscuderoTutor(a): Ángel Herranz Nieva

Madrid, Enero 2020

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

Trabajo Fin de GradoGrado en Matemáticas e Informática

Título: Historias del Laberinto

Enero 2020

Autor: Francisco del Real EscuderoTutor: Ángel Herranz Nieva

Lenguajes y Sistemas Informáticos e Ingeniería de SoftwareETSI InformáticosUniversidad Politécnica de Madrid

Resumen

El proyecto se desarrolla en el ámbito del departamento de Lenguajes y SistemasInformáticos e Ingeniería del Software de la Escuela Técnica Superior de IngenierosInformáticos de la Universidad Politécnica de Madrid.

Este trabajo de fin de grado intenta resumir en un pequeño documento el desarrollode un proyecto que empezó como una práctica de la primera signatura de programa-ción. Para ello, se estructura el documento en tres partes:

Primero se presenta una pequeña bitácora de desarrollo del proyecto antes del trabajode fin de grado. En este capítulo se describe la idea original del proyecto, que eradesarrollar un videojuego estilo .elige tu propia aventura", y su evolución a lo largo delos años.

En la siguiente sección se habla de las motivaciones para realizar este trabajo, in-cluyendo el estado de aplicaciones del mismo estilo, implementaciones diferentes ycuáles son las tendencias de videojuegos en dispositivos móviles.

Después el documento se centra en el proyecto actual, un intérprete de videojuegos.En este capítulo se describirá cómo funciona el motor por dentro, la metodología detrabajo que se ha seguido y las tecnologías que se han usado para su desarrollo.Además se incluye un diario de las tareas que se han realizado.

Por último se añade una serie de conclusiones sobre el proyecto y posibles mejoras aimplementar en un futuro.

Espero que podáis disfrutar de este trabajo tanto como lo he hecho yo.

i

Abstract

This project is developed with the help of the department of "Lenguajes y Sistemas In-formáticos e Ingeniería del Software"from the .Escuela Técnica Superior de IngenierosInformáticos.of the university Üniversidad Politécnica de Madrid".

This end-grade work is presented as a full development project, starting from thefirst steps for software engineering like planning the features the app should bundle,through all the actual development of a mobile application. The discussion of thiswork will start from the first approaches of this project, it started on my first pro-gramming subject "Programación I", and its evolution through time. From now on,this document will be structured in three distinct parts:

The first one will cover the first steps of the application as it grew before doing thispaper. This part will show the application origins, the reason for choosing a çhooseyour own adventure"videogame and how has been enduring the app before this end-grade work.

On the next section the main point will be the motivations that made possible thisidea. Also, it is included some research about similar applications, their implementa-tions, and the actual trends on mobile games.

The next chapter will talk about the core of the project: what makes it a videogameinterpreter, how it works... It is also included here the methodology used during thework, a little research of the technologies used in the development and a developmenttasks journal.

For the last part, some conclusions of the project are attached, including some pos-sible improvements.

I hope to get your expectations as high as possible.

iii

Tabla de contenidos

1. Introducción 11.1. Qué era antes Historias del Laberinto . . . . . . . . . . . . . . . . . . . . . 3

1.1.1. Menú de juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1.2. Siguiente paso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1.3. Pantalla de carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1.4. Movimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.1.5. Inventario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.1.6. Combate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2. Por qué un intérprete de videojuegos . . . . . . . . . . . . . . . . . . . . . 6

2. Descripción del proyecto 92.1. Qué es Historias del Laberinto (Descripción) . . . . . . . . . . . . . . . . . 9

2.1.1. Qué tipo de videojuegos se pueden crear . . . . . . . . . . . . . . . 102.1.2. Dónde se podrá usar el motor . . . . . . . . . . . . . . . . . . . . . 102.1.3. Qué es capaz de hacer el motor . . . . . . . . . . . . . . . . . . . . 102.1.4. Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.4.1. Diálogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.4.2. Condición . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.4.3. Elección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.4.4. Batalla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.4.5. Recompensa . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.5. Habitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.6. Personajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.7. Condiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.8. Variables personalizadas . . . . . . . . . . . . . . . . . . . . . . . . 142.1.9. Localización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2. Qué esperar del sistema (Diseño) . . . . . . . . . . . . . . . . . . . . . . . 182.2.1. Pantalla de menú principal . . . . . . . . . . . . . . . . . . . . . . . 182.2.2. Pantalla de cambio de idioma . . . . . . . . . . . . . . . . . . . . . 192.2.3. Pantalla de habitación . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.4. Pantalla de movimiento . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.5. Menú secundario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.6. Inventario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.7. Ejecución de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.7.1. Diálogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.7.2. Condición . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.7.3. Elección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.7.4. Batalla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

v

TABLA DE CONTENIDOS

2.2.7.5. Recompensa . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3. Cómo crear un videojuego . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.3.1. Imágenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.2. Literales localizables . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.3. Condiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.4. Personajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.3.5. Protagonista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.6. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.7. Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.8. Habitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.3.9. Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3. Desarrollo de la aplicación 353.1. Planificando los objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1.1. Qué es Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.2. Desarrollando en dispositivos móviles (Arquitectura) . . . . . . . . . . . . 37

3.2.1. Capa de presentación . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.2. Capa de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2.3. Capa de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4. Qué tal ha ido el desarrollo (Resultados y conclusiones) 414.1. Futuro del intérprete (Trabajo futuro) . . . . . . . . . . . . . . . . . . . . . 42

4.1.1. Versiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.1.2. Música . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.1.3. Menú de estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.4. Modificar interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.5. Movimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.6. Nuevo combate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.1.7. Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.1.8. Compartir historias . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.1.9. Puzles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Bibliografía 45

Anexo 46.1. Ejemplo de código en python . . . . . . . . . . . . . . . . . . . . . . . . . . 47.2. Ejemplo de fórmula matemática . . . . . . . . . . . . . . . . . . . . . . . . 47.3. Diario del desarrollador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

vi

Capítulo 1

Introducción

Esta idea surgió a raíz de una práctica de programación impartida por la universidad.

En Programación I, asignatura que se cursa en el primer año del grado, se propusocomo ejercicio de final de la asignatura un proyecto en lenguaje Java de tema libreen equipos de dos personas. Nos unimos una compañera de clase, Andrea del Nido,y yo.

Al principio no contábamos con tanta experiencia y no fue fácil encontrar un temainteresante. Sin embargo, ante el movimiento general de toda la clase por hacer unvideojuego (hundir la flota, adivina el número), decidimos seguir el camino de crearun programa de un juego, pero tampoco se nos ocurría una alternativa a los proyectosde nuestros compañeros.

Entonces una compañera de clase nos propuso la idea de un juego de pistas, es decir,un juego de buscar objetos para luego poder usarlos en otro lugar, añadiéndole unahistoria bien definida y atractiva.

Así nos pusimos manos a la obra a desarrollar esa idea y la historia que conllevaba.Como era un proyecto complejo para nuestro nivel de aprendizaje en el momento yademás muy alejado de las prácticas de programación, llevamos a cabo una lluviade ideas de todas las cosas que podría incluir el proyecto, intentando ser muy ambi-ciosos para luego poder descartar opciones. Personalmente me involucré mucho enel desarrollo ya que me encantan los videojuegos y además siempre había queridotrabajar en un proyecto de este tipo.

Tras muchas horas extra de programación, conseguimos una primera versión fun-cional sin muchos errores para la presentación del proyecto. Se hablará de cómofuncionaba el juego en el próximo apartado.

A partir de ahí, tras pedir permiso a mi compañera para continuar con el desarrollopor mi cuenta, proseguí arreglando errores del proyecto para tener una versión acep-table para jugar. Así pasaron los dos años siguientes del grado, dando en cada se-mestre una nueva asignatura de programación que aunque no estuvieran centradosen continuar este proyecto, me permitieron ir mejorando ciertas implementacionesdel juego así como añadir ciertas funcionalidades que no estaban presentes desde unprincipio.

Poco a poco, sin embargo fui dejando el proyecto en el olvido debido a una mezcla de

1

Figura 1.1: Ejemplo de una ejecución del juego

falta de tiempo por estudios y prácticas y también por falta de nuevas ideas, ya quela ártifice de las grandes ideas del proyecto era mi compañera.

En el último año del grado, tras enterarme de que se podría presentar un proyec-to con un tema personalizado pensé inmediatamente en continuar con el desarrollode Historias del Laberinto. Con la ayuda de Andrea del Nido y Andrea de las Heras,llegamos a la conclusión de que no podía presentar lo que llevaba hecho hasta elmomento, porque todas las actualizaciones y mejoras que fui programando provoca-ron que el código fuera muy difícil de modificar. Además el juego era muy difícil demostrar, ya que necesitaba de una máquina virtual Java para reproducirse y muchagente cercana me preguntó si este juego se podía jugar en el móvil.

Por lo tanto, el tema se centraría en el desarrollo de un nuevo videojuego que permi-tiría al usuario jugarlo en un dispositivo móvil, que contara con un sistema genéricode desarrollo de eventos, así como las características del juego original.

Inicié la búsqueda del tutor que pudiera llevar el trabajo, y por suerte encontré a miactual tutor, Ángel Herranz, al que le doy las gracias por permitirme desarrollar esteproyecto. Él se interesó desde el principio en la idea del proyecto, y me sugirió variaspautas para llevar el trabajo con él.

2

Introducción

1.1. Qué era antes Historias del Laberinto

Esta sección se centrará en la explicación de lo que fue Historias del Laberinto duran-te su desarrollo como proyecto de Programación I y sus mejoras posteriores. Primerose hablará de los aspectos relacionados con el primer proyecto.

El proyecto original era una aplicación capaz de reproducir una historia única sobredos personajes, Gerar y el jugador, al que se le podía poner un nombre.

La trama del juego sigue un argumento parecido a muchos juegos de escape: los dospersonajes debían escapar del Laberinto, un misterioso lugar lleno de trampas delque no saben cómo llegaron ni cómo pueden salir. Por ello, el jugador y su compa-ñero debían avanzar por las salas del laberinto hasta llegar a la sala final, dondeun malvado dragón les separaba de su esperada salida. Durante el camino encon-trarán carismáticos personajes como el Fantasma, salas del tesoro, encuentros conmonstruos o salas con truco.

Respecto a la funcionalidad, tras la lluvia de ideas sobre lo que el juego debía deser capaz de hacer, se desarrollaron los siguientes subsistemas principales: menú dejuego, movimiento, inventario, combate y pantalla de carga. Aparte se incluían otrasfuncionalidades extra. A continuación se describirá un poco qué hacía cada uno deellos.

Figura 1.2: Gerardo, el compañero del videojuego

1.1.1. Menú de juego

El juego se pensó desde un principio como un sistema simple que incluía lo que enotros cursos llamaríamos estados y un bucle de ejecución que evaluaba estos estadosy generaba los eventos necesarios.

Este sistema consistía en un bucle que siempre mostraba las mismas opciones: ha-blar, interactuar, inventario y moverse. Estas acciones cambiaban según una seriede parámetros que definían el estado de ejecución del programa: un número que in-dicaba una sala, un valor booleano que decía si el compañero estaba jugando y un

3

1.1. Qué era antes Historias del Laberinto

mapa de lugares ya visitados.

1.1.2. Siguiente paso

En el desarrollo inicial del juego, toda la salida de la interfaz y los diálogos era porconsola, por lo que todos los diálogos que ocurrían en la historia se imprimían porconsola.

Debido a la rapidez de la ejecución de las instrucciones, las líneas de código que seencargaban del diálogo eran directamente impresas en consola y se ejecutaban muyrápidamente, provocando que al pulsar una acción o una respuesta, todo el textosiguiente apareciera rápidamente en consola y muchas veces fuera ilegible.

Por ello se pensó en una funcionalidad que esperaba ante una respuesta del usuariocualquiera, normalmente un pulsado de la tecla "intro", para mostrar el siguientediálogo y hacer posible que la ejecución del juego fuera más legible.

1.1.3. Pantalla de carga

El funcionamiento del juego en la aplicación era muy rápido, aunque la calidad delcódigo no fuera óptima. Los conceptos adquiridos en la asignatura nos introdujeronen ámbitos básicos del lenguaje de programación Java, por lo que las operacionesque se llevaban a cabo siempre eran muy rápidas. Además, ninguna operación de-pendía de otra, no contaba con concurrencia, no hacía conexiones con Internet ni seencargaba de parsear información antes de ejecutar el núcleo del juego.

Debido a que no había ningún recurso que cargar ni inicializar, el juego se iniciabainstantáneamente. Aunque esto puede ser positivo para un programa, nosotros creí-mos en su momento indispensable separar ciertas funcionalidades del juego como elinicio, una batalla, un evento del resto para intentar emular una característica queaparece en todos los juegos actuales: la pantalla de carga.

Esta funcionalidad simplemente paraba el hilo de ejecución cada cierto tiempo ymientras tanto iba imprimiendo por consola un mensaje que indicaba que la aplica-ción estaba cargando.

1.1.4. Movimiento

La función de movimiento permitía a un jugador moverse entre las salas del labe-rinto. Para ello, se pensó en un mapa de posiciones, de manera que cada posiciónrepresentara una habitación. Cada sala estaba representada como un número del 1al 20, y cada uno de estos números se ubicaron en un mapa, representado como unamatriz de 5 columnas y 4 filas que recogía la información de la sala que se ubicabaen cada casilla. Todas las salas eran diferentes entre sí.

De esta manera se deducía que la posición actual de un jugador y las posiciones decada sala estaban dadas por unas coordenadas que representaban los índices legalespara la matriz, es decir, índices para que no surja un error al intentar acceder a lainformación de la matriz del mapa. Las coordenadas que se usaban eran una para laprimera matriz, que representaba como el eje de la x, y otra para las submatrices dela primera matriz, que representaba como el eje de la y.

4

Introducción

Un jugador tiene cuatro opciones para moverse: ir hacia delante, hacia atrás, a laderecha o a la izquierda. Al seleccionar una dirección, el sistema calculaba si esemovimiento era posible y lo ejecutaba. Todo esto incluía como un extra un sistema dedirecciones mediante el uso de una brújula. Esto significa que al moverse a cualquierdirección que no fuera adelante se cambiaba la dirección hacia la que estaba mirandoel grupo. De esta manera el jugador estaba siempre mirando a alguno de los puntoscardinales, y calculaba el movimiento teniendo en cuenta la dirección escogida.

Este sistema era capaz de evitar que al moverse el jugador pudiera irse fuera de loslímites de la matriz y también de evitar el movimiento hacia ciertas salas desde ciertoslados.

1.1.5. Inventario

La función del inventario está pensada como un sistema de uso de objetos. Incluyeun gestor de objetos y un menú de uso de los objetos.

En el proyecto original, la idea principal para manejar los objetos contaba con quesolo el protagonista podía tener un inventario, es decir, una referencia a los objetosconseguidos y guardados. De esta manera, solo el protagonista podía conseguir obje-tos y usarlos, aunque posteriormente se añadió funcionalidad para que el compañeropueda usarlos también.

Existían dos tipos de objetos genéricos: consumibles y objetos clave. Los consumi-bles son objetos que se pueden consumir por el protagonista o el compañero y quemodifican el valor de los puntos de vida actuales de los personajes. Un ejemplo deun objeto consumible es una poción, que recuperaba una cantidad de puntos de vidaactuales. Los objetos clave son objetos que solo pueden usarse fuera de las batallasen ciertas salas del laberinto y que suelen activar eventos. Son objetos que ademásno se pueden usar dentro de una batalla, y por lo tanto al usarlos mostraban undiálogo con una descripción del objeto.

Los dos tipos de objetos son limitados, es decir, hay una cantidad reducida de los mis-mos por partida y además al usarse se gastan, por lo que podría llegar un momentoen el juego en que no quedaran objetos.

1.1.6. Combate

El combate se presentó como un sistema genérico de combate que incluía tres posi-bles actores: el protagonista, el compañero y un enemigo. El protagonista y el com-pañero formaban un equipo y se enfrentaban al enemigo, que podía ser un personajegenérico cualquiera.

El combate siempre giraba alrededor de los puntos de vida actuales del enemigo ydel protagonista, por lo que si alguno de estos llegaba al cero entonces el combate seterminaba.

El sistema de combate es un combate por turnos del estilo de juegos de rol (RPG)como los descritos en la introducción, es decir, un sistema de combate por turnos,siguiendo un orden fijo preestablecido:

1. Protagonista

2. Enemigo

5

1.2. Por qué un intérprete de videojuegos

3. Compañero

Siempre siguiendo este orden de actuación en los turnos, cada turno tenía una seriede fases bien fijadas:

1. Cálculo de daño inicial: permitía calcular si el siguiente turno debía ejecutarseo no, según si el actor que fuera a actuar tuviera más de cero puntos de vidaactuales.

2. Selección de acción y objetivo: dependiendo del personaje, se podían realizarciertas acciones. En el caso del protagonista, el personaje controlado por el ju-gador, existían tres opciones: atacar, estado e inventario. El enemigo siempreusa el comando Atacar y se elige aleatoriamente el objetivo del ataque. El com-pañero podía elegir entre atacar o usar el inventario según ciertos parámetros,cómo la vida restante.

3. Resolución de daño: tras haber atacado a un objetivo, se calculan los puntos devida restantes del objetivo del ataque y se calcula si la batalla ha de terminaro si debe continuar. La batalla terminaba si el protagonista o el enemigo eranderrotados.

En desarrollos posteriores a la entrega del primer trabajo, se incluyó la posibilidadde que un personaje del combate pudiera tener un estado alterado de una lista fija:envenenado, paralizado y ciego. Esto permitía hacer más diverso el combate, ya queimpedía a un jugador no actuar o provocaba que fallara siempre los ataques.


Antes de empezar con la razón detrás de esta elección, querría hablar un poco de lostipos de juegos. A mi parecer, existen dos tipos de juegos: los juegos que se centranen contar una historia y los que se centran en desarrollar una jugabilidad entrete-nida o rompedora. Aunque es cierto que muchas veces estos dos tipos de juegos seentrelazan, pocos son los que se puede decir que tengan una jugabilidad amena y conuna historia que no solo sea atractiva para un jugador, sino que esté intimamenterelacionada con el juego en sí.

Para mostrar este hecho, pongamos algunos ejemplos:

Final Fantasy: esta saga de videojuegos tienen todos un núcleo común, una his-toria que se desarrolla a lo largo de todo el videojuego. Normalmente se resumeen un grupo de compañeros que viajan por todo su mundo para salvar de algúnmalvado. El foco principal de estos videojuegos es la historia que tienen quecontar.

Super Smash Bros: sin embargo esta otra saga, aunque alguna de sus entregascuenta con historia, se centra en su jugabilidad principal: combates a tiemporeal entre personajes de Nintendo, como Mario, Luigi... Este juego no tiene unahistoria muy atractiva, y no se centra en avanzarla a lo largo del juego.

Bravely Default: sucesor espiritual de RPGs clásicos, es una fusión de los dostipos de juegos que existen: tiene una historia atractiva en la avanzas a medidaque continúas en el juego, y tiene un gran cuidado en su jugabilidad, que ade-más está inmersa en la historia: a lo largo del juego podrás hacer las acciones

6

Introducción

”Brave” y ”Default”.

El principal factor para realizar un intérprete de videojuegos de la forma que se hadesarrollado en el proyecto es el siguiente: me encantan los videojuegos que soncapaces de sumerger a un jugador en su historia. Así que me propuse el reto decrear videojuegos cuyo foco principal sea la historia. Para ello, me basé en el trabajooriginal desarrollado en mi primer año de carrera como punto de partida.

Desde que se empezó el desarrollo del juego se ha intentado buscar una mecánicasimple que se repitiera durante todo el desarrollo del juego: elegir entre las opcionesde hablar, interactuar, inventario y moverse. El nombre de "Historias del Laberinto.alprincipio fue pensado teniendo en cuenta la historia original del juego; sin embargoeste concepto de historia se puede generalizar en un jugador que intenta escapar deun laberinto: el verdadero contenido de la historia no es tan importante como lascapacidades que se quieren dar al juego, como puede ser la exploración, el combateo la resolución de puzles.

Siguiendo esta línea de pensamiento, se elaboraron una serie de ficheros de texto quecontenían información sobre los diálogos de la historia original y que permitían ali-viar el contenido de impresiones por consola de la aplicación, en la clase de desarrollodel juego principal había más de mil lineas. Sacando la historia a los ficheros con-seguiríamos quitarnos de encima todo el relleno de texto del videojuego y quedarnossolo con la lógica que permitiera realizar las acciones. Así se podría intentar eliminartodas las acciones de imprimir en la consola la historia de relleno, que ocupaba casiel 60 % de la longitud del fichero principal de desarrollo.

Y así se empezó a evaluar cómo podíamos sacar todos los literales que definían lahistoria, pero a la hora de refactorizar el código muchas de esas líneas no se pu-dieron sacar, debido a que en ciertas partes se habían generado unas dependenciasmuy grandes. Sin embargo, se prosiguió adelante hasta conseguir eliminar todos losliterales posibles del fichero.

Durante mucho tiempo el proyecto se consideró acabado con esta solución, hasta quellegó la asignatura del trabajo de fin de grado y se presentó la posibilidad de rehacerel juego, esta vez en dispositivos móviles.

Para presentar mi idea a un profesor, primero acudí a Francisco Rosales para quefuera mi tutor. Con la idea de tener un proyecto bastante bueno –tenía muchas líneasde código–, le enseñe el sistema. Sin embargo, tras hablarlo durante un rato, meplanteó que realizar un videojuego con él no sería buena idea por dos razones: notenía mucha idea sobre el tema, y un proyecto así no solo requiere trabajo paracodificar, sino también para dibujar, planear pantallas... Si hubiera tenido un sistemade código potente o un motor bueno con el que empezar a trabajar habría ocurridootra cosa, pero realmente hacer "Historias del Laberintoçomo tal no era una buenaidea.

Y es que las capacidades del juego estaban muy limitadas: básicamente el juego erasiempre el mismo, solo que con distintos rellenos de historia: la lógica que existieraen las habitaciones estaba definida directamente en el código, como que la sala 17 erael comienzo del juego o que en la sala 5 había un cofre del tesoro... Esta capacidadno hace muy especial al proyecto ya que en el fondo siempre va a ser el mismo juego.

Así que empecé a plantearme que la totalidad del proyecto tendría que ser más ge-

7


nérico para que el juego tuviera un verdadero interés más allá de ser un videojuegomuy simple. Esto permitiría a cualquier persona, no tendría por qué ser un desarro-llador, crear un videojuego a su gusto. Con una serie de funcionalidades genéricas,como pueden ser el abrir un cofre o hablar con un personaje podrían traducirse enacciones simples que un usuario pudiera modelizar.

Este motor no se basa sólo en que sea lo más genérico posible, a veces hacer genéricoun sistema lo complica mucho. Por ello, se tienen en cuenta siempre estos aspectosdel motor:

Potencia: el motor que pueda reproducir un juego debe ser capaz de realizarmuchos tipos de acciones, en aras de mantener una jugabilidad entretenida ala vez que se proporciona una historia completa.

Versatilidad: un videojuego debe ser configurable, es decir, todos los aspectos delvideojuego deberían ser modificables por el creador de un videojuego, y deberíanmantener el mínimo número de dependencias entre el motor y la capacidad deun usuario de crear un videojuego.

A prueba de errores: debe ser capaz de reaccionar a posibles fallos que se pro-duzcan durante el juego o ser capaz de mantenerse fuerte ante los usuarios másduros.

Compatibilidad: el motor tendría que ser compatible con la mayoría de las pla-taformas disponibles en el mercado, para que cualquier cliente sea capaz dereproducir este motor en distintos dispositivos. De momento no hay planes detraducir el proyecto a Android, solo está pensado para iOS.

Para resumir, el proyecto se ha convertido en un intérprete de videojuegos porque eljuego original tenía esta idea como evolución directa y porque creo que demuestrami crecimiento en el conocimiento que he ido adquiriendo a lo largo del tiempo en launiversidad. Por ello, aproveché que además es un tema que me encanta para podercentrarme completamente en ello.

8

Capítulo 2

Descripción del proyecto

En este capítulo se describe cómo funciona el motor en esencia, es decir, sin en-trar en la implementación del mismo. Esta idea general no depende del lenguaje deprogramación.

Hay un apartado que describe al motor y sus capacidades, y otro apartado que mues-tra el diseño actual de la aplicación y expone otras ideas que se pueden llevar a cabo.

2.1. Qué es Historias del Laberinto (Descripción)

Historias del Laberinto es una aplicación que funciona como intérprete de video-juegos. Los posibles nombres con los que se identifica al motor en este trabajo sonmotor, intérprete, aplicación o proyecto.

Esta aplicación permite a un usuario reproducir un videojuego definido en un formatopredefinido. Este formato permite abstraer de toda la capa programática a un dise-ñador. De momento solo es capaz de reproducir videojuegos, no es capaz de crearlos,aunque en una futura versión probablemente se desarrolle esta opción.

Se ha referido antes al proyecto también como un motor de videojuegos, que se puededefinir de esta manera:

Un motor de videojuego es un término que hace referencia a una serie de libreríasde programación que permiten el diseño, la creación y la representación de unvideojuego. [3]

En el caso de este trabajo, el proyecto no es una serie de librerías sino que es directa-mente una aplicación. De esta manera, se puede abstraer a un creador del videojuegode la programación directa de un juego.

Otros motores de videojuego que ahora están en el mercado y tienen una funcionali-dad similar son Unreal Engine[1] o Unity[2]. Estos motores permiten crear videojue-gos con una capacidad genérica muy potente, pero en muchos casos necesitan queel diseñador tenga conocimientos de diseño 3D, programación y matemáticas. No seha conseguido llegar al nivel de estos motores, porque supondría un reto muy grandepara el ámbito de un trabajo de fin de grado.

9


Figura 2.1: Logo del motor Unreal engine

2.1.1. Qué tipo de videojuegos se pueden crear

El interprete está orientado a reproducir juegos en los que el jugador tiene que es-capar de una mazmorra. Para ello, el jugador debe reunir objetos como llaves paraabrir puertas, esquivar trampas, resolver rompecabezas, luchar contra monstruos,usar pociones y llegar a una habitación final. Algunos ejemplos de juegos parecidosa los que está orientado el motor son ”Dragones y Mazmorras” o los libros de ”eligetu propia aventura”.

Aunque el motor esté desarrollado con una fuerte influencia por este tipo de juegos,no está limitado a ellos, cualquier creador pueda ir más allá de este concepto o inclusocambiarlo radicalmente usando las herramientas genéricas de las que dispone elmotor. El límite lo pone la imaginación del usuario.

2.1.2. Dónde se podrá usar el motor

De momento sólo está disponible para dispositivos que soporten el sistema operativoiOS, es decir, solo para dispositivos portables de Apple, como un iPhone o un iPad.Tampoco hay planes actuales de mover el motor a otra plataforma, pero es posibleimplementar el motor en otros sistemas y lenguajes de programación.

Con todas estas dudas resueltas ya solo queda mostrar las funciones de las quedispone el motor.

2.1.3. Qué es capaz de hacer el motor

El proyecto anterior se considera un punto de partida para muchos conceptos que sequerían llevar a cabo para el nuevo motor. Por ello, se escogieron ciertas funcionali-dades comunes que permitieran representar al videojuego original, separandolas enpequeñas piezas: mostrar un diálogo, iniciar un combate... De esta manera nacen loseventos.

El juego original también contaba con una serie de jugadores con los que podía in-teractuar el usuario, salas en las que se desarrollaba la historia, un sistema de movi-miento en forma de cuadrícula... Todos estos aspectos se han traducido al motor demanera que sean lo más fieles posibles al juego original.

A continuación, se describen por partes las funcionalidades que tiene el motor. De

10


momento no se entra en las especificaciones propias de la implementación, pero apa-recerá el diseño llevado a cabo en la sección 2.2, y cómo se ha implementado en elcapítulo 3.

2.1.4. Eventos

Un evento representa una acción atómica que puede realizar el motor. Estas accionesse consideran básicas en el ámbito de una aventura, como escoger una opción omostrar un diálogo; aunque requieran de más trabajo a la hora de programarlas.

Los eventos están pensados para unirse entre ellos, de manera que se puedan mezclarentre sí varias acciones básicas para formar una cadena de eventos. Por ello, cual-quiera de ellos son intercambiables, intercalables y no pueden tener dependenciasentre sí. Además, siempre se ejecutan de forma lineal, siguiendo un orden predefini-do por el creador del juego.

El centro de toda la potencia del motor reside en los eventos, ya que son un mecanis-mo genérico y preciso de ejecutar acciones en el juego. El motor está encargado deleer cada uno de estos eventos y ejecutar una acción según el contenido del mismo.Otra funcionalidad clave del motor es que nunca sabe el estado en el que se encuen-tra la cadena de eventos, se conforma con guardar el evento que esté ejecutando enel momento, ejecutarlo y pasar al siguiente.

Figura 2.2: Cadena de eventos

La idea detrás de los eventos es muy sencilla: al interactuar el usuario con unaparte de la aplicación activa una cadena. El evento principal tiene una referencia a

otro evento, al que le da paso cuando termina el original. Este encadenamientosigue hasta que uno de los eventos no tenga ninguna referencia a un evento

siguiente, permitiendo que la cadena termine.

Ahora vamos a definir los tipos de eventos que existen, las acciones que conllevandentro del motor y sus posibles usos. Respecto a diseño que toman, se describirámás adelante en la sección de diseño 2.2.

2.1.4.1. Diálogo

Evento que muestra un mensaje dicho por un personaje en el videojuego. La mayortraba del proyecto original era que los diálogos correspondían con la mayor parte del

11


código fuente, por lo que este evento permite quitar mucha lógica duplicada en elcódigo.

Su uso más frecuente es para mostrar conversaciones entre personajes, aunque tam-bién se puede usar para escribir los pensamientos del protagonista, describir una salao un personaje, plantear un problema...

2.1.4.2. Condición

Evento que verifica una condición sobre el estado actual del juego. Este evento estransparente para el usuario, ya que se ejecutará un evento u otro siguiente depen-diendo de si la condición es cierta o no. Las condiciones son las que se describen enla sección 2.1.7.

Este evento se suele usar cuando se quiere evaluar el estado del juego y tomar accio-nes en consecuencia. Por ejemplo, diálogos dependientes del compañero, cofres queno se abren si no dispones de una llave...

2.1.4.3. Elección

Evento que permite al jugador escoger entre una serie de opciones. Dependiendo de laopción escogida, se ejecutará un evento u otro. Además, las opciones pueden incluiruna condición para que se muestren, como las descritas en la sección 2.1.7.

Algunos ejemplos en los que aparece este evento son cuando hay que resolver unacertijo y se muestran varias respuestas, o cuando un personaje te ofrece posiblesformas de pago para un trueque.

2.1.4.4. Batalla

Evento que inicia una nueva batalla con la información de un enemigo al que enfren-tarse. Hasta que no termine la batalla no se pasará al siguiente evento de la cadena.

Al terminar la batalla se ejecutará un evento según si el jugador ha ganado o haperdido.

2.1.4.5. Recompensa

Evento que agrega objetos al inventario del jugador. Se suele usar para recompensara un jugador por haber ganado una batalla o por haber abierto un cofre.

2.1.5. Habitaciones

La idea original para el desarrollo del juego es un laberinto. Un laberinto se puederepresentar como una serie de pasillos delgados y oscuros por los que el protagonistadebe orientarse, o como una serie de habitaciones interconectadas entre sí. Estaúltima opción permite al jugador orientarse por cada partida, obtener mayor detallesobre los eventos, recordar lugares memorables y ayudar a estructurar el laberintopara el usuario.

Una habitación es el sitio donde ocurren todos los eventos que se pueden encontraren el juego. Es en estos lugares donde el jugador va a tener mayor libertad de mo-

12


vimientos porque es el lugar donde se ejecutan cadenas de eventos, puede ir haciaotras habitaciones o donde puede guardar la partida y cambiar ciertos ajustes.

Está representada con una imagen principal que describe a la habitación junto conun título y una descripción, y una serie de acciones que puede realizar el jugadordentro de ella.

2.1.6. Personajes

Durante la aventura el protagonista puede interactuar con múltiples personajes:compañeros, enemigos y NPCs, las siglas de ”non playable character”. [5] Además,el jugador también cuenta como un personaje aparte.

Todos los personajes cuentan con un nombre y una imagen que los representa, y loscompañeros y enemigos añaden una serie de características. Las posibles estadísticasque puede tener un personaje son:

Puntos de vida actuales: representan la vida restante del personaje. Si lospuntos de vida actuales del protagonista llegan a 0, entonces el juego termina.

Puntos de vida totales: representan la vida máxima que tiene un personaje.

Puntos de ataque: representan los puntos de vida actuales que puede quitarun personaje con un ataque.

Puntos de defensa: representan los puntos de vida actuales que el personajeelimina de un ataque al recibirlo.

Puntos de agilidad: representan la velocidad de un personaje. En un combate,si un personaje supera por un factor multiplicativo la agilidad del contrario,entonces el personaje puede atacar múltiples veces en un mismo turno.

Estado alterado: representa un cambio en el estado normal del personaje ypueden reportar beneficios o perjuicios al mismo. Los estados soportados por elmotor son veneno, ceguera y parálisis.

Arma: un personaje puede tener un arma consigo para atacar. Estas armasaumentarán el estado base de ataque, añadirán un porcentaje de acierto delataque y un estado alterado a provocar.

Respecto a las tres últimas estadísticas, se explican con más detalle en el apartadode batalla de la sección de diseño 2.2.7.4.

Los personajes por lo tanto son piezas esenciales de la acción durante el juego pordistintas razones:

Los diálogos siempre son enunciados por alguien, que debe ser un personaje.Un diálogo no se puede ejecutar si no existe un personaje que lo enuncie.

El protagonista y su compañero tienen una serie de características que son cru-ciales para la evaluación de condiciones, como los indicadores de habitacionesvisitadas.

En una batalla, siempre lucha un personaje enemigo contra el protagonista ysus compañeros.

13


Además, usar personajes permite que los jugadores puedan adentrarse en la aventuracon mayor facilidad e incluso identificarse con ellos.

2.1.7. Condiciones

El motor tiene varios puntos donde se necesita ejecutar condiciones para resolverciertas acciones. Estas condiciones están sujetas a varios factores como las estadís-ticas del protagonista, valor de las variables internas, etc.

Existen varios tipos de evaluaciones:

Compañero: si el protagonista tiene un compañero que coincide con el nombredefinido, entonces la condición se evalúa a verdadera. En otro caso, la condiciónes falsa.

Objeto: si el protagonista tiene un objeto en su inventario que coincide con elobjeto del evento, entonces la condición es cierta. En otro caso, no se cumple lacondición. Es importante puntualizar que si la condición es cierta, entonces elobjeto del inventario desaparece o se consume.

Estado de habitación: dependiendo si el protagonista ha visitado una habitaciónespecífica o no, la condición se evalúa a cierto o falso. Hay una condición quesirve para saber si se ha visitado una habitación y otra para si no la ha visitado.

Relación de variables: si la relación entre dos variables se cumple, entonces lacondición es cierta. En otro caso, la condición es falsa. La relación de variablesse describe mejor en la sección 2.1.8.

2.1.8. Variables personalizadas

Esta es una nueva funcionalidad del motor que no se encontraba en la original.

Las variables personalizadas es una capacidad del juego que permite almacenar in-formación dinámica de la partida, sin estar limitados por la propia capacidad deevaluar condiciones del motor. Estas permiten a un diseñador de juegos controlarciertos aspectos internos del desarrollo del juego como puede ser la activación de unevento o de ciertas elecciones.

Estas variables se pueden usar para guardar la información del estado de ejecuciónde un evento, almacenar la cantidad de tesoros que ha encontrado el jugador durantesu partida...

De esta manera, la capacidad de formular condiciones aumenta drásticamente, yaque no dependen de las que puedan estar definidas en el motor. Es más, el diseñadordel juego puede emular cualquier condición de las ya definidas si usa las variablescorrectamente.

Las variables tienen un id que las identifica, el dato que guarda y el tipo de esedato. Una variable siempre se crea definiendo estos tres campos. El motor soporta demomento los tipos entero, que representa números enteros; booleano, que representavalores de verdad como verdadero y falso; y cadena de texto, que son un literal detexto.

14


Debido a que estas variables son dinámicas, el motor permite no solo sustituir elvalor o crear nuevas variables, sino que también permite operaciones entre variablesu otros datos estáticos.

Las operaciones estarán formadas por dos variables y la operación que realizan entreellos. El resultado de la operación siempre se guarda en la primera variable con laque se opera. Las operaciones soportadas por el motor dependen del tipo de datoque guarde la variable, y nunca podrán operarse dos variables con distintos tipos dedatos.

Las variables enteras soportan las operaciones sustituir, suma, resta, multipli-cación, división entera y módulo/resto.

Las variables booleanas soportan las operaciones sustituir, conjunción, disyun-ción y negación.

Las variables que son cadenas de texto permiten sustituir el texto o concate-narlo.

A continuación se describe lo que realiza cada operación:

Sustituir: modifica el valor anterior de la variable con uno nuevo.

Disyunción: ejecuta la operación disyunción booleana sobre la primera y lasegunda variable.

Conjunción: ejecuta la operación conjunción booleana sobre la primera y lasegunda variable.

Negación: ejecuta la operación negación booleana sobre la segunda variable.

Suma: suma el valor de la primera variable con el de la segunda.

Resta: resta el valor de la primera variable con el de la segunda.

Multiplicación: multiplica el valor de la primera variable por el de la segunda.

División entera: realiza la división entera del valor de la primera variable con elde la segunda.

Resto: halla el resto de la división entera entre el valor de la primera variable yel de la segunda.

Sustituir: concatena el texto de la primera variable con el de la segunda.

El uso principal de las variables, cuando ya tienen un valor, es el evaluar su valorcomparándolo con otra variable o un dato estático. Para ello, el motor permite reali-zar operaciones de comparación, y al igual que las operaciones de modificación solofuncionan si los dos tipos de las variables a comparar son iguales. En este caso losoperadores son compatibles para todos los tipos de variables, aunque su funcionali-dad sea distinta depediendo del tipo.

Los operadores disponibles son igual, distinto, mayor, mayor o igual, menor y menoro igual. A continuación se describe la comparación que se realiza dependiendo deloperador.

La condición es cierta:

Operadores enteros:

15


• Igual: si los dos enteros son iguales.

• Distinto: si los dos enteros son distintos.

• Mayor: si el primer entero es mayor que el segundo.

• Mayor o igual: si el primer entero es mayor que el segundo o si son iguales.

• Menor: si el primer entero es menor que el segundo.

• Menor o igual: si el primer entero es menor que el segundo o si son iguales.

Operadores booleanos:

• Igual: si los dos valores son iguales.

• Distinto: si los dos valores son distintos.

• Mayor: si el primer valor es verdadero y el segundo es falso.

• Mayor o igual: si el primero es verdadero o si los dos son falsos.

• Menor: si el primero es falso y el segundo es verdadero.

• Menor o igual: si el primero es falso o si los dos son verdaderos.

Operadores de cadenas de texto:

• Igual: si las dos cadenas son iguales.

• Distinto: si las dos cadenas son distintas.

• Mayor: si la primera cadena se sitúa posteriormente a la otra según el ordenlexicográfico.

• Mayor o igual: si la primera cadena se sitúa posteriormente a la otra segúnel orden lexicográfico o si las cadenas son iguales.

• Menor: si la primera cadena se sitúa anteriormente a la otra según el ordenlexicográfico.

• Menor o igual: si la primera cadena se sitúa anteriormente a la otra segúnel orden lexicográfico o si las cadenas son iguales.

2.1.9. Localización

Supongamos que un diseñador de juegos quiera hacer llegar su juego a la mayorcantidad de gente posible. Aparte de la barrera de los dispositivos que pueden repro-ducir ese juego, está la barrera del idioma. Aunque ciertos idiomas sean habladospor gran cantidad de gente alrededor del mundo, qué mejor que procurar un juegoen el idioma nativo del jugador.

Para ayudar a los diseñadores con este paso, el motor cuenta con soporte para todoslos idiomas recogidos en el estándar ISO 639-1 [8]. Este sistema se ha elegido porquees el estándar que recoge todos los idiomas de forma genérica, sin tener en cuentadiferencias regionales.

Para ello existen unos ficheros extra donde se pueden definir ciertas claves paraciertos literales de texto que quieren ser traducidos. De esta manera un diseñador

16


puede añadir idiomas extra incluso una vez ya desarrollado el juego. La forma deimplementación se describirá en la sección 2.3.

De ahora en adelante, si se habla de que una funcionalidad es localizable, significaque puede usar una clave que permita traducir el contenido a un idioma.

17

2.2. Qué esperar del sistema (Diseño)


En un mundo en el que todo el mundo puede acceder a miles de aplicaciones a travésde un dispositivo portátil que siempre llevan encima y en el que recibir informaciónes lo primordial, es muy importante el diseño que se tiene que llevar a cabo en unaaplicación.

Por ello, al desarrollar una aplicación para un teléfono móvil, uno de los factoresclave es que sea muy atractiva, bonita y usable. En esta sección se describirán laselecciones de diseño que se han llevado a cabo para las funcionalidades visualesdel motor, dividiéndolas en pantallas visuales. Están adjuntas capturas de la propiaaplicación para ayudar a la comprensión de ciertas decisiones.

2.2.1. Pantalla de menú principal

El menú principal es la primera pantalla de la aplicación. Sirve para iniciar la partidacargada, continuar una partida o cambiar el idioma del juego. Debido a que es laprimera pantalla del motor, está incluida una imagen con grandes cultivos que ase-mejan a un laberinto. Esta imagen no se puede cambiar, está fija y no depende deljuego cargado.

Nada más cargarse la aplicación, se cargan los ficheros de texto del juego cargado y seescoge un idioma. El idioma que se elige depende del usuario: si es la primera vez quecarga la aplicación, se escogerá uno que corresponda con algún idioma configuradoen el dispositivo. En otro caso, usa el lenguaje usado por última vez en la aplicación.

A continuación se describe la acción que debe realizar cada botón:

”Nueva partida”: permite iniciar una nueva partida. Para ello, el motor mos-trará una pantalla de carga mientras se encarga de descodificar los ficherosiniciales del juego, guardar la información en la base de datos, inicializar ciertosparámetros y cargar en disco las imágenes que se puedan descargar de Internet.

18


”Cargar partida”: recupera el estado de una partida guardada anteriormen-te. Como todos los datos ya están cargados en la base de datos, directamenteaparece el lugar en el que estuviera el jugador anteriormente.

”Cambiar idioma”: permite cambiar el idioma de la aplicación. Al pulsar navegadirectamente a la pantalla de cambio de idioma.

2.2.2. Pantalla de cambio de idioma

En esta pantalla se permite al usuario cambiar el idioma entre una lista de idiomassoportados en ese momento por el motor. La aplicación soporta cualquier lenguajerecogido en el estándar ISO 639-1 [8].

El fondo no se puede cambiar, aunque muy posiblemente cambie en un futuro muycercano. El idioma seleccionado actualmente es el que está marcado en azul. Unjugador puede seleccionar cualquier otro idioma para cambiar la selección, aunquelos cambios no se guardan hasta que el usuario pulse el botón de guardado en laparte inferior. Al pulsar guardar, se recarga la aplicación para que muestre todos lostextos en el idioma seleccionado.

19


2.2.3. Pantalla de habitación

La pantalla de habitación es donde se desarrolla la mayor parte de los eventos deljuego y es donde el jugador pasará más tiempo en una partida. Esta pantalla es laencargada de gestionar las acciones principales del jugador: moverse entre otras ha-bitaciones, abrir el menú secundario y ejecutar eventos según una serie de accionesincluidas en la habitación.

La vista cuenta con botones de acción en la parte inferior, un botón de informacióny un botón de bocadillo. Además el nombre de la misma está escrita en la partesuperior, y la imagen de fondo cambia según la habitación en la que se encuentre elusuario.

Esto es lo que ocurre si se pulsan en los distintos botones:

Botón de información: situado en la esquina superior izquierda, el botón deinformación muestra un diálogo que describe a la habitación en la que se en-cuentra el jugador.

Botón de bocadillo: situado en la esquina superior derecha, lleva al jugador almenú secundario.

Eventos: las acciones de eventos son los botones azules que siempre están enla parte inferior de la pantalla y representan las acciones que puede realizar eljugador en esa habitación. Al pulsar en uno de ellos, se ejecuta el evento quecontenga.

”Moverse”: es el botón azul que está ubicado en la parte inferior de la pantallacomo la última acción. Pulsarlo lleva al usuario a la pantalla de movimiento ode cambio de sala.

Normalmente una habitación cuenta como máximo con cuatro acciones, incluyendola de ”Moverse”, aunque soporta muchas acciones, técnicamente infinitas. Cuandoaparezcan más de cuatro acciones, entonces la vista de los botones se podrá despla-zar para mostrarlos todos.

20


2.2.4. Pantalla de movimiento

La pantalla de movimiento permite al jugador cambiar la posición de su personaje ynavegar en el laberinto de habitaciones. Se muestra una pantalla que se superpone ala de la habitación y que contiene el nombre de la habitación en la que se encuentrael usuario y unas flechas que le permiten elegir hacia qué dirección quiere moverse.

Al pulsar en una de las flechas, el jugador se moverá a la habitación que se encuentreen esa dirección, por lo que saldrá de la vista de movimiento y cambiará a la nuevahabitación.

El mapa del laberinto es aleatorio, cada vez que el usuario elija una habitación en laque todavía no ha estado presente, el motor recogerá una habitación que no se hayavisitado de entre todas las habitaciones configuradas en el juego y fijará su posición,por lo que el jugador podrá volver a visitarla si vuelve al mismo lugar. Mientras ellaberinto tenga varias salas disponibles sin visitar, el movimiento estará disponibleen cualquier dirección.

En ciertas ocasiones el motor usará una habitación genérica en lugar de las ha-bitaciones configuradas con el propósito de alargar el juego con eventos genéricosdeterminados por el diseñador. Estas salas normalmente tienen eventos como uncofre con contenido común, un enemigo débil...

Hay que resaltar que en el juego original el jugador cambiaba la dirección a la que mi-raba cada vez que se movía, simulando un movimiento real de forma más fiel, y paraorientarse contaba con una brújula que le permitía saber hacia que punto cardinalestaba mirando. Sin embargo, en esta aplicación todavía no se ha implementado estafuncionalidad, por lo que no existe este sistema de giro, el jugador siempre estarámirando hacia el mismo sitio.

21


2.2.5. Menú secundario

2.2.6. Inventario

2.2.7. Ejecución de eventos

La aplicación realiza una acción dependiendo del tipo de evento que se vaya a eje-cutar. Algunas de estas acciones muestran una vista que las representa y otras semantienen invisibles, transparentes para un jugador.

A continuación se describe la acción que realiza cada uno de los eventos, dependiendodel tipo:

2.2.7.1. Diálogo

Este evento está encargado de mostrar un mensaje para que el jugador pueda leerlo.Para ello, la aplicación muestra una pantalla por encima de la sala actual, el jugadorse mantiene en la misma sala, con ciertas características:

Mensaje: se muestra el mensaje recogido en el evento. Este mensaje es localiza-ble, por lo que se puede traducir a cualquier idioma.

Personaje: se muestra el nombre y la imagen de un personaje, para que el juga-dor reconozca quién está diciendo el mensaje.

Aunque la interfaz de la sala siga viéndose por detrás del diálogo, no se puede inter-actuar con ella. Si el usuario pulsa en cualquier sitio de la pantalla, se ejecutará elsiguiente evento.

2.2.7.2. Condición

Una condición es un evento transparente para el usuario, no se realizará ningúncambio en la UI. Sin embargo, como realiza operaciones rápidas no bloquea la expe-riencia de usuario.

22


2.2.7.3. Elección

La elección permite a un usuario recuperar el control de la aplicación y escoger entreuna serie de acciones descritas por el evento. Estas opciones aparecen si la condiciónque tienen anexa se cumple o si no tienen condición.

Muestra un mensaje localizable que insta al jugador a escoger una opción de entre lasseleccionadas. Además aparece la imagen del personaje usado en un evento anterior.

El jugador solo puede pulsar en uno de los botones que aparecen con las posibleselecciones. Si el usuario pulsa en cualquier otro sitio, no ocurrirá nada. Al pulsar enuna de estas opciones, se ejecutará el evento que corresponda.

2.2.7.4. Batalla

23


La batalla es una parte muy importante de la aplicación, ya que es uno de los lugaresdonde un jugador va a poder salir de la dinámica de explorar la mazmorra y entraren otra dinámica del juego. Además, debido a que el planteamiento del combate esmuy simple, se necesita que la interfaz sea lo más atractiva posible y que el combateen sí sea suficientemente fluido.

Un combate muestra a dos equipos enfrentados, el equipo del jugador contra el delenemigo. El equipo del jugador tiene que atacar al enemigo y viceversa, reduciendosus puntos de vida actuales respectivamente. Un luchador se considera derrotadocuando sus puntos de vida actual llegan a 0.

Gana el primer equipo que acabe con el representante del otro equipo, es decir, ganael equipo del enemigo si acaba con el protagonista y gana el equipo del protagonistasi acaba con el enemigo principal.

En el combate solo participan personajes jugables, es decir, personajes que conten-gan estadísticas. Si se intenta comenzar una batalla con un personaje que no tengaestadísticas, el evento de batalla no funcionará.

Respecto a la pantalla, debido a que en un combate se representa la lucha entredos equipos, hay una mitad de pantalla para cada equipo. En la parte superior seencuentra el bando enemigo. Se muestra una vista de estado con la información delenemigo y una imagen que representa al enemigo principal. En la parte inferior seencuentra el bando del jugador, mostrando las ventanas con la información de susluchadores y dos botones que permiten al jugador realizar acciones.

También se puede observar 3 cuadrados de información, dos para el equipo de juga-dor y uno para el enemigo. En este caso, los dos equipos muestran esencialmente lomismo. Aquí se describe qué indica cada dato de esta vista:

Nombre y foto del personaje: permite reconocer a cada luchador en la batalla.Cada luchador debería tener su propio nombre y foto para evitar confundir aljugador.

Vida actual: representa la vida actual de la que dispone en el momento el lucha-dor. Esta se reduce si un luchador contrario ataca al luchador, por lo tanto elnúmero varía. Además, los puntos de vida siguen un código de colores para ayu-dar al jugador a darse cuenta del estado en el que se encuentra ese luchador:si el color es verde significa que los puntos de vida actuales están al máximo, siel color es amarillo significa que los puntos están por debajo de un cuarto delmáximo, si el color es rojo significa que tiene 0 puntos, y en otro caso el colorserá blanco.

Vida máxima: representa el tope de vida que tiene un luchador.

Estado alterado: situado en la esquina superior derecha, representa el estadoalterado que puede sufrir uno de los personajes. Si el personaje no tiene ningúnestado alterado, entonces no aparece información al respecto.

Durante una batalla, el jugador solamente podrá controlar a su personaje, al prota-gonista. El resto de acciones, las realizadas por el resto del equipo del jugador y elequipo del enemigo, son calculadas automáticamente por la aplicación.

Respecto a las dos botones, representan las dos acciones que puede realizar un usua-rio.

24


Atacar: realiza la acción de atacar sobre el enemigo.

Inventario: lleva al usuario a la vista de inventario, para permitirle usar objetosde la misma manera que desde el menú secundario.

La batalla está diseñada prácticamente igual a la que se encontraba en el juego ori-ginal. Aunque esta vez la aplicación cuente con una interfaz que representa mejoruna pelea, el núcleo lógico de toda la pantalla es muy parecido al anterior. De todasmaneras, a continuación se describe cómo está diseñada la vista, funcionalmentehablando.

El combate sigue siendo por turnos, siguiendo el orden original: primero actúa elprotagonista, después el enemigo y por último el resto del equipo del jugador. Cadaturno cuenta con una serie de fases que le permite al jugador darse cuenta de lo queestá ocurriendo. En esta descripción, siempre se hablará del personaje que actúa enel turno como luchador y contrario como el personaje al que ataca el responsable delturno.

1. Fase de continuidad de estado alterado: el motor analiza el estado del luchador,y si tiene un estado alterado evalúa que el luchador pueda perder ese estadoalterado.

2. Fase de evaluación de daño de estado alterado: el motor analiza el estado delluchador y realiza ciertas acciones si tiene un estado alterado específico. Si elluchador está envenenado, entonces le hace una cantidad de daño al luchador;y si está paralizado hay una probabilidad de que pierda su turno.

3. Fase de introducción de acción: el motor pregunta al luchador qué acción quiererealizar. Si el luchador es el protagonista, el jugador podrá elegir una de las ac-ciones descritas anteriormente en los botones. En otro caso, el luchador siempredecidirá atacar al contrario.

4. Fase de ataque: el motor comienza el cálculo del ataque. Si no se dispone deobjetivo, el motor elige uno aleatoriamente del equipo contrario de entre los queestán vivos, es decir, tienen más de 0 puntos de vida actuales. Tras ello, el motorcalcula el daño que recibe el objetivo a partir de las estadísticas del luchador yel contrario. Se explica con más detalle esta fase más adelante. Además, si elluchador cuenta con el estado alterado ceguera, entonces es posible que falle elataque.

5. Fase de evaluación de daño contrario: el motor analiza el estado del contrario yevalúa si está derrotado.

Esta cadena de turnos se repite hasta que se da el caso de que uno de los represen-tantes de los equipos sea derrotado. Si el representante del equipo enemigo ha sidoderrotado, entonces se activa el evento de victoria. Si el protagonista es el derrotado,entonces se activa el evento de derrota.

Por último, ya que la fase de ataque es más compleja que el resto, se va a describirqué realiza exactamente el motor en esa fase:

1. Fase de obtención de arma: el motor evalúa si el luchador tiene un arma conla que luchar. Si es así, la carga en el sistema. Esta arma permite al luchadorobtener modificadores de fuerza, estado alterado y acierto, por lo que modifica

25


la fuerza del luchador, permite inflingir estados alterados al objetivo y tiene unporcentaje que determina si el luchador acierta un ataque.

2. Fase de cálculo de golpes: el motor se basa en la relación entre la agilidad delluchador y de su objetivo para calcular el número de golpes que efectuará elluchador. Para ello realiza la división entera entre la agilidad de los dos, y elresultado es el número de golpes que el luchador puede realizar. Después, cal-cula si el luchador puede fallar alguno de esos golpes. Si este no tiene arma,entonces acierta todos los golpes. En otro caso, usará el porcentaje definido enel arma para calcular los golpes que da.

3. Fase de cálculo de daño: si el luchador acierta ningún ataque, entonces terminasu turno. Si consigue acertar, entonces se calcula el daño teniendo en cuenta lafuerza del luchador y la defensa del enemigo, aparte del factor de fuerza extraque puede reportar un arma.

4. Fase de cálculo de estado alterado: si el luchador ha conseguido conectar algúngolpe y además lleva un arma equipada que puede causar un estado alterado,entonces hay una probabilidad de que se lo cause al objetivo.

2.2.7.5. Recompensa

La recompensa muestra al usuario una serie de objetos que consigue, especificadosen el evento. En la parte inferior se muestra un mensaje localizable del evento. En laparte superior se muestra una lista de objetos obtenidos por el jugador. Teóricamenteun jugador puede recibir tantos objetos como se especifique en el evento. Cada objetoestá representado con su nombre localizable, una cantidad que se recibe y una fotoindicando qué objetos se reciben.

26


2.3. Cómo crear un videojuego

En esta sección se define cómo crear un juego que sea compatible con el motor.Para ello, se dispone de una serie de ficheros que permiten a la aplicación cargar lainformación básica y empezar el juego. En esta sección se explicará para qué sirvecada fichero y cómo se deben rellenar.

Estos ficheros tienen formato YAML [12]. Este formato permite la manipulación dedatos serializables de forma sencilla tanto por el programador como por un usuario,es decir, son ficheros fáciles de transformar a código y son fáciles de interpretar ydiseñar por una persona.

Un fichero de este tipo sigue un formato ”clave:valor”. Todas las claves están definidasen inglés, para permitir que los diseñadores puedan tener un lenguaje común paracrear juegos. Algunas claves son opcionales. Si una clave es opcional, significa quepuede no aparecer o aparecer vacía.

2.3.1. Imágenes

Un diseñador puede crear o descargar sus propias imágenes para usarlas en el juego.Para ello existe una carpeta llamada ”images”, donde se deben guardar las imágenesnecesarias. En todo caso, si el diseñador prefiere generar un juego de manera que suselementos no pesen demasiado, el motor también soporta la descarga de imágenespor Internet, siempre teniendo en cuenta que sólo puede descargar imágenes de URLscon soporte SSL a través del protocolo HTTPS, es decir, que comiencen por ”https”.El motor acepta archivos con tipos comunes, como JPEG o PNG. No se asegura lacompatibilidad con otros tipos de ficheros.

Para representar una imagen hay que especificar el origen de la imagen y el lugardonde se encuentra el recurso. El origen puede ser tanto local como remoto. Si elorigen es local, el diseñador debe especificar el nombre del fichero al que quiereacceder. Si el origen es remoto, el diseñador debe especificar la URL que contiene laimagen.

1 #Si el fichero es remoto:2 imageSource:3 type: remote4 source: "https://imgur.com/zNGi05P.png"5

6 #Si el fichero es local:7 imageSource:8 type: local9 source: "tarta.jpg"

2.3.2. Literales localizables

En la pantalla de cambio de idioma se hacía referencia a la posibilidad de definirliterales de texto que podían ser traducidos. Un literal suele ser una frase que resumela traducción del texto. Normalmente se encuentran de la forma "literal- "traducción".

La información de los idiomas se guarda en la carpeta ”texts”, donde se encuentraun fichero para cada idioma que se quiera implementar. Estos ficheros son los quealbergan esos literales y sus traducciones. Es importante repetir que solo se puede

27


usar un fichero para cada idioma, es decir, si se quiere que el juego esté disponibleen español e inglés, entonces en la carpeta ”texts” debe haber dos ficheros, uno parael español y otro para el inglés.

Los archivos deben llamarse siempre <codigo_iso639-1_del_idioma>.strings [8] paraque el sistema sea capaz de reconocerlos. A continuación se muestra un ejemplo decómo se deben rellenar:

1 #es.strings2 "newGameButton" = "Nueva partida";3 "loadGameButton" = "Cargar partida";4 "gameTitle" = "Historias del Laberinto";5 "changeLanguageButtonText" = "Cambiar idioma";6 "room17LookAroundMessage" = "Miras a tu alrededor";7

8 #en.strings9 "newGameButton" = "New game";

10 "loadGameButton" = "Load game";11 "gameTitle" = "Labyrinth adventures";12 "changeLanguageButtonText" = "Change language";13 "room17LookAroundMessage" = "You take a look at your surroundings.";14 #Los ; situados al final son muy importantes para que los textos puedan ser cargados.

Para añadir un texto localizable a cualquier parte del juego, hay que usar el literal envez de su traducción.

1 #En vez de poner una traduccion directa en el fichero correspondiente...2 - id: "room17LookAround"3 mode: "dialogue"4 message: "Miras a tu alrededor"5 characterId: "narrator"6 nextStep: "room17LookAround2"7

8 #se usa el literal.9 - id: "room17LookAround"

10 mode: "dialogue"11 message: "room17LookAroundMessage"12 characterId: "narrator"13 nextStep: "room17LookAround2"

2.3.3. Condiciones

No existe un fichero específico para las condiciones, implicaría más complicaciónpara desarrollar los ficheros, aunque permitiría añadir orden. Sin embargo, se añadeesta subsección para hablar de cómo modelizar condiciones en los ficheros. Todaslas condiciones se modelan igual en todos los sitios, para evitar confusiones.

1 # Existen varios tipos de condiciones:2 # Companero3 condition:4 kind: "partner"5 required: "gerar" # Id del companero que sigue al protagonista.6

7 # Objeto8 condition:9 kind: "item"

10 required: "potion" # Id del objeto que tiene que tener el protagonista. Si se cumpleesta condicion, entonces el protagonista perdera una unidad de ese objeto.

11

12 # Habitacion visitada13 condition:

28


14 kind: "roomVisited"15 required: "startRoom" # Id de una sala. Es cierta si la sala ya se ha visitado.16

17 # Habitacion sin visitar18 condition:19 kind: "roomNotVisited"20 required: "startRoom" # Id de una sala. Es cierta si la sala todavia no se ha visitado

.21

22 # Variables23 condition:24 kind: variable25 required:26 compareToId: "numberOfApples" # Id de la variable del lado izquierdo de la

comparacion.27 relation: equal # Operacion de relacion entre las variables.28 initialVariable: # Opcional. Variable con informacion estatica para el lado

derecho de la comparacion. Si este campo no aparece, debe aparecer el dela siguiente condicion. En otro caso, no funcionara el evento que contengaesta condicion.

29 type: integer30 value: 1031

32 condition:33 kind: "variable"34 required:35 compareToId: "numberOfApples"36 relation: equal37 initialVariable: "cupcakes" # Opcional. Id de la variable del lado derecho de

la comparacion. Si este campo no aparece, debe aparecer el de la condicionanterior. En otro caso, no funcionara el evento que contenga estacondicion.

2.3.4. Personajes

Este fichero define todos los personajes que van a aparecer a lo largo del juego, juntocon toda la información que necesiten. Se debe llamar ”characters.yml”.

1 playable: #Incluye los personajes con estadisticas de combate.2 "gerar": #Id del personaje. Debe ser unico. Representa al personaje3 name: "Gerardo" #Nombre del personaje. Este se mostrara en el juego.

Localizable.4 currentHealthPoints: 300 #Puntos de vida actuales. Este dato solo sirve para

el principio del juego, no representa el estado del juego.5 maxHealthPoints: 300 #Puntos de vida maximos.6 attack: 15 #Puntos de ataque.7 defense: 15 #Puntos de defensa.8 agility: 4 #Puntos de agilidad.9 weapon: "magic_sword" # Opcional. Indica el id del arma que porta el

protagonista.10 imageSource: #Imagen grande del personaje. Se usa en dialogos.11 type: remote12 source: "https://imgur.com/zNGi05P.png"13

14 portraitSource: #Imagen reducida del personaje. Se usa en la vista de estadodel personaje.

15 type: remote16 source: "https://i.imgur.com/g3WIUf4.png"17

18 notPlayable: #Incluye los personajes que no tienen estadisticas de combate. Aunque se incluyaa un personaje con estadisticas aqui, no se podra usar como personaje en batallas.

19 "narrator": #Id del personaje. Debe ser unico. Representa al personaje.20 name: "Narrador" #Nombre del personaje. Este se mostrara en el juego.

Localizable.21 imageSource: #Imagen grande del personaje. De tipo remoto.22 type: remote23 source: "https://i.imgur.com/Upcm999.png"

29


24

25 "aurelionSol":26 name: "Aurelion Sol"27 imageSource: #Imagen grande del personaje. De tipo local.28 type: local29 source: "aurelionSol.PNG"

Todas las estadísticas que se rellenen con números deben ser enteros. El motor nofuncionará si se incluye un número con decimales.

2.3.5. Protagonista

El protagonista, el personaje controlado por el jugador, tiene su propio fichero. Mu-chas de las estadísticas son iguales, pero tiene cierta información extra. El nombredel fichero es ”prota.yml”.

1 name: "Cisco" # Nombre del protagonista. Localizable.2 partner: "gerar" # Opcional. Id del personaje que viaja con el protagonista. Debe ser un

personaje con estadisticas.3 imageSource: # Imagen grande del protagonista.4 type: remote5 source: "https://vignette.wikia.nocookie.net/megamitensei/images/6/63/Persona_5_Hero.

png"6 portraitSource: # Imagen reducida del protagonista.7 type: remote8 source: "https://vignette.wikia.nocookie.net/megamitensei/images/1/14/P5_manga_Akira.

jpg"9

10 currentHealthPoints: 590 # Puntos de vida actuales. Este dato solo sirve para el principio deljuego, no representa el estado del juego.

11 maxHealthPoints: 590 # Puntos de vida maximos.12 attack: 30 # Puntos de ataque.13 defense: 10 # Puntos de defensa.14 agility: 10 # Puntos de agilidad.15 weapon: "magic_sword" # Opcional. Indica el id del arma que porta el protagonista.16

17 items: # Objetos que porta el protagonista al principio de la aventura.18 "potion": 1 # Este objeto tiene el id del objeto como clave y la cantidad de la que se

dispone como valor.19 "high_potion": 220 "small_key": 1

El protagonista no tiene id, por lo que su id es siempre "prota".

2.3.6. Objetos

El fichero de objetos recoge todos los objetos que se pueden encontrar a lo largo deuna partida. Se guardan en un archivo llamado ”items.yml”.

Los objetos tienen un id, un nombre, una descripción, un tipo y una imagen asociada.Hay tres tipos de objetos: consumibles, armas y clave.

Consumibles: incluyen un campo obligatorio que indica la cantidad que aumen-ta o disminuye los puntos de vida actuales de un personaje.

Objetos clave: representan un objeto que se usará para ciertas condiciones. Notienen más campos.

Armas: objetos que usan los personajes para atacar. Podrán tener opcionalmen-te una estadística de fuerza extra, un porcentaje de acierto y un estado alterado

30


que provocan junto con un porcentaje de provocarlo. Si no está el campo defuerza extra, se supondrá que es 0. Si no está el campo de estado alterado, sesupondrá que es "ninguno".

Si un objeto aparece en algún sitio y no está en este fichero, entonces se tratará comosi no estuviera dentro del inventario.

1 consumableItems: # Objetos consumibles2 "potion": # Id del objeto.3 name: "Pocion" # Nombre del objeto. Localizable.4 description: "Restaura puntos de vida." # Descripcion del objeto. Localizable.5 imageSource: # Imagen del objeto6 type: remote7 source: "https://cdn.bulbagarden.net/upload/2/2e/GO_Potion.png"8 healthRecovered: 40 # Cantidad de puntos de vida actual que recupera un

personaje si lo usa. Puede ser negativo.9

10 keyItems: # Objetos clave11 "small_key": # Id del objeto.12 name: "Llave" # Nombre del objeto. Localizable.13 description: "Una llave." # Descripcion del objeto. Localizable.14 imageSource: # Imagen del objeto15 type: local16 source: "small_key.png"17

18 weapons: # Armas19 "poisoned_bow": # Id del objeto.20 name: "Arco envenenado" # Nombre del objeto. Localizable.21 description: "Un arco que puede provocar veneno." # Descripcion del arma.

Localizable.22 imageSource: # Imagen del arma23 type: local24 source: "ModernBowFarket.png"25 extraDamage: 0 # Dano extra que puede causar el luchador con el arma.26 hitRate: 94 # Porcentaje de acierto con el arma equipada.27 inducedAilment:28 ailment: "poison" # Estado alterado que puede causar el arma.29 induceRate: 32 # Probabilidad de causar el estado alterado al atacar a

un contrario.

2.3.7. Variables

El fichero de variables recoge información sobre las variables que quiera el diseñadortener inicializadas desde el principio. El nombre del archivo es ”variables.yml”.

1 - name: "isShieldActive" # Id de la variable. Unico2 content:3 type: boolean # Tipo del dato de la variable.4 value: false # Dato contenido en la variable.5

6 - name: "numberOfApples" # Id de la variable. Unico7 content:8 type: integer # Tipo del dato de la variable.9 value: 0 # Dato contenido en la variable.

10

11 - name: "partnerName" # Id de la variable. Unico12 content:13 type: string # Tipo del dato de la variable.14 value: "Gerardo" # Dato contenido en la variable.

31


2.3.8. Habitaciones

El fichero de las salas recoge todas las salas que se podrán visitar durante el juego.El fichero que las contiene se llama ”rooms.yml”.

Una sala está representada por un id que la identifica, un nombre, una descripción,acciones posibles en la sala, una imagen, un id de un evento que se ejecuta al entrara la sala. Las acciones posibles en una sala tienen un nombre, un id de evento ycondiciones de que aparezcan. Si la acción aparece siempre, el campo condición nodebe estar en la acción. Además, existen salas genéricas que sirven para provocareventos genéricos, tendrán un campo que indiquen que son genéricas.

1 rooms:2 "room17":3 id: "room17" # Id que identifica a la sala. Unico.4 name: "Primera habitacion" # Nombre de la sala. Localizable.5 description: "Esta es la primera habitacion" # Descripcion de la sala.

Localizable.6 imageSource: # Imagen de la sala en la pantalla.7 type: local8 source: "cave-near-body-of-water-at-sunset-931910.jpg"9 startEvent: "firstEvent" # Opcional. Ejecuta el evento con este id al entrar a

la sala.10 actions: # Acciones que se pueden realizar en una habitacion.11 - action: "Hablar" # Nombre de la accion. Localizable.12 nextStep: "room17Conversation" # Id del evento a ejecutar al pulsar

la accion.13 condition: # Opcional. Condicion para que aparezca esta accion.14 kind: "partner"15 required: "gerar"16 - action: "Observar" # Nombre de la accion. Localizable.17 nextStep: "room17LookAround" # Id del evento a ejecutar al pulsar la

accion.18

19 "genericRoom1":20 id: "genericRoom1" # Id que identifica a la sala. Unico.21 name: "Habitacion generica" # Nombre de la sala. Localizable.22 description: "Esta es una habitacion generica" # Descripcion de la sala.

Localizable.23 imageSource: # Imagen de la sala en la pantalla.24 type: local25 source: "orange-and-brown-cave-1533483.jpg"26 isGenericRoom: true # Opcional. Indica que la habitacion es generica.27 actions: # Acciones que se pueden realizar en una habitacion.28 - action: "Observar" # Nombre de la accion. Localizable.29 nextStep: "emptyRoomTalk" # Id del evento a ejecutar al pulsar la

accion.

2.3.9. Eventos

Los eventos será el fichero con más información comparado con el resto. Es donde seguardan todos los eventos que se van a poder ejecutar durante el juego. El nombredel fichero es ”events.yml”.

Antes de comenzar, todos los eventos tienen una serie de características comunesentre ellos:

Identificador: todos los eventos cuentan con un id, y este debe ser único. No seasegura que dos eventos con identificadores idénticos funcionen a la vez.

Habitación visitada: un evento puede marcar que la habitación en la que está eljugador en el momento ha sido visitada.

32


Final del juego: un evento puede activar el fin del juego. Si esto ocurre, enton-ces al terminar la cadena de eventos actual el jugador será llevado al menúprincipal.

Los eventos permiten realizar pequeñas acciones programables durante la ejecucióndel juego. Los diferentes tipos de eventos que se han definido para el motor son:

Diálogo: tiene un id que lo identifica, un mensaje, un id del personaje que loemite y un evento siguiente asociado.

Elección: tiene un id que la identifica y un campo que recoge redirecciones aotros eventos. La elección tendrá en un bloque entre una y múltiples accionesque tienen asociado un id de evento.

Condición: tiene un id que lo identifica, una condición, un id de evento asociadosi se cumple y otro si no se cumple.

Recompensa: tiene un id que la identifica, un mensaje, una lista de pares deobjetos conseguidos junto con una cantidad y un evento siguiente asociado.

Batalla: tiene un id que la identifica, el id del personaje enemigo, un id de unevento que se ejecuta cuando gana el jugador y otro que se ejecuta cuandopierde.

Modificar variable: tiene un id que lo identifica, un id de variable a modificar,una operación, una variable con la que operar y un evento siguiente asociado.

1 # Dialogo2 - id: "room17Conversation_WithGerar" # Id de evento. Unico.3 mode: "dialogue" # Tipo de evento. Hay que poner el tipo para que el motor lo reconozca.4 message: "room17Conversation_WithGerar_message" # Mensaje que se muestra en el dialogo.

Localizable.5 characterId: "gerar" # Id del personaje que enuncia el dialogo.6 nextStep: "room17Conversation_WithGerar_2" # Opcional. Id del evento siguiente de la cadena.7

8 # Condicion9 - id: "room17Conversation" # Id de evento. Unico.

10 mode: "condition" # Tipo de evento. Hay que poner el tipo para que el motor lo reconozca.11 condition:12 kind: "partner"13 required: "gerar"14 nextStepIfTrue: "room17Conversation_WithGerar" # Id del evento que se ejecuta si la

condicion es cierta.15 nextStepIfFalse: "room17Conversation_3" # Id del evento que se ejecuta si la condicion es

falsa.16

17 # Eleccion18 - id: "room17Conversation_WithGerar_2" # Id de evento. Unico.19 mode: "choice" # Tipo de evento. Hay que poner el tipo para que el motor lo reconozca.20 options: # Lista de acciones que tiene el evento.21 - action: "Valep" # Nombre de la opcion. Localizable.22 nextStep: "room17StartBattle" # Opcional. Id del siguiente evento a ejecutar si se

escoge esta accion.23 condition:24 kind: "partner"25 required: "gerar"26 - action: "Mejor no" # Nombre de la opcion. Localizable.27 nextStep: "" # Opcional. Id del siguiente evento a ejecutar si se escoge esta accion

.28

29 # Batalla30 - id: "room17StartBattle" # Id de evento. Unico.31 mode: "battle" # Tipo de evento. Hay que poner el tipo para que el motor lo reconozca.32 enemyId: "eternalGod" # Id del personaje contra el que luchar. Debe tener estadisticas.

33


33 winStep: "room17BattleReward" # Opcional. Id del siguiente evento a ejecutar si el jugadorgana.

34 loseStep: "exampleEnding" # Opcional. Id del siguiente evento a ejecutar si el jugadorpierde.

35

36 # Recompensa37 - id: "room17BattleReward" # Id de evento. Unico.38 mode: "reward" # Tipo de evento. Hay que poner el tipo para que el motor lo reconozca.39 message: "room17BattleRewardMessage" # Mensaje que se muestra en el dialogo. Localizable.40 rewards: # Lista de recompensas en forma de objetos41 "potion": "2" # A la derecha el id del objeto como clave y la cantidad que se recibe

como valor.42 "high_potion": "1"43 nextStep: "" # Opcional. Id del evento siguiente de la cadena.44

45 # Modificar variable46 - id: "addNumberToCount" # Id de evento. Unico.47 mode: "modifyVariable" # Tipo de evento. Hay que poner el tipo para que el motor lo

reconozca.48 variableId: "countNumber" # Id de la variable a modificar.49 operation: add # Operacion que se realiza en la modificacion.50 initialVariable: # Opcional. Variable estatica para el lado derecho de la operacion. Si este

campo no aparece, debe aparecer el del siguiente evento. En otro caso, no funcionara.51 type: integer52 value: 153 nextStep: "" # Opcional. Id del evento siguiente de la cadena.54

55 - id: "addNumberToCount" # Id de evento. Unico.56 mode: "modifyVariable" # Tipo de evento. Hay que poner el tipo para que el motor lo

reconozca.57 variableId: "countNumber" # Id de la variable a modificar.58 operation: add # Operacion que se realiza en la modificacion.59 initialVariableName: "variableName" # Opcional. Id de la variable del lado derecho de la

operacion. Si este campo no aparece, debe aparecer el del evento anterior. En otro caso,no funcionara.

60 nextStep: "" # Opcional. Id del evento siguiente de la cadena.

34

Capítulo 3

Desarrollo de la aplicación

Una vez descrito el funcionamiento del motor de forma genérica, ahora queda exponerlas partes más específicas de la implementación actual de la aplicación.

En las próximas secciones se comentará cuál ha sido la metodología de trabajo du-rante todo el proyecto y cómo está desarrollado el motor en este momento. Se ofrecerátambién una pequeña descripción de las tecnologías usadas en el camino.

3.1. Planificando los objetivos

En el desarrollo de cualquier proyecto de gran calado, en nuestro caso de una apli-cación, se necesita algo fundamental para que el desarrollo llegue a buen término:tener muy claro qué es lo que se va a desarrollar y cómo.

Durante toda mi experiencia en la empresa, he estado trabajando en un equipo dedesarrollo, programando también aplicaciones. Gracias a esto, me di cuenta de laimportancia de tener el trabajo bien ordenado, y además he aprendido alguna manerade llevar esto a cabo. Por ello, decidí en el momento que debía tener una forma deorganizarme para poder sacar el proyecto adelante.

Un error que cometí durante el desarrollo del juego original fue que no tenía ningúnorden a la hora de desarrollar funcionalidades: durante la programación se me ocu-rrían ideas nuevas que hacían que perdiera el foco de lo que estaba haciendo en elmomento. Por eso, uno de mis defectos era que algunas funcionalidades no las im-plementaba completamente, sino que las dejaba a la mitad, incluso inservibles, hastaque me diera cuenta en un futuro.

Como no quería que esto ocurriese durante el desarrollo, no podía permitirme unaaplicación que solo funcionara a veces, entonces decidí ejecutar el mismo marco detrabajo que uso en la oficina. De esta manera, empecé a trabajar con Scrum.

3.1.1. Qué es Scrum

Scrum es un marco de trabajo que permite a los desarrolladores tener una formade trabajar establecida, ayudándolos a seguir pautas ya establecidas para colabo-rar en equipo y conseguir información de forma rápida y eficaz. Si se necesita más

35

3.1. Planificando los objetivos

información sobre esta metodología, existe una guía mantenida por parte de susdesarrolladores [9].

Estas son las ventajas que aporta Scrum al desarrollo:

Desarrollo iterativo: las funcionalidades de una aplicación se desarrollan en ci-clos de dos semanas (”sprints”). Esto permite volver sobre el desarrollo anterioren estos ciclos y mejorarlo o desarrollar algo nuevo sobre lo anterior.

Trabajo colaborativo: está pensado para que varios participantes en un equipotrabajen a la vez sin interrumpirse entre ellos. Además, esto también permiteque entre todo el equipo puedan revisar el trabajo de otro, detectando posiblesfallos.

Requisitos: para poder comenzar el desarrollo con Scrum no se necesita tenerel producto completo definido, se puede aprovechar el tiempo de desarrollo paradefinir más requisitos conforme a lo que se está desarrollando en el momen-to. Además, todas las funcionalidades están descritas en historias de usuario,que son unos requisitos que incluyen más información sobre cómo desarrollarexactamente las funcionalidades.

Aunque durante este proyecto no he podido disfrutar del trabajo en equipo con otragente, sí que he ido buscando la aprobación del código de otras personas. Además,el poder adaptar los requisitos a las nuevas necesidades que me surgieran duranteel desarrollo ha ayudado mucho a que surgieran más funcionalidades útiles para elmotor.

Volviendo a la definición de Scrum, se va a describir los roles que dispone y las fasesque se llevan a cabo durante el desarrollo.

Las figuras más destacadas son:

Product owner: normalmente identificado con el cliente, es el encargado de de-finir requisitos, ayudar a generar historias de usuario y preocuparse de que lasfuncionalidades se desarrollen.

Scrum master: no es el jefe del equipo de desarrolladores, sino más bien elencargado de que todo el proceso de Scrum salga bien. Trata de solventar todoslos problemas que puedan surgir durante el desarrollo y que impidan que losdesarrolladores lleguen a cumplir los objetivos de los ”sprints”. Además sirve depuente entre el product owner y su equipo, encargándose de toda interacciónentre ellos.

Equipo de desarrolladores: son los responsables de desarrollar el producto. Sue-len formarse equipos pequeños para ayudar a la comunicación en el mismo.

36


Las fases de Scrum son:

Product backlog: el product owner se encarga de definir los requisitos y diseñarla carga de tareas de los sprints.

Sprint backlog: todo el equipo de Scrum se encarga de crear las historias deusuario conformes a los requisitos. Se balancea la carga de los sprints si esnecesario.

Sprint: los desarrolladores empiezan el desarrollo de las tareas. Esta fase sueledurar unas dos semanas. Cada día se celebra una reunión que permite al Scrummaster y al resto del equipo de desarrolladores cómo va el desarrollo.

Demo: al final del sprint, se realiza una demostración de las funcionalidadescubiertas por el sprint.

Retrospectiva: reunión final del ciclo en la que se reune todo el equipo en la quese evalúa el resultado del sprint, se plantean problemas que hayan ocurrido yse formulan soluciones para la siguiente iteración.

Aunque al final no he tenido la ocasión de realizar todas las reuniones pero ha va-lido la pena este método para ordenar mi trabajo y guardar la información de losrequisitos.

3.2. Desarrollando en dispositivos móviles (Arquitectura)

En esta sección se discutirá cómo se ha desarrollado la aplicación y con qué tecnolo-gías se ha llevado a cabo.

El motor está ahora mismo desarrollado para dispositivos móviles de Apple, en ellenguaje de programación Swift [10].

Swift es un lenguaje de programación de propósito general. Fue anunciado en 2014y es de código abierto. Este proyecto está desarrollado específicamente con la versión5 de Swift.

Existen muchas formas de programar aplicaciones en Swift: usando arquitecturasnativas como MVC o yendo a ejemplos de arquitecturas limpias como Viper y Clean-

37


Swift. Sin embargo, debido a que una de las recomendaciones de los pensadoresdetrás de las arquitecturas limpias es que la arquitectura debe adaptarse a las ne-cesidades del desarrollador, en este proyecto se ha llevado a cabo una mezcla entreestas dos últimas arquitecturas.

Para este proyecto se ha planteado desde el principio de su desarrollo una imple-mentación mediante una arquitectura con capas que permita separar elementos dela programación con distintas funcionalidades. Se tomó la decisión de seguir esta ar-quitectura ya que permite que el código esté modularizado y sea fácil de implementarsiguiendo un esquema. En la anterior arquitectura, MVC (Model-View-Controller), seincluía toda la lógica de negocio de la aplicación en los controladores, haciendo muycomplicado el mantenimiento del código y la implementación de nuevas funcionali-dades.

Proporcionaré el punto de vista de trabajo mediante Xcode el programa especializadoen compilar ficheros “swift”.

El proyecto está específicamente dividido en 3 capas.

3.2.1. Capa de presentación

Nivel que se encarga de la interfaz visual que el usuario puede ver y tocar. Esto abarcatodos los elementos visuales presentes en la aplicación, como la pantalla de inicio ola pantalla de carga. Las vistas se han implementado de esta manera:

”Storyboard”: archivo XML específico de desarrollo en iOS para Objective-C ySwift que recoge toda la información de todos los elementos de una pantallacomo pueden ser un botón, la barra de navegación o un deslizador. Incluyetodos los elementos que mantienen fija la pantalla, aunque el dispositivo roteo la resolución de la pantalla cambie. Estos ficheros se traducen en tiemporeal en el entorno de desarrollo, Xcode, para mostrar una vista previa de loselementos en un dispositivo y proporcionar herramientas para ajustar todos

38


los elementos de una vista, todo mediante el llamado ”Interface Builder”. Estefichero no contiene código en lenguaje Swift en ningún momento.

”View Controller” o controlador de la vista: archivo Swift que incluye informa-ción referente a una vista, que puede estar asociada a un ”storyboard” y quesiempre aparece en conjunto con un presentador. Este fichero contiene toda lainformación que conecta lo que se muestra en un dispositivo y las acciones quedeben ocurrir al realizar eventos. Tiene una referencia a todos los elementos deuna vista, y se encarga de modificarlos. En nuestra implementación, los contro-ladores no pueden mantenerse por sí solos, pues solo saben rellenar los datosde los elementos presentes en una vista, como ponerle un nombre a un controlo asociar una acción a un botón, pero no saben cómo tienen que rellenar loselementos.

”Presenter” o presentador: archivo Swift que incluye toda la información pararellenar una vista, pero que no tiene acceso a sus elementos. Este fichero tienesiempre asociado un controlador de la vista para saber a cuál tiene que man-darle los datos. Contienen toda la información con la que se va a rellenar unavista, como la navegación de una pantalla a otra, el color de los elementos oel lanzamiento de interactores. Suelen contener todas las referencias a los ob-jetos que necesitará una vista para ser rellenada: un enrutador, el controladoral que está asociado, y un protocolo a seguir para que el controlador sepa quéelementos usar de un presentador.

”Router” o enrutador: archivo Swift que incluye toda la información necesariapara navegar a otras vistas en la aplicación, como puede ser ir desde el menúprincipal a uno secundario. Incluye la referencia al controlador de la vista ac-tual, de manera que le permite cambiarlo por otro durante el transcurso de laaplicación. También es el encargado de crear el presentador y su controladorasociado pertinentes para la nueva vista a mostrar.

3.2.2. Capa de negocio

Nivel que se encarga de ejecutar la lógica de negocio de la aplicación. En esta capase ejecutan todas las acciones que requieren de cierta lógica, como puede ser elcálculo de una operación matemática, el acceso a una base de datos o la utilizaciónde algoritmos complejos. Esta capa incluye dos tipos de clase principales:

Objetos de dominio: objetos de negocio que se encargan de modelizar todas lasposibles estructuras posibles de un objeto en la aplicación. Pongamos el ejemplode una aplicación de cartas: una carta sería un objeto que representa una ins-tancia de la clase Carta y que contiene toda la información que la define comoel palo o el número.

”Interactor”, o interactores: archivo Swift que incluye una funcionalidad espe-cífica para la aplicación. Estos interactores operan con los objetos de dominioy con la capa de datos para ofrecer los resultados de una operación a los pre-sentadores. Una de estas operaciones puede ser sumar dos valores, o recogerinformación específica de una base de datos.

39


3.2.3. Capa de datos

Nivel que incluye todas las clases con acceso a la base de datos. Estas clases sim-plemente sirven como puente para la funcionalidad de las librerías propietarias, esdecir, desarrolladas por el equipo o de consumo único por la aplicación. La base dedatos que se ha usado en este proyecto es una nativa ofrecida por Apple, Core Data[11]. Esta base de datos permite guardar objetos directamente, sin tener que realizarconsultas complicadas. Está basada en una base de datos SQlite.

40

Capítulo 4

Qué tal ha ido el desarrollo(Resultados y conclusiones)

Resumen de resultados obtenidos en el TFG. Y conclusiones personales del estudian-te sobre el trabajo realizado. Este trabajo de fin de grado me ha afectado de muchasmaneras:

Gracias al proyecto he podido plasmar mis conocimientos adquiridos durantetodo mi proceso de aprenidzaje, durante la universidad. Que hayamos podidoempezar desde tan poco en Programación I a llegar a crear una aplicación móvilfuncional muestra una evolución evidente en tan solo cinco años. Todavía quedamucho más que aprender, tecnologías que estudiar y otras áreas que emprender,pero es un gran paso hacia el futuro.

No podría haber hecho sin toda la experiencia que adquirí en el trabajo: cómousar un control de versiones para mantener la aplicación, adquirir desde ceroel lenguaje Swift, orientado en este caso a dispositivos móviles, sin tener co-nocimiento de ello en la universidad; aprender los métodos de trabajo de unaempresa de desarrollo de software. Y sobre todo, la paciencia y las ganas quehan tenido de enseñarme todos los compañeros con los que me he cruzado enla empresa.

Ha permitido poder llegar a participar en el desarrollo de un videojuego. Aunquesea un proyecto simple, todavía es un desarrollo que no ha terminado y quetodavía tiene mucho que ofrecer, por lo que seguiré en el desarrollo de manerque algún día podamos ver todas las funcionalidades suficientes para que se lepueda llamar un juego en toda regla.

Historias del Laberinto me ha acompañado durante la mayor parte de la carrera, porlo que es un proyecto que siempre quise llegar a ver finalizado, por todas las cosasque podría llegar a enseñarme y por la satisfacción que produce ver un proyectodesarrollado por ti terminado, mi primer proyecto de verdad. Sin embargo, puedodecir que esto no es el fin del proyecto, porque los tiempos y las necesidades cambian,porque todavía queda mucho para que el motor alcance su culmen de capacidad yporque sé que este tipo de proyectos pueden llegar a mucha gente que les guste estetipo de juegos o diseños.

Agradecer también a mi tutor el haber aceptado en un primer lugar este trabajo, y la

41

4.1. Futuro del intérprete (Trabajo futuro)

ayuda para centrarme en objetivos clave del proyecto y desarrollar este trabajo.

También darle las gracias a todos los amigos que he hecho durante mi periodo enla universidad: multitud de opiniones, buenas ideas y ánimos cuando más faltaban.Agradecer personalmente además a Andrea del Nido y Andrea de las Heras, porquesin su imaginación, ideas y otros puntos de vista el proyecto no podría haber salidoadelante, o no habría sido interesante mejorarlo.


Aunque es cierto que lo que se ha marcado como objetivo es suficiente para un trabajode fin de grado, el motor todavía está en una fase temprana de su desarrollo, conmucho potencial por todas partes que permita a un usuario o un diseñador de juegosaprovechar hasta la última capacidad de crear juegos para móviles de forma sencilla.

Por ello, en esta sección se describirán algunas de las funcionalidades que alguna vezaparecieron durante el desarrollo pero se descartaron o posibles nuevas funcionali-dades.

4.1.1. Versiones

Durante el desarrollo se han tenido que llevar a cabo varios mantenimientos que noson compatibles con el ciclo de vida de una aplicación normal para un usuario final.Estos problemas todavía no se han resuelto porque la aplicación estaba en desarrolloy no se suponía disponible para el público. Sin embargo, ahora que sí está disponible,se tendrán que solucionar para futuras versiones.

Al modificar las tablas o las propiedades de la base de datos, Core Data inutilizala base de datos original y no permite lanzar la aplicación. La única soluciónrápida pasa por reinstalar la aplicación. Al no disponer de migrado automáti-co de tablas, esto requiere un extra de funcionalidad que no dio tiempo a serimplementado.

Los juegos realizados para una versión del motor no tienen porqué ser compa-tibles entre sí: puede ocurrir que lleguen a funcionar y que la funcionalidad nosea completa, o que el juego sea directamente injugable. Falta establecer unaserie de versiones del sistema según ciertas actualizaciones y avisar al jugadoro al diseñador de historias de que el juego puede no ser compatible para ciertasversiones.

4.1.2. Música

Apple cuenta con muchas librerías en Swift que ofrecen funcionalidades extra a losdispositivos de su marca. Una de ellas es ”Media Player” [4]. Esta librería nos ofrecemuchas funcionalidades, como reproducir sonidos o música.

Está pensado ofrecer herramientas a los diseñadores de juegos para poder usar supropios sonidos y música en los juegos, para que se reproduzcan en sitios específicos.Los sonidos y la música podrían ser activados por un evento nuevo, y se podría añadirmúsica específica para batallas, el menú o las salas.

42

Qué tal ha ido el desarrollo (Resultados y conclusiones)

Por último, un usuario podría modificar la música que se reproduce en algunos sitiospor una de su propia biblioteca.

4.1.3. Menú de estado

En la historia de usuario está definido que en el menú secundario puedes tocar en lospersonajes y te saldría una pantalla de estado. Sin embargo, esta funcionalidad noestá disponible todavía, por lo que es una de las prioridades para la siguiente versióndel motor.

4.1.4. Modificar interfaz

Por el momento la interfaz cuenta con cajas y botones de color azul, pero esto puedesuponer un problema si hay alguna sala cuya imagen sea de este mismo color. Porello, se quiere añadir un ajuste que permite al diseñador y a un usuario escoger elcolor de la interfaz según unos deslizadores RGB.

4.1.5. Movimiento

Acceder a una opción extra para moverse entre salas hace que el movimiento seamás torpe y lento para un jugador. La idea pasa por sacar las direcciones disponi-bles a la pantalla de sala o añadir gestos que activen el movimiento directamente,manteniendo toda la lógica que tiene por detrás el movimiento.

Aparte, se construiría un mapa que permitiera al jugador ver las habitaciones que yaha visitado.

4.1.6. Nuevo combate

El combate actual es idéntico al desarrollado por el juego original, pero no ha habidomuchos más cambios aparte de los que ofrece la estadística de velocidad. Por ello, esun combate tedioso y puede llegar a ser aburrido si se alarga mucho, debido a quesolo hay dos posibles acciones que el jugador puede realizar.

Esto no implica que el combate actual no esté bien planteado o que no pueda llegara tener futuro, sino que todavía le faltan pequeñas características que lo hagan másfluido o cambiante, como daños variables. Además, también se quiere añadir en unfuturo un sistema de habilidades, de manera que existe un mayor rango de accionespara el jugador.

Otra posible mejora es que el combate y las estadísticas se parezcan más a las plan-teadas por el juego ”Dragones y Mazmorras”, cuyo sistema de combate está bienplanteado desde el principio y permitiría simplificar además el combate actual.

Aparte de todos los cambios que se pueden hacer en los combates actuales, se pre-tende realizar un nuevo combate que sea mucho más rápido y fluido para un jugador.Estaría basada en las reglas del juego ”Pistolero”, de manera que los personajes dis-pongan de una barra de vida muy pequeña y sus acciones sean únicamente disparar,recargar un ataque o defenderse.

43


4.1.7. Tutorial

Un jugador nuevo puede considerar tediosa la aplicación si no conoce el diseño deljuego o las posibles acciones que puede realizar. Por ello sería bueno implementar untutorial que permitiera al jugador familiarizarse con la interfaz.

Aunque esto podría llegar a lograrse simplemente usando diálogos y elecciones, pue-de ser más interesante crear un evento específico que permita mostrar imágenes yflechas y no tener que depender de un evento que esté orientado principalmente amostrar texto.

4.1.8. Compartir historias

La idea del motor no es que cualquier diseñador pueda implementar su versión delmotor única con su historia única, sino que la única aplicación existente sea la actualy que se puedan modificar los ficheros que crean la historia.

Para ello, se había pensado en una nube donde cualquier diseñador pudiera subirsus ficheros para que cualquier usuario se los descargue y pueda comenzar a jugar.

4.1.9. Puzles

Uno de los recursos más típicos en una mazmorra es la resolución de rompecabezas.Para el futuro se han planteado varias formas de resolver puzles sencillos, comononogramas [6] o rompecabezas de combinación [7].

44

Bibliografía

[1] Epic Games Inc. (2004). Unreal Engine [Online]. Available:https://www.unrealengine.com

[2] Unity Technologies (2005, junio, 8). Unity 3D [Online]. Available:https://unity.com

[3] Alberto Carrasco Carrasco, https://blogs.upm.es/observatoriogate/2018/07/04/que-es-un-motor-de-videojuegos/, Universidad Politécnica de Madrid, Madrid, 2018

[4] Apple Inc., https://developer.apple.com/documentation/mediaplayer/, Cuper-tino, California, Estados Unidos

[5] SUMMON PUBLISHING GROUP, https://www.geekno.com/glosario/npc, Valen-cia, 2019

[6] James Dalgety, https://www.puzzlemuseum.com/griddler/gridhist.htm, 2017

[7] Laura Martín Hoz, http://museodeljuego.org/wp-content/uploads/ROMPECABEZAS-DE-COMBINACIÓN-Laura-mart %C3 %ADn.docx, 2018

[8] Austrian Standards International – Standardization and Inno-vation (2002, julio). ISO 639-1:2002 (1) [Online]. Disponible:https://www.iso.org/standard/22109.html

[9] Ken Schwaber and Jeff Sutherland (2017, noviembre). The Scrum GuideTM [On-line]. Disponible: https://www.scrumguides.org

[10] Apple Inc. (2014, junio). Swift Org [Online]. Disponible: https://swift.org

[11] Apple Inc. Core Data Documentation [Online]. Disponible:https://developer.apple.com/documentation/coredata

[12] (2002, julio). YAML Ain’t Markup Language (3) [Online]. Disponible:https://yaml.org

45

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

C=ES

Fecha/Hora Tue Jan 14 23:52:03 CET 2020

Emisor delCertificado

[email protected], CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES

Numero de Serie 630

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

Documents

Universidad Politécnica de Madridoa.upm.es/58280/1/TFG_FRANCISCO_DEL_REAL_ESCUDERO.pdfLa trama del juego sigue un argumento parecido a muchos juegos de escape: los dos personajes