¿Cómo hago para que los agentes A * eviten a otros agentes?

Estoy implementando un algoritmo A * de múltiples agentes en un mapa de mosaico. Los agentes solo se mueven en los ejes X e Y. Evito colisiones entre ellos comprobando dónde están los demás al calcular las rutas.

Funciona bien, excepto en la situación en que los agentes tienen que pasar el mismo mosaico desde diferentes direcciones. En situaciones como esta, una solución óptima sería que un agente espere a que pase el otro:

Además, si no hay un corredor norte, entonces la búsqueda de caminos falla.

¿Cómo podría implementar tal algoritmo?

Puede comenzar dejando que la búsqueda de ruta falle. En caso de falla, elija un tiempo aleatorio en el futuro para volver a intentar la búsqueda de rutas. Algunos protocolos de red de bajo nivel funcionan de esa manera , y bastante bien. Lo que debe hacer es crear rutas de una en una y marcar como usadas todas las fichas por las que pasará un agente. Cuando fallan otras rutas, el temporizador aleatorio para reiniciar ayudará a extender las nuevas búsquedas de ruta y romper las fallas de bucle.

La segunda parte de su problema podría manejarse devolviendo dos caminos. El primer camino es el retorno regular, incluso si falla desde un bloque. La segunda ruta es una ruta que ignora por completo a todos los agentes. Luego puede usar el conocimiento adquirido de estos dos caminos para decidir si esperar o tomar el camino largo sería mejor. La heurística para esa decisión tomará algo de trabajo, pero es mejor que no intentar nada en absoluto.

En el muy mal caso donde sus agentes se bloquean mucho por corredores de ancho único como este, es posible que tenga que agregar lugares seguros para pararse donde los agentes pueden dirigirse rápidamente y esperar a que se abra su ruta real (para que el agente no solo espera y bloquea un pasillo).

En lugar de resolver su problema, aquí hay una manera de tomar los limones y hacer limonada.

Hace muchos años, un amigo mío estaba trabajando en un FPS muy conocido que tenía precisamente el problema que usted describe: un área restringida tendría una cantidad de caracteres de IA que tenían posiciones particulares deseadas, y el algoritmo de búsqueda de ruta los golpeaba constantemente. Hola. En particular, el jugador, por ejemplo, arrojaría una granada en una pequeña habitación llena de enemigos, y los personajes de IA en el área intentarían correr hacia su salida, pero se toparían y terminarían deteniéndose, dándose la vuelta, golpear a alguien más, darse la vuelta, etc. Esto se ve muy poco realista.

Los intentos de construir un mejor algoritmo de búsqueda de ruta que podría ejecutarse con éxito dado el ajustado presupuesto computacional falló. Entonces, en lugar de resolver el problema de la búsqueda de caminos, mi amigo agregó un cheque muy barato a la IA: si una IA se ha topado con otra IA dos veces en un corto período de tiempo, deja de tratar de encontrar la salida y, en cambio, cúbrete. Entonces, ahora lo que sucede es que la PC lanza la granada y ve a un montón de enemigos corriendo hacia las salidas. Los que se golpean, se dan la vuelta y parece que se dan cuenta de que no pueden salir, por lo que se agachan y se cubren la cabeza justo antes de explotar. Esto es a la vez realista y altamente satisfactorio para el jugador.

¿Hay alguna forma similar de convertir la desventaja de su algoritmo de producción de colisiones y convertirlo en una ventaja?

Por lo general, me parece mejor aumentar la ruta A * con otras formas de búsqueda de ruta para otros escenarios localizados; La evasión de unidades suele ser una de ellas, especialmente en un mundo donde hay múltiples agentes que se mueven simultáneamente y, por lo tanto, crean bloqueadores dinámicos

En general, una técnica de seguimiento de bordes puede funcionar para esto. Cuando sigues una ruta y encuentras un bloqueador que no era parte del cálculo de la ruta original, básicamente eliges una dirección (en sentido horario o antihorario) e intentas atravesar el bloqueador viajando en esa dirección. Si no puede, espere a que el bloqueador se resuelva solo (aunque esto puede resultar en un punto muerto).

También puede implementar la capacidad de las unidades para encaminarse cooperativamente; es decir, una unidad puede pedirle a otra unidad que se mueva ligeramente a un lado para que pueda "pasar" la unidad de bloqueo. Sin embargo, esto no funciona bien en un juego basado en mosaicos en el que está restringido al movimiento basado en mosaicos, porque todavía puede llegar a un punto muerto en corredores de ancho único como su ejemplo. En ese caso, puede proporcionar a las unidades que se soliciten entre ellas "cambiar de lugar", lo que da como resultado una resolución la mayor parte del tiempo. Sin embargo, ocasionalmente esto lleva a que las unidades se salten entre sí.

