En primer lugar, para llevar a cabo esta actividad, se exportaron todas las animaciones de ambos robots a Unity, verificando que el rig fuera correcto en cada una de ellas.

Una vez completado este proceso para ambos robots, se procedió a crear el Animator Controller.

Animator controller

Dado que ambos robots comparten los mismos movimientos, sus máquinas de estados son muy similares. A continuación, se incluye una captura de la máquina de estados.

El primer estado es “Idle”, desde el cual se accede al resto de estados. Todos los estados regresan a “Idle”, excepto el estado “Death”, que marca el final de la partida.

Para gestionar las transiciones entre los estados, se han definido parámetros en la máquina de estados. Estos parámetros son:

Los parámetros definidos para la máquina de estados son Walk, Death, Punch y Block. De estos, Death y Punch son de tipo Trigger, ya que solo necesitan activarse una vez. En el caso de Punch, al finalizar la animación, el estado regresa a Idle. Por otro lado, Walk y Block son de tipo Boolean:

• Walk reproduce la animación en bucle, simulando pasos continuos.
• Block mantiene la posición mientras el jugador mantenga presionado el botón de bloqueo.

Para las transiciones entre estados, todas (excepto las relacionadas con Walk) tienen activado el “Exit Time”. Esto permite transiciones más suaves entre animaciones. Sin embargo, en el caso de Walk, no se ha activado “Exit Time” para que, durante el gameplay, el personaje comience a caminar de inmediato al pulsar la tecla correspondiente. A pesar de esto, la transición no es brusca, ya que los movimientos de Walk son pequeños y no muy diferentes del estado Idle.

En cuanto a la animación de muerte de ambos robots, fue necesario incluir un offset en el eje Y. Esto se hizo para evitar que los robots terminaran tumbados en el vacío, lo cual no era deseado.

Elementos del juego

Una vez creados los Animator Controllers de ambos robots, se desarrollaron el resto de elementos del juego. En primer lugar, se construyó un escenario utilizando el siguiente paquete de assets: Paquete.

Con estos assets, se diseñó un mercado en el desierto con un estilo moderno que incluye elementos como cámaras de seguridad y máquinas expendedoras. Además, se añadió una iluminación amarillenta para generar una sensación de calidez en el ambiente.

Posteriormente, se colocó la cámara y se posicionaron los robots enfrentados, simulando una jugabilidad estilo 2D pero con gráficos en 3D.

Para implementar el movimiento de los robots, cada uno tiene un script asociado que controla su componente Character Controller. Adicionalmente, se creó un script común para ambos robots que gestiona su vida y verifica si los golpes impactan contra el enemigo.

Para proporcionar al jugador feedback visual sobre la vida de los robots, se incluyeron dos barras de vida en la interfaz de usuario (UI), una para cada robot. Estas barras disminuyen y cambian de color conforme los robots reciben daño.

Cuando la vida de un robot llega a 0, se cambia automáticamente a una nueva escena.

Después de implementar el gameplay, se diseñó un menú de pausa. Este menú, desactivado por defecto, se activa al presionar la tecla “Esc”. Al activarse, detiene la acción del juego y ofrece las siguientes opciones: reanudar la partida, regresar al menú principal o salir del juego.

Por último, se añadió un cielo utilizando un material de tipo Skybox, completando así la pantalla de gameplay.

Tras finalizar el desarrollo del gameplay, se incorporaron otras escenas:

• Menú principal: consta únicamente de dos botones, uno para jugar y otro para salir.
• Pantalla de fin: al concluir la lucha entre los robots, muestra qué jugador ganó y ofrece la opción de regresar al menú principal.

Finalmente, se añadieron efectos de sonido para enriquecer la experiencia. Cada escena tiene su propia canción, que se reproduce en bucle. Además, se incluyó un sonido de “clic” al interactuar con los botones, y efectos de sonido específicos para los golpes, bloqueos y animaciones de muerte de los robots.

Conclusiones y trabajo futuro

Con esto concluye todo el proceso creativo de la asignatura de Media para Videojuegos. Considero que ha sido muy enriquecedor conocer el proceso completo, desde la concepción del diseño en forma de bocetos para ambos robots hasta verlos en acción dentro de un juego. Durante este recorrido, se han realizado tareas de modelado, texturización, rigging y animación. Aunque el resultado es mejorable debido a la falta de experiencia, estoy seguro de que, si tuviera la oportunidad de empezar desde cero con el conocimiento adquirido durante este proceso, el resultado sería significativamente mejor. Aun así, estoy satisfecho con el aprendizaje obtenido.

Si contara con un equipo, este juego podría expandirse fácilmente. Algunas de las posibles mejoras incluyen:

• Nuevos escenarios para las peleas, lo que añadiría variedad visual y jugable.
• Movimientos adicionales para los robots, haciendo el combate más dinámico y variado.
• Mejorar la interacción entre los robots, ya que actualmente los golpes solo reducen vida sin mostrar una respuesta visual en el otro robot.
• Incorporar más robots, cada uno con características únicas que aporten diversidad al gameplay.
• Mejorar el diseño, modelado y animaciones de los robots, logrando personajes más atractivos y con movimientos más fluidos y naturales.
• Balancear los personajes para asegurar una experiencia justa y competitiva.

En cuanto a las plataformas ideales, considero que este juego, debido a su enfoque multijugador, encaja muy bien en PC, como está actualmente. Es ideal para partidas rápidas con un solo teclado. También sería una gran opción para la Nintendo Switch, ya que esta consola facilita la implementación del multijugador local, lo que la hace especialmente adecuada para este tipo de juegos.

