Come faccio a evitare che gli agenti A * siano altri agenti?

Sto implementando un algoritmo A * multi-agente su una mappa di tessere. Gli agenti si muovono solo negli assi X e Y. Evito le collisioni tra di loro controllando dove si trovano gli altri durante il calcolo dei percorsi.

Funziona bene tranne la situazione in cui gli agenti devono passare la stessa tessera da direzioni diverse. In situazioni come questa, una soluzione ottimale sarebbe che un agente aspetti che passi l'altro:

Inoltre, se non esiste un corridoio settentrionale, il rilevamento dei percorsi non riesce.

Come potrei implementare un tale algoritmo?

Puoi iniziare lasciando fallire il pathfinding. In caso di insuccesso, scegliere un orario casuale in futuro per riprovare il pathfinding. Alcuni protocolli di rete di basso livello funzionano in questo modo e abbastanza bene. Quello che devi fare è costruire i percorsi uno alla volta e contrassegnare come usate tutte le tessere attraverso cui passerà un agente. Quando ulteriori percorsi non riescono a riavviare il timer casuale aiuterà a distribuire le nuove ricerche di percorso e a interrompere gli errori di loop.

La seconda parte del problema potrebbe essere gestita restituendo due percorsi. Il primo percorso è il ritorno normale, anche se non riesce da un blocco. Il secondo percorso è un percorso che ignora completamente tutti gli agenti. È quindi possibile utilizzare le conoscenze acquisite da questi due percorsi per decidere se sarebbe meglio aspettare o fare molta strada. L'euristica per quella decisione richiederà un po 'di lavoro, ma è meglio che non provare affatto.

