È meglio codificare i dati o trovare un algoritmo?

8

Ho lavorato su un gioco da tavolo che ha una griglia esadecimale come questa tavola:

Poiché la scheda non cambierà mai e gli spazi sulla scheda saranno sempre collegati agli stessi altri spazi circostanti, dovrei semplicemente codificare ogni spazio con i valori di cui ho bisogno? O dovrei usare vari algoritmi per calcolare collegamenti e attraversamenti?

Per essere più specifici, il mio gioco da tavolo è un gioco a 4 giocatori in cui ogni giocatore ha una griglia esadecimale 5x5x5x5x5x5 (di nuovo, l'immagine sopra). L'obiettivo è quello di andare dal fondo della griglia verso l'alto, con vari ostacoli, e ogni giocatore può attaccarsi a vicenda dal bordo della griglia su altri giocatori in base a un moltiplicatore di distanza.

Dal momento che la griglia dei giocatori non cambierà mai e la distanza di qualsiasi spazio arbitrario dal bordo della griglia sarà sempre la stessa, dovrei semplicemente codificare questo numero in ciascuno degli spazi, o dovrei ancora usare un ampio algoritmo di ricerca quando i giocatori stanno attaccando?

L'unica cosa che mi viene in mente per la codifica di tutto è che sto andando a codice 9+ 2 (5 + 6 + 7 + 8) = 61 singole celle. C'è qualcos'altro che mi manca che dovrei considerare di utilizzare algoritmi più complessi?

algorithm procedural-generation hexagonal-grid

— OghmaOsiris
fonte

Posso dirti che l'area per un attacco di raggio è 1 più la somma dei termini della sequenza data da f (n) = 6 (n-1) da n = 1 a n = x dove x è il numero di righe. EG 3 file (raggio di 10 piedi) = 1 + 6 + 12 = 19

— eazimmerman

Ecco lo pseudocodice di ciò che ho descritto

int numberOfHexagonsInArea(int rows)   {    	int area = 1;   	while(rows>0)   	{   		area += (rows-1)*6;   		rows--;   	}   	return area;   }

— eazimmerman il

Non sembra molto difficile? Da {X,Y}te ovviamente puoi andare {X-1, Y}e {X+1, Y}sulla stessa riga. Nelle righe sotto e sopra puoi andare a {X, Y-1}e {X, Y+1}. Infine, a seconda del uniforme-ness Y, si può andare a {X-1, Y-1}e {X-1, Y+1}o {X + 1, Y-1} `e{X+1, Y+1}

— MSalters

12

Immagino che prenderò il contrappunto qui e discuterò contro l'uso di valori statici. In questo caso, tutte le regioni esadecimali di cui stai parlando sono (a) facili da calcolare - non è necessario utilizzare BFS o qualcosa di così complicato; dovresti essere in grado di iterare su tutti gli esagoni in ognuno di essi con loop doppi annidati; e (b) non qualcosa che dovrai calcolare 'al volo' molto spesso. Nel peggiore dei casi si dovrebbe solo bisogno di calcolare una volta per turno, e se più sistemi non vogliono che le cellule toccati da un effetto allora si può facilmente memorizzare nella cache i valori fuori in un array di 'reachableCells' o qualcosa di simile; a prescindere, il calcolo è così semplice che dovrebbe essere effettivamente gratuito in termini di costi per fotogramma.

Quindi cosa ottieni? Flessibilità. È facile dire adesso che questi valori non cambieranno mai, ma i giochi hanno un talento per sorprenderti; anche se è più probabile che queste regioni non cambino, non si rinuncia praticamente a nulla costruendo quella flessibilità, e ci sono buone probabilità che il futuro ti ringrazierà lungo la strada. Inoltre, anche se queste sono le regioni finali che usi, i loop ben scritti per iterare sulle regioni saranno sostanzialmente più facili da capire e eseguire il debug di qualsiasi tipo di array a tessere fisse. Semplicemente non vedo alcun guadagno significativo se si utilizzano dati hardcoded rispetto ai vantaggi di andare dall'altra parte.

— Steven Stadnicki
fonte

11

Se i valori non cambieranno mai, potrebbero anche essere statici. Perché perdere tempo con la CPU ricalcolando qualcosa che sarà lo stesso dell'ultima volta?

Tuttavia, non devono necessariamente essere "codificati":

È possibile inserire i valori in un file di dati e caricarli all'inizio.
È possibile eseguire la ricerca durante la riproduzione e memorizzare nella cache i valori una volta trovati.

Il primo modo ha senso se pensi di poter cambiare la forma o la dimensione della mappa in futuro. Il secondo modo ha senso se il calcolo dei valori statici è un po 'complicato.

Non ho idea di come sia una mappa esadecimale a sei dimensioni o perché ci siano 9 + 2 (5 + 6 + 7 + 8) celle coinvolte, ma il miglior risultato per la tua situazione - e in effetti la maggior parte delle situazioni nella programmazione del gioco - è codificare qualunque cosa ti ottenga il risultato corretto più rapidamente. Se lo desideri, puoi generalizzarlo in un algoritmo in un secondo momento. "Codice per oggi", come dicono alcuni.

— Kylotan
fonte

Tutto questo. Prima fatelo funzionare, poi placate l'ego;)

— Mike Cluck,

2

Solo per chiarire la tua confusione, penso che l'OP quando si riferiva a una griglia esagonale 5x5x5x5x5x5 non si riferisse a 6 dimensioni fisiche (o virtuali), ma invece a un esagono di esagoni, in cui ciascun lato dell'esagono contiene 5 esagoni più piccoli lungo la sua lunghezza, simile a questo (ignora i punti neri). In tal caso la scheda dovrebbe contenere 9 + 2 (5 + 6 + 7 + 8) celle.

Sì, l'ho visto dal diagramma pubblicato in una modifica.

— Kylotan,

0

Q: è questo l'unico gioco esadecimale che tu abbia mai scritto? No?

A: Quindi ovviamente dovresti cercare di essere flessibile ovunque non ti costi un grande sforzo extra. Indipendentemente da come si definisce la scheda, rappresentarla in fase di esecuzione con collegamenti espliciti. È molto conveniente codificare il movimento e la logica delle relazioni in termini di collegamenti di spostamento, che è indipendente dalle dimensioni o dalla topologia della scheda.

— ddyer
fonte