Está en la página 1de 94

Escuela

Politécnica
Superior

Narrativa digital con


Inteligencia Artificial en
Python
Grado en Ingeniería Multimedia

Trabajo Fin de Grado


Autor:
Francesc Bellido Delgado
Tutor/es:
Francisco de Borja Navarro Colorado
David Tomás Díaz

Mayo 2022
Narrativa digital con Inteligencia
Artificial en Python

Ren’Py es un motor de novela visual libre que permite crear historias


interactivas complejas mediante un lenguaje de script. Una de sus
características más potentes es que permite usar código en Python
para añadir opciones más complejas a los juegos. Aprovechando esta
posibilidad, la finalidad de este TFG es desarrollar una historia
interactiva usando el motor de Ren’Py y utilizando librerías de
inteligencia artificial de Python para dotar a los personajes del juego y
a la historia de más dinamismo.

Autor
Francesc Bellido Delgado

Tutor/es
Francisco de Borja Navarro Colorado
B158 Lenguajes y Sistemas Informáticos
David Tomás Díaz
B158 Lenguajes y Sistemas Informáticos

Grado en Ingeniería Multimedia

Escuela
Politécnica
Superior

ALICANTE, Mayo 2022


Preámbulo
El presente proyecto nace a partir de la propuesta conjunta de mis tutores Francisco de Bor-
ja Navarro Colorado y David Tomás Díaz. Esta propuesta de tenía como finalidad desarrollar
una historia interactiva haciendo uso del motor Ren’Py y utilizando librerías de Inteligencia
Artifial de Python para dotar a los personajes y a la historia de más dinamismo.

Después de realizar el ABP de 4º de carrera buscaba nuevos retos y la IA me parecía muy


interesante de cara a continuar mis estudios. La propuesta de implementar una narrativa
digital con IA utilizando Python y Ren’Py me convenció desde el principio porque era algo
nuevo para mí, ya que no había hecho ningún desarrollo previo con estas tecnologías.

Tras el estudio necesario para encarar el proyecto y todo su proceso de desarrollo, he de


reconocer que la experiencia ha sido gratificante y que, por lo tanto, la decisión que tomé al
escoger esta propuesta fue muy acertada.

Esta memoria tratará de guiar a lector para que conozca la dicotomía en la que se envuelve
el proyecto, obtenga unos conocimientos teóricos con los que comprenda su alcance y pueda
apreciar el resultado final obtenido.

Por último, para que los lectores puedan disfrutar de la narrativa digital, se comparte el
software junto a una guía de uso en el siguiente enlace:

https://github.com/FrancescBellido/TFG_NarrativaDigital
Agradecimientos

Me encantaría dedicar este espacio a todas las personas que de una manera u otra han
colaborado para que este proyecto fuera el mejor posible.

Todas aquellas personas que me iban preguntando cada cierto tiempo qué tal llevaba este
Trabajo Fin de Grado y me animaban a continuar forman parte del resultado final.

Agradecer enormemente, como no puede ser de otra manera, a mis tutores Borja y David
el trabajo realizado resolviendo dudas, sugiriendo ideas, opinando de los avances y, en defi-
nitiva, guiando este proyecto.

Mis reconocimientos a todas las personas que han colaborado en la evaluación del proyecto
y han sugerido mejoras y reconocido los avances. El punto más gratificante del desarrollo
siempre es saber que hay personas que han podido disfrutar con el juego final.

No puedo acabar sin mencionar a mi familia, a mis amigos de Xixona y a mis compañeros
de la Universidad de Alicante. Todos ellos son mis pilares del día a día.
A mis padres y abuelos.
Ellos han formado la persona que soy hoy
y se merecen lo mejor.

ix
Ser humano es ser ‘un’ humano: una persona específica, con una historia de vida, idiosincrasia y
punto de vista. La Inteligencia Artificial sugiere que la línea entre las máquinas inteligentes y las
personas se desdibuja más cuando se hace un puré de esa identidad

Brian Christian.

xi
Índice general
1. Introducción y justificación del proyecto 1

2. Objetivos 3

3. Metodología 5
3.1. Herramientas de productividad y gestión documental. . . . . . . . . . . . . . 5
3.2. Etapas de desarrollo del proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . 6

4. Marco teórico 9
4.1. Dicotomía entre contenido procedural y estático . . . . . . . . . . . . . . . . . 9
4.2. Diferencias entre el contenido al azar y el contenido procedural . . . . . . . . 13

5. Estado de la cuestión 17
5.1. Videojuegos del género novela visual . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Videojuegos con IA de comprensión y generación de texto . . . . . . . . . . . 20
5.3. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6. Herramientas y tecnologías 25
6.1. Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3. Insomnia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4. Ren’Py . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.5. GPT-3 y GPT-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.6. Flask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.7. MarIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.8. GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7. Arquitectura del sistema 29


7.1. Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.3. Esquema de funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

8. Narrativa 35

9. Evaluación 37
9.1. Autoevaluación de la primera versión . . . . . . . . . . . . . . . . . . . . . . . 37
9.2. Opiniones y sugerencias de los usuarios tras probar la primera versión . . . . 41
9.3. Segunda versión desarrollada . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.4. Formulario de evaluación de la segunda versión . . . . . . . . . . . . . . . . . 44
9.5. Resultados de la evaluación de la segunda versión . . . . . . . . . . . . . . . . 48

xiii
xiv Índice general

9.6. Versión final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

10.Conclusiones 55
10.1. Análisis del cumplimiento de los objetivos planteados . . . . . . . . . . . . . . 55
10.2. Resultado obtenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
10.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Bibliografía 63

Lista de Acrónimos y Abreviaturas 67

A. Anexos 69
A.1. Guión del videojuego . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.1.1. Argumento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.1.2. Personajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.1.2.1. Dueño del androide . . . . . . . . . . . . . . . . . . . . . . . 69
A.1.2.2. Detective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.1.2.3. Jefe de policía . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.1.2.4. Sospechosos . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.1.3. Diálogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.1.3.1. Primera escena . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.1.3.2. Interrogatorio . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A.1.3.3. Desenlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
A.1.3.4. Créditos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
A.1.4. Justificación narrativa de la elección de imágenes y sonidos . . . . . . 75
A.2. Material de terceros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.2.1. Imágenes de personajes . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.2.2. Imágenes de escenas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A.2.3. Sonidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Índice de figuras
3.1. Registro de tareas en Toggl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Registro de bibliografía en Zotero. . . . . . . . . . . . . . . . . . . . . . . . . 6

4.1. ©Nintendo. Pokémon Mystery Dungeon. . . . . . . . . . . . . . . . . . . . . . 14

7.1. Esquema de componentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29


7.2. Ficheros del sistema de juego. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.3. Pantalla de carga. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.4. CMD con servidor levantado. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.5. Esquema de funcionamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

9.1. Primeras escenas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37


9.2. Conversación inicial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.3. Presentación de sospechosos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.4. Elección final. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9.5. Desenlace del juego. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.6. Temáticas de pregunta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.7. Preguntas de cada temática. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.8. Introducción formulario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.9. Primera pregunta del formulario. . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.10. Segunda pregunta del formulario. . . . . . . . . . . . . . . . . . . . . . . . . . 45
9.11. Preguntas sobre dificultad, gráficos y sonidos. . . . . . . . . . . . . . . . . . . 46
9.12. Petición del contenido generado en test.txt. . . . . . . . . . . . . . . . . . . . 47
9.13. Apartado de errores y sugerencias. . . . . . . . . . . . . . . . . . . . . . . . . 47
9.14. Número de partidas jugadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
9.15. Número de partidas jugadas hasta conseguir ganar. . . . . . . . . . . . . . . . 48
9.16. Grado de dificultad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
9.17. Valoración de gráficos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
9.18. Valoración de sonidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.19. Contenido del fichero test.txt. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9.20. Errores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
9.21. Sugerencias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
9.22. Opción de vuelta a atrás. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.23. Pantalla de victoria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.24. Pantalla de derrota. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

10.1. Ren’Py Launcher. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56


10.2. Prueba inicial de desarrollo en Ren’Py. . . . . . . . . . . . . . . . . . . . . . . 56
10.3. Tutoriales de OpenAI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
10.4. Llamada a servidor desde navegador. . . . . . . . . . . . . . . . . . . . . . . . 58

xv
xvi Índice de figuras

10.5. Llamada a servidor desde Insomnia. . . . . . . . . . . . . . . . . . . . . . . . 58


10.6. Chatbot - Introducción de mensaje. . . . . . . . . . . . . . . . . . . . . . . . . 59
10.7. Chatbot - Ejemplo de respuesta. . . . . . . . . . . . . . . . . . . . . . . . . . . 59

A.1. Sprites del jefe de policía. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70


A.2. Sprites de Anna, la primera sospechosa. . . . . . . . . . . . . . . . . . . . . . 71
A.3. Sprites de Daniel, el segundo sospechoso. . . . . . . . . . . . . . . . . . . . . . 71
A.4. Sprites de Emma, la tercera sospechosa. . . . . . . . . . . . . . . . . . . . . . 71
1. Introducción y justificación del proyecto
En este proyecto de Trabajo Fin de Grado (TFG) se ha creado una narración interactiva
que incorpora librerías de Inteligencia Artificial (IA) dedicadas a la Generación de Lenguaje
Natural (NLG). La IA participa en la narración como un personaje más. El proyecto se ha
desarrollado con el motor de juego Ren’Py1 y su conectividad con el lenguaje de programa-
ción Python2 .

Las narraciones interactivas permiten un diálogo entre la tecnología que contiene y el ju-
gador3 . Esta interacción suele verse emitida mediante puzles o diálogos con los personajes de
la narración. El juego pondrá al jugador en situaciones dónde deberá elegir una opción u otra
para continuar la aventura. Estas decisiones serán tomadas en cuenta y de ellas dependerá
el avance del jugador en la historia pudiendo dar lugar a desenlaces diferentes4 . Estas narra-
ciones interactivas, que tienen sus inicios en los libros interactivos, han llegado al mundo del
videojuego mediante los géneros de aventura gráfica, novela visual (visual novel en inglés)
o únicamente incorporando elementos en géneros como los videojuegos de acción o aventura5 .

Para el desarrollo de nuestro proyecto nos basaremos en el género novela visual. Este género
que nace en Japón6 cuenta historias donde el apartado visual se reduce a fondos y personajes
estáticos que dependiendo de nuestra interacción irán cambiando de expresión. El punto más
atractivo de estos videojuegos está en sus complejas historias y giros de guion. El motor de
juego Ren’Py es muy popular para el desarrollo de este tipo de juegos. Algunos de los juegos
más destacados del género han sido desarrollados con este motor, como es el caso de Doki Doki
Literature Club! 7 , un videojuego que cuenta la historia de un alumno de instituto que tendrá
que lidiar con sus relaciones personales de forma correcta si no quiere verse ante situaciones
catastróficas llegando a pasar de una historia alegre e infantil a una de terror psicológico.

Para implementar nuestra novela visual haremos uso del lenguaje de programación Python,
el cual tiene integración directa con Ren’Py y nos permitirá desarrollar scripts en nuestro
videojuego. Python es un lenguaje de alto nivel y multiparadigma con cada vez más usuarios
1
Ren’Py. https://www.renpy.org/
2
Python. https://www.python.org/
3
María Rodríguez Juárez, «Historias interactivas, cuando te conviertes en el protagonista del cuento», Revis-
ta Digital, 24 de septiembre de 2020. https://revistadigital.inesem.es/diseno-y-artes-graficas/
historias-interactivas/
4
Juanjo Mestre, «Narrativas interactivas: ¿cuál usar y por qué?», FLUOR Lifestyle, 20 de febrero de 2018.
https://fluorlifestyle.com/narrativas-interactivas-usar/
5
Francisco J. Brenlla, «La narrativa en los videojuegos: Historias y conflictos interactivos», MeriStation, 20
de noviembre de 2020. https://as.com/meristation/2020/11/20/reportajes/1605863800_319793.html
6
Gonzalo Scholz, «Novelas Visuales: la evolución de un género aún incomprendido en occidente», Guardado
Rápido, 11 de febrero de 2021. https://www.guardadorapido.com/reportaje-novelas-visuales/
7
Doki Doki Literature Club! https://ddlc.moe/

1
2 Introducción y justificación del proyecto

que ofrece multitud de posibilidades. Actualmente, es el lenguaje de programación con mayor


uso en el ámbito de la IA con librerías para computación científica, computación avanzada o
aprendizaje automático por lo que creemos que es idóneo para este proyecto.

Las librerías de comprensión y generación de texto nos permiten completar frases, par-
ticipar en una conversación o responder preguntas. En realidad, estas librerías tienen un
potencial mucho mayor pudiendo generar código de programación en diferentes lenguajes o
redactar noticias para un periódico digital. En nuestro proyecto vamos a explorar la madurez
y la idoneidad de estas librerías para ser incorporadas en un videojuego y así analizar la
capacidad de las librerías de IA de comprensión y generación de texto como un medio de
entretenimiento.

A continuación se describe la estructura de este documento, indicando los temas a tratar


en cada sección. En la Sección 2 analizaremos y enumeramos los objetivos que pretendemos
cubrir en este TFG; en la Sección 3 explicaremos la metodología a seguir para la consecución
de los objetivos; en la Sección 4 plantearemos un marco teórico en el que introduciremos los
conceptos necesarios para entender la problemática sobre la que se orienta el proyecto; en la
Sección 5 analizaremos el estado de la cuestión, explorando las herramientas similares que
ofrece el mercado y analizando el grado de innovación de nuestro proyecto; en la Sección 6
explicaremos las herramientas y tecnologías que usamos en todo el conjunto del desarrollo;
en la Sección 7 explicaremos la arquitectura del programa analizando los pasos que llevan al
funcionamiento del mismo; en la Sección 8 describiremos la narrativa de la historia a contar y
los puntos de inflexión de la misma; en la Sección 9 realizaremos una evaluación del proyecto
e interpretaremos sus resultados; en la Sección 10 se expondrán las principales conclusiones
del proyecto, todo lo aprendido y los puntos a mejorar en trabajos futuros.

Se puede acceder al repositorio del proyecto mediante el siguiente enlace: https://github


.com/FrancescBellido/TFG_NarrativaDigital
2. Objetivos
El objetivo principal de este TFG es desarrollar una novela visual que incorpore el uso de
las librerías de IA de comprensión y generación de texto.

Para ello se han establecido los siguientes objetivos parciales:

O1: Estudiar GPT-2 y GPT-3, librerías de IA para la generación de lenguaje natural en


Python.

Se realizará un estudio de estas librerías y sobre cómo puede encajar su uso dentro de una
narración interactiva. Analizaremos sus posibilidades y características, así como ejemplos de
uso.

O2: Profundizar en el estudio del género de videojuego novela visual (dentro del cual se
catalogará nuestra narrativa digital).

Se estudiará el mercado de los videojuegos novela visual, un género muy popular en Japón
y que poco a poco está llegando a occidente. Estos videojuegos consisten en el transcurso de
una historia en la que el jugador tiene momentos de decisión intermitente que dependiendo
de las respuestas harán cambiar el desenlace de la aventura. Su apartado visual se reduce a
imágenes de personajes y fondos estáticos, dando así un mayor peso a su narrativa.

O3: Estudiar del uso de la IA de NLG en el ámbito de los videojuegos

Se analizarán diferentes videojuegos que empleen el uso de librerías de IA con el objetivo de


explorar el uso que han dado otros desarrolladores a estas librerías. Se hará especial hincapié
en los videojuegos del género de novelas visuales.

O4: Desarrollar una narración interactiva que vaya más allá de los videojuegos tradicionales
del género novela visual e incorpore elementos de IA que permitan un mayor dinamismo a
su historia.

