RonaldGames – Blog

Título: Shinobi

Sistemas:

1987 – Arcade, Amiga, Amstrad CPC, Atari ST, Commodore 64, NES, ZX Spectrum
1988 – Sega Master System
1989 – PC Engine
2009 – Playstation 3, Wii (arcade), Xbox 360 (arcade)

Es un juego de plataformas side-scrolling en el cual el jugador asume el papel de Joe Musashi, un ninja Shinobi, que debe abrirse camino a través de 5 duras misiones -compuestas por entre 3 y 5 etapas- en su búsqueda para rescatar a los niños ninja del clan Iga secuestrados, rehenes de un sindicato ninja del mal llamado “Zeed”. Para completar una misión, el jugador deberá rescatar a todos los niños secuestrados en cada nivel, cuyo número aparece en un medidor ubicado en la esquina inferior izquierda de la pantalla.

Al comienzo de cada misión, se le muestra al jugador su objetivo, seguido de un archivo que contiene una fotografía del jefe enemigo y un mapa señalando la ubicación de la siguiente etapa. El ninja Shinobi comienza cada nivel armado, ya sea con “Shuriken” (estrellas ninja) o un arma para ataques de largo alcance, y una katana para combate a corta distancia. Además, el ninja tiene por nivel un ‘ataque mágico’, una bomba inteligente que elimina o daña a todos los enemigos en pantalla.

Se otorga una bonificación cada vez que un nivel es completado sin utilizar el ataque mágico. Un jefe al final del nivel espera al jugador al final de cada misión, y cada uno tiene varios golpes antes de ser derrotado. Una vez que esto sucede, el jugador es llevado a una etapa de bonus en la que un gran número de ninjas tratará de saltar de la parte posterior del escenario al frente para atacar al jugador. Una vida extra se otorga si el jugador se las arregla para acabar con todos los ninjas sin ser atacado.

Shinobi fue un gran éxito para Sega, y con razón. Su mezcla perfectamente realizada de plataformas y acción, exige del jugador precisión en sus movimientos y memorización de cada obstáculo en cada nivel. Es un fino exponente de la ética de juego “fácil de entender, difícil de dominar”, imprescindible en todo buen video-juego de la época.

En un post anterior había 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, de hecho tanto en el Baschet como en The Ultra Fighters se utilizó esa técnica.

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 en un post que 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:

• CHR CTR: 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.
• CHR DIR: Dirección actual del personaje, 00 = mirando a la izquierda, 01 = mirando a la derecha.
• (Sin etiqueta, debajo de CHR DIR): 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.
• Weak No: 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.
• OBJ SUU: 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.
• ATCK DNo.: Tabla de daño para la caja de Ataque de la frame de animación actual.
• SD CODE: Sonido que inicia cuando se toca la caja de Ataque de la frame de animación actual.
• ATCK EX.: Tipo de ataque para la caja de Aaque de la frame de animación actual. 00 = estandar 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.
• EX Code: 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. Actualmente, estoy desarrollando un juego que 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.

Primera generación de consolas (1972-1977)

La primera consola de videojuegos fue la Magnavox Odyssey, de la mano de Ralph Baer basándose en su anterior prototipo Brown Box y su patente de concepto de video-juego. Tenía dos mandos, un mando en forma de arma de fuego y dieciséis interruptores en la consola que permitían seleccionar distintos juegos. Fue construida usando una combinación de circuito analógico (para el control del juego y la salida) y digitales. No contenía ninguna unidad central de procesamiento o memoria de acceso aleatorio. La máquina se componía de transistores, resistencias y condensadores. Dado su reducido hardware, carecían de sonido y los jugadores debían memorizar sus puntuaciones. En ocasiones eran necesarios algunos dispositivos adicionales para poder ejecutar determinados videojuegos de la plataforma. Sus juegos (veintiocho títulos diferentes en total) eran de una sencillez extrema: ping-pong, “tenis de mesa”, voleibol, etc.

Sin embargo, no fue un gran éxito debido a que fue vendida solamente en los almacenes de Magnavox, diciendo además a los clientes que la Odyssey trabajaría solamente en televisores de su marca. Una mentira que contribuyó a la cantidad de unidades vendidas.
Aún así, la Odyssey generó un caso severo de la “locura de Pong”, y compañías por todo el mundo comenzaron a desarrollar sus propias máquinas copiando la idea de Baer.

