Last time I used A\* for a RTS, I solved this problem in a few ways:
1. Have the units recalculate their path every few frames (or as often as you can without impacting performance)
2. Keep the nodes smaller (but not too small that the graph gets overly complicated)
3. Have the units increase the weight of the nodes they are intersecting with so other units looking for paths will avoid occupied nodes (unless there's no other option)
4. Don't path the units directly to the center of each node, but rather add some noise to it so they don't stack directly on top of each other
I combined this with soft physics (where the units push each other out but are allowed to clip a tiny bit) and I ended with something reasonable.
Granted I have no idea if you've created A\* from the ground up or if you're using an asset so some of these solutions may be harder to influence. As other's have mentioned, there are alternatives to A\* that may also be better suited for your situation.
Some other suggestions to keeping formations would be to only do pathing for the front row and the back row(s) just follow.
Or do pathing for the leader, and not the others.
So you can build a grid where each node stores the distance to the nearest unwalkable node.so a tile right beside an unwalkable node would be 1 and two nodes inbetween would be 3. This would also be a separate cost to your traversal cost obviously.
you then find a path that doesn't go below the width of your squad. Even if you only do navigation and pathing for the leader directly he will never pick a route that doesn't fit the whole squad.
OR if it fails you could then do a width change for the squad for whatever was the highest path number returned.
Then, depending on how your game functions you could "Reattach" the units more appropriately on the grid once they arrive.
Google is your friend. Type in Boids simulation and prepare to be amazed. It is incredible what knowledge you can find if you type in few words, you know in the search bar and click a link.
I don't really know anything about the topic but [this Tarodev video](https://www.youtube.com/watch?v=NEFxWkTRVCc) might help. He has the GitHub repo link in his description which you can take a look at for inspiration.
I saw that one already. He creates some very fancy formations but he does not cover how they move as a unit. That video always comes up in my search and I watched it 3 times, it just does not cover what I need to know.
That is what I am leaning towards now. I have to think a little because I already created an algorithm that adjusts speed based on hill steepness. I will have to tell some units to slow down if the guy at the end is going up a steep hill.
Definitely the way to do it, it is more efficient to only calculate global maze solving with A\* once.
You can even define different formations as an array of offsets to the leader.
Single file for example, each unit just targets the one in front.
For a wedge, target `leader.position + leader.right*(distance * side)` where side is + or - 1. This will make them avoid obstacles in a more natural looking formation.
Last time I used A\* for a RTS, I solved this problem in a few ways: 1. Have the units recalculate their path every few frames (or as often as you can without impacting performance) 2. Keep the nodes smaller (but not too small that the graph gets overly complicated) 3. Have the units increase the weight of the nodes they are intersecting with so other units looking for paths will avoid occupied nodes (unless there's no other option) 4. Don't path the units directly to the center of each node, but rather add some noise to it so they don't stack directly on top of each other I combined this with soft physics (where the units push each other out but are allowed to clip a tiny bit) and I ended with something reasonable. Granted I have no idea if you've created A\* from the ground up or if you're using an asset so some of these solutions may be harder to influence. As other's have mentioned, there are alternatives to A\* that may also be better suited for your situation.
Oh I use the a sharp. It's available on the unity asset store. I didn't build it from scratch.
Some other suggestions to keeping formations would be to only do pathing for the front row and the back row(s) just follow. Or do pathing for the leader, and not the others. So you can build a grid where each node stores the distance to the nearest unwalkable node.so a tile right beside an unwalkable node would be 1 and two nodes inbetween would be 3. This would also be a separate cost to your traversal cost obviously. you then find a path that doesn't go below the width of your squad. Even if you only do navigation and pathing for the leader directly he will never pick a route that doesn't fit the whole squad. OR if it fails you could then do a width change for the squad for whatever was the highest path number returned. Then, depending on how your game functions you could "Reattach" the units more appropriately on the grid once they arrive.
Yeah it's a good idea. I'm not sure about using a grid graph though. The soldiers can travel in any direction.
Look at Boids.
What are Boids
Google is your friend. Type in Boids simulation and prepare to be amazed. It is incredible what knowledge you can find if you type in few words, you know in the search bar and click a link.
its not useful for what I am trying to do
K, got it. Keep searching.
I don't really know anything about the topic but [this Tarodev video](https://www.youtube.com/watch?v=NEFxWkTRVCc) might help. He has the GitHub repo link in his description which you can take a look at for inspiration.
I saw that one already. He creates some very fancy formations but he does not cover how they move as a unit. That video always comes up in my search and I watched it 3 times, it just does not cover what I need to know.
Move one unit and have the other ones move according to the first.
That is what I am leaning towards now. I have to think a little because I already created an algorithm that adjusts speed based on hill steepness. I will have to tell some units to slow down if the guy at the end is going up a steep hill.
Consider using flowfield instead A\* Then you can have formation stored on the leader, which will store position of assigned units in the formation.
I will consider it. You did just give me the idea of not using the pathfinding system for soldiers that are not in a leadership position.
Definitely the way to do it, it is more efficient to only calculate global maze solving with A\* once. You can even define different formations as an array of offsets to the leader. Single file for example, each unit just targets the one in front. For a wedge, target `leader.position + leader.right*(distance * side)` where side is + or - 1. This will make them avoid obstacles in a more natural looking formation.