[quote:l51e2o7m]It chooses the empty cell closest to the destination. It's not going to use A* to find which empty cell is closest to the player because then it would have to pathfind to every cell on the map and that would take forever. And even that would be no use because the cell right next to the player would be the nearest.
Agree with what you are saying and it might be a huge flaw in the behavior that in the end breaks it. Because if it just picks the nearest random cell to where its trying to go, there are no certainty that it will work and it will be completely random when it does and doesn't. However this is what my tests pretty much shows, but this also means that the behavior is so broken that it need to be fixed as its simply not working.
From testing it seems that the pathfinding will always go to the cell below the cell being blocked. Which explain why it doesn't work in screenshot 1
Rough distance check.
However this kind of falls apart.
As then this one should fail as well, but it doesn't. It actually moves to the top. And if I block all surrounding cells and just leave top open it works.
However if I do the same but with the side it doesn't work.
So I added so I can see the actual collision cells and then align the sprites to exactly overlap the collision cells. Which improve the path finding a lot.
And it will be able to find path to both top and side.
But further testing seems to cause the same problem.
As it can be seen the tile right of the green tile is clearly not blocked, but still it ain't able to find a path.
However moving the green tile 32 px up and then it works again.
And again you are left exactly as the initial problem.
[quote:l51e2o7m]..It's not going to use A* to find which empty cell is closest to the player because then it would have to pathfind to every cell on the map and that would take forever.
Not necessarily, it could work its way out from the initial target. And stop at the first cell it encounters that it can actually reach. It would require more path finding calculations. But if the alternative is that it doesn't work, then I would consider it a better solution.
Further more it have already calculated the values for the fastest/effective path to the initial destination.
This is a screenshot from another site about A*.
If we assume that the cell I have marked blue is blocked. it could move to the cell indicated by the arrow, and still make use of all the "path cost" information. And it could do that for each surrounding cell. And move backwards based on either condition being the primary one. Either find the nearest tile to the initial goal, no matter how far away it is from the path finding unit.
Which is what I use in my game:
As seen the enemies surround the target.
This could be extended, so it would also value the distance the enemy would have to travel, in comparison to how close the tile is to the original target.
How it works in my game, is that if an enemy fails to find a path to a target, ill calculate a distance to each tile from the initial target and the one with the lowest value will be the new goal for the enemy, as I use an functionality to average the distance all tiles in the same range from the initial target will have the same distance. So all tiles that are 2 tiles from the initial target might have a value of 60 and those at 3 tiles away have a value of 90, which is because there are no difference in my game whether you move directional or horizontal/vertical. But could change it by adding in some weight to how far this goal is from the enemy start position as well.