'facing' and turns won't cost any 'points'. The movemen is limited by the terrain tiles (only this type of unit can go there etc) and by the presence of ennemy units. They can't superpose.
Is the map 'deformable'? (Can terrain cost be alter by player abilities or events?)
Didn't think about it. Let's say no
Then, assuming the possibilities of a said map are known, and that its size is limited, it may be interesting for performances' sake to build a matrix. That matrix would contain the amount of points required to move 'to' a tile, and its physical position within the matrix would identify whether it is adjacent to another tile or not.
If diagonal movement is permitted, a few 'tricks' would need to be employed, but it would still work essentially the same way.
That way, you could end up with an integer matrix only (0-3 for movement points for example, and 99 for impassable tiles).
This approach should minimize process time at the expanse of added disk space requirement. Depending on your end-platform, this may be desirable.
This, obviously, wouldn't work with deformable terrain however.
The problem with A*, as mentioned above, the is the sheer amount of processing involved. It is generally better as you'll still need to build it for AI pathfinding, but it is overkill for the purpose of establishing the base of 'where your unit can move'.
The problem with A*, as mentioned above, the is the sheer amount of processing involved. It is generally better as you'll still need to build it for AI pathfinding, but it is overkill for the purpose of establishing the base of 'where your unit can move'.
It depends on the size of the map and/or the distance that units can move. That "sheer amount of processing" should easily be doable at least once per frame, if not thousands of times per frame, especially for a typical turn-based game where the movement distance is going to be in the neighborhood of 10 or maybe 20 spaces maximum. If your A* cannot handle that you're doing it wrong.
Someone in this situation should do the simplest thing first, which is probably going to be Dijkstra's algorithm. A* is an optimization for when you have a single destination, while the simpler Dijkstra's algorithm fans out equally, which is what you want to find all the tiles you can get to within a certain movement cost. Then the shortest path to every single one of them is stored already as part of figuring out which tiles you can reach, so you do not even need A*.
The trouble with the cache is it restricts your game unless you're smart about storing all the information you need. Some guys might swim, some might be good at climbing through mountains or forests, some might fly: there are different costs depending on who's moving. It's trivial to account for this if you don't try to reuse any work. You could build something that takes all of that into account and caches whatever you want, but your game might be fine without it.