Se deberá desarrollar una idea de narrativa en la que las librerías de IA encajen de forma
que la comprensión y generación de texto aporte a la jugabilidad y permita a los jugadores
obtener respuestas diferentes en cada partida. En los juegos tradicionales el usuario toma
decisiones que marcan un camino y guían el transcurso de la historia. Esto sólo permite la
rejugabilidad de elegir un camino distinto tomando decisiones contrarias a las tomadas en la
partida anterior. El objetivo es ir más allá, de forma que, mediante la generación de texto por
código, los diálogos puedan ser diferentes en cada partida sin perder la coherencia narrativa.

3
4 Objetivos

O5: Evaluar del proyecto desarrollado.

Buscaremos formas de evaluar nuestro proyecto, analizando así los puntos a mejorar y
pudiendo iterar la evaluación y el desarrollo del proyecto con el objetivo de conseguir el
mejor resultado posible para el público general. El principal método de evaluación será dar
a probar el juego a nuevos usuarios para analizar su primera impresión y su opinión después
de jugar. Se buscará que el juego se sienta dinámico y tenga una jugabilidad disfrutable para
personas que jueguen a videojuegos de manera casual.
3. Metodología

3.1. Herramientas de productividad y gestión documental.


Para la gestión y planificación de este TFG se emplea la herramienta Toggl 1 que permi-
te cronometrar el tiempo que dedicamos a las tareas, pudiendo realizar así un control del
tiempo. Cada día antes de ponernos a trabajar activamos el temporizador de Toggl indicando
una descripción de la tarea que vamos a realizar, seleccionamos el proyecto en el que estamos
trabajando (en este caso el presente TFG) y añadimos las etiquetas pertinentes para poder
diferenciar el tipo de tarea que estamos realizando, las cuales podríamos dividir en “Estudio”,
“Investigación”, “Programación”, “Memoria”, etc. El uso de este tipo de herramientas puede
permitirnos ser más productivos ya que podemos ver cuánto tiempo hemos dedicado a cada
tarea evitando excederse en el tiempo dedicado a tareas menos importantes y ayudando a
centrar el foco en los objetivos que requieren más tiempo.

La siguiente imagen muestra el registro que hace Toggl del tiempo y de las tareas. En
primer lugar, muestra el nombre de la tarea y a su derecha se indica a qué proyecto pertene-
ce. Después se muestran las etiquetas que hemos colocado a la tarea y el usuario que la ha
realizado ya que esta herramienta permite la colaboración de usuarios Por último, se indica
el tiempo que ha durado la tarea y el período de tiempo en el que trabajamos.

Figura 3.1: Registro de tareas en Toggl.

1
Toggl Track. https://toggl.com/

5
6 Metodología

Por otro lado, para la gestión de la bibliografía recurrimos al software Zotero2 . Este progra-
ma nos permite almacenar las bibliografías que consultemos, pudiendo registrar y clasificar la
información pertinente de cada una (tanto de documentos, libros, páginas web, artículos de
periódico, entrevistas o programas informáticos). Además de la utilidad que ya supone este
almacenamiento, nos permite exportar estas bibliografías a un documento de texto pudiendo
seleccionar el estilo de cita que queramos (por ejemplo, IEEE).

Figura 3.2: Registro de bibliografía en Zotero.

3.2. Etapas de desarrollo del proyecto.


Para el desarrollo del presente proyecto se han establecido las siguientes etapas o pasos:

1. El primer paso para empezar a desarrollar nuestra narración interactiva es estudiar


el lenguaje de programación Python, el motor de juego de novela visual Ren’Py y las
librerías de comprensión y generación de texto más populares: GPT-3 3 y GPT-2.

2
Zotero. https://www.zotero.org/
3
Tom Brown et al., Language Models are Few-Shot Learners. OpenAI. https://papers.nips.cc/paper/
2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html

Otros enlaces de interés:


https://openai.com/
https://openai.com/blog/openai-api/
https://openai.com/blog/gpt-2-1-5b-release/
https://arxiv.org/abs/2005.14165
3.2. Etapas de desarrollo del proyecto. 7

2. El segundo paso es conectar las librerías de IA con el motor Ren’Py mediante scripts
de Python. Ren’Py no permite el uso de estas librerías específicas pero sí permite im-
portar módulos y paquetes de Python puro, por lo que desarrollaremos una API donde
haremos uso de las librerías de IA y en el script llamaremos a esta API mediante
las funciones de requests que nos permiten hacer llamadas a un servidor. Enviaremos
a la API texto de entrada y nos devolverá el texto autogenerado que usaremos co-
mo respuesta en el juego. Este proceso se detalla en la Sección 7 donde se explica la
arquitectura del programa analizando los pasos que llevan al funcionamiento del mismo.

3. El tercer paso es plantear una historia donde el uso de las librerías de IA aporten di-
namismo y jugabilidad y desarrollarla para jugar a través de Ren’Py.

4. El cuarto paso es añadir al videojuego los elementos gráficos y sonoros necesarios: imá-
genes de personajes (con sus respectivas expresiones) y de escenarios y música.

5. Cuando tengamos una versión inicial deberemos buscar opiniones para poder mejorar la
jugabilidad del juego, tal como hemos comentado en el O5 de la Sección 2. Deberemos
iterar esta acción hasta conseguir que se sienta dinámico y disfrutable para el público
general y casual de videojuegos.
4. Marco teórico
En esta sección vamos a sentar las bases de conceptos teóricos necesarios para entender la
problemática sobre la que trata y enfrenta este TFG.

En primer lugar, explicaremos la dicotomía entre el contenido procedural y estático. Este


punto es muy importante, pues todo el proyecto se envuelve en esta dicotomía debido al uso
de las librerías de NLG que completarán parte de nuestra narración interactiva.

Posteriormente, diferenciaremos la generación de contenido procedural y aleatorio, ambos


presentes en el mundo de los videojuegos.

4.1. Dicotomía entre contenido procedural y estático


El presente TFG se enmarca en una dicotomía entre la generación de contenido procedural
o estático (hard-code). Explicado de otra forma, separaremos el contenido generado por IA y
contenido generado por humanos.

Como explica Fernández Vara en su libro Introduction to game analysis1 , la forma en que se
genera el contenido es esencial para definir un videojuego aunque las personas sin conocimien-
tos en programación no entenderán de primeras está diferencia. La dicotomía entre contenido
procedural y estático es en realidad una dicotomía entre datos (estáticos, no cambian en las
diferentes sesiones de juego) y procesos (instrucciones para crear los propios datos). Los datos
ocupan espacio de memoria y son específicos (por ejemplo, ficheros de imágenes o sonidos),
en cambio los procesos necesitan mayor capacidad técnica ya que tenemos que generar esos
datos a partir de código. Esta segunda opción permite, por ejemplo, poder generar a par-
tir de una partitura diferentes variaciones melódicas dependiendo de la situación en la que
se encuentre el jugador, podríamos aumentar el ritmo de la música si se encuentra el juga-
dor en una situación de tensión o, en caso contrario, si se encuentra en calma reducir el ritmo.

Desde una perspectiva más técnica, tal como indica Chris Crawford en su libro On game
design2 , todos los programas combinan datos (tablas de datos, imágenes, sonido y texto) y
procesos (algoritmos, ecuaciones y ramificaciones). Por lo que más que programas de conte-
nido procedural o estático, diferenciaremos programas intensivos en datos o en procesos. Los
primeros ocupan la mayor parte de su tiempo en el movimiento de los bytes de los respectivos
datos y los segundos realizando cálculos y procesando números.

1
Fernández Vara, Introduction to game analysis. Routledge, 2019.
2
Chris Crawford, On game design, 1st edition. Indianapolis, Ind.: New Riders, 2003.

9
10 Marco teórico

La clave para identificar si un contenido es procedural o estático es observar si el con-


tenido cambia en cada partida o si sus personajes, niveles, animaciones o sonidos tienen
comportamientos totalmente diferentes dependiendo de la misma. Si la primera cuestión es
cierta habría que diferenciar entre contenido aleatorio y procedural, lo cual analizaremos en
el siguiente apartado. Si la segunda opción es cierta, el contenido es efectivamente procedural.

Identificar un contenido estático es más sencillo, todo aquel que permanece invariable entre
partidas es estático. El contenido de la inmensa mayoría del medio tiene está condición y por
eso el contenido procedural es tan interesante e innovador. Por mencionar un ejemplo, el
contenido de un videojuego conocido por todos como New Super Mario Bros3 es estático en
su totalidad. Los niveles y comportamientos de los enemigos son iguales en cada partida y
para cada jugador. Nuestro TFG dejará de lado estos videojuegos y se focalizará en aquellos
que, al menos, combinan el contenido estático y el contenido procedural.

En el mundo de los videojuegos hay ejemplos de uso de contenido procedural muy dife-
rentes. Hay videojuegos que utilizan esta tecnología para la generación de misiones, mapas,
sonido o texto (como algunos de los proyectos mencionados anteriormente). Vamos a analizar
algunos ejemplos de videojuegos que utilizan esta tecnología.

Fernández Vara menciona Elite (1984, influido también por las limitaciones de la época)4 ,
Tiny Wings5 y The Elder Scrolls: Skyrim (2011)6 como ejemplos de juegos con contenido
generado proceduralmente. Estos juegos aprovechan los procesos para poder dar novedades al
jugador sin recurrir a un almacenamiento masivo de datos. El videojuego The Elder Scrolls:
Skyrim crea misiones de forma procedural que tienen en cuenta el ancho mundo y la población
del mismo.

Del mismo modo, debemos mencionar a uno de los colosos del medio: Minecraft 7 . Este popu-
lar videojuego utiliza generación de contenido procedural para la generación de sus mundos8 .
Esto consigue que cada servidor de Minecraft sea totalmente diferente, consiguiendo crear
diferentes biomas (bosques, montañas, playas, mares, cuevas, desiertos…) consistentes entre sí.

Por otro lado, No Man’s Sky 9 , el videojuego de Hello Games, prometió generar un universo
con hasta 18 trillones de planetas con faunas y floras diferentes10 . este juego también utiliza
sonido procedural, es decir, su música ambiental y otros elementos de la banda sonora no
están pregrabados sino que se generan conforme se juega y se adapta a cómo juguemos11 .
3
New Super Mario Bros. https://www.nintendo.es/Juegos/Nintendo-DS/New-Super-Mario-Bros-271969
.html
4
Elite. http://www.acomsoft.com/
5
Tiny Wings. https://apps.apple.com/es/app/tiny-wings/id417817520
6
The Elder Scrolls V: Skyrim. https://elderscrolls.bethesda.net/es/skyrim
7
Minecraft. https://www.minecraft.net/es-es
8
Martín Rodríguez, «¿Qué es la generación por procedimiento en los videojuegos?», Gamerfocus, 9 de agosto
de 2016. https://www.gamerfocus.co/juegos/la-generacion-procedimiento/
9
No Man’s Sky. https://www.nomanssky.com/
10
Alex C, «Las siete promesas que hizo No Man’s Sky, ¿humo o realidad?», Xataka, 10 de agosto de 2016.
https://www.xataka.com/videojuegos/las-7-promesas-que-hizo-no-man-s-sky-humo-o-realidad
11
Miguel López, «Qué es el sonido procedural y cómo se utilizará en “No Man’s Sky”», Xataka, 17 de julio de
4.1. Dicotomía entre contenido procedural y estático 11

Mediante generación procedural de sonido se puede llegar a conseguir creación musical algo-
rítmica. Si bien a lo largo de estos años el medio ha conseguido una auténtica revolución a
nivel visual, el aspecto sonoro ha evolucionado a una menor velocidad, tal como indica Raúl
Ibarra Díaz en su interesantísimo proyecto Generación de música ambiental de videojuegos
por medio de composición algorítmica basada en el modo de juego12 .

Por último, está la generación procedural de texto (sobre la que se enmarca este TFG) y
más en concreto la generación automática de diálogo. Esta, si bien tiene un punto de alea-
toriedad, consigue generar un texto coherente y con sentido para un humano (de ahí que se
pueda introducir para generar diálogo con el jugador). En nuestro caso, vamos a aplicar la
creación procedural mediante un sistema de generación de lenguaje natural (NLG). El uso
de sistemas NLG está en pleno auge y con él se han desarrollado desde chatbots hasta auto-
descriptores de imágenes. Tal como indica Robert Dale, está previsto que la incorporación de
redes neuronales en esta tecnología cambie por completo en el futuro el medio de la comuni-
cación atribuyéndose, al menos, la coautoría de la mayoría de las notícias13 . En el próximo
punto 5.2 “Videojuegos con IA de comprensión y generación de texto” comentaremos los
proyectos más ambiciosos que se han llevado a cabo sobre esta cuestión.

Junto a las mejoras gráficas o la personalización, creo que la próxima revolución del mundo
de los videojuegos será la mejora de las conversaciones con la entrada del procesamiento del
lenguaje natural. Esta tecnología hará que los juegos sean mucho más inmersivos. Para este
procesamiento se necesitará una gran computación y redes neuronales capaces de procesar y
administrar datos en función de innumerables parámetros, pero el resultado serán conversa-
ciones de apariencia humana14 .

En el futuro la IA irá mucho más allá del papel que pueda tener en el apartado creativo
y artístico. Según Nick Statt, la IA ayudará a desarrollar los videojuegos: ayudará al testing
de los mismos encontrando y solucionando errores de programación, mediante el aprendizaje
automático podrá realizar análisis de la forma de jugar y/o comportamiento de los usuarios
para poder mejorar el videojuego constantemente haciendo que el mismo se vaya actualizando
para evitar que su estilo o dificultad envejezcan con el paso del tiempo. Es más, se podría
desarrollar que la IA adaptará cada videojuego a cada jugador llevando la personalización a
límites insospechados15 .

2016. https://www.xataka.com/videojuegos/que-es-el-sonido-procedural-y-como-se-utilizara-en
-no-man-s-sky
12
Raúl Ibarra Díez, «Generación de música ambiental de videojuegos por medio de composición algorítmica
basada en el modo de juego». Escuela Politécnica Superior de la Universidad de Alicante, septiembre de
2014. https://grfia.dlsi.ua.es/cm/pfc/ribarra/memoria.pdf
13
Robert Dale, «Natural language generation: The commercial state of the art in 2020», en Natu-
ral Language Engineering, vol. 26(4), Cambridge University Press, 2020, pp. 481-487. https://
www.cambridge.org/core/journals/natural-language-engineering/article/natural-language
-generation-the-commercial-state-of-the-art-in-2020/BA2417D73AF29F8073FF5B611CDEB97F
doi: 10.1017/S135132492000025X
14
«4 Ways AI is Changing Gaming for the Better», Samsung Semiconductor, 24 de junio de 2021. https://
samsungsemiconductor-us.com/4-ways-ai-is-changing-gaming-for-the-better/
15
Nick Statt, «How Artificial Intelligence will revolutionize the way video games are developed and played»,
The Verge, 6 de marzo de 2019. https://www.theverge.com/2019/3/6/18222203/video-game-ai-future
12 Marco teórico

Las limitaciones que tiene la tecnología NLG en general y de la generación de diálogo en


particular es la coherencia y la intención. Hoy en día, el texto generado automáticamente
puede ser coherente desde nuestra perspectiva humana pero es complicado darle coherencia
dentro de un marco más general. En nuestro caso, darle coherencia dentro de la narrativa del
juego donde el contexto juega un papel importante.

Los humanos cuando hablamos lo hacemos con una intención, al igual que los personajes de
un videojuego. En cambio, los sistemas NLG no tienen esa intencionalidad en los textos que
generan. GPT-3 nos permitirá crear texto a partir de una frase, responder de forma coheren-
te una pregunta o crear una narración por sí mismo. Sin embargo, no podemos decirle que
mienta, que convenza a otra persona o, en el caso de nuestro videojuego, que se defienda en
un interrogatorio. Por lo tanto, podemos decir que NLG no tiene intención cuando genera
texto por lo que aún no puede tratarse como un lenguaje totalmente humano.

