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.

Ejecutable HTML en SIMMER:

Enlace al ejecutable en SIMMER: https://simmer.io/@Autenticorick/robot-fight

Resumen del proyecto:

En este último reto del semestre se buscaba mostrar como los robots diseñados, modelados, riggeados y modelados a lo largo del semestre eran aptos para ser usados en un juego sencillo de Unity.

Importación de los modelos de Maya a Unity:

En primer lugar, exporté los modelos desde maya a Unity. Una vez en Unity, tuve que ajustar ciertos parámetros. En primer lugar, el esqueleto de los robots. En mi caso, ambos eran robots con esqueletos humanoides que, durante el reto 3, ya comprobé que fuesen aceptados por Unity (Imagen 1). En segundo lugar, se dividieron las diferentes animaciones creadas en Maya en el reto anterior en diferentes frames, para diferenciarlas unas de otras (Imagen 2). Por último, se exportaron los materiales y texturas para cada robot (Imagen 3).

Imagen 1

Imagen 2

Imagen 3

Componentes y lógica de los robots:

Tras esto, a cada GameObject de los Robots les añadí diferentes componentes: Animator, Collider, RigidBody, PlayerInput y un script que contiene toda la lógica de control de los mismos (Robot Controller) (Imagen 4). Los controles para cada Robot son los siguientes:

Robot 1: W y S para movimiento, A para atacar y D para defender.

Robot 2: I y K para movimiento, J para atacar y L para defender.

Dentro del script de control, y gracias al componente Player Input, que emplea el nuevo sistema de inputs de Unity, he mapeado cada control a su funcionalidad. Además, al llamar a cada método que ejecuta esta funcionalidad, (moverse, atacar o defender), se ejecutan las animaciones correspondientes. Por otro lado, he añadido colliders como trigger para identificar cuándo un robot está pegando a otro, aplicando así el daño entre robots, haciendo que disminuyan sus puntos de salud de los 10 que tienen. Cuando lleguen a 0, el robot morirá y acabará la partida. Cuando un robot es atacado, recibe 2 puntos de daño, pero cuando es atacado mientras se defiende, recibe 1 punto de daño. Para cada una de estas acciones, existe un sonido asignado, para dar más credibilidad al juego y que el jugador pueda recibir feedback sonoro.

Imagen 4

Máquinas de estado:

Ambos robots tienen máquinas de estado similares. En este, se usa como estado principal el IDLE. En función de las acciones del jugador, se cambiará el estado, ejecutando la animación correspondiente, ya sea mediante booleanos o triggers. Por ejemplo, para caminar o defenderse, se emplea un booleano (isWalking o isDefending), de modo que la animación se ejecutará mientras estos sigan siendo ciertos. Por otro lado, atacar o morir se accionan como triggers, ya que son acciones que sólo realizarán una vez (al atacar, hará la animación 1 vez). Por otro lado, el estado de atacar cuenta con un script dentro del estado, que modifica una variable que se emplea en el script de control, permitiendo saber cuándo está atacando el robot. A continuación, adjunto imágenes de los dos controladores (Imágenes 5 y 6).

Imagen 5

Imagen 6

Sonido, decoración del escenario y menús:

El juego cuenta tanto como con una pista de audio que se ejecuta en bucle a lo largo de la partida, además de diferentes efectos de sonido que dan más sentido y ayudan al jugador a tener un feedback extra. Los efectos de sonido suceden cuando un robot es dañado (un sonido diferente en función de si se está defendiendo o no), cuando lanza un golpe y cuando acaba la partida. Dentro del script principal, se ejecutan los sonidos en los momentos correspondientes (Imagen 7).

Imagen 7

En cuanto a la ambientación, he escogido un escenario más bien sencillo, con estética Sci-Fi ambientada en una nave espacial. Por otro lado, se ha añadido un menú principal sencillo, con la opción de jugar o salir del juego. Los assets utilizados han sido obtenidos de la asset store de Unity.

Visión de futuro para el proyecto:

En caso de llevar adelante el proyecto, contando con un mayor número de desarrolladores, sería interesante desarrollar un juego al estilo Street Fighter, pero con estética Sci-Fi. En primer lugar, añadiría más personajes jugables, de diferentes formas y estilos. Ampliaría el abanico de ataques, habilidades y movimientos, haciéndolo un juego mucho más variado. En cuanto a como se jugaría, me imagino un juego tipo PvP, donde dos jugadores se enfrentan entre sí. También crearía assets tanto de sonido como de escenario propios, dándole un toque único al juego.

Conclusiones:

Para finalizar este reto y la asignatura, querría comentar que, tras modelar, texturizar, riggear, animar y luego ver el resultado final en el juego, puedo comprender más fácilmente el arduo trabajo que llevan a cabo las personas que se dedican a esto profesionalmente. Ya no solo por la complejidad y precisión que se debe tener para hacer modelos, sino por la gran cantidad de tiempo que se debe dedicar a estos.

En un principio no sabía si me iba a entusiasmar la asignatura, pues yo disfruto mucho más otros aspectos de la programación de videojuegos, pero tras esta asignatura valoro mucho más este otro aspecto, que a pesar de llevar muchas horas puede llegar a dar un resultado muy satisfactorio.