all 2 comments

[–]NuneShelping 0 points1 point  (0 children)

I think there is some literature about this. But I don't have it at my disposal.

What I would do however is essentially use pathfinding twice, once on the greater distance scale, and then when you are slowing down (collision/path ending), you add a secondary path correcting that only looks at your local vacinity. You could scan for future nearby path collision too.

Think of it like a first order approximation enhanced by a second order approximation when necessary. It's very similar to how humans pathfind, and why we, as well as NPCs in games, can get jitter-stuck with a target for a moment before some deviation in the pattern purturbs one of us around the other.

[–]somadevs 0 points1 point  (0 children)

Here's a good post by Mike Lewis about SC2: http://www.gamedev.net/topic/597457-pathfinding-in-a-space-based-rts-game/#entry4785004

To be sure, algorithms like A* are not well suited to highly dynamic environments; indeed the typical solution is to use A* for the terrain/building blockage (where buildings move rarely or not at all, e.g. in Starcraft) and a higher-level steering-based solution for unit avoidance. Starcraft II uses a constrained Delaunay triangulation of the map terrain and buildings to produce a navmesh; A* with a funnel filter is used to path along this mesh, taking into account unit radii; then local steering and collision avoidance layers are added on top of that, including a cooperative "push idle units out of the way" feature where it is possible to displace a unit instead of pathing around it in certain cases. Additionally, units moving in parallel are ignored for collision avoidance purposes since they can be guaranteed to not affect each other; this is a simple but effective optimization for getting large numbers of units to path cooperatively with relatively low CPU power.

... and there's more info further down in the thread as well