A* speed

Started by
22 comments, last by slicer4ever 12 years, 1 month ago
Awesome, I'll await the post ;-).
Advertisement

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?
[size=2][ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

[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.
Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

This topic is closed to new replies.

Advertisement