More flexible movement options

[exectails]

I've been using this library for a small prototype I've been working on and it's working very well, kudos.

I've been thinking about the movement patterns though, and while it's nice to be able to specify that something can't move down for example, I found that what I need is to be able to tell the path finder not how it can move generally, but on a tile to tile basis. For example, I might have a tile that you can only walk over from north to south.

It seems like that's not currently possible. A way to do it might be to let Grid/PathFinder take a function that can be called to get the available movement options instead of an array of offsets. I feel like that would make the system a whole lot more flexible, as you get full control over the options.

grid.GetPath(tile1, tile2, GetMovementOptions);

private IEnumerable<Offset> GetMovementOptions(Position position, int dimX, int dimY)
{
	return MovementPatterns.LateralOnly.Where(
		m =>
		{
			var target = position + m;
			if (!(target.X >= 0 && target.X < dimX && target.Y >= 0 && target.Y < dimY))
				return false;

			if ((this.GetTile(position).NorthToSouth() || this.GetTile(target).NorthToSouth()) && m != new Offset(0, 1))
				return false;

			return true;
		}
	);
}

This would be a nice feature to be have in my opinion.

[roy-t]

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.

[roy-t]

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

[exectails]

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?

[roy-t]

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).