Pathfinding - Avoiding Player & Other Instances

Alright so I've been trying to create a system of pathfinding based on the native pathfinding plugin.

Here is what I am trying to do:

      Have enemy objects find path to player while avoiding destinations of other enemy instances, i.e. no overlapping/stacking of enemies

      Prevent player and enemy objects from ever overlapping

      Have enemy objects find path around player object

      Prevent both player and enemy objects from ever "pushing"/"moving" each other

I have been working on this for a while now, and I cannot seem to get it to work. I don't have any current examples of my effort since I've been trying different methods and recently started from scratch.

What I've recently tried is comparing the destination nodes of multiple instances to prevent the destination being an overlap point, but nothing I do seems to be able to prevent the enemy objects from finding paths through the player object and treating all other instances of itself as obstacles.

I also cannot figure out a way to stop both objects from pushing each other in any way while.

If anyone has a reliable suggestion for an alternative plugin, or an example where someone has done multiple instances pathfinding around each other, that would be incredibly helpful. I have already taken a look around the forum but I haven't been able to find anything good yet, though I can imagine zombie/ship-based games would require some basic form of this.

Alright so I've seen two gritty fixes to the issues of overlapping:

1. Applying bullet behavior to each enemy sprite and having the instances "bounce" off each other.

2. Using custom movement to have each instance "push" the other.

There is another way I thought of, but it uses families and doesn't allow for dynamic additions of more instances. Plus, I don't have the full version of C2 so I cannot test it out yet.

What I'm really looking for is a way to do this using any number of instances of the same object so that I can keep things as random and dynamic as I need to. At most there should be no more than 15 or so instances of these "enemies."

hey —

can you explain more about way 1 ? capx is better

I am encountering the same problem in my game! I have not yet found a solution but I m actively trying to solve it. I will tell you if I find a solution.

OK, I have found a solution that seems to work pretty well. I will do my best to explain in simple terms/method.

First I have a main "player" that I move around with 8 directions behaviour. You can use whatever movement method you like.

Secondly I have a "node" sprite and "allies" sprites (which are to follow the player).

The "node" sprite has the behaviours of BOID (original boids not rex boids), as well as line of sight and custom movement. The "allies" have pathfinding behaviour only.

So I make a node for every instance of the allies (when ally is created, make node as well and pair together with instance variable for some kind of ID system - you can use UID if you like). The "nodes" are set to boid behaviour to flock with the other node instances, and target/destination to the main player, and the "allies" are set to path find to the node that belongs to their specific instance.

This works really well to simply pathfind to the location of the boid and avoid stacking up on top of each other. I will explain now the purpose of custom movement and line of sight...

I discovered that, when I walked into a box of solids (walls to make a room) that some boids would be inside the walls or on the wrong side of the wall to the player - causing the allies to pathfind to the incorrect place. I use the custom movement behaviour so if the boid node is overlapping a solid object (wall) then it will push out at angle towards the player. The line of sight is used as a correction to this because sometimes the boid will still push at some weird angle and through the wrong side of the solids (because the boid behaviour is trying to maintain the constraints you provide to it) so i check if line of sight is not available to simply set the node to be at player.x player.y, then the boid movement will take over for it again since it has line of sight once more.

If this is too confusing to follow I can make an example that demonstrates this - but I think I explained in simple terms how it will work.

~Sol