1. Ejecutable HTML en SIMMER

Este es el link del juego final subido a la plataforma SIMMER en formato HTML5: https://simmer.io/@cagugui/metal-fight

2. Resumen del proyecto

2.1 Resumen y conclusiones

El proyecto, titulado Metal Fight, ha sido una experiencia enriquecedora que me ha permitido aprender paso a paso cada etapa del desarrollo de modelos 3D y su implementación en Unity. Desde la concepción inicial hasta la ejecución final, he tenido la oportunidad de comprender y valorar la cantidad de tiempo, esfuerzo y atención al detalle que requiere cada paso del proceso. Esto incluye la creación de los modelos 3D, el diseño de texturas, la animación y su integración en un motor de videojuegos. Este aprendizaje me ha hecho más consciente de la importancia de organizar cada fase de manera metódica y estructurada, ya que esta planificación es crucial tanto para proyectos independientes como para aquellos desarrollados dentro de una empresa. Entender y seguir un flujo de trabajo claro no solo ayuda a evitar frustraciones, sino que también optimiza el tiempo y garantiza un resultado de mayor calidad.

Uno de los aspectos que más me ha desafiado ha sido el mapeado UV y la texturización de los modelos. Al ser un área que no había explorado antes, me encontré con un aprendizaje bastante complejo. Por otro lado, el aspecto que encontré más accesible fue la fase final, ya que tengo mayor experiencia trabajando con Animator Controllers y la programación asociada. Sin embargo, esta experiencia me ha dejado una conclusión clave: el desarrollo de videojuegos 3D es un proceso extremadamente exigente y laborioso. Incluso cuando se trata de una sola faceta del videojuego, como los modelos 3D, cada una de las cinco etapas principales es lo suficientemente compleja como para requerir años de práctica y estudio.

Es destacable observar que, en un equipo profesional, suele haber especialistas dedicados exclusivamente a cada tarea: modelado, texturización, animación, entre otras. Esto destaca el desafío de llevar a cabo todo este trabajo de forma individual. A pesar de las dificultades, este proyecto me ha dado una visión más clara de lo que implica crear videojuegos 3D y me ha permitido desarrollar habilidades esenciales que aplicaré en futuros proyectos.

2.2 Visión de futuro

Metal Fight es un videojuego que se podría desarrollar en profundidad en un futuro, en el hipotético caso de que se encontrara un equipo de desarrollo. Las adiciones que se realizarían son las siguientes:

• Habrían muchos más robots, entre los cuales los jugadores podrían elegir para luchar con ellos. Cada robot tendría una ventaja y desventaja distinta, como por ejemplo un robot tendría un ataque muy potente pero con una defensa muy débil. Los jugadores se irían desbloqueando en función del nivel del jugador 1, el cual conseguiría subir de nivel jugando contra la máquina u otros jugadores.
• Se podrían jugar de 1 a 4 personas, por lo que cabría la posibilidad de jugar con una inteligencia artificial. Además de esto, se podrían formar equipos de 2. Esta función obligaria al jugador a poser 2 o más mandos para podeer jugar de manera cómoda.
• Habrían más escenarios donde luchar, aunque siempre se lucharía dentro de un ring de boxeo, aunque este estaría persoanlizado para cada escenario.
• Se introduciría una nueva mecánica a partir de combos, que sería la habilidad especial, diferente para cada personaje.
• Otra mecánica nueva que se introduciría tendría que ver con el público, el juagador que mejor esté jugando recibiría regalos del público, como aumentar la vida o objetos especiales para defenderse o atacar.
• Se añadirían distintos modos de batalla:
  • Modo normal, que es el que ya existe
  • Modo torneo similar a juegos clásicos como Street fighter
  • En un límite de tiempo quién recibe menos golpes.
  • Sobrevivir en el ring, que consistiría en echar al otro robot del ring.

2.3 Animator Controllers

Los 2 animator contollers resultates son prácticamente iguales, ya que los 2 robots realizan distintas animaciones pero por los mismos motivos.

En primer lugar, la acción principal por defecto es la del Idle, desde este estado pueden irse a correr, atacar, o defender.  Desde el estado de corrrer se puede volver al Idle, o ir a defender o atacar. Desde el estado de ataque, se vuelve al Idle o a correr, pero no a defender ya que en cuanto el jugador deja de atacar, se volverá al idle si no se está moviendo, o al estado de correr si seguidamente corre. Lo mismo ocurre con el estado de defensa, de aquí se puede volver o al estado por defecto a a correr. El estado de morir se activa desde cualquier estado.

