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.

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/

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

Hola a todos!!!

1. Introducción:

Lo primero que quiero comentar es que tuve muchos problemas de rendimiento a la hora de publicar en  WebGL, el videojuego funciona al completo, pero se ve ralentizado y me he visto obligado a configurar el Shader para alcanzar un menor peso sacrificando mejoras como el Outline de los personajes, al inicio de esta entrada estará la versión de como corre una Build del videojuego para ordenador.

Aquí adjunto el link del videojuego en  itch.io:

https://tortmac1.itch.io/bestias-del-metal

Aquí adjunto el link del videojuego en SIMMER:

https://simmer.io/@tortmac/bestias-del-metal

Algo que agregue a esta versión WEB fue el menú de pausa, se activa con clicar sobre el botón de pausa en el centro superior de la pantalla, esto algo que leí en los criterios de entrega y no fue ningún problema dedicar algo de tiempo a configurarlo.

Este proyecto consiste en un prototipo de videojuego de peleas, intenté crear la mayoría de Assets de manera manual, sin embargo para algunos detalles de audio y el botón de pausa necesite de assets externos de los cuales daré crédito mas abajo, con esto podemos empezar una descripción resumida del proceso para crear este prototipo.

2. Resumen del proyecto

2.1. Menu Principal:

Quería crear un menú sencillo para centrarme en el Gameplay del prototipo, se dispone la los botones para empezar una partida o salir del videojuego, la disposición del menú intente que fuera similar a la de los últimos videojuegos de Dear or Alive (considerando esto como un prototipo) ,estéticamente decidí hacer varios render de la robot conejo hasta encontrar uno que me gustara para el menú principal, también incluí un pequeño Script para el movimiento del fondo.

2.2. Gameplay:

2.2.1. Fondo y Camara:

Lo primero que considere para esta escena, es el funcionamiento del fondo,  y la cámara, en los videojuegos de pelea es común que la cámara se centre en la distancia entre los dos personajes y sea capaz de desplazarse con ellos, a la vez que pueda acercarse y alejarse a la vez que lo hacen los personajes, el fondo lo cree usando la IA de DALLE-3, ya ha estado presente en otras entregas, pero esta vez se ajusta a la cámara y al nivel del suelo. Para funcionar la Cámara es controlada por otro GameObject  usando un Script para hacer zoom, moverse y seguir a los jugadores, los cuales en medio de ellos tienen un objeto invisible que me sirve como objetivo para la cámara.

2.2.2. Iluminación:

En cuanto a la iluminación, solo modifique un poco la luz direccional y la configuración del Shader ya la tengo desde la entrega anterior, por lo que esta parte no tuvo muchos cambios.

2.2.3. Sistema de combate:

Esto sería fácilmente lo mas complejo del prototipo, así que describiré de forma general como funciona el combate en el videojuego y como fueron desarrolladas:

Lo primero que hice fue pensar como interactuarían las animaciones en el Animator, empezando con una comprobación de cada una.

Aunque ambos personajes usan diferentes Animator, las conexiones y parámetros de activación son los mismos, incluso los nombres. Los personajes pueden estar inactivos, caminando, defendiendo, atacando, recibiendo daño o muriendo, teniendo en cuenta estos estados se pueden determinar mas cosas como por ejemplo que un personaje puede recibir daño o incluso morir en cualquier momento del combate, esto se debe reflejar en el Animator y las condiciones de activación en los Scripts de los personajes.

Teniendo en en cuenta esta lógica, organice a los personajes con sus respectivos Colliers y físicas para poder recibir daño y desplazarse al ser golpeados, pero para lograr crear “golpes” tenía que estudiar como funciona un impacto en un juego de peleas al menos a nivel básico .

Encontré que puedo usar GameObjects con colisiones que se activen exclusivamente al impactar con un ataque, luego a nivel del Script se podría determinar si esta ataque fue “bloqueado” o “recibido”,  si tuviera varios ataques a diferentes partes del cuerpo, podría usar mas Colliders para controlar sus rangos, sin embargo para el prototipo solo tengo un ataque.

Los propios estados de cada personaje deben tener efecto en el control del jugador, por ejemplo si estas recibiendo daño, no podrás mover a tu personaje mientras se ejecuta la animación de recibir daño,  y al realizar un ataque, no se considera que has atacado hasta que la animación llega a su punto de “golpear” que son unos pocos Frames dentro de la animación, la mejor manera de controlar esto es usar eventos en la animación que permitan ejecutar funciones dentro del script del personaje, fue algo que me costo entender, pero el resultado marca una diferencia y permite controlar con mucha precisión lo que pasa mientras se ejecuta una animación.

Para dar algo de feedback al jugador, cuando se lanza un ataque y este impacta contra el oponente, se sueltan partículas rojas desde su punto de impacto, cuando el ataque es bloqueado sucede lo mismo pero con partículas de color blanco, esta es una forma simple de indicar al jugador fuera de las barras de vida.

En el prototipo las barras de vida funcionan como en la mayoría de juegos de pelea, al recibir un ataque, si el personaje es golpeado pierde una proporción de su vida haciendo que el slider de la barra se desplace, actualmente pierden un aproximado de una quinta parte de su vida por cada golpe,  todo esto se controla desde el propio script del personaje, a nivel estético quería que se viera llamativo así que hice renders cómo foto de perfil de los personajes y use la fuente de Terminator que originalmente se uso en Dear or Alive 2 para que se viera mas moderno, la elección de colores fue por esta misma razón.

