Rallentamento delle prestazioni su un'implementazione A * in un gioco di difesa della torre

Sto realizzando un gioco di Tower Defense in Flash senza percorso predefinito.

Sebbene la mia griglia sia 40x40 (piccola?), A * è in difficoltà quando ricalcola ogni volta. Quindi ho apportato le mie modifiche per facilitare il ricalcolo e il conteggio delle celle toccate è sceso a circa 900 (quando si modifica vicino alla radice). Si blocca ancora per un periodo di tempo molto breve, ma rilevabile, quando viene posizionata una nuova torre.

È un problema di implementazione o 40x40 è troppo?

Modificare:

La struttura del mio codice:

• Tutti i dati vengono salvati in 2d array di celle.
• Ogni cella contiene il suo genitore nella direzione del percorso (1-8 in senso orario) e l'array con codifica bit a bit dei suoi figli nel percorso (ogni bit rappresenta un figlio).
• La ricerca viene eseguita da A * con la stima della distanza euclidea.

Non posso commentare, ma primo profilo in Flex, tutto il resto è congettura.

Suppongo che TD sia "Tower Defense"

Penso che A * stia andando un po 'fuori bordo per questo.

All'inizio del gioco, riempi l'area di gioco dai punti di uscita per creare una mappa di movimento:

 |---------|
 |5|4|3|3|3|
 |5|4|3|2|2|
->5|4|3|2|1->
 |5|4|3|2|2|
 |5|4|3|3|3|
 |---------|

e il movimento è sempre verso un quadrato con un valore inferiore.

Quando il giocatore piazza una torre, aggiorna ciascuno degli otto quadrati adiacenti: per ogni quadrato, imposta il suo valore di movimento su uno in più rispetto al valore adiacente più basso. Se il valore cambia, ripetere il processo centrato sul quadrato aggiornato. Quindi, per verificare che il percorso verso l'uscita non sia bloccato, assicurarsi che tutti i quadrati siano adiacenti a un quadrato di valore inferiore.

Quando il giocatore rimuove una torre, imposta il valore di movimento su uno in più rispetto al quadrato adiacente più basso e ripeti il ​​procedimento sopra.

Un approccio più semplice sarebbe quello di rifare il riempimento.

Strano, pensavo di aver risposto, ma la risposta sembra essere sparita. Rendi il tuo algoritmo di ricerca in modo che possa essere aggiornato in più passaggi, in modo che quando posizioni una torre e riproduci un'animazione, puoi fare un po 'ogni fotogramma e avrai un punto tra mezzo secondo e un secondo per aggiornare il tuo A * senza una pausa evidente. È latenza: se non riesci ad accelerarlo, trova un modo per nasconderlo. Riprodurre un'animazione mentre si posiziona una torre sarebbe naturale per un gioco e sarebbe un buon posto per nasconderla.

Per cominciare, è possibile modificare l'array in un vettore, che dovrebbe offrire alcuni miglioramenti della velocità. Pubblica il codice e potremmo essere in grado di suggerire ulteriori ottimizzazioni.

Immagino che il tuo rallentamento sia perché stai calcolando un percorso per tutti i personaggi contemporaneamente. Calcolare un percorso per un personaggio è veloce ma se ci sono due dozzine di personaggi nella scena, allora può impantanarsi.

Invece dovresti distribuire il carico su alcuni frame. Scaglionare i tuoi aggiornamenti AI in modo che personaggi diversi aggiornino il loro percorso su frame diversi. Sarebbe davvero evidente se un personaggio non reagisse fino a un secondo dopo, ma solo un fotogramma non causerà reazioni negative.