Combining A* Pathfinding and Click-To-Move

Viewed 51

Fair Warning - My question is wordy and no there is no code. Perhaps this is not the best place to ask this question. In any case:

I'm trying to implement a movement system wherein the player avatar can be moved via click-to-move. If it's a straight shot, the avatar will move directly to the mouse-pressed position. If the mouse-pressed position is around a corner or through some serpentine path, the avatar will pathfind with the A* algorithm. This is for a 2d, tile-based game using C++ and SFML. Essentially, I'm trying to mimic the movement system used in Baldur's Gate

The reason I want an either/or solution is to reduce the number of pathfinding nodes that would be required to cover an entire tilemap, but mainly because using a grid_node approach forces the avatar to move grid-aligned, which I want to avoid.

My plan to accomplish this has been to split the tilemap into walkable regions and connect the regions with nodes used by A*. If the starting position (current avatar position) and the end position (mouse-pressed position) are within the same region, then a click-to-move function is called, if the starting position and end position are not within the same region, the A* function will be called.

At the call to move with A*, the start and end positions are converted to nodes and added to a vector of nodes. The start and end nodes are made neighbors with all the nodes in their regions and all nodes within the same region are made neighbors with the start/end node respectively. As the algorithm completes, the correct path is pushed into a vector of vertices, which is given to the avatar. The avatar then moves from vertex to vertex. This image shows the neighbor connections of all "static" nodes and top-left is the start position, bottom-right the end position.

I'm having some issues getting this to work and although I have some idea as to why it's not working and how to fix it, looking forward, I foresee issues with collision detection during path-finding and I'm sure I will need a completely separate collision detection algorithm during movement without A*. Basically, I'm anticipating a code-for-every-case situation using this approach, which is unacceptable.

My question: Is there a simpler, more elegant, more appropriate method for solving this problem?

Thanks for any help

1 Answers

This reads like you want to read up on the topic of "steering". A* is fine for high level route planning, but avoidance of local and possible moving obstacles is indeed nothing A* is good at.

I personally like the Understanding Steering Behaviors introduction.

Related