AI - Fixing Pathfinding Once and For All

3/22/2011 Game/AI: Fixing Pathfinding Once and…
Game/AI
« Collaboration | M ain | Why "AI Accelerators" Will Never Happen »
July 26, 2008

Fixing Pathfinding Once and For All
I normally do everything I can to avoid saying things that could be interpreted as a criticism of other games or developers
in the industry.
But in this case, I had to make a bit of an exception.
I need to talk about some problems we face with pathfinding. In order to prove that these problems still exist, I felt the
need to make this video ... which will hopefully be taken in the humorous and lighthearted spirit in which it was intended
All of these clips were recorded over the last week with the latest, most-recently-patched version of each game.
As you can see, we're still a long way from having robust pathfinding across the
board ... and it's even a problem in some million-unit-selling, AAA-quality titles.
It's not necessarily a universal problem. M any modern games do have high-quality pathfinding, and pathfinding often works
well in some of the games shown here.
But there are still too many games that do pathfinding the same way that games did in the 1990s.
(Note: The only reason you see lots of PC role-playing games here just comes down to convenience. These are the games I
had installed at the time. The problem isn't specific to any genre or platform by any stretch of the imagination; there are
plenty of console games with similar issues.)
To the best of my knowledge, most of these games use waypoint graphs for pathfinding. I think that's the reason for
several of the pathfinding issues you see in this video, and many of the pathfinding problems we face in the industry as a
whole.
www.ai-blog.net/archives/000152.html 1/36
I believe waypoint graphs are now obsolete. This article explains the limitations of the waypoint graph approach and lays
out a five-point argument for a better approach.
There was a time when it made sense to use waypoints for pathfinding. Back in the 1980s and 1990s, we were working
under serious technical constraints and we had to cut a lot of corners.
But we're a multi-billion-dollar industry now. Our target platforms have multiple cores and ever-increasing amounts of
memory, and we can afford to do pathfinding correctly.
There's a saying among AI developers in the industry: "pathfinding is solved." We have good approaches to every
pathfinding problem modern games face. We just don't always use them.
There's no reason not to have pathfinding that works in every game, every time.
Hit the jump for a detailed explanation.
Why Waypoints Aren't For Pathfinding

Let me show you what a typical waypoint graph looks like. Here's a small piece of Stormwind City in World of WarCraft:
Figure 1. Part of Stormwind City in World of WarCraft
Here's what a typical waypoint graph might look like in that area.
Figure 2. The same area annotated with a waypoint graph
There's another way to do it, and it involves using convex polygons to describe where AI characters can travel. This
representation gives AIs a lot more information about the world around them and supports much more intelligent
decision-making.
Here's what a navigation mesh looks like:
Figure 3. The same area annotated with a navigation mesh
Here, then are the five big reasons why waypoint networks fall short.
1. Some kinds of game worlds require a ridiculous number of waypoints.

Large, open areas usually require tons of waypoints sprinkled liberally throughout the game world to achieve adequate
movement.
A navigation mesh, on the other hand, usually only requires a couple of big polygons for these kinds of areas ... which
you can pathfind through that much more quickly.
Here's an example.
The image below shows a town in World of WarCraft called "Halaa." This is a relatively large, mostly open area that NPCs
need to be able to navigate through. I've edited out a few details, such as the flag and the fountain in town, for the sake
of this example.
Figure 4. The town of Halaa in World of WarCraft, seen from above (slightly modified)
With a waypoint-based system, we need to place a lot of waypoints to get full coverage. Even then, our NPCs will end up
doing a lot of zigzags during movement unless we specify a lot more waypoints than I've shown here.
Figure 5. Halaa with a waypoint graph
With a navigation mesh, on the other hand, we can describe the same area with a handful of convex polygons:
Figure 6. Halaa with a navigation mesh
The simplicity of the navigation mesh means we don't have to search as many nodes when we call our pathfinding
algorithm at runtime, and pathfinding will be faster as a result.
2. They make characters "zig-zag" as they move.

Waypoint graphs force your characters to stick to the graphs you create. This means that your characters are effectively
on rails, and will almost never take the optimal path from A to B ... because the most direct path will almost never match
the graph.
That causes unnatural pathfinding artifacts -- in particular, characters artificially "zig-zagging" left and right as they walk.
Here's an example. Let's say we want a character to walk from A to B:
Figure 7. Two points in Halaa
Here's what the path would look like with the waypoint graph I showed you earlier.
Figure 8. Navigating from A to B using the waypoint graph
As you can see, our AIs will be turning a lot while they walk along the yellow path.
Ideally, after we created the path, we could somehow adjust it to make it smoother ... perhaps by creating a Catmull-
Rom spline along the path points.
The problem is, waypoint networks don't have any information about anything outside the network, and that makes it
impossible to do path-smoothing and adjustment safely and reliably.
How can you create a spline if the spline is outside of the waypoint graph, and actually following its curves might make
you fall off a bridge?
You might think there has to be some simpler way to make a path. Unfortunately, with waypoint graphs, there isn't.
Again, if we deviate outside of the waypoint graph even a little bit, we could easily end up falling off a cliff or bumping
into a wall. We just don't have any way of knowing, since the graph doesn't have any of that data.
So in order to stay safe, we have to take the most pessimistic view possible, and stay on the graph at all times.
The navigation mesh path, on the other hand, would look like this:
Figure 9. Navigating from A to B on the navigation mesh
Since we know where a character can safely walk, we can smooth out the path in any way we like, so long as the
smoothing keeps the path on the navigation mesh.
("Oh," I hear you say, "but I can just add more links to my waypoint graph to smooth everything out! I'll connect all the
nodes in the whole town if I know an NPC can walk between them in a straight line."
"But that gives you exponential explosion," I reply ... "You're talking about 40 or 50 extra links in this example alone. The
number of connections you'll need between all the nodes approaches O(N^2) as the size of the area increases."
"OK," I hear you say, "In that case, I'll just mark each area between any set of 3 mutually adjacent waypoints as 'open' so I
know my AIs can walk anywhere in that area."
"That makes a polygon ... and you've just created a navigation mesh," say I).
The fact that navigation meshes tell us exactly where our characters are allowed to travel means we can easily use
splines to smooth our paths. All we need to do is make sure our splines stay inside the navigation mesh.
Going back to our Stormwind City example, here's a waypoint path (red) and a smoothed path on a navigation mesh
(blue).
Figure 10. A waypoint path (red) and a smoothed navigation mesh path (blue)
3. They don't allow path correction. That makes robust dynamic obstacle avoidance
difficult, if not impossible.
Waypoint graphs don't have any data about anything outside the graph. They don't know which areas characters can
legally walk on even one inch outside the graph.
That makes it impossible for pathfinding systems to modify waypoint paths to deal with dynamic obstacles robustly.
Let's imagine there's a large, heavy crate on the bridge in Stormwind City.
With a waypoint graph, we're screwed -- if the crate overlaps the waypoint graph, we have no idea whether to go around
it to the left or the right, or if our path is blocked completely and we need to take a major detour. We could always
guess, but if we make the wrong guess, we'll fall off the bridge and end up in the water.
Figure 11. A large, immovable crate on the bridge
With a navigation mesh, though, it's a lot easier, since we know what areas we're allowed to walk in. We do a bit of
raycasting against the barrel and adjust our path around it, keeping our path (and ourselves) safely on the navigation
mesh.
Figure 12. Navigating around the crate
Sure, you can address this in a waypoint graph, too, by dropping down tons and tons of waypoints until your waypoint
graph is as thick as grass (and your pathfinding as slow as molasses).
I don't know about you, but I'd rather run my A* search over one big polygon than several hundred waypoints.
4. They don't work robustly for characters that move differently.

