TomC has an
AStar example up that I've been looking at with developing my library. The object orientated approach seems a little more straight forward and less buggy than my method but I didn't quite like the Pandora's box approach with the Nodes (within nodes, within nodes, etc.). So I set about integrating my code and his (so it would operate from 4 directions upto a 26 directional cube - by means of a quick algorithm, no 26 conditions this time). I also couldn't use his "walkable" method - otherwise I wouldn't be able to do things like
snake.
But I really don't get what is going on with Tom's use of G. I want to use it as a terrain modifier. It's important to give users that option. This is the section giving me trouble.
Code:
// otherwise, loop through neighbours
Iterator iter = current.neighbours.iterator();
while(iter.hasNext()) {
Node adjacent = (Node)iter.next();
if (adjacent.walkable && !closed.contains(adjacent)) {
if (!open.contains(adjacent)) {
open.add(adjacent);
adjacent.parent = current;
adjacent.setF(finish);
}
else {
// if this is a better way to get there than last time we looked at it
if (adjacent.g > current.g + current.location.dist(adjacent.location)) {
adjacent.parent = current;
adjacent.setF(finish);
}
}
}
}
Without the else block this code performs BFS (Best First Search). I like having that option - a stupid search could be interesting. But I need to figure out the else block for my code.
Code:
for(int j = 0; j < current.child.length; j++){
//instead of stripping walkables, just check terrain is set above 0
if(n[current.child[j]].g >= 0 && !closed.contains(n[current.child[j]])){
if(!open.contains(n[current.child[j]])){
open.add(n[current.child[j]]);
n[current.child[j]].parent = current.id;
n[current.child[j]].setF(finish, fast);
}
//removing this else makes the search imitate bfs
else{
//ergo must be on open? - hence the bfs
if(n[current.child[j]].p.dist( > current. //arrghh?!?!?
n[current.child[j]].parent = current.id;
n[current.child[j]].setF(finish, fast);
}
}
}
The trouble in translation is Tom's Node class:
Code:
public void setG() {
g = parent.g + location.dist(parent.location);
}
If someone can assure me that Tom's Pandora Nodes won't eat up memory then I'll do a direct transcript and fit in the extra stuff like being able to search in 3 dimensions, wrapped environments, corners or no, BFS, etc. I could always add the terrain modifier as a separate value inside the Nodes.
Preferably I'd like to understand what is going on in Tom's else block and with his setting of G. I'd rather not be a copy/paste monkey.