Link del Juego

• UnityPlay: LINK

Introducción

Para este proyecto se creará un videojuego de lucha Jugador vs Jugador, donde se usará los modelos de los anteriores proyectos del curso.

Implementación de los modelos de Maya

Para el modelo de los jugadores y las animaciones se esta usando lo realizado en maya.

Además para agregar las colisiones para la animación de “ataque” se crearon dos clips de animación copiando las propiedades del modelo de animación original de maya, ya que este ultimo no permitía la modificación.

Para el Animator se realizo como se muestra en la imagen, cada animación tienen como enfoque principal a la animación Idle, debido a que ella es la animación por defecto cuando el jugador no controla al personaje, además la animación de muerte no es necesario que vuela a Idle ya que en teoría ahí terminaría el juego. Se uso dos animaciones para caminar, derecha e izquierda una con velocidad en positivo y el otro con velocidad en negativo representando que esta caminando hacia atras.

Movimientos Scripts

Para los movimientos de los jugadores, se implementos el Script  para que cada jugador según su “Tag” asignado, tuviera su tecla del teclado correspondiente(‘a’, ‘d’, ‘f’, ‘r’, ‘j’, ‘l’, ‘h’, ‘y’). Mejorando a futuro con variables independientes que puedan ser modificadas por parte del jugador desde una ventana de opciones en el modo de juego.

Control de la cámara

Con respecto al control de la cámara se implemento un script para que vea a un objeto invisible fijado entre los los jugadores, manteniéndose siempre en el medio de ellos y alejando la cámara si los jugadores se alejan. A su vez se implemento un pequeño script para poder pausar el juego con la tecla ‘escape’.

Otros Scripts

Scripts básicos para cambiar entre escenas.

Conclusión

Todo lo visto en este ultimo proyecto y los anteriores, me demostraron que no es fácil crear un videojuego desde cero, pero que tampoco es imposible, se necesita constancia y esfuerzo para llegar a la meta planteada. Con estas bases puedo seguir estudiando más tutoriales o videotutoriales para mejorar tanto en programación, animación, edición de audio y otros aspectos más que embarcan la creación de un videojuego.

Visión de futuro para este proyecto

Contando con un equipo de desarrollo, se podría implementar más animaciones, como el salto, diferentes ataques más, un movimiento de esquiva. Y seguir puliendo los algoritmos usados para optimizar el proyecto. Asu vez el tener como meta llegar a más plataformas inicialmente a Nintendo Switch y móviles, ya que estas están más enfocadas a la jugabilidad entre amigos, ya sea vía online (móviles) o de forma local (Switch). También podemos agregar efectos de ataque para cada luchador y agregando más luchadores, aumentando la malla de personajes.

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

Animación de dos robots

Modelos en Sketchfab:

• Big robot: https://skfb.ly/pBTNv
• Little Robot: https://skfb.ly/pBTJD

En esta actividad he creado las animaciones principales para los dos robots desarrollados en los retos anteriores con el uso de Blender. El objetivo ha sido dotarles de un conjunto de acciones básicas que se puedan reutilizar después en Unity: reposo, movimiento, ataque, defensa, recibir daño y muerte.

Aunque el enunciado pedía cinco animaciones por personaje, finalmente he preparado siete animaciones para cada robot, reutilizando la misma lógica pero adaptando el movimiento y el peso a la personalidad de cada uno.
A lo largo de la entrada adjunto capturas del proceso, los enlaces a sketchfab y un video por cada robot con todas las animaciones desde distintos puntos de vista.

Modelos y enfoque general

He trabajado toda la animación en Blender, reutilizando los rigs que preparé en el reto de rigging. Desde el principio he querido que cada robot tuviera una personalidad clara a nivel de movimiento. En Little Robot he priorizado la sensación de agilidad, apoyando gran parte del peso en el único brazo disponible y marcando bien los cambios de apoyo en las piernas. Para reforzar esta idea he exagerado la asimetría del cuerpo: el brazo activo ha tomado más protagonismo en las poses de ataque y defensa y he desplazado ligeramente el centro de masas hacia ese lado, de forma que el personaje parece desequilibrado por el peso de su único brazo “útil”. En Big Robot he buscado justo lo contrario: un personaje más lento y estable, con movimientos más contenidos y robustos. Sus reacciones han sido más lentas y los gestos algo más torpes, lo que ayuda a transmitir esa sensación de peso y de máquina pesada que no se mueve con tanta soltura como el robot pequeño.

