Un * algoritmo per i giochi di ruolo tattici?

Sto scherzando con la scrittura di un gioco di ruolo tattico davvero scadente in C ++. Finora ho una mappa di tessere 2D e ho appena fatto funzionare l'algoritmo A * basato sullo pseudocodice in Wikipedia .

Ma i veri giochi di ruolo tattici non solo trovano il percorso migliore su un piano piatto e si spostano lì. Di solito hanno intervalli di movimento limitati e devono salire o scendere. Se hai mai giocato a Final Fantasy Tactics, queste sarebbero influenzate dalle statistiche Move e Jump. Questo è dove mi perdo. Come posso modificare l'algoritmo A * in modo che trovi il percorso migliore verso un bersaglio, ma il percorso è lungo solo un numero di tessere? Come devo prendere in considerazione le differenze di altezza e saltare le statistiche? Come posso implementare saltare un gap?

Se aiuta, in questo momento la mia mappa è rappresentata da un vettore di oggetti Tile. Ogni riquadro ha puntatori al riquadro Nord, Sud, Est e Ovest, che sono impostati su nullptr se non esiste alcun riquadro, ad esempio lungo il bordo della mappa o se un riquadro è impostato su non passabile.

L'arrampicata e le lacune sono solo diverse funzioni di costo. Per un'unità che può saltare il divario ha un costo normale (?), Mentre per un'unità che non salta ha un costo arbitrariamente alto. Costi di arrampicata extra, così come terreni difficili, ecc. L'algoritmo A * è in grado di gestire le funzioni di costo, quindi se l'implementazione non lo sta già facendo, basta cercare su Google come implementare A * con una funzione di costo.

Detto questo, tuttavia, non credo che A * sia un approccio particolarmente valido per un gioco di ruolo tattico. O più precisamente, non è una storia completa. Non vuoi che le tue unità sbagliano alla cieca verso il loro obiettivo, vuoi che si posizionino per sfruttare la copertura, l'altura, qualunque cosa, mentre avanzano verso l'obiettivo finale e cercano di affiancare gli avversari e così via. Quindi il valore tattico del punto finale di ogni mossa è di enorme importanza, non solo quanto vicino è l'obiettivo. Ciò richiede una risoluzione dei problemi più approfondita rispetto alla semplice ricerca di percorsi.

Quando vuoi tutte le possibili opzioni di movimento di un'unità, usa l'algoritmo di Dijkstra .

La differenza tra A * e Dijkstra è che Dijkstra ti offre tutti i percorsi più brevi possibili raggiungibili con un dato costo, e se nessuno di essi raggiunge ancora la destinazione, aumenta il costo di uno e continua. A *, d'altra parte, preferisce calcolare prima quei percorsi che hanno buone probabilità di raggiungere la destinazione.

Quindi quando vuoi solo il percorso più breve dal punto A al punto B, allora A * è una buona scelta. Ma se vuoi tutte le possibili opzioni di movimento e il percorso più breve per ognuna di esse, Dijkstra è esattamente quello che vuoi.

Tutto quello che devi fare è eseguire l'algoritmo di Dijksta senza un nodo di destinazione specifico, ma con un costo massimo che non deve essere superato (il raggio di movimento dell'unità). Quando si viaggia in un nodo supererebbe il costo massimo, non visitarlo. Quando l'algoritmo termina a causa della mancanza di bordi non visitati, ogni nodo nel set visitato è una destinazione possibile e i marker di nodo precedenti dei nodi formano un elenco collegato che rappresenta il percorso di ritorno al nodo iniziale.

Per quanto riguarda i salti: quelli possono essere rappresentati come ancora un altro vantaggio sia in A * che Dijkstra. Possono avere lo stesso costo di attraversare un bordo normale o uno diverso. È inoltre possibile passare un parametro "jump_height" all'algoritmo che indica all'algoritmo di ignorare i jump-edge che superano una determinata altezza.

Le altre risposte hanno alcune buone informazioni, quindi assicurati di leggerle.

Tuttavia, per rispondere alla tua domanda: in base allo pseudocodice a cui ti sei collegato, hai una sorta di funzione in heuristic_cost_estimatecui stai calcolando il costo da tileA a tileB (supponendo che siano adiacenti). Invece di usare un flat (1) per quel costo, dovresti modificarlo per includere le statistiche delle tessere e le statistiche delle unità, e possibilmente le statistiche sui bordi.

Per esempio:

if (edge == JUMP && !unit.canJump()) 
    return INF;
if (tile.Type == Forest && unit.moveType == HORSE) 
    return 2;
//Other cases here
//-----
else 
    return 1;

Questo ti darà il tuo percorso. Quindi, dovrai semplicemente spostare l'unità lungo il loro percorso mentre consumano punti movimento e fermarli quando rimangono Punti <edgeCost. Nota che questo potrebbe non essere del tutto ottimale se finisci con rimanendo Punti = 1, ma dovrebbe essere abbastanza buono per un gioco di ruolo pratico. In realtà, vorresti più tattico, come ha sottolineato Jack Aidley!

Sfida:
se vuoi diventare più avanzato, probabilmente vuoi usare Djikstras come suggerito per trovare tutti gli spazi entro la distanza X, quindi vuoi valutare ogni spazio in quella lista per un posto "migliore", in base alla vicinanza al bersaglio, alla difesa potere, indipendentemente dal fatto che tu possa essere attaccato o meno da quella posizione, ecc. In base a tali informazioni, sceglieresti una tessera, quindi ti sposteresti seguendo il percorso che hai appena calcolato usando Djikstras.

L'arrampicata e le lacune sono piuttosto banali poiché modificano solo i costi. Il pathfinding (e la maggior parte dell'intelligenza artificiale tattica) consiste nel sommare il costo su tutti i nodi da visitare e minimizzarlo. Una scogliera invalicabile avrà un costo infinito (molto, molto alto), le pendenze avranno un costo più elevato del normale, ecc.

Questo, tuttavia, trova il percorso ottimale a livello globale che non è la soluzione migliore perché i veri avversari di solito non trovano il percorso ottimale. È altamente irrealistico, a volte fino a un punto che è ovvio per il giocatore, e fastidioso (specialmente quando l'IA in quanto tale è sostanzialmente invincibile perché anch'essa sceglie l'ottimale).

Le buone simulazioni non trovano deliberatamente il percorso migliore. Un algoritmo molto migliore potrebbe essere la ricerca gerarchica di percorsi - se non altro, tracciando una linea retta sulla mappa e prendendo 4-5 waypoint, quindi la navigazione da un waypoint a quello successivo, considerando solo i pesi dei nodi che sono così lontani noto e impostando tutti gli altri pesi del nodo su "indifferenti". In alternativa, è possibile eseguire prima A * su una griglia più grossolana, quindi il percorso da un nodo grande a quello successivo (ma suppongo che anche disegnare una linea sulla mappa vada bene).

Questo è molto più realistico (e consuma anche una frazione della potenza di elaborazione perché il grafico è molto più piccolo). Sì, può significare che un'unità si sposta verso una scogliera solo per scoprire che non può attraversare. Va bene, succede anche ai veri avversari. La prossima volta non accadrà più (perché ora è noto il costo infinito).