TítuloDesarrollo de un juego roguelike adaptado para invidentes empleando técnicas de generación de texto

Texto completo

(1)Facultade de Informática. TRABAJO FIN DE GRADO GRADO EN INGENIERÍA INFORMÁTICA MENCIÓN EN COMPUTACIÓN. Desarrollo de un juego roguelike adaptado para invidentes empleando técnicas de generación de texto.. Estudante: Dirección: Dirección:. Viteri Letamendía, Jorge Gómez Rodríguez, Carlos Vilares Ferro, Jesús A Coruña, setembro de 2019..

(2)

(3) A mi familia..

(4)

(5) Agradecimientos Muchas gracias a mi familia y amigos por todo su apoyo durante la carrera. Muchas gracias a Jesús Vilares Ferro y a Carlos Gómez Rodrígues por sus consejos y recomendaciones con las que he podido avanzar el proyecto. Y muchas gracias al café de Lázaro y al mixto de Ori, los añoraré..

(6)

(7) Resumen Este proyecto trata del desarrollo de un juego del género roguelike accesible para las personas con algún tipo de deficiencia visual grave. El juego conserva las características clásicas de un roguelike: se desarrolla por turnos en una mazmorra y el héroe o heroína deberá avanzar por esta superando los obstáculos que se le presenten. También sigue presente la permadeath o muerte permanente lo que implica que se perderá todo avance realizado una vez el protagonista muera. Además, la mazmorra será generada pseudo-aleatoriamente, dando al juego un mayor grado de rejugabilidad. Finalmente, se tiene un entorno gráfico ASCII para el juego y dos áreas de texto en las que se mostrará información sobre la partida, y que además son compatibles con lectores de pantalla. Al disponer de ambas representaciones, gráfica y textual, se permite que tanto jugadores videntes como invidentes puedan disfrutar de la experiencia de juego.. Abstract This project is about the development of a roguelike game accessible to people with some kind of serious visual impairment. The game retains the classic characteristics of a roguelike: it takes place in a dungeon in which the progress is made in turns and the hero or heroine must advance through it overcoming obstacles that arise. The permadeath or permanent death is also present, which implies that any advance made will be lost once the protagonist dies. In addition, the dungeon will be generated pseudo-randomly giving the game a greater degree of replayability. Finally, there is a graphical environment textit ASCII for the game and two areas of text in which information about the game will be displayed, and which are also compatible with screen readers. By having both graphic and textual representations, both sighted and blind players are allowed to enjoy the gaming experience.. Palabras clave: • Accesibilidad. • Roguelike.. • WordNet. • Jugadores invidentes. • Generación procedural.. • Generación Automática del Len- Keywords: guaje. • Java.. • Accessibility. • Roguelike..

(8) • Automatic Language Generation.. • Blind players.. • Java. • WordNet.. • Procedural generation.. 2.

(9) Índice general. 1 Introdución. 1. 1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. 1.3. Metodología de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.4. Plan del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2. 1.5. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5. 2 Fundamentos. 7. 2.1. Concepto del Roguelike . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 2.2. Estado del arte: situación actual de la industria del videojuego . . . . . . . . . 11. 2.3. Historia de los Roguelike . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12. 2.4. Tiflotecnología y videojuegos para invidentes . . . . . . . . . . . . . . . . . . 14. 3 Datos técnicos. 7. 19. 3.1. Lenguaje Empleado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19. 3.2. Equipo de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19. 3.3. Software de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20. 3.4. Licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20. 4 Desarrollo. 23. 4.1. Análisis de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23. 4.2. Diseño del juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23. 4.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.1. La interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29. 4.3.2. La mazmorra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31. 4.3.3. Elementos de la mazmorra . . . . . . . . . . . . . . . . . . . . . . . . . 38. 4.4. Creación de recursos léxicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43. 4.5. Generación de texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 i.

(10) Índice general. 5 Conclusiones y trabajo futuro. 53. 5.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53. 5.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53. A Herramienta Wordnet. 59. A.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 A.1.1. Wordnet: qué es? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59. A.2 Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 A.2.1. Instalación de la Wordnet y obtención de Offsets . . . . . . . . . . . . . 61. A.2.2. Concultas a la Wordnet desde Java: MySQLAccess . . . . . . . . . . . . 61. A.2.3. Construcción de Json a partir de las consultas: JsonCreator . . . . . . . 61. A.2.4. Obtención de variaciones y datos morfológicos: FindStr. A.2.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65. . . . . . . . . 63. A.3 Pasos para añadir un synset a los recursos . . . . . . . . . . . . . . . . . . . . 65 B Manual del juego. 67. B.1. Instalación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67. B.2. El juego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68. B.3. El héroe y sus acciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 B.3.1. B.4. Controles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69. Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 B.4.1. Armaduras y armas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70. B.4.2. Consumibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70. B.4.3. Tomos de magia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70. Bibliografía. 71. ii.

(11) Índice de figuras. 2.1. Captura de Rogue en el que se puede observar el clásico mapa de rejillas representado mediante caracteres ASCII . . . . . . . . . . . . . . . . . . . . . . . 10. 2.2. 3 de los juegos que más beneficios dan a día de hoy. . . . . . . . . . . . . . . . 11. 2.3. Wizardry y Ultima los cuales definirían con Rogue los videojuegos de rol. . . . 13. 2.4. Captura de ”Azure Dreams” de la primera PlayStation. . . . . . . . . . . . . . . 14. 2.5. Captura de ”Enter the Gungeon” un buen ejemplo de rogue-lite. . . . . . . . . . 14. 2.6. Hitos de la tiflomecánica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15. 2.7. Foto del Optacon en funcionamiento. . . . . . . . . . . . . . . . . . . . . . . . 16. 2.8. Foto del Braille lite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16. 2.9. Oregon Trail en su verisón de 1978. El juego se creó en 1971 y aún sigue recibiendo nuevas versiones a día de hoy. . . . . . . . . . . . . . . . . . . . . . . . 17. 2.10 Hardware accesible en videojuegos. . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. Imagen en la que se puede ver la interfaz del juego compuesta por un terminal ASCII y dos JTextAreas. En la inferior se muestran los mensajes de las cosas que van sucediendo en la mazmorra mientras que en la superior derecha se muestra el estado del jugador siempre y también las diferentes pantallas que puedan surgir como la de subir de nivel. . . . . . . . . . . . . . . . . . . . . . . 25. 4.2. CheckEnviromentScreen, cuando el puntero se encuentra sobre el jugador. En este caso, se muestra múltiple información de lo que tiene a su alrededor, como las dimensiones de la sala, número de cada criatura y posición respecto al centro de la mazmorra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30. 4.3. CheckEnviromentScreen, cuando el puntero se coloca sobre otro elemento de la mazmorra. En este caso, se indicarán los datos del objetivo, como su vida en el caso de que sea una criatura. También se puede observar la línea del puntero dibujada mediante el algoritmo ya comentado. . . . . . . . . . . . . . . . . . . 31. 4.4. Captura en la que se pueden observar las tres partes de la interfaz. . . . . . . . 32 iii.

(12) Índice de figuras. 4.5. Diagrama que muestra algunas de las pantallas del juego. Se puede ver a la interfaz Screen en el centro y que algunas de las pantallas que la implementan tienen otras clases que las extienden. . . . . . . . . . . . . . . . . . . . . . . . 33. 4.6. En esta imagen se pueden ver los triangulos definidos por tres puntos y las circunferencias que no contienen ningun vértice de otro triángulo. . . . . . . . 35. 4.7. Diagrama que muestra las clases encargadas de la construcción del World. . . 37. 4.8. Diagrama en el que se muestra las clases involucradas en la realización de la función hunt por parte de un goblin. . . . . . . . . . . . . . . . . . . . . . . . . 39. 4.9. Diagrama en el que se muestra la clase CreatureAi y sus diversas extensiones.. 41. 4.10 Se pueden observar las múltiples factorias, las cuales son llamadas por el PlayScreen y genera elementos del tipo Item o Creature . . . . . . . . . . . . . 44 4.11 La facotría WordDataGetterAndRealizatorFactory con las interfaces WordDataGetter o y Realizator y las implementaciones de estas. . . . . . . . . . . . . . 51 4.12 Se puede apreciar la localización incluso en los textos generados . . . . . . . . 52 A.1 En esta imagen se puede observar la clasificación que hace la Wordnet de las palabras. Este ejemplo se centra en el grupo de palabras {car; auto; automobile; machine; motorcar}, el cual se trata de un synset. Las diversas flechas en la imagen indican la dirección de las relaciones y están nombradas con los tipos de estas. Se puede ver que el synset principal es hiperónimo de {cab, taxi, hack, taxi, cab}, mientras que conveyance, transport son hiperónimos de este. Finalmente a la derecha, unas relaciones que se indican algunos synsets merónimos, como car door. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 A.2 Diagrama en el que se puede ver las relaciones entre las clases de la herramienta. 64. iv.

