En 1993 Capcom se encontraba en condiciones de brindar una secuela de Final Fight, aunque solo para el mercado doméstico (no-arcade). La consola favorecida fue la Super Famicom/SNES, la cual había tenido una versión bastante pobre del juego original (solo un jugador a la vez, un personaje menos y algunos niveles recortados).
Capcom salda la deuda con dicha consola, restaurando el modo de juego cooperativo (2 jugadores), con posibilidad de escoger alguno de estos 3 personajes: Haggar (del Final Fight original), Maki (estudiante de la misma técnica de Guy) y Carlos (estudiante de diferentes artes marciales).
El juego comienza mostrando que ha pasado algún tiempo desde que Haggar, junto a sus amigos Cody y Guy, derrotaron a la banda Mad Gear y devuelto la paz a Metro City. Sin embargo, los miembros sobrevivientes de Mad Gear se han reagrupado en secreto planeando su venganza. Comienzan secuestrando a la novia de Guy, Rena, junto con su padre.
Como a Guy no se le encuentra por ninguna parte, la hermana menor de Rena, Maki le informa a Haggar de la situación. Acompañado por su amigo Carlos, Haggar viaja a Eurasia para encontrarse con Maki, y los tres unen su fuerzas para enfrentar a la nueva Mad Gear.
Final Fight 2 no se desvía mucho de su predecesor, conserva su estilo (ataque y salto) y presenta enemigos algo diferentes pero ajustados a la mecánica del juego. La mayor diferencia está en que, cada uno de los 6 niveles del juego, tienen lugar en algún país de Eurasia en el siguiente orden: Hong Kong, Francia, Holanda, Inglaterra, Italia y Japón.
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.