Por lo tanto, para que nuestra narrativa tenga sentido vamos a tener que tratar de darle
coherencia al texto generado automáticamente. Para afrontar este problema y para intentar
dar una intencionalidad a nuestros personajes dentro de lo posible, nuestra herramienta para
guiar a GPT-3 va a ser el contexto. Si indicamos más cantidad de información es más pro-
bable que el texto que se genere concuerde con lo que esperemos. Por ejemplo, si yo indico
una pregunta como “Policía: ¿Eres el asesino? Tú:” la respuesta puede ser cualquiera. La
IA podría responder sí, no o depende. En cambio sí el texto de entrada que le llega a la IA
es “Has sido erróneamente acusado de asesinar a una persona. Estás en un interrogatorio y
debes defenderte. Policía: ¿Cómo se declara el acusado? Tú:” es más probable que el texto
generado sea “Inocente”. Este método no es infalible ya que NLG como hemos comentado
anteriormente tiene un punto de aleatoriedad. Podría darse el caso de que respondiera “Soy
culpable, yo lo maté” pero dentro de un contexto tan concreto reducimos la aleatoriedad.
Además, si cuando vayamos a hacerle una segunda pregunta añadimos la primera junto con
su respuesta al texto que enviamos para completar en NLG la IA responderá teniendo en
cuenta su respuesta anterior. De esta forma, si realizamos 3 preguntas no serán tres pregun-
tas con respuesta totalmente aleatoria sino que la respuesta siempre estará en parte vinculada
con las respuestas anteriores.

Desde un punto de vista más bien filosófico, el artículo What Might Machines Mean? 16 de
Springerlink, trata la cuestión de si los hablantes artificiales realmente se están comunicando.
Si hablamos de lenguaje puramente humano está claro que hoy en día no es replicable por las
máquinas. Nuestros estados cognitivos como la intención, el deseo, la expectativa, nuestros
recuerdos o nuestros miedos forman parte de nuestra manera de pensar y comunicarnos. El
artículo argumenta que es posible comunicarse sin tener intenciones reflexivo-comunicativas,
pero en cambio habría que hacer una reflexión más profunda si hablamos de afecto. Una
máquina no puede sentir arrepentimiento o alegría ya que, en general, no puede sentir.

-procedural-generation-deep-learning
16
Mitchell Green y Jan G. Michael, «What Might Machines Mean?», Springer Link, 27 de enero de 2022.
https://link.springer.com/article/10.1007/s11023-022-09589-8
4.2. Diferencias entre el contenido al azar y el contenido procedural 13

Por lo tanto, aplicando estos argumentos a nuestro videojuego y teniendo en cuenta que las
máquinas hoy en día ni están imbuidas de conciencia ni tienen principios morales, el jugador
no podría ver en ningún caso alegría, miedo o nervios en las respuestas autogeneradas de
los personajes de nuestra narrativa. Unas disculpas por parte de una máquina nunca serán
sinceras ya que no hay un proceso de arrepentimiento de por medio, por lo que ya reside en
la conciencia de los usuarios interpretar los mensajes producidos por la IA al pie de la letra
o mediante una evaluación moral.

4.2. Diferencias entre el contenido al azar y el contenido


procedural
Debemos hacer hincapié en la diferencia entre el contenido generado al azar y el contenido
procedural (generado mediante IA). Los juegos de azar como las tragaperras, los dados o las
cartas se basan en la aleatoriedad pero no tienen elementos procedurales. Desde el principio
de la partida conoces que el dado únicamente tiene 6 caras y que cuando lo lances caerá en
una de sus caras marcando siempre entre 1 y 6 puntos. Cuando realices una segunda tirada
no cambia ni el dado ni la probabilidad de que toque cada cara. Siempre habrán 6 caras y �
de posibilidades de que el dado caiga en cada una de ellas.

En cambio, el contenido procedural tendría en cuenta los resultados anteriores de forma


que si generamos una imagen de forma procedural no se generará cada píxel de un color
aleatorio sino que en base a unos parámetros los píxeles contiguos se variarán su escala de
color respecto al primero dentro de unos límites de forma que se genarará una imagen más
consistente que la puramente generada en base a la aleatoriedad17 .

Un ejemplo de videojuegos con contenido aleatorio serían los pertenecientes al género ro-
guelike. Este género, que a su vez es un subgénero de los videojuegos de rol, utiliza un sistema
de mazmorras o niveles que contienen un conjunto de salas que están divididas en cuadrícu-
las. Tanto los objetos que aparecen en el escenario como los enemigos se generan también de
manera aleatoria. De esta forma cada vez que visitemos la mazmorra nos encontraremos un
nivel distinto aunque dentro de unos parámetros18 . Un ejemplo de este género es Pokémon
Mundo Misterio19 , como se muestra en la Figura 4.1. Este videojuego incorpora un sistema
de movimientos y ataques por turnos, algo que inicialmente definía al género pero que con la
evolución del mismo y con la entrada de los videojuegos roguelite es un elemento a destacar.

17
«Random normal vs Random Procedural», Ajierda Games, 13 de febrero de 2017. https://arjierdagames
.com/blog/programacion/random-normal-vs-random-procedural/
18
Julián Ramírez, «¿Cuál es la gracia de los ‘roguelikes’?», Gamerfocus, 9 de noviembre de 2020. https://
www.gamerfocus.co/juegos/cual-es-la-gracia-de-los-roguelikes/
19
Pokémon Mundo Misterioso: Equipo de Rescate Azul y Equipo de Rescate Rojo. https://www.nintendo.es/
Juegos/Game-Boy-Advance/Pokemon-Mundo-misterioso-Equipo-de-rescate-rojo-267145.html
14 Marco teórico

Figura 4.1: ©Nintendo. Pokémon Mystery Dungeon.

Para poder diferenciar claramente los roguelike de los roguelite vamos a definirlos deta-
lladamente. Un roguelike es un videojuego que tiene un sistema de mazmorras donde las
habitaciones y pasillos se generan aleatoriamente de forma que el jugador no sabe dónde
estarán los objetos y enemigos. Además, el mapa tiene que estar dividido por casillas, contar
con un sistema de turnos, control de recursos (objetos, habilidades, etc) y muerte permanente,
es decir, si morimos nos tocará empezar desde el principio en una nueva mazmorra aleatoria.
En cambio, un roguelite sería un videojuego que cumple algunas de las características ante-
riormente mencionadas pero no la totalidad de ellas. De ahí el nombre roguelite, que querría
decir roguelike ligero20 .

En realidad, la mayoría de jugadores no hacen esta distinción entre roguelike y roguelite


ya que ambos tienen como elemento principal la aleatoriedad. Sin embargo, para los más
puristas del género, un videojuego sólo puede considerarse como roguelike si al menos contie-
ne escenarios aleatorios, sistema por turnos y muerte permanente. Por ejemplo, el éxito de
ventas The Binding of Isaac21 estaría encajado en este segundo género ya que no incorpora
el sistema por turnos, aunque generalmente siempre se le ha atribuido el género roguelike sin
profundizar en esta distinción.

20
Alma López, «¿Qué es un roguelike? ¿y un roguelite?», Juegos ADN, 29 de septiembre de 2020. https://
juegosadn.es/que-es-un-rogue-lite-y-un-rogue-like-ar-3790/
21
The Binding Of Isaac. https://store.steampowered.com/app/113200/The_Binding_of_Isaac/
4.2. Diferencias entre el contenido al azar y el contenido procedural 15

Por otro lado, lo mismo ocurre con Rogue Legacy22 , videojuego de plataformas/acción 2D
que cuenta con mazmorras aleatorias pero que no cuenta con un sistema de combate por
turnos. Una de las peculiaridades de este título es que el héroe con el que jugamos también
tendrá un componente aleatorio pues tras morir se nos permitirá elegir entre tres herederos
y todos ellos tendrán una combinación de particularidades diferentes que harán variar la
forma de jugar. Estas pueden ser tanto negativas como positivas yendo desde pérdida de un
porcentaje de la visión hasta poder crear plataformas23 . Como podemos ver con todos estos
ejemplos, la innovación sobre la aleatoriedad en los videojuegos se encuentra en un proceso
constante.

22
Rogue Legacy. https://store.steampowered.com/app/241600/Rogue_Legacy/
23
Antonio Matías, «Rogue Legacy Review: un roguelike que no debe perderse», Guía Game, 9 de abril de
2021. https://guiagame.com/rogue-legacy-review-un-roguelike-que-no-debe-perderse/
5. Estado de la cuestión
En este apartado analizaremos el género de las novelas visuales y las experiencias narrati-
vas generadas con IA por separado con el objetivo de estudiar que aportaría la combinación
de ambas.

5.1. Videojuegos del género novela visual


Las novelas visuales son un género de videojuegos muy popular en Japón. Estos juegos
tratan de una historia con la que el jugador interactúa mediante opciones de diálogo. Las
características que hacen a este género diferente son sus historias complejas, sus escenarios
y personajes estáticos, el diferente transcurso de la historia según las decisiones del jugador
que pueden hacer que llegue a variar el final del juego y, en su mayoría de casos, su arte estilo
anime.

Para el desarrollo de este tipo de videojuegos y narraciones interactivas en general existen


diferentes motores como Twine, Ink o Ren’Py.

Twine1 es un motor que permite crear narraciones interactivas no lineales sin usar código.
Usa un sistema de ramificaciones donde el desarrollador indicará cómo avanza la historia
según la respuesta. Además, publica directamente los juegos en formato HTML por lo que
cuando esté listo se puede llegar a modificar incluyendo CSS o JavaScript.

El videojuego 57º North2 que está disponible para Android y iOS y permite conectividad
con Realidad Virtual (RV, o en inglés VR) ha sido desarrollado en Twine. Este juego cuenta
la historia de unos chicos que naufragan en una isla y tienen que intentar sobrevivir y volver a
casa. Durante la aventura se darán cuenta de que la isla esconde misterios ya que observarán
que hay cámaras de seguridad ocultas.

Ink 3 es un lenguaje de scripting narrativo para juegos que puede integrarse en Unity o ex-
portar a web mediante su editor Inky. Ink nos permitirá escribir la historia de nuestro juego
y podremos incluir marcas para la toma de decisiones o los saltos de guión. Su editor Inky
nos permitirá ver el resultado a tiempo real donde podremos probar a seleccionar opciones
para comprobar que todos los caminos de decisión de funcionan correctamente.

1
Twine. https://twinery.org/
2
57° North. https://www.mightycoconut.com/57north/
3
Inkle. https://www.inklestudios.com/ink/

17
18 Estado de la cuestión

Un ejemplo de videojuegos desarrollado con Ink es la saga Sorcery! 4 que cuenta con 4 en-
tregas y está disponible para PC, Android y iOS. Esta saga, que narra una novela de fantasía
plagada de combates, criaturas y hechizos, está basada en los libros de Steve Jackson5 (libros
de “Elige tu propia aventura”).

Ren’Py es un motor de juego dedicado exclusivamente a las novelas visuales. Incluye mu-
chas opciones para el desarrollo de las mismas como sistemas de toma de decisión que nos
permitirán ramificar la historia, sistema de guardado y cargado de partida, transiciones de
imagen y sonido, etc. Además, posibilita volver atrás en la historia simplemente girando la
rueda del ratón. Un punto a destacar es que Ren’Py también permite la integración con
Python, por lo que se puede desarrollar scripts que mejoren e innoven en las novelas visuales
que desarrollemos.

Una de las novelas visuales más populares del momento y que ha sido desarrollada com-
pletamente mediante Ren’Py es Doki Doki Literature Club! 6 . En esta novela el jugador vive
la vida de un joven japonés que tiene que ir al instituto y acaba matriculándose en un club
de literatura junto a un grupo de chicas. El punto fuerte de este videojuego está en sus giros
de guión. Empieza como una novela muy plana y sin demasiada personalidad en la que el ju-
gador flirtea con las chicas del club de literatura pero estas decisiones acaban transformando
una novela de romance en una historia de auténtico terror (no apta para jugadores sensibles)
en la que sufriremos con las consecuencias que supone tomar cada decisión.

En mi opinión, el giro de guión por el que este videojuego ha obtenido reconocimiento llega
tras una introducción demasiado extensa. Además, al necesitar de 5 horas para completarlo
se complica la rejugabilidad para jugadores del público general con un tiempo limitado para
dedicar a videojuegos. Estos puntos serían algo a solventar en el desarrollo de nuestro pro-
yecto.

Otros ejemplos interesantes de videojuegos desarrollados en Ren’Py serían los siguientes:


• Long Live the Queen7 , donde seremos una joven princesa que va a convertirse en reina
y deberemos sobrevivir hasta que llegue el momento de la coronación.
• Magical Diary 8 , donde seremos un estudiante de una escuela de magia y deberemos
aprender hechizos, hacer amistades o aprobar exámenes.
• Date Warp9 , donde una pareja tiene una avería en el coche y deciden refugiarse en una
mansión abandonada cercana. Casualmente allí se encuentran con un grupo de jóvenes
apuestos y tras pasar la noche para poder irse la mañana siguiente ocurre un giro de
guión que lo cambia todo.
4
Sorcery! https://www.inklestudios.com/sorcery/
5
Steve Jackson Games. http://www.sjgames.com/
6
Ramón Varela, «Doki Doki Literature Club Plus supera el medio millón en ventas en apenas dos se-
manas», Vandal, 21 de julio de 2021. https://vandal.elespanol.com/noticia/1350746312/doki-doki
-literature-club-plus-supera-el-medio-millon-en-ventas-en-apenas-dos-semanas/
7
Long Live the Queen. https://www.hanakogames.com/llq.shtml
8
Magical Diary. https://www.hanakogames.com/magical_diary.shtml
9
Date Warp. https://www.hanakogames.com/datewarp.shtml
5.1. Videojuegos del género novela visual 19

• The Royal Trap10 , donde se nos presenta como pretendiente de una princesa. Durante
la ceremonia de boda secuestran a la princesa y la trama de la historia trata de nuestro
protagonista intentando rescatarla.

Ren’Py es el motor con más difusión de los comentados por lo que será el que usaremos
en este proyecto. Además, como podemos ver con el ejemplo de Doki Doki Literature Club! 11
tiene ejemplos de obras de éxito.

Por último, cabe mencionar una novela visual que inicialmente fue lanzada únicamente en
Japón pero que tras su éxito llegó a Europa y es Danganronpa: Trigger Happy Havoc. Su
historia trata de un instituto para estudiantes de alto nivel. A este instituto sólo podrá ir el
alumno más aventajado de cada oficio, como el programador definitivo o el jugador de béisbol
definitivo. Además de esas plazas también se sortea una, que es la oportunidad que consigue
nuestro protagonista para entrar en este instituto. Al poco tiempo el jugador se dará cuenta
de que esa oportunidad quizás no haya sido precisamente buena suerte pues el instituto era
una trampa. Su director, un oso de peluche blanco y negro, tiene encerrados a sus alumnos
con la premisa de que para dejarles escapar tendrán que acabar con la vida de otro alumno
sin que este crimen sea delatado. En seguida, el jugador sentirá la responsabilidad de cada
decisión para mantenerse con vida.

Este juego además incorpora elementos ausentes en las novelas clásicas como escenas donde
el jugador además de responder con opciones a las preguntas podrá clicar a los objetos de
la escena para interactuar o obtener información de ellos. También, hay momentos donde el
jugador podrá moverse entre las diferentes salas del instituto.

