Comment trouver un obstacle?

Comment représenter au mieux la situation suivante - l'agent ( @) doit atteindre l'objectif ( $). Le chemin est bloqué par un fossé ( ~~~). Un râteau (ou un autre appareil, comme des bottes de marche) est disponible qui permettra de franchir l'obstacle.

.....~~~...   . ground
...=.~~~...   = rake
.....~~~.$.   ~ water
.@...~~~...   @ agent
.....~~~...   $ goal

Comment trouver correctement le chemin de à @à $condition qu'il n'y ait pas de chemin immédiatement disponible? Mon parcours devrait-il avoir non seulement un coût mais aussi des prérequis?

UPD : Le problème est que l'objectif n'est pas accessible et le râteau n'est qu'un des nombreux objets possibles sur la carte. La question est alors "comment faire comprendre à l'agent qu'il a besoin du râteau?"

Je pense à une pile d'objectifs, le pathfinding devra être annoté :

• Commencez avec un objectif get $
• Essayez de trouver le chemin vers $- le chemin existe avec la capacité de marche sur l'eau requise.
• Poussez l'objectif get waterwalking.
• La pile de buts est maintenant get waterwalking, get $
• D'une manière ou d'une autre, trouver que le râteau donne la marche à l'eau, renommons-le en bateau.
• Chemin vers le râteau. Objectif supérieur atteint, sortez-le de la pile, l'objectif est get $.
• Chemin vers $- nous avons maintenant des capacités et pouvons atteindre l'objectif.

La recherche de chemin entier n'est qu'une recherche du chemin le plus court sur un graphique. pour résoudre votre problème, le seul changement que vous devez appliquer est d'ajouter des bords supplémentaires (représentant le chemin que le bateau peut prendre) et de faire un algorithme de recherche de chemin simple. peu importe que vous utilisiez BFS, Dijkstra ou A *, implémentez simplement un algorithme de recherche de chemin normal avec quelques bords supplémentaires. pour plus d'informations sur la recherche de chemin dans une page wiki de vérification de graphique

Je ferais cela avec une sorte de solution d'arbre de comportement - vous chemin vers le but, et prenez note de tous les obstacles qui bloquaient votre A *. Si vous échouez, vous vérifiez s'il existe des objets qui peuvent aider à surmonter ces obstacles, dans ce cas, le chemin vers cet objet. Répéter. Cela signifie que l'agent doit essayer d'atteindre le but et échouer avant d'avoir l'idée d'utiliser des outils, ce qui peut prendre du temps, surtout s'il y a un monde énorme de tuiles qui doivent toutes être vérifiées. Cela pourrait ne pas sembler trop déplacé que l'agent prenne un certain temps pour réfléchir à la façon de résoudre le problème.

Je peux cependant imaginer une vraie solution hardcore. Ajoutez une autre dimension à votre grille de recherche de chemin. Donc, dans le cas d'une carte 2D, vous faites la grille de repérage 3D. Dans cet exemple simple, cette nouvelle dimension n'aurait qu'une profondeur de deux, mais dans un vrai jeu, elle deviendrait grande rapidement.

À z = 0, vous cartographiez le terrain dans des circonstances normales, ce qui signifie que les tuiles d'eau sont considérées comme infranchissables.

À z = 1, vous cartographiez le terrain tel qu'il est tout en ayant le râteau, ce qui signifie que les carreaux d'eau sont considérés comme accessibles à pied (mais si vous avez par exemple des carreaux de mur, ceux-ci peuvent rester solides).

La recherche de chemin est un A * ordinaire dans les dimensions x et y, ce qui signifie que chaque cellule de la grille est considérée comme ayant accès à ses voisins. Dans la dimension z cependant, le A * n'est PAS autorisé à se propager.

Sauf où est le râteau. L'objet râteau agit comme une ouverture entre z = 0 et z = 1 dans la grille de recherche de chemin.

Cela signifie que le A * se remplira vers l'extérieur en z = 0, frappera l'eau et manquera d'options - puis il se propagera à z = 1 à travers la tuile de râteau, et à z = 1 (où l'eau est accessible à pied) trouver son chemin vers le but. L'effet est que le PNJ sans hésitation se déplace vers le râteau, puis se déplace le plus court chemin vers le but.