Nel brutto caso in cui i tuoi agenti vengono bloccati molto da corridoi a larghezza singola come questo, potresti dover aggiungere punti sicuri in cui gli agenti possono rapidamente raggiungere e attendere che il loro vero percorso si apra (quindi l'agente non aspetta e blocca un corridoio).

Invece di risolvere il tuo problema, ecco un modo per prendere i limoni e fare la limonata.

Molti anni fa un mio amico stava lavorando su un FPS molto noto che aveva esattamente il problema che descrivi: un'area vincolata avrebbe un certo numero di personaggi AI che avevano posizioni desiderate particolari e l'algoritmo di ricerca del percorso li ha costantemente colpiti l'uno nell'altro. In particolare, il giocatore, diciamo, lanciava una granata in una piccola stanza piena di nemici, e i personaggi dell'intelligenza artificiale nella zona cercavano ciascuno di correre verso la loro uscita, ma si imbattevano l'uno nell'altro e finivano per fermarsi, girandosi, colpire qualcun altro, voltarsi e così via. Questo sembra molto irrealistico.

Tentativi di creare un algoritmo di pathfinding migliore che potrebbe essere eseguito correttamente a causa del fallimento del budget computazionale. Quindi, invece di risolvere il problema del pathfinding, il mio amico ha aggiunto un controllo molto economico all'intelligenza artificiale: se un'intelligenza artificiale si è imbattuta in un'altra intelligenza artificiale due volte in un breve periodo di tempo, smetti di cercare di trovare l'uscita e invece cerca di ripararti. Quindi ora succede che il PC lancia la granata e vede un gruppo di nemici correre verso le uscite. Quelli che si colpiscono, si girano e sembra che si rendano conto di non poter uscire, quindi si abbassano e si coprono la testa appena prima di esplodere. Questo è sia realistico che altamente soddisfacente per il giocatore.

Esiste un modo simile per trasformare lo svantaggio dell'algoritmo che genera la collisione e trasformarlo in un vantaggio?

Di solito trovo migliore per aumentare A * pathing con altre forme di percorso per altri scenari localizzati; l'evitamento delle unità è di solito uno di questi, specialmente in un mondo in cui ci sono più agenti che si muovono simultaneamente e quindi creano bloccanti dinamici).

In generale, una tecnica che segue i margini può funzionare per questo. Quando stai seguendo un percorso incontrando un bloccatore che non faceva parte del calcolo del percorso originale, fondamentalmente scegli una direzione (in senso orario o antiorario) e provi a attraversare il bloccatore viaggiandolo attorno in quella direzione. Se non ci riesci, aspetti che il blocco si risolva da solo (anche se questo può provocare un deadlock).

Puoi anche implementare la capacità delle unità di seguire il percorso in modo cooperativo; cioè un'unità può chiedere a un'altra unità di spostarsi leggermente in modo da "spingere oltre" l'unità di blocco. Questo non funziona bene in un gioco basato su tessere in cui si è limitati al movimento basato su tessere, tuttavia, poiché è ancora possibile effettuare un deadlock in corridoi a larghezza singola come il tuo esempio. In tal caso è possibile prevedere che le unità si chiedano reciprocamente di "cambiare posto", il che si traduce in una risoluzione la maggior parte delle volte. Di tanto in tanto ciò porta a unità che si saltano a vicenda, però.

"Evitare l'unità" è un argomento abbastanza comune quando si parla di pathfinding nei giochi, ci sono molti successi là fuori per questo. In particolare, potresti voler dare un'occhiata a questa domanda sul pathfinding "campo di flusso" usato in Supreme Commander 2. Gli RTS di solito incontrano molto questo problema e lo risolvono in molti modi interessanti.

Se si dispone di un sistema di movimento basato su turni / tick che è possibile creare un grafico 3D in cui ogni transizione sposta l'agente nel modo in cui la mappa apparirebbe in futuro. Quindi chiedi a ciascun agente di rivendicare le tessere su cui si troverebbero in quel punto in futuro e di contrassegnarle come inaccessibili. Ogni agente ha quindi un'opzione aggiuntiva di "itingaiting" al prossimo tick come terzo modo per passare attraverso il grafico. Questo sarà più difficile sul tuo sistema, ma dovrebbe darti risultati migliori che aspettare casualmente. Ancora meglio se consenti a 2 agenti di comunicare ma uno di loro invia un messaggio "Voglio passarti" se il suo percorso più breve passa attraverso quell'agente,

Quando si utilizza un algoritmo come A * si ha la massima latitudine nel lavorare con l'euristica dei costi.

In questo caso particolare potresti adattare l'euristica per aumentare il costo dei movimenti che portano un agente vicino ad un altro agente, il problema è che probabilmente finiresti con entrambi cercando di prendere la strada superiore e potresti finire con loro oscillanti avanti e indietro tra i percorsi mentre si chiudono l'uno sull'altro a seconda del momento esatto.

Un'altra possibilità è quella di tracciare i percorsi previsti dagli agenti e regolare i costi verso l'alto lungo i percorsi previsti dagli altri agenti. Ciò consente effettivamente agli agenti di coordinarsi tra loro in misura limitata. Il problema principale qui è se tutte le rotte sono bloccate la ricerca del percorso potrebbe continuare a fallire per l'ultimo agente che si sposta.

Nel caso in cui vi sia un solo percorso, la ricerca del percorso fallirà o avanzeranno l'uno verso l'altro fino a quando non si bloccano.

Se nessuno di questi è abbastanza buono, è necessario iniziare a tenere traccia del tempo anche nel calcolo dei costi. Il costo per il secondo agente dovrebbe essere la quantità di tempo necessaria per chiarire il primo agente più il normale costo di attraversamento, in questo modo il tuo agente sarebbe in grado di decidere correttamente quando attendere rispetto a seguire l'altro percorso.

Accordare i tempi può essere significativamente più impegnativo, quindi la maggior parte delle persone si accontenta di modificare la disposizione dei livelli e i valori dei costi fino a quando le cose non sono abbastanza buone.

Normalmente ti consiglierei di usare comportamenti di guida per risolvere problemi come questo durante il percorso. E potresti ancora prendere molto su quelli per trarre ispirazione per il comportamento di gruppo. Ma sfortunatamente non è realmente direttamente applicabile per semplici movimenti basati su piastrelle.

Dal momento che hai già un modo per evitare collisioni funzionanti per la maggior parte delle situazioni, concentriamoci su questo particolare. Immagino che tu stia rifacendo il percorso ogni volta che un agente vuole muoversi, altrimenti non riesco a vedere come reagiscono agli altri che si muovono durante la loro mossa. Secondo, immagino che quegli agenti siano amichevoli l'uno con l'altro.

Suggerisci a un agente di aspettare l'altro e ti consiglierei di farlo esattamente. Dai agli agenti un modo per accedere ai percorsi degli altri, cerca la prima tessera del tuo percorso che non fa parte dell'altro percorso e vai lì. I problemi con questa tecnica possono essere:

1. Come si decide se esiste un altro modo accettabile per l'altro agente o no? Non vuoi aspettare l'altro agente se c'è abbastanza spazio per aggirarlo. Un errore di ricerca dei percorsi quando si considera l'altro agente è un chiaro segno della situazione che si desidera correggere, ma nell'esempio che si è sollevato non si verificherà un errore di ricerca dei percorsi. Ma puoi - con un po 'di calcolo - decidere se il percorso alternativo A * ti dà solo attorno all'altro agente in un piccolo cerchio, o usa un percorso totalmente diverso come il corridoio settentrionale.

2. Non so fino a che punto un agente può viaggiare durante un round / operazione, ma se ciò non è abbastanza lontano, o se tutti gli agenti si muovono in parallelo, entrambi gli agenti avrebbero deciso di attendere dall'altra parte del percorso. Questo può essere risolto segnalando all'altro agente che si libera il suo percorso.

Una delle possibili soluzioni sarebbe quella di disabilitare la collisione dell'unità in punti così ristretti.

Ad esempio nel gioco Starcraft, i lavoratori (SCV, Sonde, Droni) non si scontrano tra loro durante l'estrazione di cristalli.