Mappe sotterranee ricorsive come rappresentate da un array elastico 2d

8

Ho escogitato un metodo per generare ricorsivamente semplici mappe sotterranee iniziando con una stanza e collegando ricorsivamente nuove stanze adiacenti in modo casuale.

Le mappe sono rappresentate come matrici bidimensionali in cui ogni cella contiene un valore di 0-15. 0 non rappresenta spazio mentre ogni direzione è rappresentata da nord = 1, est = 2, sud = 4, ovest = 8.

Volevo iniziare con una singola non room ([[0]]) e quindi espandere l'array 2d secondo necessità per adattarlo alla mappa generata. La difficoltà che devo affrontare con questo albero come la ricorsione è che se gli array devono essere spostati per aggiungere righe e colonne a sinistra e in cima alla mappa, devo regolare la posizione corrente della funzione, a quale riga e colonna si trova . Questo fa sì che i rami separati non siano a conoscenza delle regolazioni dell'indice di array da altri rami, solo le loro funzioni figlio lo sapranno perché hanno la posizione corretta passata loro come argomenti di riga e colonna.

C'è un modo per fare questo? Ho provato a memorizzare i valori di offset di riga e colonna al di fuori della ricorsione, ma per qualche motivo non ha funzionato.

software-engineering game-mechanics level-design

5

C'è un motivo per cui è necessario utilizzare un array 2D o potrebbe funzionare una tabella hash o un altro tipo di mappa? Quindi gli indici x, y continuano semplicemente nello spazio negativo, ma non importa.

Se sei preoccupato per la memoria o la velocità della CPU, 1) Non esserlo, le tabelle hash sono molto efficienti in cose come coppie di interi densi, 2) puoi costruire il livello in una tabella hash e poi elaborarlo in un array una volta che conosci la dimensione finale.

quindi la funzione hash accetterebbe un argomento x e ay e questo verrebbe mappato sostanzialmente su un array associativo con chiavi come 1x1, -1x3, ecc?

Si. In C ++ userei solo uno std :: pair <int, int>; in Python, un dict con (x, y) tuple per le chiavi. Non sono sicuro di quale lingua stai usando.

2

Sto facendo una cosa simile, in Python. (O almeno la parte elastica).

Ho un dizionario di (x, y) tuple che mappano alle celle. In pseudo codice:

map = dictionary( (0,0) : cell at (0,0), (1,0) : cell at (1,0) ... (2, 2) : cell at (2,2)
getCell(x,y):
    return map[(x,y)]
    catch error if out of bounds:
         map[(x,y)] = new cell and return

Una tabella hash sarebbe molto buona per questo tipo di cose.

— L'anatra comunista
fonte

1

La soluzione del minimo sforzo è quella di scegliere una dimensione massima (estensione X e Y) che si desidera raggiungere nel dungeon, posizionare il punto di partenza al centro e non consentire la crescita al di fuori di esso. Non c'è bisogno di fare alcun cambio. Dipende dal fatto che una misura fissa sia accettabile, ovviamente.

— caos
fonte

-1

Si desidera utilizzare un grafico anziché l'array 2D.

Ogni stanza sarebbe un nodo nel grafico e sa quali altre stanze sono adiacenti ad essa:

Room {
    long x;
    long y;
    List adjacentRooms;
}

In questo modo non devi definire quanto può diventare grande la tua mappa.

Le coordinate x, y possono essere utilizzate come chiave univoca in una hashmap per un rapido accesso a ciascuna stanza. L'aggiunta di una nuova stanza aggiungerebbe semplicemente voci agli elenchi delle stanze adiacenti delle stanze vicine.

Il grafico è ottimo anche per gli algoritmi di ricerca del percorso, se ne hai bisogno.

— Stefano
fonte

Ciò funzionerà male e richiederà molta più contabilità di una tabella o matrice di hash. Non c'è alcun vantaggio nelle stanze che hanno sia una chiave hash X, Y che formano un grafico diretto.

Come faresti ad accedere rapidamente alle stanze con solo il grafico diretto? Come faresti la ricerca del percorso solo con una chiave hash X, Y? Ciò richiederebbe una logica aggiuntiva per determinare le stanze adiacenti. La chiave hash è davvero solo un'altra visione del mondo di gioco. Concordo sul fatto che la gestione di un grafico è più un problema, ma trarranno vantaggio gli algoritmi che utilizzano il grafico. Le prestazioni dipendono dalle dimensioni del mondo di gioco. Quindi questo deve essere prototipato. Grazie per il voto negativo. Saluti!

— Stephen

Nulla nel pathfinding preclude l'uso di un hash di coppie X, Y. Gli stati successivi sono stati successivi, non importa se si mantiene un grafico pazzo o lo si cerca su una tabella hash, tranne per il fatto che la tabella hash è più veloce e utilizza meno memoria.

La soluzione chiave hash è meno astratta. Come ho scritto prima, il Pathfinder deve sapere quali stanze sono adiacenti l'una all'altra, come calcolare la distanza dalla stanza target ecc. Inseriresti la conoscenza del mondo di gioco nel tuo algoritmo di ricerca del percorso. Se l'impostazione del mondo di gioco cambia, ad esempio è consentito il movimento da stanze diagonali tra loro o viene aggiunta una terza dimensione, è necessario modificare ogni algoritmo che accede al mondo di gioco. I grafici lo rimuovono. Niente di pazzo. Ci sono sempre degli svantaggi in ogni soluzione.

— Stephen

1

"I grafici lo sottraggono." Lo stesso vale per qualsiasi iteratore, generatore, coroutine o metodo di costruzione di elenchi e non richiedono il gonfiamento della struttura O (n) né più contabilità in fase di compilazione.