Proceso de animación

Poses base

Para construir cada animación he seguido siempre el mismo flujo de trabajo. Primero he definido las poses clave sin preocuparme todavía por las transiciones; por ejemplo, en la animación de ataque he partido de la pose relajada, he fijado la pose de impacto y finalmente la vuelta a la calma. Una vez claras las posiciones extremas, he añadido las poses intermedias necesarias para evitar deslizamientos y conseguir que el movimiento se sintiera creíble. En la animación de caminar, por ejemplo, he reforzado la pose en la que la pierna se levanta entre paso y paso, porque sin esa clave el pie tendería a arrastrarse sobre el suelo. En estas poses intermedias también he aprovechado para separar ligeramente los brazos, introducir pequeños rebotes en la cabeza y el torso y compensar el peso del cuerpo.

Con el esqueleto de poses montado, he ajustado los tiempos y los espaciados para que el movimiento resultara más natural. He desfasado levemente los brazos respecto a las piernas, he introducido ligeros retrasos entre el gesto del pecho, la cadera y los brazos, y he añadido pequeños rebotes que ayudan a vender el peso y la inercia de cada personaje. Todo este ajuste ha sido clave para intentar que las animaciones no se vean mecánicas.

Gestión del pelo del Big Robot

El pelo del Big Robot ha sido la parte más complicada. Para automatizar su comportamiento he usado dos constraints principales por mechón:

• Damped Track, para que el esqueleto del mechón siguiera una referencia y reaccionara al movimiento de la cabeza.

• Limit Rotation, para restringir los ángulos y evitar que el pelo atravesara en exceso el modelo.

Por ello, de cara a la exportación he tenido que hacer un paso extra. Primero he bakeado la animación de estos huesos para transformar el resultado de los constraints en keyframes normales. Después he limpiado los keys redundantes y he ajustado los bucles para minimizar los cambios bruscos de rotación entre el final y el inicio de cada ciclo. De esta manera Unity recibe animaciones cerradas en bucle y no depende del cálculo en tiempo real de los constraints, lo que evita saltos extraños al reiniciar las animaciones.

Herramientas de Blender usadas

Para agilizar el trabajo me he apoyado en varias herramientas de Blender:

• Pose Library:
  Durante el proceso he utilizado la Pose Library de Blender para agilizar el trabajo con los dos personajes. He ido guardando poses predefinidas tanto de toda la armadura como de grupos de huesos concretos. Entre estas poses he registrado, por ejemplo, una pose de relax general, un puño cerrado o las poses base de ataque y defensa. Esta biblioteca me ha permitido reutilizar y adaptar rápidamente las mismas poses en distintas animaciones y en ambos robots, modificando solo los matices necesarios para cada situación en lugar de construir cada pose desde cero.

  

• Bloqueo de transformaciones:
  Para mantener las animaciones más limpias y evitar keyframes en canales que no debían cambiar, he configurado el bloqueo de transformaciones en varios huesos del rig. En el torso he bloqueado la localización, dejando solo la rotación activa, ya que por la propia jerarquía del esqueleto no tenía sentido que ese hueso se desplazara de forma independiente. En los huesos de tipo pole IK he bloqueado la rotación porque su función es únicamente de dirección y no de giro directo. Con estos bloqueos he evitado generar keyframes vacíos o ruido innecesario en el editor de curvas, lo que ha facilitado tanto la edición como la limpieza final de las animaciones.