Waypoint graphs tend to work poorly for characters with different heights, widths, turn rates, and other pathfinding
parameters. This means it's usually impossible to use a single, unified waypoint graph for all the different types of units in
your game.
When we think about AI pathfinding, we tend to think in terms of humans navigating around in a game world.
But AI systems need to control lots of different kinds of units -- tanks, planes, ships, hovercraft, motorcycles, orcs,
goblins, dragons, lumbering giants, flying and hovering creatures, and so on. In many cases, units need to do pathfinding
differently depending on their size, shape, and movement capabilities. A good pathfinding representation should handle
all of them.
Here's an example. Let's say we have a concrete bunker out in the desert with a few sandbags around it.
Figure 13. A bunker in the desert
If we have a human soldier, he can run along right next to the sandbags (the red arrow in the image below).
A Panzer tank, on the other hand, has to drive much farther away from the sandbags to avoid a collision (blue arrow).
Figure 14. The closest possible paths that a human soldier (red) and a tank (blue) can take around the sandbags
With a waypoint approach, you can't handle this robustly with a single representation. You need to use totally separate
waypoint networks for the tanks and the soldiers. Add a new "motorcycle" unit, and now you need a third network. And
so on for every different type of unit that has different movement capabilities.
With a navigation mesh, on the other hand, it becomes much easier.
Figure 15. Part of a navigation mesh around the outside of the bunker
Notice the two light green edges emanating from the corner of the sandbags in the image above. Since we know that a
soldier has a collision radius of 1 meter, and a Panzer tank has a radius of 5 meters, it becomes trivial for us to build two
different paths using the same mesh. We just compute the path along the sandbags, and then push it either 1 meter or 5
meters away from the corner, respectively, depending on whether we're doing pathfinding for a soldier or a tank.
Figure 16. Part of a navigation mesh around the outside of the bunker
Here's another example. Let's say we have a soldier on a motorcycle. Unlike human soldiers, motorcycles can't turn on a
dime while they're moving.
In the example below, it's obvious that the motorcycle rider can drive safely from his current position to the room at the
top (red line), but cannot turn into the hallway on the right since the angle is too sharp (orange line). Whatever
pathfinding representation we choose should be able to figure this out, too.
Figure 17. A motorcyclist can go into the room at the top (red) but not the room on the right (orange)
With a navigation mesh, this is relatively easy to do. We just test the turn angles and distances as we're doing the
pathfinding and reject any paths that require steep turns over short distances.
With a waypoint approach, on the other hand, it's essentially impossible. At a minimum, we'd need a completely separate
waypoint graph for soldiers on motorcycles, since we can't use the same graph that soldiers on foot are using. Adding an
entirely new graph like that for every unit with different pathfinding capabilities gets very cumbersome.
5. They don't have enough data to support what your AI needs beyond pathfinding.
AI search spaces aren't just for navigation. AIs need to be able to use the pathfinding data to tell them how to move in
the world.
A game character needs to constantly query the pathfinding system and ask: is it OK if I move here? How about over
here?
Games are increasingly moving to animation-driven movement systems that give animators control over the position of
game characters. That means that in order to know what the results will be if we play animation X, we need to figure out
where the character will be when X is finished, and whether that location is inside a wall, hanging over a cliff, or in some
other location the level designers don't want him to be.
Here's an example. The swordsman below has four moves: a left strafe, a right strafe, a backstep, and a big flying leap
into the air that sends him up 20 feet and then has him land 8 feet in front of where he started.
Figure 18. A swordsman with four animations that contain translation
In order to make sure my swordsman doesn't end up slamming into a brick wall when he leaps or strafes or backsteps, I
need to test the predicted end position of each of these animations against the navigation mesh.
Yes, it's possible to use your collision system to do raycasting. That will often give you useful information, and for
dynamic physics objects in the game world, it's usually the only way for AIs to find out about them.
But raycasting can be expensive, and when you only care about the static game world and not the dynamic physics
objects, it's faster and easier to query a navigation mesh.
Although I can use raycasting to tell me if there's a wall between me and point (X,Y,Z), the collision system can't tell me
if the swordsman will land in a position that the level designers actually want characters to walk in ... only a navigation
mesh can tell me that.
If you're still not convinced after all of that, let me try to address any remaining concerns you might have by answering
common questions about waypoint graphs and navigation meshes.
Q&A
But isn't it slower to do pathfinding on a navigation mesh?

Not at all. A navigation mesh is a graph, just like a waypoint graph is, and the core pathfinding routines are very similar.
The difference is that a navigation mesh has a polygon associated with each graph node.
The image below shows the graph connecting the nav mesh polygons.
Figure 19. An illustration of the graph (red) underlying a navigation mesh
Whenever you run the A* algorithm for pathfinding, you're always running it on some kind of a graph, whether it's a
square grid, a waypoint graph, a navigation mesh, or what have you.
In most cases, navigation meshes have performance similar to waypoint graphs. In cases where they cover the same area
with fewer nodes (such as Figure 6), a navigation mesh can actually be significantly faster.
But don't navigation meshes take a lot more memory than waypoints?
If done correctly, no.
Navigation meshes are a very simple and compact representation. In general, a nav mesh will only require a tiny fraction
of the memory required by the underlying rendering geometry for the static game world. A navigation mesh is much
smaller than a collision mesh, since it cares about fewer surfaces (it ignores walls, ceilings, and other unwalkable
surfaces) and uses a smaller number of much larger polygons to cover a given area.
A navigation mesh tends to use a few more points for each graph node than a waypoint graph in the worst case. And in
some cases, such as the town in Figure 6, a navigation mesh can actually be smaller because it's a simpler representation.
Most of the examples you showed were role-playing games. Why don't I see the same
kinds of problems in first-person shooters?
The problems are still there in many first-person shooters, but they're harder to spot due to the nature of the gameplay.
- M ost AIs don't live long enough to let you spot the flaws in their pathfinding.
- AIs will usually stop and shoot the moment they have line-of-sight to you, so their paths are a lot shorter.
- In many single-player FPS games, AIs don't move very much, and will attempt to snipe you from a relatively fixed position.
- A lot of modern FPS games provide AI sidekicks who will kill the enemy AIs so quickly they don't have time to move very
far.
Here's an example from Half-Life 2. With a little bit of experimentation, it's easy to see that the guard on the stairs is
locked to a single, linear waypoint path that runs directly up and down the center of the stairs. The guard still ends up
looking competent since he can shoot at you whenever he can see you.
When you take away ranged weapons and force characters to use melee weapons -- as with some of the Covenant
soldiers in Halo, the Icarus stealth assassins in F.E.A.R., or the M etroids in a M etroid Prime game -- waypoint graphs are
suddenly a much less attractive option (which is part of the reason all three of those games used navigation meshes
instead ...)
Look, I understand everything you said, but designers need to be able to put down
cover points, patrol paths, and so on. That's just essential for creating the AI in our
games.
Of course! You can still do that, even if you're using a navigation mesh.
The key is to separate the two representations. You use one representation (a nav mesh) for the pathfinding and
navigation, and another (designer-placed points) tell the AI how to use the world.
A navigation mesh doesn't prevent you from doing any scripting. It simply provides extra information for your AIs for when
they need to navigate more autonomously.
Here's an example. We have a patrol path (purple) for some guards patrolling around town and a special marker for an old
man who likes to fish in the moat a few times a day (red). The cover points (yellow) represent points where characters
could take cover around corners in FPS-style magic duels between the mages and warlocks of Stormwind City.
Figure 20. Various terrain markers (AI hints) and a navigation mesh
OK, but isn't it a lot of work to place a navigation mesh?

