Estrategias para lidiar con multitudes en los puntos de estrangulamiento

Recientemente cambié mi motor de juego de comportamientos de dirección a movimiento basado en impulsos con una resolución de colisión adecuada basada en el tiempo. Esto ha resuelto tantos problemas (no más túneles, sí) y ha hecho que la simulación sea mucho más estable. Sin embargo, con la estabilidad ha llegado un nuevo problema.

Las tres bolas comenzaron su viaje cerca de la parte inferior de la imagen, su objetivo era donde se detuvo la bola rosa. En el camino, las bolas rojas y verdes se han quedado atascadas en el punto de estrangulamiento en la pared.

Antes, podía confiar en los errores de coma flotante y la inestabilidad general de los comportamientos de dirección para hacer que las bolas verdes y rojas se empujaran entre sí hasta que lograran atravesar el punto de estrangulamiento. Ahora con una resolución de colisión adecuada, las fuerzas que actúan sobre las bolas se cancelan entre sí, lo que hace que las bolas permanezcan perfectamente inmóviles.

¿Qué métodos se usan comúnmente para resolver tales situaciones? Quizás algún tipo de sistema de colas de prioridad funcionaría, aunque puedo ver que se vuelve complejo una vez que necesito decidir la prioridad entre más de 2 objetos.

collision-resolution

— Fibras
fuente

También estoy decepcionado con la gestión de multitudes. ¿Podría agregar algunos enlaces sobre "movimiento basado en impulsos" en la pregunta?

— Kromster

Un impulso es solo fuerza * tiempo. Lo que intentaba decir era que me había mudado a un modelo basado físicamente usando detección de colisión continua en lugar de discreta. Los comportamientos de dirección realmente no respetan cosas como las leyes de movimiento de Newton, fueron diseñados para imitar bandadas de pájaros en lugar de ser una simulación física. Realmente no tengo ningún enlace de gamedev para el movimiento, en realidad es solo física de secundaria. Sin embargo, el libro Real Time Collision Detection de Christer Ericson es prácticamente el juego devible para la detección continua de colisiones.

— Fibbles

Respuestas:

Asigne a cada objeto móvil un índice único y prohíba que un objeto con un índice más alto mueva un agente con un índice más bajo. Esto permitirá que los objetos 'más viejos' empujen a los 'más nuevos', pero no al revés, y es menos costoso que hacer cola. Esencialmente, el índice actúa como una prioridad de movimiento.

— Pikalek
fuente

He implementado esto y funciona en que las unidades ya no se atascan, aunque debo decir que no siempre es bonito. Algunas advertencias: solo use el índice para determinar la prioridad para mover objetos de la misma masa, los objetos grandes deben empujar a los objetos pequeños fuera del camino de forma natural. Solo use el índice para determinar la prioridad de los objetos en el mismo equipo. Un objeto enemigo no debería poder actuar como un muro inamovible para un objeto jugador simplemente porque fue generado primero y, por lo tanto, tiene mayor prioridad.

— Fibbles

No había considerado la masa o el equipo; Sus ajustes parecen ser la forma lógica de parchear mi respuesta.

— Pikalek

agregar tiempo a la búsqueda de ruta

Aquí hay un artículo que habla sobre ese cubo de tiempo: http://www0.cs.ucl.ac.uk/staff/D.Silver/web/Applications_files/coop-path-AIWisdom.pdf

y aquí hay una implementación de Objective-C: http://allseeing-i.com/ASIPathFinder

— Rakka Rage
fuente

He leído e implementado esto antes. Incluso con múltiples hilos no es de mucha utilidad en mi situación. En un juego de estrategia en tiempo real puede haber cientos de unidades móviles y cuadrículas de mapas que son mayores de 500 casillas a un lado. La sobrecarga para calcular rutas basadas en el tiempo para cada unidad es demasiado alta. Solo para agregar, no estoy diciendo que la respuesta de rakkarage sea incorrecta, es un algoritmo muy bueno. Solo digo que las situaciones en las que es útil están limitadas por su complejidad.