A la hora de desarrollar un videojuego del género novela visual unos de los problemas que
encuentro son la duración de las introducciones con las que nos sitúan en la historia y los
escasos momentos de clímax para el jugador. En nuestro proyecto deberíamos solventar estos
problemas incluyendo decisiones de relevancia cada menos tiempo, alternando así decisiones
cuyas consecuencias sean importantes e inmediatas con decisiones de menos calado narrati-
vo. Además, reducir la duración de los juegos animará al jugador a volver a jugarlos para
descubrir los diferentes caminos y desenlaces que ofrece el juego.

Incorporar elementos de IA puede aportar innovación y rejugabilidad a este género puesto


que al autogenerar diálogos las decisiones podrían suponer consecuencias distintas, a dife-
rencia de las novelas visuales clásicas. Cada jugador podría tener una experiencia distinta
pudiendo dar lugar a anécdotas divertidas o misteriosas que compartir con los demás. Aun-
que el juego cuente la misma historia e incluso el jugador tome aparentemente las mismas
decisiones el desenlace será totalmente sorpresa, lo que hará que cada partida se sienta única.

Antes de continuar a la siguiente sección, cabe mencionar que hay juegos, también exce-
lentes, que han adaptado la narración interactiva a los videojuegos de forma diferente a como
lo hacen las novelas visuales. Entre ese tipo de juegos encontramos Detroit: Become Human
10
The Royal Trap. https://www.hanakogames.com/royaltrap.shtml
11
Danganronpa: Trigger Happy Havoc. https://www.danganronpa.com/switch/en/
20 Estado de la cuestión

(2019). Este juego es una de las inspiraciones sobre la que construiremos nuestra narrativa,
tal como desarrollamos en la Sección 8 donde comentamos su contexto narrativo.

La parte jugable de este videojuego es interesante para el presente proyecto de TFG pues
la historia avanza según las decisiones que toma el jugador tanto en diálogo como en explora-
ción, a parte de esto la única otra mecánica que nos encontraremos serán los llamados “Quick
time events” (eventos en los que tendremos que realizar rápidamente una acción, normal-
mente pulsar un determinado botón, para evitar un problema). La mención a este videojuego
terminaría aquí si no fuera un videojuego desarrollado por David Cage, fundador de Quantic
Dream.

“Estamos en un momento en la industria en el que podemos parar de hacer el


atraco al tren o el atraco al banco. Podemos ir hacia algo más sutil. Creo que
deberíamos crear nuestra propia Metrópolis o nuestro Ciudadano Kane” (David
de Gruttola, más conocido por su pseudónimo David Cage).12

Tras su paso por el cine, David Cage siempre ha querido apostar por el apartado narrativo
de los videojuegos. Él siempre ha querido revolucionar la industria, diferenciarse de la aventu-
ra clásica y desconectar de las mecánicas tradicionales como apuntar y disparar. Su objetivo
siempre ha sido crear una obra donde la historia y el jugador sean sólo uno. Esto hace que la
narrativa y la interacción con el jugador sea el punto central de sus obras como se demuestra
en sus lanzamientos Fahrenheit (2005), Heavy Rain (2010), Beyond: Two Souls (2013) o el
ya mencionado Detroit: Become Human (2019). Todos ellos son juegos donde es el jugador
el que decide el camino a tomar y dependiendo de esto el paso de la historia y el final de
la misma difieren según sus decisiones. Al lado de las novelas visuales, estos videojuegos son
superproducciones pero cabe destacar el punto común que tienen ambos: la interactividad
con el jugador determina como continua la historia.

José Altozano, más conocido en Internet como ‘Dayo’, analiza el medio de los videojuegos
y, en particular, el papel de David Cage en la industria en su libro El videojuego a tra-
vés de David Cage13 . En esta tesis se explica como David Cage defiende que el videojuego
puede ser un espacio donde expresar emociones, ideas o sentimientos pero que el medio es
mucho más porque a un videojuego no sólo lo forma su narrativa, sino también sus mecánicas.

5.2. Videojuegos con IA de comprensión y generación de texto


En el mercado actual no encontramos demasiados juegos que incorporen una IA de com-
prensión y generación de texto, en cambio como hemos comentado anteriormente sí que
encontramos una gran oferta de narraciones interactivas que avanzan siguiendo una ramifi-
cación controlada de las decisiones tomadas.

12
D. D. G. Christian Nutt, «Tense Questions: David Cage On Heavy Rain», 26 de marzo de 2010. [Game Deve-
loper]. https://www.gamedeveloper.com/business/tense-questions-david-cage-on-i-heavy-rain-i-
13
José Altozano, El videojuego a través de David Cage. Héroes de Papel. www.heroesdepapel.es
5.2. Videojuegos con IA de comprensión y generación de texto 21

Esto no significa que no haya ningún proyecto que incorpore esta IA. Un ejemplo sería AI
Dungeon14 . Esta herramienta permite a los usuarios crear sus propios escenarios de narracio-
nes interactivas que se irán autocompletando con librerías de IA. Sus juegos son puramente
textuales y dependiendo del juego podremos crear nuestro propio personaje para personalizar
aún más la historia o hacer un inicio rápido. Tras una introducción, en cada turno que le toque
al jugador deberá elegir entre las opciones “Hacer”, “Decir” o “Historia” y escribir el mensaje
oportuno. Con la primera opción nuestro personaje realizará una acción, con la segunda ha-
blará y con la tercera escribiremos la historia como si fuéramos el narrador de la misma. Este
proyecto, además, es muy interesante puesto que para continuar las historias utiliza GPT-3,
una de las librerías más potentes del mercado actual y de la que haremos uso en este proyecto.

Tal como hace AI Dungeon con sus categorías, los videojuegos que incorporan la IA para la
comprensión y generación de texto en narraciones interactivas pueden dividirse en dos tipos:
mundos y escenarios.

Las narrativas que presentan un mundo nos suelen ofrecer una introducción. Explican cómo
funciona el mundo al que nos incorporamos como personaje. Un ejemplo podría ser un mundo
como el que plantea John R. R. Tolkien15 en sus novelas y que el personaje fuera un hobbit
más. El jugador podrá decidir qué decir o hacer en cada momento y la historia se generará
de forma procedural. En AI Dungeon encontramos experiencias jugables de este estilo como
The World of Besatheus16 , donde seremos uno más en un mundo postapocalíptico donde tras
una rebelión de la población se ha dado una guerra eterna y nuestro objetivo será volver a
levantar la gran civilización que un día fue ese mundo.

Por otro lado, las narrativas que plantean un escenario tienen un planteamiento de una
situación mucho más concreta con personajes cerrados. Un ejemplo podría ser una cena con el
jefe de nuestra empresa donde el jugador deberá intentar causar buena impresión con aquello
que dice o hace. En AI Dungeon podemos encontrar The Death Pit 17 , donde seremos un
gladiador que luchará a muerte en el foso y la gente de las gradas nos aclama como a un gran
guerrero, en seguida el locutor dará paso a nuestro oponente.

Además de AI Dungeon, existen otros proyectos interesantes desarrollados mediante GPT-


3. Project Electric Sheep18 es un juego interactivo de simulación de sueños. El jugador debe
indicar qué quiere soñar y cómo se lo imagina visualmente. Los personajes y las conversacio-
nes serán autogeneradas mediante la IA. Esta combinación de diseño creativo e IA convierte
a este proyecto en una oportunidad para mostrar el impacto de la IA en las tecnologías del
futuro. Su lanzamiento estaba proyectado para finales de 2021 pero aún no hay novedades,
14
AI Dungeon. https://play.aidungeon.io/main/home
15
J. R. R. Tolkien, The Hobbit. George Allen & Unwin, 1937. Biografía: https://www.sociedadtolkien.org/
biografia/
16
The World of Besatheus. https://play.aidungeon.io/main/worldStart?worldPublicId=f0d8852a-1073
-4743-a63d-453b0c5af91a
17
The Death Pit. https://play.aidungeon.io/main/scenarioView?publicId=45bb0730-544e-11ec-bf4e
-17f41501f616
18
Project Electric Sheep. https://www.projectelectricsheep.com/
22 Estado de la cuestión

como indican en sus redes sociales el juego continúa en desarrollo. Participaron en el festi-
val de tecnología, cine y música 2022 South by Southwest 19 , donde publicaron un nuevo tráiler.

También se ha incorporado GPT-3 en el desarrollo de juegos de RV como es el caso de


Modbox 20 , un sandbox de juegos multijugador con soporte de SteamVR21 . En este caso, el
jugador podrá hablar mediante voz con los NPC (Non-Playable Character) que encuentre en
mundo virtual y estos les responderán con mensajes de voz autogenerados. Esta unión de RV
y NLG abre un nuevo mundo de posibilidades en el que explorar22 .

Los videojuegos que incorporan una IA de comprensión y generación de texto suelen mos-
trar únicamente texto, por lo que incorporar está tecnología a una novela visual ya supondría
un salto gráfico y sonoro lo que podría atraer a más público. Las posibilidades que ofrecen
estas librerías son infinitas y podemos guiar sus narrativas a cualquier situación; en cambio
las novelas visuales tienen escenas cerradas que únicamente variarán según las decisiones, lo
que puede llegar a ser monótono para el jugador en una segunda partida del videojuego.

5.3. Conclusión
Combinar el género de novela visual con las librerías de IA es un terreno muy interesante a
explorar. Para crear una novela visual necesitamos tener al menos un control mínimo de la si-
tuación por lo que es más interesante en un principio plantear una narrativa de tipo escenario.

El punto fuerte de las novelas visuales son sus giros de guión y la importancia de sus de-
cisiones por lo que combinar la narrativa con la generación procedural de texto nos puede
llevar a situaciones aún más complejas que las planteadas inicialmente por el género. Esta
combinación aportará una mayor jugabilidad y dinamismo a las novelas visuales, además de
la innovación que supone unir estas tecnologías.

En los juegos analizados que incorporan IA de comprensión y generación de texto la intro-


ducción no se hace pesada ya que nos sitúa en la historia desde el momento inicial. En cada
turno vemos las consecuencias de nuestras decisiones por lo que el jugador juega cada turno
de palabra con cuidado e intriga de las consecuencias de lo que puede decir o hacer. Esta
tecnología hace que la experiencia sea siempre rejugable porque hasta en las narrativas de
tipo escenario que muestran situaciones más cerradas las situaciones que se darán serán to-
talmente diferentes en cada partida. En AI Dungeon los jugadores tienen un número máximo
de interacciones por tiempo, pero de no ser así la duración de la partida la marca únicamente
las ganas que tenga el usuario de jugar. Para convertir estas experiencias en más atractivas
habría que incorporar elementos visuales y sonoros para que el jugador se sienta atrapado
con más facilidad y llame más la atención al público general que únicamente un espacio de
19
South By Southwest. https://www.sxsw.com/
20
Modbox. https://www.modboxgame.com/
21
Steam VR. https://www.steamvr.com/es/
22
David Heaney, «This OpenAI GPT-3 Powered Demo Is A Glimpse Of NPCs In The Future», Upload, 19 de
febrero de 2021. https://uploadvr.com/modbox-gpt3-ai-npc-demo/
5.3. Conclusión 23

texto.

Uniendo la esencia de las novelas visuales con las características de los juegos con IA de
comprensión y generación de texto se solventan gran parte de los problemas encontrados en
el género de la novela visual. Como conclusión, podemos afirmar que ambas tecnologías son
complementarias y que uniéndose pueden ofrecer un producto interesante e innovador que
mejora a las tecnologías por separado y con hueco en el mercado de narraciones interactivas
de hoy en día.

Nuestra narrativa, por una parte, aportará ese toque innovador que necesita el género de la
novela visual. El atractivo de los juegos del género reside en su guión y en las posibilidades de
ramificación de la historia. Nuestro título se enfocará de una manera original en este sentido,
pues, además de su narración, mostrará su tecnología como atractivo principal del producto.
Los juegos comentados mantienen una narración completamente estática, en cambio nuestro
proyecto incorporará generación de texto procedural con la IA de NLG. De esta forma, el
título aumenta su rejugalidad ya que cada partida será diferente. Además, evitaremos caer en
los errores más comunes de las novelas visuales al no implementar una introducción de larga
duración y decisiones de poca o nula relevancia. Por otro lado, convertirá las experiencias
textuales con IA ya comentadas en experiencias multimedia al incorporar imagen y sonido.
Esto hará el producto más accesible para el gran público y conseguirá mostrar la tecnología
de NLG como un elemento más atractivo y jugable.
6. Herramientas y tecnologías
En este apartado vamos a analizar las tecnologías necesarias para llevar a cabo el proyecto:
lenguajes de programación, entornos de desarrollo, motores de juegos, librerías...

6.1. Python
Python es un lenguaje de programación de alto nivel que destaca por la legibilidad de su
código y por la multitud de posibilidades que ofrece. Se le conoce como un lenguaje multipa-
radigma ya que llega a soportar orientación a objetos, programación imperativa y, a menor,
escala programación funcional.

Además, Python puede usarse para programación web, desarrollo de interfaces gráficas,
librerías matemáticas, desarrollo de software y muchas más opciones. Actualmente, es el len-
guaje de programación con mayor uso en el ámbito de la IA con librerías para computación
científica, computación avanzada o aprendizaje automático por lo que creemos que es idóneo
para este proyecto.

En este proyecto lo usaremos tanto para el desarrollo de scripts en el motor de juegos


Ren’Py como para la API donde haremos uso de las librerías de IA.

6.2. Visual Studio Code


Visual Studio Code1 es un entorno de desarrollo moderno nos permitirá el resaltado de
sintaxis del código y el autocompletado del mismo. Además, permite compilar y ejecutar el
código directamente desde su propio terminal. Se puede personalizar mediante la descarga
de extensiones que nos permitirán detectar determinado lenguaje de programación y resaltar
su sintaxis, personalizar el aspecto visual del entorno de desarrollo e incluso conectarse con
aplicaciones externas como Git 2 . Para Python existen complementos propios de Microsoft 3
como Pylance4 y para Ren’Py usaremos complementos como Ren’Py Language5 que permi-
tirá detectar la sintaxis y los ficheros de Ren’Py.

1
Visual Studio Code https://code.visualstudio.com/
2
Git. https://github.com/
3
Microsoft. https://www.microsoft.com/es-es
4
Pylance. https://marketplace.visualstudio.com/items?itemName=ms-python.vscode-pylance
5
Ren’Py Language. https://marketplace.visualstudio.com/items?itemName=LuqueDaniel.languague
-renpy

25
26 Herramientas y tecnologías

6.3. Insomnia
Insomnia6 es una aplicación que permite realizar llamadas a una API, funciona de forma
similar a Postman7 . Permite realizar peticiones REST, SOAP, GraphQL y GRPC, así como
automatizar pruebas. En nuestro proyecto hemos usado Insomnia para hacer pruebas sobre
nuestra API de forma que hemos podido comprobar la entrada y salida de datos sin tener
que realizar las llamadas forzosamente desde el script de Ren’Py.

6.4. Ren’Py
Ren’Py es un motor de juego para novelas visuales que incluye muchas opciones para el
desarrollo de las mismas como ramificar historias, sistema de guardado y cargado de partida,
transiciones de imagen y sonido, opciones para volver atrás en la historia, etc. El punto que
hace este motor muy interesante para el proyecto es que admite código Python con el que
podremos desarrollar scripts para poder llevar aún más allá las novelas que desarrollemos.
En esta librería se han desarrollado obras que han sido un éxito como Doki Doki Literature
Club!, juego que he mencionado recurrentemente a lo largo de la memoria. Al ser el motor
de juego que más difusión tiene entre las novelas visuales es el que hemos seleccionado para
el desarrollo de este proyecto.

6.5. GPT-3 y GPT-2


