Programación Específica > Programación de Videojuegos
Administracion De Colisiones
bob esponja:
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 :P 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.
JuanK:
lo ideal es no hacer uso de eventos para este tipo de cosas.
No se como lo estas haciendo pero asumo que 'personajes' y objetos estan en una o varias listas,
lo que yo haria ( y de hecho lo hice si revisas la documentacion de FMC) es incluir un proceso de deteccion de las colisiones para cada uno de los objetos involucrados, esto en el ciclo del videojuego es necesario hacerlo por cada objeto, es decir
se supone que estos son los pasos basicos:
loop
- proceso sig cuadro
- dibujo
- capturar dispositivos de entrada
end loop
en el proceso del siguiente cuadro, el cual recorre la lista de objetos para determinar que se hara con cada uno, se debe determinar con que otroes elementos el objeto entra en colision y de acuerdo a ello cambiarlo a un estado determinado.
bob esponja:
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" :P, 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 )
JuanK:
bueno depende del dimensionamiento que le des a lo que piensas hacer...
si es para juegos de baja resolucion y casi 100% tiles cuadrados no hay problema y de hecho hay formas mucho más eficientes de implementar las colisiones, pero si lo que necesitas es mas elaborado es lo mejor.
Hay que tener contemplado el diseño en todo esto como bien lo has dicho.
Por ello la manera en que cada objeto puede saber el estado de los demas deberia ser a traves de un metodo capas de recibir una referencia al array de los demas objetos o al menos a un array donde se encuentre la posicion y estado de los demas objetos suceptibles de colisionar.
La idea es que cada opbjeto pueda acceder a esta informacion.
Lo que he hecho es utilizar un array de objetos animados (personajes) y otro artilugio para saber con que 'cosa' del escenario estoy teniendo contacto.
El primero es que cada personaje animado debe explorar para saber si tiene o no contacto con otros personajes animados y de acuerdo a un juego de estados determinar que debe suceder.
El otro es el que se usa para los escenarios, el cual puedes usar haciendo referencia al array o al manejador de escenarios para que te diga segun tu posicion en pantalla y/o en escena que debe suceder.
El acoplamiento en todo caso se mantendra alto puesto que la complejidad de los juegos lo hace necesario en especial cuando requieres intercambiar tanta informacion con los demas elementos involucrados, lo que debes procurar es aislar el acoplamiento a las capas mas superiores en el conjunto de funcionalidades y dejar las capas inferiores lo mas 'limpias' que sea posible. si lo que tratas es hacer algo completamente reutilizable como un motor tu desarrollo nunca llegaria a ser muy acoplado pero necesariamente el desarrollador que haga uso de ese motor tendrá que acoplar muchos de los componentes para poder aprovechar las funcionalidades.
Amilius:
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.
Navegación
[#] Página Siguiente
Ir a la versión completa