— Fibbles

Sí, simplemente vuelvo a ejecutar todo mi algoritmo de búsqueda de ruta en cada turno en lugar de comprenderlo e implementarlo por completo, pero creo que eventualmente tendría que hacerlo

— Rakka Rage

En realidad, no creo que debas arreglarlo. Si (puedo adivinar) las flechas indican vectores de fuerza aplicados a cualquier esfera, en cualquier posición de la cuadrícula (probablemente interpolada "bi-linealmente" o de manera similar, o de alguna manera más "analógica" que simplemente ser 0/1), entonces el el comportamiento es físicamente correcto y debe felicitarse por tener una solución que se comporte bien.

Las 2 esferas están en un buen equilibrio, ya que se sientan allí y se odian. Aparentemente, si se mueven un poco hacia la derecha, la "flecha de fuerza" hacia la derecha afecta un poco más a la esfera del lado derecho (y viceversa en la esfera del lado izquierdo; un poco menos), por lo que retroceden para equilibrarse. Así es como debería ser.

En mi humilde opinión, lo que debe arreglarse es la pared, o los tamaños de las esferas, o algo más entre las piedras de construcción. Ha creado una imposibilidad y el comportamiento correcto en esa situación es, en consecuencia, un punto muerto (perdón por el mal uso de las palabras, espero que las obtenga de todos modos :-)).

¿Quizás deshabilitar las flechas de fuerza izquierda / derecha más cercanas, o organizarlas de alguna otra manera que no sea simétrica y no aliente el equilibrio ?

Creo que sería una mala solución arreglarlo artificialmente ... se pondría peludo demasiado pronto.

— Ventormenta
fuente

Esto no responde la pregunta. Entiendo tu motivación, pero en última instancia la pregunta es cómo lidiar con la situación. No conocemos las intenciones de juego, por lo que juzgar si esto es un problema o no depende de Fibbles. Cambiar el muro puede cambiar el propósito del punto de estrangulamiento. La pregunta es un problema válido que se puede resolver.

— Felsir

Mi respuesta es bascal: (re) organizar las fuerzas o reorganizar algo más en el escenario, pero no codificar el solucionador de física (" Imho, lo que debe arreglarse es la pared, o los tamaños de las esferas, o algo más entre las piedras de construcción ellos mismos "). La pregunta es " ¿Qué métodos se usan comúnmente para resolver tales situaciones?" Creo que mi A es en gran medida un "método de uso común" y una solución al problema. Por ejemplo, los juegos de minigolf en línea (que la Q recuerda hacer mucho) ahogan las bolas, si el entorno está pidiendo que eso suceda. La física errática es una mala manera, en mi opinión.

— Ventormenta

Estoy de acuerdo en que el solucionador de física debe permanecer intacto. La pregunta establece que las esferas deben buscar el objetivo, básicamente cómo cambiar los comportamientos de los agentes (por lo tanto, no la física o el diseño del nivel). La alteración del diseño de nivel puede resolver esta ocurrencia, pero puede aparecer en un diseño diferente. Entonces, la pregunta es diferente al ejemplo de minigolf que proporcionas, ya que en este caso la pregunta es específicamente evitar un punto muerto.

— Felsir

Como puede ver, también propongo reorganizar las fuerzas en la respuesta. Parece que queda poco después de eso :-).

— Ventormenta

Reorganizar las paredes o alterar el tamaño de las esferas no es viable en mi caso, aunque puede serlo en otros. La captura de pantalla es del modo de depuración de un motor RTS. Hay muchos tamaños de unidades diferentes y el jugador puede colocar las paredes a voluntad. Las flechas que ves son generadas por mi algoritmo de Campos de flujo rápido. Son vectores normalizados que se utilizan para influir en la dirección de desplazamiento de las unidades móviles. No es posible alterar la longitud de los vectores porque todas las unidades móviles del grupo comparten el mismo campo de flujo.

— Fibbles