For context, I am currently trying to make a 2d side-scrolling game that takes place inside a palace with lots of floors and lots of npcs having specific schedules. The player can move by point and clicking. There are specific jobs that the npc or the player can perform depending on their status in the palace.
I’m trying to architect something barebones and to start seeing some movement happening, and because astar2d seemed a bit limited, so I thought I would go with creating a NavigationRegion2Ds, one for each floor, and linking them with NavigationLinks.
First of all, I’d like to ask for opinions on whether or not this approach might sound … well … sound , instead of using astar2d or something else.
Secondly, when I am trying to create the nav regions (and pretty much create rectangular Navigation Polygons for each floor), only their outline seems to appear, and only when I am clicking on them, making me think that I’m setting them up incorrectly somehow.
Ok, the non-appearing coloured internal of the polygon appeared after I made it less narrow and pressed Bake NavigationPolygon, but there still seems to be a huge margin.
EDIT: To anyone that might stumble on this in the future, the agent radius option is what caused the margin. It seems to be a mechanism to avoid conflicts with collisions.
The NavigationPolygon has a default agent radius so if your outline surface is too small for this nothing will appear, but you already discovered this yourself.
In general an agent radius offset is needed because in pathfinding an actor is just a point, it has no shape, compared to physics where everything has a shape. The problem arises when physics shapes and navigation mesh surfaces have no margin because then the actors would get stuck all the time on the shapes. See documentation for navigation meshes for more detail here Using navigation meshes — Godot Engine (stable) documentation in English
For baking stability it is also better to have at least some agent radius because the deflate of the polygon paths fixes a lot of geometry issues (e.g. vertex overlaps caused by float errors) that can result in bake errors.
For your actual project, sure you can use navigation meshes, it is not ideally designed for this side view use but you can make it work if you want.
The benefit of AStar2D is that a waypoint navigation is very simple and robust, no matter what and how you place it, as long as you connect the points it will work.
A navigation mesh defines a surface so you need to be more careful to not cause overlap or other invalid surfaces that break the baking or pathfinding.
Also if you use NavigationLinks, those are no real polygons, just virtual connections between points. So if they stretch over longer distances you might run into pathfollowing issues, e.g. while an agent is in the middle of the link and repaths. So you might need to consider such situations in your scripts.
While we are on the subject, I did consider the astar2d initially, but changed my mind, because an npc’s behaviour (or the player’s) can abruptly change ( npc encounters combat, so they have to run an arbitrary distance away), or the player clicks on a specific (yet arbitrary) point, which is not one of the defined points of the star graph.
Hence, it looked like it made more sense to use NavPolygons, but instead of having each polygon cover an area, they would collapse upon the y axis and basically simulate a line (kinda). Maybe I’m missing something and astar would work better, which is why I’m making this post in the first place.
Finally, I was skeptical about implementing the movement between floors. I was thinking of having circular staircases and running an animation of the player and npcs running up, but as to how those animations would trigger, I’m at a loss.
AStar is simple point pathfinding, because of that you can not really use it to define inbetweens or areas. You would need to add many many points and it would still not cover an entire surface like a navigation mesh polygon would. That is one of the key differences between the two pathfinding options.
To connect otherwise disconnected navmeshes like floors you use navigation links.
When a NavigationAgent2D uses such a link point in the pathfollowing it emits a signal that you can use to take over in your scripts, e.g. make a “use” animation play while you warp your actor to the other side position to continue with the normal pathfollowing.
, instead of using astar2d or something else.