(13) Índice de tablas. 1.1. Planificación ideal del tiempo de cada tarea de proyecto. . . . . . . . . . . . .. 3. 1.2. Tiempo real empleado en el proyecto . . . . . . . . . . . . . . . . . . . . . . .. 4. 1.3. En esta tabla, se muestra el coste de proyecto pero teniendo en cuenta la aplicación de los impuestos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1.4. 5. En esta tabla, se muestra el coste de proyecto pero teniendo en cuenta la aplicación de los impuestos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5. 3.1. Especificaciones ténicas del hardware empleado. . . . . . . . . . . . . . . . . . 19. 3.2. Software empleado en el desarrollo. . . . . . . . . . . . . . . . . . . . . . . . . 20. v.

(14) Índice de tablas. vi.

(15) Capítulo 1. Introdución. 1.1 Motivación Siempre he tenido mucho interés por lo videojuegos, especialmente por los de rol y es la razón principal de que comenzase esta carrera. El medio de los videojuegos es enorme y variado, ofreciendo experiencias únicas y complejas creadas por la colaboración de multiples doctrinas. Esta colaboración es aún más notable dentro del aspecto de informática de un videojuego, ya que se pueden definir características en el videojuego que requieran el trabajo de ingenieros de diferentes campos de la informática, como redes e inteligencia artificial. En resumen, en mi opinión es el tipo de proyecto informático más completo y más interesante. Tengo deseos de realizar varios trabajos en la industria que todos puedan disfrutar. De este modo, también me resulta importante mejorar la accesibilidad en esta industria que no para de crecer. A medida que pasa el tiempo, los videojuegos van formando más parte de la vida diaria para personas de todas las edades y género. Esta expansión no debería verse restrigida por algunas limitaciones que no han sido consideradas durante el desarrollo, por ello considero también muy importante el diseño orientado a la accesibilidad. Esto puede ir desde ofrecer diversos niveles de dificultad a configuraciones de la interfaz.. 1.2 Objetivos El objetivo del proyecto es el desarrollo de un videojuego del género roguelike que sea accesible tanto para jugadores habituales de este género como aquellos que tengan algún tipo de deficiencia visual grave. Además, este juego contaría con una interaz cómoda, un generador te textos y que esté internacionalizado. Con un carácter más específico, se considerarían como objetivos básicos: • Desarrollo del juego. Ofrecer a los usuarios un roguelike divertido que no sacrifique ninguna de las características clave que definen al género. 1.

(16) 1.3. Metodología de desarrollo. • Definir mecanismos para la obtención del vocabulario. El vocabulario debería estar disponible en múltiples idiomas y estructurado de tal modo que sea fácil de tratar por el programa y que le aporte información importante sobre las palabras solicitadas. • Desarrollo de un generador de texto automático. Para dar un experiencia aún más dinámica y entretenida, se crearía un generador de texto capaz de ofrecer diversos resultados equivalentes para una misma situación. Es decir, que ante una misma situación a describrir, no genere siempre el mismo texto, sino que sea capaz de introducir variedad. También debería soportar varios idiomas. • Habilitar una interfaz adecuada para todos los jugadores. Armonizar la pantalla de juego y las ventanas centradas al texto para ofrecer una interfaz que se pueda disfrutar por cualquier tipo de usuario, vidente o invidente.. 1.3. Metodología de desarrollo. Tal y como se planificó, se ha seguido una metodología iterativa-incremental que se englobaría en dos etapas principales. La primera fue la implementación del juego en si, comenzando con la generación de la mazmorra ya que sería de lo más complejo del juego y del que depende el resto de esta etapa. Con la mazmorra ya funcional, se desarrolló a las criaturas e items con sus respectivos comportamientos y efectos. Finalmente, teniendo ya la mazmorra habitada y con herramientas, se implementaron las múltiples pantallas que el juego cuenta para las diferentes situaciones tales como subir de nivel o disparar a un objetivo con un arco. En la segunda etapa el foco del desarrollo se centró en la generación de texto, comenzado por implementar una interfaz que sea cómoda para mostrar el texto, compatible con varios idiomas y que sea legible por lectores de pantalla. Una vez implementada la interfaz, los esfuerzos se centraron en la obtención y organización de los vocabularios que se emplearían. Después, se implementó la clase que gestionaría estos recursos y, finalmente, la clase que construiría las frases descriptivas con las palabras y restricciones obtenidas por el gestor de los recursos.. 1.4. Plan del proyecto. El proyecto se inició en el segundo cuatrimestre del curso 2017-2018, período en el cual se realizaron las reuniones iniciales y se tomaron varias decisiones, pero no se pudo avanzar mucho más a causa del trabajo del curso. Al acabar con dicho trabajo, en el verano de 2018 se planificó el desarrollo del proyecto. En al Tabla 1.1 se pueden observar las actividades que se habían planificado en ese verano. 2.

(17) CAPÍTULO 1. INTRODUCIÓN. Tarea. Duración de la Tarea. Investigación y documentación.. 40 horas. Diseño inicial del juego.. 15 horas. Diseño inicial de la gramática.. 25 horas. Diseño inicial de la 20 horas. integración de la Wordnet en el proyecto. Comienzo del desarrollo. 5 horas. del juego: la terminal. Generador de mazmorras.. 40 horas. Diseño e implementación. 25 horas. de criaturas y su IA. Diseño e implementación. 15 horas. de items y efectos. Diseño e implementación. 30 horas. de acciones y sus pantallas. Implementación de la interfaz.. 15 horas. Incorporación de la. 40 horas. Wordnet al juego. Implementación del generador de texto.. 50 horas. Correcciones de código.. 15 horas. Pruebas con los betatesters.. 30 horas. Total. 315 horas. Tabla 1.1: Planificación ideal del tiempo de cada tarea de proyecto.. Debido a diferentes responsabilidades y a dificultades inesperadas del proyecto, el tiempo que le podía dedicar menguó a la vez que el requerido por este se incrementó considerablemente. Un problema especialmente complejo fue la integración de Wordnet, que supuso prácticamenete un subproyecto a parte para poder obtener los recursos necesarios para el juego. Se hablará en más profundidad de esto en el AnexoAppendix A. Junto a este, también existieron problemas trabajando con algunos otros recursos, como los problemas de codificación de los WikiCorpus, del que también hablaremos en la Sección⁇. Esto implicó su división en tareas que, en conjunto, tenían una mayor duración que la esperada. Con los retrasos, el testeo y QA no fueron tan profundos ni amplios como se pretendían inicialmente. Del mismo modo, algunas tareas acabaron siendo menos complejas de lo previsto, por lo que fueron más cortas, por ejemplo, la implementación de criaturas. Todo esto se puede ver en la Figura 1.2 3.

