4

I have written an implementation of the A* search algorithm. The problem is that the heuristic I'm currently using only works accurately on square grids. As my map is isometric, the heuristic doesn't take into account actual the layout of the map and thus, the distance between cells.

Update: After extensive logging and analysis (read as spending lots of time trying to figure out a banality), I have come to the conclusion that my current heuristic works quite well, with one little exception: the end result is reversed for real straight and diagonal movement.

inline int Pathfinder::calculateDistanceEstimate(const CellCoord& coord) const
{
    int diagonal = std::min(abs(coord.x-goal->position.x), abs(coord.y-goal->position.y));
    int straight = (abs(coord.x-goal->position.x) + abs(coord.y-goal->position.y));
    return 14 * diagonal + 10 * (straight - 2 * diagonal);
}

This means that a straight move, which really costs sqrt(2) times more than a diagonal move on an isometric map, is calculated to be the that of a diagonal one. The question is: how can I modify my current heuristic so it will produce correct results for an isometric layout? Simply replacing diagonal with straight and vice versa will not work.

Map layout

Community
  • 1
  • 1
Electro
  • 2,994
  • 5
  • 26
  • 32
  • You've said you're looking to repair the heuristic; can you post the code relevant to the heuristic? Or alternatively enough of the code that we can determine a solution? – CoderTao Aug 12 '09 at 17:34
  • Is your heuristic... pixel-based? Manhattan distance is typical for a square grid map, and should be easy to translate to isometric, seeing as you probably store a map in a square matrix anyhow. Regardless, posting a hint as to how your current heuristic works, and how you represent the map internally, would be quite helpful. CoderTao, I think, has the right idea in his answer, but I too am confused as to why his suggestion would require a complete re-write. – agorenst Aug 12 '09 at 18:06
  • My heuristic is not pixel based, and my map is not stored in a square matrix, hence the rewrite. The map would be stored in a square matrix if it was, e.g. diamond shaped. The map is projected as a rectangle. – Electro Aug 12 '09 at 19:10
  • Yes; but each square in the map is still a set of two coordinates. We aren't suggesting a massive rewrite of everything; just a bit of data processing when calculating the heuristic. Ultimately we still need a better description to be able to better advise you on what course to take. (Example: I've been talking about how to fix the distance till completion portion of algorithm; on rereading, it sounds like you're having trouble with just the 'distance to get here' portion) – CoderTao Aug 12 '09 at 19:49
  • The 'distance to get here' portion *is* the heuristic. And what I need, is a heuristic which accounts for the irregularity of the map's layout. – Electro Aug 12 '09 at 20:24
  • Is the revised answer any better? Or alternatively; what are the short comings with it? (We do like to help... just getting on the same page can be difficult) – CoderTao Aug 12 '09 at 20:32
  • Okay, so, one more time, what are you expecting as output from the heuristic? that distance(3,2; 3,3) < distance(3,1; 3,3) < distance(3,2; 3,3) ? – CoderTao Aug 13 '09 at 14:17
  • pretend that last one was distance(3,2; 3,3) < distance(3,1; 3,3) < distance(2,3; 3,3) – CoderTao Aug 13 '09 at 14:18
  • That's almost right. First cost is 10, second and third 14. But reread the updated question, if you will. – Electro Aug 13 '09 at 14:31
  • Okay; then I think the new solution might have it; the distance formula as posted gives values of 10, 20, and 10 for the above cases; the formula in my answer has 10, 14, 14. Barring a piece of the update that I missed. – CoderTao Aug 13 '09 at 14:39

2 Answers2

4

One thing to try would be converting from isometric coordinates to a square grid coordinate set for all calculations.

Say that 0,0 stays the root of the map. 0,1 stays the same, 1,2 becomes 0,2; 1,3 becomes 0,3; 2,3 becomes 1,4; 3,3 becomes 2,5; 0,2 becomes -1,1; etc. This puts you back into a square grid such that the coordinates and heuristics should work again.

Y coordinate becomes Y+sourceX offset (3,3 is at x=2; so becomes 2,5); finding sourceX mathmatically is proving itself more difficult.

