Habíamos visto anteriormente que en ocasiones, en nuestro juego debemos manejar una gran cantidad de acciones y animaciones para los personajes.
¿Cómo podemos manejar dicha información?
En uno de mis proyectos, los personajes cuentan con varias acciones, animaciones y además utilizan 2 cajas de colisiones (una de vulnerabilidad y otra de ataque).
De forma similar a como vimos en Street Fighter 2, se utilizan variables que registran la siguiente información:
SI: Slot de la secuencia donde inicia la acción.
SR: Slot donde se repite la secuencia de la acción.
SF: Slot de la secuencia donde finaliza la acción.
La información se toma de la siguiente tabla:
Cada slot contiene la siguiente información:
ID Fot.: ID del fotograma de la hoja de sprites.
Int.: intervalos de tiempo de juego que la frame de la animación se va a mostrar antes de avanzar a la siguiente frame.
CXV: coordenada horizontal del centro de la caja de vulnerabilidad.
CYV: coordenada vertical del centro de la caja de vulnerabilidad.
RXV: radio horizontal de la caja de vulnerabilidad.
RYV: radio vertical de la caja de vulnerabilidad.
CXA: coordenada horizontal del centro de la caja de ataque.
CYA: coordenada vertical del centro de la caja de ataque.
RXA: radio horizontal de la caja de ataque.
RYA: radio vertical de la caja de ataque.
La información se toma de la siguiente tabla:
La hoja de sprites es similar a esta:
Ahora, a modo de ejemplo, examinemos cuadro a cuadro la acción de ataque:
La acción de atacar establece el slot inicial en 40. El slot 40 establece que el ID del fotograma de la hoja de sprites que será presentado es el 26. En la figura podemos apreciar el fotograma 26 que da inicio a la animación. Observamos según la tabla que, entre cada fotograma hay 6 intervalos de tiempo antes de pasar al fotograma siguiente, excepto en el último fotograma cuya duración es de 12 intervalos. Además, el último fotograma se repite si no se pasa a otra acción. En ese caso, se debe establecer que al llegar a la conclusión del slot e intervalo, se pase a la acción siguiente (por ej: parado). También, podemos ver que en la imagen se ha marcado con una cruz blanca la coordenada de referencia donde se va a imprimir el sprite, mientras que la cruz roja indica el centro de la caja de ataque.
Veamos más de cerca:
Según la tabla de slots, vemos que en el primer fotograma se nulifica (es decir, que todos los valores son iguales a cero) la caja de vulnerabilidad. Esto se hizo con el propósito de que el balón no golpee accidentalmente el personaje al ejecutar el ataque. También, vemos que el centro de la caja de ataque se establece a 4 pixeles horizontales de las coordenadas de referencia del sprite y a 52 pixeles verticales (rectángulo verde). Por otro lado, vemos el radio horizontal y vertical establecido en 27 y 18 pixeles respectivamente (rectángulo purpura).
Obviamente, este sistema se puede optimizar, por ejemplo, quitando de la tabla de slots la información de las cajas de colisión y estableciendo una tercer tabla que guarde dicha información asociándola a un ID (como vimos en Street Fighter 2).
Ahora, un video con los resultados:
En una entrada anterior habíamos mencionado algo sobre cómo animar un objeto a partir de una línea de tiempo, emulando algo similar a la línea de tiempo que ofrece Adobe Flash habíamos establecido una variable matriz en la cual se asignaba a cada elemento (equivalente a un intervalo de tiempo de juego), el número de frame/fotograma de la hoja de sprites que debe imprimirse en ese instante de la secuencia.
El método es útil para algunas secuencias de frames y animaciones pequeñas, pero ¿qué ocurre si tenemos una gran cantidad de acciones con animaciones extensas?
Existe otro método que podemos utilizar, de hecho el método que veremos a continuación nos permite manejar otros datos de la animación que nos serán de gran utilidad al momento de programar las interacciones entre los objetos del juego.
Anteriormente se analizaba las colisiones en 2D, se mencionó el modo de prueba de objetos del Street Fighter 2.
Extendiendo un poco la información ya presentada, podemos destacar los parámetros siguientes:
CHRCTR: El número de intervalos de tiempo de juego que la frame de la animación se va a mostrar antes de avanzar a la siguiente frame.
CHRDIR: Dirección actual del personaje, 00 = mirando a la izquierda, 01 = mirando a la derecha.
(Sinetiqueta,debajodeCHRDIR): ID actual de secuencia de animación.
HEAD: ID de caja de vulnerabilidad Cabeza para la frame de animación actual.
BODY: ID de caja de vulnerabilidad Cuerpo para la frame de animación actual.
FOOT: ID de caja de vulnerabilidad Piernas para la frame de animación actual.
WEAK: ID de caja de punto Débil para la frame de animación actual.
ATCK: ID de caja de Ataque para la frame de animación actual.
BODY1: ID de caja de presión para la frame de animación actual.
KAGE: ID de sombra de fondo para la frame de animación actual.
PRIO: Prioridad del sprite para la frame de animación actual.
CATCH: ID de Agarre para la frame de animación actual. Determina la posición y desplazamiento del sprite del oponente para cuando está agarrado por una técnica de lanzamiento. Parece haber una para cada personaje, por ejemplo, cada personaje tiene su propia selección de sprite y posición de desplazamiento para reaccionar a una frame de Ryu con un valor de Agarre de 01, etc.
BLOCK: Bandera de bloqueo para la frame de animación actual. 00 = no bloquea, 01 = bloquea de pie, 02 = bloquea de rodillas.
WeakNo: Efecto extra para aplicar si la caja de punto Débil es tocada durante la frame de animación actual. 00 = nada, 02 = daño doble.
SIT: Bandera de Agacharse para la frame de animación actual 00 = de pie, 01 = agachado.
OBJSUU: Número de tiles de la frame de animación actual.
DX: Desplazamiento en X para la hitbox mostrada actualmente.
DY: Desplazamiento en Y para la hitbox mostrada actualmente.
SX: Radio en X para la hitbox mostrada actualmente.
SY: Radio en Y para la hitbox mostrada actualmente.
ATCKDNo.: Tabla de daño para la caja de Ataque de la frame de animación actual.
SDCODE: Sonido que inicia cuando se toca la caja de Ataque de la frame de animación actual.
ATCKEX.: Tipo de ataque para la caja de Ataque de la frame de animación actual. 00 = estándar con base en el suelo normal, 01 = barrido, 02 = salto normal, 03 = movimiento especial (causa poco daño durante bloqueo), 04 = normal con propiedades especiales (derribar, etc.).
ADJUST1.: Tabla de daño adicional al azar para la caja de Ataque de la frame de animación actual cuando la vitalidad es 3C o superior.
ADJUST2.: Tabla de daño adicional al azar para la caja de Ataque de la frame de animación actual cuando la vitalidad es 3B o inferior.
EXCode: Efecto en el golpe para la caja de Ataque de la frame de animación actual si ATCK EX = 03 o 04.
Tal vez no necesitemos utilizar todos estos datos para nuestro proyecto, pero pueden servirnos de base. Un proyecto propio utiliza tan solo 2 cajas de colisiones (una de vulnerabilidad y otra de ataque).
¿De que forma se pueden manejar esos datos?
La respuesta se dará en la siguiente parte.
Sistemas:
2016 – Windows, PS3, PS4, Wii U, Xbox One
El polémico Mighty No. 9, es un videojuego de acción-plataformas desarrollado por Comcept. Es el resultado de una campaña en Kickstarter impulsada por Keiji Inafune, quien fue parte del staff de Rockman/Megaman en Capcom.
En la descripción del proyecto, Inafune menciona estar asociado con desarrolladores veteranos de dicho staff. Partiendo de esta base es imposible no comparar Mighty No. 9 con Rockman/Megaman, dado que contiene muchos de los mismos elementos, temas y estilos. Está claro que la intención de Inafune era crear un sucesor espiritual de ese título.
Haciendo un paréntesis en el análisis de Mighty No. 9, vale mencionar algunos datos sobre Keiji Inafune:
Usaba el nombre "INAFKING" en los créditos finales de varios juegos.
Además, aunque lo llaman “el padre de Megaman”, él mismo ha mencionado que su diseño ya estaba creado cuando se unió a Capcom. Akira Kitamura, director del Megaman original había creado el sprite pixel art estático. Esto era para asegurarse de que el sprite se podía ver adecuadamente en los fondos del juego, y así poder comenzar a trabajar en el desarrollo del mismo. Después de eso, el pixel art fue entregado a Inafune, quien creó una ilustración refinada del personaje. Inafune se refiere a este proceso como un "diseño de personajes a la inversa", ya que es lo contrario de lo que normalmente ocurre, donde los artistas crean arte conceptual que luego se traduce en los gráficos del juego.
Podríamos decir que el trabajo de Inafune en un comienzo fue, pasar de esto:
A esto:
Volviendo a Mighty No.9, este proyecto era muy esperado desde que se anunció, pero las largas demoras, sumado a la financiación de proyectos en paralelo, habían comenzado a crear un ambiente de incertidumbre sobre el resultado final. Cuando finalmente fue lanzado, recibió una recepción mixta. Los gráficos, el diseño, contenido, calidad de voces, y los problemas técnicos del videojuego fueron muy criticados, la mayor parte de los jugadores coincidieron en que el videojuego no pudo cumplir las expectativas.
Mighty No. 9 es protagonizado por un robot androide llamado Beck, la novena unidad de un conjunto de robots de combate llamados Mighty Numbers. En algún momento, un virus de computadora ataca al resto de sus compañeros, así como otras máquinas en todo el mundo. El jugador, controlando a Beck, debe enfrentar la contingencia y descubrir al villano final que amenaza el futuro del planeta.
La jugabilidad en Mighty No. 9 se enfoca en plataformas 2D con gráficos en 3D. El jugador cuenta con tres acciones principales: salto, embestida y disparo. No se trata tan solo de eliminar enemigos con el disparo. Es necesario saber cuántos impactos necesitará cada enemigo para debilitarlo y luego poder ejecutar la absorción de Xel. Esto es, una habilidad que nos permitirá realizar combos que, a medida que vayamos aumentando su número, recibiremos potenciadores temporales.
El desafío del juego está en poder realizar el 100% de absorción de Xel de cada enemigo, luego realizar el movimiento de embestida (llamado AcXelerar) lo más rápido posible tras debilitar al enemigo. Si lo hacemos al instante, obtendremos un 100% de absorción de Xel y un punto para el contador de combo. Si tardamos unas milésimas de segundo más, bajaremos el porcentaje y perderemos el combo.
Además, cada enemigo nos puede dar potenciadores de AcXel en base al tipo de robot que hayamos absorbido, como por ejemplo: mejorar temporalmente el daño de los disparos (icono rojo), moverse más rápido (icono verde), aguantar más impactos (icono amarillo) o recuperar vida (icono azul).
El juego contiene una escena de introducción seguida de 8 escenas principales, mismas que el jugador puede escoger libremente en qué orden jugar. Al final de cada escena, Beck, el protagonista, debe enfrentar a alguno de los restantes ocho robots Mighty Number, quienes actúan como jefes de escenario. Luego de estas escenas, se desbloquean las escenas finales.
El cuerpo de Beck tiene la habilidad de transformarse en distintas formas, dependiendo del robot Mighty Number que haya derrotado. Estas nuevas formas se llaman Mighty Skills, y le darán al jugador nuevas habilidades y formas de enfrentar los niveles. Por ejemplo, alguna habilidad podría permitir a Beck crear brazos magnéticos que le permitan escalar estructuras o destruir escudos enemigos, mientras que otra podría permitirle convertirse en un tanque para pasar fácilmente sobre áreas cubiertas con picos y mover ciertos objetos. En este sentido, va más allá de sencillamente copiar el arma del enemigo (y un simple cambio de color en el aspecto) como ocurre en Rockman/Megaman.
Otro aspecto interesante es que al derrotar un jefe, este te ayuda en alguna otra escena eliminando enemigos o quitando obstáculos. Para saber en qué nivel te pueden ayudar, debes seleccionar la opción adicional “consejo” de la escena, el robot que te dé la advertencia será el que te ayude.
Además de estos detalles, en términos generales, el juego cuenta con varios desafíos y modos a desbloquear.
En conclusión, si tomamos este juego en forma independiente, tan solo es un juego de plataformas regular, que presenta un buen desafío y entretiene. Lamentablemente, no podemos dejar de tomar como referencia dos puntos:
En primer lugar, el apartado gráfico es muy malo en comparación con la propuesta inicial. Si observamos el arte conceptual inicial, se ve interesante. Incluso en la demo presentada con 7 días de desarrollo se veía aceptable.
Pero al trasladar todo ese arte a un 3D de baja calidad, pierde muchísimo.
En segundo lugar, si lo tomamos como sucesor espiritual de la saga Rockman/Megaman, la realidad es que dista mucho de serlo. La falta de carisma, personalidad, historia y desarrollo del juego, hace que solo se le parezca un poco en su estilo.
(El verdadero estilo Rockman/Megaman)
Esto, junto al apartado gráfico, posiblemente sea algo mejorable a futuro si hubiera una secuela.
