SoloCodigo

Bueno, sigo con mis molestias, es debido a que estoy haciendo una especie de base generica de videojuego en la cual se puedan construir simples juegos 2D y lo quiero hacer lo mas descentralizado posible.

el problema de hoy    es el siguiente:

para detectar las colisiones pretendo que los elementos colisionables se agreguen a una lista y esta chequee las colisiones entre los objetos y genere un evento añadiendo los elementos que colisionaron entonces los objetos que estan en esa lista tienen un callback para eventos como el que les comente antes ( que ya funciona ) y al recibir la llamada actuan en consecuencia.

que opinan. existe algun metodo mejo? mas eficiente?

mis consultas son para discutir las formas mas adecuadas de resolver problemas que todos en todos los juegos tienen, pretendo encontrar la mejor forma.

mas o menos lo que vos planteas es lo que quiero hacer, pero no entendi bien en tu planteo quien es el que se fija si hay colision, porque si cada objeto ve si colisiona, cada objeto debe tener conocimiento de todos los otros elementos y eso es algo asi como "alto acoplamiento"  , lo que yo busco en el esquema es que la logica de los objetos solo se encargue de actuar ante situaciones especiales y que de la deteccion de colisiones y eventos y de dibujarlos se encargue otra clase ( la clase Game )

Pues yo entendi que el detector de colisiones es el que hace el ciclo con todos los objetos en pantalla.  

Pero se podria generalizar a un detector de colisiones que sirviera incluso para juegos 3d, haciendo el proceso preliminar para determinar si dos sprites estan lo suficientemente cerca como para colisionar.  Luego pasariamos a un proceso más fino y especifico de colisiones 3d o deteccion de colision por pixeles.

Este proceso preliminar tendria mucha importancia para ganar en eficiencia, para no tener que usar los procesos mas detallados y pesados con todos los objetos.

Y el problema principal es que detectar colisiones "todos contra todos" es un algoritmo cuyo consumo de CPU se incrementa geométricamente al incrementar el numero de sprites en el juego.

------- Al grano: (Es complicado pero creo que seria mas eficiente)

La idea es evitar hacer el test de colision básico con todos los objetos, solo con aquellos suficientemente cerca para tener chances.

Por ejemplo tener dividido toda la zona del juego en varias areas, no demasiado grandes que contengan demasiados sprites ni tan pequeñas que haya que actualizar frecuentemente las listas de sprites por zonas. Cada zona tendria una lista dinámica de sprites. Al moverse un sprite a otra zona tendriamos que moverlo a la lista de esa zona.

Para detectar colisiones solo tendriamos que revisar entre los sprites de la zona actual y si esta muy cerca de otra u otras zonas, lo suficiente para hacer colision, revisar tambien en esas listas.

Si por ejemplo tenemos 1000 sprites en todo el mapa de juego, pero en nuestra zona sólo tenemos a 3 sprites ganamos muchisimo al evitar comprobar colisiones con los otros 997. Y asi reducimos el tiempo de CPU necesario para calcular si podemos mover o no a nuestro sprite, claro que existe algo extra de consumo de CPU para revisar si hemos pasado a otra zona y en ese caso modificar las listas, pero esto solo lo hacemos una vez por sprite. Asi que el tiempo de CPU no se incrementa geometricamente como seria el caso de aumentar mas sprites a nuestro juego y seguir con el proceso de revisar todos contra todos.

Pero esto no solo se queda en colisiones, tambien sirve para determinar los sprites suficientemente cerca para ser por ejemplo atacados, potenciales enemigos, para envio de mensajes entre sprites que colaboran entre si, o para saber cuales sprites estan suficientemente cerca de la zona que tenemos que dibujar para mostrarlos en pantalla.

la idea de amilius esta muy buena.

sobre lo que yo planteo los beneficios que encuentro son:

no tenes que plantear en cada objeto suceptible a ser colisionado la logica de deteccion de colisiones sino en un lugar central, cada objeto 'colisionable' solo deberia tener la logica de que hacer cuando colisione.
 En cuanto a evitar controles innecesarios, y sin tener en cuenta el enfoque de amilius, si un metodo chequea las colisiones de todos los que contiene en una lista se pueden evitar controles innecesarios.

por ejemplo cuatro objetos A B C y D.
los tengo en la lista.
chequeo su A colisiona con B, C o D.
cheque si B colisiona con C o D ( ya que A colision B es igual a B colision A )
chequeo si C colisiona con D.

y listo 6 controles.

en cambio si cada elemento tuviera una lista de los otros seria 4 ( objetos ) x 3 ( elementos en su lista ) = 12 ( controles ).
imaginense para numeros mayores por ejemplo 100  

y si se le agrega el control con zonas ( que seria especifico para cierto tipo de juegos y no se si generalizable o util a todos ) esto seria una mejora de eficiencia importante.

Para el problema del acoplamiento mencionado al principio puedes usar un patron tipo "concentrador". En cuanto a lo de la reduccion de calculo de colisiones, las soluciones propuestas son similares a los planteamientos básicos de BSP y portales.

Camilo.
Grupo PENTEX