Implementación en Unity

En este proyecto he desarrollado un videojuego de lucha entre dos robots, utilizando como base los modelos, texturas, rigs y animaciones creados a lo largo de las prácticas anteriores de la asignatura. El objetivo principal de esta última entrega ha sido la implementación de esos personajes mediante un sistema de animación y control en Unity, integrando las animaciones dentro de una máquina de estados funcional y conectándolas a una lógica de juego básica.
El resultado es un prototipo de robots fighter inspirado conceptualmente en los juegos clásicos de lucha en dos dimensiones, como Street Fighter, pero implementado con personajes y entornos tridimensionales. El juego se desarrolla en una única escena, denominada Space Level, donde ambos robots se enfrentan hasta que uno de ellos se queda sin vida.

Actualmente cada robot dispone de movimiento lateral, ataque, defensa, reacción al daño y animación de derrota. Aunque el sistema es deliberadamente sencillo, está planteado como una base sólida sobre la que se podrían añadir mecánicas más complejas en el futuro, como ataques especiales, habilidades diferenciadas o gestión de energía.

El proyecto ha sido exportado a formato HTML y publicado en Unity Play e Itch.io, permitiendo su ejecución directamente desde navegador sin necesidad de instalación local.

• • Robots Fight (UnityPlay): https://play.unity.com/en/games/4a0fc901-9b75-45ac-834e-f62dfd62f825/robots-fight
  • Robots Fight (Itch.io): https://raquel-lopez-barcelo.itch.io/robots-fight
  • Repositorio: https://gitlab.com/RaquelLB/robots

Diseño del sistema de animación

Para el proyecto se han creado dos Animator Controllers independientes, uno para cada robot, tal y como indicaba el enunciado. Aunque ambos controllers comparten exactamente la misma estructura y lógica, se mantienen separados para evitar problemas de retargeting y permitir ajustes específicos en el futuro si cada personaje requiere animaciones o comportamientos distintos.

Estructura de la máquina de estados:

La máquina de estados está planteada de forma clara y deliberadamente contenida. Mientras el personaje está vivo y no recibe ningún input, el estado por defecto es Idle. Desde este estado se puede pasar a Walk cuando se recibe entrada de movimiento, o a Defend cuando el jugador mantiene pulsada la tecla de defensa.

La animación de caminar utiliza un parámetro de tipo float denominado SpeedMultiplier, que permite controlar tanto la dirección del movimiento sin necesidad de duplicar animaciones. Este parámetro se ajusta desde el script de control y se multiplica por un factor de dirección para cada personaje, permitiendo reutilizar el la misma lógica aunque los robots estén enfrentados.

El ataque se gestiona mediante un trigger que lanza la animación correspondiente. Durante la animación de ataque, el personaje no puede moverse ni iniciar nuevas acciones, evitando estados inconsistentes. De forma similar, cuando el personaje recibe daño se activa el trigger Hit, que lleva a la animación de reacción al impacto.

Si el personaje se encuentra defendiendo en el momento de recibir daño, se reproduce una animación específica de Defense_Hit. Desde esta animación se retorna automáticamente al estado de defensa si el jugador mantiene el input activo, o a Idle en caso contrario. Desde Idle no es posible llegar directamente a Defense_Hit, ya que este estado está pensado únicamente como reacción contextual durante la defensa.

El estado Dead se encuentra conectado desde Any State y no tiene transiciones de salida. Una vez se entra en este estado, la máquina de animación queda bloqueada, reflejando que el personaje ha sido derrotado y no debe responder a más inputs.

Las únicas animaciones que funcionan en bucle son Idle, Walk y Defense_Idle. El resto están pensadas para reproducirse una sola vez. Las transiciones se han ajustado manualmente para evitar saltos o solapamientos extraños, permitiendo interrupciones inmediatas únicamente en los casos de Hit, Defense_Hit y Dead, ya que estas situaciones deben reaccionar de forma instantánea a lo que ocurre en el combate.

Control y lógica del juego

