Once I read the whole thing and understood the concepts fairly well, I sat down to implement it in our game.
First we needed to create nav meshes in the level. This was done via UDK Editor. It’s as simple as adding a Pylon and clicking “Build Paths.” However, to actually see the paths, we needed to press “P”. It actually took me half a day to figure that out, as it was not mentioned in any tutorial. I kept wondering why the paths were not generated and it ended up being a simple fix. Anyways, this needed to be done just once per level. Once a nav mesh is built, it is saved in the level information. It is now up to us to use the nav mesh in code. That is fairly easy too.
Here’s all the code you’d need to make a guard navigate around the level using nav mesh:
Notice that there’s potentially a While(true) loop in there. The code will loop until the destination is reached. NavMesh, if used well, is pretty robust in that all accessible areas of a level can be calculated. But just for that one off occasion when it fails, we need a backup. So I set a limit to the number of searches we make per destination.
Another tweak we had to do to the basic code is to get it working not just for an Actor destination (an object in the level), but for a Vector destination (any location coordinates). For some weird reason, the library/reference code only works for Actors, which we may not always have available. The code gets a little messy when we need to check using vector3 destinations, but it had to be done. (we have an investigate state for the guard where he doesn’t move to a particular PathNode, but to any given location in the level.)
As an ending note, I’d say NavMesh is working pretty well now. But we haven’t used it’s real power, which is to set goals and constraints. That allows the guard to traverse the same area in different ways based on different conditions. That is something that cannot be achieved using PathNodes.
So here’s hoping we get to implement more cool behaviors for the guards and unleash the power of NavMesh!