¿Es mejor codificar datos o encontrar un algoritmo?

8

He estado trabajando en un juego de mesa que tiene una cuadrícula hexadecimal como esta placa:

Dado que el tablero nunca cambiará y los espacios en el tablero siempre estarán vinculados a los mismos espacios a su alrededor, ¿debería codificar cada espacio con los valores que necesito? ¿O debería usar varios algoritmos para calcular enlaces y recorridos?

Para ser más específico, mi juego de mesa es un juego de 4 jugadores en el que cada jugador tiene una cuadrícula hexagonal de 5x5x5x5x5x5 (de nuevo, la imagen de arriba). El objetivo es llegar desde la parte inferior de la cuadrícula a la parte superior, con varios obstáculos en el camino, y que cada jugador pueda atacarse desde el borde de su cuadrícula a otros jugadores en función de un multiplicador de rango.

Dado que la cuadrícula de los jugadores nunca cambiará y la distancia de cualquier espacio arbitrario desde el borde de la cuadrícula siempre será la misma, ¿debería simplemente codificar este número en cada uno de los espacios, o aún debería usar un algoritmo de búsqueda de amplitud primero cuando los jugadores están atacando?

La única desventaja que puedo pensar para codificar todo es que voy a codificar 9+ 2 (5 + 6 + 7 + 8) = 61 celdas individuales. ¿Hay algo más que me falta que debería considerar usar algoritmos más complejos?

algorithm procedural-generation hexagonal-grid

— OghmaOsiris
fuente

Puedo decirte que el área para un ataque de radio es 1 más la suma de los términos de la secuencia dada por f (n) = 6 (n-1) de n = 1 a n = x donde x es el número de filas. EG 3 filas (radio de 10 pies) = 1 + 6 + 12 = 19

— eazimmerman

Aquí hay un seudocódigo de lo que describí

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

— eazimmerman

¿No parece muy difícil? Desde {X,Y}, obviamente, puede ir hacia {X-1, Y}y {X+1, Y}en la misma fila. En las filas de abajo y arriba puedes ir a {X, Y-1}y {X, Y+1}. Finalmente, dependiendo de la uniformidad de Y, puede ir {X-1, Y-1}y / {X-1, Y+1}o {X + 1, Y-1} `y{X+1, Y+1}

— MSalters

12

Supongo que tomaré el contrapunto aquí y argumentaré en contra del uso de valores estáticos. En este caso, todas las regiones hexadecimales de las que habla son (a) fáciles de calcular: no necesita usar BFS ni nada tan complicado; deberías poder iterar sobre todos los hexágonos en cualquiera de ellos con bucles directos doblemente anidados; y (b) no es algo que necesitará calcular 'sobre la marcha' con mucha frecuencia. En el peor, sólo tendrá que calcular una vez por turno, y si varios sistemas no quieren que las células afectadas por un efecto entonces se puede almacenar en caché fácilmente los valores fuera en una matriz 'reachableCells' o algo similar; independientemente, el cálculo es tan fácil que debería ser efectivamente gratuito en términos de costos por cuadro.

Entonces, ¿qué obtienes por eso? Flexibilidad. Es fácil decir en este momento que estos valores nunca cambiarán, pero los juegos tienen la habilidad de sorprenderte; incluso si es más probable que estas regiones no cambien, esencialmente no renuncias a nada al desarrollar esa flexibilidad, y hay una buena posibilidad de que en el futuro te lo agradezcas en el futuro. Además, incluso si esas son las regiones finales que usa, los bucles bien escritos para iterar sobre las regiones serán sustancialmente más fáciles de entender y depurar que cualquier tipo de matriz de mosaicos fijos. Simplemente no veo ninguna ganancia significativa por usar datos codificados en comparación con los beneficios de ir hacia otro lado.

— Steven Stadnicki
fuente

11

Si los valores nunca cambian, también pueden ser estáticos. ¿Por qué perder el tiempo de CPU recalculando algo que será igual que la última vez?

Sin embargo, no necesariamente tienen que estar 'codificados':

Puede poner los valores en un archivo de datos y cargarlos al principio.
Puede realizar la búsqueda durante la reproducción y almacenar en caché los valores una vez que los encuentre.

La primera forma tiene sentido si cree que podría cambiar la forma o el tamaño del mapa en el futuro. La segunda forma tiene sentido si calcular los valores estáticos es un poco complicado.

No tengo idea de cómo se ve un mapa hexadecimal de seis dimensiones, o por qué hay 9 + 2 (5 + 6 + 7 + 8) celdas involucradas, pero el mejor resultado para su situación, y de hecho la mayoría de las situaciones en la programación del juego, es codificar en lo que sea que le dé el resultado correcto más rápidamente. Puede generalizarlo a un algoritmo más adelante si es necesario. "Código para hoy", como dicen algunos.

— Kylotan
fuente

Todo esto. Primero haz que funcione, luego apacigua al ego;)

— Mike Cluck

2

Solo para aclarar su confusión, creo que el OP cuando se refiere a una cuadrícula hexagonal de 5x5x5x5x5x5 no se refería a 6 dimensiones físicas (o virtuales), sino a un hexágono de hexágonos, donde cada lado del hexágono contiene 5 hexágonos más pequeños a lo largo de su longitud, similar a esto (ignore los puntos negros). En ese caso, el tablero contendría 9 + 2 (5 + 6 + 7 + 8) celdas.

Sí, lo vi en el diagrama publicado en una edición.

— Kylotan

0

P: ¿es este el único juego hexadecimal que escribirás? ¿No?

R: Entonces, obviamente, debes tratar de ser flexible siempre que no te cueste mucho esfuerzo adicional. Independientemente de cómo defina el tablero, represéntelo en tiempo de ejecución con enlaces explícitos. Es muy conveniente codificar el movimiento y la lógica de relación en términos de enlaces cruzados, que es independiente del tamaño o la topología de la placa.

— ddyer
fuente