Por ejemplo, el Colecto Telstar, se empezó a vender a partir de junio de 1976 y se convirtió en un éxito por derecho propio, con alrededor de una docena de modelos. Aunque originalmente esta consola era un clon del Atari Pong. Esta última, surgió luego de que Nolan Bushnell asistiera a una demostración de la Odyssey, y tomando la misma idea con algunas mejoras (rutina de movimientos mejorada, puntuación en pantalla, efectos de sonido, entre otras), consiguiera tener más éxito. Las compañías con productos similares (incluida Atari) tuvieron que pagar una licencia durante algún tiempo.

Me complace anunciar que un nuevo juego ya está disponible: The Ultra Fighters!

Este es el segundo remake de los 8 que serán presentados. Han sido alrededor de 7 meses de trabajo, sin contar el trabajo previo del motor de juego utilizado. Es resultado ha sido por demás satisfactorio y los cambios son tan significativos que el juego ha sido completamente renovado en un 100%.

Como he comentado anteriormente, la versión original fue desarrollada en Basic, utilizando un screen a 4 colores y sonido del parlante interno del PC (sin música de fondo). Actualmente, este remake fue realizado en C++, utilizando un screen con paleta de colores de 32-bits y audio de 16-bits (17 pistas de música). En un principio solo se iba a mejorar la parte gráfica y el sonido, sin embargo el entusiasmo por el proyecto fue creciendo y los tiempos de producción fueron más cortos de lo establecido, todo esto resultó en cambios más allá de lo previsto.

Pero eso no es todo, el motor de juego fue completamente renovado (desarrollado a partir del remake de Baschet) ofreciendo además, la posibilidad de juego ONLINE!

En resumen, es una versión que no solo cumple las expectativas trazadas sino que ha sido una renovación total del juego original. Seguramente existan muchas ideas para mejorar este proyecto, cualquier sugerencia será bienvenida. Sin embargo, este proyecto se da por cerrado y solo se publicarán revisiones en caso de tener que mejorar errores de programación. Las ideas sugeridas se aplicarían en una futura secuela del juego.

Actualmente existe una versión demo gratuita en inglés. La versión completa se encuentra en 3 idiomas (español, inglés y japonés), compatible con los sistemas Windows y Linux, y se puede obtener por la donación de tan solo $0.99 centavos vía Paypal en la página oficial del juego.

¡Disfruten del juego!

Ahora que nuestro personaje se mueve por el mapa es necesario no perderlo de vista. Para esto tenemos que establecer lo que se llama movimiento de scroll.

Inicialmente es algo sencillo establecer un movimiento de scroll o seguimiento de cámara. Lo difícil puede ser generar el fondo a partir de los tiles dentro del área visible del screen.

La posición del scroll la guardaremos en un par de coordenadas x e y, lo que determinará que cada objeto (incluido el mapa entero) estará sujeto a dichas coordenadas. Para entenderlo, veamos el siguiente caso:

Como vemos en la imagen, el mapa (y personaje) tuvo que ser desplazado 43 pixeles a la izquierda y 32 pixeles hacia arriba (del área visible) para poder seguir al personaje. Esa diferencia de pixeles es la que se registra en las variables del scroll.

El desplazamiento del scroll se puede hacer de varias maneras según el tipo de juego, por ejemplo, se puede hacer que suavemente vayan cambiando los valores hasta acercarse al personaje.

En este videojuego, se impone que el scroll esté desplazado 159 pixeles a la izquierda de las coordenadas del personaje y 159 pixeles por encima. Cada vez que colocamos el personaje, el mapa o cualquier objeto del entorno, debemos sumarle las variables de diferencia de scroll. Los únicos elementos no sujetos al scroll son aquellos que deben permanecer fijos en cierta sección del screen, como por ejemplo: número de vidas, puntaje, tiempo, etc.

Finalmente, al momento de generar el mapa a partir de los tiles se puede hacer de dos maneras. Una forma es generar todo el mapa completo, lo cual gasta recursos innecesarios, ya que no todo el mapa es visible dentro del screen. Otra manera es determinar cuáles son los tiles que caben dentro del área visible del screen, y solo presentar esos.

En el ejemplo de la imagen anterior notamos que, los tiles visibles surgen a partir de la 3er fila y 3er columna. Sabemos que el tamaño visible del screen es de 20×15 tiles. Así que, generamos los tiles comprendidos entre la 3er fila y 3er columna en adelante hasta completar los 20×15 tiles. Pero, debemos tomar en cuenta la diferencia del tile con el screen (marcada en la imagen anterior).

Conclusión

Hasta aquí he presentado las bases para comenzar con el diseño de un videojuego de plataformas. Posiblemente más adelante aborde otros temas puntuales y más profundos del desarrollo de videojuegos, pero considero que con la información presentada, el lector será capaz de darle los elementos faltantes a este ejemplo (enemigos, ítems, movimientos, etc.).