Se me ocurrió poner rectángulos/cuadrados girados:

Luego chequeo esas zonas.

El problema es... ¿Cuánto debo girarlos/estirarlos, desde dónde y hacia dónde? Ahí por ejemplo tracé 2 líneas que usen puntas de píxeles extremos. Pero no sé cómo hacer que un cuadrado quede con ese ángulo. Si a esa línea le agrego más líneas de modo que sea un cuadrado rotado y lo convierto en símbolo, va a quedar una figura romboide cuya área va a ser un cuadrado, como se muestra la figura roja. Al crear la zona, debe hacerse derecha y rotarse/estirarse después, cuando ya esté creada, para evitar el problema. Pero de hacer las figuras adecuadas es como que no tengo idea, no me sale bien. Supongo que debo poner paralelogramos en cada zna inclinada, pero no me sale hacerlo rápido, bien.

Por ahora estoy separando a Mario en zonas, ya tengo 3: La cabeza, el pelo de atrás que no se considera zona de hit, y el cuerpo.

Supongo que haré un video que muestre mejor mi problema.

Muchas gracias por tus consejos y por compartirlos. La información que proporcionaste es muy útil y aprendí muchos consejos.

En ese caso, el uso de cajas simples debería bastar. Ten por seguro que casi todos los juegos retro usan ese método o alguna variación. Simplemente, como te dije antes:


Sin necesidad de ver el código del Donkey Kong original, es muy obvio que las cajas de colisión son más pequeñas que los sprites.

En cuanto a los paralelogramos, el método no es inútil, pero sí innecesario en este caso. La detección de colisiones se hace más complicada, y que yo sepa, Flash no la implementa (lo único que hará será verificar la colisión entre las áreas rectangulares que delimitan esas figuras), así que tendrías que programarla tú. Y aún si Flash lo hiciera por ti, necesariamente va a ser menos eficiente. Independientemente del método que se use, detectar colisiones con paralelogramos será al menos unas 30 o 40 veces más lento que hacerlo con cajas "simples" (alineadas al eje). En la práctica, como las computadoras modernas son rápidas, probablemente no haya problemas de rendimiento, y aún si pudieras tener cientos de barriles en pantalla (cosa que obviamente ya en el juego no sucedería), se pueden realizar optimizaciones (separar la verificación de colisiones en dos fases, dividir el nivel en secciones/sectores), pero no deja de ser trabajo extra que no se justifica para juegos de este tipo.

Otras alternativas más eficientes serían: usar zonas de forma circular y verificar la colisión comparando la distancia al centro del círculo con su radio, o cápsulas, que se pueden implementar como un rectángulo con semicírculos en dos extremos opuestos, pero tampoco las considero necesarias, puesto que el método de las cajas basta y sobra en este caso. El Donkey Kong probablemente haga algo así:



Aunque pueda parecer que las cajas son muy pequeñas, puedes hacer pruebas en un emulador y verás que son bastante aproximadas a las que el juego original de arcade debe usar. En todo caso, puedes hacer ajustes o incluso usar cajas separadas para la cabeza y el cuerpo si quieres algo un poco más preciso, pero sólo un poco, pues paradójicamente, las colisiones muy exactas pueden perjudicar la jugabilidad y causar frustración. Como regla general, y en particular en juegos de plataformas, suele ser aconsejable que, cuando se trata de cosas que pueden dañar al jugador (enemigos, balas, barriles), las cajas de colisión sean más pequeñas, y en caso contrario (plataformas, escaleras, power-ups), hacerlas exactas o incluso más grandes, según cada caso. De igual manera, por lo general es conveniente tratar los pies de manera aparte, ya que su principal uso es aterrizar en superficies (o pisar enemigos, pero aquí no es el caso), por lo cual su caja es algo más precisa y muchas veces no se toma en cuenta para colisiones con enemigos, así que yo te aconsejaría que únicamente la uses para detectar si Mario está sobre una plataforma, pero no con barriles y bolas de fuego. Con esto consigues dar al jugador un margen de tolerancia para la parte inferior del sprite.