Choosing direction in DFS maze generation - depth-first-search

I've recently implemented a DFS maze generation algorithm according to the standard procedure:
Fill a maze with walls
Choose a starting square
Choose a random neighbor and break the wall between that neighbor if that neighbor hasn't already been explored
Recursively generate the rest of the maze by starting at the neighbor
I've been told that I may be able to "aesthetically" improve the generated mazes by implementing a rule for choosing which neighbor to explore (north, south, east or west) that isn't just completely random, but I'm having a hard time wrapping my head around what kind of rule that would be. Are there any methods out there that involve choosing a direction non-randomly, or randomly with weights? I haven't been able to find any so far.

Yes, there are many indeed.
DFS is uninformed search, so I would recommend having a look at informed search and how they are applicable to mazes.

Related

Solving maze with "islands"

I have this layout of a maze that I am having trouble thinking of how to implement a solution for:
I know there are many resources for maze solving algorithms e.g. http://www.astrolog.org/labyrnth/algrithm.htm but I am not sure which algorithm is best suited for the given maze.
There are three areas labelled “*” which are the locations that MazeSolver needs to go to before being able to exit the maze from the entrance at the top of the map.
I would appreciate pseudo code of solving the maze islands part. I would be looking for a simple solution and optimal time is not really an issue. The thing is even though an overview of the maze is provided beforehand to the solver, it may not be completely accurate at when the maze solver actually does the maze so its a little more complicated than coding it before hand or using an algorithm that uses omniscient view of the maze and needs to "half" human/doable if you get what I mean...
While the robot/robot programmer will be supplied with a map of the mine for each rescue, the map may be out of date due to new mining or due to damage from the event.
For this application the robot is required to first of all locate all the rescue areas and determine if they are occupied. The robot will have to be totally autonomous. When these have been investigated the robot should then do a check of all the passageways for humans.
The robot should also be self-navigating. While a GPS system is a natural choice, in this case it cannot be used due to the thickness of the rock ceiling preventing any GPS signals, therefore you are also required to design a navigation system for the robot. For this end, small hardware alterations, such as additional sensors or deployable radio beacons, may be added to the robot. Please note that at least one of the shelters is located in an “Island”.
Assuming you are not looking for a shortest path to get out of the maze - just any path, create some order for your Islands: island1,island2,...,islandk.
Now, assuming you know how to solve a "regular" maze, you need to find paths from:
start->island1, island1->island2, ...., islandk->end
Some comments:
Solving "regular" maze can be done using BFS, or DFS (the later is not optimal though).
If you are looking for a more efficient solution, you can use
all-to-all shortest path rather than multiple "regular" maze solving.
If you are looking for a shortest path, this is a variation of Traveling Salesman Problem. Possible solution is discussed here.
If you want to also pass through all passages, you can do it using a DFS that continues until all nodes are discovered. Again, this won't be the shortest such path, but finding the shortest path is going to be NP-Hard.
This problem is related to the Travelling salesman problem problem, which is NP-Hard, so I wouldn't expect any quick solutions for larger number of islands.
For small number of islands, you can do this: for each 2 islands (including your starting position), compute the shortest path between them. Since you are interested in distances between relatively low fraction of vertices, I recommend using the Dijkstra's algorithm, since it is relatively easy and can be done by hand (for reasonably large graf).
Now you have the shortest distances between all points of interest and it is when you need to find the Hamiltonian optimal path between them. Fortunately, the distances satisfy a metric, so you can have 2-approximation (easy, even by hand) or even 3/2-approximation (not so easy) algorithms, but no polynomial algorithms are known.
For perfect solution with 3 islands you have to check only 6 ways how to visit them (easy), but for 6 islands you can visit them in 720 ways, and for n in n! so good luck with that.

Understanding an Inconsistent Heuristic