(18) 1.4. Plan del proyecto. que representa el tiempo real empleado en el proyecto. Tarea. Duración de la Tarea. Investigación y documentación.. 40 horas. Diseño inicial del juego.. 15 horas. Diseño inicial de la gramática.. 25 horas. Diseño inicial de la 20 horas. integración de la Wordnet en el proyecto. Comienzo del desarrollo. 5 horas. del juego: la terminal. Generador de mazmorras.. 60 horas. Diseño e implementación. 15 horas. de criaturas y su IA. Diseño e implementación. 10 horas. de items y efectos. Diseño e implementación. 30 horas. de acciones y sus pantallas. Implementación de la interfaz.. 20 horas. Creación de un proyecto 15 horas. capaz de hacer consultas a la Wordnet. Creación de las funciones que crean. 45 horas. los recursos del juego desde la Wordnet. Implementación del. 50 horas. generador de texto. Correcciones de código.. 15 horas. Pruebas con los betatesters.. No realizado. Total. 370 horas. Tabla 1.2: Tiempo real empleado en el proyecto Como se puede ver, el proyecto al final contó con 370 horas de desarrollo. Las reuniones realizadas durante el comienzo de este duraron aproximadamente 2 horas y se realizaron 3. Durante el resto del desarrollo, se realizaron unas 7 reuniones de 1 hora cada una. Esto implica que el proyecto además contó con 13 horas de reuniones para las que hay que sumar el coste por hora del tiempo del director y el analista. Puede verse la estimación del coste del proyecto en las Tablas 1.3 1.4. Se empleó el convenio definido por el BOE[1]. 4.

(19) CAPÍTULO 1. INTRODUCIÓN. Perfil Programador Analista Director de proyecto Total. Saldo/Hora sin impuestos aplicados 25e 35e 45e. Horas totales 370 horas 13 horas 13 horas. Total sin impuestos aplicados 9250e 455e 585e 10290e. Tabla 1.3: En esta tabla, se muestra el coste de proyecto pero teniendo en cuenta la aplicación de los impuestos. Perfil Programador Analista Director de proyecto Total. Saldo/Hora con impuestos aplicados 17.809e 32.78e 42.14e. Horas totales 370 horas 13 horas 13 horas. Total con impuestos aplicados 6589.33e 491.14e 547.82e 7625.29e. Tabla 1.4: En esta tabla, se muestra el coste de proyecto pero teniendo en cuenta la aplicación de los impuestos. El coste de producción es prácticamente el mismo de desarrollo, ya que únicamente se ha empleado software cuyas licencias son gratuitas y no requiere ningun hardware específico para funcionar.. 1.5 Estructura de la memoria Junto a esta introducción, se encuentran en este documento los posteriores capítulos cuyo contenido se compendia a continuación: • Capítulo 2. Fundamentos. Es este capitulo se describe los roguelike, respecto a las características de estos juegos y su historia. También se hace una introducción a la tiflotecnología y a la accesibilidad en los videojuegos. • Capítulo 3. Datos técnicos. Aquí se describen las herramientas y tecnologías empleadas en el proyecto. • Capítulo 4. Desarrollo. En él se realiza una descripción detallada del trabajo realizado en sus diferentes etapas. Adicionalmente, se detallan las estructuras y patrones utilizados en el desarrollo y la explicación del funcionamiento de las características más particulares de este. • Capítulo 5. Conclusiones y trabajo futuro. Se comenta la experiencia adquirirda en el marco de este trabajo y los planes futuros para mejorar y expandir el juego. 5.

(20) 1.5. Estructura de la memoria. 6.

(21) Capítulo 2. Fundamentos. 2.1 Concepto del Roguelike El Roguelike es un subgénero del videojuego de rol que nació en los 1980 con el juego llamado ”Rogue”[2], del que mostramos una captura en la Fugura 2.1(página 10). En él, el jugador controla a un personaje que explora una mazmorra con el objetivo de obtener un objeto y salir de esta. Rogue estableció las bases de un subgénero muy diverso ya que ni los mismos desarrolladores ni fans de estos títulos han consensuado unas características determinadas, de ahí el termino roguelike, ”similar al Rogue”.Sí existen una serie de llamadas ”interpretaciones” al respecto, que pueden verse, en cierto modo, como convenios: • Interpretación de Berlín: Se manifiesta en la ”Roguelike Development Conference” del año 2008 [3] que se realizó en Berlín. Esta interpretación pretende definir, por así decirl, cuánto de roguelike tiene un juego. Para esto se definieron unas pautas en base a juegos que sí son considerados puros roguelikes, como el NetHack. Estas pautas pueden subir el ”nivel” de roguelike de un juego más o menos según la categoría del patrón. Finalmente, añadir que algunas de estas pautas han sido criticadas, ya que esta interpretación puede llegar a ser un tanto restrictiva, como que el hecho de que el juego emplee gráficos basados en ASCII haga que el juego se considere más roguelike. A continuación, presentamos algunas de las principales características que harían que un juego fuese más roguelike: – Reto táctico. Se debe aprender sobre las tácticas antes de poder hacer un avance significativo importante. El juego debe proporcionar retos tácticos al jugador. Una de los medios del juego para realizar esto, es la obligación de tener que volver a empezar desde cero cuando se vuelve a jugar, eliminando la posibilidad de ser capaz de enfrentarse a retos de los últimos niveles. – Juego no modal. Las diversas acciones deben ocurrir todas en el mismo mo7.

(22) 2.1. Concepto del Roguelike. do, implicando que en todo momento del juego se pueda realizar cualquiera de las acciones definidas. En otros juegos, por ejemplo, en el momento de entrar en combate el modo de juego cambia, pasando a otro tipo de pantalla que funciona de forma diferente. – Gráficos ASCII. Método tradicional de mostrar la rejilla del mundo. – Hack’n’slash. Durante el juego, no habría ningun comportamiento amigable por parte de las otras criaturas, la única opción siempre es el combate. – Un único personaje. En el juego, sólo se puede controlar un personaje y la mazmorra debe estar centrada en este. • Interpretación de Temple of the Rogue: El foro Temple of the Rogue es uno de los más populares entre los jugadores de este género. En esta web se definió en 2014, coincidiendo con el resurgir de los roguelikes, una nueva interpretación más generalista y abierta que la de Berlín, si bien en este caso se trata de una definición estricta. Se la conoce como Interpretación clásica [4] y está formada por 7 pautas entra las que se encuentran el mapa de rejillas y la generación procedural. Es de carácter más actual y más aceptada tanto por desarrolladores como por jugadores. Estas pautas son: – Basado en turnos. El jugador interactua por turnos, decidiendo la acción a tomar. Tras actuar, el resto de elementos del juego también realiza su acciones. El jugador puede no hacer nada en un turno, pero el resto del mundo sí llevará a cabo igualmente sus acciones. – Basado en rejilla. Puede ser ortogonal o hexagonal, siendo la superficie donde se disponen los elementos del juego. El movimiento es atómico, de una celda a otra. – Fallos permanentes. Los jugadores deben arriesgarse y responsabilizarse de sus decisiones, ya que no hay forma de guardar partida y luego volver a cargarla tras realizar una acción. – Entorno procedurales. En cada partida, la mazmorra es regenerada proceduralmente para dar una mayor rejugabilidad. – Resultados aleatorios de los enfrentamientos. Al igual que en los juegos de rol, los combates en roguelike se verán afectados por el azar. Por ejemplo, el daño realizado con un arma no debería ser el mismo siempre. – Inventario. Por toda la mazmorra hay items que el jugador puede recoger y emplear, tales como armas, pociones mágicas, comida, etc., pero debe tener cuidado ya que hay un límite de objetos a llevar y su uso puede ser limitado. – Un único personaje. El jugador está representado en la partida por un único personaje. Esta pauta es similar a la definida en la Interpretación de Berlín. 8.