"Evitar la unidad" es un tema bastante común cuando se discute la búsqueda de caminos en los juegos, hay muchos éxitos para ello. En particular, es posible que desee consultar esta pregunta sobre la búsqueda de "campo de flujo" utilizada en Supreme Commander 2. Los RTS generalmente se encuentran con este problema y lo resuelven de muchas maneras interesantes.

Si tiene un sistema de movimiento basado en giros / tics, podría crear un gráfico 3D en el que cada transición mueva al agente a la apariencia del mapa en el futuro. Luego, haga que cada agente reclame los mosaicos en los que estaría en ese punto en el futuro y márquelos como inaccesibles. Cada agente tiene una opción adicional de "itingaiting" a la siguiente marca como una tercera forma de transición a través del gráfico. Esto será más difícil para su sistema, pero debería brindarle mejores resultados que esperar al azar. Aún mejor si permite que 2 agentes se comuniquen, haciendo que uno de ellos envíe un mensaje de "Quiero pasar" si la ruta más corta pasa a través de ese agente,

Cuando se utiliza un algoritmo como A *, tiene la mayor libertad para trabajar con la heurística de costos.

En este caso particular, podría ajustar la heurística para aumentar el costo de los movimientos que llevan a un agente cerca de otro agente, el problema es que probablemente terminaría con ambos tratando de tomar la ruta superior, y podría terminar con ellos oscilando de ida y vuelta entre los caminos a medida que se cierran entre sí según el momento exacto.

Otra posibilidad es rastrear las rutas previstas de los agentes y ajustar los costos hacia arriba a lo largo de las rutas previstas de otros agentes. Esto efectivamente permite a los agentes coordinarse entre sí de forma limitada. El problema principal aquí es si todas las rutas están bloqueadas. La búsqueda de rutas puede seguir fallando para el agente que se mueva en último lugar.

En el caso de que solo haya una ruta, la búsqueda de ruta fallará o avanzarán entre sí hasta llegar a un punto muerto.

Si ninguno de los dos es lo suficientemente bueno, también debe comenzar a controlar el tiempo al calcular su costo. El costo para el segundo agente debe ser la cantidad de tiempo que le toma al primer agente aclararse más el costo transversal normal, de esa manera su agente podría decidir correctamente cuándo esperar en lugar de tomar el otro camino.

Tener en cuenta el tiempo puede ser significativamente más esfuerzo, por lo que la mayoría de las personas se conforman con ajustar el diseño del nivel y los valores de costo hasta que las cosas sean lo suficientemente buenas.

Normalmente, le aconsejaría que use comportamientos de dirección para resolver problemas como este durante el seguimiento de la ruta. Y aún puede tomar mucho en ellos para obtener inspiración para el comportamiento de agrupación. Pero desafortunadamente no es realmente directamente aplicable para el movimiento simple basado en mosaicos.

Como ya tiene un sistema de prevención de colisiones en la mayoría de las situaciones, concentrémonos en esta en particular. Supongo que estás volviendo a hacer la búsqueda de caminos cada vez que un agente quiere moverse, o de lo contrario no puedo ver cómo reaccionan ante otros que se mueven durante su movimiento. En segundo lugar, supongo que esos agentes son amigables entre sí.

Sugiere que un agente esté esperando al otro y le aconsejaría que haga exactamente eso. Ofrezca a los agentes una forma de acceder a las rutas de los demás, busque el primer mosaico de su propia ruta que no sea parte de la otra ruta y vaya allí. Los problemas con esta técnica pueden ser:

1. ¿Cómo decide si hay otra forma aceptable de evitar al otro agente o no? No desea esperar al otro agente si hay espacio suficiente para rodearlo. Una falla de búsqueda de ruta cuando se considera al otro agente es una clara señal de la situación que desea solucionar, pero en el ejemplo que mencionó no habrá una falla de búsqueda de ruta. Pero usted puede, con un poco de cálculo, decidir si la ruta alternativa A * le da la vuelta al otro agente en un círculo pequeño, o si usa una ruta totalmente diferente como el corredor norte.

2. No sé qué tan lejos puede viajar un agente durante una ronda / operación, pero si eso no es lo suficientemente lejos, o si todos los agentes se mueven en paralelo, ambos agentes decidirían esperar en el otro extremo del camino. Esto se puede solucionar indicando al otro agente que liberas su camino.

Una de las posibles soluciones sería deshabilitar la colisión de la unidad en lugares tan reducidos.

Por ejemplo, en el juego Starcraft, los trabajadores (SCV, sondas, drones) no chocan entre sí cuando extraen cristales.