
Try the A* pathfinding algorithm with HTML5 canvas - coderdude
http://www.matthewtrost.org/projects/astar/
======
xedarius
One of the heuristics I implemented in my A _, was to link information from
the AI back to the routing grid. For example A_ will always pick the shortest
route, however this isn't the best route. Imagine you have the AI pinned down
in a building and the route finder picks a route out of the building, well
it's likely to pick the shortest route (out the front door). So all the player
has to do is put the cross hair over the door and keep shooting.

Now sure you could write some code to 'fix' this issue. Or you could let the
problem fix itself. If when an AI pawn is killed at a certain point, I added a
penalty to the surrounding nodes. This made the route more and more expensive
over time, after a short while the AI decided to use the back door and walk
around the building.

The important part of this is the player perception. To the player it looks
like the AI is flanking the player, and they're like 'woooo cooool', which is
the effect you're after.

~~~
palish
Brilliant!

That seems very similar to real life heuristics, actually...

"Holy crap, that guy in front of me just got blown away!" _runs out the back
door_

~~~
shoo
a few other tricks:

\- increase the cost of traversing nodes that are within known enemy firing
zones

\- in some circumstances if the destination is unreachable it might be
desirable to still compute a "best effort" path to the node that is the
minimal heuristic distance from the unreachable destination

~~~
palish
_\- in some circumstances if the destination is unreachable it might be
desirable to still compute a "best effort" path to the node that is the
minimal heuristic distance from the unreachable destination_

This is actually very important, especially in RTS games! If you have a unit
selected, and he's standing near the edge of a cliff, and you right-click off
the edge (intersecting lower-elevation terrian), then the naive Astar algo
would make the unit _run away_ from your mouse cursor, because it would search
the whole map for a valid way to get there --- however the player very likely
wanted to get as close as possible to the edge, e.g. to attack an enemy he
spotted.

(In other words, when pathing to different elevations, the the player almost
always wants the unit to "run up as close as possible" to the edge, _not_ try
to find a valid path all the way around the map.)

It's actually a very tough/interesting problem, because it's probably
impossible to "always do what the user intends in every situation" by merely
looking at his mouseclicks.

------
5hoom
As I am currently trying to implement the A* pathfinding algorithm in C++ this
is both timely & very cool.

Most interesting is the selectable distance heuristic function (never thought
about doing that in my own limited experience) which could mix things up a bit
with a pathfinding game AI or similar.

Kudos for sharing this little gem :)

[edit] implementing A* on my own for educational purposes, but here's a good
reference implementation in C++ on google code:

<http://code.google.com/p/a-star-algorithm-implementation/>

------
kaib
If you are interested in a production quality open source pathfinding library
take a look at Recast/Detour. It's used in a number of AAA game titles and is
probably one of the most robust implementations out there:
<http://code.google.com/p/recastnavigation/>

Full disclosure: the author works with me on Tinkercad, a web based solid CAD.

------
kunley
Folks are saying here how choosing a right heuristics is important. That's
right but there's another catch:

For something more real (ie. graph containing more edges) A* needs priority
queue for openset to extract the node with minimum f() in log time at most;
also note such structure needs to delete previously stored entry by _node_ not
by f(), which is not something priority queue has by default - another area to
fine tune in order to avoid time explosion.

------
matthewtoast
Hi, Matthew Trost (author) here. I'm actually a bit mortified that this found
its way onto Hacker News, as now my admittedly bush-league JavaScript code is
getting the brickbats. :-) In truth, I made it mainly as a practice exercise:
code, UI, documentation .... So, please check out the links offered by others
here, as many talented folks out there deserve attention for their far-more-
sophisticated work!

In any case, I love this discussion. Programming is fun.

~~~
bgrins
Hey Matthew, great job on this! I had fun learning this algorithm, too. My
implementation is here: [https://github.com/bgrins/javascript-
astar/blob/master/astar...](https://github.com/bgrins/javascript-
astar/blob/master/astar.js), and I have a demo here:
<http://briangrinstead.com/files/astar/>

I have added in a few optimizations: in my first run at it
([https://github.com/bgrins/javascript-
astar/blob/master/astar...](https://github.com/bgrins/javascript-
astar/blob/master/astar-list.js)) I used a standard array for the open and
closed lists, and I found it slowed down quite a bit as the graph size got
larger. I switched the implementation to a binary heap, which made it much
faster for larger graphs. Try the original demo then the new one at 100x100 to
see what I mean :)

------
steve_b
I recently learned about the A* algorithm from the book Eloquent Javascript.
Makes it very easy to understand.
<http://eloquentjavascript.net/chapter7.html>