Estoy convencido de que este proyecto tiene un gran potencial y que, con las mejoras mencionadas, podría convertirse en una experiencia de juego aún más completa y divertida.

Enlaces:

El juego se puede ver y jugar en el siguiente enlace:
https://simmer.io/@tortolavivo23/media-r5

1. Desarrollo en las Prácticas de Media para Videojuegos

Durante la asignatura de Media para Videojuegos, participé en distintas prácticas que abarcan aspectos importantes del diseño y desarrollo de contenidos para videojuegos. Cada etapa permitió adquirir conocimientos básicos sobre modelado 3D, texturizado, rigging, animación y la integración de estos elementos en un juego sencillo. A continuación, detallo el progreso realizado en cada una de estas áreas.

a. Modelado 3D

En la primera práctica, aprendí los fundamentos del modelado 3D. Trabajé en la creación de personajes desde su boceto inicial hasta el modelo completo. Aunque los resultados no fueron demasiado complejos, logré entender cómo se construyen formas tridimensionales utilizando herramientas de modelado.

b. Texturas y Mapas de UV

Después de completar los modelos, realicé UV Mapping y creación de texturas. Este proceso consistió en desplegar las superficies del modelo para aplicar texturas. Aunque mis texturas eran sencillas, logré que los modelos tuvieran un aspecto más cercano al diseño original para el videojuego.

c. Rigging

El siguiente paso fue el Rigging, donde añadí esqueletos humanoides básicos a los modelos. Aprendí a colocar huesos y a vincularlos al modelo para que pudieran moverse. Aunque las deformaciones no fueron perfectas, logré que los personajes tuvieran una estructura funcional para realizar animaciones.

d. Animaciones

En cuanto a las animaciones, trabajé en ciclos básicos como caminar y “idle” y acciones como atacar, defender y morir. Aunque los movimientos eran algo rígidos, pude implementar acciones funcionales que daban vida a los personajes.

e. Videojuego de Peleas

Finalmente, integré todo lo aprendido en un juego de peleas sencillo en Unity. Configuré mecánicas básicas como ataques, defensas y detección de colisiones e integré una serie de interfaces para controlar el flujo del juego. Además, añadí sonidos para mejorar la experiencia del juego y aunque no era muy complejo, logré integrar bien mis modelos y animaciones para crear una experiencia funcional.

En general, este recorrido por las prácticas de la asignatura me permitió adquirir conocimientos fundamentales sobre la creación de contenido para videojuegos y aplicar lo aprendido en un proyecto básico.

2. Visión de Futuro

El juego actual, con sus mecánicas básicas de combate y menús funcionales, representa una base sólida para futuras mejoras. Aunque su diseño es sencillo, ofrece un potencial considerable para evolucionar hacia una experiencia más completa y atractiva. A continuación, se presentan algunas ideas de desarrollo futuro que podrían implementarse gradualmente.

1. Mejoras en las Mecánicas de Juego: Ampliar el repertorio de movimientos de los jugadores, como ataques combinados o bloqueos avanzados, añadiría profundidad al sistema de combate.
2. Nuevos Escenarios: Incorporar escenarios variados con elementos visuales y temáticos distintos enriquecería la experiencia de los jugadores. Aunque no interactivos, podrían servir como un cambio estético para mantener el interés en partidas repetidas.
3. Variedad de Personajes: Crear personajes adicionales con diferencias leves en velocidad, fuerza o resistencia, permitiría diversificar las partidas.
4. Polish Visual: Mejorar los efectos visuales de los ataques y las defensas, como destellos o pequeñas explosiones, incrementa la sensación de impacto en los combates.

En conclusión, el proyecto tiene un camino claro hacia la expansión agregando elementos que hagan el juego más dinámico y atractivo. Estas mejoras no sólo enriquecerán la experiencia actual.

3. Descripción del Animator Controller

El Animator Controller diseñado para el personaje en Unity está estructurado en dos capas principales, Movement y AttackDefend, cada una con roles específicos para gestionar las animaciones del personaje de forma modular y eficiente. A continuación, se detalla el funcionamiento de cada capa:

a. Movement

Esta capa controla las animaciones generales del cuerpo completo del personaje relacionadas con su movimiento y estado al ser derrotado.

1) BlendTree – Movement

1. Dentro de la capa Movement, se encuentra un Blend Tree llamado Movement. Este árbol mezcla de manera fluida las animaciones de Idle, Movimiento hacia adelante y Movimiento hacia atrás según el parámetro moveInput.
2. Parámetro moveInput: Este parámetro es de tipo float y representa la dirección e intensidad del movimiento.
   • Cuando moveInput está cerca de 0, el personaje permanece en el estado Idle.
   • Valores positivos de moveInput activan la animación de movimiento hacia adelante.
   • Valores negativos de moveInput activan la animación de movimiento hacia atrás (invertido)
     
     Carregant...

     Actualitza

2) Animación de Derrota

1. En esta misma capa, hay un estado separado para la animación fija del personaje siendo derrotado. Este estado no forma parte del Blend Tree y puede activarse según las condiciones específicas del juego, como la pérdida de vida del personaje.
   
   Carregant...

   Actualitza

   
   

b. AttackDefend

La segunda capa, AttackDefend, controla exclusivamente las animaciones del tronco superior del personaje, permitiendo realizar acciones como atacar o defender sin interrumpir las animaciones de movimiento en la capa inferior.