GPT-3 es el último modelo de lenguaje de OpenAI 8 . El objetivo de esta herramienta es
predecir una respuesta coherente a un texto dado, para ello se ha implementado mediante
machine learning que comprenda la semántica de las palabras. Ofrece una cantidad inmensa
de posibilidades como autogenerar chats, responder preguntas, corregir errores de gramática,
traducir, generar código en un lenguaje determinado a partir de un enunciado, solucionar
errores de programación, crear reviews de productos, convertir código de JavaScript 9 a Pyt-
hon, redactar noticias o artículos de opinión que podrían parecer escritos por humanos...10

Para generar estas respuestas OpenAI ha entrenado a GPT-3 con todos libros publicados,
millones de páginas web y documentos científicos lo que hace que tenga conocimiento para
responder en cualquier situación que planteemos.

6
Insomnia. https://insomnia.rest/
7
Postman. https://www.postman.com/
8
OpenAI. https://openai.com/
9
JavaScript. https://www.javascript.com/
10
Alex Walker, «What Happens When AI Tries To Review A Video Game», Kotaku, 22 de octubre de 2021.
https://kotaku.com/what-happens-when-ai-tries-to-review-a-video-game-1847917110
6.6. Flask 27

Esta última versión se encuentra en fase beta y para poder usarla necesitaremos una clave
(API Key) que tendremos que obtener desde la página oficial de OpenAI. Actualmente, pode-
mos registrarnos en la web sin problema y obtener la clave, aunque nuestra prueba gratuita
tendrá una fecha de caducidad y un número máximo de usos que se traducen como créditos
monetarios. Hasta el 9 de diciembre de 2021 para poder acceder necesitábamos realizar un
cuestionario mostrando nuestro interés y esperar a que OpenAI decidiera compartir una API
Key con nosotros. En nuestro caso, se nos llegó a conceder acceso a la beta. Debido al uso
limitado de GPT-3, aunque implementaremos también esta tecnología en nuestro proyecto,
hemos decidido hacer uso de la versión anterior GPT-2, la cual es una versión completa y
gratuita.

A diferencia de GPT-3, GPT-2 únicamente ha sido creado con el objetivo de predecir las
siguientes palabras de una oración, lo que nos servirá para completar las conversaciones de
nuestra novela visual. La comprensión y generación de texto que ofrece tiene algunas limi-
taciones puesto que puede llegar a generar texto repetitivo, falta de comprensión en algunos
temas excesivamente técnicos o no incorporarse al contexto o jerga de una conversación. Ade-
más tras haber probado ambas librerías dentro del juego, podemos afirmar que las respuestas
que ofrece GPT-3 se sienten mucho más coherentes

Estas tecnologías aunque ofrecen una gran cantidad de posibilidades aún están en una fase
inicial por lo que aún es pronto para llegar a ver su verdadero potencial.

6.6. Flask
Flask 11 es un framework escrito en Python que nos permitirá crear aplicaciones web fácil-
mente. Haremos uso de él en el proyecto para generar la API a la que llamaremos desde el
scripting de Ren’Py. Esta API será necesaria para nuestro proyecto ya que Ren’Py no permite
el uso directo de librerías a las que no da soporte pero sí permite importar módulos y pa-
quetes de Python puro por lo que, como alternativa, desarrollaremos esta API y realizaremos
peticiones GET en el script mediante la librería requests. Enviaremos un texto de entrada y
nuestra API mediante las librerías de comprensión y generación de texto devolverá el texto
autogenerado que usaremos como respuesta en el juego.

11
Flask. https://flask.palletsprojects.com/en/2.0.x/
28 Herramientas y tecnologías

6.7. MarIA
MarIA12 es un modelo de lenguaje basado en transformadores que a diferencia de las
anteriores está preparado para desenvolverse en español. MarIA tiene versiones desarrolladas
basándose en los modelos de lenguaje RoBERTa13 y GPT-2. Ha sido entrenada con más de 200
millones de documentos suponiendo 570GB de texto después de eliminar las duplicaciones.
Será útil para nuestro proyecto el uso de la versión de GPT-2 si decidimos desarrollar la
opción de jugar en castellano.

6.8. GitHub
GitHub es una plataforma que nos permite alojar el código fuente de nuestro proyecto tanto
de forma pública como privada y mantener un control de versiones. Este portal tiene sistemas
para la colaboración entre desarolladores y un sistema de perfiles con la que podremos ver
los repositorios públicos de otros usuarios. Su principal uso se centra en la creación de código
pero, en realidad, nos permite subir cualquier tipo de fichero. En la Sección 1 hemos indicado
la URL en la que está alojada tanto nuestro proyecto de Ren’Py como las distribuciones para
los distintos sistemas.

12
Asier Gutiérrez-Fandiño et al., Spanish Language Models. 2021. https://arxiv.org/abs/2107.07253v2

Otros enlaces de interés:


https://github.com/PlanTL-GOB-ES/lm-spanish
https://huggingface.co/PlanTL-GOB-ES/gpt2-base-bne
https://huggingface.co/PlanTL-GOB-ES/gpt2-large-bne
https://huggingface.co/PlanTL-GOB-ES/roberta-large-bne

13
RoBERTa. https://huggingface.co/PlanTL-GOB-ES/roberta-large-bne
7. Arquitectura del sistema
A modo de introducción, vamos a analizar los componentes que forman nuestro flujo de
información y que posteriormente detallaremos.

Figura 7.1: Esquema de componentes.

El usuario ejecutará el cliente que usará el motor de juego Ren’Py. Desde nuestro script
realizaremos consultas al servidor para recibir las respuestas de la IA a las preguntas del
interrogatorio del juego.

En el servidor hemos conectado las librerías necesarias para usar GPT-2 y GPT-3 tanto en
castellano como en inglés. El servidor deberá estar levantado esperando a que nuestro cliente
le realice consultas. Una vez completado este proceso, empezará la parte jugable.

El sistema de nuestro videojuego está compuesto de una estructura cliente-servidor, siendo


el cliente el motor de Ren’Py y el servidor una API donde realizaremos las peticiones a las
librerías de NLG. A continuación vamos a explicar el uso y funcionamiento de estas partes.

29
30 Arquitectura del sistema

7.1. Cliente

El cliente ejecutará el motor de Ren’Py que es lo que nos permitirá jugar. Las líneas
generales de nuestro videojuego están incluidas en game/script.rpy. En este fichero, además
del guión de la historia, es donde hemos integrado mediante Python las librerías que nos
permitirán realizar peticiones al servidor.

Figura 7.2: Ficheros del sistema de juego.

Cuando arranquemos el cliente pasaremos a un menú de selección de idioma y de modelo de


lenguaje con el que podremos configurar el sistema de IA del que hará uso el juego. Después,
pasaremos a una pantalla de carga. En este momento desde el cliente lanzaremos 12 peticiones
al servidor: enviaremos todas las posibles preguntas que se podrán hacer en el interrogatorio
y el servidor nos devolverá la respuesta de cada una. Esta carga puede tardar más o menos
dependiendo de las opciones de juego que escojamos. Una vez se complete la carga ya no
habrá más durante el resto de la partida. Para enriquecer las respuestas de la IA el texto
que enviaremos tendrá en cuenta toda la conversación previa en el caso de GPT-3 y de las 3
preguntas anteriores en caso de GPT-2 ya que este segundo sistema tiene un tope máximo de
caracteres de entrada. Además, indicaremos la situación de las preguntas (un interrogatorio
policial) para darle contexto.

El usuario a partir de aquí podrá empezar a jugar. El detective tendrá que interrogar a los 3
sospechosos, de los cuales uno que se elegirá de forma aleatoria responderá con las respuestas
que ha generado la IA y los otros dos con respuestas escritas por el desarrollador.
7.2. Servidor 31

Figura 7.3: Pantalla de carga.

7.2. Servidor
Para poder jugar necesitaremos tener el servidor levantado para que espere las llamadas
que realizaremos desde el cliente. Para ello necesitaremos tener instaladas algunas librerías,
así que en primer lugar abrimos un terminal CMD y ejecutamos los siguientes comandos:

pip install torch


pip install transformers
pip install openai
pip install flask

Una vez instaladas las librerías nos dirigiremos a la carpeta del juego, donde se encuentra
en fichero server.py, y ejecutar el comando python3 server.py Al ejecutar el comando veremos
un mensaje como el de la siguiente imagen, que quiere decir que el servidor ya está levantado.
Deberemos mantener el terminal abierto con el servidor corriendo durante toda nuestra sesión
de juego.

El servidor admite dos tipos de llamadas GET, una para las llamadas a GPT-2 y otra para
las de GPT-3. En estas llamadas indicaremos dos cadenas de texto: la versión que queremos
usar y la secuencia de texto entrante. Para GPT-2 las versiones podrán ser las de MarIA
(castellano) o la inicial de OpenAI (inglés), en cambio para GPT-3 con versión indicaremos
únicamente el idioma de la consulta (castellano o inglés).
32 Arquitectura del sistema

Figura 7.4: CMD con servidor levantado.

1 @app.route('/gpt2/<string:version>/<string:sequence>')
2 def getSentenceGPT2(version, sequence): ...
3
4 @app.route('/gpt3/<string:version>/<string:sequence>')
5 def getSentenceGPT3(version, sequence): ...
6
7 if __name__ == '__main__':
8 app.run(debug=False, port=4000)

El funcionamiento de estas funciones será recibir la secuencia de texto de la conversación


que queremos autocompletar. Por ejemplo, esta podría tener la siguiente estructura:

Detective: ¿Qué estuviste haciendo anoche?


Sospechoso: Me fui a pasar la tarde a casa de un amigo.
Detective: ¿Por qué estabas por el vecindario en el momento del asesinato?
Sospechoso:

La IA nos devolverá el texto que responderá el sospechoso que, por ejemplo, podría ser
“Tengo que cruzar el vecindario para llegar a mi casa”.
7.3. Esquema de funcionamiento 33

7.3. Esquema de funcionamiento


Una vez explicado el funcionamiento del cliente y el servidor de nuestro software vamos a
indicar mediante un esquema todos los procesos para que pueda verse visualmente.

En primer lugar, por la parte del cliente seleccionamos el idioma y el modelo de lenguaje
que vamos a utilizar y por la parte del servidor únicamente lo levantamos y esperamos a que
lleguen las llamadas desde cliente.

Cuando el cliente haya seleccionado idioma y modelo realizará 12 llamadas (una por pre-
gunta que podemos hacer a cada sospechoso) al servidor y este nos devolverá las respuestas,
las cuales asignaremos automáticamente a un sospechoso.

A partir de aquí pasamos al curso de juego donde el jugador que interpreta el papel de un
detective podrá interrogar a los sospechosos mediante 12 preguntas preestablecidas divididas
en 4 temáticas. Cuando haya preguntado a los 3 tendrá que responder a cuál es el asesino.
El asesino será el que cuyas respuestas sean las que ha generado la IA y los inocentes las que
ha escrito el desarrollador.

En caso de elegir correctamente al asesino el jugador habrá ganado y en caso contrario


habrá perdido.
34 Arquitectura del sistema

Figura 7.5: Esquema de funcionamiento.


8. Narrativa
El protagonista y jugador de la historia es un detective que tiene que resolver un crimen.
Un androide ha cortocircuitado y se ha escapado de la casa donde realizaba tareas de limpie-
za, no sin antes acabar con la vida de su dueño, un señor mayor.

La policía ha detenido a todos los sospechosos que concurrieron por la zona la noche del
crimen. Detectar cuál de ellos es un humano y cuál es un androide es más difícil de lo que
pensaban por lo que nuestro protagonista debe interrogar a todos ellos y llegar a una conclu-
sión. En caso de equivocarse puede que el androide se cobre más víctimas.

La diferencia entre humanos y androides es que los primeros tenemos capacidad de ra-
ciocinio, coherencia e intención (como hemos detallado en la Sección 4) y, en cambio, los
segundos únicamente siguen patrones definidos. Su forma de actuar viene programada por
una IA, por eso la tecnología de NLG juega un papel imprescindible en esta narrativa y,
además, es la que la convierte en una experiencia jugable. Las respuestas al interrogatorio
que nos ofrecerá el androide serán generadas mediante GPT-3 (o GPT-2, según seleccione el
usuario) y, por lo tanto, serán respuestas generadas por una IA real. La gracia del gameplay
reside en adivinar si las respuestas de los sospechosos han sido escritas por un humano o por
la IA, por lo que el jugador deberá buscar inconsistencias en las respuestas para poder decidir.

La mecánica de analizar si las respuestas están escritas por humanos o generadas por siste-
mas inteligentes es similar al funcionamiento del Test de Turing1 . Este experimento consiste
en evaluar la capacidad de las máquinas para generar lenguaje humano en forma textual.
Para llevar a cabo la prueba, un participante debe analizar conversaciones entre humanos y
máquinas e identificar cual de los interlocutores es la IA. En el caso de que el participante no
puediera distinguir la humanidad de los hablantes, la máquina habría superado la prueba.

Esta narrativa tiene su mayor fuente de inspiración en la película Blade Runner 2 (1982) y
en el videojuego Detroit: Become Human3 del estudio Quantic Dream4 . Esta segunda inspira-
ción no sólo recae en la parte narrativa sino que también es parte de la inspiración conceptual
de este TFG pues es una de las historias interactivas que me hicieron interesarme de forma
más profunda por este estilo de videojuegos. La narrativa de este videojuego se basa en una
revolución de los androides con forma humanoide que los humanos de esta realidad utilizan
para las tareas del día a día como limpiar la casa o incluso acompañar a los niños al colegio.
Estos androides comienzan a desarrollar sentimientos y comienzan a producirse muchos casos
1
Test de Turing. https://es.wikipedia.org/wiki/Prueba_de_Turing
2
Ridley Scott, Blade Runner, (25 de junio de 1982). Información: https://www.filmaffinity.com/es/
film358476.html
3
Detroit: Become Human. https://store.steampowered.com/agecheck/app/1222140/
4
Quantic Dream. https://quanticdream.com/en

35
36 Narrativa

en los que estos se revelan y empiezan a desobedecer a los humanos. Con el paso del tiempo
la cosa no queda en casos aislados y los androides empiezan a organizarse para acabar con el
sometimiento que los humanos hacen sobre ellos.

Por otro lado, cabe destacar la parte jugable de Detroit: Become Human. La historia avan-
za según las decisiones que toma el jugador tanto en el diálogo con los personajes como en
la exploración por los escenarios. Al lado de las novelas visuales este título es una superpro-
ducción, pero aún así el foco de ambos está puesto en la interactividad con el jugador, que
es la que decide como continúa la historia. En la Sección 5 nos adentramos en la perspectiva
del género y la innovación de su autor, David Cage, en el conjunto de su obra. El objetivo de
este peculiar desarrollador siempre ha sido innovar e ir más allá de los estándares del medio.
El objetivo de nuestro proyecto también coincide, en parte, con esa premisa.

En la Sección A.1 profundizaremos en el guión de la narración interactiva desarrollada.


Detallaremos el argumento, presentaremos a los personajes, escribiremos todas las líneas de
diálogo teniendo en cuenta las ramificaciones de la historia y justificaremos narrativamente
la elección de las imágenes y sonidos que componen la novela visual.
9. Evaluación
Con el objetivo de poder evaluar nuestro desarrollo, se han implementado diferentes ver-
siones del videojuego.

En primer lugar, vamos a autoevaluar la primera versión del videojuego con el objetivo de
explicar los detalles del estado del juego que se está evaluando.

9.1. Autoevaluación de la primera versión

Figura 9.1: Primeras escenas.

37
38 Evaluación

Al iniciar el juego seleccionaremos el idioma y la IA con la que queremos jugar, marcándose


como recomendado jugar con la configuración inglés y GPT-3. Justo después, se realizan las
llamadas al servidor para obtener las respuestas generadas por la IA y se mostrará una
pantalla de carga durante el proceso que puede llevar desde los 20 segundos hasta los 60
dependiendo de la configuración seleccionada. Durante estas escenas está sonando una música
ambiental de sueños y cuando acabe la carga de información sonará el teléfono y comenzará
el juego.

