Introducción

En esta última práctica de la asignatura de Media para Videojuegos debemos hacer un pseudo-juego de lucha con los personajes que hemos realizado durante el curso.

Desarrollo

Mi intención es hacer una simulación muy simple del videojuego Pacific Rim: The Game en 2.5D (es decir, con los personajes moviéndose únicamente en el eje Y y X aunque sea en un entorno 3D).

He recreado un entorno importando diferentes assets gratuitos de la Store (enlances en el apartado de referencias), recreando un mundo post-apocalíptico con ciudades hundidas en el océano como fondo. También he incluido un skybox de cielo nocturno para dar más realismo y un ambiente oscuro.

He incluido los paquetes “Animation Rigging” y “Cinemachine” para controlar mejor los movimientos de los personajes y el seguimiento de la cámara.

Pare empezar con la programación y las animaciones, he añadido componentes de física a todos los elementos. El robot tiene un RigidBody con un Capsule Collider y, por otro lado, el suelo tiene un Box Collider. Importante bloquear la rotación y el movimiento del eje Z del rigid body con constraints.

El script de robot jugador lo he ido escribiendo y mejorando con ChatGPT. Básicamente, consiste en una máquina de estados que transiciona según el input de las teclas y que llama a las animaciones adecuadas según cada estado. Este acercamiento me permitirá añadir la lógica de juego sencillamente después.

He creado este animator controller donde la animación por defecto es la de Idle. Ésta puede transicionar bidireccionalmente con la de Walking dependiendo del parámetro de velocidad. Después las demás animaciones pueden partir desde cualquier estado y al acabar vuelven a Idle (excepto Defeat, que termina la máquina de estados). CORRECCIÓN: hay que eliminar la transición a exit, ya que si no la animación de Defeat se queda en Loop al ser derrotado.

El primer “problema” que me he encontrado es que las animaciones no transicionaban a no ser que hubiera acabado el clip. Por suerte esto tiene fácil arreglo: solo hace falta desmarcar la casilla “Has Exit Time” en la transición de las animaciones correspondientes.

Algo similar sucedía cuando se mantenía presionada una tecla, ya que la animación se reiniciaba constantemente. Esto lo he podido solucionar por código haciendo que no se pueda transicionar entre estados hasta que las animaciones de ataque o defensa hayan finalizado.

He escrito por código que cuando el personaje camine hacia el lado opuesto al que empieza se invierta la animación ( de speed 1 a speed -1) para que haga el efecto de caminar hacia atrás con el parámetro WalkingSpeed.

Al aplicar lo realizado en el V1 al V2 me he encontrado algún que otro inconveniente. Primero, la animación de Walking por alguna razón se exportó con 40 frames congelados así que la he tenido que recortar. Por suerte, desde el inspector de Unity esto se puede hacer fácilmente. Con este robot no se siente tan bien el invertir la animación para hacer que camina hacia atrás, pero todos los parámetros son correctos, así que debe ser un problema artístico de la práctica anterior. CORRECCIÓN: resulta que el problema es que al girar el robot la pierna que comienza a caminar se debía invertir. Es decir, haciendo un flip del personaje se ha solucionado.

He añadido dos barreras invisibles a los laterales para que los personajes no puedan salirse de cámara. Finalmente no he utilizado Cinemachine para hacer seguimiento de los personajes.

En este punto he añadido dos BoxCollider as Trigger delante de los robots para activar la zona de puño cuando se ejecuta la animación. También he hecho que tengan un indicador de vida (100 puntos) y que si se están defendiendo que no puedan sufrir daño. Como extra, he añadido un sistema de partículas que lance chispas cuando impactan para dar más feedback. Para que quede en escrito, este juego no pretende estar balanceado ni dar una experiencia de combate justa.

Para los SFX he utilizado diversos audios de PixaBay y los he reproducido en momentos concretos del script. Los SFX que se reproducen son: Attack, Defeat, Impact y Walking.

Para la lógica del menú he creado un GameManager con una FSM para los diferentes estados del juego: GameStart, GameRunning, GamePaused, GameWinnerV1, GameWinnerV2. Los menús son gameObjects con botones, ya que me parecía mucho más sencillo hacerlo así que crear una nueva escena para el menú principal, etc. También he hecho que reproduzca música en loop y algunos efectos de comenzar y terminar partida.

Finalmente, para exportar con WebGL he instalado el paquete WebGL publisher y he creado una build en local para debuggear. Al principio el asset de la store de Vrbn Studios me ha dado algunos problemas, pero he eliminado del proyecto todos los scripts relacionados (ya que aportaban funcionalidades que no necesitaba para los edificios). De esta manera ya compilaba (con varias advertencias en la consola, pero son ingorables).

Ahora llega el momento que más me temía, que es que el proyecto parece ser demasiado grande para ser exportado en WebGL. Tras una tarde de prueba y error, conseguí exportarlo correctamente importando todas las partes del proyecto de una en una a una versión anterior de Unity y comprimiendo los archivos. Aun así, los edificios seguían dando problemas, así que opté por la vía rápida: hacer un pre-renderizado y ponerlo como textura plana en el fondo. Este método es muy efectivo en cuanto a rendimiento, y más para una versión web. Además, con los efectos de desenfoque y demás no se nota tanto. Debería haber pensado en utilizarlo antes, la verdad.

Edificios con canal Alpha aplicado.

Resultado final exportado con WebGL Publisher.

Juego en WebGL

Mecha Battle! – Unity Play

Apunte: he intentado incrustar el proyecto con un iframe tanto de Itch.io como de Unity Play, pero el WordPress de este servicio no lo permite.

El repositorio de todo el proyecto se puede encontrar públicamente en GitLab: https://gitlab.com/jongompal/r5-mecha-battle.git

Visión de futuro

Lo cierto es que el resultado es sencillo, pero estoy muy contento con el empaque final y cómo se integran los modelos con el entorno. Evidentemente, se podría expandir muchísimo más con más animaciones, personajes, entornos, más tipos de ataque y hacer un sistema de combate más atractivo.

Lo cierto es que me ha atraído mucho la idea de hacer un combate más estratégico y lento en lugar de uno en el que cada milisegundo cuenta y los reflejos rápidos son la joya de la corona. Creo que es una perspectiva del género inexplorada y que empaca muy bien con la estética de Mechas que he querido transmitir.

En el hipotético caso de que siguiera en un futuro apostando por este concepto, claramente haría un rediseño total, pensando muchísimo más en las mecánicas y recreando el apartado artístico en consecuencia (aunque no ha estado mal investigar el camino inverso por una vez).

Para terminar, decir que el punto que me falla siguen siendo las animaciones. Son el apartado que claramente requieren más trabajo y que se nota más antinatural. Por ello, en un futuro proyecto de este estilo buscaría cómo integrar aún más las herramientas del motor con las externas e incluso investigar si sería posible crear animaciones procedurales que se adaptaran al entorno.

Referencias