• Colecciones de huesos:
  También he aprovechado el sistema de colecciones de huesos que preparé en el reto de rigging para organizar mejor el trabajo de animación. He aprovechado las colecciones específicas para los huesos móviles del cuerpo y otra para los huesos del pelo, de modo que podía aislar rápidamente el grupo que necesitaba en cada fase del proceso. Esto me ha ayudado a evitar bakear por error huesos que no debían recibir animación directa, como la cadena de IK de los brazos o la punta del pelo utilizada solo como soporte de constraints, y a centrarme en los huesos realmente relevantes en cada momento sin saturar el timeline.

Animaciones creadas

Para cada robot he generado el mismo set de animaciones, adaptando timings y actitudes a su personalidad:

• Idle
  Bucle en posición de reposo. El objetivo ha sido que se pueda reproducir indefinidamente sin saltos visibles.

• Hit
  El personaje recibe un impacto desde la pose de reposo. He intentado usar el mínimo número posible de keyframes para que en un futuro se pueda combinar con otras animaciones (por ejemplo, con un desplazamiento), aunque esto habría que testearlo en un contexto real de juego.

• Defense_Idle
  Bucle en posición de defensa, con un peso más bajo y tenso que en Idle.

• Defense_Hit
  El personaje recibe un golpe mientras está en defensa. Cambian los vectores de reacción respecto a Hit normal para que se note la diferencia.

• Attack
  Animación de ataque desde la posición de reposo hasta la acción y retorno a la calma.
  He enfatizado el anticipo y el follow-through para que se lea bien el gesto.

• Walk
  Bucle de caminar. He incluido un avance del root para poder gestionar la velocidad desde el Animator de Unity ajustando el parámetro de velocidad del clip.

• Dead
  Animación de derrota/muerte. No es cíclica; el personaje termina en el suelo y se queda inmóvil.

Pruebas en Unity

Para asegurarme de que las animaciones estaban correctamente preparadas para el motor he realizado una prueba rápida en Unity. He exportado los modelos en formato FBX con todas las animaciones incluidas y he creado un Animator Controller básico para cada robot, conectando los estados Idle, Walk, Attack, Defense, Hit y Dead. A partir de ahí he configurado parámetros booleanos y triggers para cambiar entre estados y he comprobado que los bucles de Idle, Defense_Idle y Walk se reproducían sin saltos visibles, que las transiciones entre Attack, Hit y Dead no generaban poses intermedias extrañas y que el avance del root en la animación de caminar se podía reutilizar para controlar la velocidad desde el parámetro de speed del propio clip. Mi intención es utilizar este controller como punto de partida para la siguiente actividad, donde los robots empezarán a “pelear” dentro del juego y podré refinar este sistema.

Dificultades

El pelo de Big Robot ha sido una de las partes más conflictivas del proceso. Al calcularse automáticamente mediante constraints, el reinicio de los bucles forzaba un recálculo brusco de la rotación del pelo y aparecían posiciones extrañas justo al volver al primer frame. La solución, como explico en el resto del documento, ha pasado por bakear la animación de estos huesos antes de exportar, limpiar las curvas y cerrar cuidadosamente los bucles para evitar esos saltos. Sin embargo, me hubiera gustado implementar un sistema de colisiones, dado que me enfrenté a este problema al final del proceso, en la exportación, no tenia tiempo para gestionar este cambio de cálculo.

Otra dificultad importante ha sido la pérdida de varias animaciones durante el trabajo en Blender. El programa elimina automáticamente los datos que se quedan con “0 users” al cerrar el archivo, y aunque existe la opción de marcar un “fake user” para conservarlos, no suelo tener problemas con ello y en este caso me he confiado. En la práctica lo que hacía era generar una acción, pulirla y dejarla a 0 users al asignar al rig la siguiente animación. Entre distintas sesiones de trabajo me he encontrado con que había perdido casi todas las animaciones generadas hasta ese momento en cada modelo, a excepción de la que estaba usando en la última sesión, lo que se ha traducido en unas cuatro animaciones perdidas. Gracias al sistema de autosave he podido recuperar dos animaciones y una pose de referencia; la otra animación he tenido que reconstruirla desde cero y la pose de posado he tenido que terminarla de nuevo. Para evitar que volviera a suceder he gestionado correctamente las acciones añadiendo el “fake user” y poniéndola en “stash” en NLA. Aunque ha sido frustrante, también me ha servido como recordatorio para gestionar mejor las acciones y los “fake users” en futuros proyectos.