(23) CAPÍTULO 2. FUNDAMENTOS. Más recientemente, en el año 2018 se realizó una nueva interpretación, la llamda del roguelike tradicional [5]. Esta viene influenciada por la necesidad de determinar mejor cuales son las características más tradicionales de un roguelike que se puedan encontrar en un juego actual. Con esto se busca favorecer a los juegos que siguen más el testigo de los roguelike clásicos. En esta ocasión, las pautas se reducen a cuatro y constan de unas definiciones aún más estrictas: – Centrado en un personaje. El jugador controla únicamente a un personaje, al contrario que en otros juegos en los que no se controlan personajes, o en los que el jugador toma el papel de un director que maneja a un grupo de entidades. – Consecuencias permanentes. Cualquier tipo de acción tomada no puede ser anulada de ningún modo. Con esto se busca que el jugador actúe con tácticas precavidas y estrategias a largo plazo, y con ello aumentar la diversión al avanzar por la mazmorra generada proceduralmente. – Contenido procedural. La mayor parte del juego debe generarse proceduralmente para cada partida. Con esto, se incentiva al jugador a que se sienta menos dolido por las consecuencias permanentes, ya que sus efectos desaparecen una vez se comience una nueva partida. – Juego basado en turnos. Se debe tener el tiempo que uno quiera para pensar la decisión a tomar. Esto es importante dado que, al tener toda acción consecuencias permanentes, no se buscan decisiones rápidas por parte del jugador, sino movimientos bien planificados en situaciones críticas. Partiendo de las diversas interpretaciones existentes, vamos a considerar como los patrones para nuestro ”roguelike” los listados a continuación: • Permadeath o Muerte permanente. Característica común en juegos con dificultad, significa que si tu personaje muere pierdes todos los avances y se debe empezar la partida desde el principio. Tampoco hay posibilidad de guardar o cargar partida. Por otro lado, ante este tipo de juego, dicha carácterística se ofrece como un aliciente para partidas cortas, intensas y divertidas. • Mapa de rejilla. La mazmorra está divida en rejillas cuadradas en las que se sitúan los componentes del juego, un tanto similar a un tablero de ajedrez tal y como se puede ver en la Figura 2.1(página 10). Esto limita los movimientos, ya que sólo se podrá transportar un elemento de una mazmorra a una casilla que sea vecina. • Desarrollo de la partida por turnos. Cada acción que realice el jugador es un turno y en un turno se realizarán también las acciones de los otros elementos de la mazmorra. 9.

(24) 2.1. Concepto del Roguelike. Figura 2.1: Captura de Rogue en el que se puede observar el clásico mapa de rejillas representado mediante caracteres ASCII. Por tanto, mientras el jugador no realice ninguna acciónb tampoco el resto de elementos de la mazmorra harán las suyas. Asimismo, significa que cuando el jugador realice una acción habrá movimiento en zonas de la mazmorra que no sean perceptibles por este. Cabe recordar que ”pasar turno” es considerado como una acción, por lo que el resto de elementos sí actuarían.. • Aleatoriedad. Junto a la permadeath esta es la característica que más favorece la rejugabilidad y diversión. Esto se puede ver claramente en la generación de la mazmorra, cuyas salas se organizan de forma aleatoria así como los elementos que se disponen en esta. Hay incluso algunos elementos, caso de pociones, cuya apariencia cambia de partida a partida, por lo que el jugador no sabe qué es hasta que lo usa.. • Inventario y su gestión. Durante la exploración por la mazmorra, el jugador encontrará diversos items, tales como armas, pócimas, etc., que le servirán en la aventura pero que también tendrá que gestionar, ya que no tienden a aparecer con frecuencia y tampoco suelen poder usarse más de una vez. También se deberá tener en cuenta que el tamaño del inventario es limitado, por lo que el jugador no puede cargar con todo lo que se encuentre y debe ser más selectivo.. 10.

(25) CAPÍTULO 2. FUNDAMENTOS. (a) Captura de GTA V que sigue a día de hoy siendo una de los más exitosos, batiendo records.. (b) PokemonGO el fenónemo de los juegos par móviles.. Figura 2.2: 3 de los juegos que más beneficios dan a día de hoy.. 2.2 Estado del arte: situación actual de la industria del videojuego La industria del videojuego es ahora mismo la mayor industria de entretenimiento del mundo, superando a la música y cine [6]. Como ejemplo, el videojuego Grand Theft Auto V ha alcanzado las 90 millones de unidades vendidas, generando beneficios de 6 mil millones de dolares[6], lo que lo convierte en el lanzamiento más grande de la industria del entretenimiento. Asimismo, en el año 2018, el mercado de videojuego generó 115 mil millones de dolares y se espera que alcance los 300 mil millones para el 2025 [7]. En EE.UU., su principal mercado, 211 millones de personas juegan asiduamente a videojuegos [8], seguido ya por China, siendo la casa de Tencent, la mayor empresa del sector en estos momentos [9]. Respecto a las consolas, podemos comentar que la PlayStation 4 ha sido la que más rápido ha alcanzado los 100 millones de unidades vendidas [10], y que la Nintendo Switch lleva ya unas 37 millones de consolas vendidas en dos años a la venta [11]. Para finalizar con las ventas, los juegos para móviles siguen siendo los que más beneficios generan y los que mayor crecimiento tienen [12]. De entre los juegos de móvil más exitosos se debe citar a ”Pokemon Go” que a día de hoy lleva 2500 millones de dolares generados [13]. Algunos de estos otros juegos se pueden ver en la Figura 2.2(página 11). Sobre los nuevos avances tecnológicos en la industria, tenemos los nuevos servicios de juego por streaming que buscan llevar una experiencia similar a la dada por Netflix, ofreciendo un catalogo de juegos bajo subscripción. En este ámbito destacaría el caso Google, que se adentrará en esta industria mediante su plataforma Stadia [14]. También se lanzarán el año que vienen las nuevas iteraciones de las consolas de Sony y Microsoft, que parece que intentarán favorecer en la industria el uso del Path tracing[15], tecnología con la que se simula una iluminación más realista. Mientras, el trabajo con equipos de realidad virtual sigue avanzando 11.

(26) 2.3. Historia de los Roguelike. y destaca el lanzamiedo del nuevo headset de Valve [16]. A modo de conclusión de este apartado, se puede decir que esta industria sigue siendo la que más crece dentro del mundo del entretenimiento, así como que más tecnología introduce a la sociedad. Así mismo, poco a poco se está convirtiendo en una de las más influyentes a nivel cultural.. 2.3. Historia de los Roguelike. Para entender mejor los Roguelike y su historia, es conveniente conocer el precedente de este: el juego de rol. Un juego de rol es un juego de mesa en el que los participantes deben interpretar un rol de un personaje a lo largo de una aventura que está planificada por un tercero conocido como el director de juego master. Los jugadores deberán enfrentarse a la situaciones que se les presente según como quieran ellos, ya que tienen libertad en decidir cómo actuar. Para aumentar las capacidades de las acciones que los jugadores pueden tomar, los roles tienen diferentes habilidades según sus atributos; por ejemplo, el jugador con rol de mago será capaz de realizar hechizos. También interviene el factor del azar, ya que no se puede tomar ninguna acción importante en el juego sin lanzar unos dados para determinar el resultado. Las partidas de rol suelen durar mucho tiempo por lo que los personajes van ganando lo que se llama ”puntos de experiencia”, que le permiten aquirir mejoras en sus diferentes capacidades y así permitirles enfrentarse a problemas más complicados. El juego más conocido de este tipo es ”Dragones y Mazmorras”(”Dungeons & Dragons”), el cual está ambientado en un mundo de fantasía medieval de espada y brujería y que ha acabado por definir los clichés que nos solemos encontrar en buena parte de los videojuegos del género de rol [17]. Como ya hemos comentado en la Sección 2.1 ”Rogue” nació en 1980 de la mano de Glenn Wichman y Michael Toy[]RogueHistGam. Este tiene la premisa de que el jugador aparece en la primera planta de una mazmorra y este no puede escapar sin el ”Amuleto de Yendor”, que se encuentra al fondo del laberinto. El jugador deberá avanzar por los niveles de la mazmorra para obtener el amuleto y luego regresar a la superficie con este para escapar. La ambientación del juego era de un mundo de fantasía como el ”Dragones y Mazmorras”, compartiendo también con este algunos puntos como el azar tan presente en las acciones y en el mundo. Si bien no son Roguelikes, llegados a este punto es importante mencionar otros dos juegos de rol: ”Wizardry” y ”Ultima” 2.3 (página 13). Cada uno de estos juegos representa una aproximación diferente pero acertada al juego de rol de mesa clásico. Estos títulos se influirían mutuamente en sucesivas entregas y asentarían las bases del videojuego de rol tal y como lo conocemos hoy en día [18]. Lamentablemente, este subgénero iría perdiendo popularidad con el paso del tiempo por diversas razones, como la migración de los jugadores a las videoconsolas lo que generó una 12.