Todas las transiciones entre estados estan controlados por parámetros booleanos o de tipo Trigger. Los booleanos se utilzian para acciones que pueden durar en el tiempo, como Idle, correr o defenderse, ya que el jugador puede mantener la posición de defensa. Los triggers se activan para estados que ocurren solo momentáneamente, como el ataque o la muerte. Cuando se activa la animación de ataque, después de que acabe vuelve al estado que corresponda. Cuando el jugador muere, se activa la animación de muerte mediante el trigger, se esperan 3 segundos para que el jugador asimile que es lo que ha ocurrido y depsués se cambia a la siguiente pantalla.

Las animaciones de Idle y correr se reproducen en bucle, ya que son las únicas que se tienen que reproducir continuamente al encontrarse en su correspondinete estado. Las otras animaciones, al ser la de muerte, el ataque que solo ocurre una vez, y la de defenderse que mantiene el último fotograma de la animación, no necesitan estar en bucle.

Por último, con respecto a Maya, las animaciones se han tenido que acelerar en el inspector del Animator debido a que, a pesar de que en Maya se reproducían a una velocidad adecuada, en Unity se visualizaban con demasiada lentitud.

3. Archivos de terceros

Nombre: Action Fighting Outro
Autor: Emmraan
Procedencia:https://pixabay.com
link: https://pixabay.com/music/rock-action-fighting-outro-230279/
Uso: Música de fondo del juego

Nombre: Game Music
Autor: DeepMusicEveryDay
Procedencia:https://pixabay.com
link: https://pixabay.com/music/video-games-game-music-7408/
Uso: Música de fondo del menu

Nombre: Metal Hit 10
Autor: floraphonic
Procedencia:https://pixabay.com
link: https://pixabay.com/sound-effects/metal-hit-10-193281/
Uso: Efecto de sonido de atacar

Nombre: Metal Hit 95
Autor: floraphonic
Procedencia:https://pixabay.com
link: https://pixabay.com/sound-effects/metal-hit-95-200424/
Uso: Efecto de sonido de atacar y el otro jugador se está escudando

Nombre: Explosion Sound Effect 2
Autor: Cyberwave-Orchestra
Procedencia:https://pixabay.com
link: https://pixabay.com/sound-effects/explosion-sound-effect-2-241820/
Uso: Efecto de sonido del escudo rompiéndose

Nombre: Robot Heavy Mechanical Footsteps
Autor: DavidDumaisAudio
Procedencia:https://pixabay.com
link: https://pixabay.com/sound-effects/robot-heavy-mechanical-footsteps-194039/
Uso: Efecto de sonido del robot 1 al andar

Nombre: 029974_inside the robot
Autor: freesound_community
Procedencia:https://pixabay.com
link: https://pixabay.com/sound-effects/029974-inside-the-robot-70923/
Uso: Efecto de sonido del robot 2 al andar

Nombre: sucked into classroom
Autor: freesound_community
Procedencia:https://pixabay.com
link: https://pixabay.com/sound-effects/sucked-into-classroom-103774/
Uso: Efecto de sonido del robot 1 muriendo

Nombre: Bubbles
Autor: freesound_community
Procedencia:https://pixabay.com
link: https://pixabay.com/sound-effects/bubbles-108320/
Uso: Efecto de sonido del robot 2 muriendo

Nombre: 046559_Crowd cheer.wav
Autor: freesound_community
Procedencia:https://pixabay.com
link: https://pixabay.com/sound-effects/046559-crowd-cheerwav-67948/
Uso: Efecto de aplausos

Nombre: Click Buttons – UI Menu Sound Effects – Button 7
Autor: skyscraper_seven
Procedencia:https://pixabay.com
link: https://pixabay.com/sound-effects/click-buttons-ui-menu-sounds-effects-button-7-203601/
Uso: Botones de la UI entrar

Nombre: Click Buttons – UI Menu Sound Effects – Button 5
Autor: skyscraper_seven
Procedencia:https://pixabay.com
link: https://pixabay.com/sound-effects/click-buttons-ui-menu-sounds-effects-button-5-203601/
Uso: Botones de la UI click

