Aquí os traigo la traducción de un artículo escrito por el genial
Upsilandre, el cual analiza las peculiaridades de algunos videojuegos de NES y el funcionamiento de las cajas de colisiones.
Artículo original (francés):
https://upsilandre.over-blog.com/2018/0 ... aisir.htmlSIN CAJAS DE COLISIONES, NO HAY PLACER
Me divertí convirtiendo unos quince scripts para hacerlos compatibles con el emulador Mesen y cuyo tema común es mostrar hitboxes en los juegos de NES. Es un tipo de script realmente interesante y merecía ser archivado en este prometedor futuro emulador. Y así al mismo tiempo compartir contigo lo que podemos observar gracias a estos guiones y ver si hay algo que decir. ¡Así que hablemos de Hitbox!
Los conceptos básicos.El hitbox es la solución clásica para probar colisiones entre objetos. Definimos cuadros delimitadores alrededor de los objetos a probar y si 2 cuadros están parcialmente superpuestos, hay una colisión. Llevar a cabo este tipo de pruebas en cajas es relativamente trivial y, al mismo tiempo, bastante efectivo, por lo que naturalmente se impuso.
En las consolas más antiguas como la Atari 2600, la Intellivision o la Videopac existía otra solución alternativa, una solución hardware al problema de colisiones mediante flag gestionado por el chip gráfico. Banderas (bits de hardware en un registro) que se activaban si los píxeles de la pantalla eran comunes a 2 sprites o comunes a un sprite y el fondo. Una función de hardware posible gracias al número limitado de sprites en ese momento. No siempre se podía usar, tenía que cumplir con ciertas condiciones, pero podía ayudar (y causaba colisiones de píxeles ya que era sensible solo a los píxeles opacos de los sprites). Hay un residuo de este tiempo en NES con la bandera del sprite cero pero que ha asumido un papel completamente diferente (sirve como señal de sincronización entre el código y la pantalla).Pero aparte de estas pocas excepciones e intentos de resolver colisiones de una manera de hardware, podemos decir que los hitboxes, que son un enfoque de software, se convirtieron rápidamente en la solución más viable y flexible para satisfacer casi todas las necesidades.
Podemos distinguir dos familias principales de colisiones. Primero las colisiones objeto> entorno (aquí podemos reemplazar el término objeto por sprite si queremos). Por ejemplo, para evitar que el jugador o los enemigos (los objetos) crucen el suelo y las paredes (el entorno) o para tener en cuenta los elementos del entorno que son destructibles por las balas o que son letales para el jugador. . Este tipo de colisión no es muy costoso porque el entorno (el mapa de mosaicos, el plano de construcción del escenario) ya es como una pila de cajas (los mosaicos o metatiles) todas del mismo tamaño y perfectamente ordenadas una al lado de la otra. . Simplifica las cosas y, por lo tanto, este tipo de colisión es económico.Esto por ejemplo se ha explotado mucho en los shmups verticales de los 80 para tener algo muy dinámico y espectacular con mucha interacción como aquí en Blade Buster un homebrew tipo Caravan Shooter disponible gratis
Mucha colisión entre la bala y el medio ambiente.
Pero lo que nos interesará en este post (lo que nos permite visualizar los scripts que convertí para Mesen) son más bien las colisiones objeto> objeto (o sprite> sprite). Estos son los tipos de colisiones que más utilizan los hitboxes (a veces, las colisiones con el entorno también requieren que los hitboxes tengan una granularidad más fina y precisa). Estas 2 familias de colisiones no utilizan los mismos algoritmos ni los mismos datos. Se tratan de forma independiente.
El costo de las colisiones objeto> objeto se infla mucho más rápido que la cantidad de objetos y, por lo tanto, esta es la parte sensible del motor de colisiones. Si cada objeto puede chocar con todos los demás, eso implica que con 5 objetos en la pantalla tienes que hacer 5x5 = 25 pruebas de hitbox. ¡Si hay 20 objetos, eso significa 20x20 = 400 pruebas! Vemos que este no es un simple problema lineal, aumenta según el cuadrado del número de objetos, de ahí el desafío.
La primera simplificación es definir 2 subconjuntos en esta familia de colisiones. Por un lado están los objetos “player”, es decir, el sprite del jugador (o jugadores) y sus balas por ejemplo. No es necesario probar las colisiones entre las balas del jugador y el propio jugador ni entre las balas en sí, por lo que no hacemos una prueba de colisión entre los objetos de este subconjunto. Y el otro subconjunto se referirá más bien a los enemigos y sus balas. Entonces, el objetivo será probar las colisiones entre estos 2 subconjuntos y en las 2 direcciones. Vamos a probar las colisiones de jugador> enemigo (para averiguar si las balas del jugador han golpeado a un enemigo) y las colisiones de enemigo> jugador (para averiguar si el enemigo ha golpeado al jugador. Ya sea por contacto directo o a través del intermediario). de una bala). ¡Esta es la teoría!Ahora veamos qué podemos observar realmente en los juegos con estos famosos guiones, será más divertido.
Abran paso a los ejemplos.Ver los hitboxes le permite ver que a menudo son permisivos. Los hitboxes enemigos se muestran aquí en rojo y el hitbox del jugador en azul. Por ejemplo, esta flecha en Holy Diver parece particularmente peligrosa pero al final más miedo que daño, los 2 hitboxes no se tocan.
¡Justito!
En Contra Force podemos ver que las prensas (que aquí son objetos formados por elementos establecidos en el background, ya que en NES tratamos de disminuir el uso de sprites tanto como sea posible) tienen pequeños hitboxes colocados al frente. Entendemos mejor entonces por qué hay un lugar seguro que parece desafiar lo que nos muestra la imagen.
¡Ni siquiera duele!
El acto de realizar un ataque a menudo requiere una cierta cantidad de cuadros de animación, pero la mayoría de las veces solo uno de los cuadros que componen esa animación tiene un hitbox activo. Así que aquí también a veces podemos engañarnos un poco por lo que nos muestra la imagen. El impulso en Castlevania toma alrededor de veinte cuadros, pero solo el 17 está activo y ni siquiera se encuentra entre los primeros cuadros de animación del látigo en la posición estirada.
El último golpe en blanco
Vice project doom es uno de esos juegos de NES de alta calidad pero poco conocidos (especialmente porque no existe en PAL). Y contrariamente a las apariencias, es la alternativa real a Ninja Gaiden. Mucho más que una Shadow of the Ninja (Sombra azul) por ejemplo porque aquí encontramos la misma dinámica, el slash muy breve y preciso a baja distancia, el salto sin carta de colores vertical, el knockback, los enemigos muy numerosos y agresivos que salen de los agujeros..., pero todos tienen un solo toque, la reaparición violenta, el corte de las etapas, el formato de la escena... Es 100% como Ninja Gaiden pero con variaciones inspiradas en otros juegos (fases a lo Spy Hunter u Operation Wolf) y un pixel art bastante inspirado en Batman y sus descendientes (Shatterhand, Kabuki ...). Pero también hay otra cosa interesante en este juego que es un cierto esfuerzo para tratar de tener hitboxes que mejor se adapten a lo que el jugador ve en la pantalla.
Por ejemplo, el hitbox de barra es muy interesante. De hecho, se trata de cuatro hitboxes sucesivos que, por tanto, duran cuatro fotogramas y que acompañan literalmente todo el movimiento de animación de la barra. Por lo tanto, podemos golpear atrás, arriba, adelante, a nuestros pies, pero sucesivamente. Entonces, el tiempo es diferente dependiendo de si queremos golpear a un enemigo detrás o en nuestros pies, lo que requiere una fase de aprendizaje, especialmente porque la barra tiene un tiempo de reutilización, no podemos golpear (máximo 6 golpes por segundo) . Esta es la parte más interesante del juego (también me gusta poder correr agachado).
Un hitbox dinámico ingenioso
La granada también tiene derecho a un hitbox dinámico de 2 etapas para simular la explosión de la explosión (así como un pequeño hitbox para la fase de lanzamiento) y una vez más, intenta ceñirte a lo visual.
La explosión de la explosión se materializó
Encontramos el mismo enfoque en las fases de shoot'em up vertical. El juego nos da la posibilidad de modificar nuestra velocidad de movimiento con un botón y este cambio de velocidad está representado por una pequeña llama de escape en la parte trasera del vehículo como en otros shoot'em up excepto que aquí se materializa esta pequeña llama también por un hitbox que por lo tanto puede destruir a un enemigo detrás, clase!
Incluso las llamas de escape tienen sus hitboxes
Ahora a Megaman 4. Podemos ver dos cosas interesantes. Te hablé de los dos subconjuntos en
objeto>pruebas de caída de objetos. Resulta que las pruebas de
jugador>enemigo no necesariamente usan las mismas áreas de impacto que las comprobaciones de
jugador>enemigo, incluso si se comprueban los mismos objetos. A veces hay asimetría en las comprobaciones, lo que significa que los enemigos suelen tener dos hitboxes, uno para cada prueba. Te permite tener más control sobre cómo quieres que reaccione u optimice el juego.
Aquí en Megaman tenemos las colisiones entre casillas rojas y azules que están destinadas a colisiones de
jugadores>enemigos para saber si el jugador está siendo golpeado por el enemigo. Y junto a eso tenemos las colisiones entre casillas verdes y amarillas para colisiones de
jugadores>enemigo para saber si el jugador golpea al enemigo.
El principio de múltiples hitboxes
Entonces, podemos ver claramente en este caso que la bala del jugador con su hitbox amarillo no golpea el hitbox verde y por lo tanto no golpea al enemigo. Y la otra cosa interesante que notamos es que el deslizamiento de Megaman no tiene el efecto esperado de cambiar la forma del hitbox de Megaman sino que cambia la del enemigo y de manera bastante significativa. Sin duda, una vez más para tener un control preciso sobre el diseño del juego y decidir bajo qué enemigo será efectivo o no el deslizamiento y, por lo tanto, gestionar la mecánica de esquivar caso por caso. Aquí vemos que la opción es modificar el hitbox del enemigo lo suficiente para que el jugador pueda pasar por debajo si usa el deslizamiento.
Ninja gaidenAhora hablaremos de los tres Ninja Gaiden. Tenemos la suerte de tener un guión para cada uno de ellos y hay mucho que decir. Hagamos esto en orden y comencemos con el primer Ninja Gaiden. Les dije que las colisiones
caja>caja son un gran éxito porque es trivial y fácil de hacer incluso para máquinas viejas, pero aún podemos simplificarlas para ganar algunos ciclos, en particular haciendo colisiones
línea>caja o
punto>caja. Siempre es bueno enfrentarse a una NES.
Ninja Gaiden tomó la decisión de reemplazar el hitbox del jugador con una línea vertical simple para simplificar un poco las colisiones de
enemigos>jugadores. Pero eso luego implica calibrar el hitbox de los enemigos según esta elección, es decir ensancharlos para compensar la suavidad del hitbox del jugador reducido a una simple línea central. Lo podemos ver claramente en el martillo que tiene un hitbox exageradamente grande y aún más en el cuchillo arrojado. Es esta exageración de los hitboxes enemigos lo que compensa y permite el contacto con la línea de impacto del jugador de acuerdo con el contacto visual.
El enemigo con casco tiene el lujo de un hitbox dinámico.
Es menos preciso para el hitbox del lanzador de cuchillos que tiene un hitbox casi ordinario y de repente al chocar con el jugador debe realmente meterse en él por completo. Sentimos dudas sobre la elección del ancho del hitbox porque este hitbox enemigo rojo también se usa para
jugadores>colisiones enemigas con la barra del jugador y de repente hacer que el hitbox sea demasiado ancho y luego favorece el ataque del jugador.
Por el contrario, para las colisiones de
jugador>enemigo con un jugador que dispara a distancia (aquí el shuriken), la colisión del shuriken ocurre con la línea amarilla central del enemigo. Es la misma
línea>optimización de caja pero invertida. De repente, por la misma razón, el hitbox (violeta) del shuriken es excesivamente grande para compensar.
Hitlines y hitboxes desproporcionados
Hay un caso divertido en este Ninja Gaiden es el poder del salto de hidromasaje. Este poder funciona como los poderes de invulnerabilidad que se encuentran en Ninja Gaiden (la rueda de fuego) o Megaman u otros. Este tipo de poder consiste internamente en desactivar las colisiones de jugadores> enemigos (para que los enemigos ya no puedan tocar al jugador) y en activar un gran hitbox de ataque que abarca al jugador y por lo tanto infligirá daño a los enemigos en contacto. El salto de hidromasaje de Ninja Gaiden funciona así. Solo salta y activa el poder en el aire.
Pero el error que cometieron aquí es no anticipar el uso de este tipo de poder en la cara de un jefe porque el hitbox de ataque que te envuelve es permanente (no dura un solo frame sino que dura hasta que te caigas al suelo). Por lo tanto, no se destruye al entrar en contacto con el jefe, como es el caso del siguiente Ninja Gaiden y, además, los jefes no tienen marcos de invulnerabilidad. El resultado es que infliges daño al jefe en cada cuadro con el que estás en contacto (a una velocidad increíble). Esto significa que puede reducir su HP a cero en un cuarto de segundo (16 cuadros). Sabiendo que durante este tiempo eres invencible (el hitbox azul de Ryu desaparece). Puedes adivinar que esto lo convierte en el arma definitiva contra los jefes. El HP del jefe cae tan rápido que el juego no tiene tiempo para actualizar su barra de salud (solo se actualiza 10 veces por segundo). Por esta razón, he mostrado sus PV reales en tiempo real debajo de él.
Un hitbox con un poder demasiado poderoso
Ahora pasemos al episodio 2 de Ninja Gaiden. Algo interesante de este script, así como del de Ninja Gaiden 3, es que la información de los hitboxes no se recupera simplemente en la RAM o ROM, sino directamente en el momento de la ejecución de la prueba de choque por parte de la CPU que luego genera una interrupción del script. Esto significa que el script aquí solo muestra los hitboxes cuando hay una prueba concreta. La consecuencia es por ejemplo que los hitboxes no se muestran si no hay enemigo porque no hay prueba de colisión en este momento pero sobre todo permite aquí ver que las colisiones solo se hacen un fotograma de dos, por tanto, a 30Hz. Esto permite que el motor de colisión entreteje las colisiones de jugador> enemigo (caja blanca y verde) con las colisiones de
enemigo>jugador (caja roja y azul), cada una por turno,cada uno su marco. Esta es otra forma bastante común de ahorrar recursos de CPU en pruebas de choque. Las colisiones a 30Hz siguen siendo suficientes en general, creo.
Distribución de pruebas entre fotogramas pares e impares
También notamos que Ryu obtuvo un hitbox real en este episodio, así como los enemigos. Pero eso no detuvo otra pequeña optimización. Esta vez, la barra de golpe se reduce a una sola línea. En términos económicos no será muy notorio pero al mismo tiempo las consecuencias negativas son casi nulas. La reducción de la barra a una línea sigue siendo bastante consistente con su representación en la pantalla. Entonces, el ataque se vuelve aún más quirúrgico que nunca, especialmente durante los movimientos verticales (salto o caída), realmente tienes que presionar en el marco correcto para alcanzar tu objetivo. Los enemigos tienen espacio para pasar por debajo o por encima. Quizás el Ninja Gaiden más quirúrgico.
Un corte quirúrgico tan delgado como una línea
Respecto a Ninja Gaiden 3 esta vez no hay más línea, solo tenemos hitboxes reales. Por otro lado, encontramos un motor de colisión que funciona a 30Hz, por lo que cada dos fotogramas, pero además de eso, el algoritmo corta a los enemigos en dos grupos de cuatro (por lo que un máximo de ocho enemigos en la pantalla, eso incluye sus proyectiles) y solo procesa un grupo cada vez, lo que significa que las pruebas de colisión con un enemigo en particular solo se realizan realmente una vez cada cuatro cuadros, es decir, a 15Hz (podemos observar esta alternancia de cuadros rojos en el gif).
Está empezando a hacer muy poco como frecuencia de prueba. Esto significa un retraso de entrada de la barra que variará de acuerdo con el ciclo del motor de colisión que se está probando cuando golpea. Lo más problemático en un motor de colisión de frecuencia demasiado baja es para proyectiles rápidos como nuestros poderes mágicos (las cajas blancas en el gif) hasta el punto de que los desarrolladores lo sabían muy bien y, por lo tanto, aumentaron la frecuencia a 20Hz. prueba de nuestros proyectiles mágicos (así que una vez cada tres fotogramas) e incluso a 20Hz, lamentablemente, sigue siendo demasiado bajo. Aceleré el juego (en modo "sin daño") y por eso a menudo me enfurecía al recibir daño debido a una magia que atraviesa a un enemigo sin tocarlo porque entre dos pruebas demasiado lejanas en el tiempo, el proyectil había pasado al otro lado del enemigo sin que hubiera superposición de los hitboxes. Este es el riesgo de un motor a una frecuencia demasiado baja. A cambio, el juego mantiene una excelente velocidad de fotogramas a 60 fps en todas las circunstancias a pesar de la intensidad de la acción y eso sigue siendo genial.
Este gif nos permite visualizar con qué frecuencia se ejecutan las diferentes colisiones y la distribución entre los dos grupos de enemigos. Por tanto, el ciclo completo para realizar todas las pruebas se diluye en cuatro fotogramas.
Pruebas de colisión a 15 hz
El juego compensa estas pequeñas debilidades con grandes áreas de impacto para nuestros ataques. Incluso tenemos dos tipos de barras en este episodio. El slash básico cuyo hitbox deja pasar a ciertos enemigos desde abajo y el super slash cerca del strider slash y que ofrece un hitbox muy grande que protege desde nuestros pies hasta la coronilla. Puedes comparar las dos barras en este gif.
Comparación de los dos tipos de barra
Ninja Gaiden 3 también es una oportunidad para hablar sobre los errores que se pueden resaltar con un script de este tipo. La visualización de hitboxes, por ejemplo, le permite averiguar cuándo hay un error de formato de hitbox. Mira con atención las piedras que caen del techo en esta escena del sexto jefe cuya estrategia es chocar contra la pared para crear deslizamientos de tierra. Hay siete piedras que caen cada vez excepto que siempre hay una de ellas que tiene un hitbox de buggy completamente desproporcionado (57x33 en lugar de 9x9, incluso más grande que el del jefe) y que nos impide 'esquivar. La única solución en esta lucha para no dejar tu destino en manos del azar, es destruir las piedras sobre ti usando magia vertical (arte de ondas de vacío).
Un buen error de hitbox
Identifiqué otro error durante mis speedruns. Durante la pelea final el jefe dispara rayos precisamente en el lugar donde te encuentras en este momento y por lo tanto para evitarlos es absolutamente necesario estar en plena carrera para que el momento en que el rayo caiga al suelo ya te has movido. Pero debido a las colisiones que se ejecutan solo en un cuadro de cada cuatro, tenemos una prueba de colisión de la luz con el jugador que no siempre se realiza en el mismo tiempo en esta secuencia y variará de acuerdo con el ciclo de prueba actual. Por tanto, la prueba de colisión de la luz con el reproductor se realizará de forma más o menos prematura con una variación de más de cuatro fotogramas.
A esto se suma el hecho de que la raza de Ryu no es lineal. Para tener esta velocidad de movimiento común a una gran cantidad de juegos de 90 píxeles por segundo, implica alternar entre cada fotograma desplazamientos de un píxel con desplazamientos de 2 píxeles (lo que nos da un desplazamiento de 1,5 píxeles por fotograma en promedio es decir, 1,5 x 60 = 90). El resultado es que si por mala suerte nos encontramos en el caso de una prueba de colisión ligera que se haría prematuramente en el primer fotograma posible (una oportunidad de cuatro) combinado con un desplazamiento Ryu de solo un píxel por cuadro anterior (una posibilidad de dos) nos encontramos sufriendo un ataque de rayo fatal (una posibilidad entre ocho) que no podemos evitar, por lo que es un error de calibración vinculado a la baja frecuencia del motor de colisión que no fue visto durante la prueba de juego.
Amor a primera vista
A pesar de todo lo que podría señalar aquí en Ninja Gaiden 3, es un juego muy divertido de jugar. Uno de los mejores juegos de NES. Tengo muy buenas sensaciones al respecto a pesar de todo eso porque el juego compensa con otros activos. Lo recomiendo encarecidamente (especialmente para aquellos a los que no les gusta Ninja Gaiden, es muy diferente de la mecánica del uno y del dos).
ContraAhora terminemos con uno de los gigantes de la colisión: Super Contra (además de Contra que usa casi el mismo motor). El juego permite al jugador disparar hasta 10 balas en la pantalla (incluso de 16 a 2 jugadores), lo que es un factor de estrés enorme para el motor de colisión porque multiplica las pruebas de colisión por mucho. Estamos lejos de las dos balas de Contra Force, el spin-off que seguirá a este episodio (en general en NES es más bien entre una y tres balas para el jugador). El motor también permite hasta 13 enemigos en la pantalla, por lo que potencialmente tenemos 10 x 13 = 130 pruebas solo para jugadores> colisiones enemigas. Y todo ello con colisiones de 60Hz e incluso un modo de dos jugadores (que por tanto duplica las colisiones de jugadores enemigos> así como una muy buena estabilidad de framerate a 60 fps (lejos de Contra Force).
Podemos suponer que los algoritmos de colisión Contra y Super Contra están altamente optimizados. Esto implica, entre otras cosas, la elección esta vez de colisión tipo punto> caja para ganar algunos ciclos. Esta vez, el hitbox del jugador (y sus balas) es reemplazado por un solo punto (la cruz azul en el centro del sprite en el gif). Por lo tanto, es el hitbox enemigo el que tendrá que compensar el pequeño tamaño del jugador. Entonces, en lugar de tener un hitbox diferente para el jugador para cada uno de sus estados (de pie, acostado, etc.), son los enemigos los que tendrán tantos hitboxes como el estado del jugador (de pie, acostado, agachado, saltar, en el agua, así como un hitbox para colisiones con las balas del jugador).
Hitboxes dinámicos que se adaptan a la posición del jugador
Entonces, la desventaja es que cada enemigo debe tener seis hitboxes. Luego tenemos un costo adicional de datos (pero un hitbox no pesa mucho) y hitboxes con formas extrañas (ya que están calibrados a medida para alcanzar el hitpoint del jugador de una manera consistente). Pero al final permite las mismas colisiones y con la misma precisión que en
box>box mientras consume menos recursos de CPU. Podemos ver claramente aquí los cambios en el hitbox rojo de los enemigos (o sus balas) dependiendo del estado del jugador y la forma extraña que puede dar (el hitbox verde de las balas enemigas que está completamente descentrado para compensar el hecho de que el hitpoint del el jugador está descentrado cuando está acostado)
Un gif final que muestra una escena de prueba de choque muy ocupada. The Spread Gun en demostración contra muchos "enemigos". Contra y Super C son la crème de la crème del género en NES. Además, algún día también tendremos que hablar sobre el salto particular de Contra, tanto que decir.
Muchos enemigos y balas.
También tengo guiones para Super Mario Bros 1 y 3 , para Faxanadu , Crystalis y Castlevania 2 . Aquí hay un paquete que reúne todos estos scripts. Para usar con el emulador MESEN (versión 0.9.6 como mínimo): Mesen_Script_Hitbox
En conclusión, los hitboxes tocan de alguna manera la esencia de los videojuegos. Materializa la interacción. Merece respeto, pero en la vida real pasé demasiado tiempo en esta publicación, ya no puedo soportar hitboxes. ¡Socorro!
Actualización 5 de diciembre de 2019:Agregué mi piedra al edificio haciendo un guión para visualizar los hitboxes de Splatter House Wanpaku Graffiti, lo que me permitió una vez más comprender mejor el comportamiento del juego. ¡Me encantan estos guiones!
Los remito al hilo de twitter en el que detallé e ilustré lo que podemos aprender de él con muchos Gifs:
https://twitter.com/upsilandre/status/1 ... 6445571072Actualización 13 de enero de 2021:Con cierto placer, continué produciendo mis propios scripts de hitbox en varios otros juegos de NES, cada vez con un hilo de Twitter lleno de información y gifs. Te remito directamente a estos grandes hilos:
Chacal:
https://twitter.com/upsilandre/status/1 ... 9106079745Astyanax:
https://twitter.com/upsilandre/status/1 ... 6790470659GI Joe:
https://twitter.com/upsilandre/status/1 ... 5986095105Castlevania 3:
https://twitter.com/upsilandre/status/1 ... 4766442498 
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
![[flipa]](/images/smilies/nuevos2/flipando.gif "flipando")
