More flexible movement options about astar HOT 4 CLOSED

Hey exectails. I've given this some thought, and I think it will be extremely hard to implement without sacrificing a lot of performance. It would add a call to a delegate for every tile inspect. Which is very different from the list iteration we have now.

In the case where not all tiles are equal you could start looking at path finding algorithms for Directed Acyclic Graphs. (Which is also possible with A*). It might be nice to add a DAG path finding part to this library and a way to convert from DAGs to grids (with some meta info) and back.

from astar.

I've opened #18 to explorer this further. No ETA though :)

from astar.

I think it will be extremely hard to implement without sacrificing a lot of performance. It would add a call to a delegate for every tile inspect.

That would certainly not be desirable, though I wonder how much performance you would lose, have you done any benchmarks by any chance? My idea was that you wouldn't actually lose a lot/any performance because you replace the call to the current GetMovementOptions with the call to the delegate. Do you think the use of a static method gives a measurable advantage over a delegate?

from astar.

Sorry for the late reply. I've been pondering about this. But yes a call to a delegate is definitely slower because the compiler cannot think about what will happen until it runs the code. So optimizations like inlining are out of the question. Its also two jumps instead of one (from method to method vs, from method to delegate logic, to method in delegate).

from astar.