Figura 9.2: Conversación inicial.

La persona que nos llama es el jefe del centro de policía y nos pide que le ayudemos a
identificar al androide que ha asesinado a su dueño y ha huido del hogar entre un grupo de
sospechosos.

Tras una escena de transición en el tranvía donde escucharemos el sonido de las paradas,
pasamos a la oficina del centro de policías, donde nos presentarán a los 3 sospechosos. Los
sospechosos irán pasando de uno en uno y les podremos hacer las mismas preguntas a cada
uno.
9.1. Autoevaluación de la primera versión 39

Figura 9.3: Presentación de sospechosos.

Las opciones de pregunta son las siguientes:

• ¿Qué estuviste haciendo anoche?

• ¿Por qué estabas por el vecindario en el momento del asesinato?

• ¿Conocías al vecino asesinado?

• Suficientes preguntas. Pasemos al siguiente sospechoso.

La cuarta opción nos permite pasar al siguiente sospechoso. Omitiremos esas viñetas en
esta autoevaluación y pasaremos a la elección del asesino por parte del detective.
La primera imagen de esta figura es un ejemplo de respuesta a la pregunta ‘¿Qué estuviste
haciendo anoche?’. Después de preguntar a todos los sospechosos el jefe de policía nos pregun-
tará nuestro veredicto acerca de cuál de los tres es el androide. Una vez tomemos la decisión
podremos volver a casa. Tras pasar de nuevo por una escena de transición en el tranvía,
habremos llegado a casa y el jugador estará durmiendo (música ambiental de sueños) hasta
que una llamada nos vuelva a despertar y comience la escena final.
40 Evaluación

Figura 9.4: Elección final.

Dependiendo de si el detective acierta identificando al asesino tendremos un final u otro.


En caso de acertar, como se muestra en la primera fila de imágenes, el jefe de policías nos
dirá que no han habido más asesinatos y que la elección del asesino ha sido exitosa. En caso
contrario, nos dirá que continúan habiendo asesinatos en el vecindario y que el sospechoso
que escogimos no era el androide.

Esta primera versión parte muy avanzada ya que ya contiene elementos gráficos y sonoros
que se mantendrán en la versión final. Además, la elección inicial de idioma e IA sirve para
que los jugadores no angloparlantes puedan disfrutar del juego y que los más curiosos prueben
con las diferentes IA para probar la diferencia entre su dificultad. GPT-3 ofrece resultados
bastante precisos aunque no asegura que las respuestas sean adecuadas en el 100% de los
casos, tal como explicamos en el ‘Marco teórico’.

Como desarrollador, los puntos que he detectado como mejorables residen en la escasa
cantidad de preguntas disponibles y en la repetición de las respuestas estáticas tras jugar un
número alto de partidas. A continuación, analizaremos las opiniones vertidas por el resto de
usuarios a los que se le ha permitido probar el juego.
9.2. Opiniones y sugerencias de los usuarios tras probar la primera versión 41

Figura 9.5: Desenlace del juego.

9.2. Opiniones y sugerencias de los usuarios tras probar la primera


versión
Esta primera versión ha sido probada por familiares, amigos y los tutores del presente
proyecto. En este apartado vamos a resumir los consensos que ha recibido el juego y las su-
gerencias que han propuesto todos ellos como mejora para la versión final.

Todos ellos coinciden en que la dificultad parece adecuada (la mayoría de ellos no ganan
en su primera partida) y que el juego es disfrutable. Las sugerencias vamos a clasificarlas en
tres apartados: visual, sonoro y técnico.

Respecto al apartado visual, las opiniones han sido masivamente positivas. Antes de ter-
minar de desarrollar la primera versión se sugirió la idea de ampliar el contexto del juego
incluyendo un mapa/escenario donde presentar a los sospechosos. Actualmente, se ha incluido
ya una escena donde se hace fade-in de los 3 sospechosos antes de comenzar a interrogarlos,
tal como se muestra en la tercera imagen de la Figura 9.3. Por lo tanto, dejamos como zanjada
esta cuestión.

Respecto al apartado sonoro, las opiniones han sido positivas. La música ambiental inicial
que acompaña la pantalla de carga ha recibido buenas críticas ya que se comenta que hace
amena la espera. Las únicas sugerencias para mejorar en el apartado sonoro residen en relle-
nar los apartados que actualmente están faltos de sonido como la pantalla final de victoria o
derrota. Se tendrá en cuenta está última consideración en la versión final para que el audio
acompañe correctamente a la imagen y a la situación del juego.
42 Evaluación

Respecto al apartado técnico se han recibido sugerencias muy variadas. A continuación


vamos a valorar el encaje en el producto final de cada una de ellas.

En primer lugar, se ha comentado la posibilidad de que el usuario introduzca sus propias


preguntas. Esta idea aunque es cierto que sería potente y gratificante para el jugador ha
tenido que rechazarse ya que introducir preguntas no permitiría tener disponible el conjunto
de respuestas estático.

En segundo lugar, se ha pedido crear una guía de uso e instalación para el juego ya que
varios jugadores no han instalado correctamente las librerías necesarias para poder levantar
el servidor y jugar al juego. Se ha añadido a la carpeta del juego una guía de uso donde se
explica paso a paso cómo levantar el servidor, cómo ejecutar el cliente y qué hacer en caso
de ocurra un error durante la carga del juego.

En tercer lugar, se ha aportado como idea introducir preguntas temáticas para ampliar
las 3 que hay disponibles actualmente. Esta idea consistiría que cuando tengamos delante al
sospechoso podamos seleccionar por temas del estilo ‘Preguntar acerca del asesino’, ‘Pregun-
tar acerca del día anterior’ o ‘Preguntar acerca de su familia”. Dentro de cada una de estas
secciones habría diferentes preguntas para seleccionar. Esta idea es interesante y se imple-
mentará en la próxima versión del juego, aunque habrá que tener en cuenta que ampliar el
número de preguntas supondrá realizar un mayor número de consultas a GPT y reducirá la
dificultad del juego ya que habrá un mayor número de posibilidades de identificar al robot.
Todo esto se tendrá en cuenta en el desarrollo para que el producto final esté bien balanceado.

En base al análisis expuesto en la autoevaluación y en las sugerencias de este apartado, se


ha desarrollado la versión final que incluye un mayor banco de respuestas estáticas para los
sospechosos inocentes, de forma que las respuestas prefijadas no se repitan fácilmente tras
jugar un par de partidas, y un mayor número de preguntas disponibles clasificadas por temas.

9.3. Segunda versión desarrollada


Tras el desarrollo de la primera versión del juego y su evaluación, se añaden novedades
jugables que mejoran la experiencia de juego.

Se han añadido preguntas temáticas en lugar de las 3 preguntas con las que se contaba
anteriormente. Ahora cuando el procedamos a interrogar a un sospechoso nos encontraremos
con 4 opciones.

• Preguntar acerca del vecino


• Preguntar acerca de la noche
• Preguntar acerca del vecindario
• Preguntar acerca del sospechoso
9.3. Segunda versión desarrollada 43

Figura 9.6: Temáticas de pregunta.

Dentro de cada una de estas opciones nos encontraremos con 3 preguntas diferentes. De
forma que la versión actual del juego cuenta con hasta 12 preguntas para cada sospechoso,
a diferencia de las 3 que teníamos anteriormente. El resultado ofrecido con este cambio ha
sido mejor de lo esperado pues, en contra de lo que se pensaba, la dificultad ha aumentado
respecto a la versión anterior. Al tener un mayor número de preguntas GPT-3 también tiene
un mayor contexto por lo que las respuestas que ofrece son más precisas. El tiempo de carga
ha aumentado pero la espera para jugar con la configuración recomendada (GPT-3 en inglés)
se mantiene al rededor de un minuto.

Por otro lado, también se ha aumentado el número de respuestas humanas predefinidas


para los sospechosos inocentes. En esta versión costará más encontrar respuestas repetidas
respecto a las partidas anteriores. El juego cuenta con 5 paquetes de respuestas humanas
para cada una de las temáticas. Aleatoriamente se asociará a los sospechosos un paquete
de respuestas humanas para cada tema. De esta forma un inocente puede contar con, por
ejemplo, el paquete 3 para la temática 1, el paquete 5 para la temática, etc. Esto aportará
mayor rejugabilidad al juego.

Por último, cabe destacar que se ha añadido en la pantalla final nuevos sonidos. Cuando
el jugador gane se escuchará un sonido de victoria y, en cambio, cuando pierda se escuchará
un sonido de derrota. Esto dará al jugador un mayor feedback al final de la partida, más allá
de los actuales mensajes de ”You win!” y ”You lose...”.
44 Evaluación

Figura 9.7: Preguntas de cada temática.

9.4. Formulario de evaluación de la segunda versión


Para evaluar esta segunda versión se ha creado un formulario que está disponible en la
siguiente URL: https://forms.gle/gMVCp2wfTv1Xh25NA

El juego se ha ofrecido a probar a diferentes usuarios, con mayor y menor contacto con el
mundo de los videojuegos, y se ha compartido el formulario. Para poder realizarlo únicamente
se pide que, al menos, se haya jugado una partida completa.

Figura 9.8: Introducción formulario.

El formulario consta de 8 preguntas, 3 de ellas opcionales.

En primer lugar, se pregunta cuantas partidas se han jugado antes de realizar el cuestio-
nario. Con esta pregunta se pretende valorar también la rejugabilidad del juego. Se espera
que se jueguen al menos dos partidas ya que la duración de estas es corta.
9.4. Formulario de evaluación de la segunda versión 45

Figura 9.9: Primera pregunta del formulario.

En segundo lugar, se pregunta que, en caso de haber jugado más de una partida, cuántas
se han jugado hasta conseguir ganar una. Esta pregunta es opcional ya que puede ser que
un jugador sólo haya jugado una única partida. La intención de esta pregunta es valorar
la dificultad del título y si esta está construida de forma que incite a volver a jugar hasta
conseguir identificar al asesino.

Figura 9.10: Segunda pregunta del formulario.

A partir de aquí nos encontramos con preguntas que deberán responderse con una pun-
tuación de 1 a 5. Se pide valorar la dificultad, gráficos y sonidos de forma que podamos
cuantificar la calidad del título en estos aspectos concretos.
46 Evaluación

Figura 9.11: Preguntas sobre dificultad, gráficos y sonidos.

Posteriormente a las calificaciones de dificultad, gráficos y sonido, se pide al jugador que


copie y pegue el contenido del fichero test.txt. En este fichero tendremos un código por cada
partida que jugada. Por ejemplo, el contenido del fichero podría ser el siguiente:

3:W:7;3;4
1:L:8;1;6

Este código se genera a partir de los siguientes datos: [Número del asesino (1, 2, 3)] : [W
en caso de victoria y L en caso de derrota] : [Número de preguntas realizadas al primer sos-
pechoso] ; [Número de preguntas realizadas al segundo sospechoso] ; [Número de preguntas
realizadas al tercer sospechoso]

Con estos resultados podemos ver cuantas preguntas ha necesitado el jugador para descar-
tar que un sospechoso fuera el androide. Además, esta forma de medición se podría utilizar
para evaluar diferentes sistema de IA. Esta cuestión volveremos a mencionar en la Sección
10.3 Trabajo futuro.
9.4. Formulario de evaluación de la segunda versión 47

Figura 9.12: Petición del contenido generado en test.txt.

Por último, encontramos dos preguntas opcionales donde el usuario podrá sugerir ideas
para mejorar el juego o comentar si ha encontrado algún error en las partidas para que
podamos subsanarlo antes de la la versión final.

Figura 9.13: Apartado de errores y sugerencias.


48 Evaluación

9.5. Resultados de la evaluación de la segunda versión

En este apartado vamos a analizar los resultados obtenidos en el formulario de la segunda


versión del juego y a partir de ellos se desarrollará la versión final.

Figura 9.14: Número de partidas jugadas.

Como podemos ver en el gráfico de la Figura 9.14, los jugadores que únicamente han juda-
do una partida son minoría. Este resultado es bastante satisfactorio ya que uno de nuestros
intereses es que el juego fuera rejugable.

Figura 9.15: Número de partidas jugadas hasta conseguir ganar.

En la Figura 9.15 podemos ver que todos los jugadores juegan hasta ganar alguna partida
y que estos lo hacen principalmente entre la primera y la segunda partida.
9.5. Resultados de la evaluación de la segunda versión 49

Figura 9.16: Grado de dificultad.

En la figura 9.16, vemos como los jugadores sitúan la dificultad del juego en torno a una
valoración media. Nadie considera el juego ni excesivamente fácil ni excesivamente difícil.
Con estos datos, junto a los obtenidos en la Figura 9.15, podemos llegar a la conclusión de
que la dificultad es adecuada para el juego desarrollado.

Figura 9.17: Valoración de gráficos.

En las Figuras 9.17 y 9.18 hemos obtenido unas valoraciones muy positivas. En el caso
de los gráficos la valoración obtenida es perfecta. Con estos datos podemos concluir que la
elección del apartado artística ha sido muy acertada tanto a nivel gráfico como sonoro. Los
cambios que se implementarán en la versión final recaerán en el apartado técnico.
50 Evaluación

Figura 9.18: Valoración de sonidos.

Figura 9.19: Contenido del fichero test.txt.

En la Figura 9.19 tenemos el contenido de los ficheros test.txt. En ellos podemos ver que
los jugadores suelen realizar la mayoría de las preguntas ganen o pierdan. También, podemos
observar que conforme el jugador va realizando partidas realiza menos preguntas a los sospe-
chosos.

En la Figura 9.20 tenemos los mensajes que han escrito los usuarios respecto a los errores
que han encontrado jugando. Todos los errores que se comentan van relacionados con las
respuestas autogeneradas por la IA. Este punto tiene un componente aleatorio, como hemos
desarrollado en la Sección 7, pero hay que destacar que la versión del juego en inglés y, por
ende, de la IA de OpenAI se desenvuelve mucho mejor en inglés. Debido a esto y a un menor
tiempo de carga se recomendará a los jugadores la versión en inglés con GPT-3.
9.5. Resultados de la evaluación de la segunda versión 51

Figura 9.20: Errores.

En la Figura 9.21 encontramos las sugerencias que nos han hecho los usuarios para mejorar
el juego. Entre ellas encontramos algunas muy interesantes y que serán implementadas en
la versión final. Entre las respuestas encontramos sugerencias tan variadas como opciones de
repetir el interrogatorio de un sospechoso, incorporar mayor número de sospechosos, mejorar
las respuesta autogeneradas o mostrar quien era el asesino cuando se pierde.

Figura 9.21: Sugerencias.


52 Evaluación

9.6. Versión final


El proceso de evaluación del juego ha ayudado a encontrar mejorar para el título. Desde la
primera versión a esta versión final han habido modificaciones en todos los aspectos del juego.

A partir de las sugerencias del formulario anterior se ha implementado dos novedades


jugables. En esta versión podremos volver al sospechoso anterior para volver a realizar las
preguntas. De esta forma, si el jugador no tiene la certeza de quién es el asesino podría repetir
la conversación e intentar salir de dudas. Una vez terminemos con el tercer sospechoso ya no
habrá vuelta a atrás y decidiremos quién creemos que es el asesino.

Figura 9.22: Opción de vuelta a atrás.

Por otro lado, también se ha implementado que al final del juego se muestre quién era el
asesino junto al mensaje de ”You win!” o ”You lose”. En caso de ganar, el asesino aparecerá
con una expresión triste pero si perdemos aparecerá feliz. Con esta novedad el jugador ade-
más de la información sobre que ha perdido o ganado recibe un feedback visual que hay que
añadir al sonoro que se implementó en la segunda versión.