En general, el proceso de animación me ha resultado más exigente de lo que esperaba, sobre todo por la cantidad de iteraciones necesarias para que los movimientos dejaran de verse mecánicos y por los problemas añadidos del pelo y la gestión de acciones en Blender. Aun así, siento que he aprendido bastante sobre cómo planificar mejor las animaciones, proteger el trabajo (fake users, NLA) y preparar los clips pensando desde el principio en su uso real dentro del motor.

Vídeos de las animaciones, en Blender y en Unity:

Este primer vídeo fui montándolo según iba terminando animaciones:

Vídeo de cómo se ven las animaciones finales en Unity (sin input, simplemente en bucle):

Distintas perspectivas:

A continuación adjunto varios vídeos del proceso. La mayoría corresponden a autoguardados de diferentes momentos, ya que durante la producción estuve muy centrada en el trabajo y no siempre grabé manualmente:

Animación idle en proceso, se puede ver que todavía no había ajustado bien las curvas y daba un “salto” del último al primer frame.

Animaciones de andar en proceso.

Captura del proceso de animación de Death de Player1. Si no colocaba manualmente los huesos en el frame 19, autogeneraba un giro extraño al dar la vuelta del modelo, haciendo que quedase todo el personaje revuelto.

En el caso de las animaciones de ataque y defensa, no dispongo de capturas de proceso porque fueron relativamente rápidas de producir (aprox. 30 minutos por animación) y no se generaron autoguardados en esos intervalos.

Respecto a las animaciones de muerte, al ser las últimas que realicé, los autoguardados se sobrescribieron a medida que iba ajustando detalles, y solo he podido recuperar la captura de pantalla anterior.

Software empleado

• Blender para todo el proceso de animación. Las animaciones se han planteado para ser vistas de lado; de frente puede parecer que los personajes están algo “desbalanceados”, ya que se han exagerado posturas para mejorar la lectura y la estética de las animaciones

Animaciones de Reposo (Idle)

Las animaciones de tipo Idle fueron las más sencillas de realizar, creando en primer lugar un primer frame que sirva de “pose base” también para las demás animaciones.

La principal manera de crear las animaciones de idle fue crear la pose inicial, duplicarla en el último frame (48 frames en total) y entre medias añadir pequeñas oscilaciones, sobre todo en los huesos del torso y la cadera para crear un pequeño movimiento. En Player 2 se ha elegido hacer un movimiento más marcado y a un ritmo ligeramente distinto que en Player 1, que es algo más suave o sutil. Además, a Player2 he añadido la particularidad de tener un pie de puntillas en la mayoría de animaciones.

Por último, se ajustaron las curvas de animación para facilitar el loop.

Animaciones de Ataque

Para las animaciones de ataque, planifiqué que Player1 diera dos puñetazos, al ser de menor tamaño que Player2, y Player2 una patada. Para ello, tuve como referencia fotos y vídeos que tomé de mí misma, y también grabé la pantalla mientras jugaba Tekken 7 con distintos personajes, editando luego el vídeo y ajustándolo a velocidad 0.2x, pudiendo así estudiar detenidamente cómo se planteaban ciertas animaciones dentro del juego, y cómo varían de personaje a personaje. Sin embargo, no he seguido una técnica tradicional de motion capture, ya que en vez de situar el vídeo dentro del propio software y fijarme en la posición de cada frame, simplemente lo he empleado de referencia y como material de estudio.

En Player1 al tener un ataque doble, la animación dura 48 frames. Player2, que es más rápida, tiene una animación de 30 frames.