[Stream of consciousness; ignore] Isometric coordinates at Y=0 are accurate for source X. So, to calculate source X you need to 'move left/up Y times' which should net a change of Y/2; rounded down, in the X coordinate.... roughly suggesting that the square coordinates would be:

sourceX = X - Y/2
sourceY = Y + sourceX

Where sourceX and sourceY are the coordinates in a normal square grid; and Y/2 is integer arithmetic/rounded down.

So, in theory, this becomes:

double DistanceToEnd(Point at, Point end)
{
    Point squareStart = squarify(at);
    Point squareEnd = squarify(end);
    int dx=squareStart.X-squareEnd.X;
    int dy=squareStart.Y-squareEnd.Y;
    return Math.Sqrt(dx*dx+dy*dy);
}
Point squarify(Point p1)
{
     return new Point(p1.X-p1.Y/2, p1.Y+(p1.X-p1.Y/2));
}

Update based on new bits of question:

Assuming that you are trying to get distance(3,2; 3,3) < (distance(2,3; 3,3) = distance(3,1; 3,3)); the following should work: (translated from C#; typos not guaranteed to be non present)

inline int Pathfinder::calculateDistanceEstimate(const CellCoord& coord) const
{
    int cx=coord.x - coord.y/2;
    int cy=coord.y + cx;
    int gx=goal->position.x - goal->position.y/2;
    int gy=goal->position.y + gx;
    int diagonal = std::min(abs(cx-gx), abs(cy-gy));
    int straight = (abs(cx-gx) + abs(cy-gy));
    return 14 * diagonal + 10 * (straight - 2 * diagonal);
}

EDIT: Fixed horrible typo.... again.

CoderTao
  • 3,831
  • 1
  • 23
  • 18
  • I need to fix the heuristic, not the algorithm itself, and doing this would require a complete change of the system. – Electro Aug 12 '09 at 16:21
  • Ultimately this should only change the Heuristic; if you try the heuristic for distance remaining as distance(squareCoords(current), squareCoords(dest)); you shouldn't need to make any other changes in the system. – CoderTao Aug 12 '09 at 17:31
  • Two things: A) there's a typo B) it's not giving me any better paths than my current heuristic, for a good reason: it's not taking into account diagonal movement – Electro Aug 12 '09 at 20:46
  • I take no responsibility for awful spelling. That said; what do you mean 'its not taking into account diagonal movement'? An explicit example of what it is doing on your end would be useful. – CoderTao Aug 12 '09 at 21:11
  • It's not making any diagonal moves whatsoever, unless you are moving to a tile which is adjacent. – Electro Aug 13 '09 at 10:15
  • That... doesn't make alot of sense. There shouldn't be a case where the algorithm would outright stall.... at some point it should exhaust all possibilities and give up; but it shouldn't be stalling. – CoderTao Aug 13 '09 at 15:13
  • Well, that's what I meant. But it takes some time to do that. – Electro Aug 13 '09 at 15:14
  • Okay; yet another horrible typo was probably present. I suspect I should have posted the C# code; gy=position.y + cy should have been gy=position.y+gx – CoderTao Aug 13 '09 at 16:46
  • Thanks for the code! I tweaked `return 14 * diagonal...` to `return 11 * diagonal...` and had better results, for what it's worth. – Clay May 08 '12 at 01:49
-1

Amit here computes the "manhattan distances for hexagons". Its C++ code, and I can't vouch for it, but Amit is a name I've heard before for game development.

The manhattan distance for hexagons should be suitable for a proper heuristic.

Edit: reversed the syntax for hyperlinking, whoops.

agorenst
  • 2,425
  • 14
  • 18
  • Unfortunately, tiles on a hexagonal grid only move in 6 directions, and the cost of moving is equal for every direction, so I can't use this. – Electro Aug 12 '09 at 16:20
  • My god, I completely misread your question. Somehow isometric became hexagonal. Sorry about that. – agorenst Aug 12 '09 at 17:42