1. Configuración de la Capa
   La capa está configurada con un Override del tronco superior del personaje, de manera que las animaciones de esta capa sustituyen únicamente las de esa parte del cuerpo, mientras que las piernas y el movimiento continúan siendo controlados por la capa Movement.
2. Estados y Transiciones
   1. Estado Idle: Es el estado base de la capa, donde el tronco superior permanece inactivo hasta que se recibe una acción.
   2. Triggers:
      1. Attack: Al activarse este trigger, el estado cambia de Idle a la animación de ataque.
      2. Defend: De manera similar, este trigger cambia el estado de Idle a la animación de defensa.
   3. Tras completarse cada animación (ataque o defensa), el estado regresa automáticamente a Idle.

Este diseño del Animator Controller permite un control claro y eficiente de las animaciones. La capa Movement gestiona los aspectos básicos del desplazamiento y los estados principales, mientras que la capa Attack Defend asegura que las acciones de ataque o defensa no interrumpan la continuidad del movimiento, creando una experiencia visual fluida y coherente para el jugador.

4. Enlace al Juego

En el siguiente enlace encontrareis un enlace a una pagina en la que se encuentra la build del juego para Windows con acceso público, la Build generada para Web no se ejecutaba correctamente debido a las limitaciones de los juegos Web, asi que he decidido hacer una version para PC (Windows):

Animal Robots’ Brawl

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.

Introducción al juego de pelea Robotic Fighters

Después de realizar las anteriores prácticas, he aprendido a modelar mis robots en 3D con Maya, texturizarlos, darles color y detalles, realizar su rigging y, finalmente, animarlos con diferentes secuencias como ataque, idle, muerte, movimiento y defensa. En esta última práctica, he creado una breve demostración de lo que sería un juego de lucha llamado Robotic Fighters, utilizando todos los elementos creados durante estas prácticas, es decir, tanto los robots como sus animaciones.

Cabe mencionar que ya tenía bastante experiencia previa con el programa Unity, tanto en 2D como en 3D, por lo que la implementación de un juego en dicho programa no me planteaba un reto extremadamente complicado a priori, pero sí desafiante y atractivo, ya que nunca había realizado un juego de lucha ni nada parecido.

Creación del entorno del juego, cámaras y personajes

Lo primero que realicé en Unity fue importar los assets que iba a utilizar como escenario para el juego. En la Unity Store conseguí unos assets muy adecuados para mi juego, con unos escenarios futuristas y decadentes, perfectos para el estilo visual de mis personajes, alejados del estilo cartoon y más orientados a una estética futurista y sombría.

Así, creé una escena en la que arrastré diferentes assets para poco a poco ir formando el escenario, lleno de contenedores, bunkers y coches destruidos, lo que le da un toque de abandono y desolación al mundo del juego. Una vez que conseguí el resultado deseado, importé mis personajes de Maya: Robotydus y Archie. Los coloqué mirándose uno al otro con una distancia determinada y les apliqué a cada uno dos componentes: un Box Collider y un Rigidbody.

Hice lo mismo con el suelo, añadiendo un Collider para que los personajes se mantuvieran de pie al iniciar el juego. Para finalizar los preparativos, creé una cámara estática que enfocara a los dos personajes, colocando uno a la derecha y el otro a la izquierda. También añadí un Collider invisible detrás de cada robot para delimitar el espacio en el que se moverían durante el combate. Así conseguí preparar el entorno de mi juego de lucha y dejarlo listo para comenzar a implementar las funcionalidades jugables.

Lo primero que implementé en el juego Robotic Fighters fue el escenario mediante un Asset gratuito descargado desde la Unity Asset Store llamado RPG_FPS_Industrial Game.

Una vez creado el escenario implementé una cámara que enfocara a ambos robots en posición lateral mirándose el uno al otro.

Creación de las animaciones y el movimiento en cada robot

Este fue uno de los pasos más largos, aunque no el más difícil. Lo primero que hice fue crear un Animator para cada personaje y añadir allí los 5 clips de cada animación. Como ya había creado los clips en el proyecto anterior, pude acortar mucho trabajo.

Lo más desafiante fue crear las transiciones y conexiones entre cada animación, siendo Idle la animación central a la que derivaban todas las demás animaciones como muerte, movimiento, defensa y ataque. Para controlar estas animaciones, creé triggers como ataque, muerte y defensa, y un booleano para calcular la velocidad y activar la animación de movimiento.

Todo esto lo conecté con cada robot mediante un script llamado PlayerMovement. En este script, hice que, con el input de las teclas deseadas, se activara un trigger determinado. Además, al mover el robot, se modificaba el booleano del Animator para reproducir la animación de movimiento. Tuve que realizar algunos ajustes en la configuración del Animator para conseguir el resultado deseado en cuanto a los tiempos y las velocidades de las animaciones.

Todas las animaciones son controladas desde el Animator de cada robot. Cada animación cuenta con su propio trigger de activación y una transición con la animación siguiente.

HUD, menú y pausa

Una vez realizado el movimiento de los robots, me puse a crear las interfaces y los menús del juego, tanto el principal como el de pausa. Para ello, creé un Canvas en el que añadí tres paneles: el de la vida de los robots, el del menú de pausa y el del menú principal.

Para las vidas, creé un Slider para cada robot y ajusté algunos parámetros para conseguir el color y estilo visual deseado. Para los menús, importé un asset de UI Sci-Fi, que era muy acorde al estilo del juego. Creé dos paneles sencillos, cada uno con sus opciones. En el menú principal tenemos la opción de empezar el juego o salir. En el menú de pausa, las opciones son reiniciar el juego, continuar o salir.

