The coord is usually referred to as 'vector' for 3D, use that label and your code is compatible with many:)
1. Use the cost numbering scheme described by Patrick Lester: 10=horizontal/vertical, 14=diagonal. We use these numbers because the actual distance to move diagonally is the square root of 2, or roughly 1.414 times the cost of moving horizontally or vertically. We use 10 and 14 for simplicity's sake.
2. Use the standard Manhattan heuristic:
I'm having some difficulty interpreting the list-node setup. I can understand how the map.tile(x,y,z) is built. But, its difficult for me to interpret how the adjacent nodes are determined. It would be obvious that no matter how they are determined, more would be needed for the diagonal nodes.
3. IMHO I would ditch the link list structure altogether as the Pros recommend using a binary heap for faster sorting of the fcost. (and its really fast)
still analyzing the astar.bb code
1. Use the cost numbering scheme described by Patrick Lester: 10=horizontal/vertical, 14=diagonal. We use these numbers because the actual distance to move diagonally is the square root of 2, or roughly 1.414 times the cost of moving horizontally or vertically. We use 10 and 14 for simplicity's sake.
2. Use the standard Manhattan heuristic:
Function getEstimatedCost(this.tile, where.coord) Return 10*(Abs(this\x-where\x)+Abs(this\y-where\y)+Abs(this\z-where\z)) End FunctionOther heuristic formulas can be found here. The purpose is not to determine the true distance but, to estimate it.
I'm having some difficulty interpreting the list-node setup. I can understand how the map.tile(x,y,z) is built. But, its difficult for me to interpret how the adjacent nodes are determined. It would be obvious that no matter how they are determined, more would be needed for the diagonal nodes.
3. IMHO I would ditch the link list structure altogether as the Pros recommend using a binary heap for faster sorting of the fcost. (and its really fast)
still analyzing the astar.bb code