Enemies not surrounding target

Hello! Basically I want my enemies that use FloatingPawnMovement to surround my buildings in order to attack them. I use AI Move To but they keep stucking and forming a queue of enemies who block each other. How do I make them surround the buildings? Should I use dynamic navigation instead of static for this? If so how do I make then ignore their own collision when they use navigation? (In blueprints)

changing the AI controller class (in the character blueprints class defaults) to Detour Crowd AI might help with pathing of many agents.

As for surrounding a specific point, the way I do this in my project is just to manually set waypoints and I do a little simple logic to prioritize which waypoints to go to based on distance from player and line of sight.

So I have a blueprint that is basically empty and just has a billboard so I can easily see them in the level. This is the POI (point of interest) or waypoint that my enemies seek.

On a timer they check to see which waypoints are within desired range of player and have line of sight. There is a few further cases in case they dont find the desired waypoint.

In order to make sure the agents don’t all go to same point, I have a boolean on the waypoints that can be toggled with an enemy has selected it and when it leaves to another. This way they can basically be marked occupied.

In my system I leave a lot up to random variability but with these basic rules it usually works out that the enemies naturally surround the player, and the way I place POI’s can influence what sort of formations they assume. So if I want them to be on a line if the player is in a general area, I just setup the POI’s so they’ll influence things that way.

I see. So how is this done on a target pawn? Since the player will be constantly building, I want every building to have waypoints, but if possible I want to expand this beyond buildings. How do I achieve this, what do I use?

well my situation is with a static level so it is different.

perhaps you can make your buildings into modular blueprints, where each building piece comes with predefined spots around it that enemies can use as waypoints?

For instance if you have a building that has the backside weak to certain enemy types, you could make some waypoints just on that side and give it a gameplay tag or some way to let certain units know to prioritize that waypoint above others. So the data you need is like a component mapped with a struct that holds any additional data units might want to know about the component. The component itself can just be a scene component because you only need to know a location.

Just an idea, but that would be first guess. I haven’t dealt with games that have such requirements so I can’t say anything for certain.

Thanks for responding! It looks like the waypoint method can’t be used in my case, since enemies are going to have different range, and it might get tricky there. Do you know if using dynamic navigation could help solve the problem? Like if we consider enemies as obstacles, they will try to find another way to approach the building. The only problem that keeps getting me stuck with this is that enemies do not ignore their own collision meaning they consider themselves obstacles and then the movement glitches… If anyone knows how to make them ignore their own effect to navigation, that could be very helpful.

I am using the crowd detour AI controller class and it seems pretty good about avoiding enemies bunching up together. But I think you’ll have to test it out a lot and probably end up extending it a bit with your own logic.

I am not familiar with dynamic navigation so I can’t say anything about that.

You can control the range of enemies to some degree in a simple way by adjusting the acceptance radius of their move to commands. So for instance if you make a larger radius for a ranged enemy, they would stop further away from the waypoint.

My basic philosophy for enemy AI is to have just a few environment waypoints keep tabs on what is going on around them, and then enemies query those. To me this is just simpler to manage compard to having each enemy query the entire environment. I guess the idea is similar to if you coded chess or something like that, where pieces query the board.

I found out that both crowd detour and RVO avoidance can only be used with character movement. However, I’m just using Floating pawn movement and a Box Collision. I’m getting really frustrated with this, because even if I use waypoints, should two pawns collide, they just completely stop moving, without any effort to go around or avoid each other. It is pretty annoying and frustrating since I tried a lot of methods. The only thing I haven’t tried is to make a custom avoidance component but it seems like a hard task. If anyone has anything in their mind, help would be much appreciated.

you could use character movement and just override the gravity to make it like floating pawn?

I find the character class pretty limiting since I have to use a capsule collision (that does not fit in my case). Do you know if I can overcome this difficulty too?

you might disable collision on the capsule and use something else? Not sure if the character movement stuff is intrinsically tied to that particular capsule - I dont think it is.

In my project, I only use that capsule for interacting with triggers, but I use the physics asset for more complex interactions (like hit detection) and I use sphere colliders for other types of detection (like knowing if a projectile was a near miss so we can play a “whiz-by” sound effect).

For my enemy AI they use that capsule for navmesh movement but same as my player character, their physics asset is used for complex collision queries (like knowing if I shot the leg or the head).

Ok I will try this! Do you know if it can support flying units?

The character movement component does have an enum for “flying” as one of the movement modes.

But I don’t know enough to say what might be unreals intended use for that. There is a ton of “flying AI” tutorials out there though, so I doubt it will be too hard to figure something decent out.

If your game is like RTS, a flying unit might possibly work exactly same as others, just elevate the skeletal mesh and of course it might not suffer movement penalties that others do.

Hey I actually got it working to some extent, but some enemies still collide and form a queue. I think I will combine this with some waypoints and it should be working! Where do you store these waypoints? Like the positions and wether they are filled or not?

well, that sort of depends on what your overall architecture is. There isn’t a right or wrong answer.

In my case, my waypoints are individual actors that I place directly in the level. On begin play, they use an event dispatcher to report themselves to my abstract manager class (I use the player controller or game mode for that).

The manager then adds them to an array and keeps track of their distance from the player. When they are close enough to player, they get added to another array which individual enemies will query for “active” waypoints.

I do it this way because my waypoints are only associated with the level, not specific actors, and being able to use the snapping tools is nice.

In your case it sounds like it might make more sense to have waypoints be scene components that are associated with building units though. So if each building is a blueprint you can add scene components to it and use their world location as waypoints.
You could also just use an array of vectors, and if you want to manually set their position in level, make them public and set Show 3d Widget:

then you can move them around per instance in the level:

Thanks! I noticed that the character movement only uses the capsule component for collision, completely disabling other components. Since my units do not fit in the capsule, is there any way to use their collision for colliding with actors?

You can change the diameter and orientation of the capsule, if that helps at all. So long as your unit was contained within the radius it should solve pathing issues, I’d expect.

If that makes the collider enormous such that it causes collision issues with other channels, that is where I’d relegate the collider to only being used for the pathing, and use other colliders set to other channels for other sorts of queries.

Beyond that, I am not sure. Perhaps you can add your own collision component and edit the code to point to that instead. Not sure if you need the source code or not to do that. I can only guess, I’ve never looked into the character movement component code myself, I only know what it does from a blueprint perspective.

I’m only working with blueprints too. I found a solution with the additional collision components not colliding; apparently, setting “Simulate Physics” on the editor and then disabling it with code at runtime solves the problem, and any other collision apart from the capsule works just fine.