Est-il préférable de coder en dur les données ou de trouver un algorithme?


8

J'ai travaillé sur un jeu de société qui a une grille hexadécimale comme cette carte:

entrez la description de l'image ici

É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?


Je peux vous dire que la zone pour une attaque de rayon est 1 plus la somme des termes de la séquence donnée par f (n) = 6 (n-1) de n = 1 à n = x où x est le nombre de lignes. EG 3 rangées (rayon de 10 pieds) = 1 + 6 + 12 = 19
eazimmerman

Voici le pseudocode de ce que j'ai décrit int numberOfHexagonsInArea(int rows) { int area = 1; while(rows>0) { area += (rows-1)*6; rows--; } return area; }
eazimmerman

Cela ne semble pas très difficile? De {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é de Y, vous pouvez aller à {X-1, Y-1}et {X-1, Y+1}ou {X + 1, Y-1} `et{X+1, Y+1}
MSalters

Réponses:


12

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.


11

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»:

  • Vous pouvez placer les valeurs dans un fichier de données et les charger au début.
  • Vous pouvez effectuer la recherche pendant la lecture et mettre en cache les valeurs une fois que vous les avez trouvées.

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.


Tout ça. Faites d'abord fonctionner puis apaisez l'ego;)
Mike Cluck

2
Juste pour clarifier votre confusion, je pense que l'OP en se référant à une grille hexagonale 5x5x5x5x5x5 ne faisait pas référence à 6 dimensions physiques (ou virtuelles), mais plutôt à un hexagone d'hexagones, où chaque côté de l'hexagone contient 5 hexagones plus petits sur sa longueur, similaire à cela (ignorer les points noirs). Dans ce cas, la carte contiendrait 9 + 2 (5 + 6 + 7 + 8) cellules.

Oui, je l'ai vu sur le diagramme publié dans un montage.
Kylotan

0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.