1
\$\begingroup\$

So more often than not I have a case where two agents get the same destination vector3.

This causes some hiccups because they won't be able to get to their target because they block for one another.

I was thinking that I am not the only one who has faced this issue and was wondering what you guys do to fix such an issue?

An example of this could be if I want my agents to go to the nearest tree and chop it down. Since both agents have the destination which is the trees transform they will go to the same position.

\$\endgroup\$
  • \$\begingroup\$ There is no way anyone can solve this without more detail about what you've done. \$\endgroup\$ – Engineer Mar 19 '18 at 11:21
1
\$\begingroup\$

If the tree example is representative, where the destinations the AI tend to bunch up at are "job sites," then you can solve this by using a claim system.

When an AI goes looking for a job to do, it searches for the nearest unclaimed job site. Then it places a claim on that job site before proceeding.

The next AI to search for unclaimed job sites of the same type won't be assigned the same one, because it's already been claimed.

When an AI needs to stop work (has a full load of wood to bring back, changes jobs, gets interrupted, dies) it releases its claim so that it doesn't gum up the works with claims that aren't currently in use.

One issue with this system is that if it acts globally, it can give the AI a kind of clairvoyance. Each one knows what every other is doing and which job sites will be in use, even if nobody's nearby yet. This can lead to strange behaviour like an AI who's been ordered to chop wood walking away from the tree right next to them (because it's been claimed by another AI who's still pathing over from the far side of the map).

To solve this you can introduce some hierarchy & local awareness to it. Say, have a resource patch entity that encompasses many trees. It knows how much harvesting capacity it has, and AI pathing from a long distance away can register their claim with the patch itself. Only once they get close do they bother claiming an individual tree. That way the coordination looks more like what can be accomplished with regular senses & shouted updates, rather than ESP or a central traffic control system. ;)

\$\endgroup\$
  • \$\begingroup\$ Thank you so much for your response i actually realized this approach a few hours ago so i am glad that you could confirm it. In a more practical sense what I did was to add a script to the tree that had empty gameobjects as "go to points" which the agents could then occupy. Does this make sense? and is it the correct way to implement it? \$\endgroup\$ – Marc Rasmussen Mar 19 '18 at 12:41
  • \$\begingroup\$ There are generally many ways to skin a cat. If this one is working for you, then it would appear to be correct for your needs. \$\endgroup\$ – DMGregory Mar 19 '18 at 12:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.