Come si fa a seguire un percorso AI all'interno di un motore fisico 2D come farseer / box2d?


12

Sono in procinto di spostare un gioco top down 2d su cui ho lavorato in un vero e proprio motore di fisica del corpo rigido come Farseer. Fino ad ora, avevo appena inciso il mio codice fisico dove necessario.

Sto cercando di imparare il modo corretto di fare le cose qui.

Qual è il modo corretto per far sì che la tua IA segua un percorso prestabilito dopo averli resi corpi rigidi all'interno del motore fisico?

Se sulla mia mappa ho un percorso di nodi di navigazione che devo seguire dall'intelligenza artificiale, in precedenza li sposterei semplicemente lungo il percorso calcolando la posizione successiva in cui dovrebbero trovarsi per il passaggio successivo e impostandoli manualmente in quella posizione .

Ma ora sono corpi rigidi e soggetti a collisioni e forze che potrebbero colpirli e metterli fuori strada.

Quindi per far muovere l'IA credo che dovrei ora applicare impulsi / forze a loro? Non dovrei più impostare manualmente la loro posizione su ogni fotogramma.

Quindi penso di dover andare da un mondo deterministico in cui costringo l'IA a seguire rigorosamente un percorso verso un mondo non deterministico in cui potrebbero essere colpiti in qualsiasi direzione se colpiti e li spingo semplicemente verso il nodo successivo nel percorso per farli muovere.

È giusto? È così che lo fanno le altre persone?

Ciò solleva alcune domande su come evitare che la tua IA rimanga bloccata negli angoli dello scenario ora che non stanno percorrendo un percorso preciso, come gestite questo tipo di cose?

O è meglio in qualche modo mescolare i due e far sì che la tua IA segua un percorso fisso impostando la loro posizione manualmente e reagisca solo ad altre forze in determinate circostanze che puoi facilmente controllare?

Grazie per qualsiasi consiglio ragazzi.


1
+1 Sono anche abbastanza interessato a conoscere questo.
David Gouveia,

Risposte:


7

I comportamenti di guida funzionano molto bene in combinazione con un motore fisico, poiché di solito sono implementati in modo da restituire una "forza di guida" che può quindi essere applicata al tuo corpo fisico.

Per fare in modo che un'unità segua un percorso, è possibile utilizzare Seek per passare da percorso-nodo a percorso-nodo (assicurarsi di evitare il superamento) e quindi utilizzare Arrivo all'ultimo nodo del percorso.

Per quanto riguarda le tue preoccupazioni su come rimanere bloccati: modellare il percorso che segue usando le forze dovrebbe in realtà essere abbastanza preciso. Hai ragione sul fatto che un oggetto potrebbe essere gettato fuori dal percorso se si scontra con un altro oggetto, ma poiché calcolerai una forza di governo in ogni aggiornamento, l'oggetto dovrebbe essere di nuovo in pista in pochissimo tempo. Se la deviazione dal percorso dopo una collisione può potenzialmente essere enorme, allora ti suggerisco di ricordare la tua ultima posizione ogni volta che si verifica una collisione e quindi riportare l'oggetto all'ultima posizione prima di continuare il percorso normale.


Articolo straordinario, grazie per la condivisione. Mi ha salvato la giornata.
Ricardo Sanchez-Saez,

0

Direi che sei sulla buona strada, potresti voler guardare questo articolo:

http://www.policyalmanac.org/games/aStarTutorial.htm

Spiega alcune funzioni di base per evitare le collisioni e individuare i percorsi usando l'algoritmo A *.

Modificare:

Se hai davvero bisogno solo di quale sia il modo migliore di spingere i tuoi oggetti nella giusta direzione, allora dovresti usare una forza (diciamo, MovementForce o qualcosa di simile) che punta nella direzione del percorso migliore che hai trovato usando l'algoritmo di rilevamento del tuo scelta


Non penso che l'articolo sia rilevante per questa domanda. L'OP non sta chiedendo come trovare il percorso ottimale tra due posizioni, ma piuttosto come fare in modo che un attore segua un percorso che ha già calcolato, nel contesto di una simulazione fisica.
David Gouveia,

