dynamic goal A*
So, I've read some articles on a* and understand the concept, but wouldn't it suck of a lot of memory just running the pathfinding every frame? What I'm saying is, what kind of pathfinding articles/snippets/tutorials/concepts are there that are for moving goals? I want my AI to follow the player, not move to a single point. How do I do this? Thanks.
well, in my case if the 'moving goal' (target player) is obstructed I use an intercept steering behaviour to try to intercept the player. If the target player is obstructed (or the intercept point is obstructed) then I use A* to plan a path to them/the intercept point.
But yes, it's run every frame. The intercept steering behaviour is not memory or cpu intensive at all.
But yes, it's run every frame. The intercept steering behaviour is not memory or cpu intensive at all.
just repathing every second or so instead of every frame is the common solution.
-me
-me
Just some suggestions, maybe you could discriminate between static and moving goals?
- update AI following a moving goal every frame. Or maybe only update if the player moves off of the current node?
- AI paths to a static goal could only be calculated once, but recalculate if they run into something along the way.
- update AI following a moving goal every frame. Or maybe only update if the player moves off of the current node?
- AI paths to a static goal could only be calculated once, but recalculate if they run into something along the way.
As was said above, once a frame is a bit excessive. As long as the target isn't instantaneously teleporting around, you should be able to use part of the existing path when you compute the path to the target's new position. The further away the target is, and the slower the target is moving, the less that has to be recomputed. Just chop off the end of the old path and reuse the beginning of it. Maybe run a more complete update even less frequently to ensure that reusing the old paths doesn't result in an overly jumbled path (although the less than optimal path from the reuse could produce a behavior that looks like tracking...).
The other approach is not to plan complete paths to the target every iteration of your planning cycle. Rather, when you're far away, plan a path to the nearest point in a region that you expect the target to be in at some future time (if it's stationary, then that would be the current target position... if it's moving, then the endpoints of simple linear extrapolation of possible trajectories would define a region). Start executing this plan and while executing it, continue to make plans to the target, reducing the target region at each step and using a point along the path you are now executing as the starting point for that next plan. You should pick a point far enough along your current path as the root of the next search such that you have sufficient time to compute the next plan before you get to that point. Thus, the next plan becomes a new subplan for the current plan. If you're clever about data storage, you can save information from previous iterations of the planner to speed up subsequent runs of it.
Cheers,
Timkin
Cheers,
Timkin
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement