AI Doorways

Hi, so I have a room where these AI goblins roam around when you feed them candy, they run through these little sliding doors and chill in those rooms (and probably despawn if I decide to do that). But the problem I’m running into is that I don’t want them to choose any spot behind the door when choosing a location to run to. I’ve tried using a nav mesh blocker, but I’m unsure how I can temporarily enable and disable it. And maybe create a nav mesh that only certain colored goblins can run on.

The first screenshot shows the side the player will see; each colored door corresponds to the colored goblin and which door they should run into.

The second screenshot shows the backside where the player won’t be able to see and where I want the goblins to end up after they get their candy, but shouldn’t try to walk to that area until intended.

Hey @Zapking9224!

So what you can do is as follows:

Set a location in your behavior tree for each goblin that finds a location behind THEIR door if they have their candy. Set a middle point for the area behind said door in editor, like a static location type thing. Have them use a MoveTo node (assuming you’re using Blackboard/Behaviour Trees) to go to said location, but like I said, only once they have a True for something like “Has Candy?” on their blackboard :slight_smile:

If I misunderstood the question or something, let me know! If not, let me know if you hit any snags!

So I already have them walking to a set location behind the doors already working fine. That’s what those circles are on the ground in the second picture. I’m just not sure how to prevent them from wanting to go back there because my “free roam” task works by finding locations around the map and since I need a nav mesh behind the doors, they’ll include that in their search for locations to run to. Let me know if that makes sense :sweat_smile:

OK! So here’s some documentation, it’s a quick start guide for navmesh but we’re going to ignore everything before chapter 4! You’re looking for Dynamic Modifiers Only.

Also, you could ensure that the points they choose to navigate to in their random search are not within a given set of vectors, which would not block them from moving into the doors when explicitly told to do so.

Hey, maybe I’m just confused about how to implement this. But how does this prevent them from wanting to go to the other side of the doors?

Hey @Zapking9224!

So in the link provided by @Mind-Brain, you have several options. You can:

  • If you never want the goblins to go back into the room break up the nav mesh with nav modifier volumes then add a one way nav link proxy.
  • Or, you can assign priorities to where the room is a higher cost to move than your main play area, and will not move there until told to do so. That would require a query which is further explained here:

I hope the above is the solution you need!

Hey @Quetzalcodename, I believe that I have my cost all set up. However, I’m not sure how to correctly implement it. I’m sending a screenshot of the Navigation Query Filter for my Orange Goblin. I set up an enum to call a move to with the respective filter being called and that logic works fine. But when the goblin goes to run to its platform behind the doors, it doesn’t want to walk onto that modified navmesh. Let me know if you need to see anything else or if anything is unclear :slightly_smiling_face:

Hey @Zapking9224!

A few things:

  • Your acceptance radius is extremely small. Have you tried setting to a positive value?
  • What point is your ai character moving to?
  • The travel cost override is only to prioritize one path over another, lower value = more priority/easier to move. The starting areas behind the doors should have a higher travel cost, but I don’t see where you have set those up either.

You should have a collision with an invisible volume that blocks the door when there is no candy. When the character has candy, then you may disable collisions with this type of volume for that particular actor.

@shellcode Good call! I had this thought, too. Unfortunately this won’t work for them, because of the random pathing code the actors have. If they get a random path beyond that wall and they have no candy, they’ll mash their face against the invisible wall forever :frowning:

@Quetzalcodename The AI is supposed to move to those circular platforms which all have an enum corresponding to the AI’s color. That whole system works. If that wall with the three little walls didn’t exist, everything would work out fine. I’m just trying to find a way to prevent them from choosing a location to hide behind those walls because the player can’t actually get back there and they could get stuck and it wouldn’t be fair for the player to hope that they come out of there based off an rng value. Basically, the platforms behind the doors are just a place for the AI to go after the player has given them their candy and to get them out of the scene. They should ignore the backroom area until instructed to move back there.

Hey @Zapking9224!

What I think you may need to do is create another 3 zones for behind the doors with a high travel cost and/or a high entry cost (like 100) so it is easy for your goblins to leave, but extremely difficult to impossible to enter unless given a very direct position to move to inside and/or changing the query at runtime to focus on the small rooms since you will have the ability to do so. (Though I can’t quite see if you’ve already done this)

I think you are almost there with this, but making the rooms no-go zones may help you in the long run, or possibly creating a blocking volume at runtime as well.

Hey @Quetzalcodename!

I have one more idea that might possibly work and I’ve sort of got it set up but I don’t know if it’s working for sure. But I have an eqs system running to find a hiding location and there is a test to filter out according to cost value. But I’m not sure how I would set it up to filter out or know for sure if it’s working.