bene, quando lo
rileggo

:) Ho cambiato anche il titolo per chiarire le cose. Sicuramente interessato a seguire il percorso piuttosto che a trovare il percorso.
TerryB,

0

A giudicare da ciò che @davidluzgouveia ha commentato sul post di Anonymly, farò apparire il mio progetto. Il percorso e la ricerca del percorso sono tuttavia molto diversi. La ricerca del percorso è più di ciò che anonimamente pubblicava, e per la ricerca del percorso guarderei all'algoritmo di Dijkstra. Per il percorso che segue uso interamente il mio motore di fisica scelto. Il modo in cui l'ho impostato è che ogni posizione in cui cammina una classe di unità, è impostata nella sua sottoclasse di tracciamento tramite offset 2D, sì, sono 2D e non 3D, questo è dovuto al modo in cui ho impostato la mia fisica nel mio gioco .

Spiegazione 3D: ogni unità ha un solo collettore principale impostato esclusivamente per la collisione con il terreno e gli oggetti del mondo. È una forma a capsula e ha un raggio e un'altezza programmaticamente parlando. È costruito al centro del modello e dovrebbe estendersi appena oltre la parte anteriore e superiore del modello. Ma ho anche un offset di superficie per quanto è lontano da terra in ogni momento, e un galleggiante di quanto è permesso scivolare giù prima di rimbalzare leggermente, alla volta. Sembra che stia applicando una sorta di soluzione sbagliata per un problema di collisione del terreno, ma ho le mie ragioni.

Ad ogni modo, dovresti applicare forza a questo oggetto capsula e dovrebbe rimanere sempre sospeso sopra il terreno. Questo non vuol dire che non può andare più in alto, solo che non può andare più in basso. Il motivo per cui deve rimanere sospeso (nel mio caso) è perché in un corpo rigido e un motore fisico ragdoll, le gambe delle mie unità sono animate proceduralmente. Quindi applicando una semplice forza alla capsula, le gambe della mia entità si riposizioneranno da sole. Avranno anche le loro applicazioni di gravità separate! Ciò che fa è che se il mio personaggio è inclinato, un piede può trovarsi ad un'altezza inferiore rispetto all'altro.

Questo è esattamente come dovresti farlo. A giudicare da ciò che stai chiedendo è. Se vuoi tralasciare alcune funzionalità, ovviamente va bene, soprattutto se si tratta di un RTS o FPS e nessuno vedrà mai i piedi delle unità o si preoccuperà comunque. Ma in generale, l'unità dovrebbe avere un oggetto di collisione PRINCIPALE che funziona quasi esclusivamente con il movimento del personaggio.

In particolare 2D: dovresti comunque avere un punto principale, o solo una sorta di riferimento, per far muovere il motore che è per il movimento di un'unità. Puoi dare ad ogni unità una sottoclasse di tracciamento che ha alcune posizioni che deve percorrere, puoi specificarla nel codice di livello, (ad es. Posizione1 (x, y) posizione2 (x, y) ecc.) Il modo migliore (io don sapere a che tipo di gioco stai lavorando) probabilmente per specificare le posizioni nel livello e far sì che ogni unità le elabori nell'ordine specificato dal livello e dopo aver raggiunto ogni posizione, far sì che sostituisca la posizione desiderata con il prossimo deve arrivare.

Ci sono molti modi in cui puoi modificarlo, come avere un elenco di posizioni in primo luogo per ogni unità, poiché ciò significherebbe che non tutte le unità devono andare nelle stesse posizioni. Tuttavia, allo stesso modo, è possibile farlo anche nel codice di livello (unit1.location1 (x, y) unit1.location2 (x, y) grunt.l1 (x, y) knight.loc3 (x, y) qualunque cosa)

Solo alcune idee! Ti suggerisco di leggere la versione 3D anche se è molto meno rilevante.

EDIT: Ho deciso di fornire entrambi per chiunque potesse leggere questo (Sì, è vero) .... (Inizialmente ho solo scremato la tua domanda e non mi sono reso conto che era piuttosto specifico per il 2D fino a quando non l'ho riletto>.>)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.