Dois-je partager la même structure de tuiles pour l'affichage et la recherche de chemin?

Je sais comment afficher une carte 2D avec des tuiles.

Je sais comment créer un algorithme de recherche de chemin en utilisant A *.

Ces deux choses exigent une structure ou une classe. Ma question est: utilisez-vous la même structure pour l'affichage et le calcul de chemin? Structure de noeud pour la recherche de chemin pour ajouter des données: position x, position y, F, G, H plus le noeud parent. La structure des tuiles pour l'affichage peut être optimisée pour presque une seule information: la valeur de la tuile.

Utilisez-vous une grande classe pour vos tuiles, qui gère à la fois l'affichage et le cheminement, ou utilisez-vous une méthode différente? Merci pour tes conseils !

Ma question est: utilisez-vous la même structure pour l'affichage et le calcul de chemin?

Non, non. Vous pouvez obtenir une optimisation du calcul de votre A * directement sur la carte de tuiles, mais vous ne pouvez pas facilement utiliser votre algorithme A * pour des choses qui ne sont pas directement mappées aux tuiles. En outre, cela signifie que vous ne pouvez pas exécuter l'algorithme A * simultanément dans plusieurs threads car ils finissent par partager les données de la carte. Enfin, certaines méthodes de déplacement ne permettent pas l'optimisation tile = node; un véhicule qui a besoin d'espace pour faire demi-tour pourrait potentiellement arriver à la même tuile de différentes directions et avoir des options différentes dans chaque cas - ils ne peuvent pas être fusionnés en un seul score.

Je suggère donc de garder les données séparées.

Du point de vue du développement logiciel, il est toujours bon de séparer les différentes choses .

Pour une solution rapide et sale, assemblez tout et commencez à travailler sur les spécificités du jeu.

Pour une solution extensible, gardez les choses à part: vous ne voulez pas changer les classes de tuiles parce que votre algorithme de recherche de chemin a été changé! Conservez deux structures: une représentant les tuiles de jeu visibles et l'autre représentant la structure d'orientation. Idéalement, un algorithme de recherche de chemin est maintenu à un niveau bas, donc peut-être qu'un tableau de points x, y en entrée dans l'algorithme est une meilleure idée que de lui fournir vos classes de tuiles. L'algorithme lui-même peut configurer des tableaux pour les valeurs F, G, H.

Je pense que dans ce cas (et je suppose que vous vous efforcez d'être un bon programmeur), vous devriez opter pour la solution extensible, car cela ne vous demandera pas beaucoup d'efforts supplémentaires mais cela gardera votre code plus propre et vous gagnerez de bonnes pratiques expérience.

J'étais en train de construire un jeu basé sur des tuiles sur l'Amiga 500 avec des tuiles 512x512 mais le joueur ne pouvait déplacer que 8 tuiles, j'ai donc généré une carte murale "pr" 9x9 ". soldat. Si j'avais fait cela avec la carte d'origine, j'aurais d'abord dû "l'effacer" après chaque calcul + la quantité de mémoire nécessaire pour avoir les deux données de tuile + les données de cheminement feraient que 512x512 devienne un porc de mémoire beaucoup plus mendiant.

Alors non, gardez les choses aussi petites que possible et séparées pour pouvoir les modifier pr. objet / classe si nécessaire. Une autre chose à penser pourrait également être que certains de vos objets en mouvement POURRAIENT se déplacer différemment sur certaines parties de la carte. Par exemple. lent dans le sable, peut / ne peut pas nager, peut ouvrir des portes, etc.