La lógica general del juego está centralizada en el script GameManager, que actúa como coordinador de los estados globales de la partida. Este script gestiona el menú inicial, el inicio del combate, el estado de lucha, la finalización de la partida y la recarga de la escena. También se encarga de actualizar el HUD, mostrando la vida de cada robot mediante barras, y de mostrar los textos de victoria y derrota al finalizar el combate.
Al comenzar la partida, el GameManager ejecuta una pequeña secuencia cinemática en la que ambos robots se desplazan hasta su posición inicial de combate. Durante este proceso los controles están desactivados y se reproducen las animaciones de caminar de forma controlada desde código. Una vez los personajes alcanzan su posición, se habilitan las colisiones del escenario y se activa el control de los jugadores.

La lógica específica de cada robot se encuentra en el script Robot_Ctrl, que se aplica al objeto padre de cada personaje. Este script se encarga de leer los inputs desde el Input Action Asset, gestionar el estado actual del robot (reposo, movimiento, defensa, ataque, impacto o muerte) y traducir ese estado en movimiento físico y cambios de animación. Para evitar comportamientos erráticos, el script comprueba constantemente las etiquetas del estado actual del Animator, bloqueando el movimiento o el ataque cuando el personaje se encuentra en animaciones críticas como ataque, impacto o muerte.

La gestión de la vida se realiza en el componente Robot_Statics, que mantiene el valor de salud del personaje y marca su estado como muerto cuando esta llega a cero. La aplicación del daño se realiza de forma distribuida mediante los scripts MakeDamage y TakeDamage, asociados a los colliders ofensivos y defensivos respectivamente. Cuando un collider de ataque entra en contacto con una zona vulnerable del oponente, se registra el impacto y el Robot_Ctrl decide si el daño es válido, comprobando que no se trate de un autogolpe y que el oponente esté realmente en un estado de ataque. Si el personaje se encontraba defendiendo, el daño se anula y solo se reproduce la reacción visual correspondiente.
Este sistema, aunque sencillo, permite separar claramente la detección física del impacto de la lógica de juego, facilitando futuras ampliaciones como distintos tipos de daño, zonas críticas o ataques especiales.

Estética, cámara y sonido

La cámara está planteada siguiendo la lógica clásica de los juegos de lucha en dos dimensiones, con una vista lateral fija, pero aprovechando la profundidad del espacio tridimensional. Se ha elevado y rotado ligeramente para mejorar la lectura de los personajes y dar sensación de volumen sin perder claridad en la acción.
El escenario representa el interior de una nave espacial. Actualmente funciona como un blocking visual cuidado, más orientado a definir el espacio de juego que a ser un entorno final. La estética del escenario es deliberadamente más simple, con geometría low poly y texturas planas, lo que genera cierto contraste con los robots, que presentan un mayor nivel de detalle, suciedad y variación de materiales. Esta diferencia es consciente y se asume como una base provisional sobre la que se podría trabajar en futuras iteraciones.

En cuanto al sonido, el proyecto incluye actualmente música de fondo durante el combate y efectos sonoros básicos para la interacción con el menú. En un desarrollo futuro sería deseable añadir sonidos específicos para los robots, como ruidos metálicos al moverse, impactos al atacar o variaciones sonoras según el estado del personaje.

Interfaz y flujo de juego

Al iniciar el juego se muestra un menú principal desde el que se puede comenzar la partida o salir del juego. Durante el combate, el jugador puede pausar la partida mediante un botón situado en la esquina superior derecha, lo que muestra nuevamente el menú con opciones adicionales para reiniciar la escena o continuar la partida. Al finalizar el combate, el GameManager muestra los textos de vencedor y perdedor mediante una pequeña animación de entrada y, tras unos segundos, recarga automáticamente la escena, devolviendo al jugador al menú inicial.

Evolución y continuidad del proyecto