En ambas animaciones, se añadieron los frames 1 y 48, que son iguales, y posteriormente se añadió un frame central con la pose de ataque  (es decir, la pierna levantada en caso de la patada, y el primer puño sacado en el caso de los puñetazos). A partir de ahí, fui añadiendo keyframes intermedios y más detalles, finalmente editando las curvas para ajustar el ritmo. En estas animaciones lo que me resultó más complicado fue afinar el efecto de impacto, que mejoró bastante con pequeños movimientos y giros en zonas cercanas (ej.: El muslo en el caso de la patada, el pecho en el caso del puñetazo), además de hacer que el keyframe de impacto dure dos frames. Al estar sostenido un frame más, da la sensación de que es un golpe y no solo un movimiento del brazo o la pierna.

Animaciones de Defensa (Crouch)

Puesto que ambas tienen ataques altos, he planteado que la postura de defensa sea agacharse para esquivar los ataques. En estas animaciones no he añadido una transición para pasar de Idle a Crouch, sino que añadiré dentro de Unity una transición entre ambas animaciones para suavizar el cambio de una animación a otra. De esta manera, se puede repetir en bucle la animación de defensa si el jugador decide mantenerse más de 48 frames en este estado. Al igual que en la animación Idle, he añadido un pequeño balanceo en ambos personajes, siendo el movimiento de Player 2 más notorio.

Animaciones Desplazamiento  (Step)

Para el desplazamiento de los personajes he querido plantearlo similar a como lo plantean sagas como Street Fighter o Tekken, en el que el movimiento es un solo paso cada vez que se pulsa el botón de input (una Arrow Key del gamepad, como herencia de cuando se planteaban estos juegos de lucha en máquinas de arcade). No es un movimiento sostenido o constante, sino un solo paso cada vez que se pulsa el botón.

Por esto, mi idea es plantear el propio desplazamiento del personaje en el eje X a través de programar el comportamiento en Unity, permitiendo que la animación de Desplazamiento comience y termine como el primer frame de Idle, permitiendo oscilar fácilmente entre movimiento y reposo. La animación se ha hecho manteniendo el eje central del personaje fijo, y simulando movimiento con el cuerpo, sin llegar a desplazar el propio personaje.

Además, se ha planteado para poder invertir la velocidad del movimiento y que la animación funcione como un paso hacia atrás también.

Animación Derrota (Death)

Las animaciones de derrota, junto a las animaciones de ataque, fueron las más complejas. Especialmente la de Player1, que quise hacer que diera un giro en el aire como consecuencia de recibir una patada final de Player 2. Hacer que diera la vuelta fue especialmente complicado, y es la animación con más keyframes con diferencia. Gran parte del trabajo fue, no solo moviendo los huesos del personaje, sino ajustando las curvas para que el ritmo fuera adecuado.

A continuación se pueden ver dos capturas de pantalla de los keyframes (mostrando solo los de los huesos parent) y el gráfico de curvas (teniendo en cuenta todos los huesos):

Como se puede observar en las curvas, en los frames 18 y 19  es cuando el personaje termina de dar el giro en el aire, y cambian de orientación y posición numerosos huesos del cuerpo. En las curvas se traduce como una zona saturada de pequeños puntos (ajustes en huesos), con mayores curvas en el gráfico.

En esta animación, al igual que en las anteriores, se añadieron en primer lugar el keyframe 1, luego el central (dando la vuelta en Player1, y cayendo en el caso de Player2), y la postura final. Una vez tengo estos tres keyframes clave, voy añadiendo keyframes, moviendo el keyframe central y corrigiendo detalles.

En Player2 hice una animación de derrota en la que el personaje se ve brevemente impulsado en el aire y finalmente cae, tras recibir un puñetazo. En el caso de Player 2 la posición de caída es de lado, mientras que en Player 1 se ve perpendicular a la cámara. Quise hacer esta distinción para generar más diferencia entre ambos personajes, tras haber estudiado y visto que en juegos de lucha también hay numerosas posiciones y animaciones de derrota según el ataque que reciban.

Para estas animaciones, tuve como referencias grabaciones que tomé de Tekken 7, a cámara lenta:

Exportación de FBX y conclusiones

Se pueden observar los modelos animados en sketchfab:

Player1

Player2

