Awesome, I'll await the post ;-).

I think you can double the speed on mostly empty areas by spreading from both the start and end and finding the path when the 2 areas collide somewhere, but in a tight maze it might be slower...

This is a good advice for you ,and I am really agree with .

[quote name='Waterlimon' timestamp='1330701966' post='4918617']
I think you can double the speed on mostly empty areas by spreading from both the start and end and finding the path when the 2 areas collide somewhere, but in a tight maze it might be slower...

This is a good advice for you ,and I am really agree with .
[/quote]
You read my comment about this, right?

[quote name='Waterlimon' timestamp='1330701966' post='4918617']
I think you can double the speed on mostly empty areas by spreading from both the start and end and finding the path when the 2 areas collide somewhere, but in a tight maze it might be slower...

This is a good advice for you ,and I am really agree with .
[/quote]

I have to agree with cornstalks, on a theoretical principle, it can speed things up, but i expect cornstalk's example of where it would fail's would be common. as well, if it does succeed and follow the same path to meet with the starting search grid, if searching from start to end produces the same path as start/end meeting in the middle, than you have most likly gained nothing.

the only scenario where this is useful imo, is if the end point is blocked from the starting point, in a small room, where the end search would produce that the two nodes are not reachable much quicker than start-end search.