Proceso

La primera etapa del proceso consistió en la creación de bocetos orientativos para las animaciones, en los cuales se definieron los fotogramas iniciales de cada secuencia. Posteriormente, el ritmo y la cantidad de fotogramas entre cada fotograma clave fueron ajustados y adaptados a una velocidad estándar de 60 frames por segundo, comúnmente utilizada en los videojuegos. Estos bocetos evolucionaron a medida que se desarrollaban las animaciones, ya que surgieron oportunidades para mejorar el ritmo de la animación y se identificó la necesidad de incluir fotogramas adicionales. El objetivo era lograr animaciones lo suficientemente orgánicas para transmitir la ilusión de que los robots están vivos, pero sin perder la esencia mecánica que destaca su naturaleza metálica.

En cuanto al robot 1, la animación de Idle simula un patrón de respiración, acompañado de movimientos ocasionales de la cabeza hacia los lados, como si estuviera buscando posibles presencias en su entorno. La animación de correr está diseñada para imitar a una persona, con los brazos hacia atrás, y busca transmitir la impresión de que el robot es pesado y su desplazamiento requiere un esfuerzo considerable. La animación de defensa fue completamente rediseñada debido a limitaciones en el modelo del robot, que impedían un cruce natural de brazos. En su lugar, se optó por un movimiento en el que agita su espada de forma protectora. Por último, la animación de ataque incorpora un uso de los brazos-espada, enfatizando la fuerza y el daño infligido.

Respecto al robot 2, su movimiento se caracteriza principalmente por el uso dinámico de sus brazos, que funcionan como tentáculos, y el pez en su interior, que imita los movimientos de estos. Para evitar que la animación de correr se viera estática, como sugerían los bocetos iniciales, se añadieron oscilaciones hacia adelante y atrás en los brazos, inspiradas en la animación de Idle. La animación de muerte enfatiza la desconexión del robot, con el detalle del pez interior cayendo.

Todas las animaciones de los robots, excepto las de muerte y defensa, comienzan y terminan en el mismo fotograma, permitiendo su reproducción en bucle. Las animaciones de muerte, al reproducirse una sola vez, no requieren un diseño en bucle. En el caso de las animaciones de defensa, el jugador puede mantener el botón de defensa, prolongando el último fotograma de forma indefinida, lo cual elimina la necesidad de un ciclo continuo. Este enfoque asegura que las animaciones sean coherentes con la estética del juego y funcionales en su implementación técnica.

Como referencias para algunas animaciones, como la de correr del robot1, utilicé videos de referencia y utilicé la página syncsketch para visualizar cada fotograma y poder extraer los fotogramas clave e intermedios.

El proceso de animación consistió en grabar los fotogramas clave de cada animación, y modificar las curvas del Graph Editor para suavizar algunos movimientos o eliminar fotogramas de determinadas propiedades del objeto que entorpecían el movimiento deseado.

Cada animación realizada se comprimía en clips haciendo uso de las herramientas del Time Editor, que permite grabar distintas animaciones en distintos clips.

El último paso ha sido colocar las animaciones una detrás de otra en el Time Editor para poder exportarlas con Game Exporter. Este obtiene los clips del Time Editor y selecciona de su fotograma inical al último, realiza el bake y los comprimer en un único archivo FBX para poder importarlo a Unity con los distintos clips.

Problemas encontrados

Un problema que surgió a la hora de animar el primer robot, fue que el controlador IK de las piernas no estaba correctamente finalizado, ya que debía añadir un controlador de la orientación de las rodillas para poder animar bien las piernas.

Además de esto, los problemas afrontados para esta entrega han sido en relación a la inexperiencia a la hora de utilizar el Time Editor, teniendo que repetir algunos pasos reiteradas veces, y del propio prorgama Maya, ya que cuantas más animaciones realizaba y guardaba peor funcionaba el programa, congelándose la pantalla y perdiendo el progeso del archivo en múltiples ocasiones.

Experiencia general

La experiencia de realizar manualmente todas las animaciones ha sido positiva. A diferencia de las animaciones generadas automáticamente a través de herramientas como Mixamo, las animaciones hechas a mano tienen un valor añadido, ya que reflejan un enfoque más personal y único. Este proceso permite que cada movimiento esté completamente alineado con la visión del creador, lo que otorga un nivel de detalle y autenticidad que difícilmente puede lograrse con soluciones automáticas.

