4

I've read many Q/As about how to solve a maze and I'm familiar with using recursion in programming. My case is slightly different:

I'm trying to develop a machine (in Java) to solve a 2D arena with one entry point, which could be anywhere in the map, not just in the edge. The goal is not to find a way out (there is no such. The entry point is the exit). The mission is to walk all places and looking for collectibles, avoiding obstacles.

Imagine it's a digger in a mine. It's dark, you can see 2,3,4 tiles around and what you can see on this range is only collectibles, because they sort of flicker. Neither obstacles, nor edges of the map can be "seen" until digger tries them and fails to move. That means we don't know the full size and shape of the map. Sometimes it's a series of long thin tunnels, sometimes it's a set of large rooms (30x100 blocks), or a combinations of both.

I've tried a simple maze solving solution with recursion in a room-like map with half empty room (no obstacles and no collectibles). Starting from this part of room makes digger to go dozens of times in these empty blocks back and forth, until it finally plays out all possible ways and finally reach the other end of the room.

Obviously I need a different approach for such maps, while this simple maze solver is great (well, almost) for walking long tunnels.

For those of you who've reached this far, here is a list of additional conditions and characteristics:

  1. While most of collectibles when 'digged' they disappear and make way, some convert to obstacle and cannot be passed.
  2. There are gates around the map leading to another map. Imagine it as an elevator and floors.
  3. There are levers, that open doors, keys being collected, stones being moved to open a way or be placed in certain places to unlock areas, etc.

Well, pretty awesome case and, of course, my digger is going to do just simple jobs (1. and 2. are easily codeable, while 3. is for Isaac Asimov)

So, in case it's not clear what exactly I'm asking, here it is:

How to improve my algorithm to not go so many times in an area, where it's already clear and be 'smarter' in looking for collectibles, no matter the type of the map?

Jeff Horowitz
  • 41
  • 4
  • 2
    How about a breadth first search, keeping track of every tile that was already visited so it's not visited again? – Bart van Nierop Jan 04 '16 at 14:59
  • Yep. I'm considering it and see what am I missing in my implementation. – Jeff Horowitz Jan 04 '16 at 15:18
  • Sounds like a graph problem, use a graph library (I'd say boost::graph, but you're using Java...) – kebs Jan 04 '16 at 15:19
  • Still doing my research and found another approach behind the name "backjumping". – Jeff Horowitz Jan 04 '16 at 15:20
  • 1
    I would add to my initial comment that, to get back to your starting point, you should probably do another search from scratch. After all, the path you took to get to some tile, while collecting everything, is likely much longer than the shortest path back from that tile. You should of course keep information about which tiles are impassible. – Bart van Nierop Jan 04 '16 at 15:22
  • I passed quickly BFS and that's my mistake. Indeed BFS is way better than what I've implemented, which perhaps is some kind of **Depth-first search**. Perhaps a hybrid of BFS + backjumping and if I know it's a tunnel-more-like map, then DFS + backjumping. – Jeff Horowitz Jan 04 '16 at 15:44

1 Answers1

1

All graph search algorithms that I'm aware of assume the graph is known from the start. If you want to try to use something resembling a graph search you will need to make some kind of probablistic model for the environment (outside of sensor range) then do a monte-carlo simulation:

loop N times and:

  • randomize an instance of the unknown parts of the environment according to the model, given the information you already have.
  • solve the search problem with the usual algorithms on the "guessed" environment
  • add a vote towards the first movement the "optimal path" would take

The movement direction with most votes wins.

you'll have to tune N and the way you model the environment for this approach to be of any use. In any case, this is a really difficult problem. And even this technique doesn't consider the potential information gain from each of its choices (looking ahead deeply with this kind of computation as state evaluation is just prohibitively expensive)

yonil
  • 564
  • 3
  • 12
  • 1
    Thanks, @yonil! Making my machine capable of learning is great. As a start I would go for something simplistic like choosing between set of solvers or/and giving a preference to a direction of "digging" - a simple version of your _vote system_. With your's and @Bart's guidelines I'm going to be busy next days. Thanks again! – Jeff Horowitz Jan 04 '16 at 16:19