danielbeck.net
http://danielbeck.net
Photos and text from danielbeck.net en-usA*++
http://danielbeck.net/blog/1342.html
http://danielbeck.net/blog/1342.html<p>Just discovered a nifty new-to-me <a href="http://harablog.wordpress.com/2011/09/07/jump-point-search/">improvement on A*</a>, via a <a href="http://qiao.github.io/PathFinding.js/visual/">nifty interactive demonstration</a> of various pathfinding algorithms.</p>
<p>I’m supposed to be working on other things today, so I haven’t fully digested the <a href="http://users.cecs.anu.edu.au/~dharabor/data/papers/harabor-grastien-aaai11.pdf">paper</a> explaining the algorithm and may be misunderstanding it entirely. But at least part of the trick turns out to be one of those it’s-easy-when-you-know-how things: its inventor <a href="http://harablog.wordpress.com/2011/09/07/jump-point-search/">explains</a> you want to “prune the set of immediate neighbours around a node by trying to prove that an optimal path… exists from the parent of the current node to each neighbour and that path does not involve visiting the current node.” </p>
<p>In other words, at each step of the pathfinding, instead of subjecting every neighbor of the current node to A*, you try to draw a path from the previous step in the path to each neighbor. If that path crosses through the current node, then you can discard that neighbor as a possible next step.</p>
<p>Easy once you know how. And the speed increase compared to other pathfinding algorithms is shocking (seriously, play with that <a href="http://qiao.github.io/PathFinding.js/visual/">interactive demo</a> for a bit, the difference is amazing.)</p>
<br />
<br />
<p><small><i>This post was syndicated from <a href="http://danielbeck.net/blog/1342.html">http://danielbeck.net/blog/1342.html</a></i></small></p>