In general, placing a navigation mesh by hand is not much more labor-intensive than placing a waypoint graph. In both
techniques, the amount of time you spend creating the search space representation is a fraction of the time you spend
testing it in-game.
From my experience, it takes 1-3 hours to create a navigation mesh for a medium-sized level in an FPS game.
Creating a navigation mesh editor is relatively simple. All you need is the ability to drop vertices into the game world,
select them, and specify that they represent a polygon in the navigation mesh. You can determine the connectivity of
the navigation mesh based on which vertices are shared between adjacent polygons.
Also, there are some middleware solutions, such as xaitment, NavPower, PathEngine and Kynapse, that can handle both
the nav mesh construction and runtime pathfinding aspects for you. All of these are becoming increasingly robust and
viable solutions.
What if I want to have AIs walk up and down stairs? My designers don't want to have
to lay down a nav mesh polygon for every single step in the staircase.
A navigation mesh just represents an area that an AI can walk in. It doesn't replace a collision mesh -- your NPCs will still
use the underlying collision system for all their in-game collision.
You should be able to safely cover the entire stairway in a single rectangular navigation mesh polygon.
Can't I just give each point in my waypoint graph a radius, so I have circles instead
of points? That gives me a representation of what areas are walkable. That's how
they do it in robotics, too ...
That approach can work in some cases, but most areas in videogames have a lot of human architecture, full of angular
streets and buildings. Circles don't represent these kinds of spaces very well, and it's difficult to achieve the same level
of coverage that you can get with polygons.
Here's an example of the circle-based approach in Stormwind City:
Figure 21. Extending the waypoint approach with circles
(Quick anecdote: When I worked on the MechWarrior 4: Vengeance team, we found out the hard way that the circle-
based system that worked so well in outdoor areas really didn't work so well when we suddenly tried to put it to use in
urban areas. The team eventually made it work, but a lesson was learned: circles and urban environments don't mix!)
Also, having corners is important. In the case of the desert bunker Figure 16, we can use the corner of the navigation
mesh to create different paths for units with different shapes, sizes, and movement capabilities, such as a soldier and a
tank. Circle graphs don't have "corners," so it becomes much more difficult to create correct paths for different kinds of
units.
My game already has a collision mesh. Can't I just use that for pathfinding?
You can try, but it's not a good idea.
A collision mesh is optimized for collision, not for pathfinding. As a result, it's going to have a lot more polygons than you
need for pathfinding, and your search function is going to be slower.
For example, your collision mesh might have 1000 polygons on a cobblestone street that a navigation mesh would
represent with 1 rectangle, and 50 polygons on the roof of a building that a navigation mesh might not include at all
(since our characters would presumably never walk on the roof).
Also, part of the advantage of a navigation mesh (as with any search space representation) is that it doesn't just tell you
where your characters can travel; it also tells you where designers want them to travel.
If you let your designers create navigation meshes by hand, you give them the ability to tell the game "don't ever send AIs
here. I just don't want them to go there because it's not appropriate for this game." That's not the kind of information
you can ever get from a collision mesh.
All the examples as presented show the nav mesh as a 2D projection onto the space.
How would you handle a case like a bridge over a road, wherein you could go over
or under. Or a building with multiple floors?
Navigation meshes handle those cases very elegantly. Here's an example of what part of a nav mesh in Shattrath City in
World of WarCraft might look like (for simplicity, I've omitted the parts of the nav mesh on the far side of the bridge).
Figure 22. Part of a navigation mesh over and under a bridge in Shattrath City
In a navigation mesh, each polygon also typically stores a "height" parameter indicating how much vertical clearance that
is available for that polygon. So the polygon that you see passing under the bridge would know that it only has 7 feet of
clearance, and units more than 7 feet tall would know that they cannot use those polygons.
In the case of a multi-storey building, each floor can have its own navigation mesh polygons, connected with additional
polygons in the stairwells (elevators are a bit trickier, of course).
I don't believe in a one-size-fits-all approach. Different games require different

representations for pathfinding.
If you're making a strategy game that's entirely 2D, then an approach based on a grid is usually better, since grids give you
fast random access to any cell.
Otherwise, the navigation mesh really is the best approach we've found for robust pathfinding and terrain reasoning in
truly 3D worlds.
Suppose I were interested in implementing navigation meshes in my game. Has

anything been published to help me figure out how to build the meshes, do
pathfinding on them, and optimize them for my game?
Here are the ones I'm aware of:
"Simplified 3D M ovement and Pathfinding Using Navigation M eshes" by Greg Snook (Game Programming Gems)
"Polygon Soup for the Programmer's Soul: 3D Pathfinding" by Greg Hjelstrom and Patrick Smith (GamaSutra.com)
"Building a Near-Optimal Navigation M esh" by Paul Tozour (AI Game Programming Wisdom)
"Efficient Navigation M esh Implementation" by John C. O'Neill (Journal of Game Development, M arch 2004)
"Search Space Representations" by Paul Tozour (AI Game Programming Wisdom 2)
"A Fast Approach To Navigation M eshes" by Stephen White and Christopher Christensen (Game Programming Gems 3)
"Choosing a Relationship Between Path-Finding and Collision" by Thomas Young (Game Programming Gems 3)
"Improving on Near-Optimality: M ore Techniques for Building Navigation M eshes" by Fredrik Farnstrom (AI Game
Programming Wisdom 3)
"Smoothing a Navigation M esh Path" by Geraint Johnson (AI Game Programming Wisdom 3)
"Dynamically Updating a Navigation M esh via Efficient Polygon Subdivision" by Paul M arden and Forrest Smith (AI Game
Programming Wisdom 4)
"Intrinsic Detail in Navigation M esh Generation" by Colt M cAnlis and James Stewart (AI Game Programming Wisdom 4)
"Navigation M esh Generation: An Empirical Approach" by David Hamm (AI Game Programming Wisdom 4)
"Navigation M esh Generation in Highly Dynamic Worlds" by Ramon Axelrod (AI Game Programming Wisdom 4)
"Crowds in a Polygon Soup: Next-Gen Path Planning" by David M iles

(http://www.navpower.com/gdc2006_miles_david_pathplanning.ppt)
Note: Please e-mail me if you're aware of any other articles that should be on this list.
How many games have actually used navigation meshes successfully?

Here's a short list:
Halo 2
Halo 3
First Encounter Assault Recon (F.E.A.R.)
Counter-Strike: Source
M etroid Prime
M etroid Prime 2: Echoes
M etroid Prime 3: Corruption
Jak and Daxter: The Precursor Legacy
Jak II
Jak 3
Uncharted: Drake's Fortune
Scarface: The World is Yours
... and many more.
So there you have it: all the cool kids are doing it.
OK, maybe it works for you, but we used waypoints in all of our previous games, and
they worked fine.
Like they say, if it ain't broke, don't fix it ... and we haven't run into any of the
problems you're talking about.
Look at the big picture. Think 10 or 20 years down the road.
In that kind of time frame, do you think your games might have lots of different types of AI-controlled characters with
different shapes, sizes, and movement capabilities?
Will players have AI henchmen that they expect to be just as intelligent as themselves?
Will your game worlds be significantly larger, more complex, and more dynamic than they are today?
Will you have huge crowds of AI characters -- so many that just using simple steering and obstacle avoidance are no
longer adequate to make them coordinate with each other effectively?
Will your games have realistic physics and huge amounts of physically-simulated objects, and will players be able to use
the physics to mess with the AI characters in every way imaginable?
Will players be able to change the game world until it's virtually unrecognizable?
Will there be AIs in multiplayer that are expected to pass for human players?
There's no way to know what games will look like decades in the future, but it's clear that we're going to need much
more advanced AI. Part of that will require us to give game characters the data they need to reason about their
environment, find optimal paths, and deal robustly with complex, ever-changing game worlds.
Posted by PaulT at July 26, 2008 01:00 PM | TrackBack
Comments
Wow, great article! It was worth the wait :-)
To be fair, while the problem is technically solved, WoW has never really made it a priority to ship solid AI -- so it's almost
a bit unfair to pick on it. Sure, it'd be cool if Blizzard hired an experienced navigation mesh programmer, but would the
different show in the average case?
If anything, WoW is a rather depressing example that games can make huge amounts of money without good pathfinding.
alexjc
AiGameDev.com
Posted by: alexjc at July 26, 2008 11:08 AM
What game is that with the shotgun and the enemy stuck by the crate? (The 2nd clip in...)
Thanks! =)
Posted by: Eric at July 26, 2008 03:09 PM
Eric, I'd prefer not to mention any of these specific games by name, since I want the emphasis to be on the AI
pathfinding problem across the industry, rather than picking out the flaws in specific games (P.S. check your e-mail).
Posted by: Paul T at July 26, 2008 03:40 PM
All the examples as presented show the nav-mesh as a 2d projection onto the space. How would you handle a case like a
bridge over a road, where in you could go over or under. Or a building with multiple floors?
Posted by: PaulB at July 26, 2008 03:59 PM
Wonderful article. Really nailed it into me that Navmeshes are great. I now know more about them then I did before, and
I thought I knew how they fully worked :)
Now I wait for the article in 10+ years decrying navmeshes and a inevitable need for something better (or simply improved
navmeshes!). Hopefully, however, Navmeshes are a good solution for a long while, much more so then waypoints at least
:D
Posted by: Andrew at July 26, 2008 05:07 PM
[PaulB]
> All the examples as presented show the nav-mesh
> as a 2d projection onto the space. How would you
> handle a case like a bridge over a road, where in
> you could go over or under. Or a building with
> multiple floors?
Thank you, Paul; good question!
Scroll up a bit -- I've added this question to the list and answered it with an example image.
Posted by: PaulT at July 26, 2008 05:41 PM
> [Andrew] Wonderful article.
Thanks, Andrew! :)
Seems to me waypoints aren't in conflict with navigation mesh, they're just an alternative or simplication to raycasting.
Also, in both cases you would need a solution for points that you have to jump or climb or fall (or give up) to intelligently
follow the player, which you seem to have exploited in a couple examples.
Posted by: Henrik at July 27, 2008 12:24 AM
This is mostly why I no longer play against AI's. Its just so frustrating when they are incapable of handling the
environment. I now play TeamFortress2 almost exclusively since humans at least look convincing when navigating the
maps. Its honestly quite depressing.
Posted by: Ian at July 27, 2008 04:23 AM
> [Henrik]
> Seems to me waypoints aren't in conflict with
> navigation mesh, they're just an alternative or
> simplication to raycasting.
You can always use waypoints for giving AIs explicit paths -- for example, scripting an AI's movement during a cinematic
sequence. That's possible (and often necessary) regardless of what pathfinding representation you use, and it's not what
I'm discussing in my article.
What I'm criticizing is the use of waypoints for pathfinding. Technically, yes, it's "just an alternative," but it's generally an
inferior alternative, since it's not a robust approach to pathfinding and causes all the problems I discuss above.
> [Henrik]
> Also, in both cases you would need a solution
> for points that you have to jump or climb or
> fall (or give up) to intelligently follow the
> player ...
Yes, that's true regardless of what representation you use for pathfinding.
Posted by: PaulT at July 27, 2008 08:22 AM
Excellent article and great video Paul.
Posted by: RCornelius at July 27, 2008 11:34 AM
I too would like to know what game is in the stuck on crate clip.
Posted by: Balder at July 27, 2008 12:26 PM
I'm working on my first 2D web based action RPG.
I'll probably be using a waypoint system for pathing because it's easier to program.
What level of math is required to implement something like this? Calculus?
I'm thinking of some type of grid-based waypoint system for my simple flash based game.
Posted by: micsun at July 27, 2008 01:13 PM
A good number of the problems with waypoints that you've shown are due to programmer and/or designer error; many of
them aren't even that difficult to fix.
Having worked on games that use both, I can safely say that (much like any feature in games) it ultimately comes down to
how well the system is implemented.
I've worked with mesh system where the AI pathed unnaturally, cutting all corners as close as possible, generally running
in a straight line between them. I've also has to deal with breaking up the mesh appropriately any time a table, chair,
crate or other obstacle was placed or moved. In complex obstacle filled environments, like building interiors, a mesh
based system starts to become unwieldy. You may even end up with a separate avoidance system within the system to
avoid needing the create "islands" around these obstacles.
I've also worked with a waypoint/node based system that handles nearly every bug you mentioned above, including
smooth pathing between distant nodes. It doesn't handle every case (nor does the navigation mesh system); but it does
handle all of the cases that it needs to.
In short, use the right tool for job and heed the fact that navigation meshes are not always the right tool, even in fully
interactive 3D environments.
Posted by: Dreyruugr at July 27, 2008 01:27 PM
The majority of issues you seem to point out as issues in waypoint systems are issues in Navigation M eshes as well.
AI doesn't have to zig zag with a waypoint system and any good implemented systems it doesn't.
For AI to handle flying over ledges like you shown requires a special case for your navigation mesh (which can be added
just as fine to a waypoint system).
The advantage of a navigation mesh is purely it can requires less data to describe the same thing in waypoints. Which can
simply be shown by as the density of your waypoints approaches infinity your waypoints get closer and closer to
describing your navigation mesh. This is due to navigation meshes are just closed waypoints. As a result, any additional
issues in a waypoint system over a navigation is either due to density or implementation issues.
Density can be handled by a hierarchical system. Also waypoints handle adding of dynamic blockers can be simpler than
navigation meshes.
BTW I do prefer navigation meshes in general, but they aren't some magical solution since the properties are essentially
the same except with some slightly different handling of situations.
Posted by: Cryect at July 27, 2008 03:11 PM
I think that at least for anything with NPC's trying to engage the player (pretty much anything that is not a strategy game)
extra navigation maps for the AI will fall by the wayside. Wether or not the AI can walk there/take cover (and against
what) will be handled by the AI analyzing it's surroundings.
An AI would be prepped with data about it's model (height, width, length, mass, appendages, weapons (if applicable also
data about it or methods to determine weapon characteristics), what have you), it's objective (flee in terror, guard,
engage on sight etc), characteristics (ie use cover, spray and pray, take aim, feint, sneak) and data abouts its (or as for
weapons methods to gain data by trial and error) surroundings (Tiny bridges out of teakwood have a weight capacity of x,
Cover out wood are useless against my weapons, mist disables my weapons (That's somethings the AI should notice after
thr first shots and avoid after that)
Posted by: Bleh at July 27, 2008 03:57 PM
I hear what he is saying, and navigation meshes are a superior solution, but most of the problems he shows in the video
can just as easily happen in games that use navigation meshes.
Posted by: LittleBrain at July 27, 2008 04:52 PM
Navmesh is definitely another solution but it comes with its own problems. Having worked on a large GTA scale game that
used navmesh that got so complicated it was almost like building the world twice. Once for the visibile geometry and
then almost as long again to clean up the navmesh around it.
I still think there's a better solution than either of them... course if I knew what it was I'd be a rich man :P
Posted by: Jasta at July 27, 2008 05:00 PM
Fantastic article. I know only basic programming yet everything made perfect sense. Thanks for enlightening us all, the
field needs more people like you.
Posted by: Jon at July 27, 2008 05:43 PM
I for one think the Navigation M esh is superior to the traditional waypoint method. Is it the end of the line? No, the nav.
mesh has it still has it's on inherent problems, but overall it is the better system for the time being.
Posted by: Free Xbox 360 Elite at July 27, 2008 06:51 PM
That's a really good article. We chose to use Navmeshes because each character can quickly determine the amount of
free space around them in any direction. This is useful when coordinating large numbers of characters without having
one character push another character into a wall or off of a ledge. Typically collision probes are too expensive for every
AI character to use, but with the Navmesh it's very fast to get this information given the polygon that the character is
starting in.
One of our GDC talks (http://www.navpower.com/gdc2006_miles_david_pathplanning.ppt) from a few years back also gives
some approaches for automatically generating Navmeshes and modifying them at runtime (no audio with the slides, but
hopefully somewhat useful).
Posted by: DavidM at July 27, 2008 10:47 PM
A great article, I wish the gaming industry would take this with open arms, rather than keeping them shut on these
things.
One question tho, how would path-finding mesh work on enviroments where you and AI can move in 3 dimensions? (For
example a space-ship-shooter type of game.)
PS.
Second game in the clip I haven't seen, interested a bit. What's the name?
Posted by: DF at July 28, 2008 12:23 AM
Out of curiosity, what is the possibility of doing real time line of sight based navigation on today's platforms?
It was possible but very slow 10 years ago, however this makes intelligent characters independent of the environment
which is a big win for production time and decouples character technology from environment building.
If you are looking 10 - 20 years down the road is this something you are also thinking about perhaps?
Posted by: Ian Wilson at July 28, 2008 01:23 AM
> [LittleBrain]
> I hear what he is saying, and navigation meshes
> are a superior solution, but most of the
> problems he shows in the video can just as
> easily happen in games that use navigation
> meshes.
True -- some of the problems in the video are not specifically related to waypoint graphs; they were more intended to
show that the industry as a whole still doesn't always take pathfinding seriously.
And yes, navigation meshes are not a panacea; there have been some games that have used navigation meshes but still
had pathfinding issues.
> [DavidM ]
> One of our GDC talks
>(http://www.navpower.com/gdc2006_miles_david_pathplanning.ppt)
> from a few years back also gives some
> approaches for automatically generating
> Navmeshes and modifying them at runtime (no
> audio with the slides, but hopefully somewhat
> useful).
Thanks, David! I've added this to the article.
EDIT: I've also added you to the list of middleware vendors mentioned in the article. Cool stuff! Looks like exactly the
approach I've found to work.
Looks like kotaku took notice.
Some *interesting* comments there. Gives a bit of insight on what players really think/understand about AI and
pathfinding. Here are a couple of the highlights...
"Really all AI is designed to do these days is put up a bit of a fight and then die. Don't see that changing much for a
while."
"ive recently been playing alot of snes games, and the AI hasnt seemed to have improved from then to now."
"But like a few of you have said, why bother when in general the gaming public isn't going to notice or care?"
"i havent seen ai really improve in 10 years, and at that time the only improvement i saw was in half life, with ai that used
cover, some of the time, in principle."
http://kotaku.com/5029669/the-problems-with-pathfinding
Also, not that it hasn't been said already, but nice article, the video was great. It seems like it really comes down to
whether a company really cares and/or has budgeted the time and money to reflect their decision (but that really
applies to AI in general).
Posted by: thaspius at July 28, 2008 07:46 AM
How about the AI in Assassin's Creed folks? The guards that are following the assassin throughout the rooftops of the
entire cities, jumping and running everywhere?
Posted by: julius at July 28, 2008 08:20 AM
I totally agree with you julius, there are some great games out there that do some amazing pathfinding, I just wonder
how much an average gamer really thinks about it when he sees it. I've got a sneaking suspicion that a lot of them just
take it for granted and complain when it misbehaves.
Posted by: thaspius at July 28, 2008 10:41 AM
Great article! I generally agree with everything said. M y only complaint is the video early in the article shows a myriad of
navigation bugs, not necessarily related to the navigation network or its representation.
The spirit of the article is spot on - M odern AI calls for a number of features that become very difficult to manage with
waypoints (obstacle avoidance, smoother/more natural movement, group navigation or formations, the list goes on).
Our old system here used waypoints. Some complain about the navmesh pipeline being more of a hassle, but that's a tolls
problem, and a much easier problem to solve than fixing all the downfalls of waypoints in games employing modern AI
features.
Posted by: Bill at July 28, 2008 11:32 AM
Wow, men, pretty nice
This made remember i talked of something like this when I was on a Genetic Algorithm class where the npc would
navigate the whole map using a collision mesh, create a couple of paths and from those path start optimizing until a
shortest path was decided.
Posted by: CJLopez at July 28, 2008 01:26 PM
Great post Paul.
I also enjoyed your article on the AI Wisdom books. I read almost all of the articles you mention in preparation for my
GSoC project. I am implementing an open soruce navmesh generator for the open sourced game engine Crystal
Space/CEL.
The code is a bit behind schedule, due mostly to my indecision in what algorithms to use to optimize the navigation
mesh. The original plan is to use Hertel-M ehlron to do the triangulation and then pass the result mesh for simplification
to some merging algorithms, and do some culling of unusable or isolated fragments. Do you think this is a good approach?
What is the fastest/optimal algorithm to handle this sort of task? (but relatively simple to implement).
I am putting off some of the more advanced features for a second phase of the project, stuff like dynamic navmesh
generation (for destructible environments), solving jumps, doors, elevators, ladders links, handling tunnels/crawl spaces,
etc... however there really isn't that much information on strategies to implement these features (even in the articles
you appended to your post).
I was thinking about jumping cells(polygons), my idea is that if we calculate the relative height between adjacent cells, if
the cell is at 0.5m high he can jump, if the cell is at [0.0, 0.2]m high he can walk, if the cell is at 2.0m high he can hang
and climb, if the cell is at -2.0m he can jump and roll, etc... Adding this field would add more memory requirements, this
is just a naive approach to the problem but do you think it could work?
Any pointers by Paul or any other of the hundreds of AI experts that read this blog would be very helpful to create a
good, flexible and open sourced implementation of a navigation mesh.
TIA.
Thanks for the article, it is a great "sales pitch" for the use of navigation meshes.
Posted by: dannyBlue at July 28, 2008 03:02 PM
> [DannyBlue]
> The code is a bit behind schedule, due mostly
> to my indecision in what algorithms to use to
> optimize the navigation mesh. The original plan
> is to use Hertel-M ehlron to do the
> triangulation and then pass the result mesh for
> simplification to some merging algorithms, and
> do some culling of unusable or isolated
> fragments. Do you think this is a good
> approach?
Yes, I do; that's an approach I've used with some success in the past (though in retrospect it would have been a good
idea for me to have added more support for more designer control, if I'd had the time to implement that sort of thing).
> What is the fastest/optimal algorithm to handle

> this sort of task? (but relatively simple to
> implement).
Hard to say. I'd recommend checking out all the articles I link to above. M y approach was essentially just a greedy
merging algorithm, and it rejected any remaining polygons based on various factors: the Z values of their normals (i.e. the
poly faces sideways or downwards), surface area (throw out polys that are too small), and connectivity (toss any polys
that aren't connected to other nav mesh polys).
Posted by: Paul T at July 28, 2008 06:12 PM
As others have already mentioned, using a nav mesh wouldn’t automatically fix these problems. Another point is that in
some of the cases the issue may be with the capabilities of the object doing the search as opposed to the pathing logic
itself. If you look closely at the segment with the panthers you’ll notice that the Player jumps to get up and down that
one area. There’s possibly a break in the mesh there and if so then their pathing code might not take jumps into
consideration but I’ve seen the same thing when the NPCs weren’t set up the with ability to jump, either by design, lack
of animation or omission. Along the same lines the pathing in the river could be due to the monster not having the ability
to swim, which you’ll notice the Player does. Sure, it doesn’t look good but the issue may not be with the pathing code
or the search space.
Someone had asked about jumping so I thought I’d pass along some of what we did. To improve load speed we preprocess
the cell linkages and other related data. Part of this is determining all the potential jump cells. When something tries to
jump off the mesh we’ll check the list of potential jump cells and see if there’s one in line that the avatar could actually
jump to. Since you could have different guys with different sizes and abilities we’ll determine this when jumping or
searching for a path. Other factors like if you can hang from the cell and the hang height of the avatar would be
factored in as well. Assuming your avatars have standard jump abilities you could factor these jump cells into your
pathing. Since there was the potential for avatars to make great leaps in what we were working on we took a different
path to reduce the search space. What we did instead was set down “breadcrumbs” every time the Player would jump
off of one part of the mesh onto another and we’d factor those into the search. These could also be preplaced in the
mission as needed.
Regarding physical objects in the mesh one thing you can do is weight any cell with objects in it higher so the search
will prefer to use other cells. When objects are added or removed you update the cell information accordingly. If you
still need to go into or through that cell then, as someone else mentioned, you may need to come up with another
alternative. For one game we came up with a supplemental LoS pathing solution. In another our solution was much
simpler. Anything that wasn’t cut out of the mesh was an object that could be destroyed so anytime an NPC would bump
into one they’d just do a melee attack, destroy it and keep moving on.
Posted by: ScottE at July 29, 2008 09:03 AM
If the problem with using the collision mesh for a navigation mesh is the number of collision polygons, you could have a
compile time tool that takes the collision mesh and outputs a navigation mesh of the collision mesh's perimeter.
Posted by: Chris Peterson at July 29, 2008 09:43 AM
I just wanted to alert you to some of the cutting edge research being done on pathfinding, particularly a dynamic
lookahead heuristic thats been worked on, that I think you may find interesting. I've got most of the details here at my
blog:
http://www.oddco.ca/zeroth/zblog/2008/07/29/dynamic-pathfindingcutting-edge-research/
I attended the presentation, thought it was a pretty awesome algorithm. It certainly shares a lot of similarities with
navigation meshes.
Peace,
Zeroth
Posted by: Zeroth at July 29, 2008 10:05 AM
Just curious, wouldn't it be easy to simply add the ability to stick an invisible "navmesh" attribute on any given surface, as
simple as adding textures? Like, if I was using Hammer to work up a new map for HL2 as I was building I would do a pass
where I marked all the surfaces where people could move around and run as navigable? Then just hit compile and let el
computadora do all the hard work.
Posted by: Michael Leza at July 29, 2008 03:55 PM
I've seen some questions from some people about implementing a NavM esh system from scratch for their own games. In
my previous game studio I've implemented one and wanted to give some information about it.
Unfortunately most of the published articles in the game programming related books (eg: Game programming gems and AI
Game Programming Wisdom ones) are too specific on one part of the problem. They are good articles but they are mainly
suited for optimizing an already existing system. They don't give too much insight about the overall system and how to
implement one from scratch.
One good source I used is (which is already in the list)

"Efficient Navigation M esh Implementation" by John C. O'Neill (Journal of Game Development, M arch 2004)
This article talks about the problem overall, presents data structures and the pathing algorithm on the mesh. It is fairly
good although doesn't go too deep on the some hard implementation details. Unfortunately this article is extremely hard
to find, Not sold anymore, I've seen used copies on amazon. Fortunately we had a copy in the company.
Even after this article you'll be left with lots of low level implementation details. From simple 3D geometric math to
Triangulation, 2D-3D Boolean operations... For these don't look further than the CS literature and articles on
"Computational Geometry". (Well a warning here: Computational Geometry is a CS M asters course on most colleges and
require a good understanding of Linear Algebra as a prerequisite.)
This book is especially a good one:
Computational Geometry: Algorithms and Applications by M ark de Berg
There are also really good (and technical) articles on "ACM Digital Library". - Requires membership to access - a Well
worth membership.
On the side note, Since navmeshes generate graphs, you'll also have know graph data structures and traversals. (A* and
djikstra). Well there are a ton of literature. And I assume any AI programmer should already know about graphs.
On the scheduling side, it took me about 1.5-2 months to implement. (Tool and engine side, and bug fixing and a
presurizing lead alltogeter :) ). It had no runtime mesh modification support, designers had to switch navmeshes when
they wanted to modify it. For dynamic small obstacles sphere avoidance algorithm worked fine. Generally I was really
happy with the result. Although all I can say is, it is not a trivial task to implement a robust Navmesh system.
In my current company we are using NavPower. Even though it is alittle bit expensive I appreciate it alot. It saves you
from lots of headaces and development time.
Posted by: Tolga Tekin at July 29, 2008 04:57 PM
A couple of comments about World of Warcraft in particular (I admit it, I'm an addict):
Whatever navigation system it's using, it's not a waypoint graph. Enemies path in straight lines directly toward their
targets, sliding along walls/cliffs when they reach them. They can move to any location in an open area. Looks like a nav
mesh system to me.
Second, WoW has a clever system for solving AI pathfinding trouble: make it the player's problem. If an NPC can't reach its
target, it will "evade", resetting its health and returning back to its start location. Since the player was presumably trying
to kill the monster, this forces them to choose not to stand on special rocks and cliffs and other places that cause
pathfinding failures.
This is horrible from an "AI should make the monsters behave realistically" perspective, but brilliant from an "AI should
never let the monsters be pushovers" perspective.
Basically, if you're going to have an AI failure, err on the side of preventing exploits.
Posted by: Jason at July 30, 2008 04:33 PM
Wouldn't it make more sense to use a negative nav mesh, i.e. a map of places the AI can't pass trough?
Posted by: MichalT at July 30, 2008 09:36 PM
> [Jason]
> Whatever navigation system it's using, it's not
> a waypoint graph
That's why I said "most" of these games use waypoint graphs for pathfinding, rather than "all" :)
In any event, the video was more a demonstration of some of the pathfinding issues modern games still face, and was
intended to motivate the discussion. Some of the bugs are clearly unrelated to the pathfinding representation.
> [M ichael]
> Wouldn't it make more sense to use a negative nav
> mesh, i.e. a map of places the AI can't pass
> trough?
The "points-of-visibility" approach does this. That approach can work, but I find it's generally easier to run a search
algorithm (such as "A*") on spaces you *can* walk on than spaces you can't. The navigation mesh approach also lets you
mark areas with flags to indicate what kinds of creatures can move through there and how they should do so; it's a bit
more difficult to do that with a points-of-visibility approach.
Thank you Paul for this great Post !

There have been a lot of good articles in the past Gems/AI Wisdom books, however they're mostly addressing the low-
level CSG Operations. What I found to be the most difficult is the handling of non-blocking dynamic objects and tricky
movement capabilities. Three examples here:
1. How to handle partially overlapping areas, 1 above and 1 down below, where the lower one is filled with water and the
upper is some sort of bridge. This means you could do a "waterjump" to reach the upper one, but there is no real edge
generated from the base geometry.
2. Floating Objects. In a Quake-Style Game Items like Armors are sometimes found floating between 2 Jumppads. I can't
assign this item to an area and detecting the nearest "best" one is tricky.
3. Dynamic Objects which can be moved e.a. a winding bridge or a latter. Or even a sequence of jumppads.
So far the only solution I've seen is to get rid of the 2.5D Represention and switch over to using simplified BSP-Trees like
JP van Waveren did since Quake III. Am I wrong ? Are there any good lectures on this topic ?
Posted by: MarkusK at July 31, 2008 12:10 AM
[M arkusK]
> 1. How to handle partially overlapping areas, 1
> above and 1 down below, where the lower one is
> filled with water and the upper is some sort of
> bridge. This means you could do a "waterjump"
> to reach the upper one, but there is no real
> edge generated from the base geometry.
Yes, in this case, it may be difficult to get the results you need from an approach based on automatically generating a
nav mesh from the base geometry.
> 2. Floating Objects. In a Quake-Style Game

> Items like Armors are sometimes found floating
> between 2 Jumppads. I can't assign this item to
> an area and detecting the nearest "best" one is
> tricky.
I'm not sure I understand; what is the need to assign it to any navigation mesh regions at all? If the question is how bots
should be able to plan a path to jump and get the armor, it should be possible to either do this dynamically (by testing
various jump arcs that intersect the armor, and making sure they land on the navigation mesh somewhere), or by setting
up some number of scripted jump trajectories.
> 3. Dynamic Objects which can be moved e.a. a

> winding bridge or a latter. Or even a sequence
> of jumppads.
Yes, in this case, parts of your navigation mesh need to move. The only tricky part is updating the connectivity data
when your polys become adjacent to existing nav mesh polys; there are lots of ways to handle this, including scripting.
> [M ichael Leza]

> Just curious, wouldn't it be easy to simply add
> the ability to stick an invisible "navmesh"
> attribute on any given surface, as simple as
> adding textures? Like, if I was using Hammer to
> work up a new map for HL2 as I was building I
> would do a pass where I marked all the surfaces
> where people could move around and run as
> navigable? Then just hit compile and let el
> computadora do all the hard work.
Potentially, yes, though you could also end up with a lot more polys than you actually need for navigation. You also run
into issues in cases where you want to tweak the nav mesh separately from the geometry -- for example, you want units
to walk at least 3 meters from a wall for reasons specific to your game design. It's easiest to do this with a separate mesh;
with the approach you describe, you'd probably need to subdivide a lot of existing polys so you could mark them as
"navmesh" on one side and not the other.
I think at least two of the games you pick on are M M O's, World of Warcraft and Age of Conan? I remember a time when
path finding in M M Os were just straight linear pathing. The question is if correct pathing is even possible under the
requirements of the massive multiplayer environment. There's a lot more to pick on in these types of games but they're
so easy to fix that it's obviously a resource versus correctness compromise. Good article though.
Posted by: Peter at August 1, 2008 09:11 AM
>Now I wait for the article in 10+ years decrying navmeshes and a >inevitable need for something better (or simply
improved ?>navmeshes!). Hopefully, however, Navmeshes are a good solution >for a long while, much more so then
waypoints at least :D
I quote this because I would expect that demand to come from games with 3-D nav requirements (more than
M esh+height) as in underwater, air, or space based environments (my video game wet dream is the battle room from
Ender's Game).
I am not well versed in the issue so perhaps there is already something for 3 Space pathing that works well but is difficult
to apply to surface based environments. Either way this article is a great example of what time and knowledge can
provide, rather than just making fun of something or whining about it. Thanks.
P.S.
>Anything that wasn’t cut out of the mesh was an object that >could be destroyed so anytime an NPC would bump into
one >they’d just do a melee attack, destroy it and keep moving on.
I found incredibly comic. Think of traffic jams, long lines, or that corner you always bang into.
Posted by: Indu at August 1, 2008 11:53 AM
Are there instances where you'd need a "navigation volume"? i can see where you might have a flying unit in your bridge
example who wants to fly up from under the bridge to on top of it. is there any way you've seen to extend your mesh
idea to cover more "space" or at the point you need that are you back to setting "flyer waypoints" in space and just
using your the mesh to find landing points? (i think that's how the FAA operates, so maybe it's not such a bad model)
I can imagine with a sense of volume, you might find it easier to reason that the tank wanting to path around the
sandbags has a "step height" tall enough to go straight over them (not even considering deformable terrain or the
laughability of sandbags being a deterrent to tanks IRL), essentially treating the wall as if it were part of the ground
mesh. Otherwise, how can you fix the issue with hovering units/flyers/etc. without writing it off to a collision detection
problem or making different meshes for each type just like you'd have to with waypoints?
M y opinion:
M eshes > Waypoints. Got it.
M eshes > *. Not so sure.
Posted by: ifatree at August 1, 2008 02:33 PM
> Are there instances where you'd need

> a "navigation volume"? i can see where you
> might have a flying unit in your bridge example
> who wants to fly up from under the bridge to on
> top of it.
Yes. Again, you usually want every polygon in your navigation mesh to have an associated "height" value that indicates
how much open space is available above the polygon (where your definition of "above" is either directly vertical or in the
direction of the polygon's plane normal, depending on the needs of your game).
If you do it correctly, you should have no problem setting up a mesh to allow a flier to move from below the bridge to
over top of it.
All you're doing is using A* to find the list of navigation mesh polygons that will get the flier from one point to another,
and once you know that, you can much more easily figure out a path in terms of actual vertices.
> I can imagine with a sense of volume, you might

> find it easier to reason that the tank wanting
> to path around the sandbags has a "step height"
> tall enough to go straight over them ...
Yes, having a "step height" for each character is definitely recommended; that will help ensure that your characters
know how to do pathfinding in a way that corresponds to their movement capabilities.
Posted by: PaulT at August 2, 2008 07:55 AM
You might have to consider with the step height of that tank going over the sandbags whether this is an efficient
decision as this might unnecessarily slow down the tank and the cost to this climb-step has to be considered in the A*
costs.
Posted by: Nexii Malthus at August 2, 2008 07:04 PM
An incredible article. Thank you!
Posted by: Michael Kofman at August 4, 2008 01:15 AM
I think, that the simplest way to generate navmesh - is on "Figure 21. Extending the waypoint approach with circles" with
extension like...
Then 2 circles intersect, you can place portal \ graph node at this intersection and think about area inside this circle
amidst neighbour portal \ graph node as a navimesh poly. You make connected graph this way.
Then graph is done, you make postporcess - eleminate nodes that are formed a straight poly and merge them.
sorry for tangled story, i made some explanatory pics
pic1 - make graph node from circles intersections
http://img80.imageshack.us/img80/707/placenodesat7.jpg
pic2 - form navimesh polys
http://img225.imageshack.us/img225/7103/formpolysyr4.jpg
pic3 - optimize by merge postprocess
http://img262.imageshack.us/img262/7902/mergepolysij3.jpg
Posted by: Tomat at August 4, 2008 03:30 PM
Hello,
Great article, wow! lots of comments!...
well, I have some questions:
- Is it worth to use polyhedron-based navigation mesh for flying creatures, maybe in a 3D labyrinth? and how may I create
an editor for that kind of mesh?
- How can I say that is it posible to jump from a polygon to another? Considering jumping down of the bridge or jumping
across a fissure? [I think my idea (I didn't read it anywhere else) of the polyhedron-based navigation mesh may solve it]
I'll read the references ^_^
Thanks a lot!!!
~ Alfonso J. Ramos - Theraot@gmail.com
Posted by: Alfonso J. Ramos at August 4, 2008 11:17 PM
Oh, sorry, sorry, It has been a serius subject of study (I think) to create the polyhedrical approach [has been
implemented perhaps?], I will be looking forward for the next solution for pathfinding, I am sure that this is not fully
solved.
- Alfonso J. Ramos - Theraot@gmail.com
Posted by: Alfonso J. Ramos at August 4, 2008 11:24 PM
Great article! Really a nice, comprehensive and complete comparison of Way-Point-Graphs and NavM eshes. We try to
convince game studios of the same thing, and your article really helps to find great arguments.
We also provide a solution for automated NavM esh generation including several classifiers for Bots influencing the
NavM esh generation (falling and jump heights, max slopes, size classifiers etc).
It would be great if you could add our company to the above mentioned middleware solutions, as well.
Posted by: Thorsten at August 5, 2008 12:27 AM
> [Thorsten]
> It would be great if you could add our company
> (Xaitment) to the above mentioned middleware
> solutions, as well.
Done!
> [Alfonso J. Ramos]

> Great article, wow! lots of comments!...
> well, I have some questions:
>- Is it worth to use polyhedron-based navigation
> mesh for flying creatures, maybe in a 3D
> labyrinth? and how may I create an editor for
> that kind of mesh?
All you need to do in most cases is add a "height" parameter to each navigation mesh poly to extrude it upwards. There's
a bit of discussion of this in the section that contains Figure 22.
For some games that are *truly* 3D and have no fixed up and down, such as "Descent," you can use convex polyhedra
instead of 2D polygons with heights.
>How can I say that is it posible to jump from a

> polygon to another? Considering jumping down of
> the bridge or jumping across a fissure? [I
> think my idea (I didn't read it anywhere else)
> of the polyhedron-based navigation mesh may
> solve it]
There are several ways to handle this. The most robust solution is to create a special nav mesh polygon hanging down off
both sides of the bridge you mention, and across the fissure, and mark it as a "jump" region. Then your pathfinding
system needs to know that creatures should jump whenever they cross a "jump" region.
You could also do it in a more traditional way, and drop markers/annotations/hints into the world with start and end
points for each possible jump. This gives you a bit more control over the exact start and end locations of each jump, and
possibly the trajectories as well, but I prefer the first solution since it's integrated into the navigation mesh.
> [Tomat]
> I think, that the simplest way to generate
> navmesh - is on "Figure 21. Extending the
> waypoint approach with circles" with extension
> like...
I think that's a good approach, but I'm not sure it's much simpler than dropping vertices into the world and connecting
them.
If you imagine a case where you have a sequence of rectangular polygons, a manual nav mesh editor like the one I've
described requires you to drop 2 vertices plus 2 more for each polygon (since each neighboring pair of polys shares 2
vertices). With the approach you describe, you still have to place 1 vertex for each of the circles, and you also have to
allow the user to specify a radius for each circle as well as the direction of the circle's surface normal (since many
navigation mesh polygons will be on sloped surfaces).
So it's basically an equivalent amount of work.
In the case where your nav mesh consists of triangles connected in more of a random mesh, a vertex-based approach is
simplest; in that case, triangles often share 2 or 3 of their vertices with their neighbors, and describing them with center
points plus a radius and a normal probably wouldn't get you anything.
After over 8 years in the game AI world, this is the best article I have ever read on navmeshes. Bravo!
Posted by: Dr Paul Kruszewski at August 5, 2008 08:40 AM
Awww, shucks :)
Thanks, Paul!
why not scrap them both and start with a floor that is, essentially, a nav mesh? That way there need be no polygons to
describe anything and collisions could be detected by setting up objects like walls --which would seem to need polygons
and coordinates anyway.
Posted by: shandooga at August 7, 2008 11:43 AM
> [shandooga]
> why not scrap them both and start with a floor
> that is, essentially, a nav mesh?
If you do that, you're tying the hands of your artists and level designers by forcing them to fit into the needs of your
pathfinding system.
Artists and level designers need to be able to build the geometry of the game world using a potentially very large number
of polygons to represent the game world ... while you want a navigation mesh to be as simple as possible for the sake of
efficient pathfinding and easy editing.
Again, a cobblestone street on a curved road is a good example. You can usually represent the navigation mesh for a
road like that with one big rectangle, but you don't want to go to your artists and say, "M ake this all one big rectangle."
If you do that, there's no way for them to do the cobblestones (assuming you want real, bumpy stones and not just fake
it with normal-mapped cobblestones), and there's no way to make the road curved.
You really need to use separate representations for the render geometry, the collision geometry, and the pathfinding.
Keep in mind that you'll often want to tweak both the collision geometry and the pathfinding to be different from the
render mesh -- in the case of the collision mesh, this includes things like adding invisible walls to prevent the player from
going into certain areas or simplifying complex areas of collision for better collision performance; in the case of
pathfinding, this includes being able to tell your AIs "keep more distance from this wall when you're walking down this
hallway" or "don't go down this street, even though there's a render mesh and a collision mesh there."
Posted by: PaulT at August 7, 2008 01:17 PM
I think I may have an idea about jumping and stepping off things.
Ether a programmed side to the poligon or another poligon block to signal that another type of behaviour can be used.
Useing the bridge and road in Stormwind as an example the edges of the poligons next to the water would be
programmed to let the NPC know that at a sertain ammount of life the NPC can perform another action and jump to the
side at the line then end up in the waterand hopefuly safe. It could be adjusted for just about anything even marking
obsitcles in the mesh as hidable behind and others as just off the edge as walls and huge drops. Another fun thing it
might alow is for an NPC to make what might seem like a risk assesment alowing the NPC to only jump off cliffs if thay will
have a sertain amount of life left at the end of the fall so the fall risk is programmed at the top of the cliff and ledge. The
NPC would then step off to chase the player if thay will survive the fall. Hopefuly this wont be implemented on the
scryers or aldor lifts in warcraft though for anyone that has badly timed the aldor lift you'll know why.
If you alow for more layers of polygons you could have some programmed to overide the walking space mechanic and let
the NPC know theres an object that it can jump on if need be.
Jumping mechanics would probably be handled by three types of jump lines. One thats a one way jump and cant go
back, one that alows falling off a small ledge if you back track and the other that alows for turning around and jumping
back the way the NPC jumpecd in the first place.
I tend to visualise stuff like this and its hard to describe so i'm sorry if you cant pick though what i'm trying to say. If you
can I hop e it helps.
Posted by: Krysta at August 9, 2008 03:15 AM
Jumping is more or less a solved problem. In the past, I've seen it done either via connected pairs of annotations, or by
special "jump"-type navigation mesh polygons marking regions that creatures can jump across.
I also recommend checking out these two articles:
"Jumping, Climbing, and Tactical Reasoning: How to Get M ore Out of a Navigation System" -- Christopher Reed, Benjamin
Geisler (AI Game Programming Wisdom 2, 2003)
"Navigating Doors, Elevators, Ledges, and Other Obstacles" -- John Hancock (AI Game Programming Wisdom, 2002)
Posted by: PaulT at August 9, 2008 04:22 PM
Thanks!
Posted by: Thorsten at August 11, 2008 03:11 AM
The whole nav-mesh idea is great. In a limited way, it was done for Kratos in the God of War series. What they did is have
the map rendered in 2 strokes, the viewable map, and the playable map (userland).
Userland is where the character lives and can interact in. Which is why you cant jump off that big crate, or take a dive
off a ledge.
The viewable map is all the fancy architecture that you can see, but not interact with. The objects were placed in the
userland,
you could probably engineer something similar for the ai, using a raycast to determine accurate paths, and use simple
heights to see if the AI can hide behind it*. That'd take care of flying enemies, tanks, motorcycles, humans, etc.
of course, It's a tad more complicated than simply rendering only a flat 2d mesh, but it'd provide more accurate results,
especially if you have a very large group of various monsters/enemies attacking.
This approach would be a lot more complex, and the trade off would be CPU power. but then again, you could just have
the player live in this space as well, and just have the AI aware of what's going on.
plus, some games could use some better optimization. If I recall correctly, F.E.A.R. ran like crud for the same visual
effects of games in the same class.
Posted by: Chris Kalani at August 16, 2008 09:20 PM

AI - Fixing Pathfinding Once and For All

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AI - Fixing Pathfinding Once and For All

Uploaded by

Copyright:

Available Formats

3/22/2011 Game/AI: Fixing Pathfinding Once and…

« Collaboration | M ain | Why "AI Accelerators" Will Never Happen »

July 26, 2008

But in this case, I had to make a bit of an exception.

Why Waypoints Aren't For Pathfinding

Figure 1. Part of Stormwind City in World of WarCraft

Figure 2. The same area annotated with a waypoint graph

Here's what a navigation mesh looks like:

Figure 3. The same area annotated with a navigation mesh

1. Some kinds of game worlds require a ridiculous number of waypoints.

Figure 5. Halaa with a waypoint graph

Figure 6. Halaa with a navigation mesh

2. They make characters "zig-zag" as they move.

Here's an example. Let's say we want a character to walk from A to B:

Figure 7. Two points in Halaa

Figure 8. Navigating from A to B using the waypoint graph

Figure 9. Navigating from A to B on the navigation mesh

Figure 12. Navigating around the crate

4. They don't work robustly for characters that move differently.

Figure 13. A bunker in the desert

With a navigation mesh, on the other hand, it becomes much easier.

Figure 18. A swordsman with four animations that contain translation

But isn't it slower to do pathfinding on a navigation mesh?

Figure 19. An illustration of the graph (red) underlying a navigation mesh

OK, but isn't it a lot of work to place a navigation mesh?

Here's an example of the circle-based approach in Stormwind City:

Figure 21. Extending the waypoint approach with circles

I don't believe in a one-size-fits-all approach. Different games require different

Suppose I were interested in implementing navigation meshes in my game. Has

"Search Space Representations" by Paul Tozour (AI Game Programming Wisdom 2)

"Crowds in a Polygon Soup: Next-Gen Path Planning" by David M iles

How many games have actually used navigation meshes successfully?

Posted by PaulT at July 26, 2008 01:00 PM | TrackBack

Wow, great article! It was worth the wait :-)

Posted by: alexjc at July 26, 2008 11:08 AM

Posted by: Eric at July 26, 2008 03:09 PM

Posted by: Paul T at July 26, 2008 03:40 PM

Posted by: PaulB at July 26, 2008 03:59 PM

Posted by: Andrew at July 26, 2008 05:07 PM

Thank you, Paul; good question!

Posted by: PaulT at July 26, 2008 05:41 PM

> [Andrew] Wonderful article.

Posted by: PaulT at July 26, 2008 05:49 PM

Posted by: Henrik at July 27, 2008 12:24 AM

Posted by: Ian at July 27, 2008 04:23 AM

Posted by: PaulT at July 27, 2008 08:22 AM

Excellent article and great video Paul.

Posted by: RCornelius at July 27, 2008 11:34 AM

Posted by: Balder at July 27, 2008 12:26 PM

I'm working on my first 2D web based action RPG.

What level of math is required to implement something like this? Calculus?

Posted by: micsun at July 27, 2008 01:13 PM

Posted by: Dreyruugr at July 27, 2008 01:27 PM

Posted by: Cryect at July 27, 2008 03:11 PM

Posted by: Bleh at July 27, 2008 03:57 PM

Posted by: LittleBrain at July 27, 2008 04:52 PM

Posted by: Jasta at July 27, 2008 05:00 PM

Posted by: Jon at July 27, 2008 05:43 PM

Posted by: DavidM at July 27, 2008 10:47 PM

Posted by: DF at July 28, 2008 12:23 AM

Posted by: Ian Wilson at July 28, 2008 01:23 AM

Posted by: PaulT at July 28, 2008 07:29 AM