Comment trouver un obstacle?

10

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

zzandy
la source
Je pense que vous devriez clarifier votre cas d'utilisation, car cela affecterait l'approche adoptée pour résoudre ce problème. Par exemple, si le cas d'utilisation est de calculer les chemins pour les ennemis, vous devriez probablement d'abord voir si l'objectif peut être atteint actuellement, sinon les ennemis obtiennent le râteau (c'est-à-dire que le râteau EST le but), puis trouver le premier objectif à nouveau.
jhocking

Réponses:

6

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.
zzandy
la source
1
+1 J'ai fait quelque chose de similaire avec mon jeu, et j'ai écrit un petit article à ce sujet sous Unit Tasks and pathfinding .
MichaelHouse
@ byte66 ne gère pas les cas spéciaux quand il y a un chemin sans utiliser le râteau mais, en utilisant le râteau, le chemin est plus court
Ali1S232
@Gajet, vous avez raison. Devinez aura besoin d'une approche différente pour cela.
zzandy
1
Il s'agit simplement d'ajouter des coûts supplémentaires. Lorsque vous rencontrez de l'eau, ajoutez le coût d'obtention de l'élément de marche sur l'eau au chemin. A * sautera la marche sur l'eau jusqu'à ce qu'il devienne le chemin le moins cher.
MichaelHouse
3

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

Ali1S232
la source
+1 Faites de votre râteau un lien à sens unique avec l'eau, avec des liens à sens unique eau-sol.
Laurent Couvidou
Je ne comprends pas bien comment lier la recherche géométrique et la recherche d'entités. Comment aller de no path from @ to $à goto rake, bring it to water, place it, goto $.
zzandy
@zzandy lors de la recherche de chemin, pour chaque tuile, vous allez aux tuiles les plus proches si possible. il vous suffit d'ajouter une condition selon laquelle si le nœud actuel est un râteau, vous pouvez directement ajouter un nœud de l'autre côté de la rivière pour ouvrir la liste.
Ali1S232
Mais que faire si vous pouvez transporter l'appareil? Je pensais que
c'était
Oui, je veux dire que l'appareil peut (et doit) être utilisé. @kaoD, votre réponse n'inclut pas l'étape lorsqu'un agent a l'idée qu'il a besoin du râteau.
zzandy
2

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.

Joar Jakobsson
la source
J'ai traité le râteau plus comme des "bottes de marche sur l'eau" dans mon exemple, ce qui signifie un objet qui, si vous l'avez, vous permet de voyager sur des tuiles d'eau. Si le râteau doit être réellement "construit" comme un morceau de terrain, et couvre une quantité limitée de tuiles qui pourraient ou pourraient ne pas suffire pour traverser l'eau, le problème est plus difficile. Ma solution permet cependant d'utiliser des éléments à usage unique, si vous effectuez un mouvement dans z = 1, redescendez automatiquement à z = 0.
Joar Jakobsson