Finalmente, comprobé que los modelos con sus animaciones se animasen y exportaran correctamente a Unity, que no me dio problemas. Creé un loop igual que en sketchfab, reproduciendo todas las animaciones una después de otra.

Como conclusión, era la primera vez que animaba en 3D y he notado una curva de aprendizaje importante. El primer día la mayor cantidad de tiempo se fue en comprender cómo configurar correctamente las acciones en Blender para que se guarden las animaciones.

Tuve algún susto de animaciones que de golpe dejan de funcionar o verse, y agradezco haber hecho copias de seguridad según iba trabajando ya que algunos de los errores eran por configurar mal la animación nueva que creaba, sobreescribiendo otra acción o no guardándose correctamente. Para el último día de trabajo ya sentía que había agilizado bastante el proceso, y me lancé a hacer las animaciones de derrota más complejas que las anteriores para poner a prueba lo aprendido.

Para el futuro, me gustaría probar a hacer el proceso de animación recreando el método de Motion Capture, con vídeos propios o de licencia gratuita, para comprobar si hay mucha diferencia entre hacerlo a mano, de manera libre, y con un vídeo en el fondo pudiendo adaptar cada keyframe para que sea exactamente igual que el vídeo.

Siento que he aprendido bastante, pero ha habido momentos en los que no conseguía que el movimiento se viera del todo natural y no conseguía descifrar qué en concreto era lo que fallaba. La mayoría de veces se arreglaba añadiendo movimientos sutiles en huesos como la cabeza o la cadera, pero ha habido otros keyframes que por muchas vueltas que le diese no terminaba de sentirlo natural.

Animaciones de los Robots

Animaciones del Robot A:

• Idle_Robot_A
• Movimiento_Robot_A
• Ataque_Robot_A
• Defensa_Robot_A
• Muerte_Robot_A

Animaciones del Robot B:

• Idle_Robot_B
• Movimiento_Robot_B
• Ataque_Robot_B
• Defensa_Robot_B
• Muerte_Robot_B

Resumen

Se tomo como base algunas animaciones de mixamo para crear las propias para cada robot. Como el movimiento asemejando a movimientos de boxeo, para el ataque del Robot A usa sus puños para su ataque en cambio el Robot B lanza unos martillazos. Sus movimientos de movilidad son similares para ambos robot diferenciándose en que el Robot B arrastra sus pies debido a que usa ruedas. Para su movimiento de reposo parten de la misma base pero con sutiles diferencias, siendo el Robot A un tipo de lucha de Box mientras que el Robot B se considera un tipo de lucha más salvaje al usar martillos.

Videos

Robot A

Robot B

En versión Drive.

Reflexión

Aunque al principio parecía fácil de animar, en realidad es un trabajo laborioso. Ya que debes de ser minucioso para que las animaciones resulten lo más fluidas posibles. Fue bastante divertido generar animaciones desde cero, aprender el proceso y lograr ver los resultados que uno desea.

Introducción

En esta tercera práctica había que crear el rig de los robots modelados anteriormente. El objetivo era generar dos versiones diferentes: una creada manualmente en Maya (en mi caso utilicé Blender para realizarla mediante el add-on de rig humano) y otra utilizando el sistema automático de Mixamo. A lo largo del proceso encontré varios desafíos técnicos que me permitieron comprender mejor cómo funciona la relación entre esqueleto, pesos y deformación de la malla.

Drive: 

https://drive.google.com/drive/folders/1HEFsW46dQojQpPvkppn2On5CRNctHvfS?usp=sharing

Rig manual en Blender

Para comenzar el rig manual, habilité el add-on Rigify, ya que proporciona una estructura inicial de esqueleto humano que sirve como base para colocar los huesos principales de forma más organizada. Tras añadir el esqueleto, el siguiente paso fue emparejar cada hueso con la parte del cuerpo correspondiente del robot. Una vez colocados todos los huesos, procedí a vincular la armature y la mesh utilizando el método de “Automatic Weights” como punto de partida. Como es habitual con este tipo de automatización, algunas zonas se deformaban de manera incorrecta al rotar ciertos huesos. Para solucionar esto utilicé la herramienta “Weight Paint” para ajustar manualmente la influencia de cada hueso sobre la malla. Finalmente, probé diferentes posiciones, exporté el resultado a FBX y verifiqué en Unity que la estructura se importaba correctamente.

