PathFinder status

[LogicParrot]

Then the cPathfinder constructor can actually receive a reference to the cPath object (that will be stored in the cMonster as well) so that it will not need another param, can pre-allocate the path etc.

Your proposal breaks the idea of a "dumb device". How will you handle static paths?

I think the current way it's done is the most flexible because it covers all the use cases, here's an example:

Case 1, a zombie, always chasing the player

Upon spawning, create a cPathfinder instance, and create a cPath instance.
Always call the cPathfinder::findPath and pass on cPath. cPath is reused and memory is saved.

Case 2, a custom mob - a patrolling zombie.

Upon spawning, create a cPathfinder instance, create a cPath instance for chasing the player, and a cPath array for the static patrol routes.
For each cPath in the array, call cPathfinder::findPath only once and pass on that cPath.
When chasing the player, forget the array and switch to a regular zombie behavior and use the cPath reserved for chasing.

---

Another approach would be merging the two classes. Wanna chase the player? No problem, just create a single "MergedThing" instance and call findPath. Want 3 static routes? create 3 of that instance and call findPath for each. The disadvantage here is that each of the different instances of MergedThings will make some allocations that would have been made only once if one had create a single Pathfinder and derived the paths from it. So the current interface is still better in this regard.