Como gestionar varios rect collision o hitboxes?

[borgo66]

Vuelvo al ataque a tratar de terminar una demo de un juego de peleas despues de un tiempo.
He aqui la cuestion: en este juego (un clon del street fighter) tenemos varios hitboxes (las cuales son rects que se usan para determinar que parte del cuerpo del sprite colisiona con que otra,etc) por frame de cada animacion del personaje y ese es el problema,¿como demonios hago para gestionar los cientos de hitboxes que tiene cada uno de los varios personajes del juego?.
Con "gestionar" me quiero referir a colocarlas en las coordenadas especificas para cada luchador(ya que no es lo mismo el lugar donde impacta un golpe si un personaje es mas alto que otro), actualizar sus pociciones, chequear si colisionan,etc, con varios personajes y sus muchas animaciones.
Hasta ahora lo que tengo es una clase "Frame" que contiene la imagen que le corresponde, una lista de hitboxes (rects) de ataque y otra que indica que zona del sprite son golpeables ej: cabeza, torso, pies y según que zona es golpeada reaccione distinto, pero quiero recalcar la pregunta: ¿Tengo que "setear" o inicializar a mano todas las hitboxes? Si tienen alguna idea de como hacer algo asi o una sugerencia de otro sistema de colisiones para un juego de peleas lo voy a apreciar mucho porque hace rato que estoy estancado.

[hugoruscitti]

Hola Borgo,

al menos en los juegos que yo vi, el sistema de colisiones se
intenta simplificar lo máximo posible, porque como decís, con
tantos personajes y movimientos se vuelve cada vez mas complejo
y difícil de manejar.

Por ejemplo, en el juego shaolin estoy tratando de implementar
un tipo de colisiones fácil de manejar, y para mi sorpresa, se
puede simplificar muchísimo.

Estás son algunas de las ideas que estoy planteando para simplificarlo. Te las
comento, porque tal vez se parezcan a las del juego que estás haciendo. Y tengan
algo en común:

- Cuando un personaje pega, construye un sprite golpe.
- El sprite golpe es invisible, pero se puede hacer visible para depurar (con un flag).
- Las colisiones se dan cuando el emisor (sprite golpe) toca el rect del enemigo.
- El rect del enemigo es fijo, no tiene distintos puntos de recepción de golpes.
- La posición del sprite golpe es relativa a la posición del personaje que emite el golpe.

Esta imagen muestra cómo se ve un golpe en pantalla:



No se si te servirá de mucho, pero si quieres puedes investigar
un poco el readme que estoy escribiendo:

https://bitbucket.org/hugoruscitti/sbfu ... adores.rst

Es todo un mundo los juegos de peleas, estaría bueno seguir conversando a ver
si sacamos estrategias para escribir un artículo no?

[hechelion]

Yo uso un sistema de boxes asociados a cada sprite de la animación, la idea la tome del M.U.G.E.N. de DOS (ni idea si aún sigue siendo igual), de esa forma cuando das un golpe, se crea un "box" que sigue a la animación con lo cual se consigue que esté bien sincronizado y a bajo coste, pues es simplemente una lista de coordenadas.

Respecto a la cantidad de boxes y precisión de colisiones, se suele usar un sistema similar al usado a las texturas, mientras más lejos, menor resolución y mientras más cerca, más resolución.
Esto aplicado a colisiones sería tener un único box por entidad, de esa forma tienen que comprobar muy pocas colisiones por ciclo, si un momento detectas que hay una colisión, bajas un nivel y pasas a comprobar colisiones de forma detalla (ya sea con más box o por pixel) solo entre las entidades que sus box ya están en colisión, de esa forma tienes precisión pero solo calculas colisiones precisas si son necesarias.

[borgo66]

Tenes razon Hugo es todo un mundo y por cierto no hay mucha informacion al respecto, pareciera que programar un street fighter es algo asi como magia negra en el mundo de la programacion.
Por otro lado el juego que estas haciendo tiene una pinta barbara y me gusto la idea, el codigo lo voy a analizar bien el fin de semana.
Queria pasarte el link de este juego en pygame (me olvide de decir que yo estoy haciendo el mio tambien en pygame)http://pygame.org/project-Street+pyghter-1860-3372.html.Estuve tratando de desenmarañar el codigo y no se entiende mucho, pero he aqui que en la carpeta de los sprites y demas recursos hay un par de sprite sheets (o algo asi) con las hit boxes dibujadas a mano pero en dos "capas".Al parecer el tipo uso gimp para dibujar las cajas sobre la sprite sheet de las animaciones del luchador y despues usa esas capas no visibles para chekear colisiones, algo como lo que haces vos Hugo y tambien lo que dice hechelion y el problema seria como que no se bien por donde empezar a implementar algo asi (soy un intermedio en esto de los video juegos).
Hechelion parece que ya hizo algo de esto asi que si tenes algun codigo como ejemplo o informacion de por donde empezar te lo agradeceria mucho.
Yo por mi parte voy a tratar de seguir desentrañando el codigo del juego que les pase y el de Hugo tambien (para que no digan que no hago nada, je,je,je!).

[hechelion]

Lamentablemente el ejemplo es para VB, por eso no lo había colocado

http://www.stratos-ad.com/forums/index. ... ic=11944.0

La clase se encarga de gestionar las animaciones, y cada frame de la animación tiene asociado un array de coordenadas que representan los boxes de colisión.


También te recomiendo darle una mirada a M.U.G.E.N. me parece que no tienen liberado el código fuente, pero si lees un poco la wiki de como se crean personajes y escenarios, te da ideas sobre como tienen implementadas algunas cosas y eso ya es un inicio.
http://www.elecbyte.com/mugen
Te recomiendo darla una mirada a la documentación, pues es precisamente un motor de juegos de pelea 2d tipo Street figther, puede que te de más de una idea.

[borgo66]

Hechelion la verdad te pasaste, el código en VB no importa, supongo que en algunos días si me pongo a estudiar lo puedo comprender.
La idea de lo que hace Mugen creo que la tengo, el problema para mi es que no se como hacer para transformar un dibujo, o gráfico mejor dicho, en coordenadas para las hitboxes en pantalla. Pero de nuevo te agradezco mucho por el código.

[hechelion]

En ese caso, ¿has pensando en usar colisión por mascaras en lugar de cajas?

[shackra]

Aun no escribo ni una sola linea de codigo, pero entre los comentarios veo una solucion casi obvia.

A nosotros nos importa solo dos cosas, saber si el CPU golpio al jugador o viceversa, y el estado del otro jugador ¿Me explico porque me viene y me va la cantidad de rects para saber que parte del cuerpo colisiono el sprite golpeador? Facil, porque con solo saber si el sprite golpeador estaba con los pies en el suelo o golpeando mientras golpeaba o en ultima instancia haciendo barridas, sabremos que animacion ejecutar para el sprite golpeado en consecuencia.

Por ejemplo, si el sprite A es golpeado por el sprite B mientras est estaba saltando, ejecuta la animacion del sprite A moviendo la cabeza para atras. Si el sprite A golpea al sprite B mientras estaba agachado haciendo una barrida, ejecuta la animacion donde el sprite A se cae y se repone y asi sucesivamente.

Con mi sugerencia, veras que la cantidad de rectangulos para detectar colisiones se reduce quizas a uno o dos, haciendo más facil para ti desarrollar el juego independientemente si estas metiendo todos los personajes de Marvel, capcom, Bandai, Nintendo, etc.

No sé si me expliqué bien.
saludos!