Hello, I have a couple of questions regarding A* compared to the default Unity navmesh system.
Case 1: Say an AI must get into a room, but that room has a door and it is currently closed. How does the AI know that it has to get to the door (in order to open it) before it can enter the room?
Case 2: The AI is locked in the room because the player has closed the door from the outside and the door cannot be open from the inside. The goal of the AI is to exit the room in order to chase the player. But now that the door is closed, how does it know to still go to the door (although itâs closed) and wait for it to open? Wouldnât it instead act like a trapped fly and aimlessly hug the walls between it and the player?
Case 3: The AI is chasing the player into the room but the the player jumps onto a large table which is itself in the corner of the room. So heâs out of reach of the AI (since it canât climb on the table). The situation currently with the default Unity navMesh behavior is that the AI then exists the room and goes to the other side of the roomâs corner walls in order to attack the player through the wall. Because technically the player is âcloserâ this way (although itâs totally illogical). Does A* suffer from the same issue/limitation?
More generally, is there a concept of âwallsâ in A*? So that an AI would know not go to the other side of a wall, even if that location is technically closer to its goal.
I would recommend that you do not make the doors affect the navmesh at all. Instead pathfinding will never care about doors, however you would have a script on your AI that checks where the AI is about to walk. If it turns out that the AI is about to walk straight in to a closed door, it stops the AI and waits for the door to open (or does whatever else your game requires the AI to do when it encounters a door).
See 1.
Yes, unfortunately the same thing would happen in this package. The AI will try to get to the closest point to the player it can reach, and that may be in another room. If you know exactly where the walls are you can create a custom subclass of the NNConstraint class and override the Suitable method which determines which nodes a get-nearest-node query will consider. However detecting all the walls/rooms might be a bit tricky depending on your game.
Regarding your suggestion to not make doors affect the navmesh at all, how would you go about catching this situation: the AI somehow enters a doorâs trigger BUT itâs not supposed to go through that door. How would the AI know the difference? Is there a way to check that the path to its destination does NOT go through said door?
Also, in case a room has more than one door, wouldnât the AI only try to go through the closest one and never even consider using a second (farther away) door, since that would be a less efficient path?
It depends on how complex you want to make the system. It is possible to get the whole path of the AI, so you can calculate exactly which doors it would pass through. Itâs hard to say for me exactly which door detection method would work best given that I know very little about your game. My advice would be to keep it as simple as possible to start with (e.g open all doors within a distance X from the agent if the AIâs velocity seems to be in the doorâs direction) and then refine it if that doesnât work well. Usually you can get away with a very simple system even though in theory there are a bunch of cases when it wouldnât work perfectly.
Sorry, I should have given you more details: in case a room has more than one door and the AI needs to follow its target into the room. The AI will presumably go to the closest door to enter the room, because itâs the shortest way.
But if that door cannot be opened (itâs locked and the AI doesnât have the key) then I assume the AI wouldnât even try to go to the other (presumably opened) door to enter the room, would it? Because the second door would be farther away and the path would be considered less efficient. Or am I missing something?
In the game, AIs always have keys. But some (sliding) doors can only be opened from one side. So in that case keys do not matter.
So letâs keep the same situation: the AI wants to enter a room which has 2 doors. The first (closest) door cannot be opened from the outside. While the second (farther away) is open.
If the AI discovers that it cannot open the first door then how would the AI know to change its path and use the longer path to the second door/opening?
On top of that, if the AI can be told to go to the other door (which could easily be managed by the doorâs game logic), how can the AI be made to go to the other door while remaining on the outside of the room? Because as I understand it, it would think âok, no probs, Iâm going to the second door by crossing the room!â Which would be completely wrong of course, even though it is the shortest way.
(Again, this is based on your interesting suggestion that all doors in the game would be virtual only: the navmesh would remain unbroken so the AI will always look at the shortest path).
Ah. You have one-way doors. That is significantly different.
Then I think the best way is to use links. Links are unfortunately the area of the package that I am the least happy with, but it should be doable.
Check out the âRecastExample2â scene. It contains a few navmesh links.
So I think the best approach would be to apply a tag to the links (can be accessed through the âstartNodeâ and âendNodeâ properties of the script) and configure the Seekerâs tags so that it can only traverse those doors that it has keys for.
But still, if the doors are ordinary, but different AIs have different keys? How to force them to build different routes? Is it possible to mark the nodes as unwalkable for a particular path query?
