Detección de durezas

[Drumpi]

Hola a todos:

Me estoy planteando cambiar el sistema de detección de durezas del Echo. El sistema actual reconoce los tiles de dureza y actúa en consecuencia, pero como llega a haber  como unos 25 diferentes, hacer las comprobaciones con tantos tiles me supone un sobrecoste mucho mayor que el uso de un sistema de detección clásico, ya sabeis, map_get_pixel.
Así que estaba pensando en hacer algo más "tradicional". Voy a seguir contando con el mapa tileado de durezas, y voy a crear una función que me diga la dureza en un pixel concreto. Básicamente si es un tile transpasable, no transpasable o especial (como un suelo que se puede pasar de abajo a arriba pero no de arriba a abajo, o unas escaleras).

La duda es que no sé cómo plantearlo:
No sé cuántos puntos de lectura de durezas tengo que usar. Usar un único punto en el centro de los pies del prota no es suficiente, y pensaba en usar tres: uno en el centro y otros dos en las esquinas inferiores. Y luego aparte, otro en el lateral para cuando avance que no se choque con las paredes ni atraviese zonas donde haya un hueco. Probablemente necesite usar otros dos en las esquinas superiores para las colisiones con el techo.
Luego está la comprobación en sí. Si el prota está en una rampa, ¿cómo serían las comprobaciones? ¿debo ajustar su altura en base al punto de referencia inferior central? ¿cómo debo actuar con el pixel de la esquina inferior a la hora de avanzar?

Ya digo, le estoy dando vueltas y tengo más preguntas que ideas, y quería saber si alguno de vosotros lo había hecho, y qué debería plantearme a la hora de empezar.
Ya sé que esto es de primero de plataformas de DIV ^^U pero la detección de durezas del Castle of Dr. Malvado es demasiado simple y creo recordar que metía medio sprite del prota dentro de las paredes  (o modificaba las durezas para que eso no pasase, y eso no puedo hacerlo).

A ver si me podeis ayudar a ordenarme las ideas :P

[JaViS]

Yo para anarkade, hago una comprobación en forma de rombo, cuyo tamaño esta definido en cada proceso.


Lo que yo hago es hacer una comprobación pixel por pixel en la dirección en la que me estoy moviendo, por cada pixel compruebo si el choca con una dureza arriba, abajo o a los lados. si choca dejo de comprobar y muevo el proceso solo hasta donde llegó sin chocar.


Ademas de esto tengo una lógica muy compleja centrada en hacer todo este proceso lo mas performante posible, si quieres comparto el codigo aqui para que lo veas

[Drumpi]

Me podría servir de inspiración, si no te importa.
Ahora, si no quieres compartirla en público, pues me lo mandas por correo o por MP. Tampoco tiene que ser todo el código, con que tengas un esquema o un pseudocódigo me vale, yo ya rellenaré los huecos ;)

Entonces para las rampas compruebas desde los pies del prota, centrado lateralmente ¿no? y las paredes desde el lateral del prota, a media altura. ¿No te han dado problemas los escalones? Por ejemplo, imaginemos que tu personaje cae con una dirección en diagonal ¿Cómo evitas que la esquina de un suelo se meta dentro de tu rombo? Quiero decir, en algún momento el borde del suelo estará más abajo que tu comprobador de paredes y aun no habrá llegado a tocar tu punto de control de los pies ¿no?

[JaViS]

Es que, justamente, al tener forma de rombo, me facilita el subir los escalones.

No tengo problema con compartir el código. Cuando anuncié Anarkade justamente comenté que todo el código reusable del juego iba a ser ordenado y compartido en forma Open Source.

El código de durezas está bien separado y hay ejemplos de cómo usarlos. En un rato público acá con una explicación básica

[BoMbErLiNk]

Ya que pides un poco de info, te dejo un poco lo que hice con este mapa de durezas basado en 2.5D usando X,Y,Z, además de un análisis de color para darle distinta lógica, igual te sirve un poco como idea.


- el color negro es vacío, el personaje cae hasta tocar color azul o amarillo, se guarda la linea de salto y se compara con la caída actual, si la caída es superior a la linea de salto ésta pasa a renovarse continuamente hasta tocar suelo.
- el color azul es suelo, no solo pisa suelo, puede desplazarse vertical o horizontalmente en él, se actualiza una copia de variables de X / Z mientras pisa este suelo.
- el color verde es pared, si el prota queda dentro de este color se le devuelven las últimas variables copiadas del color azul, si la distancia es muy elevada, intenta hacer un bucle inverso desde el punto destino a origen hasta tocar color, para evitar el defecto de "teletransportación".
- el color amarillo es plataforma, actúa igual que el azul pero es capaz de crear plantas virtuales.

