Documento explicativo R5 MPV

Resumen del proyecto

El proyecto se ha subido a SIMMER en la URL: https://simmer.io/@ddaher/r5-media-para-videojuegos

Controles:

• Robot1:
  • WASD para el movimiento en 3D
  • F para atacar y R para defenderse
• Robot2:
  • IJKL para el movimiento en 3D
  • H para atacar e Y para defenderse

El proyecto en UNITY consiste en 2 escenas, una de menú principal y otra de la zona de mapa con los robots donde se produce el gameplay.

Se han creado varios scripts para implementar las mecánicas del juego. Script para que la cámara siga siempre a los 2 personajes y nunca se salgan de su visión, scripts de control de los menús y scrips de control del personaje.

Se ha implementado un menú de pausa que permite, mediante la tecla de ESC, pausar la partida, reiniciar o salir. Si se pulsa ESC de nuevo, se vuelve al juego.

Se ha implementado un sistema de vidas:

• Cada robot cuenta con 3 vidas, son representadas visualmente mediante la interfaz
• Cuando un robot ataca al otro, y el otro no se defiende, el que recibe el golpe pierde 1 vida.
• Al llegar a 0 vidas, dicho robot pierde la partida. Al finalizar, sale un mensaje de victoria con el robot que gana la partida, se puede volver a empezar el gameplay o salir.

Las animaciones utilizadas para la partida se han exportado de maya y se ha adaptado su velocidad en UNITY, de cada clip, según fuera necesario para que el gameplay fuera fluido. Los clips son creados y tratados con las herramientas de unity, se han creado de tal forma de que puedan reproducirse en bucle (idle/walk por ejemplo) sin realizar movimientos bruscos. Los movimientos de atacar o defender, también se realizan de forma que no se vean saltos bruscos en los cambios de animaciones.

Se han añadido varios efectos sonoros al juego. Un audiosource con música de fondo, y efectos de sonido para atacar/defender/morir.

Animator controller

El animator controller de los 2 robots sigue la misma estructura. Un árbol de animaciones, hechas en maya en la entrega anterior, que transicionan entre sí dependiendo de unos parámetros del animator.

Para permitir que desde cualquier estado el robot pueda caminar, defenderse o atacar, se crean transiciones desde el Any State hacia las distintas animaciones en función del cambio de los parámetros. 

Estos valores se modifican mediante código, desde el script de control principal “CharacterRobotController”. Si se ejecuta el trigger Attack o Defend, el personaje atacará o se defenderá, si Speed es mayor que cierto valor el personaje caminará. 

El caso de la animación de muerte es un poco distinto, ya que si muere, no podrá transicionar a ninguna otra animación ya que al terminar la animación de muerte se destruirá mediante código el controlador del personaje. 

Para las transiciones, mientras el personaje está ejecutando la animación de muerte, también se tiene en cuenta que este estado no esté activo como condición. 

A nivel de código, las animaciones se controlan mediante corrutinas llamadas según el gameplay del juego. Por ejemplo del combate:

También tenemos en cuenta de si un robot se está defendiendo, entonces no recibirá daño del otro robot:

Visión de futuro

Para poder desarrollar este juego en algo más formal y con un equipo, estos son los puntos sobre los que evolucionaría:

• Mayor cantidad de personajes/robots
• Personalización de robots, estética
• Habilidades especiales características de cada personaje, con sus animaciones correspondientes. Set de habilidades base a todos los personajes y luego las especiales.
• Mejora del entorno, distintos mapas/localizaciones. Me lo podría imaginar como algo similar a los juegos tradicionales de Dragon Ball, distintos mapas en que los personajes puedan pelear.
• Sistemas de vidas, escudo, maná más complejos. Que solo se pueda defender X veces en un tiempo determinado y que luego haya que esperar a que se recupere el escudo. Maná para las habilidades.
• Lo plantearía como un juego de peleas, 1vs1. Tendría sentido que estuviera disponible en consolas portátiles, incluso móviles. Habría que configurar los controles para mando, y táctiles si fuera necesario.

Materiales de terceros y derechos audiovisuales

Los robots, las animaciones y los sprites de la interfaz son desarrollados por mí @ddaher (Daniel Daher Pérez)

La música de fondo y efectos sonoros, se han descargados de https://pixabay.com/ y son de libre uso.

Para la entrega del reto R3 se han creado los esqueletos necesarios de los 2 robots resultantes del reto R2.

Pueden descargarse los robots.fbx en (drive compartido para la UOC): https://drive.google.com/drive/folders/19Eea0Z8B2gwiH8Tfq5uzE9X_aMmxDQR2?usp=sharing

Con el objetivo de dotar de capacidad de movimiento a los robots creados, se ha utilizado Maya para la creación de los esqueletos.

Siguiendo los tutoriales del aula, se han creado los esqueletos satisfactoriamente:

Se han tenido en cuenta el número y tipología de huesos necesario para una figura humanoide en Unity.

Para evitar la distorsión, producida por defecto, del resto de partes cercanas del cuerpo (al fusionar el skeleton y la skin), se ha decidido utilizar la técnica del peso de vértices en el menú de componentes. Esta forma me pareció mucho más “segura” y “controlable”, así podemos asegurarnos qué movimiento influye en qué pieza con un 100% de certeza.

Una vez creados los esqueletos, fusionado la skin y el skeleton, confirmado las dependencias de movimiento, se llevaron los .fbx de los robots a Unity para confirmar su funcionalidad correcta:

Teniendo en cuenta la jerarquía de los huesos, y los nombres para el mapeo automático en Unity, se ve que la exportación es satisfactoria a primera vista.

El siguiente paso fue confirmar la falta de distorsión con movimientos de distintas partes de los robots:

Como se aprecia en las imágenes, los movimientos son correctos y no causan distorsión alguna en otras partes del robot.

Mixamo y autorigger

Mixamo es una plataforma web que te permite realizar un autoriggin de los personajes humanoides que subas. En los casos de mi robot, ninguno de los 2 robots fueron aceptados por Mixamo en su plataforma, incluso probando con sus distintas opciones de configuración en relación a las manos. Razones posibles:

• Falta de articulaciones o proporciones incorrectas. Se han hecho con forma bípeda y recordando a la humanoide, pero seguramente no fue suficiente para la herramienta automática de autorigger de mixamo.

Limitaciones de la herramienta:

• Está clara. La limitación a una estructura clara y predeterminada, que es la que se asemeja con un ser humano.
• Las herramientas automáticas estarán muy bien como manera de ahorrar tiempo, siempre y cuando se utilicen en su campo específico (como puede ser el caso de seres humanos y mixamo). Cuando sales un poco de ese molde, algo muy común en un entorno directamente relacionado con la imaginación como es el desarrollo de videojuegos, es necesario el desarrollo manual de estas características.