
JPS+: Over 100x Faster than A* (2015) [video] - eriknstr
http://www.gdcvault.com/play/1022094/JPS-Over-100x-Faster-than
======
amitp
Title's misleading. A* is also 100x faster than A* ;) It depends a lot on the
graph you give it.

JPS by itself (not JPS+ in this video) is notable for not requiring any
precomputation to achieve some speedup.

If you're willing to precompute some things, there are lots of other
techniques available for unweighted grid maps.
[http://www.cs.du.edu/~sturtevant/papers/GPPC-2014.pdf](http://www.cs.du.edu/~sturtevant/papers/GPPC-2014.pdf)
has an overview of techniques and some benchmarks that use real-world game
maps (Baldur's Gate, Dragon Age).

I believe the "goal bounding" from the video is called "arc flags" in the
literature.

~~~
krosaen
Yes, was just about to post, "Exact Routing in Large Road Networks Using
Contraction Hierarchies" which, after a one-time pre-processing step returns
an optimal route on a continent-scale network in milliseconds.

[http://dl.acm.org/citation.cfm?id=2351896](http://dl.acm.org/citation.cfm?id=2351896)

~~~
nonsince
What's the memory usage there? Is it on the order of what can be used for
games? Often memory is even more constrained than CPU time

------
y7
Paper:
[http://www.aaai.org/ocs/index.php/SOCS/SOCS12/paper/download...](http://www.aaai.org/ocs/index.php/SOCS/SOCS12/paper/download/5396/5212)

Previous HN thread:
[https://news.ycombinator.com/item?id=9714774](https://news.ycombinator.com/item?id=9714774)

~~~
_delirium
A somewhat more detailed paper (by the same authors):
[http://users.cecs.anu.edu.au/~dharabor/data/papers/harabor-g...](http://users.cecs.anu.edu.au/~dharabor/data/papers/harabor-
grastien-aaai11.pdf)

------
justinhj
Not to take anything away from the work but I think the title is misleading.
A* is an optimal algorithm for graph search so you cannot make it 100x faster.
What this does is make path finding faster by changing the structure of the
graph.

~~~
simias
It's a very practical optimization (not just a theoretical algorithm) so I
don't think it's really misleading in the context of game development.

That being said there's an important gotcha, those techniques require a
significant amount of precomputations (especially the bounding box one) so it
might not be practical if you have very dynamic maps.

~~~
Kiro
The map in my game is completely dynamic and every pathfinding technique I've
tried is way too slow. I've had to resort to a really stupid path finding
algorithm where the enemies just looks a few tiles ahead (meaning they get
stuck very easily). Any pointers?

~~~
yestoallthat
Check out "influence maps" or "potential fields" or "scents" or however they
may be called -- google any of those phrases in combination with pathfinding,
look at 1-2 videos and you'll grok the idea in a minute, I promise.

They may not solve all your problems or even any of them (hard to tell knowing
nothing about your game, after all), but I was absolutely dumbfounded when I
played around with them at how cheaply you can get some rather complex
(seeming) behaviors (e.g. put the player and some enemies in a maze, give the
players a scent that strongly attracts the enemies, but also give them a
slight scent that makes them repulse each other, and they'll automagically
split up and surround the player).

At the very least, if you're stuck with what you're doing at the moment, play
around with those, and maybe you can at least find a use for them that frees
up some processing resources for precise path finding where nothing short of
it will do.

~~~
spiffytech
Have you seen any efficient algorithms that avoid local minima/maxima[0]? All
my research leads to either algorithms resembling Dijkstra, or complicated
research papers I'm not sure how to implement.

[0] Potential fields can't tell you a route is a dead end until you reach the
dead end. Then they only tell you you're at a dead end, but don't tell you how
to get out and find a viable route. Add-on exit-a-dead-end algorithms I've
seen have very inefficient movement.

Algorithms to avoid the dead end in the first place have to look ahead so far
that you might as well use Dijkstra/A*.

\----

Some papers I've turned up:

Potential fields:

\-
[http://www.gamedev.net/page/resources/_/technical/artificial...](http://www.gamedev.net/page/resources/_/technical/artificial-
intelligence/motion-planning-using-potential-fields-r1125)

\-
[http://www.heikohoffmann.de/htmlthesis/node56.html](http://www.heikohoffmann.de/htmlthesis/node56.html)

\-
[http://www.researchgate.net/publication/222662144_Solving_th...](http://www.researchgate.net/publication/222662144_Solving_the_potential_field_local_minimum_problem_using_internal_agent_states)

\-
[https://randomaccessmaths.wordpress.com/2013/10/27/potential...](https://randomaccessmaths.wordpress.com/2013/10/27/potential-
field-nav/)

Harmonic Potential Functions (related to potential fields, they attempt to
solve the local minima/maxima problem)

\-
[http://repository.cmu.edu/cgi/viewcontent.cgi?article=1625&c...](http://repository.cmu.edu/cgi/viewcontent.cgi?article=1625&context=isr&sei-
redir=1)

\-
[http://www.itst2007.eurecom.fr/site/var/html/h1053/file1221....](http://www.itst2007.eurecom.fr/site/var/html/h1053/file1221.pdf)

\-
[http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=429591...](http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4295916&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D4295916)

\-
[http://ncsu.summon.serialssolutions.com/search?s.cmd=addFace...](http://ncsu.summon.serialssolutions.com/search?s.cmd=addFacetValueFilters%28ContentType,Magazine+Article%29&s.fvf\[\]=ContentType,Journal+Article,f&s.fvf\[\]=ContentType,Conference+Proceeding,f&s.fvf\[\]=ContentType,Dissertation,f&s.fvf\[\]=ContentType,Journal+%2F+eJournal,f&s.fvf\[\]=Language,English,f&s.fvf\[\]=ContentType,Book+Chapter,f&s.light=t&s.q=harmonic+potential+field+ship+navigation)

~~~
yestoallthat
You're way ahead of me, I really just dabbled, and I kinda embraced the
inefficiency. Though when I did the calculation on the GPU the bottleneck kind
of became reading pixels of the texture data for individual agents to make
decisions on - otherwise, the potential field updated way faster than the
agents could move, and local minima didn't exist long enough to matter. But of
course that all really depends on the game map (resolution) and gameplay, and
even just having requirements like map sections where some agents don't fit
through, while others do, might make it kinda useless.

I think the main power is that potential fields reduce the complexity of the
calculation to the map and the number of goals, with an infinite number of
agents being able to use that at little cost, but you pretty much always have
to build additional pathfinding on top of it. For example, for some games it
might be fine for agents to follow the potential field generally, but every
tick one of them gets to use Dijkstra/A*, and if that points the other way it
follows that path until coming close to another agent or something. Too much
efficiency can be off-putting, but also be too predictable and easy to exploit
as a player, that's also worth noting. But of course, I'm kind of
rationalizing my lack of deeper knowledge here, I'd love to be able to do it
perfectly, and then tone that down for realism/gameplay. Alas :)

------
nhaehnle
I wonder if any games use a landmark approach to bound their A* search.

The basic idea of landmarks is that you choose a small number of landmarks
(e.g. four corners of a map) and for every landmark, you pre-compute the
distances to every node. You can then use this information to get a lower-
bound for the distance to the target via the triangle inequality: d(p,t) >=
|d(p,LM) - d(t,LM)|.

This is obviously weaker than the goal bounding explained in the video, but
the precomputing only takes O(n). We used it quite successfully in a global
router (for EDA), where the heuristic lower-bound is often _much_ better than
a standard A-star heuristic based on geometric distances, because edges could
have wildly different costs.

~~~
karussell
I'm curious: what does "global router (for EDA)" mean?

And yes, A* & landmarks is really nice :) !

~~~
rasz_pl
its something no remotely competent engineer uses, but tool providers love to
dick wave around

[https://teespring.com/shop/autorouter](https://teespring.com/shop/autorouter)

~~~
nhaehnle
You do know EDA is about more than just PCBs, right? Good luck routing
millions of nets in a microprocessor design by hand...

The _really_ competent engineers use the tools for the bulk of the problem,
and fix up by hand where it makes sense.

~~~
rasz_pl
Yeah, I automatically went into what I know :/ Its impossible to route
manually there days, which doesnt mean automagic tools are even remotely good,
same goes for synthesis (fpga).

------
k2xl
Just watched the entire video - very interesting; however, there are two major
caveats the speaker mentions that is worth noting.

1) This requires expensive precomputation. He mentioned it took 10 hours on
one of the large starcraft maps. 2) (I may have misunderstood this point) This
does not necessarily respond well to map changes - so in maps where you have
the map changing structure (new walls, etc) you will have to run the
precomputation again.

With that said, very interesting stuff coming out of Digipen.

~~~
vanderZwan
I think the Goal Bounding Gate optimisation he talks about could help with
both: it's still O(N²), but if N is limited to those gateway nodes that would
cut down on costs tremendously. But that all depends on whether it's cheap to
find those gateway nodes automatically.

------
lngnmn
So, basically, it is about a much better heuristics, not a general algorithm.

Of course, with a specialized heuristics one could get a lot of pruning, but
generally, if there is no way to come with a specialized heuristic when there
is no way to have a jumping heuristic (one have to take one step at a time)
and there is no way to look ahead for a specialized nodes, the A* is still the
king.

But in AI almost everything is about finding a good-enough heuristic.

~~~
zamalek
JPS+ is also about skipping operations. It's a skip list expanded to grid
format.

------
gens
And i just implemented A* yesterday...

JPS is great. I remembered it from a former talk a while ago.

From the little experience i have with pathfinding, it seems to be an
interesting topic with many little details to be explored. Like smoothing a
path, smoothing/tuning a path in regards to loss of "speed" when turning,
avoiding dynamic obstacles like other "agents", "flocking" of groups, various
different ways of representing a "map", and probably many more.

------
karussell
Contraction Hierarchy (CH) is also at least 100x faster as A* . CH has nice
properties of having good memory efficiency, optimality, any graph etc. And I
am very sure JPS is not that generic applicable like CH. Still all 'fast'
routing algorithms have their own drawbacks of engineering complexity, pre-
processing time and memory requirements, potential lack for time dependent
support etc.

If you want to have the best summary of routing algorithms currently available
then read 'Route Planning in Transportation Networks' (2014)
[https://arxiv.org/abs/1504.05140](https://arxiv.org/abs/1504.05140)

And if you want fast implementations for routing algorithms like Dijkstra, A*,
CH and Landmarks check out GraphHopper:
[https://github.com/graphhopper/graphhopper](https://github.com/graphhopper/graphhopper)
(note: I'm one of the founders)

~~~
danpat
Hello from OSRM :-) I would've quoted exactly the same paper, it's the best
overview that I know of.

~~~
karussell
Hi back :)

------
sand500
I had an idea when I took my algo class to overlay a small graph of "highways"
on a map and computer all pairs shortest path to that sub graph. Then when you
do your search, you do BFS from both the start and goal till you reach a
*highway node" and then you have a short but not optimal path between two
points without too much computation.

~~~
TillE
Something like that is an essential optimization when pathfinding over long
distances. You often need to answer the question _can_ I go from A->B->C long
before you need to say _how_ exactly you do it.

------
vanderZwan
I had trouble watching the video on GDC (it kept breaking when changing
chapters, for some reason), so for anyone else with the same problem, here's a
Youtube Mirror:

[https://www.youtube.com/watch?v=KFwxqN_nASM](https://www.youtube.com/watch?v=KFwxqN_nASM)

------
Tloewald
In a sense the JPS+ algorithm seems to be to be turning the grid into s kind
of nav mesh and if you were to explicitly do this instead you might actually
get a better and more general solution that's also easier to update in real
time.

The boundary checking improvement would be simplified by dividing the map into
islands divided by gates (per his closing remarks) limiting the damage to
precalculated data from changes to the map (assuming they occur in one island
at a time)

------
revelation
This seems to be specifically for grids. Of course essentially no modern AAA
game uses grids for navigation anyway, they use convex polys in a nav mesh.

------
botexpert
Sounds similar to
[https://en.wikipedia.org/wiki/Contraction_hierarchies](https://en.wikipedia.org/wiki/Contraction_hierarchies)

There was a paper by Microsoft Research where they find shortest path from one
point to another in time equivalent to 5 memory reads + they sped up
significantly the precomputation times and lowered memory requirements.

------
mcguire
Wait. 100× faster than an _algorithm_?