Cuando un jugador golpea a otro y disminuye su vida a 0, se lanza una pantalla de victoria con el personaje ganador en su animación de Idle y un fondo de victoria creado por IA, en este menú se dispone de botones para iniciar otra partida o volver al menú principal, el texto también cambia según el jugador ganador,  esto se controla desde un GameObject con el script de Game Manager.

2.2.4. Sistema de Sonido:

Durante todo el juego disponemos de sonidos de terceros (créditos al final), que permiten dar vida a los personajes, música de fondo para el combate y para el menú principal, entre otros, la música es un apartado muy importante en los videojuegos, también las voces de los personajes, por eso considere importante agregar esto, los sonidos de fondo normalmente los asigno a la cámara, y los de personajes se encuentran dentro de ellos mismos, así puedo usarlos desde su script fácilmente.

2.3 Animator Controller:

Los Animator de los personajes los he explicado anteriormente en el sistema de combate, son muy similares entre sí porque en este caso busco que ambos jugadores tengan las mismas opciones, cuando el personaje se encuentre  inactivo, caminando, defendiendo, atacando, recibiendo daño o muriendo, los parámetros son de suma importancia para activar los estados de animación desde el script de los personajes, como un dato adicional, he realizado pruebas con transiciones de animación y al parecer en los juegos de pelea es común que no hayan transiciones o sean muy bruscas para favorecer el tiempo de respuesta del jugador, en este caso decidí no usar transiciones de salida por este motivo, de por si las animaciones de mis personajes son lentas y están funcionando a 30 FPS en vez de los 24 originales porque se sienten mas fluidas, he realizado algunas modificaciones en la velocidad de las mismas para que el combate se sienta mas fluido.

Robot Coneja:

Robot Tiburona:

3. Conclusiones:

• Esta asignatura fue sin duda la que mas disfrute este semestre, me encanta el arte en los videojuegos, incluso el como se relaciona con la parte mas técnica de estos, esta practica consistió mas en programación y diseño de videojuegos, pero es justo esa variedad la que nos enseña lo útil que es lo que hemos aprendido, no se trata solo de crear un personaje, si no de como usarlo y integrarlo en un videojuego correctamente, por esto esta ultima practica es tan importante.
• Me gustaría que tuviéramos una segunda asignatura de Multimedia para cubrir mas temas como el Parallax en videojuegos, optimización de nuestro arte, los famosos LOD en videojuegos, realmente creo que el tiempo en relación con lo aprendido es excelente, pero sin duda es una asignatura que merece una segunda parte.
• Considero que como siempre, el limite de lo que aprenda cada estudiante dependerá de su empeño y cuanto quiera expandirse en los caminos que enseña el profesor, en mi caso siento que justo necesitaba entender mas de esta parte técnica de Unity, para sacar partido a futuros trabajos, estoy muy agradecido y contento con el progreso en las entregas, es algo realmente lindo cuando puedes ver tu avance y como cada una de las entregas fue una pieza mas de este rompecabezas que hoy podemos llamar prototipo de juego de peleas.

4. Visión de futuro para este proyecto:

• Quisiera contar con un programador con experiencia en Gameplay de combates, seguramente crear un sistema de combos, rondas y dar lugar a nuevas dinámicas entre personajes, sería algo ideal.
• Me gustaría contar con un equipo para desarrollar mas personas, con mas personalidad, nuevas facciones, algo que adoro de videojuegos como Guilty Gear, es el mimo con el que se trabaja cada personaje,  de cierta forma logre algo con este prototipo, pero realmente quisiera aprender mas sobre animación de personajes y como se consigue un nivel como ese.
• Me gustaría crear un selector de personajes para los combates, donde al elegir a cada uno de ellos, tenga su animación propia de selección.
• Escenarios con zonas rompibles como los usados en Dear or Alive, poder romper a tu enemigo contra una pared, o ver como se va callendo el techo del escenario mientras peleas, son esa clase de detalles los que marcan una diferencia entre un simple fondo y un escenario de combate.
• Desarrollar una IA para combatir contra ella con diferentes modos de dificultad, esto también seria útil para el modo historia del videojuego.
• Teniendo varios personajes en varias facciones, sería genial crear un modo campaña para que los jugadores puedan conocer la historia de cada uno de estos particulares robots.
• Teniendo poco presupuesto la historia podría desarrollarse como una novela visual entre las peleas que vaya contando la historia, sin duda seria mas viable para un videojuego Indie.
• Creo que podría escribir todo el día sobre ideas a futuro, pero por ultimo quería decir que pese a ser un prototipo, realmente creo que podría salir un videojuego de peleas divertido a futuro, me gustaría darle una vuela mas cuando deba pensar en mi TFM, pero si alguien me lo preguntara, yo creo que es una buena idea, que vale la pena pulir y representar algún día.

5. Creditos:

Fuente de texto:

https://www.dafont.com/terminator.font?text=DEAD+OR+ALIVE+2&psize=s

Música y sonidos:

https://www.dillonbecker.com

https://es.fiverr.com/davidkbd

Iconos:

https://assetstore.unity.com/packages/2d/gui/icons/modern-rpg-free-icons-pack-264706

6. Anexo:

Como considero muy interesante el Script de control del personaje lo pondré aquí por si alguien tiene curiosidad:

Muchas gracias por leer hasta el final !!!