Para configurar estos menús, creé un script con variables públicas para cada panel. La idea es que, al iniciar el juego, se muestra el menú principal, pero no se inicia el juego hasta que el jugador pulse los botones (a los que asigné métodos públicos). Al pulsar el botón Start, el movimiento de los robots y el juego en sí se inician. Con el botón Exit, se sale del juego. Durante la partida, si se pulsa la tecla espacio, el juego se pausa, y si se vuelve a pulsar, se retoma (con un margen de 1 segundo). En la pausa, podemos reiniciar, retomar el juego o salir.

Menú principal de juego y menú final que aparece cuando uno de los robots derrota al otro, y se muestra su nombre como el vencedor del combate.

Sistema de juego

El sistema de juego de Robotic Fighters está diseñado para ofrecer una experiencia fluida y dinámica en el combate entre los robots. Cada personaje comienza con 100 puntos de vida, representados visualmente mediante barras en el HUD. Cada golpe acertado por parte de un robot reduce la vida del oponente en 10 puntos, añadiendo un componente estratégico a los ataques y defensas.

El sistema de combate se basa en colisiones, habilitadas mediante colliders asignados a los modelos de los robots. Estos colliders permiten detectar los golpes en tiempo real. La gestión de los golpes se realiza a través de un script llamado AttackManager, que coordina los estados de ataque y defensa de ambos robots.

Cuando un robot ejecuta un ataque, su collider entra en trigger con el del oponente. El AttackManager verifica dos condiciones importantes:

1. El robot atacante debe estar en estado de ataque, definido mediante un booleano en el script PlayerMovement.
2. El robot oponente no debe estar en estado de defensa, lo cual también se controla mediante un booleano.

Si ambas condiciones se cumplen, el AttackManager llama a la función TakeDamage del script LifeManager. Este último es responsable de reducir la variable de vida del robot impactado y actualizar en tiempo real su barra de vida en el HUD.

Cada robot tiene un collider y un script llamado AttackManager que gestionan el impacto entre los robots. Cuando un robot ataca y el otro no está defendiendo, el AttackManager activa la función TakeDamage, lo que reduce la vida del robot afectado en 10 puntos y actualiza la barra de vida correspondiente.

Cuando se reinicia el juego, el LifeManager restablece todas las variables de vida a su estado inicial (100 puntos). Este proceso asegura que las barras de vida se reinicien adecuadamente al comenzar una nueva ronda.

En cuanto a la sonorización, el juego está completamente sonorizado: desde los movimientos de los robots hasta los botones de la interfaz de usuario. Estos sonidos se reproducen a través de Audio Sources, y son gestionados desde el script PlayerMovement, que controla la reproducción de los efectos de sonido durante las interacciones y acciones en el juego.

Script RobotFightController, que gestiona la mayoria de funciones del juego, como las animaciones de los personajes y sus movimientos, el reinicio del juego, el menú de pausa…

Script AttackController que gestiona el ataque de cada personaje al entrar en contacto con el otro y llama al método deseado del script LifeManager para reducir la vida del robot enemigo.

Script LifeManager, que gestiona la inicialización de las barras de vida de cada robot ( empezando con 100 en cada partida ) y la reducción de dichas barras cada vez que un robot golpea al otro.

Conclusiones y puntos de mejora

Así pues, ha sido un proceso muy dinámico y enriquecedor. Más que encontrarme con obstáculos o picos de dificultad, he tenido que dedicar bastante tiempo a planificar y complementar los elementos jugables, así como a asegurarme de que los aspectos visuales se alinearan con el estilo del juego. Estoy contento con el resultado, aunque soy consciente de que las animaciones podrían estar más pulidas y tener un timing más acertado.

Como puntos de mejora, me gustaría que, si en un futuro el juego tuviera más recursos y tiempo de desarrollo, se pudieran añadir más robots y escenarios para enriquecer la experiencia. Además, sería interesante incorporar un ataque especial para cada robot, con animaciones únicas que le den un toque más distintivo a cada uno. También me gustaría mejorar cada animación, tanto en términos de fluidez como de timing para que las transiciones entre ellas se perciban más naturales y realistas.

En resumen, este proyecto me ha permitido aprender y aplicar diversos conocimientos en modelado 3D, animación, programación en Unity y diseño de interfaces, lo cual me ha proporcionado una base sólida para futuros proyectos en el desarrollo de videojuegos.

Recursos Utilizados

A continuación, se detalla la lista de recursos utilizados en el desarrollo de Robotic Fighters, con sus respectivos enlaces:

• Sonidos de combate para cada robot:
  Smacks & Scuffles Pack 1
• Música de fondo:
  Free Sci-Fi Music Collection
• Escenario y assets de decoración:
  RPG/FPS Game Assets for PC/Mobile – Industrial Set v3.0
• UI, menús y HUD:
  UI Samples

Controles del juego

Controles para Archie V 1.34

• Avanzar: Letra D
• Retroceder: Letra A
• Atacar: Letra F
• Defenderse: Letra R

Controles para Robotydus

• Avanzar: Letra L
• Retroceder: Letra J
• Atacar: Letra H
• Defenderse: Letra Y

Controles comunes

• Pausar el juego: Tecla Espacio. Al pulsarla, el juego se detiene, y al volver a pulsarla, el juego se reanuda con un margen de 1 segundo.

Enlace al juego en Simmer.io:

https://simmer.io/@daniTydus/fighting-robots

Plataforma de subida

He elegido la plataforma Itch.io porque ya tengo algunos proyectos publicados allí y me gustaría seguir ampliando mi portfolio subiendo más trabajos en el futuro.

Link del juego:  ich io 

Link escrito: https://samknightgames.itch.io/fruit-fighter

1. Resumen del proyecto y conclusiones de todas las entregas.

El proyecto consistió en crear una maqueta jugable de un juego de peleas, recorriendo todos los procesos creativos involucrados en su desarrollo. A continuación, se describen las etapas clave y las conclusiones de cada una de ellas:

1.1 Bocetos y Modelado de los Robots

La primera etapa del proyecto fue diseñar y modelar ambos robots. Este paso fue uno de los más desafiantes debido a las limitaciones de tiempo, ya que era crucial crear modelos que definieran la identidad visual del proyecto. Durante esta fase, reflexioné sobre cómo atacarían y se defenderían los robots, incluso considerando las animaciones que cada uno realizaría.
Además, tuve el reto adicional de volver a familiarizarme con Blender después de varios años sin usarlo, pero retomarlo fue una experiencia gratificante.

1.2 Texturizado de los Modelos

En esta etapa, trabajamos en texturizar cada robot. Fue fundamental planificar cuidadosamente los cortes de las texturas para asegurarnos de que todas las partes encajaran y reflejaran la personalidad e intención original de cada diseño. Este proceso añadió una capa importante de detalle y coherencia visual al proyecto.

1.3 Rigging de los Robots

El rigging de los modelos se realizó manualmente, ya que las opciones automáticas, como Mixamo, solo funcionaron parcialmente. Aunque el rig automático ofrecía ideas interesantes, no se alineaba con la personalidad que quería transmitir en los robots. Por ello, opté por un rig manual, que me permitió mayor control y flexibilidad para adaptar cada esqueleto a la visión específica que quería transmitir.

1.4 Creación de Animaciones

Las animaciones se diseñaron teniendo en cuenta aspectos clave como la distancia de ataque de los robots, asegurando un combate equilibrado en esta etapa inicial. Este enfoque también deja margen para futuras iteraciones, donde se podrían incluir robots con diferentes rangos de ataque y movilidad para diversificar las mecánicas de juego.

1.5 Montaje en Unity

Finalmente, integramos todos los elementos en Unity. Esta fase incluyó:

Programación de Scripts: Desarrollo de un sistema de control para los robots y un sistema básico de daño.

Creación del Escenario: Diseño del entorno utilizando ProBuilder.

Interfaz y Estilo Final: Implementación de una pantalla inicial y la aplicación de postprocesado en la cámara para otorgarle un acabado más profesional.

Cada uno de estos apartados se desglosará más adelante para explicar los detalles de su implementación.

2. Visión de futuro para este proyecto. Imaginando que contáis con un equipo que puede llevarlo a cabo.

La actualización de contenido que añadiría al proyecto sería:

2.1 Customización de los robots

Una de las principales características a añadir sería un sistema de personalización para los robots. Este permitiría cambiar ciertas partes de su estructura, otorgando puntos de customización que modificarían las estadísticas y habilidades de los personajes, como por ejemplo, Cambiar un brazo por uno con mayor poder de ataque pero menor alcance o Sustituir las piernas por unas que aumenten la velocidad del robot a costa de reducir su capacidad defensiva.

Estas modificaciones no solo añadirían profundidad estratégica al juego, sino que también permitirían a los jugadores crear robots más personalizados, adaptándose a su estilo de combate preferido y haciendo que las batallas sean más variadas y dinámicas.

2.2 Nuevos escenarios

Otra mejora clave sería la incorporación de nuevos escenarios que introduzcan elementos interactivos para los jugadores. Inspirándome en juegos como Super Smash Bros, estos escenarios podrían incluir plataformas móviles, zonas destructibles…etc. La idea es agregar elementos que otorguen ventajas o desventajas dependiendo de cómo los jugadores los aprovechen.

Este enfoque haría que cada combate no solo dependiera de las habilidades y estrategias de los jugadores, sino también de su capacidad para adaptarse al entorno.

2.3 Plataformas posibles

El juego podría lanzarse en Steam y contar con la incorporación de un modo multijugador online. Esto permitiría implementar un sistema de ranking en el que la posición de los jugadores se actualice automáticamente en función de las victorias y derrotas obtenidas en las partidas. Aunque también podrían explorarse otras plataformas como la Switch.

3. Capturas de pantalla de vuestros Animator controllers y las explicaciones correspondientes de las decisiones tomadas.

3.1 Animator Controller y configuración de las animaciones.

Idle: Es la animación predeterminada que se reproduce cuando el robot no realiza ninguna acción. Permanece activa hasta que se detecta un cambio, como el inicio de un movimiento o una acción específica.

Walking: Se activa cuando se detecta movimiento. Además, se implementó un sistema de flip para que el personaje gire adecuadamente dependiendo de la dirección. La transición de la animación se controla mediante un bool.

Ataque y defensa: Estas animaciones pueden activarse desde cualquier estado, asegurando que el robot responda inmediatamente al input de ataque o defensa sin importar lo que esté haciendo. Durante estas acciones, el robot permanece inmóvil. Estas animaciones se activan mediante Triggers.

Muerte: Cuando el robot llega a 0 de vida, se activa la animación de muerte, el robot derrotado queda inmóvil. En este punto, aparece una pantalla de Game Over con opciones para volver al menú principal o reiniciar el combate. La animación se activa mediante un trigger.