(27) CAPÍTULO 2. FUNDAMENTOS. (b) Ultima ofreció un mundo enorme a explorar y permitía también a acceder mazmorras, las cuales se navegaban en primera persona.. (a) Wizardry establecería las bases de los de un subgéreno propio.. Figura 2.3: Wizardry y Ultima los cuales definirían con Rogue los videojuegos de rol.. gran pérdida de popularidad del ordenador como plataforma de juego [19]. Aún así, llegó a salir algún juego del género para consolas como, por ejemplo, ”Azure Dreams” para PlayStation (véase Figura 2.4 página 14). Para finales de la década del 2000 haría acto de presencia ”Dwarf Fortress”, que sigue estando en evolución y desarrollo a día de hoy [20]. Se trata de un juego de rol muy complejo que se caracteriza por el inmenso mundo que ofrece para explorar y la variedad acciones que permite. Además, tiene un modo roguelike. También son peculiares las descripciones de los combates debido a la irracionalidad de situaciones que describe y el lenguaje que usa. He de decir, que en este aspecto ha influido en cierta manera en las descripciones generadas por mi juego, sobre todo en el uso de vocabulario. Sin embargo, en los últimos años los ordenadores han retomado su posición como unas de las plataformas de juego más relevantes. Esto ha sido así gracias a diversos factores, como la aparición de palataformas de distribución digital como Steam[21] y Good Old Games[22], y el crecimiento de desarrolladores indie, los cuales no siguen las tendencias del momento ni dependen de decisiones de productoras, lo que les permite desarrollar juegos no tan mainstream caso de los roguelike. Con este retorno del PC, el roguelike también ha recuperado estatus gracias a nuevos lanzamietos en PC y consolas e incluso la aparición de nuevas variaciones del género, caso de los llamados ”roguelite, que son juegos que constan de características de los roguelike pero no todas o no de un modo totalmente fiel a los rogelike. Algunos de los roguelite más populares actualmente serían ”Spelunky”, la saga ”Pokemon Mystery Dungeon” y ”Enter the Gungeon”. En este último, del cual mostramos una captura en la Figura 2.5(página 14) el combate pasa a ser en tiempo real y orientado a disparos, si bien conserva aún la estructura de mazmorra de un roguelike. También otras sagas de juegos de rol han probado suerte recientemente con adaptaciones del género, como el ”Wizrogue” de la saga ”Wizardry”. Está claro que el género goza de buena salud a día de hoy y que le queda mucho por ofrecer. Seguir dando soporte a estos títulos y hacerlos más accesibles resulta de gran interés. 13.

(28) 2.4. Tiflotecnología y videojuegos para invidentes. Figura 2.4: Captura de ”Azure Dreams” de la primera PlayStation.. Figura 2.5: Captura de ”Enter the Gungeon” un buen ejemplo de rogue-lite.. 2.4. Tiflotecnología y videojuegos para invidentes. La tiflotecnología es una tecnología de apoyo centrada en permitir el acceso de personas con ceguera u otros problemas visuales graves a las nuevas tecnologías. Respecto a su historia, es muy difícil de datar su origen aunque tendríamo sus precursore en la tiflomecánica, la cual buscaba el mismo objetivo pero empleando mecanismos. Dicho esto, se suele considerar como hitos importantes el prototipo de máquina parlante de Wolfgang von Kemplelen de 1791[23] y al rafígrafo de Foucault[24] de 1841 los cuales se pueden ver en la Figura 2.6 (página 15). La primera es una máquina que consistía en un conjunto de tubos de organo con los que s epretendía reproducir las vocales, siendo así el primer sintetizador de voz. El segundo dispositivo consiste en diez palancas, compuestas cada una de tecla y punzón, con las que se 14.

(29) CAPÍTULO 2. FUNDAMENTOS. (b) Maquina parlante de Kemplelen. (a) Rafígrafo.. Figura 2.6: Hitos de la tiflomecánica. realiza la impresión mecanizada de caracteres visuales en relieve punteado. Más fácil de trazar es su historia en España, a la que llegó a comienzos del siglo XX en forma de una máquina Pitch [25], de las primeras de escribir Braille. También habría que tener en cuenta los audio-libros de los años 60, pero el desarrollo comienza de verdad con la microelectrónica. De este momento nace finales de los años 70 el dispositivo conocido como Optacon, el cual reproducía en una matriz táctil las imágenes que capturaba con una cámara. Este aparato se puede ver en la Figura 2.7(página 16). Ya en la década de los 80, los ordenadores pasan a estar en el foco. Aparece entonces el COBRA, el primer software español dedicado a la tiflotecnología. Este software era capaz de convertir textos ASCII a Braille y formatearlos para poder imprimirlos en una impresora de Braille. También cabe destacar en esta década la aparición de las denominadas líneas braile, dispositivos que cuentan con unas celdas en las cuales se representan los caracteres braille mediante una matriz de agujas que suben y baja. Un dispositivo conocido de este grupo sería el Braille Lite que se puede apreciar en la Figura 2.8(página 16). A día de hoy, posiblemente la tecnología de este campo que más destaca sería la de los lectores de pantalla, un software capaz de interpretar lo que hay en pantalla y que luego convierte en audio al usuario. Cabe destacar la gran variedad de lectores como NVDA[26] y ORCA[27]. En lo que respecta a los videojuegos, en concreto primero deberíamos retornar a comienzos de los años 70. Durante esta época, los ordenadores no disponían de una interfaz gráfica como las de hoy en día y únicamente eran capaces de representar textos. Debido a ello, existían por entonces los llamados juegos basados en texto, juegos que completamente delegaban en texto para su interfaz y sí mostraban imágenes, estas solían ser secundarias. Los jugadores podían tomar decisiones según las teclas que se pulsasen o introduciendo frases en lenguaje 15.

(30) 2.4. Tiflotecnología y videojuegos para invidentes. Figura 2.7: Foto del Optacon en funcionamiento.. Figura 2.8: Foto del Braille lite. natural. Debido a que confiaban tanto en el texto, estos juegos eran relativamente fáciles de usar por los invidentes mediante el uso de sintetizadores de texto. En la Figura 2.9(página 17) se puede ver una captura de ”Oregon Trail, el juego más conocido e influyente de esta clase [28] aunque el primero que ofreció compatibilidad fue ”Colossal Cave Adventure”(1976) [29]. Con el avance tecnológico, los ordenadores irían ganando capacidad para representar gráficos y los videojuegos pasarían a usar más este tipo de representación en lugar de la de texto. Esto redujo considerablemente la accesibilidad para los invidentes, viéndose progresivamente relegados a los juegos más simples. Como respuesta a este problema, algunos desarrolladores se pusireron a trabajar en videojuegos centrados en el aspecto del sonido, aunque basándose en otros ya existentes. Se acabarían creando videojuegos únicamente basados en audio y conocidos como audiojuegos. 16.