Rig en Mixamo

Después de terminar el rig manual, decidí probar con Mixamo para comparar. Subí el robot en FBX con las texturas ya aplicadas esperando que el proceso fuera más rápido. Sin embargo, me encontré con que el rig automático deformaba partes del modelo de forma extraña, especialmente en las articulaciones.

Comparando ambos enfoques, el rig manual consume bastante más tiempo y requiere paciencia, pero a cambio se tiene más control sobre cada hueso y cómo afecta a la malla. Además, se puede adaptar a cualquier personaje, sin importar lo alejado que esté de la anatomía humana. Mixamo,por otro lado, es increíblemente rápara modelos que tienen proporciones humanoides, pero se complica cuando te sales un poco de ese molde.

Robot 1

Proceso de generación del rig: Mixamo

Para obtener el rig de Mixamo, he tenido que subir la versión del modelo de la práctica anterior sin texturas. Al exportar con texturas me aparecía un error en Mixamo diciendo “Sorry, unable to map your existing skeleton” cuando no tiene esqueleto. Este es el resultado:

Como se puede ver en la imagen, la posición de los huesos es aceptable, pero al ser un modelo robótico, no respeta la rigidez de los materiales.

En algún momento conseguí subir el modelo con mi propio rig y sin texturas, pero no he conseguido replicarlo y solamente tengo una captura de pantalla:

Una vez riggeado si que respeta la rigidez, pero no los “constraints” de los huesos.

Proceso de generación del rig: Blender

Para el proceso de rigging he utilizado Blender. El primer paso es crear una “armature”. Una vez añadidos los huesos el modelo queda así:

He utilizado el sistema de nomenclatura de Unity para este modelo ya que se aproxima bastante a un humanoide.

El siguiente paso ha sido pintar los pesos de la influencia de los huesos en cada parte del cuerpo. La mayoría de objetos solamente es afectada por un hueso así que ha sido un proceso sencillo.

Para simplificar el proceso de animación de la siguiente práctica, he añadido constraints a los huesos para que se comporten de manera lógica.

Por último, para la exportación a Unity, he intentado hacer que las texturas estén dentro del fbx pero me ha sido imposible, al subir el modelo a sketchfab sí que se incluían, para solucionar el problema, dejo las texturas en el Drive y con añadirlas junto al modelo en Unity es suficiente. También he subido el proyecto de Blender.

Robot 2

Proceso de obtención del mapa UV

Con el segundo robot también me ha pasado algo similar:

Este autorigging es bastante peor, ya que no es suficientemente humanoide, la topología es demasiado low polly como para que haga un buen trabajo.

Proceso de generación del rig: Blender

Repitiendo los pasos del primer robot, he creado una armature y he creado los huesos que creía convenientes:

Mi intención es que los brazos y piernas sean muy flexibles, así que he puesto más huesos. Para poder añadirle el avatar de Unity he creado dos huesos que realmente no se utilizan en el modelo (spine y chin). Los nombres de los huesos de brazos y piernas no siguen la convención, pero están nombrados de forma lógica: brazos: b[1-4].[L|R], manos: m[1-4].[L|R], piernas: p[1-3].[L|R].

El proceso de skinning ha sido más complicado en este modelo, el modo automático de Blender no ha sido suficiente y he tenido que modificar las influencias de muchos objetos.

La exportación a Unity ha sido igual que el robot anterior

Comentarios

Mixamo es una muy buena herramienta para hacer auto-rigging y obtener animaciones online, pero, como se ha podido comprobar en esta práctica, no es muy útil con personajes no humanoides o de materiales rígidos. Pero no puedes editar nada en la aplicación, ni ajustar posiciones de huesos, pesos, o rehacer el rig.

Tampoco ayuda que el formato fbx no se comporta de la misma manera en Blender, maya, sketchfab y Unity. Esto es porque no es un formato abierto, es propiedad de Autodesk y solamente comparten el SDK. Unity solamente acepta fbx y collada.

