Asignatura: Trabajo Final de Grado (TFG)
Titulación: Grado Multimedia
Nombre del estudiante: Alejandro Bernat Martínez
Consultor y profesor: Ester Arroyo Garriguez
Introducción
La idea de mi TFG empezó a fraguarse algunos semestres antes, mientras estaba cursando la asignatura Narrativa Interactiva del grado, ya que en una de las entregas se nos pedía la realización de un guion para un hipotético producto interactivo el cual formaría parte de un proyecto transmedia más grande. Para tal fin, escribí el guion que años más tarde sería el germen de este proyecto.
Cuando llegó el momento de matricularme en el TFG y decidir qué rama escogería, me acordé de este guion que tenía guardado a la espera de una oportunidad. Después de barajar muchas otras opciones, opté por rescatarlo y desarrollar un videojuego, ya que era un tipo de proyecto en el que podría expresar casi todas las disciplinas estudiadas durante el grado, como narrativa interactiva, diseño de interactividad, diseño gráfico, modelado y animación 3D y, por supuesto, diseño de software y programación, entre muchas otras materias.
Por tanto, me propuse hacer un videojuego en el que pudiera crear yo mismo todos los elementos y assets que formarían parte de él en cuanto a gráficos, música y código, utilizando mi experiencia en el mundo multimedia complementada ampliamente con lo aprendido en el grado.
No obstante, y puesto que el desarrollo de un juego completo significa muchísimas horas de trabajo, especialmente siendo una única persona la encargada de generar todos los elementos de este, decidí que el objetivo fuera la creación de una demo introductoria de la aventura, de esas que se distribuyen gratuitamente para que, si al jugador le gusta, compre la versión completa. Esta demo se compone de una cinemática de introducción y el primer capítulo interactivo del videojuego en forma de aventura gráfica point & click, al estilo de las clásicas Monkey Island, pero desde un punto de vista más adulto, y adaptándola a los tiempos actuales tanto en narrativa como en jugabilidad. Uno de mis referentes en este sentido ha sido la saga Syberia.
Etapas y retos
Planificación
Uno de los retos más complicados que tuve que asumir fue hacer una planificación correcta del tiempo y los objetivos, ya que debía realizar muchas tareas que no había realizado antes. Además, iba a ser mi primer contacto con el motor de videojuegos Unity y, por lo tanto, tenía que incluir el tiempo de investigación y aprendizaje de este dentro de la planificación.
Investigación y aprendizaje
Empecé a investigar la utilización del motor gracias a unos cursos online adquiridos en una conocida plataforma de aprendizaje, los cuales, si bien no me dieron unas habilidades específicas en lo que necesitaba desarrollar, sí es cierto que me dotaron de una visión general del engine, la cual me permitió avanzar poco a poco complementando con la extensa documentación de Unity. Paralelamente a esta tarea iba adaptando y ampliando el guion original para que se adecuase a una aventura gráfica y creando un mapa de pantallas en el que poder añadir la información referente a cada una: los items que esta contiene, las relaciones entre ellas, los personajes, etc. Este paso, en una demo como pretende ser este TFG, no parece una tarea demasiado práctica, pero considero que se tornará imprescindible según vaya creciendo el videojuego completo.
El siguiente paso era investigar posibles entornos para point & click creados anteriormente en Unity, para que me sirvieran de base en la programación de la interactividad de mi videojuego. Esta búsqueda resultó infructuosa, así que decidí realizarlo yo de cero utilizando código propio y algunas de las herramientas que ofrece Unity, como Raycasting o NavMeshAgent.
Creación de assets 3D
Después de tener más o menos claro lo anterior, ya que podía ser un escollo importante para llevar a buen puerto el proyecto entero, empecé a crear los modelos 3D de los diferentes objetos que compondrían cada escena del juego utilizando el software Blender, el cual es gratuito pero increíblemente potente. Debido a los conocimientos adquiridos en el grado, esta etapa no tuvo inconvenientes reseñables a excepción del momento de hacer el rig de los personajes (la creación de huesos «virtuales» que te ayudan después a cambiar la posición de los modelos y a generar animaciones), ya que tuve problemas con el weigth paint en algunos puntos de la malla, y los cuales sigo sin haber corregido al 100 % en el momento de escribir estas líneas.
Según iba acabando los modelos y los personajes de cada escena los iba importando a Unity directamente. Unity y Blender se llevan muy bien, se pueden importar directamente los archivos sin necesidad de conversiones. Después, montaba las escenas de cada pantalla del juego según el guion con estos assets exportados.
El cursor
Como único elemento de entrada del que dispone el usuario, toda la mecánica interactiva recae sobre su control. Así pues, era primordial que este fuera lo más satisfactorio posible y por tanto requirió una gran cantidad de trabajo y código (tanto es así que la clase que lo controla es la más extensa).
Básicamente el cursor aprovecha las propiedades de detección de «colisiones» de la clase MonoBehaviour de Unity. Esta avisa a la clase que controla el ratón cuando el cursor pasa por encima de uno de sus «colisionadores» y actúa en consecuencia cambiando el aspecto del cursor para que el usuario sepa que ese objeto es interactivo. Además, recoge toda la información que necesita de este para generar la interactividad, por ejemplo, el nombre, las acciones disponibles, etc.
Todo esto permite que el usuario vea cómo el mismo cursor va cambiando de estado según dónde esté situado, modificando su texto asociado, su imagen y las opciones que este brinda al jugador.
El movimiento del personaje por el escenario y las animaciones
Una vez creada la interacción del cursor, había que hacer que el personaje principal se moviera al punto del escenario al que quisiera el jugador pinchando con el puntero del ratón en el punto de la pantalla deseado.
Pero había un problema, utilizábamos un método de entrada 2D en un espacio 3D, por tanto, había que encontrar la manera de salvar esta «limitación». Afortunadamente no tardé en descubrir una función que te brinda Unity que te permite lanzar un «rayo virtual» (Raycasting) desde la posición del cursor y perpendicular a la pantalla. Cuando este «rayo» colisiona con una malla del escenario 3D que contiene un colisionador, te devuelve la coordenada 3D donde se han tocado, así como información sobre el GameObject en cuestión.
Esto me sirvió para averiguar de forma fácil dónde pinchaba el jugador y poder obtener las coordenadas 3D para mover el personaje si hacía falta. Además, el hecho de poder discriminar las mallas contra las que quieres que pueda colisionar el Raycasting te permite filtrar ciertas acciones indeseadas del usuario, como por ejemplo limitar el movimiento del personaje sin necesidad de utilizar «paredes invisibles».
Así pues, una vez obtenidas dichas coordenadas 3D, la clase que controla el ratón las envía a una función de la clase que controla el movimiento del personaje; esta, haciendo uso del sistema que tiene Unity para encontrar caminos dentro del escenario, llamado NavMeshAgent, mueve al personaje hasta el punto deseado esquivando los posibles obstáculos que se encuentre por el camino. No obstante, tuve la necesidad de realizar varios ajustes a la clase para evitar ciertos errores que se producían a la hora de calcular si el personaje había llegado o no al punto de destino, así como para girarlo hacia el lugar hacia donde estaba caminando.
Esta clase que controla el movimiento del personaje principal también dispara sus animaciones. Utiliza la herramienta Animator de Unity, la cual es un potente sistema de animación integral en el que se cargan las animaciones para después poder ser disparadas en tiempo de ejecución de manera correcta.
Parte de las animaciones del personaje están exportadas de la aplicación web Mixamo, la cual tiene muchas preprogramadas que puedes aplicar a tus personajes. Normalmente mi proceso para hacerlas lo más personalizadas posible era: subir el modelo a Mixamo, aplicarle huesos automáticos (estos huesos no los uso después, solo son para generar la animación), seleccionar las animaciones deseadas y descargarlas, abrir estas animaciones en Blender para aplicarlas al modelo con el que estaba trabajando y finalmente guardarlas para importarlas en Unity y cargarlas en el Animator.
El movimiento de la cámara
Otra de las cosas que tenía claras cuando empecé el proyecto es que quería utilizar la cámara como un recurso expresivo y narrativo más, por lo tanto, debía darme la posibilidad de cambiar el plano mostrado al jugador en tiempo de ejecución.
Primeramente «anclé» el GameObject cámara al personaje para que le siguiera siempre a una distancia fija (offset). Esto lo conseguí de manera muy fácil agregándole un script de muestra que viene incluido con Unity (FollowTarget), arrastrar y listo. No obstante, no era exactamente lo que buscaba, ya que no podía manejar la cámara a mi antojo, así que, antes de nada, hice unas búsquedas por Internet esperando encontrar algo parecido o que Unity me lo brindara de manera fácil, pero no lo encontré, motivo por el que me propuse programarlo yo mismo modificando el script anteriormente citado. Al principio creía que iba a ser algo complicado, pero al final lo conseguí haciendo que un árbol de decisiones modificara ese offset de la cámara analizando continuamente la posición del personaje jugable, utilizando para ello una matriz numérica que divide el escenario en porciones.
Para evitar un salto brusco de la cámara en el cambio de un offset a otro, utilicé una función de Unity que permite recorrer la distancia en línea recta que separa dos puntos del escenario.
Así pues, con estas modificaciones conseguí posicionar la cámara en el lugar que me interesaba según la posición del personaje jugable, pudiendo destacar así partes del escenario que me interesaban o creando planos «cinematográficos».
La creación del inventario y el control de todos los items y acciones.
Como todo juego de aventuras, necesitaba crear una interfaz a modo de inventario en el que el jugador pudiera ver de qué objetos dispone e interactuar con ellos. Ya desde el principio tenía claro que este debía ser no intrusivo ni permanente en la pantalla, como por ejemplo los menús de acciones típicas de las point & click clásicas que ocupan un tercio de la pantalla. Así pues, inspirado en las interfaces de juegos ya más actuales como Monkey Island 3, Syberia, etc., el inventario solo aparece en la pantalla en el momento en que el usuario quiere, desplazando el cursor a la parte superior de esta. El inventario da la opción de ver la descripción de los objetos, combinarlos con otros objetos del mismo o utilizarlos con elementos interactivos del escenario del juego.
Esta fue una de esas partes en las que tampoco tenía experiencia previa: cómo crear una interfaz 2D en Unity e integrarla en un entorno 3D, pero finalmente no resultó difícil gracias al GameObject Canvas que provee Unity (el cual facilita la creación de dichas interfaces), y a los conocimientos sobre diseño de interfaces y diseño gráfico que he adquirido durante el grado y mi carrera profesional.
Así pues, tanto los elementos gráficos de esta interfaz como los items están creados principalmente en Illustrator y Blender para los que necesitaban objetos 3D, después fueron exportados a PNG con canal alfa y por último retocados de color, tamaño, etc. en Photoshop.
Los monólogos del personaje y las conversaciones
El personaje jugable puede decir frases según las interacciones que realiza el jugador y también puede hablar con otros personajes que aparecen en la escena. Todas estas conversaciones se plasman en forma de texto en la pantalla.
Para la colocación adecuada de este, cada personaje dispone asociado un objeto vacío (no se muestra en pantalla pero tiene todas las cualidades de cualquier objeto) que indica el punto en el que han de aparecer las frases. La clase que genera los textos busca en tiempo real de ejecución dónde está este objeto «target» y coloca ahí el texto, pudiendo así modificarse la posición durante el juego.
Por otra parte, todos los textos de las conversaciones y monólogos están incluidos en archivos JSON, los cuales corresponden a los personajes y/u objetos interactivos de la escena, de tal manera que, cuando el jugador interactúa con alguno de ellos, el código que se encarga de mostrar el texto recibe como parámetro este objeto y busca dentro de él. Junto con las conversaciones se encuentran los nombres de las clases de las posibles interacciones que podríamos hacer con dicho objeto o personaje, de tal manera que, si el jugador las realiza, ya tenemos esa información a mano.
Soy consciente de que la estructura de código/datos descrita anteriormente no es la óptima de cara a seguir los patrones de buenas prácticas de la programación orientada a objetos, ya que en algunos casos estoy juntando estos en un mismo archivo. Por lo tanto, una de mis primeras tareas tras presentar el TFG tiene que ser el segregarlos en una estructura más limpia.
La cinemática de introducción
La demo contiene una cinemática de introducción que se reproduce al ejecutar el juego. Está creada directamente con escenas modeladas, montadas en Blender y animadas. En esta ocasión, toda la animación utilizada es de elaboración propia, con las herramientas de animación de Blender y gracias a los conocimientos adquiridos durante el grado.
Durante la realización tuve varios problemas que se agravaban porque se trataba ya de las últimas semanas antes de entregar el proyecto. Por ejemplo, no conseguía importar en Unity el movimiento de los ojos de los personajes (estos, en un primer momento, estaban creados con Blend Shapes, que es una herramienta típica de los entornos 3D que ayuda a crear animaciones y «posturas») y finalmente lo solucioné utilizando huesos (bones) en los ojos en vez de los Blend Shapes (era extraño porque el resto de expresiones de la cara funcionaban correctamente).
Otro de los escollos que tuve fue la imposibilidad de sincronizar correctamente los textos (generados en Unity) con los movimientos de los personajes y demás objetos. Esto fue debido a que, por desconocimiento, estaba utilizando la herramienta Animation de Unity junto con código para disparar cada animación o texto y era una locura coordinarlo todo. Pronto me di cuenta de que las cinemáticas son algo muy común en los videojuegos y que no podía ser que Unity no tuviera un sistema específico para ellas. Así pues, investigando, descubrí la herramienta Timeline que permite gestionar, sincronizar y disparar código todo desde la misma línea de tiempo, como si fuera cualquier programa de animación, facilitando enormemente la tarea.
La música
Desde que tuve mi primer ordenador, un MSX HB-55P allá por finales de los 80, he tenido inquietudes de crear música con herramientas informáticas: en principio era una simple instrucción de BASIC, como «PLAY”EEFGGFEDCCDEEDD”», posteriormente fue con los primeros PC con tarjetas Sound Blaster… y así han ido pasando los años y la tecnología, y siempre he tenido esa curiosidad de crear con ella, sin más aspiración que pasármelo bien.
Para este proyecto pensé que sería divertido hacer yo también la música, aunque como es un apartado que queda fuera del ámbito del grado, me lo propuse como un hito secundario. No obstante, llegué a hacer la música de la introducción y la del menú de inicio con el software de notación musical Notion Music y un sintetizador hardware Roland XV-3080.
La estética
Hoy en día el mercado está sobresaturado de juegos, y aunque pienso que es el mejor momento de la historia para la industria y el jugador, bien es cierto que es realmente difícil destacar y ser conocido, especialmente siendo un estudio pequeño. Algo en que parece coincidir la mayoría de juegos de bajo presupuesto que han sobresalido en los últimos tiempos en la industria es la utilización de una estética diferente, ya sea por bonita, rara, expresiva, etc.
Así pues, consciente de mis limitaciones técnicas, artísticas y de tiempo (al ser una sola persona) decidí utilizar la técnica de modelado low poly, que consiste en generar figuras y objetos utilizando pocos polígonos y generando una estética como de elementos de juguete. No obstante, quería ir un pasito más allá y utilizar la luz y el color como un elemento vivo y estético más y así intentar destacar un poco sobre el resto de juegos con estética low poly dentro de mis posibilidades.
He utilizado ampliamente iluminación en tiempo real y volumétrica, creando sombras dinámicas como las que las nubes proyectan en el suelo. Esto resta una cantidad considerable de recursos, pero creo que merece la pena después de ver los resultados. Además, también he intentado cuidar la paleta de color, utilizando tonos contenidos y adyacentes en la mayoría de los casos, lo que otorga homogeneidad y calidez.
Conclusiones
Más allá del ámbito académico y de la nota obtenida, considero que la realización de este TFG ha sido una experiencia muy satisfactoria a título personal. El hecho de tener libertad en la concepción del proyecto y el apoyo y guía constante de los/las tutores/as me ha facilitado enormemente la puesta en marcha y la búsqueda de los recursos necesarios.
Así mismo, es muy motivadora la oportunidad de poner en práctica todo lo aprendido durante tantos años, tanto en el grado como de forma autodidacta; y lograr no solo los objetivos primarios propuestos, sino también ir un poco más allá y que, además, te lo reconozcan los responsables de la asignatura con matrícula de honor.
Si pudiera volver al inicio de la asignatura, estoy convencido de que volvería a presentar el mismo proyecto por lo que significa para mí; no obstante, esta vez planificaría un poco mejor la estructura del código antes de empezar, para perder menos tiempo una vez se empieza a picar. Cierto es que esta es una tarea mucho más fácil ahora que conozco el motor Unity y sus «intimidades»; aun así, y visto que Unity se comporta prácticamente al 100 % como cualquier librería orientada a objetos, sé que hubiese ganado tiempo de haberlo planificado mejor.
Por último, quiero agradecer desde estas líneas el trato recibido por los/las tutores/as y responsables de la asignatura, tanto en la ayuda durante la realización del proyecto, como en su valoración e interés que mostraron durante mi defensa.
Enlaces relacionados
Si te ha gustado el artículo y sientes curiosidad por probar la demo, se encuentra disponible en el siguiente enlace: https://fardatxodigital.itch.io/hidden-celtics-prologue
Cita recomendada: BERNAT MARTÍNEZ, Alejandro. Hidden Celtics: una aventura gráfica point & click situada entre Barcelona y Galicia en la brutal posguerra del s. XX. Mosaic [en línea], mayo 2021, no. 193. ISSN: 1696-3296. DOI: https://doi.org/10.7238/m.n193.2122
Thanks.