You can add NavModifier components to actors, but it’s not obvious how to use them. I would expect a travel/entry cost variable to be on them, in addition to some way to specify volume. How are they intended to be used?
Background
I have a navigation mesh set up for enemies that terrorize a miniature, tile-based town. However, they path directly to their target. I’d like their paths to be more jagged so that they, for example, would go right and then down rather than going diagonally down-right. This gives the player more consistent angles from which to shoot the enemies and increases enemy travel time to destinations, thereby giving the player more time to react.
So, I’ve created an Actor-derived BP that adds box colliders in a grid, forming narrow corridors between each box. This limits the enemies to straight lines within these corridors and works well enough while they are traveling (although, I’d still like their paths to be more straight, with limited right-angle turns). However, enemies still need to be able to reach houses that are located within these box colliders. So, ideally, enemies should avoid entering these boxes until their target is within one of them. Thus, it makes sense to make entering these boxes high-cost so that they are avoided only while traveling.
I could implement some custom pathing algorithm, but reinventing the wheel when the engine has a built in solution is a bit of a waste. So, I’d like to try getting UE4’s built in navigation meshes working before looking at alternatives.
In general if you add NavModifierComponent to an actor it will project that actor collision’s shape to navmesh as navigation area of indicated area class. If you use NavArea_Obstacle as the area class you’ll basically get what you need - AI will be able to enter the area only as the last resort (this area is super expensive).
Having said that, the A* we have (and A* in general) won’t give you those detour-shaped squared paths. Maybe with low distance heuristic (like 0.2) you’ll get something close… I wonder Let me know! But it sounds like a crucial part of your gameplay so you may end up implementing custom pathfinding anyway
Just tried this out. With modifier volumes, it works well. However, it’s broken for Blueprint use.
I added a box manually and increased its extents on x. It affected both the x and y axis. That’s not too bad, because the zones in my case are perfect squares. However, I then tried to add a second box. It affected the area in the same, broken way. But, it ignored the box’s position; the area was centered at the object’s origin. I removed the second box and moved the first to see if it also only extended from the origin. It did. This also applies to colliders added in a construction script. And, spawning volumes isn’t possible.
Overall, using nav modifier volumes works exactly as I want it to. However, managing them manually is a nightmare. So, the best solution I’ve come up with that works is to
Manually add a bunch of Nav Modifier Volumes to the level
Add an editable volumes array to the grid spawner BP
Individually add each modifier volume to the array
In the grid’s construction script, move and scale (volume extents isn’t editable, but scale is) each volume to position them in a grid pattern.
Select all volumes in the viewport and wiggle them a bit to update the navmesh; building paths doesn’t work.
This method isn’t ideal, but it does work. AI agents take jagged paths to their goal, only entering when necessary.
Setting the heuristic scale to 0.1 is pretty much identical to the default value of 0.999, but higher values are definitely more jagged and roundabout. So, I’ll at least stick with something below 1 for now. Although I may have to implement something custom eventually, I’d say this is good enough for now.
If you have any more suggestions, I’ll take 'em. Otherwise, I have my working (if somewhat flawed) solution. I only suggest more precise modifier support for blueprints, which would improve procedural generation. My thanks to you, good sir.
I agree NavModifier is not that configurable via Blueprint - it just uses owner actor’s bounding box and applies this shape (axis aligned) as navigation are. It shines when you use that in C++. We’ll address that with time.
What would be awesome if that (along other million things) if that would be documented. Even the APIs don’t say anything. They have million components and not a single line of documentation in the official API
,
Also, I’m seeing a lot of “To be addressed in blueprint at some point” posts from 2015. I’m not sure if Blueprint was forgotten in the AI department but it seems to be the case.
Let me know! But it sounds like a crucial part of your gameplay so you may end up implementing custom pathfinding anyway 