Al crear cada animación desde cero, se tiene control total sobre el ritmo, la fluidez y la intención . Este nivel de personalización es clave para dotar de identidad y coherencia a los personajes y a la narrativa del proyecto. Por otro lado, este método implica un esfuerzo considerable, ya que requiere más tiempo, paciencia y atención a los detalles en comparación con el uso de animaciones prefabricadas. Sin embargo, el resultado final compensa el trabajo adicional, pues las animaciones adquieren un carácter distintivo que enriquece tanto el diseño como la experiencia del jugador.

Enlaces SketchFab

Robot1:

https://skfb.ly/psxL6

Robot2:

https://skfb.ly/psxNJ

Videos animaciones finales:

Modelos de 3D FBX

Este es el enlace a los modelos FBX creados, en su versión manual y con mixamo. El robot 2 no se ha podido crear el rig automático por mixamo al no ser humanoide:

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

Proceso de creación del rig

Para ambos robots, el proceso ha sido parecido. Primero se crea todo el esqueleto con cuidado de que quede en el centro de los objetos, posteriormente se orientan todos los huesos de forma correcta y por último se gestiona la influencia de los huesos en los vértices del modelo de manera meticulosa. Para el robot 1 hubo un último paso, al contar con dos piernas humanoides que el robot 2 no tiene, y fue crear un controlador IK para cada pierna para optimizar el futuro proceso de animación. De esta manera al agachar el cuerpo del robot 1, las piernas se flexionan automáticamente y los pies quedan rectos en el suelo.

Esqueletos finales

Unity

Comparativa métodos de rigging

Mi experiencia con Mixamo en relación a estos modelos de robot ha sido positiva en cuanto a su rig automático, siempre y cuando se trate de modelos muy humanoides. Sin embargo, he encontrado limitaciones significativas al trabajar con modelos más complejos.

Por ejemplo, en el caso del robot 2, que tiene una pecera en la cabeza y cuatro brazos, Mixamo no ha logrado reconocer correctamente la geometría. Debido a que este modelo posee cuatro brazos y solo una pierna, la herramienta no pudo procesarlo adecuadamente, por lo que Mixamo no está preparado para manejar esta variedad de morfologías en los modelos.

En cuanto al robot 1, este sí que ha conseguido reconocerlo y ha creado un rig parecido al que he hecho yo manualmente en cuanto a forma. No obstante, al importalo en maya y probarlo he observado que el modelo contaba con una flexibilidad indeseada en sus extremidades, por lo que a pesar de crear automáticamente los huesos y el esqueleto, todavía habría que pulir el modelo para que fuera funcional. Por otro lado, al rig del robot que creé manualmente añadí los controladores IK, los cuales son muy necesarios de cara a sus futuras animaciones. Estos elementos no son creados por Mixamo, por lo que habría que adaptar este esqueleto automático. Además de esto, utilizando este modelo las animaciones prefabricadas que ofrece Mixamo no ean una opción, ya que están preparadas únicamente para modelos muy humanoides. Al tener el nacimiento de las piernas situadas en los laterales del cuerpo, y brazos rígidos con ausencia de codos, las animaciones generaban problemas de flexibilidad innecesaria y atravesamiento de sus extremidades.

En conclusión, en mi experiencia Mixamo (al igual que muchas otras herramientas automáticas) es una muy buena herramienta de generación de rig automático con la condición de que los modelos utilizados sean muy humanoides. El proceso de cración del rig y de la selección adicional de animaciones dura apenas unos minutos, por lo que resulta extremadamente útil y rápido para los animadores. Sin embargo ofrece muy poca flexibilidad al estar automatizada. La creación manual del rig, aun siendo bastante más laboriosa, permite adaptar el esqueleto y las articulaciones a cualquier tipo de personaje indistintamente de su morfología y establecer la rigidez que se desee. En el caso de mis modelos, podría haber partido desde el esqueleto generado automáticamente ahorrándome el primer paso de la generación de los huesos y su orientación. Sin embargo, dado que uno de los robots no lo reconocía y el otro necesitaba bastante más trabajo, no merecía demasiado la pena utilizarlo.