Por último, cabe comentar otros cambios que también son novedad en esta versión final.
En primer lugar, se ha dado nombre a los sospechosos: Anna, Daniel y Emma. Esta novedad
consigue convertir la decisión de elegir culpable en algo más personal. Por otro lado, se ha
añadido una sección posterior al mensaje de victoria o derrota con los créditos. En esta sección
se menciona mi autoría y el uso de material de terceros, el cual ya estaba mencionado en la
Sección A.2 y en ficheros TXT dentro de la carpeta del juego.
9.6. Versión final 53

Figura 9.23: Pantalla de victoria.

Figura 9.24: Pantalla de derrota.


10. Conclusiones
Para concluir el proyecto es necesario repasar los objetivos que nos habíamos propuesto en
la Sección 2 y demostrar el grado de cumplimiento de cada uno de ellos. Así como analizar
los pasos dados en cada una de las etapas de desarrollo marcadas en la Sección 3.

10.1. Análisis del cumplimiento de los objetivos planteados


El O1 trataba de estudiar GPT-2 y GPT-3, librerías de IA para NLG. Este objetivo se
llevó a cabo en las dos primeras etapas de desarrollo. La primera etapa consistió en estudiar
el lenguaje de programación Python, el motor de juego Ren’Py y las librerías mencionadas.
La segunda etapa consistía en unir estas librerías con el motor de Ren’Py mediante scripts
de Python.

En primer lugar, se realizó un estudio de Python. Esto no supuso un gran problema ya


que se contaba con experiencia previa en otros lenguajes como pueden ser C++ o Java y en
programación web.

Posteriormente, para estudiar Ren’Py se realizaron los tutoriales, probamos el juego The
Question que viene con el propio launcher del motor y se desarrolló un primer juego sin IA
que sólo constaba de algunas líneas de diálogo.

Para el estudio de las librerías se empezó a investigar toda la documentación alojada en


la web de OpenAI y paralelamente se comenzó a buscar la forma de conectar Ren’Py y estas
librerías. La web ofrece algunos tutoriales y ejemplos y ofrece información de cómo dar los
primeros pasos para construir una aplicación con su tecnología.

Como Ren’Py no permite la conectividad directa de OpenAI en sus scripts pero sí la de


todas las librerías básicas como requests implementamos un servidor con Python. De esta
manera la forma de obtener en Ren’Py el texto autogenerado de GPT pasa por realizar pe-
ticiones al servidor enviando como parámetro el texto de entrada. Para probar el correcto
funcionamiento del servidor envíe peticiones desde el propio navegador y desde el software
Insomnia.

Una vez, habíamos dado estos primeros pasos y teníamos claro cómo conectar Ren’Py con
GPT, desarrollamos un pequeño chatbot en Ren’Py donde el usuario escribía preguntas y la
IA respondía.

55
56 Conclusiones

Figura 10.1: Ren’Py Launcher.

Figura 10.2: Prueba inicial de desarrollo en Ren’Py.


10.1. Análisis del cumplimiento de los objetivos planteados 57

Figura 10.3: Tutoriales de OpenAI.

Esta mecánica de introducir texto se descartó para la versión final del juego ya que si el
usuario introducía texto no podíamos tener preparadas las respuestas hardcode. De cualquier
forma, una vez desarrollado este chatbot damos por cumplido el O1 y las dos primeras etapas
de desarrollo.

Los objetivos O2 y O3 trataban de profundizar en el género de la novela visual y en el


uso de la IA de NLG en el ámbito de los videojuegos. Para ello, he redactado el apartado
‘Estado de la cuestión’ (Sección 5) donde analizo videojuegos ubicados en este género y las
posibilidades y usos que se le han dado a la IA de NLG y he llegado a la conclusión de que
ambas cuestiones son totalmente compatibles.
58 Conclusiones

Figura 10.4: Llamada a servidor desde navegador.

Figura 10.5: Llamada a servidor desde Insomnia.

Para explorar el género he probado títulos de gran éxito en España como Doki Doki Lite-
rature Club! o Danganronpa: Trigger Happy Havoc. Además, he analizado los motores más
populares para el desarrollo de este género de videojuegos. En el apartado ‘Marco teórico’
(Sección 4) se profundiza en la dicotomía entre el contenido procedural y estático y se ponen
ejemplos de distintos usos que se le han dado a la generación procedural en videojuegos como
creación de escenarios, bandas sonoras o, en nuestro caso, texto.

El O4 trataba de desarrollar una narración interactiva que vaya más allá de los videojuegos
tradicionales del género novela visual e incorpore elementos de IA que permitan un mayor
dinamismo a su historia. Este objetivo coincide con las etapas de desarrollo 3 y 4 que tratan
de plantear una historia donde el uso de la IA de NLG aporte a la jugabilidad y desarrollarla
a través de Ren’Py añadiendo los elementos sonoros y gráficos pertinentes. La idea sobre la
que se construye la narrativa es la mecánica “identificar al bot”. De esta forma, se plantea
el contexto expuesto en el apartado ‘Narrativa’ (Sección 8) donde el jugador es un detective
que deberá averiguar cuál de los sospechosos es un androide que ha escapado de su hogar tras
asesinar a su dueño. El eje del juego gira en torno a la dicotomía entre el contenido generado
proceduralmente y el estático, anteriormente mencionado. En este contexto, las respuestas
que nos dará el robot en el interrogatorio serán procedurales y generadas con la librería GPT
y, en cambio, las respuestas del resto de personajes serán estáticas y aleatorias dentro de un
conjunto de respuestas prefijadas.

El O5 y la cuarta etapa de desarrollo se centran en la evaluación del proyecto. Tras reali-


zar la primera versión jugable, se ha dado a probar a diferentes usuarios con el objetivo de
encontrar nuevas ideas y poder mejorar el videojuego final. Toda la evaluación está recogida
en la Sección 9, donde se expone tanto los resultados de la misma como los detalles de cada
versión evaluada.
10.1. Análisis del cumplimiento de los objetivos planteados 59

Figura 10.6: Chatbot - Introducción de mensaje.

Figura 10.7: Chatbot - Ejemplo de respuesta.


60 Conclusiones

10.2. Resultado obtenido


Tras la consecución de los objetivos y una fructífera evaluación podemos concluir que el
videojuego desarrollado cumple con las expectativas creadas inicialmente.

El videojuego ha sido totalmente desarrollado en Ren’Py mediante scripts de Python. La


adhesión de las tecnologías de NLG hacen de él una novela visual innovadora y rejugable.
La tecnología GPT-3 responde de forma adecuada en el contexto de la historia planteada de
forma que en una primera partida es difícil identificar quién de los personajes es el bot.

El producto final obtenido es todavía mejorable y escalable por lo que a continuación plan-
teamos una serie de ideas que deberán desarrollarse en un futuro para poder atraer al gran
público.

10.3. Trabajo futuro


Con el objetivo de obtener un salto de calidad a nivel jugable se plantea añadir la mecánica
“Mago de Oz”, basada en los sistemas de Mago de Oz 1 utilizados para evaluar la interacción
hombre-máquina. Este sistema obtiene su nombre de la novela El maravilloso Mago de Oz 2 ,
donde un hombre corriente se esconde detrás de una cortina y hace creer que se trata de un
poderoso mago. En este experimento un participante interactúa con un sistema inteligente
que cree que funciona de manera autónoma pero en realidad está controlado por un humano
que suele estar en una habitación contigua. El objetivo original de esta prueba es recopilar
información de la interacción entre el participante y el sistema para poder analizar así la
usabilidad del mismo. En nuestro caso, la mecánica tratará de una interacción en la que el
usuario cree que está hablando con una máquina pero en realidad detrás hay un humano.

Actualmente, el videojuego dispone de un conjunto de respuestas prefijadas para cada tipo


de pregunta de forma que existe la posibilidad de que alguna de estas se repita si jugamos un
número abultado de partidas, para evitar esto la idea es que los personajes que actualmente
están desarrollados con contenido estático sean realmente humanos. Con la mecánica “Mago
de Oz” sumada a la de “identificar al bot” conseguimos superar está problemática.

El videojuego en su estado actual es offline y para un sólo jugador. Para desarrollar esta
mecánica necesitaríamos que varios jugadores se pudieran conectar desde máquinas remotas a
nuestro videojuego, de forma que aleatoriamente uno fuera elegido detective y el resto harían
el papel de Mago de Oz como los sospechosos inocentes. Los inocentes dispondrán de un
tiempo para responder a las preguntas que se plantean y cuando acabe su tiempo el detective
deberá jugar para identificar cuál de los sospechosos es el bot. En caso de que el detective
errara en la elección del asesino ganarían los sospechosos y, en caso contrario, el detective. De
esta manera, se podría realizar un Test de Turing entre la IA y los jugadores donde ambos
1
Wizard of Oz experiment https://en.wikipedia.org/wiki/Wizard_of_Oz_experiment
2
L. Frank Baum, The Wonderful Wizard of Oz. United States: George M. Hill Company, 1900.
10.3. Trabajo futuro 61

intentan convencer al detective de que son humanos.

Una vez clara la idea a implementar, el primer paso sería el desarrollo del canal de comu-
nicación en Ren’Py para las máquinas remotas.

Por otro lado, el sistema podría adaptarse para la evaluación manual de sistemas de NLG
mediante narraciones. A partir de la cuestión de la Figura 9.12 que está incluida en el for-
mulario de la Sección 9.4, podemos obtener datos de la dificultad que tiene un usuario para
detectar cual de los personajes es la IA.

Para realizar esta cuestión se ha implementado que el juego genere automáticamente un


fichero al final de la partida que guarde el número del asesino (1, 2 o 3), si el jugador ha ga-
nado o perdido (W o L) y el número de preguntas que ha necesitado hacer a cada sospechoso.
En cada partida realizada se añade una línea más al fichero de forma que tenemos disponible
un registro con todas las partidas jugadas.

Este proceso podría adaptarse para diferenciar entre diferentes IA o modelos de lenguaje
y así poder hacer una comparativa de su similitud con el lenguaje humano en el contexto de
una narración.
Bibliografía
4 Ways AI is Changing Gaming for the Better. (2021, junio). Samsung Semiconduc-
tor. Descargado de https://samsungsemiconductor-us.com/4-ways-ai-is-changing
-gaming-for-the-better/

Alex Walker. (2021, octubre). What Happens When AI Tries To Review A Video Game.
Kotaku. Descargado de https://kotaku.com/what-happens-when-ai-tries-to-review
-a-video-game-1847917110

Alma López. (2020, septiembre). ¿Qué es un roguelike? ¿y un roguelite? Juegos ADN. Descar-
gado de https://juegosadn.es/que-es-un-rogue-lite-y-un-rogue-like-ar-3790/

Antonio Matías. (2021, abril). Rogue Legacy Review: un roguelike que no debe per-
derse. Guía Game. Descargado de https://guiagame.com/rogue-legacy-review-un
-roguelike-que-no-debe-perderse/

Asier Gutiérrez-Fandiño, Jordi Armengol-Estapé, Marc Pàmies, Joan Llop-Palao, Joaquín


Silveira-Ocampo, Casimiro Pio Carrino, … Marta Villegas (2021). Spanish Language Mo-
dels. Descargado de https://arxiv.org/abs/2107.07253v2

C, A. (2016, agosto). Las siete promesas que hizo No Man’s Sky, ¿humo o realidad? Xata-
ka. Descargado de https://www.xataka.com/videojuegos/las-7-promesas-que-hizo
-no-man-s-sky-humo-o-realidad

Chris Crawford. (2003). On game design (1st edition ed.). Indianapolis, Ind. : New Riders.

Christian Nutt, D. D. G. (2010, marzo). Tense Questions: David Cage On Heavy Rain. Des-
cargado de https://www.gamedeveloper.com/business/tense-questions-david-cage
-on-i-heavy-rain-i-

David Heaney. (2021, febrero). This OpenAI GPT-3 Powered Demo Is A Glimpse Of NPCs
In The Future. Upload. Descargado de https://uploadvr.com/modbox-gpt3-ai-npc
-demo/

Fernández Vara. (2019). Introduction to game analysis. Routledge.

Francisco J. Brenlla. (2020, noviembre). La narrativa en los videojuegos: Historias y conflictos


interactivos. MeriStation. Descargado de https://as.com/meristation/2020/11/20/
reportajes/1605863800_319793.html

Gonzalo Scholz. (2021, febrero). Novelas Visuales: la evolución de un género aún incompren-
dido en occidente. Guardado Rápido. Descargado de https://www.guardadorapido.com/
reportaje-novelas-visuales/

63
64 Bibliografía

J. R. R. Tolkien. (1937). The Hobbit. George Allen & Unwin.

José Altozano. (2017). El videojuego a través de David Cage. Héroes de Papel. Descargado
de www.heroesdepapel.es

Juanjo Mestre. (2018, febrero). Narrativas interactivas: ¿cuál usar y por qué? FLUOR Lifesty-
le. Descargado de https://fluorlifestyle.com/narrativas-interactivas-usar/

Julián Ramírez. (2020, noviembre). ¿Cuál es la gracia de los ‘roguelikes’? Gamer Fo-
cus. Descargado de https://www.gamerfocus.co/juegos/cual-es-la-gracia-de-los
-roguelikes/

L. Frank Baum. (1900). The Wonderful Wizard of Oz. United States: George M. Hill
Company. (OCLC: 9506808)

María Rodríguez Juárez. (2020, septiembre). Historias interactivas, cuando te conviertes


en el protagonista del cuento. Revistadigital. Descargado de https://revistadigital
.inesem.es/diseno-y-artes-graficas/historias-interactivas/

Miguel López. (2016, julio). Qué es el sonido procedural y cómo se utilizará en ’No Man’s
Sky’. Xataka. Descargado de https://www.xataka.com/videojuegos/que-es-el-sonido
-procedural-y-como-se-utilizara-en-no-man-s-sky

Mitchell Green, y Jan G. Michael. (2022, enero). What Might Machines Mean? Springer Link.
Descargado de https://link.springer.com/article/10.1007/s11023-022-09589-8

Nick Statt. (2019, marzo). How Artificial Intelligence will revolutionize the way video games
are developed and played. The Verge. Descargado de https://www.theverge.com/2019/
3/6/18222203/video-game-ai-future-procedural-generation-deep-learning

Ramón Varela. (2021, julio). Doki Doki Literature Club Plus supera el medio millón en
ventas en apenas dos semanas. Vandal. Descargado de https://vandal.elespanol.com/
noticia/1350746312/doki-doki-literature-club-plus-supera-el-medio-millon
-en-ventas-en-apenas-dos-semanas/

Random normal vs Random Procedural. (2017, febrero). Ajierda Games. Descar-


gado de https://arjierdagames.com/blog/programacion/random-normal-vs-random
-procedural/

Raúl Ibarra Díez. (2014, septiembre). Generación de música ambiental de videojuegos por
medio de composición algorítmica basada en el modo de juego. Escuela Politécnica Supe-
rior de la Universidad de Alicante. Descargado de https://grfia.dlsi.ua.es/cm/pfc/
ribarra/memoria.pdf

Ridley Scott. (1982, junio). Blade Runner [Ciencia ficción].

Robert Dale. (2020, junio). Natural language generation: The commercial state of
the art in 2020. En Natural Language Engineering (Vol. 26(4), pp. 481–487).
Cambridge University Press. Descargado de https://www.cambridge.org/core/
journals/natural-language-engineering/article/natural-language-generation
Bibliografía 65

-the-commercial-state-of-the-art-in-2020/BA2417D73AF29F8073FF5B611CDEB97F
doi: 10.1017/S135132492000025X

Rodríguez, M. (2016, agosto). ¿Qué es la generación por procedimiento en los videojue-