La comprobación está en el punto de control (en los pies), como es vista en perspectiva no es necesario hacer muchas más comprobaciones (porque no va con separación de tiles), la copia de variables sirve para saber hacia donde se desplaza el prota, si solo lo hace hacia la izquierda se recoge info del mapa solo por la izquierda.

Luego hay combinaciones, todas se consideran cuando el prota se levanta del suelo (saltos,etc):
azul+amarillo, se anula el salto de plataforma y pasan a considerarse ambos suelo
azul+verde+amarillo desde distinta Z, se considera plataforma superior y se empieza a pisar cuando el personaje desciende de un salto, no mientras se impulsa
azul+negro en misma Z, salto en caída hasta tocar azul o amarillo
azul+negro+azul, salto en misma linea de suelo
azul+negro+amarillo, salto a plataforma superior
azul+negro+verde, choque con pared horizontal, se omite choque vertical
amarillo+negro+amarillo, actúa como azul+negro+azul, para "escalar" hay que combinar azul y amarillo

En el juego no solo chocas con la pared, puedes deslizarte por ella lo cual puede actuar también como una rampa, en ese caso se comprueban las esquinas de X,Y en el sentido que se actualizan las coordenadas.

Margen virtual, los enemigos pueden salir fuera del mapa de durezas y que éste sigue funcionando, lo que hace es coger el último pixel de cada extremo del mapa y seguir comprobando, así si un mapa termina con pared significa que esa parte será infinita fuera del mapa.

[Futu-block]

¿hay alguna manera de que considerando al echo como tile, le pregunte al siguiente tile que codificación tiene y asi actuar?

Eso es lo que estamos haciendo con el chiva poket, si avanzas pregunta en la malla de tiles que numero tiene y conforme a eso asi se actua

[JaViS]

perdon por la demora, ahora mismo no estoy en casa y no puedo ponerme tranquilo con esto


echale un vistaso a esto mientras tanto https://bitbucket.org/pixelatom/bennu_framework/src/6a703f9b16c62a962b01ad5804e2696690448505/test_hardness/basics.prg?at=master&fileviewer=file-view-default




la idea es declarar un mapa de durezas ( que es un tipo de variable ) basado en una imagen, para pasarle a los procesos para que detecten dureza, con la funcion hmap_apply

[Drumpi]

Gracias, Javis, le echaré un vistazo.
Y también gracias a ti, Bomber, es muy ilustrativo. Siempre pensé que usábais un sistema de coordenadas 3D virtuales :) Lo que pasa es que un juego 2'5D no es lo mismo que un juego de plataformas, y hay comportamientos que no se cubren, como subir rampas más o menos inclinadas, escalones o choques contra los techos.

Futu: ese es el sistema actual del detector de durezas, y mientras tienes pocos tiles de durezas es un sistema muy efectivo e incluso más eficiente que el clásico. Pero mi juego tiene actualmente más de 50 tiles diferentes de dureza, y a la comprobación del cambio de tile le tienes que añadir la comprobación de movimiento DENTRO del tile, que en ocasiones interactúa con los tiles de alrededor.
Por ejemplo, en un tile de rampa, a medida que avanzamos a la derecha, el prota debe ir subiendo, y llegado un momento que se acerca a la derecha, debe comprobar si el tile de la derecha le deja pasar o no, o a medida que sube, si choca con el tile de encima, que puede ser un techo liso o tener dos inclinaciones (dos inclinaciones, dos alturas para las medias rampas, y dos direcciones, son en total 6 tiles/reacciones diferentes, sin contar que tengo tiles normales y de agua).
Hay muchísimas combinaciones de interacción entre tiles. Si sólo tienes 4 o 6, el código pasaría de tener 2000 lineas a menos de 500.
Al final, los case consumen más tiempo que un map_get_pixel, y como puedo saber el color de cada pixel sin usar map_get_pixel, puede que sea más rápido hacer la coprobación de movimiento "leyendo los colores" de cada pixel en lugar de ir tile a tile.

[JaViS]

Pregunta cualquier duda que tengas, creo que es bastante facil de usar, pero leer el codigo de la libreria quizas se te complique. Estoy para ayudar