Say I have a grid with some squares designated as "goal" squares. I am using A* in order to navigate this grid, trying to visit every goal square at least once using non-diagonal movement. Once a goal square has been visited, it is no longer considered a goal square. Think Pac Man, moving around and trying to eat all the dots.
I am looking for a consistent heuristic to give A* to aid in navigation. I decided to try a "return the Manhattan Distance to the nearest unvisited goal" heuristic for any given location. I have been told that this is not a consistent heuristic but I do not understand why.
Moving one square towards the closest goal square has a cost of one, and the Manhattan Distance should also be reduced by one. Landing on a goal square will either increase the value of the heuristic (because it will now seek the next nearest unvisited goal) or end the search (if the goal was the last unvisited goal)
H(N) < c(N,P) + h(P) seems to always hold true. What is it that makes this algorithm inconsistent, or is my instructor mistaken?
If you are asking how to use A* to find the shortest path through all the goals, the answer is: you can't (with only one iteration). This is the Travelling Salesman Problem, an NP-Complete problem. To solve this using A*, you'd need to try every permutation of goal-orderings. Each path from a single-start to a single-goal could then be solved using A* (so you'd need to run the algorithm multiple times for each permutation).
However, if you are asking how to use A* to find the shortest path from a single start to any one of a number of goals, your solution works fine, and your heuristic is indeed consistent. The minimum of multiple consistent-heuristics is still a consistent-heuristic, which is easy to prove.

Travelling Salesman Constructive Heuristics

Say, we have a circular list representing a solution of the traveling salesman problem. This list is initially empty.
If the user is allowed to enter a city and it's coordinate one by one, what heuristics could be used to insert those coordinates into the already existing tour?
An example uses the nearest neighbor heuristic : it inserts the new coordinate after the nearest coordinate already in the tour.
What are some other options (pseudo-code if possible).
There are plenty of construction heuristics you can use, such as First Fit, First Fit Decreasing, Best Fit, Best Fit Decreasing and Cheapest Insertion.
Those constructions heuristics are applied on bin packing normally, but they can be converted to TSP too. Documentation about those heuristics is here.
Since you're only inserting 1 unassigned entity at at time, all of these basically revert to what you call nearest neighbor heuristic (with a slight variation on ties), but note that that is not what they usually call Nearest Neighbor. Nearest Neighbor always adds to the end of the line, the nearest neighbor of all unassigned entities.
Now, what you really want, is a decent solution, without having to restart your entire construction heuristics. That's harder: welcome to repeated planning and real-time planning (and this documentation). I am working on a open source example for TSP and vehicle routing that does real-time planning.
You can of course generalize the idea you have mentioned:
Define k'th_path(v) = minimum weight of a path including max{k,not_visited cities} cities
Note that calculating the k'th path is O(|V|^k) [this bound is not tight]
Special cases:
For k=1 you get the nearest neighbor, as you suggested.
for k=|V| you get an optimal solution [note it will be very expansive to calculate].
There are not other heuristic because TSP is always about to find the nearest coordinate. At least I don't know an algorithm that can insert a coordinate and knows the nearest coordinate but there are plenty algorithm to find a good tour. A good heuristic is for example the Christofides algorithm, it works only in euklidian space but it give you a guarantee of the solution to be within 3/2 of the optimum. It's not very easy to code. Especially the edmond blossom v algorithm is for an expert skill. The importance of a guarantee isn't high enough because how would you explain that your method can deliver non-sense in some rare situation?

A* for finding shortest path and avoiding lines as obstacles

I have to get the (shortest)/(an optimal) distance between two points in 2D. I have to avoid shapes that are lines, that may be connected together. Any suggestion on how to represent the nodes I can travel on? I have thought of making a grid, but this doesn't sound very accurate or elegant. I would consider a node as unwalkable if any point of a line is inside a square (with the node being the center of the square).
An example would be going from point A to B.
Is the grid the recommended way to solve this? Thanks A LOT in advance!
I think this is essentially Larsmans' answer made a bit more algorithmic:
Nodes of the graph are the obstacle vertices. Each internal vertex actually represents two nodes: the concave and the convex side.
Push the start node onto the priority queue with a Euclidean heuristic distance.
Pop the top node from the priority queue.
Do a line intersection test from the node to the goal(possibly using ray-tracing data-structure techniques for speedup). If it fails,
Consider a ray from the current node to every other vertex. If there are no intersections between the current node the vertex under consideration, and the vertex is convex from the perspective of the current node, add the vertex to the priority queue, sorted using the accumulated distance in the current node plus the distance from the current node to the vertex plus the heuristic distance.
Return to 2.
You have to do extra pre-processing work if there are things like 'T' junctions in the obstacles and I wouldn't be surprised to discover that it breaks in a number of cases. You might be able to make things faster by only considering the vertices of the connected component that lies between the current node and the goal.
So in your example, after first attempting A,B, you'd push A,8, A,5, A,1, A,11, and A,2. The first nodes of consideration would be A,8, A,1, and A,5, but they can't get out and the nodes they can reach are already pushed on the queue with shorter accumulated distance. A,2 and A,11 will be considered and things will go from there.
I think you can solve this by an A* search on a graph defined as:
Vertices: origin, destination and all endpoints of obstacle edges.
Edges (successor function): any pair of the previous where the corresponding line does not cross any obstacle's edges. A naive implementation would just check for intersection between a potential edge and all obstacle edges. A faster implementation might use some kind of 2-d ray tracing algorithm.
I.e., it's not necessary to discretize the plane into a grid, but without it, the successor function becomes difficult to define.
A grid, and A* running through it is the way to go. All games i am aware of use A* or an adaptation of it for the global route and complement it with steering behaviour for local accuracy. Maybe you were not aware that using steering behaviour will resolve all your concerns about accuracy (search-engine it).
EDIT: i just remember a strategy game that uses flow-field. But it is not main-stream.
BTW: to get a feel for what steering behavior does for your objects take a look at the many youtube-videos about it. Some of them use the term path-finding in a more general sense: including the global algorithm (A*) as well as collision-avoidance, path-smoothing and object-inertia involved in steering-behavior.

How does space partitioning algorithm for finding nearest neighbors work?

For finding the nearest neighbor, Space Partitioning is one of the algorithms. How does it work?
Suppose I have a 2D set of points (x and y coordinates), and I am given a point (a,b). How would this algorithm find out the nearest neighbor?
Spacial partitioning is actually a family of closely related algorithms that partition space so that applications can process the points or polygons easier.
I reckon there are many ways to solve your problem. I don't know how complex you are willing to build your solution. A simple way would probably to build a binary tree cutting the space into 2. All the points divided between some middle plane. Build your tree by subdividing recursively until you run out of points.
Searching for the nearest neighbor will then be optimized, because each traversal of the tree narrows down the search area.
In some literature, they call this a kd tree
These two videos should help:
Explaining how a KD tree is built up:
http://www.youtube.com/watch?v=T9h2KKJ_Pl8
Explaining how to perform nearest
neighbour search: http://www.youtube.com/watch?v=2SbVSxWGtpI

Resources