gos? Gamer Focus. Descargado de https://www.gamerfocus.co/juegos/la-generacion
-procedimiento/

Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Pra-
fulla Dhariwal, … Dario Amodei (2020). Language Models are Few-Shot
Learners. OpenAI. Descargado de https://papers.nips.cc/paper/2020/hash/
1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html
Lista de Acrónimos y Abreviaturas
2D Dos dimensiones.
3D Tres dimensiones.
ABP Aprendizaje Basado en Proyectos.
AI Artificial Intelligence.
API Application Programming Interfaces.
CC-BY-NC Creative Commons - Atribución - No Comercial.
CMD Command.
CSS Cascading Style Sheets.
DOI Digital Object Identifier.
GB GigaByte.
GPT Generative Pre-Trained Transformer.
GRPC Google Remote Procedure Call.
HTML HyperText Markup Language.
HTTPS Hyper Text Transfer Protocol Secure.
IA Inteligencia Artificial.
IEEE Institute of Electrical and Electronics Engineers.
iOS iPhone Operating System.
NLG Natural Language Generation.
NPC Non-Player Character.
OCLC Online Computer Library Center.
PC Personal Computer.
REST Representational State Transfer.
RV Realidad Virtual.
SOAP Simple Object Access Protocol.
TFG Trabajo Final de Grado.
TXT Archivo de texto.
UA Universidad de Alicante.
URL Uniform Resource Locator.
VR Virtual Reality.

67
A. Anexos

A.1. Guión del videojuego


Se va a analizar en profundidad el guión del videojuego. Para ello, se va a explicar el
argumento, se va a describir cada personaje, se va a analizar los diálogos y justificar narrati-
vamente la elección de las imágenes y sonidos.

A.1.1. Argumento
Un androide ha asesinado a su dueño, un señor mayor, y ha escapado de casa. La policía
encuentra gracias a las cámaras de seguridad que tiene instaladas en el vecindario a varias
personas que han estado por la zona la noche del asesinato. Para identificar cuál de estos
sospechosos es el asesino recurren a un detective que tiene que ir corriendo a la oficina de
policía para interrogar a los tres sospechosos y tomar la decisión correcta identificando cuál
de los tres es el auténtico asesino. Tras esta decisión la historia tiene dos finales posibles.
En caso de que el detective acierte le llamará el jefe de policías para agradecerle que ya no
han habido más asesinatos en el vecindario pero en caso de errar en la decisión, el policía le
comunicará que hay nuevas personas asesinadas.

En este argumento, como hemos redactado, existe una ramificación en la decisión del de-
tective sobre cuál es el sospechoso culpable.

Se ha seleccionado este argumento puesto que es idóneo para la mecánica “identificar al


bot” que consiste en que el jugador, que interpreta al detective, deberá adivinar cuál de los
sospechosos es el robot en base a las respuestas que ofrece en el interrogatorio, las cuáles
serán generadas por una IA de NLG.

A.1.2. Personajes

A.1.2.1. Dueño del androide

El dueño del androide es un señor mayor que no tendrá una participación activa en la
historia. En el asesinato que ha ocurrido en el vecindario él es la víctima.

69
70 Anexos

A.1.2.2. Detective
El detective es el personaje que interpretará el jugador. Es el personaje principal pues la
historia gira en torno a la decisión que tome. El jefe de policía le llamará por la noche y tendrá
que ir corriendo a la comisaría a interrogar a los sospechosos para identificar al asesino. Su
imagen no se muestra en el juego pero sí tiene diálogo.

A.1.2.3. Jefe de policía

Figura A.1: Sprites del jefe de policía.

El jefe de policía es la persona que contactará con el detective para que acuda a la comi-
saría a interrogar a los sospechosos. Como se puede observar en la imagen, no lleva nada que
lo identifique como policía pues ha tenido que ir corriendo a atender el caso. Al día después
de que el detective identifique al asesino volverá a llamar al detective para comunicarle si la
decisión ha sido acertada o errónea en base a si ha habido nuevos asesinatos o no.

A.1.2.4. Sospechosos
En el juego aparecerán tres sospechoso de ser el androide que ha acometido el asesinato
de su dueño. Para los sospechosos se ha elegido a Anna, Daniel y Emma. Los dos primeros
son una chica y un chico jóvenes, la tercera es más bien una niña. El aspecto de cada uno no
juega ningún papel en la narrativa. En cada partida aleatoriamente uno de los tres será el
androide asesino y los otros dos humanos inocentes. Esta decisión se ha tomado para poder
añadir rejugabilidad ya que si siempre fuera el mismo sospechoso el culpable sólo tendría
sentido jugar al juego una vez.
A.1. Guión del videojuego 71

Figura A.2: Sprites de Anna, la primera sospechosa.

Figura A.3: Sprites de Daniel, el segundo sospechoso.

Figura A.4: Sprites de Emma, la tercera sospechosa.


72 Anexos

Las líneas de diálogo de los sospechosos varían entre partidas. Los humanos responderán
con respuestas estáticas preestablecidas que se seleccionarán de forma aleatoria entre un
banco de respuesta en cada partida. El androide generará sus propias respuestas a partir de
la IA de NLG.

A.1.3. Diálogos

Tras un menú de selección de idioma e IA comienza la historia. Vamos a mostrar los diálogos
habiendo seleccionado jugar en castellano.

A.1.3.1. Primera escena

Teléfono: *Ring ring ring*

Jefe de policías: Buenos días, Sr. Detective. Necesitamos su ayuda inmediatamente. Ha


habido un asesinato en el vecindario.

Tú: ¿Cómo? ¿Un asesinato?

Jefe de policías: Sí, un asesinato. Estás escuchando bien. Ayer un androide asesinó a su
dueño y huyó de casa. Menos mal que teníamos cámaras de seguridad y pudimos encontrar
a algunos sospechosos.

Tus pensamientos: Afortunadamente me escucharon con el tema de las cámaras, esto es


algo que sabía que algún día podría ocurrir...

Jefe de policías: Vamos rápidamente a la oficina, tenemos allí a los detenidos y hay que
interrogarlos.

Tú: Enseguida estoy allí, voy directo con el tranvía.

Esta primera escena ocurre en la habitación del jugador, es decir, del detective. Por la no-
che el jefe de policías llama al detective para que acuda corriendo a la comisaría a interrogar
a los sospechosos de un crimen.

La escena termina con una transición que muestra el viaje en tranvía desde la casa del
detective hasta la oficina de policías.
A.1. Guión del videojuego 73

A.1.3.2. Interrogatorio
Jefe de policías: Has llegado a tiempo. Tenemos a tres sospechosos que interrogar.

[Aparecen en escena los tres sospechosos]

Jefe de policías: Estos tres estaban por la zona a la hora del asesinato. No les juzgues por
su apariencia, el androide puede ser cualquiera. Nosotros únicamente conocemos sus nombres:
Anna, Daniel y Emma.

Tú: Por favor, que pase el primer sospechoso.

Tus pensamientos: ¿Qué debería preguntar?

[Se muestran cinco opciones de diálogo con a su vez 4 más opciones en cada una]

• Preguntar acerca del vecino


– ¿Conocías al vecino asesinado?
– ¿Alguna vez has visto al vecino por la calle?
– ¿Alguna vez has oído hablar del vecino?
– Volver atrás

• Preguntar acerca de la noche


– ¿Qué estuviste haciendo anoche?
– ¿Sueles salir por la noche?
– ¿No tienes miedo de salir a esas horas?
– Volver atrás

• Preguntar acerca del vecindario


– ¿Por qué pasaste por el vecindario?
– ¿Conocías a alguna persona del vecindario?
– ¿El vecindario es un lugar de tránsito frecuente para ti?
– Volver atrás

• Preguntar acerca del sospechoso


– ¿Tienes antecedentes penales?
– ¿Alguna vez han detenido a algún conocido tuyo?
– ¿Sabes cuál es la condena por asesinar a alguien?
– Volver atrás

• Suficientes preguntas. Pasemos al siguiente sospechoso.


74 Anexos

Si elegimos cualquiera de las temáticas se mostrará otro menú que nos permitirá elegir entre
3 preguntas y una opción de volver al menú de selección de temáticas. Si elegimos cualquiera
de las preguntas, el sospechoso nos responderá. En caso de estar preguntando al asesino, el
texto de respuesta estará generado mediante la IA de NLG y en caso de ser inocente, el texto
vendrá de un conjunto de respuestas prefijadas.

A partir del segundo sospechoso se añadirá una nueva opción. Esta indicará ”Volver al
sospechoso anterior” y nos servirá para retroceder de sospechoso y volver a realizarle las pre-
guntas. Esta opción es útil cuando no tenemos claro quién de los tres sospechosos es el asesino.

Una vez acabemos de hacer las preguntas al primer sospechoso podremos clicar la última
opción de diálogo y pasaremos a interrogar al siguiente. En el último sospechoso esta última
opción pasará a ser: ‘Suficientes preguntas. Creo que ya se quién es el androide’. En cuanto
hayamos interrogado a los tres sospechosos continuará la trama.

Jefe de policías: No hay más sospechosos, detective. Bien, ¿quién crees que puede ser el
asesino?

[Se muestran tres opciones de diálogo]

• Anna.

• Daniel.

• Emma.

Jefe de policías: De acuerdo, puedes irte a casa. Ojalá hayamos tomado la decisión co-
rrecta.

Esta escena termina de nuevo con una transición en tranvía, pero el viaje es el camino
contrario pues vamos de la oficina a casa del detective.

A.1.3.3. Desenlace
La escena comenzará igual que la primera. Nos encontraremos en la habitación del detec-
tive por la noche y una llamada nos despertará.

Teléfono: *Ring ring ring*

A partir de aquí hay dos finales diferentes en base a sí el jugador ha acertado en identificar
quién es el asesino o no. Mostraremos los mensajes finales usando el ejemplo de que el asesino
fuera el primer sospechoso.
A.1. Guión del videojuego 75

En caso de que erremos en la elección el final será el siguiente:

Jefe de policías: Detective, ha habido un nuevo asesinato. El asesino aún está libre.

[Mensaje final: Has perdido... El androide era Anna......]

Por el contrario, en caso de que acertemos:

Jefe de policías: Detective, hemos pasado una noche tranquila. No ha habido más ase-
sinatos. Creo que hemos acertado descubriendo al asesino.

[Mensaje final: ¡Has ganado! ¡El androide era Anna!]

A.1.3.4. Créditos
Por último y tras finalizar el juego, se mostrarán los créditos del juego. Se menciona mi
autoría y el material de terceros.

CRÉDITOS

Diseñado, escrito y programado por


Francesc Bellido Delgado

Imágenes de usuarios de itch.io


Fülli
NoranekoGames
Potat0Master
Konett

Sonidos de usuarios de Fresound


inchadney
sound_designer_from_Turkey
InspectorJ
Fupicat
TaranP

A.1.4. Justificación narrativa de la elección de imágenes y sonidos


En el videojuego se utilizan recursos gráficos y sonoros para acompañar la narrativa de
nuestra narración interactiva y para que el producto final sea más atractivo para el público.
Esto es un estándar en las novelas visuales, que suelen ir acompañadas de un apartado gráfico
estilo anime. En nuestro proyecto hemos optado por un estilo de dibujo no tan fiel al estilo
de animación japonés sin que llegue a suponer una revolución gráfica dentro del género.
76 Anexos

Todos los sprites de los personajes que hemos utilizado en el videojuego tienen tres va-
riantes para mostrar su expresión en el diálogo. Estas tres variantes son enfadado, felicidad
y tristeza. Variar entre las expresiones de los personajes nos ayuda a remarcar su intención
comunicativa y a dotarlos de expresividad.

Los escenarios que componen nuestra trama son la habitación del detective, la oficina de
policías y el tranvía que utilizamos para las transiciones. La habitación del detective tiene dos
variantes: luz encendida y luz apagada. Cuando se muestra la luz apagada se quiere hacer ver
al jugador que es de noche y al acompañar la escena sonoramente con una música de sueños
se quiere hacer ver que el jugador está todavía durmiendo. Esta escena se muestra durante
la pantalla de carga y un breve tiempo tras tomar la decisión final de manera que se muestre
un tiempo de calma antes de saber si hemos ganado o perdido. Al sonar el teléfono se corta
la música ambiental de dormir y cambiamos la escena a la luz encendida de forma que se
aprecie que el jugador se ha despertado y comienza/continúa la historia.

En el juego podemos escuchar cinco sonidos. Vamos a analizar su función y aporte a la


narrativa.

El primero que escucharemos será el sonido de una caja de muñecas que utilizaremos en la
escena inicial durante la pantalla de carga para hacer ver que el juego aún no está listo y que
acompañado de una escena oscura hará entender al jugador que debe esperar a que termine
la carga.

El segundo sonido es el de un teléfono británico, este sonido se escuchará cuando el jefe de


policías llame al detective para pedirle que vaya urgentemente a resolver el caso y además
será el sonido que rompa la calma de la pantalla de carga y de comienzo al juego.

El tercer sonido será el de los pitidos que se escuchan en un metro al abrirse y cerrarse las
puertas, lo utilizaremos para acompañar a la imagen del tranvía durante las transiciones de
forma que se haga ver que va a comenzar a moverse.

El cuarto y quinto sonido dependerán del desenlace que hayamos obtenido en la partida.
En caso de ganar escucharemos un satisfactorio sonido de victoria pero en caso de perder
escucharemos uno de derrota. Estos sonidos junto al mensaje final y la imagen del asesino en
pantalla buscan dar al jugador un feedback instantáneo de si ha ganado o perdido.
A.2. Material de terceros 77

A.2. Material de terceros


El software asociado a este proyecto utiliza assets de libre uso para las imágenes de los
personajes y de las escenas, además de efectos de sonido.

Agradecer a los siguientes usuarios de itch.io1 por sus imágenes:

• Fülli (https://fuelli.itch.io/)

• NoranekoGames (https://itch.io/profile/noranekogames)

• Potat0Master (https://potat0master.itch.io/)

• Konett (https://konett.itch.io/)

Agradecer a los siguientes usuarios de Freesound 2 por sus sonidos:

• inchadney (https://freesound.org/people/inchadney/)

• sound_designer_from_Turkey (https://freesound.org/people/sound_designer_from
_Turkey/)

• InspectorJ (https://freesound.org/people/InspectorJ/)

• Fupicat (https://freesound.org/people/Fupicat/)

• TaranP (https://freesound.org/people/TaranP/)

En las siguientes subsecciones comparto los enlaces donde se pueden obtener todas las
imágenes y sonidos presentes en el juego.

A.2.1. Imágenes de personajes


https://fuelli.itch.io/free-to-use-character-sprites (Libre uso con créditos, tras
contactar con la autora de los sprites se indica que la licencia es CC-BY-NC 4.0)

A.2.2. Imágenes de escenas


https://noranekogames.itch.io/yumebackground (Libre uso con créditos)

https://potat0master.itch.io/free-visual-novel-backgrounds-starter-pack (This
pack has a royalty free license)

1
«Itch.io». https://itch.io/
2
«Freesound». https://freesound.org/
78 Anexos

https://potat0master.itch.io/free-visual-novel-backgrounds-starter-pack-2 (This
pack has a royalty free license)

https://konett.itch.io/modern-visual-novel-backgrounds (CC-BY 4.0 license)

A.2.3. Sonidos
https://freesound.org/people/inchadney/sounds/457869/ (This work is licensed un-
der the Attribution Noncommercial License)

https://freesound.org/people/sound_designer_from_Turkey/sounds/613178/ (This
work is licensed under the Creative Commons 0 License)

https://freesound.org/people/InspectorJ/sounds/346573/ (This work is licensed un-


der the Attribution License)

https://freesound.org/people/Fupicat/sounds/521646/ (This work is licensed under


the Creative Commons 0 License)

https://freesound.org/people/TaranP/sounds/362204/ (This work is licensed under


the Creative Commons 0 License)

También podría gustarte