Advertisement

Is my A* search considering too many nodes?

Started by April 01, 2010 07:36 PM
5 comments, last by jezham 14 years, 7 months ago
I've not really needed a search function before. Recently though, I've been reading about the navigation mesh (http://www.ai-blog.net/archives/000152.html), and I've suddenly found huge interest in path finding. To help me fully understand the concept, I've based the code on the readings in this tutorial http://www.policyalmanac.org/games/aStarTutorial.htm. Though I haven't looked at the sample code there as their nodes are spread out, and I think v1 should be as simple as possible. Well I finally got it to work, based on stopping the search when the first score-based path is found. But here's the thing, is my code considering too many nodes? In the screenshot below, the path is 16 nodes, and 61 nodes are considered...this number increases quick...but not as quickly as when I forgot to check if a node was already closed as well as checking if it was already open - lol! Does this look kinda' normal to you? (apart from the random textures of course!) Thanks for your help. =)
No, it looks normal. You could hack your heuristic to make it a little better in this case, but it might become worse generally.

Join us in Vienna for the nucl.ai Conference 2015, on July 20-22... Don't miss it!

Advertisement
Looks fine.

It can't do any better because your heuristic will lead it straight to the wall, at which point it needs to backtrack and try alternate routes. Notice that once it escapes the small area behind the wall it doesn't explore any unnecessary nodes at all.
Ideal. I was a little concerned at first, after a good sleep and your experienced feedback I feel ready to optimize and add detail. Thank you!
I've had good experience reducing the searched nodes by adding a tiny adjustment to the "h" function that considers the straight line distance from the ideal path to the heuristic.

Not enough to make it inadmissible, something like 0.01 * straight_line_distance. It forces the search to consider nodes closer to straight-line before nodes in the opposite direction.
My A* thread is all about optimizing the algorithm - Feel free to look at it.
Advertisement
ID Merlin, when I write the navigation mesh version, I will probably drop the Manhattan distance completely - and use distance squared as there won't be many polygons to deal with.

Thanks Narf, I do read through related posts they tend to spark off ideas or just help me decide that I'm on the right path ;-)

This topic is closed to new replies.

Advertisement