在我的寻路区域周围设置边界是否可以接受？答案

【问题标题】：Would it be acceptable to place bounds around my pathfinding area?在我的寻路区域周围设置边界是否可以接受？
【发布时间】：2010-12-29 08:12:26
【问题描述】：

我目前正在使用 A* 寻路算法来计算无限网格上的路径（使用 Gridworld 中的 UnboundedGrid，AP CS 案例研究，如果对任何人有帮助的话）。一切都很好，除了因为末端节点完全被墙包围而没有有效路径的情况。正如预期的那样，算法继续无限搜索，永远找不到结束节点。

一个可能的解决方案是在整个寻路区域周围放置不可见的（如用户看不到但算法看到的）墙，确保起始节点、结束节点和所有墙节点在这些墙内，有 2-3 个空间填充左右。比如：

_________________________________
|                               |
|              S  |             |
|            _____|   _____     |
|                     | E |     |
|                     |___|     |
|_______________________________|

...想法是最终所有节点都将添加到封闭列表中，开放列表将变为空，此时我将知道不存在有效路径。

这似乎是解决问题的合理方法吗？有什么方法可能会出错吗？我知道另一种解决方案是同时从末端向后寻路，但这似乎可能很昂贵，特别是在末端节点没有那么紧密封闭的情况下。

【问题讨论】：

这是一个主观回答的问题。这样做是否正确？在某些情况下是这样，但在某些情况下不是。取决于项目的限制。一定要找路吗？如果是这样，您是否遇到上述情况，您是否应该通过说没有路径来解决它们？如果是，那么您需要某种限制。如果没有，那么，你不会:)。
用户可以随意安排环境，所以是的，我必须能够处理不良路径。双方同时进行的寻路似乎/我一直相信这可能是最好的方法，尽管我可能需要稍微重构我的代码才能让它工作。哦，好吧：D

标签： java algorithm path-finding a-star gridworld

【解决方案1】：

你不知道结束节点到底在哪里吗？如果这样做，请在执行算法之前检查它是否被包围。

【讨论】：

问题是它可能不会立即被包围。它可能有 10、20、50 个节点，形状各异。
@Lewis 在这种情况下，从开始和结束都做一个 A*，当你有一个会面点或队列为空时停止（在这种情况下，其中一个是附上。）请注意，如果您按照您的建议进行操作，您所在区域外部可能存在有效路径，因此您可能会错过有效路径
是的，你当然是对的，现在再次查看该方法，它看起来可能比我在问题中提出的更有效。但是，只是为了好玩，用矩形墙包围的方法真的有效吗？
@Lewis 如果你有足够大的围墙（至少在 IMO），它会在 99% 的情况下工作
听起来不错。那我会用你的方法，因为它是更好的方法。谢谢！

【解决方案2】：

另请参阅我对您的问题的评论。打字后，我想出了一个不错的解决方案。这适用于您不知道您的终端节点并且无法对您的终端节点的位置做任何事情的情况，如上所述。

你也可以这样说：“我在我的领域发现了一个封闭的盒子，并且在 x 时间之后没有路径，所以我可以说 y%没有路径，并更新 y% 以随着时间的推移而增加，但永远不会达到 100%。

可能是一个很好的解决方案，它位于搜索区域的边界并且什么都不做。

【讨论】：

这是一个很好的解决方案，特别是如果我希望用户能够在算法运行时看到统计信息。 A* 确实需要知道结束节点（否则需要类似 Dijkstra 算法），所以幸运的是，我确实可以访问结束节点。
这是真的，我已经有一段时间没有使用 A* 了:)。

【解决方案3】：

我遇到了类似的问题，这就是我所做的：

运行算法进行 n 次迭代，从 A 开始搜索 B。
运行算法进行 n 次迭代，从 B 开始搜索 A。

如果任一运行确定其中一个或另一个位于完全隔离的区域（不再有开放节点），则搜索失败。否则搜索正常进行。

当然，这里的诀窍是为 n 提供一个好的值。我通过增加 n 进行了多次传递并缓存了结果（我的图表没有改变很多）。

【讨论】：

【解决方案4】：

您正在使用 A*，因此您应该能够使用成本对地形节点进行加权。将高得离谱的成本放在墙节点上。它必须大于任何可能路径的总成本。如果路径的最终成本大于边界成本，那么你必须通过一堵墙才能找到路径，所以它是无效的。 A* 算法围绕高成本节点进行路由，因此除非必须，否则它不会穿过墙壁。

【讨论】：