3.2 Sistema de combate.

El feedback es fundamental para que el jugador sienta el impacto de sus acciones. Para ello, he implementado:

Indicadores Visuales: Color verde intermitente cuando un robot bloquea correctamente un ataque y otro de color rojo cuando recibe daño.

Sonidos Diferenciados: Cada robot tiene efectos de sonido específicos tanto para los golpes como para el daño recibido, lo que mejora la inmersión y facilita identificar las acciones durante el combate.

Ajustes en el sistema de Ataque y defensa: Se realizaron mejoras para que la orientación de los robots sea relevante en el momento de defender. Esto garantiza que el bloqueo solo sea efectivo si el robot está correctamente orientado hacia el ataque enemigo.

3.3 Creación de escenario.

El escenario se diseñó utilizando ProBuilder y se texturizó siguiendo el mismo estilo visual que los robots para mantener la coherencia estética. La ambientación es una fábrica minimalista, que aporta un entorno atractivo y funcional para el combate.

Además, se añadieron partículas para dar mayor profundidad al escenario, mejorando la atmósfera.

El juego incluye dos pantallas principales. En la primera, se mostrará un botón central para iniciar el juego y, en la esquina inferior izquierda, un botón adicional que permitirá visualizar los controles de ambos jugadores. Además hay un tema para el menú y otro para dentro del juego que es una variación de este. También el botón tiene un sonido de cuando se va a los controles y otro cuando vuelve al menú principal.

3.4 Recursos utilizados.

Tanto la música, efectos de sonidos y gráficos han sido creados por mi, menos la tipografía usada en el proyecto.

Reflexión final

Resumen del proyecto y explicación

Juego en simmer.io

En esta entrega he desarrollado un pequeño juego de peleas ambientado en un evento de wrestling. Para ello, el escenario se asemeja a un estadio lleno de personas donde los asistentes pueden ver a los luchadores tanto subidos al ring como en tiempo real en las pantallas del evento y desde diferentes ángulos.

Para el desarrollo, he empezado implementando un movimiento básico con el componente Character Controller, ya que para este tipo de juego (o por lo menos con mecánicas tan simples) no son necesarias las físicas. Una vez hecho esto, el siguiente paso fue organizar el Animator.

En el diagrama, creé un estado por cada una de las animaciones que hice en la entrega anterior. Siendo el estado base la animación “idle”, esta tiene transición tanto de entrada como de salida con el estado “walk”, ya que es manejado por un parámetro de tipo booleano que cambia de estado según si el personaje se está moviendo o no. El resto de animaciones, como son acciones instantáneas y que no se mantienen, están enlazadas con el estado “any state” de forma que en cualquier estado puede transicionar a “attack”, “kill” o “defend” al triggerear cualquiera de las variables correspondientes.

Esto lleva a un problema, ya que lo esperado es que pueda atacar o defenderse mientras está parado o andando, pero teniendo la transición en “any state” también puede hacerlo a mitad de ataque o defensa, cosa que no se quiere. Para solucionarlo y desde el código, se han implementado estados en los personajes de los que entra y sale al principio y fin de cada animación.

Para el manejo de los estados, se hizo uso de los eventos en las animaciones. Con una función ya preparada en el script del personaje que prepara la entrada y salida del estado PlayerState. De esta forma, antes de lanzar cualquier otra acción, se comprobará si el jugador no está ya en otra para no interrumpirla.

Con estos mismos eventos, pero con otra función, también se detecta la colisión del ataque de un jugador contra el otro, lanzando un evento que detecta la colisión en X frame de la animación.

Conclusiones de las entregas

Crear los assets para el juego y sus animaciones ha sido un proceso nuevo para mi que me ha hecho tener curiosidad y ganas de aprender nuevas técnicas y crear nuevos assets para los próximos proyectos que haga. Aunque por otro lado me ha costado entender trabajos como el rigging y el pintado de pesos y como estos repercuten en el modelo, otros aspectos como el modelado en sí y el despliegue y pintado de UVs ha sido bastante divertido, ya que podía plasmar directamente mis ideas. Y para esta última entrega, como ya tenía experiencia con Unity y en el desarrollo de proyectos, el proceso ha sido básicamente juntar lo viejo conocido con lo nuevo, creando algo con lo que estoy bastante satisfecho.

Visión de futuro

En el caso de encontrar un equipo de arte más extenso, que no consistiera en mi, y ayuda en el desarrollo, se podrían abarcar las siguiente mejoras:

• Sistema de combos que no estuviera limitado a atacar y defenderse, consistiendo en combinaciones de ataques ligeros y pesados como pasa en otros juegos de peleas.
• Modularización de los robots, creando previamente al combate una pantalla que dejase elegir de 3-4 partes básicas del robot (torso, brazo izquierdo y derecho y tipo de piernas) otorgando estadísticas en base a las partes elegidas y sus sinergias.
• Nuevos escenarios en los que pelear
• Mejor diseño sonoro, donde los sonidos tengan coherencia entre sí.
• Creación de modo contra la IA y otro online, los cuales llevarían bastante tiempo.

Recursos utilizados

Assets

Interfaz:
https://www.kenney.nl/assets/ui-pack-sci-fi

Música y sonidos

Música juego:
https://freesound.org/people/levelclearer/sounds/346200/

Sonido de gente animando:
https://freesound.org/people/ken788/sounds/386762/

Sonido ataque:
https://freesound.org/people/Riley_Garinger/sounds/726620/

