5

A have a maze and character that's controlled by the player and a drone who has to find him (by itself). Does anyone know an (efficient) AI algorithm for doing something like this? P.S. I know there are several path finding algorithms(e.g. A*), but as far as I know these only work for finding the path between two nodes that "don't move" (this would work if my character was standing still, but that's obviously not the case).

conectionist
  • 2,694
  • 6
  • 28
  • 50
  • Does the drone know the maze layout or does it have to discover it as it goes? Also, does it know where the player is within the maze as it moves? – cdeszaq Jan 19 '12 at 15:38
  • A* also requires that you know beforehand the locations of the start and end points. Does the drone know where the player is and just has to reach it? Our does the drone also need to locate the player? – Jack Edmonds Jan 19 '12 at 15:41
  • @cdeszaq Yes, it knows the layout of the maze (although I wouldn't mind an algorithm the assumes it doesn't know it) and yes, it does know where the player is within the maze. – conectionist Jan 19 '12 at 15:41
  • @JackEdmonds Yes, it just has to reach him. But take into account the fact that the player is constantly moving. – conectionist Jan 19 '12 at 15:43
  • If the maze is not too big you could use Floyd-Warshall to get all shortest paths. Then you can lookup the shortest path for all possible player <-> drone positions. If your maze is too big try to search the shortest paths between road junctions. Then you can lookup the shortest path for all possible player(next junction) <-> drone(next junction) positions. – Zeta Jan 19 '12 at 16:30
  • @Zeta Its dimensions differ from run to run. But Floyd-Warshall isn't such a bad idea. – conectionist Jan 20 '12 at 18:53

1 Answers1

1

If the "start point" is where the drone is, and the "end point" is to run into the player, about the best you can do using just a "standard" algorithm is to use A* periodically and from that determine where the drone needs to move.

As you get closer to the player, you will be calculating faster and faster since the search space is, in theory, smaller.

Using this, it would be possible for the player to find a set of positions that, when moving between them causes the drone to get "stuck" just moving back and forth, but those sorts of optimizations are situation-specific and a general algorithm won't include them.

Essentially, you do have a fixed search space each "frame", but you just have to run it each frame to decide what to do.

There are likely tweaks to A* that cover minor perturbations between runs, but I don't know any off the top of my head.

cdeszaq
  • 30,869
  • 25
  • 117
  • 173
  • This was actually the first thing I though of. One of the problems with this solution is that calculating the path might take the drone a lot of time and then its motion might look something like this: move a bit, then halt and calculate, then move again, then calculate again etc. I would like it to move constantly (kind of like the way the ghosts move in pacman). – conectionist Jan 19 '12 at 15:54
  • 2
    I agree, A* is likely your best bet. You'll want the ability to stop A* in the middle of a calculation when the human has moved. You'll also need to update the start and end goals every time the human or drone have moved. I guess you could also use something like Johnson's algoritm to find all shortest paths between all possible position's and then use it as a lookup table. That should work if the maze is not dynamic. http://en.wikipedia.org/wiki/Johnson%27s_algorithm – Justin Jan 19 '12 at 16:00
  • @Justin - I like the idea of the lookup..._Much_ faster than continuously doing A*. You could use the same memoized idea _with_ A* and cache the results. Then you would slowly build the lookup table based on where the player and drone are and have been, ignoring the "un-visited" parts of the maze until they are needed. – cdeszaq Jan 19 '12 at 16:03
  • @Justin Indeed, this solution sound better. I think I'll try this if I don't find something better. – conectionist Jan 19 '12 at 21:36
  • 1
    The more I think about it. You are better off from a efficiency standpoint just to use plain old Dijkstra's algorithm from every vertex at initialization and use that as your look-up table. Like Johnson's algorithm, without the initial Bellman-Ford step since you cannot have negative weights in your graph. Essentially, all your weights should be 1. – Justin Jan 20 '12 at 01:00