1

I'm currently using the A* pathfinding algorithm to calculate a path on an infinite grid (using an UnboundedGrid in Gridworld, the AP CS case study, if that helps anyone). Everything works wonderfully, except for cases where no valid path exists because the end node is completely surrounded by walls. As expected, the algorithm continues searching infinitely, never finding the end node.

A possible solution to this would be to place invisible (as in, the user doesn't see them but the algorithm does) walls around the entire pathfinding area, making sure the start node, end node, and all the wall nodes are within these walls, with 2-3 spaces padding or so. Something like:

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

...the idea being that eventually all the nodes will be added to the closedlist, the openlist will become empty, and at that point I'll know that no valid path exists.

Does this seem like a reasonable solution to the problem? Are there any ways in which this could potentially go wrong? I understand that another solution is to simultaneously pathfind backwards from the end, but this seems like it could be potentially expensive, particularly in cases where the end node isn't so tightly enclosed.

Adrian Monk
  • 1,061
  • 9
  • 17
Lewis
  • 1,310
  • 1
  • 15
  • 28
  • This is a question with a subjective answer. Is it correct to do so? In some cases it is, but in some it isn't. Depends on the restrictions of the project. Do you have to find a path? If so, do you get situations like above and should you be able to solve them by saying there is no path? If yes, then you need some kind of restriction. If not, well, you don't :). – bastijn Dec 29 '10 at 08:31
  • The user can arrange the environment however they like, so yeah, I do have to be able to deal with bad paths. Pathfinding from both sides simultaneously seems to/I've been convinced is probably the best way to do this, although I may have to refactor my code a bit to get it to work. Oh well :D – Lewis Dec 29 '10 at 08:40

4 Answers4

2

Don't you know exactly where is the end node? If you do, just check if it's surrounded before doing your algorithm.

Gabi Purcaru
  • 30,940
  • 9
  • 79
  • 95
  • The problem is it might not be immediately surrounded. It could be 10, 20, 50 nodes out, in all sorts of weird shapes. – Lewis Dec 29 '10 at 08:21
  • 1
    @Lewis In that case, do an A* both from the start and the end, and stop when you have a meeting point, or when a queue is empty (in that case, one of them is enclosed.) Note that if you do what you suggested, there may be a valid path _outside_ your area, so you might miss valid paths – Gabi Purcaru Dec 29 '10 at 08:24
  • Yeah, you're right of course, and looking at that method again now it looks like it'd probably be more efficient than what I proposed in the question. But, just for the fun of it, would surround-with-a-rectangular-wall method actually work? – Lewis Dec 29 '10 at 08:27
  • @Lewis it would work in something like 99% of the cases, if you have a big enough surrounding wall (at least IMO) – Gabi Purcaru Dec 29 '10 at 08:29
  • Sounds good. I'll be going with your method then, since it's the better one. Thanks! – Lewis Dec 29 '10 at 08:31
1

See also my comment on your question. After typing I came up with what might be a nice solution. This is for a case where you do not know your end node and can do nothing with your end-node's position as suggested above.

You could also something along the lines of: "I have found a closed box in my field and no path after x time so with y% propability I can say there is no path, and update the y% to increase over time, but never reaching 100%.

Might be a nice solution which is in the middle of bounding the search area and doing nothing.

bastijn
  • 5,841
  • 5
  • 27
  • 43
  • This is a good solution, particularly if I want the user to be able to see the stats as the algorithm runs. A* does require the end node to be known (otherwise something like Dijkstra's algorithm in needed), so I do have access to the end node, luckily. – Lewis Dec 29 '10 at 08:45
  • A that is true, it has been a while since I have used A* :). – bastijn Dec 29 '10 at 09:36
0

I had a similar problem and here's what I did:

  1. Run algorithm for n iterations, starting at A searching for B.
  2. Run algorithm for n iterations, starting at B searching for A.

If either run determines that one or the other is in a completely isolated area (no more open nodes), the search fails. Otherwise the search is made as normal.

The trick here is, of course, to come up with a good value for n. I did multiple passes with increasing n and cached the results (my graph didnt change alot).

Mizipzor
  • 51,151
  • 22
  • 97
  • 138
0

You're using A* so you should be able to weight the terrain nodes with a cost. Put an insanely high cost onto the wall nodes. It must be greater than the total cost of any possible path. If the end cost of the path is greater than that boundary cost, then you had to pass a wall to find a path, so it's invalid. The A* algorithm routes around high cost nodes, so it won't route through a wall unless it has to.

Tom Whittock
  • 4,081
  • 19
  • 24