Link a Drive:

• Drive: https://drive.google.com/drive/folders/143j_IHjQiW87DK8mbydg6tpAd9A2_4xn?usp=drive_link

Link a Folio:

• Folio: https://dsanzfu.folio.uoc.edu/2025/11/15/actividad-r3-media/

1. Enlaces de drive:

Drive: Enlace

2. Resumen:

2.1. Proceso para generar el Rig

El procedimiento de la creación del Rig se realizó siguiendo los videos tutoriales proporcionados. Duplique el archivo en maya para tener un backup y procedí a generar los huesos con la herramienta Create Joints, además de apoyarme con la visualización del esqueleto en Unity.

Al generar cada hueso correspondiente y agruparlos en jerarquía, uní los huesos al cuerpo del robot usando Bind Skin.

Para una mejor precisión preferí usar la opción Smooth Skin, para que no se deformara y se apreciara los movimientos como debería de verse en un robot

2.2. Capturas de pantallas

2.3. Comparativa entre los métodos de rigging

Al usar la generación automática de Mixamo el modelo presente algunos errores como en las capturas anteriores, donde el guante del Robot A y el mazo del Robot B se deforma y el mismo cuerpo del robot se siente menos realista, en cambio al generar el rig de forma manual se tuvo mayor libertad y precisión; pero a mayor esfuerzo. Además hubo una dificultad de generar por Mixamo el modelo del Robot B debido a que las articulaciones son pequeñas y no se detectan, teniendo que tomar los puntos un poco antes de la articulación, generando mayor deformación en las extremidades del robot.

Aunque despues intente también combinar ambos primero generar el esqueleto en Maya y posteriormente mandar el archivo a Mixamo para unirlo con animaciones, dando lugar a unas animaciones más acordes al Robot y no deformando los guantes, ni el mazo.

Introducción

El objetivo de esta tarea era crear y aplicar texturas a los modelos 3D de dos robots. Para simplificar la tarea, se ha optado por unas texturas con estilo cómic utilizando colores planos y algunos detalles pero todo pintado a mano.

Mapas UV

Para realizar los ajustes se utilizó la siguiente textura quedando un resultado como el que se puede ver a continuación. Utilizando dicha textura se ajustaron las piezas en el mapa UV cuidando la orientación y la escala. El robot mostrado en la imagen se muestra a mitad del proceso.

Las dos imágenes a continuación representan los mapas UV resultantes con las piezas de los dos robots. Las piezas están organizadas del mismo modo que las piezas en el robot de modo que sean de fácil localización. Además, al utilizar colores planos no se ha realizado el mayor esfuerzo para ocupar todo el espacio ya que no se requiere un gran detalle. Eso sí, esta última decisión podría hacer necesaria una reorganización de los elementos en caso de aplicar alguna textura en alta resolución al modelo para evitar la pérdida de detalle.

Texturas

En las siguientes capturas se encuentran las texturas de los dos robots. Se ha hecho una selección de colores que diferencie los elementos de las extremidades. Se han añadido algunos detalles en la parte frontal entre los que se encuentran la cara imitando una pantalla. Sin ser unas texturas muy detalladas se está bastante satisfecho con el resultado que queda muy en la línea de lo que se esperaba quedando dos robots que podrían ser utilizados perfectamente en un juego con una estética de este tipo.

Mapas de normales

Utilizando Gimp se han sacado los mapas de normales para aplicar algo de textura a los modelos. Ya que no tienen mucho detalle, sobre todo se pueden ver marcas en la cara de los robots, el pecho y las ruedas del robot con ruedas.

Modelos en sketchfab

Los modelos finales están accesibles en los siguientes enlaces a sketchfab

– https://skfb.ly/pCJIW para el robot con una rueda.
– https://skfb.ly/pCJJr para el robot con piernas.

Recursos

• Modelado con Maya 2023
• Texturas editadas con Gimp
• Todas las texturas se han creado a mano. No se han utilizado recursos externos