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?
fuente
int numberOfHexagonsInArea(int rows) { int area = 1; while(rows>0) { area += (rows-1)*6; rows--; } return area; }{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 deY, puede ir{X-1, Y-1}y /{X-1, Y+1}o {X + 1, Y-1} `y{X+1, Y+1}Respuestas:
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.
fuente
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':
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.
fuente
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.
fuente