• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • 🏆 Hive's 6th HD Modeling Contest: Mechanical is now open! Design and model a mechanical creature, mechanized animal, a futuristic robotic being, or anything else your imagination can tinker with! 📅 Submissions close on June 30, 2024. Don't miss this opportunity to let your creativity shine! Enter now and show us your mechanical masterpiece! 🔗 Click here to enter!

A* Pathfinding help

Status
Not open for further replies.
Level 7
Joined
Aug 15, 2007
Messages
52
Ok im making a pathfinding system. Just for learning. Its working great. Just that the algorithm doesnt return the best path. Im new to pathfinding.
And i wonder if anyone here have skills in this stuff.
The 2 screenshots show the red line as i want the path to be as close to as possible.

The small dots are the nodes checked and big glowing dots represent the path found
 

Attachments

  • pathfind1.jpg
    pathfind1.jpg
    346.7 KB · Views: 297
  • pathfind2.jpg
    pathfind2.jpg
    318.2 KB · Views: 365
Level 7
Joined
Jul 20, 2008
Messages
377
How are you implementing it? You're using the F = G + H equation properly, correct?

More importantly, are you maintaining the open, closed, and on-the-path lists correctly?
 
Level 7
Joined
Aug 15, 2007
Messages
52
its all correct, else the algorithm wouldnt find the path.
and ye the cost is F=H+G
I asume it was the Heuristic tat was wrong. I changed it to pythagoras now and works alow better. Now i need to find an optimization to workaround the operation limit and to allow a more straitght movement
 

Attachments

  • pathfind3.jpg
    pathfind3.jpg
    771.3 KB · Views: 561
  • pathfind4.jpg
    pathfind4.jpg
    544 KB · Views: 297
Level 7
Joined
Jul 20, 2008
Messages
377
Cost is local to each of the correlating circle, right? Just checking...

But anyway, the route your algorithm is currently taking is of minimal distance (in your first screenshot, it shows 15 bright dots, and I counted along a more straight path and it is still 15), although its path isn't quite straight. I believe to get a truly straight path, you should prefer a diagonal path if you can move diagonally. Of course, you could also make D_COST = 10. That would make it not always favor orthogonal movement over diagonal movement. The G cost is kind of like a priority factor, the lower it is, the more the algorithm prioritizes it. You could also check diagonally adjacent nodes BEFORE orthogonally adjacent nodes. That way, if it finds a diagonally adjacent node it likes, it will tend to not override that node with an orthogonal one.

However, if that doesn't work quite as expected (prefers to move diagonally too much?) you can just have it check diagonally first IF and only IF the unit's X AND Y values do not match the target point (meaning they're NOT either on the same X axis or Y axis). Otherwise, check orthogonally first.
 
Level 7
Joined
Aug 15, 2007
Messages
52
it is the heuristic tat determine. Ive changed the cost constants, doesnt effect much. It only effect if D cost is lower than O cost or more than 2 its size. This is because of the part where it check if pathing through current node is better than going straight, like mountains and stuffs. But in wc3 it doesnt have mountains so its same thing.
Ive made it work now, just need tip on operation limit
 
Level 7
Joined
Aug 15, 2007
Messages
52
ye wc3 stop on 10k loops, and tats easily reached if u have 100 nodes (O(n^2)) in openlist, currently algorithm will reach the operation limit very fast.
Im implementing binary heap to reduce the loop alot. SO it will prolly be able to handle more. And then i will make it periodically then there will be no op limit.
Just im researching on how to make smooth path with shortest euclidean space path.
But now im too tired to read about it :p
 
Level 7
Joined
Jul 20, 2008
Messages
377
Ah, considering I'm working on a TBSRPG, the # of nodes are pretty small in my project, so I've never run into that problem. I suppose you could try taking some shortcuts such as distancing the nodes a bit and maybe making them bigger. Other than that, there's really not much I can help with.
 
Level 7
Joined
Jul 20, 2008
Messages
377
Turn based strategy RPG; like Fire Emblem. If you haven't played that, then it's like Ghost's Battle Tactics map. But yeah, there are these circles of power that represent the different "spaces" on the board. So yeah, it's a lot cheaper (performance and memory) than open terrain.

But how's the binary heap solution coming along?
 
Level 7
Joined
Aug 15, 2007
Messages
52
Turn based strategy RPG; like Fire Emblem. If you haven't played that, then it's like Ghost's Battle Tactics map. But yeah, there are these circles of power that represent the different "spaces" on the board. So yeah, it's a lot cheaper (performance and memory) than open terrain.

But how's the binary heap solution coming along?

Just finished coding the binary heap (or i call it NodeHeap), need to implement it into the algorithm :p
 
Status
Not open for further replies.
Top