Sonido defensa:
https://freesound.org/people/kyles/sounds/452620/

Sonido fin de ronda
https://freesound.org/people/BennettFilmTeacher/sounds/523788/

Sonido movimiento robot derecha:
https://freesound.org/people/ChrisGrundlingh/sounds/765635/

Sonido movimiento robot izquierda
https://freesound.org/people/craigsmith/sounds/675727/

Introducció

En aquest curs, s’ha vist pas per pas com construir un model 3D de dos robots i s’ha creat desde zero les seves animacions corresponents (a tenir en compte: atac, defensa, moviment, mort i estàtic). En aquesta última entrega es desenvouparà un joc de lluites incorporant aquests elements.

Joc pujat al drive: https://drive.google.com/file/d/1-3Y7mxidDEZgoWxsRzLo29FpTkHCK-fn/view?usp=drive_link

Correccions en les animacions

Els primers problemes van venir en exportar les animacions a Unity ja que el motor gràfic necessita d’unes certes correcions per funcionar tal com es veu a Maya. A continuació, s’enumeren les difcultats trobades en aquest apartat

-Problema amb el rig del peu: Desafortunadament, es va obsevar que, al importar l’animació del robot 2 (el blanc) a Unity, el peu esquerre no estava correctament conectat a seu òs superior (en aquest cas lower leg). Això provocava que Unity no llegís bé l’estructura òssea i no pogués desenvolupar un rig humanoide correcte. Es va decidir tornar a Maya, desencaixar el peu i tornar-ho a connectar. Això provoca que aquest peu, si un es fixa molt, faci un moviment diferent del seu parell però no s’aprecia gaire. En la següent figura, s’observa com quedava el peu al desencaixar-lo.

-Posició del robot 1 en l’animació: Un altre problema que va sorgir durant els primers compassos va ser que Unity interpretava incorrectament la posició incial de l’animació, produint un gir de casi 45 graus (provocant que el robot ataqués en diagonal en comptes de recte). Això es va solucionar canviant l’0pció de Root Transforn Rotation de l’animació a Original en comptes de Body Orientation.

En les següents figures s’aprecia el canvi d’orientació. La figura dreta és la correcta.

-Problema típic del model movent-se cap adalt: Per últim, un problema comú que va sorgir va ser que el model, una vegada exportat, es movia cap adalt. Això es va corregir, canviant l’opció a Center of Mass en el Root Transfrom Position (Y).

Controlador d’animacions

El controlador d’animacions pels dos robots va acabar sent de la següent manera:

L’animació d’entrada es l’anomenada Idle (repòs) i per tant, només encendre el programa els robots aniran cap aquest estat. Des d’aquí hi ha un paràmetre float, anomenat Run, que incialment es zero però que quan els robots es moguin variará. Aquest paràmetre controlarà l’animació Movement i l’activarà quan Run sigui diferent a zero i la desactivarà quan torni al seu valor original.

Per les animacions Block, Death i Attack s’ha decidit que s’activin des de Any State per poder fer els canvis d’animació instantàneament sense passar per Idle. Els paràmetres són de tipus Trigger i, quan s’apreta la tecla corresponent, s’activa l’estat especificat. Per impedir que les animacions es superposin, es controla la duració de les animacions mitjançant codi de la següent manera:

El mètode GetCurrentAnimatorStateInfo() permet comprobar si l’animació entre cometes está activa o no. Si una animació está activa no es permetrá començar d’altres. El mètode Block() no té aquesta restricció (intencionalment) per permetre bloquejar de forma ràpida, interrumpent altres animacions si es necessari. El mètode Death(), inclou la destrucció del codi i per tant no pot ser interrumput.

A mode d’exemple s’incorpora el mètode Attack():

On es pot veure que s’invoca a un mètode (amb Invoke) que provocará l’activació del Collider de l’espasa per tal de controlar quan els cops d’un robot impacten contra l’altre. Com que les animacions que es van exportar eren ReadOnly (no es va poder fer d’una altra manera) no es va poder utilitzar l’Animation de Unity per tal d’especificar en quin moment de l’animació acitvar el Collider dels cops. Alternativament, es va mesurar el temps en el que l’espasa estava recta i es va escruire en el codi, directament, en quin moment passava això. Tambés es pot veure en el codi que es para el so del moviment del robot i s’activa el so de l’espasa.

Elements de Gameplay afegits

Aquí s’enumeren elements de joc que s’han pogut afegir

-S’ha pogut realitzar un menu inicial, que permet començar nova partida i sortir del programa.

-S’ha implementat una barra de vida i es té en compte que els cops bloquejats no resten vida. Quan la vidda arriba a zero, el robot mor i surt un menú on s’indica quin robot ha guanyat, un botó per tornar a jugar i un botó per sortir.

-L’espasa emet soroll a l’atacar. També hi ha so pels cops bloquejats i els cops que resten vida. El robot emet so quan es mou i també hi ha música de fons.

Valoració de futur

Assets

Els assets de tercers utilitzats són els següents:

So:

RibhavAgrawal Pixabay (block)

Mixkit.co (hit and sword sound)

jeussfl2009 (backgorund)

DavidDumaisAudio (robot steps)

Models 3D:

Media para Videojuegos

Resumen del proyecto

Con el transcurso de la asignatura he realizado unos bocetos y diseño final de dos robots humanoides, he modelado los robots, los he texturizado, los he riggeado, los he animado y por último los he implementado en un pequeño juego que aún siendo muy simple se puede apreciar el trabajo realizado durante la asignatura.

