J'ai travaillé sur un jeu de société qui a une grille hexadécimale comme cette carte:
Étant donné que le tableau ne changera jamais et que les espaces sur le tableau seront toujours liés aux mêmes autres espaces autour de lui, devrais-je simplement coder en dur chaque espace avec les valeurs dont j'ai besoin? Ou dois-je utiliser différents algorithmes pour calculer les liens et les traversées?
Pour être plus précis, mon jeu de société est un jeu à 4 joueurs où chaque joueur a une grille hexagonale de 5x5x5x5x5x5 (encore une fois, l'image ci-dessus). Le but est d'aller du bas de la grille vers le haut, avec divers obstacles sur le chemin, et chaque joueur pouvant s'attaquer depuis le bord de sa grille sur d'autres joueurs sur la base d'un multiplicateur de portée.
Étant donné que la grille des joueurs ne changera jamais et que la distance de tout espace arbitraire du bord de la grille sera toujours la même, devrais-je simplement coder en dur ce nombre dans chacun des espaces, ou devrais-je toujours utiliser un premier algorithme de recherche étendu lorsque les joueurs attaquent?
Le seul inconvénient auquel je peux penser pour tout coder en dur est que je vais coder 9+ 2 (5 + 6 + 7 + 8) = 61 cellules individuelles. Y a-t-il autre chose qui me manque que je devrais envisager d'utiliser des algorithmes plus complexes?
la source
int numberOfHexagonsInArea(int rows) { int area = 1; while(rows>0) { area += (rows-1)*6; rows--; } return area; }{X,Y}vous pouvez évidemment aller vers{X-1, Y}et{X+1, Y}sur la même ligne. Sur les lignes ci-dessous et au-dessus, vous pouvez aller à{X, Y-1}et{X, Y+1}. Enfin, en fonction de l'uniformité deY, vous pouvez aller à{X-1, Y-1}et{X-1, Y+1}ou {X + 1, Y-1} `et{X+1, Y+1}Réponses:
Je suppose que je vais prendre le contrepoint ici et plaider contre l'utilisation de valeurs statiques. Dans ce cas, toutes les régions hexadécimales dont vous parlez sont (a) faciles à calculer - vous n'avez pas besoin d'utiliser BFS ou quelque chose d'aussi compliqué; vous devriez pouvoir parcourir tous les hexagones de chacun d'eux avec des boucles doublement imbriquées simples; et (b) pas quelque chose dont vous aurez besoin pour calculer «à la volée» très souvent. Au pire , vous ne devriez avoir besoin de les calculer une fois par tour, et si plusieurs systèmes ne veulent que les cellules touchées par un effet alors vous pouvez facilement mettre en cache les valeurs hors dans un tableau « reachableCells » ou quelque chose de semblable; Quoi qu'il en soit, le calcul est si facile qu'il devrait être effectivement gratuit en termes de coûts par image.
Alors qu'obtenez-vous pour cela? Souplesse. Il est facile de dire en ce moment que ces valeurs ne changeront jamais, mais les jeux ont le don de vous surprendre; même s'il est plus probable qu'improbable que ces régions ne changeront pas , vous n'abandonnez pratiquement rien en renforçant cette flexibilité, et il y a de fortes chances pour que l'avenir vous en remercie. De plus, même si ce sont les régions finales que vous utilisez, des boucles bien écrites pour itérer sur les régions seront beaucoup plus faciles à comprendre et à déboguer que n'importe quel type de tableau à tuiles fixes. Je ne vois vraiment aucun avantage significatif à utiliser des données codées en dur par rapport aux avantages d'aller dans l'autre sens.
la source
Si les valeurs ne changent jamais, elles peuvent aussi bien être statiques. Pourquoi perdre du temps CPU à recalculer quelque chose qui sera le même que la dernière fois?
Cependant, ils n'ont pas nécessairement besoin d'être «codés en dur»:
La première manière est logique si vous pensez que vous pourriez changer la forme ou la taille de la carte à l'avenir. La deuxième façon est logique si le calcul des valeurs statiques est un peu délicat.
Je n'ai aucune idée à quoi ressemble une carte hexadécimale à six dimensions, ni pourquoi il y a 9 + 2 (5 + 6 + 7 + 8) cellules impliquées, mais le meilleur résultat pour votre situation - et en fait la plupart des situations dans la programmation de jeux - est pour coder tout ce qui vous permet d'obtenir le résultat correct plus rapidement. Vous pouvez le généraliser à un algorithme plus tard si vous en avez besoin. "Code pour aujourd'hui", comme disent certains.
la source
Q: est-ce le seul jeu hexagonal que vous aurez jamais écrit? Non?
R: Alors, évidemment, vous devriez essayer d'être flexible partout où cela ne vous coûte pas beaucoup d'efforts supplémentaires. Quelle que soit la façon dont vous définissez la carte, représentez-la lors de l'exécution avec des liens explicites. Il est très pratique de coder la logique de mouvement et de relation en termes de liens traversants, qui est indépendante de la taille ou de la topologie de la carte.
la source