¿Cómo manejo la detección de colisión para que los objetos rápidos no puedan atravesar las paredes?

Estoy creando un tirador 2D de desplazamiento lateral, y estoy teniendo un pequeño problema con la detección de colisión de las balas. Todo, incluidas las viñetas, son objetos con sus propios polígonos / métodos de actualización.

El problema es que las balas van rápido, y a 60 cuadros por segundo (en qué se ejecuta el juego) una bala saltará a menudo a través de una pared, ya que se mueve más del ancho de la pared durante el intervalo de actualización, y continúe felizmente en su camino ya que los polígonos nunca se superpondrán realmente.

¿Qué puedo hacer sobre esto? Lo único que he podido encontrar es dibujar una línea desde la posición anterior a la nueva posición y hacer una detección de colisión en eso, pero la documentación de slick2d recomienda el dibujo de línea para la detección de colisión. ¿Como puedo resolver esto?

Los enfoques estándar son (elija uno):

1. Aumente su ancho de límite Y / O reduzca la velocidad máxima de su bala para que nunca pueda saltar a través de una pared en una sola actualización (requiere un poco de Pitágoras para calcular las distancias máximas / anchos de límite mínimos);
2. Realice la detección de colisión continua (CCD), generalmente mediante la emisión de rayos para detectar la colisión con superficies lineales (2) o planas (3D) delante del objeto en movimiento. Esto es más costoso, pero es una solución más completa. Raycasting contra líneas 2D es bastante básico, pero necesita definir todos sus límites como polígonos de borde recto en este caso.

Para el caso, puedes modelar tus balas como rayos, si eso encaja con la apariencia de tu juego, como en left4kdead . De esa manera no es necesario aproximar las balas como rayos, porque ya son rayos. Desde el punto de vista de la apariencia, esto puede verse decente si dibuja la línea con un punto más brillante en el extremo de la viñeta, o simplemente dibuja la línea como un gradiente de claro (extremo de la viñeta) a oscuro (extremo de la cola), dándole una apariencia de movimiento.

Estoy de acuerdo en que, en la mayoría de las circunstancias, el uso de gráficos para la detección de colisiones es un poco equivocado, sin embargo, la detección de colisiones con píxeles perfectos es exactamente eso, y es una técnica aceptada. Supongo que todo depende de lo que quieras lograr y de qué tan rápido. Si no necesitas un juego muy rápido con muchos cuerpos + acción, anímate. De lo contrario, es mejor usar uno de los enfoques que describí anteriormente.

Si desea que sus balas se comporten como objetos físicos realistas (por ejemplo, sus balas son más como flechas o piedras de una catapulta en lugar de disparos), entonces también puede intentar aumentar la frecuencia de sus actualizaciones físicas.

Entonces, aunque su juego podría ejecutarse con 60 fotogramas por segundo, su simulación física podría ejecutarse a 120 actualizaciones por segundo (aquí está el artículo de corrección ubicua de su paso de tiempo que explica una buena configuración física que puede ejecutarse a una velocidad diferente que el bucle de renderizado).

Por supuesto, aumentar el intervalo de actualización en el motor de física pondrá una mayor carga en la CPU. Por lo tanto, este enfoque solo es sensato si sus proyectiles no se mueven muy rápido (lo que suponía ya que puede decir que sus proyectiles se mueven en arco).