La primera entrega; la que consistía en hacer los bocetos y modelar los robots ha sido un poco apresurada para mi gusto. Yo soy principalmente modelador, no uno especialmente bueno pero si le dedico mucho tiempo. Pierdo tiempo haciendo detalles para luego deshacerlos por exceso de polígonos, por optimizar la malla hasta puntos un poco enfermizos, rehacer la base del modelo, crear variantes que me convenza más y un largo etcétera. Soy muy perfeccionista en ese aspecto, tanto que muchas veces ni acabo modelos por frustración y luego empiezo otro. Es un ciclo vicioso en el que por cada cuatro modelos que empiezo con suerte acabo uno y luego ni siquiera me gusta su acabado porque considero que podría ser mejor, ya sea en la textura o en la malla.

Para la segunda entrega he presentado a los robots texturizados. Con las texturas me pasa algo parecido al modelo, soy algo obsesivo pero sin llegar al punto que el modelado Las texturas podría ser mejores pero me considero relativamente satisfecho en ese aspecto

Para la tercera entrega he riggeado los robots. Honestamente no hay mucho que contar. Los robots se han diseñado especialmente para que no haya partes de la malla que se doblen. Las rodillas y los codos son esferas por ejemplo. De esta manera simplifica muchísimo el rigeo.

Para la cuarta entrega tenía que realizar las animaciones. Repetiré lo mismo que dije en la entrega anterior; son muy mejorables y podrían ser más vistosas pero son funcionales y dan el pego más o menos. Con más tiempo podría haber pulido mucho más la animaciones e incluso crear algunas más como la de recibir daño, un par de ataques extras y una animación de victoria.

Visión de futuro

Con un equipo más extenso se podría hacer más personajes/robots, más ataques, habilidades y combos con sus respectivas animaciones, más escenarios. El código fuente se tendrá que pulir ya que algunos scripts son un poco código espagueti y en general se tendría que rehacer todo lo que es la interfaz por una más original y personalizada.

Animators

Primero he tenido que ajustar los tiempos en cada animación. Algo que pasaba era que las animaciones duraban más de lo que debían. Por ejemplo; si una animación ocurre entre el frame 30 y el 60 Unity lo exportaba como que duraba del 0 al 60. Esto hacía que durante el frame 0 hasta el 30 el personaje estaba totalmente quieto pero del 30 al 60 ejecutaba la animación.

El animator lo he diseñado de tal manera que se aplique una animación dependiendo del estado en el que se encuentre el personaje. El personaje puede estar:

1. Caminando hacia delante.
2. Caminando hacia atrás
3. Atacando
4. Bloqueando
5. Muerto

En caso de que no esté en ninguno de los 6 estados anteriores, se aplica la animación de reposo, o idle. Para evitar errores en las animaciones, el personaje solo puede tener un estado. Si el personaje está atacando no puede interrumpir o realizar otra acción hasta que su ataque finalice. El único estado que le impide volver al idle es el estado de muerte. Para evitar las mezclas he puesto todos los parámetros de transiciones y Exit Time en 0.

Para la animación de caminar hacia atrás, he cogido la de caminar normal y he puesto el “speed” en negativo para que se realice la animación en reversa.

Sonidos

Se han añadido varios sonidos:

1. Efecto de sonido para los golpes cuando reciben daño
2. Efecto de sonido para los golpes cuando son bloqueados
3. Efecto de sonido para cuando el usuario coloca el ratón encima de un botón (selección)
4. Efecto de sonido cuando se aprieta un botón
5. Una música para el menú principal
6. Una música para el nivel de la pelea

Se han implementado mediante Audio Source y se ejecutan mediante codigo con Scripts. Los unicos sonidos que se ejecutan automaticamente sin código y se repiten en bucle es la música.

UI

Se ha implementado una UI, tanto para el juego como el menú principal.

1. Barras de vida para cada robot
2. Un menu de pausa que detiene el juego y permite volver al menú principal.
3. Una pantalla final que permite salir del juego o repetir el nivel/pelea
4. Un menú principal que permite entrar al nivel, ver los controles o salir.
5. Un menú de controles que da información acerca de los comandos para controlar a cada personaje.

Recursos externos utilizados

Para implementar un escenario, sonidos y una UI he utilizado recursos de terceros.

Unity Asset Store

Sci-fi GUI skins: https://assetstore.unity.com/packages/2d/gui/sci-fi-gui-skin-15606

Game Input Controller Icons Free: https://assetstore.unity.com/packages/2d/gui/icons/game-input-controller-icons-free-285953

Low Poly street Pack: https://assetstore.unity.com/packages/3d/environments/urban/low-poly-street-pack-67475

AllSky Free – 10 Sky / Skybox Set: https://assetstore.unity.com/packages/2d/textures-materials/sky/allsky-free-10-sky-skybox-set-146014

Free deadly Kombat: https://assetstore.unity.com/packages/2d/gui/icons/game-input-controller-icons-free-285953

Sonidos extras:

Click botón: https://freesound.org/people/bubaproducer/sounds/107130/

Selección botón: https://freesound.org/people/Thunderman98/sounds/656180/

Música

Menu: Jack Wall – Adrenaline (Black Ops 2 Multiplayer Theme)

Juego: Baki OST – Confrontation

Juego

ANTES DE JUGAR! Recomiendo jugar con la pantalla maximizada.

Actualización:La tecla P también sirve para pausar la partida. (Esc o P para pausa)

Link: https://simmer.io/@PauGallego/pec5paugallego