This is exactly why I prefer to design grid based games in Hexagonal formats. Six directions instead of 8, and the distance to the tile in any direction is the same. In a Cardinal/Diagonal format, the GCost will represent the actual cost of the move from point a to point b (including the 40% tax for diagonals). You could add a function that gets the current GCost of a given location, and only display the locations with a GCost that is less than the Move points.

This implementation of A* is far from exhaustive or perfect, and it wasn’t intended to be so. There is a tradeoof between speed and accuracy in any navigation algorithm.

The first time I did my own pathfinding, I completely left out GCost/HCost/FCost. Neighbor nodes were simply added to a queue, and it wound up searching a LOT more nodes before arriving at a solution. Often, the results when combined with obstacles would involve paths with lots of backtracking. I wound up calling that my Keystone Cop algorithm.

When I did my version of this course during the development stage, I made the choice to go purely Cardinal (N/S/E/W). I intentionally left out diagonal moves. Adding in blocking (i.e. you can’t walk or shoot through a tile with other characters in it), and you get a completely different dynamic, requiring different strategies than if the Diagonal directions are added and you can pass through occupied tiles.