(31) CAPÍTULO 2. FUNDAMENTOS. Figura 2.9: Oregon Trail en su verisón de 1978. El juego se creó en 1971 y aún sigue recibiendo nuevas versiones a día de hoy.. Con las mejoras en la tecnología de audio llegaría el sonido envolvente o posicional, el cual permite dar la sensación de que un sonido procede de una dirección determinada. Esta tecnología sería aprovechada para el desarrollo de nuevos y poder representar situaciones espaciales. Un buen ejemplo moderno sería el proyecto RAD [30], que consiste en una interfaz de audio aplicable a cualquier juego de carreras y que da la información necesaria para que el jugador invidente pueda disfrutarlo sin problemas. Llegdos a este punto, es obligatorio destacar el papel que ha tenido internet en estos juegos accesibles. Hoy en día, existen numerosas comunidades y webs dedicadas a los audiojuegos y la accesibilidad. Un buen ejemplo es la web audiogames [31], la cual contiene un foro activo dedicado a este tipo de juegos y un archivo con el que se puede acceder a diversos títulos de este tipo. En el caso del hardware, tenemos a Microsoft, que ha lanzado un mando adaptativo altamente personalizable para dar apoyo a las personas con discapacidad. También registraron recientemente la patente de un mando con panel braille [32]. Ambos mandos se muestra en la Figura 2.10(página 18). En lo que respecta a juegos roguelike, durante los últimos años ha habido diversos avances en ofrecer accesibilidad a personas invidentes. En la Roguelike Celebration del 2016 fue uno de los temas abordados los retos a la hora de adaptar un roguelike accesible a personas con problemas visuales[33]. Actualmente, existen ya diversos roguelikes accesibles para invidentes, destacando Dungeon Crawl Stone Soup, que se caracteriza por la amplia oferta de atajos y acciones que permiten al jugador actuar rápidamente [34]. Otro juego sería Brogue-SPEAK, una versión del juego Brogue que incluye un lector de pantalla propio y realiza un gran trabajo con los efectos de sonido [34]. Con nuestro proyecto buscamos iniciar un nuevo juego que se una a la tendencia actual 17.

(32) 2.4. Tiflotecnología y videojuegos para invidentes. (a) Mando adaptativo anunciado el año pasado.. (b) Imagen de la patente del mando con panel braille.. Figura 2.10: Hardware accesible en videojuegos. buscando así aportar nuevas ideas, experiencias y que pueda ser disfrutado por todo tipo de jugadores, videntes o invidentes, favoreciendo así su integración también en este ámbito.. 18.

(33) Capítulo 3. Datos técnicos. 3.1 Lenguaje Empleado Desde el inicio del proyecto se decidió trabajar con el lenguaje Java, siendo la principal razón que la comunidad de desarrolladores de roguelike emplean este lenguaje por lo que no es difícil encontrar recursos, tutoriales, foros que traten el desarrollo de esto juegos con Java. Este lenguaje también da las ventajas de ofrecer universalidad entre diferentes plataformas por lo que no debería de haber problemas según el sistema operativo. Finalmente, hay que destacar que es un lenguaje muy orientado a la accesibilidad por lo que componentes del Swing no tienen problemas con los lectores de pantalla más comunes [35], aunque en Windows requiera activar el Java Accessibility Bridge [36] pero no implica mucho problema.. 3.2 Equipo de desarrollo Para el desarrollo se empleó el equipo especificado en la Tabla 3.1. Como se puede ver, el equipo supera con creces las necesidades de la tarea. Modelo CPU Velocidad CPU Núcleos por CPU Hilos por núcleo Caché L1/L2/L3 Memoria RAM GPU. Intel Core i7 6700HQ 2.60GHz 4 2 256KB/1MB/6MB 12GB NVIDIA GeForce GTX 950M. Tabla 3.1: Especificaciones ténicas del hardware empleado.. 19.

(34) 3.3. Software de desarrollo. 3.3. Software de desarrollo. Para evitar problemas, se decidió emplear las librerías de terceros más necesarias procurando trabajar dentro de todo lo posible con lo ofertado por la API de Java. Al comienzo del desarrollo, se estudió emplear ”Necklace of the Eye” [37] para la interfaz gráfica, pero se descartó por problemas de compatibilidad con Java. Algunas de las librerías de terceros que se usaron fueron json.org [38] con la que se pudo trabajar con los json que almacenan los recursos de texto y asciiPanel [39] que simula un monitor ASCII soportando 256 caracteres, colores en primero y en segundo plano y varias dimensiones para el terminal. Respecto a la herramienta que obtiene los datos de la Wordnet, se ha empleado también la librería json.org y se ha añadido la librería mySQLConnector [40] con la que se puede acceder a la Wordnet MCR 3.0 [41] la cual incluye inglés, español, gallego, euskera, catalán y portugués. Para obtener los datos de las palabras se comprobó la información contenida en el Wikicorpus[42], una colección de textos de Wikipedia con información lingüística. A continuación, la Tabla 3.2 en la que se muestra el software empleado para el desarrollo del propio juego. Sistema Operativo IDE Versión de Java Librería Gráfica. Windows 10 Eclipse Neon.3 8 asciiPanel. Tabla 3.2: Software empleado en el desarrollo.. 3.4. Licencias. Al momento de escoger una licencia para nuestro programa, se tuvieron en cuenta las licencias de las librerías y recursos de terceros empleadas en el proyecto. Las librerias que se han empleado en el juego constan de las siguientes licencias: • MIT License.[43]: correspondiente a la librería ascciPanel. • JSON License.[44]: de la librería org.json. • Apache 2.0.[45]: de commons-io. Ante estas licencias, se decidió que el juego tendría una GNU General Public License 3.0 [46], dado que es compatible con las licencias mencionadas. Respecto al generador de recursos tenemos además otras licencias, siendo algunas de recursos: 20.

(35) CAPÍTULO 3. DATOS TÉCNICOS. • Apache 2.0. [45]: empleada por commons-io y java native access. • JSON License. [44]: una vez más, org.json. • GNU General Public License v2.[46]: por mySQLConnector. • GNU Free Documentation License.[47]: la misma que Wikipedia, empleada por WikiCorpus. • Wordnet License.[48]: licencia propia de la Wordnet original del habla inglesa. • Attribution 3.0 Unported (CC BY 3.0).[49]: licencia empleada por el resto de componentes de la Wordnet MCR 3.0. Una vez más, se ha decidido licenciar con GNU General Public License 3.0 ya que evitaba problemas de compatibilidad con las licencias mencionadas.. 21.

(36) 3.4. Licencias. 22.

(37) Capítulo 4. Desarrollo. 4.1 Análisis de Requisitos El proyecto se propuso con la idea de que pudiera ser jugado por personas invidentes, es por esto que fue necesario pensar en una interfaz competente. Desde el principio se decidió que el juego contaría con una interfaz ASCII para jugar, pero esto daría problemas de compatibilidad con los lectores de pantalla por lo que no se podía relegar toda la información a esta pantalla. Con este problema, también surge el de la localización ya que se deseaba que el juego fuera sencillo de localizar a diferentes idiomas y el formato ASCII iba a ser un gran inconveniente. Otro problema que se quería solventar era la ”monotonía” de los mensajes ya que lo normal es que para cada situación haya un mensaje que el juego muestra. Para una persona invidente esto sería muy cansino y molesto ya que el lector no pararía de repetir el mismo texto una y otra vez. Del juego cabe decir que no se planteó hacerlo muy diferente al Rogue básico. La idea era crear un juego de partidas de corta duración, pero intensas y divertidas, buscando la rejugabilidad. También, el juego debería ser fácil de modificar para añadir nuevas criaturas o objetos al juego.. 4.2 Diseño del juego Ante los problemas planteados se decidieron tomar las siguientes opciones: • Para solventar los problemas de interfaz y los lectores de pantalla, se decidió que se debería añadir algún tipo de ventana complementaria que acompañarían al terminal de juego, y en los que se mostraría la información del juego de forma repartida: una estaría centrada en los mensajes que se suceden cuando el jugador avanza por la mazmorra mientras que la otra actuaría con las diferentes pantallas de equipo como la de subir nivel. Al trabajar con Java, se sabía de la disponibilidad del TextArea así que se tuvo en 23.

(38) 4.2. Diseño del juego. mente realizar la implementación con esta clase. En la Figura 4.1 (página 25), se puede ver la forma final de la interfaz. Como ya se comentó, también se estudió el emplear Necklace of the Eye [37], pero debido a incompatibilidades se decidió no emplearlo. Se pensaba emplear para dar una interfaz gráfica tridimensional. • El conocimiento del TextArea comentada en el anterior apartado también serviría para solventar el problema de la localización respecto a la interfaz, ya que no habría problema para soportar caracteres unicode. También permitiría más comodidad en otros puntos de la localización, como cuidar el tamaño de un mismo texto en dos idiomas diferentes que puede dar problemas a una interfaz. TextArea ofrece las herramientas para solventar estos problemas fácilmente. Otro recurso que se pensaba emplear, era el de la Wordnet el cual podía controlar varios idiomas e identificar una palabra entre estos, lo que permite obtener la traducción de una palabra con tan solo un identificador. También se siguieron pautas definida en el libro ”The Game Localization Handbook”[50], como evitar ”hardcodear” texto en el juego, guardar los recursos en archivos de texto de fácil acceso, que no se requiera un editor de texto propietario para tratarlos y que los textos dentro del archivo estén identificados por una llave única. Con estas pautas, se decidió que los recursos serían almacenados en archivos json estructurados. • Respecto el problema de la monotonía, se optó implementar un generador de textos. Este funcionaría en base al estado de la partida describiendo, por ejemplo, el combate entre dos criaturas. También debería ser capaz de trabajar con sinónimos y alternar sus usos en las frases, esto se resolvería mediante el uso de la Wordnet ya que agrupa las palabras en synsets, es decir, conjuntos de sinónimos identificados por una llave. Como es lógico, también debería ser fácil de preparar para que trabaje con un idioma nuevo, identificando los componentes de la frase y juntandolos según la gramática definida. Al principio se estudió realizar una ”Probabilistic Unification Grammar” [51], en la cual las unidades gramaticales están asociadas con sets de valores de unas características. Estas unidades, se combinarían únicamente cuando otras características comunes se unían. Estos valores de características son, pues, la información del contexto de la frase a crear, reglas a cumplir. La implementación de esta habría sido mediante algún lenguaje lógico como PROLOG, ya que se ajusta bastante a la gramática. Finalmente, se decidió realizar una mucho más simple independiente del ”contexto” de la frase, ya que iba a ser muy complejo y ya tratar el tema del ”contexto” que daría para un trabajo propio. Si bien no se perfiló totalmente desde el principio, la gramática final ya se esbozó como una basa en plantillas por cada acción, en las que se irían asignando las palabras necesarias. Otra causa de esto fue que las Wordnet no almacenan ciertos tipos de palabras como determinantes y preposiciones. 24.

(39) CAPÍTULO 4. DESARROLLO. Figura 4.1: Imagen en la que se puede ver la interfaz del juego compuesta por un terminal ASCII y dos JTextAreas. En la inferior se muestran los mensajes de las cosas que van sucediendo en la mazmorra mientras que en la superior derecha se muestra el estado del jugador siempre y también las diferentes pantallas que puedan surgir como la de subir de nivel.. 25.

(40) 4.3. Implementación. Para modificar palabras según las necesidades de la situación, se estudió implementar código que lo realizase o emplear NodebBox:Linguistics, más finalmente esta decisión se tomó más adelante en base al estado de los recursos en la Wordnet. • Con el objetivo de mantener el juego lo más simple y divertido posible se decidió no hacerlo muy grande pero sí bien definido y con opciones divertidas para que el jugador pudiera experimentar. También, algunas de las criaturas de la mazmorra tendrían comportamientos heteróclitos que podrían llamar la atención del jugador. • Con motivo de conseguir un juego fácil de modificar se decidió realizar la implementación del juego siguiendo consejos de la comunidad e incluso algún tutorial. Esto permitiría poder comparar resultados y tener también referencias de código por si se cometía algún error. Estas decisiones se realizaron durante un tiempo en el que se dedicó a estudiar los recursos disponibles, el cual se centró principalmente en las Wordnet y las gramáticas dado a que eran algo que sería complicado de realizar y totalmente nuevo para mi. Investigando las primeras descubrí que existe un estándar conocido como el KYOTO [52] a cumplir, por lo que decidí que emplearía una que lo cumpliese. También, seguí la recomendación de mi directos de que buscase alguna que funcionase con algún sistema de gestión de bases de datos.. 4.3. Implementación. La parte más costosa y duradera del proyecto con diferencia, comenzó con la realización de la ventana de juego con el terminal ASCII teniendo que definir una mazmorra inicial y las primeras pantallas del juego. Tras eso, me dispuse a la implementación de un constructor de mazmorras, la cual fue la parte más compleja de todo el proyecto. Al principio se estudio realizar la construcción de la mazmorra mediante el algoritmo A estrella[53], pero finalmente se decidió seguir el definido en ”Gamasutra” [54] dado que sus resultados se ajustaba más a las necesidades del proyecto. El problema fue a causa de que muchos de los componentes del método tenían implementaciones que no se ajustaban a mis necesidades, como las de Delaunay, por lo que me ví obligado a implementarlas por mi parte. Curiosamente, de todos los componentes que tuve que implementar aquí, el que más problemas me dió fue el de obtener el centro de un círculo dados tres puntos. Esto fue debido a que no comprobaba bien todas las posibles situaciones de este cálculo, dando errores matemátios graves. Al final, este código se implementó adaptando el código desarrollado por Danylo Malyuta para Matlab [55]. Otros problemas con la creación de la mazmorra fueron habitaciones superpuestas, lo que obligó a definir en la clase Room una función que comprobase que dos habitaciones fueran disjuntas. 26.

(41) CAPÍTULO 4. DESARROLLO. Una vez creada la mazmorra, ahora los problemas provenían del dibujado de esta los cuales eran causados por el cambio de coordenadas a las de una imagen, que el dibujado de los pasillos no estaba bien definido y que algunas posiciones de las habitaciones no eran generadas dentro del rango del terminal. Estos se solucionaron controlando el paso de coordenadas en el eje ”y”, con una definición del dibujado en el que se tendrían en cuanta las posiciones y distancias entre las posiciones de dos habitaciones, y restringiendo las posiciones que se podrían tener en cuenta a la hora de generar la mazmorra. Tras completar el constructor y su dibujado, comencé la creación de los diferentes elementos que habría en la mazmorra empezando por el jugador el cual sería representado por el carácter @. Tras tenerlo en la mazmorra y poder desplazarlo por esta, se porcedió a añadir criaturas fijas y, con estas, las primeras interacciones básicas entre el jugador con otros elementos. En esta parte no hubo mucho cambio de lo esperado, ni tantos problemas. Los comportamientos eran muy básicos, orientados al combate, y las criaturas no era complejas. Después se porcedió a añadir varios niveles a la mazmorra y conectarlos mediante escaleras. Este punto tuvo algo de dificultad ya que había que controlar las posiciones de las escaleras permitiendo así que al volver a un nivel anterior el personaje apareciera en el punto donde estaban las escaleras previas. Esto también significo que el jugador debería aparecer en la escalera de salida del primer nivel siempre. Seguidamente, se porcedió a añadir criaturas que se comportaban de forma más inteligente, se estableció un campo de visión y los items. Lo primero requirió definir máquinas de estados finitos y una implementación del algoritmo A estrella[53] con el que las criaturas podría perseguir a los objetivos que se encontraban a su vista. Siguiendo con la vista, esto requirió implementar un campo de visión el cual se realizó generando una línea del tamaño del radio de visión y se comprobaba lo que había al alcance. Esta línea se dibujaba siguiendo el algoritmos de la línea de Bresenham [56]. Respecto a los items, se implementó la clase y se definió el atributo inventory que permitiría a las criaturas llevar un número de objetos. Tras completar la parte del juego se volvió a la interfaz. Ya se tenía algo que se podía jugar y que mostraba los mensajes mas había que adaptar la interfaz para que fuera accesible a los lectores de pantalla. Para ello, se modificó la clase principal añadiendo dos TextAreas, mas estas no funcionaban bien ni permitían tantas modificaciones como me esperaba. Por ello, se pasó a usar JTextAreas las cuales no requirieron mucho cambio en el código ya que comparten muchas funciones. Llevó un poco de tiempo modificarlas para que se ajustaran al terminal del juego, pero se consiguió. Con las dos JTextAreas, surgió el problema de como permitir el acceso a estas desde el resto de pantallas del juego, por lo que se definió una clase singleton que se iniciaría con estas dos componentes, y se encargaría de manejarlas. Luego se tuvo que permitir su lectura por parte de los lectores de pantalla, lo que implicó permitir que fueran focusable y había que controlar las entradas del juego. Si esto último no se hacía, el 27.