------
andrewljohnson
Here's a-star I implemented on iPhone/iPad - the actual a-star algorithm
wasn't mine, just the game code around it. XCode project on GitHub:
[https://github.com/trailbehind/The-
World/tree/master/TheWorl...](https://github.com/trailbehind/The-
World/tree/master/TheWorld)

~~~
5hoom
Outwit the A* pathfinding ninja!

That's really nice, thanks for sharing.

------
gradstudent
There are about a zillion implementations of vanilla A* on the internet.
What's particularly interesting about this one? Do you have some cool new
heuristic function or some nice insight into how the search works? The as-is
version is pretty crappy. I mean, I can't even see the nodes expanded!

~~~
coderdude
As far as I can tell there is nothing particularly interesting about this
implementation. It's cool because it lets you play with it and because the
code is pretty short which makes it easy for anyone unfamiliar with the
algorithm to grok how it works. It also has some nice documentation:
[http://www.matthewtrost.org/projects/astar/documentation.htm...](http://www.matthewtrost.org/projects/astar/documentation.html)

For the Python programmer here is a very short implementation of A* that
someone on Stack Overflow posted:
[http://stackoverflow.com/questions/4159331/python-speed-
up-a...](http://stackoverflow.com/questions/4159331/python-speed-up-an-a-star-
pathfinding-algorithm)

~~~
gradstudent
Actually, I found the documentation reasonably poor. It does a good job of
explaining the API but does little to provide a would-be user with any
insights into why the search works, how it works or how efficient it is. It
doesn't even discuss why (or when) I might choose one of the three given
heuristic functions over the others.

i.e. despite its length, it's not actually a very useful document.

~~~
coderdude
While I agree that what you listed would be useful to include I think it's
important to note that it is documentation of his implementation (what the
various parameters are for) and not of how A* works. To that end he did a good
job. I especially like the little ideas he throws in under "Extending
astar.js." He links to the Wikipedia entry for those who want to know more
about how A* works.

~~~
gradstudent
Suppose the C++ STL documentation, such as it is, linked you to CLRS. Would
you regard it as adequate or would you demand more? I don't expect a rigorous
academic treatment here but at least _something_ to tell me (a) how efficient
the implementation is and (b) why (or when) I might want to use X or Y
provided feature over Z. For example: why is the Euclidean heuristic "slow"?
Is it a shitty implementation? Is it because it's underestimating the goal
distance too much? Another gripe: the author doesn't even tell me what kind of
open and closed list implementations are in use!

I don't mean to be a hater but this fails at contributing something novel
(which it doesn't), it fails as a learning resource which teaches something
interesting (which it doesn't) and it fails as a well documented programming
hack (which it isn't).

------
ioquatix
If you are interested in a slightly more step by step visualisation you can
try my original implementation: [http://www.oriontransfer.co.nz/learn/a-star-
maze-solver/inde...](http://www.oriontransfer.co.nz/learn/a-star-maze-
solver/index)

~~~
bgrins
I really like that visualization! It would be awesome to see that same
visualization side by side with Dijkstra's algorithm (same as astar, but with
fixed heuristics) to see how much better it can perform.

~~~
ioquatix
Thanks - if I get some time I may consider augmenting it - that visualisation
was put together as a proof of concept and as my first <canvas> experiment -
it needs some more work ^_^.

------
MasterScrat
I had made something similar some time ago, with a few more features (async
searches with priorities) and the ability to see what paths are tested:

<http://www.gravytea.com/labs/ariane/>

------
SeanLuke
In the back of my mind, I seem to recall that path-finding A * algorithms like
these actually aren't quite A * .

IIRC, this is a constrained version of A * under the assumption that the
heuristic h() is not only admissible but also monotonic, whereas A * only
requires admissibility. The additional monotonicity constraint guarantees that
the g() values of previously visited nodes never change, right? Otherwise if
you find a better g() path you may have to do a lot of costly book-keeping. I
presume the book-keeping is not part of the algorithm on display here.

------
baxter
It's so strange, I was just playing with pathfinding algorithms in
CoffeeScript this weekend and thought about putting something like this
together, but you have beaten me to it :) Really nice work.

~~~
swah
What is strange is that we don't do things because other folks have already
done it and miss a great learning experience :)

~~~
baxter
That's an excellent point! Perhaps I will put something together anyway.
Thanks for this :)

------
peterbraden
I made something similar a while back -
<http://peterbraden.github.com/maze.html>

It generates a random maze and uses a few different algorithms to find a path
through it. Refresh the page to get a new maze.

------
mcculley
I have a Java implementation at
<http://www.stackframe.com/software/PathFinder> which has a similar demo
applet.

------
humanfromearth
Check out my golang implementation of astar:
<https://github.com/humanfromearth/gopathfinding>

