Eu tenho trabalhado em um jogo de tabuleiro que possui uma grade hexadecimal como esta:
Como o quadro nunca mudará e os espaços no quadro sempre serão vinculados aos mesmos outros espaços ao seu redor, devo apenas codificar cada espaço com os valores de que preciso? Ou devo usar vários algoritmos para calcular links e percursos?
Para ser mais específico, meu jogo de tabuleiro é um jogo de 4 jogadores em que cada jogador tem uma grade hexagonal de 5x5x5x5x5x5 (novamente, a imagem acima). O objetivo é ir do fundo da grade para o topo, com vários obstáculos no caminho, e cada jogador sendo capaz de atacar um ao outro da borda do seu grid a outros jogadores com base em um multiplicador de alcance.
Como a grade de jogadores nunca muda e a distância de qualquer espaço arbitrário a partir da borda da grade sempre será a mesma, devo apenas codificar esse número em cada um dos espaços ou ainda usar um algoritmo de primeira pesquisa quando jogadores estão atacando?
O único truque em que posso pensar para codificar tudo é que vou codificar 9 + 2 (5 + 6 + 7 + 8) = 61 células individuais. Falta alguma coisa que eu deva considerar o uso de algoritmos mais complexos?
fonte
int numberOfHexagonsInArea(int rows) { int area = 1; while(rows>0) { area += (rows-1)*6; rows--; } return area; }{X,Y}que você pode, obviamente, ir para{X-1, Y}e{X+1, Y}na mesma linha. Nas linhas abaixo e acima, você pode ir para{X, Y-1}e{X, Y+1}. Finalmente, dependendo da uniformidade deY, você pode ir para{X-1, Y-1}e{X-1, Y+1}ou (X + 1, Y-1} `e{X+1, Y+1}Respostas:
Acho que vou pegar o contraponto aqui e argumentar contra o uso de valores estáticos. Nesse caso, todas as regiões hexadecimais das quais você está falando são (a) fáceis de calcular - você não precisa usar BFS ou algo tão complicado; você deve conseguir iterar todos os hexágonos em qualquer um deles com loops duplamente aninhados diretos; e (b) não é algo que você precisará calcular on-the-fly com muita frequência. Na pior das hipóteses você só deve calcular-los uma vez por turno, e se múltiplos sistemas não quer as células tocados por um efeito então você pode facilmente armazenar em cache os valores de folga em uma matriz 'reachableCells' ou algo semelhante; independentemente, o cálculo é tão fácil que deve ser efetivamente gratuito em termos de custos por quadro.
Então, o que você ganha por isso? Flexibilidade. É fácil dizer agora que esses valores nunca mudarão, mas os jogos têm um talento especial para surpreender você; mesmo que seja mais provável que essas regiões não mudem, você não abre mão de nada construindo essa flexibilidade e há uma boa chance de futuro - você agradecerá no futuro. Além do mais, mesmo que essas sejam as regiões finais que você usa, loops bem escritos para iterar sobre as regiões serão substancialmente mais fáceis de entender e depurar do que qualquer tipo de matriz de blocos fixos. Eu realmente não vejo nenhum ganho significativo ao usar dados codificados em comparação com os benefícios de seguir para o outro lado.
fonte
Se os valores nunca mudarem, eles também podem ser estáticos. Por que perder tempo na CPU recalculando algo que será o mesmo da última vez?
No entanto, eles não precisam necessariamente ser 'codificados':
A primeira maneira faz sentido se você acha que poderá alterar a forma ou o tamanho do mapa no futuro. A segunda maneira faz sentido se calcular os valores estáticos for um pouco complicado.
Não tenho ideia de como é um mapa hexadecimal em seis dimensões ou por que há 9 + 2 (5 + 6 + 7 + 8) células envolvidas, mas o melhor resultado para sua situação - e de fato a maioria das situações na programação de jogos - é para codificar o que você obtiver o resultado correto mais rapidamente. Você pode generalizá-lo posteriormente para um algoritmo, se necessário. "Código para hoje", como alguns dizem.
fonte
P: este é o único jogo hexadecimal que você já escreveu? Não?
R: Então, obviamente, você deve tentar ser flexível sempre que isso não lhe custa muito esforço extra. Independentemente de como você define o quadro, represente-o em tempo de execução com links explícitos. É muito conveniente codificar a lógica de movimento e relacionamento em termos de atravessar links, independente do tamanho ou da topologia do quadro.
fonte