(42) 4.3. Implementación. usuario se vería incapaz de salir de las JTextAreas por lo que no podría jugar. Una vez acabada la interfaz, comenzó el trabajo con la Wordnet el cual fue bastante más complicado de lo esperado. El primer problema fue que pensaba que se podría decidir el synset adecuado para el contexto de la situación de alguna forma automática, e intenté buscar algún modo de realizarlo. Desistí de esta opción, ya que era muy compleja y se trataba de un trabajo de Word Sense Desambiguation[57], una problemática que ya daba para un trabajo propio. Con esto, yo mismo tuve que ir comprobandos los synsets de la Wordnet e ir apuntando los identificadores de estos para poder obtenerlos en el proceso de crear los recursos. Una vez obtenidos los identificadores, se porcedió implementar las peticiones en java a la Wordnet. Hubo éxito, ya que los grupos de palabras se escribían agrupados en archivos json bien estructurados, mas surguió el problema de que sólo se tenían las palabras, no los datos morfológicos. Se estudió realizar peticiones al API de la RAE (Real Academia Española) NLP Linguakit[58], pero finalmente se opto por emplear el WikiCorpus [42], que indirectamente también resolvió el problema de la conjugación de los verbos. Aún así, esto llevo a un punto crítico, ya que se tenía pensado que toda esta parte del proyecto iría integrada en el juego, ya que se deseaba que el juego tuviera un proceso de instalación que consistiría en la creación de todos estos recursos, pero se estaba haciendo demasiado grande. Es por esto, que el trabajo con Wordnet acabó siendo un proyecto propio del cual se aprovecharían los recursos generados. Finalmente, comentar que el WikiCorpus también fue problemático, debido a que pese tener archivos en español, no estaban en unicode, por lo que las palabras estaban con caracteres incorrectos. Finalmente, se porcedió a la creación del generador de texto. Este motor se diseñó en base a la teoría de Natural Language Generation que define dos componentes importantes, el Planificador del Discurso y el Realizador de Superfie [59]. Aproximandome a estos dos conceptos, implementé una clase que obtendría las palabras necesarias desde los recursos del programa y otra que realizase las frases juntando estas palabras mientras respetaba las restricciones definidas por estas. Algo que se tuvo que decidir fue el momento adecuado en el que el Planificador del discurso debía actuar para obtener algunas palabras como los nombres y características de las criaturas, ya que podría hacer al crealas o de forma dinámica en ejecución. Se optó por la primera opción, que sería más cómoda de tratar y daría resultados igual de buenos y más estables, además, así se podría establecer el género del jugador de forma aleatoria. Una cosa que cambió un poco, fueron las plantillas ya que al final no se definieron para cada acción, esto se hizo sólo en parte ya que están definidas en grupos de acciones y, en ocasiones, algunas plantillas más específicas. Las diferencias en estas plantillas, se intuiría en qué componentes forman parte de esta y cuales no. Gracias a la investigación previa, este apartado no fue tan costoso como pensé inicialmente, aunque sí que requirió escribir mucho código delicado aunque totalmente operativo y fácil de aprovechar. Donde sí surgieron problemas fue en la 28.

(43) CAPÍTULO 4. DESARROLLO. definición de los recursos, que significo modificar la herramienta de la Wordnet, especialmente por el verbo to be. Ahora, se procederá a describir en más detalle como están implementados los componentes del proyecto.. 4.3.1 La interfaz Como se comentó previamente, la interfaz consta de tres elementos: un terminal ASCII y dos JTextAreas tal y como se puede ver en la Figura 4.4 (página 32). Inicialmente, se estuvo trabajando únicamente con la terminal, mediante la cual se irían probando las pantallas iniciales del juego. Para implementar las pantallas, se creó una interfaz Screen en la que se establecían las funciones básicas de una pantalla: displayOutput() que se encargaría de mostrar la imagen necesaria y respondToUserInput() con la que las pantallas serían capaces de capturar las entradas del juegador y tratarlas. La primera implementación de la interfaz fue StartScreen que simplemente contiene un mensaje de introducción indicando que se pulse cualquier tecla para comenzar partida. Tras pulsar alguna tecla, se pasa a la pantalla PlayScreen que es donde transcurre la mayor parte del juego. Es en esta pantalla en la que el mundo realiza sus actividades y el jugador lleva a cabo sus acciones. Según las acciones ejecutadas, PlayScreen llamará a otra Screen más especializada en tratar la acción. Una vez realizada, se vuelve a PlayScreen. PlayScreen es también responsable del posicionamiento de las criaturas e items en la mazmorra. Esto es útil, ya que se ha establecido que aparezcan nuevas criaturas cuando el jugador obtenga el amuleto al fondo de la mazmorra. Otras responsabilidades de esta clase son la impresión de la mazmorra en el terminal y controlar el scroll de esta. Finalmente, también es la encargada de comprobar si el jugador cumple la condición de victoria. De las otras pantallas, primero hay que destacar las clases abstractas InventoryBasedScreen() y TargetBasedScreen(), que se usan como base para situaciones en las que se requiera visitar un listado de elementos y en las que se mueve un cursor por la zona perceptible del mapa. Un ejemplo del empleo de las dos clases sería la acción de lanzar un objeto, por la cual se accede primero a la pantalla ThrowScreen() que extiende a InventoryBasedScreen(), mostrando así los objetos que tienen el jugador en un lista. Una vez seleccionado el objeto, se pone la pantalla ThrowAtScreen() en la que el jugador puede seleccionar con un cursor el objetivo del lanzamiento. Otra pantalla importante es CheckEnviromentScreen que no implementa a TargetBasedScreen aunque sea similar al contar con un puntero. Esto es debido a que requiere un mayor esfuerzo por la clase principal, pues en esta pantalla se lista todo lo que esté a la vista del jugador, si se encuentra en una habitación, su posición, y la posición de un puntero que podrá mover libremente por la zona perceptible, permitiéndole ver los detalles de los elementos que 29.

(44) 4.3. Implementación. Figura 4.2: CheckEnviromentScreen, cuando el puntero se encuentra sobre el jugador. En este caso, se muestra múltiple información de lo que tiene a su alrededor, como las dimensiones de la sala, número de cada criatura y posición respecto al centro de la mazmorra. hay. Al igual que las TargetBasedScreen, la línea del puntero y lo que hay a la vista funciona gracias al algoritmo de la línea de Bresenham[56]. En la Figura 4.2 (página 30) y 4.3 (página 31) se pueden ver unos ejemplos de su uso. Esta pantalla requirió bastante testeo y tiempo, debido a que tenía que distinguir entre un pasillo y una habitación. Esto se podía complicar en algunas posiciones como las esquinas y las entradas a una habitación. Una vez las pantallas estaban implementadas y los textos iniciales de las acciones se generaban, se porcedió a añadir los JTextAreas a la ventana de juego. No resultó complicado añadir estas componentes ya que sólo hubo que modificar la clase principal del juego. Ahora, para que los textos generados aparecieran en las JTextAreas hubo que implementar un clase singleton llamada TextManager. Esta clase es iniciada una vez en la clase StartScreen que le pasaría las dos JTextAreas que se encargaría de manejar. Así, cuando se necesitase escribir algo, se llamaría al getInstance de TextManager y se le llamaría a su función writeText() en la que se le pasa el texto a escribir en formato String y un 1 o un 2 para identificar la JTextArea en la que se quiere escribir. Finalmente, añadir que este manager también controla el eliminado de la primera línea, el borrado de contenido de una JTextArea y reemplazar líneas. Para controlar las entradas y evitar problemas con el focus de los JTextAreas, se definieron dentro de estas KeyListeners y, en estos, se estableció en la función keyPressed que se controlasen las teclas de dirección, que se usarían para desplazarse por la pantalla de texto. El resto de entradas serían dirigidas a la pantalla que estuviese presente en ese momento para que se traten de la forma correspondiente. Si hay algún cambio de pantalla a causa de la entrada, el KeyListener se encargará de establecerla como la pantalla actual y se llamara a que se vuelva 30.