Este proyecto está planteado como una base sobre la que se podrían desarrollar mecánicas mucho más complejas. A nivel jugable, sería interesante introducir ataques especiales y habilidades únicas para cada robot, sustentadas por una barra de energía. Por ejemplo, el Big Robot podría disponer de ataques a distancia o golpes de área, mientras que el Little Robot podría incorporar saltos, dash o movimientos más rápidos.
También sería interesante ampliar el espacio de combate, pasando de un escenario estático a uno dinámico, manteniendo la lógica 2D pero con desplazamientos horizontales o verticales. Escenarios móviles, como una pelea sobre un tren en movimiento o una zona que se va inundando progresivamente, añadirían presión y variedad al combate, incluso incorporando peligros ajenos a los personajes.
Desde el punto de vista estético, el proyecto ganaría mucho con escenarios tematizados, efectos visuales asociados a las habilidades y un uso más activo de la cámara para reforzar impactos y momentos clave del combate. A nivel de control, una adaptación a mandos sería prácticamente imprescindible para mejorar la ergonomía y permitir una experiencia multijugador más cómoda.

Conclusiones de las entregas anteriores

Este proyecto es el resultado de un proceso progresivo en el que cada una de las entregas anteriores ha condicionado directamente las decisiones tomadas en la siguiente, hasta converger en un único sistema coherente. Desde el inicio, el planteamiento no ha sido el de generar piezas aisladas, sino el de construir un pipeline completo de creación de personajes pensado para su uso final en un motor de videojuegos.

El modelado inicial de los robots sentó las bases visuales y conceptuales del proyecto, definiendo desde el principio dos personalidades claramente diferenciadas que han guiado todas las decisiones posteriores. El contraste entre un personaje ligero y ágil frente a otro más pesado y estable no solo se reflejó en las proporciones y volúmenes, sino que condicionó la forma de entender su movimiento, su comportamiento y, más adelante, su rol dentro del juego. La decisión de mantener un diseño relativamente simple y modular no fue únicamente estética, sino estratégica, ya que permitió afrontar con mayor control las fases posteriores de rigging y animación.
Este planteamiento se reforzó durante la fase de texturizado, donde se buscó alejarse de un acabado excesivamente limpio para apostar por superficies con desgaste, suciedad y variación de materiales. Estas decisiones no solo aportaron mayor riqueza visual a los personajes, sino que ayudaron a consolidar su identidad como máquinas usadas, algo que posteriormente ha resultado clave para que los robots mantengan presencia y credibilidad dentro de Unity incluso en un entorno escénico sencillo.

El rigging me supuso reto en el proceso, ya que obligó a traducir todas las decisiones previas en una estructura funcional capaz de sostener la animación. Al tratarse de personajes que no responden a una anatomía humana estándar, fue necesario diseñar un rig manual adaptado a sus necesidades reales, diferenciando claramente entre piezas rígidas y zonas deformables. Este trabajo no solo facilitó la animación posterior, sino que permitió introducir elementos más complejos, como el control específico del “pelo” del Big Robot, que acabarían influyendo directamente en la planificación y limpieza de las animaciones.

La fase de animación terminó de unificar todo el proceso. Las animaciones no se plantearon como clips aislados, sino como partes de un sistema pensado para convivir dentro de una máquina de estados en Unity. El peso, los tiempos y la exageración de las poses se ajustaron para reforzar la personalidad definida desde el modelado inicial, asegurando que cada robot se moviera y reaccionara de acuerdo con su carácter. El hecho de preparar los bucles, los impactos y las transiciones pensando desde el inicio en su uso en tiempo real ha facilitado la integración posterior en el motor.

Todo este trabajo previo a ayudado a generar un pequeño proyecto de videojuego con la comprensión del pipeline de medios 3D desde su diseño hasta su integración en motor, permitiendo que los recursos generados sean a favor del videojuego y su individualidad.

Recursos

• Kenney. (s. f.). UI Pack [Imagenes]. https://kenney.nl/assets/ui-pack
• Kenney. (s. f.). Space Station Kit [Modelos 3D]. https://kenney.nl/assets/space-station-kit
• dafont.com. (s. f.). TT Octosquares [Fuente tipográfica]. https://www.dafont.com/es/tt-octosquares.font
• OpenGameArt.org. (s. f.). Mouse click [Efecto de sonido]. https://opengameart.org/content/mouse-click
• OpenGameArt.org. (s. f.). Cynic Battle Loop [Archivo de audio]. https://opengameart.org/content/cynic-battle-loop