It's such a quick prompt but can quickly signal how useful the model is in that language or framework, how much you have to constraint output with specs and tests.
Improving Heuristics for A* Pathfinding
21–30 of 42 posts
Re: Improving Heuristics for A* Pathfinding
#22If you don't already know exactly what the heuristic function is and that L is something called a landmark marker, and anyway what is a landmark marker anyway, you need to read quite a long way through the blog post to make sense of it.
And when you do finally get to that point, you realise it is all very simple, so why not just say that at the start?
Re: Improving Heuristics for A* Pathfinding
#23Re: Improving Heuristics for A* Pathfinding
#24It seems to me that you would need a step to select useful landmarks but the code doesn't seem to do this and I don't see it discussed.
Re: Improving Heuristics for A* Pathfinding
#25I don't understand how the multiple landmarks works. If you just max all of the landmark distances wouldn't some landmark near the starting point eventually dominate as you move away from it? Once you get halfway through the path the useful landmarks would be returning lower and lower values while ones behind you return larger and larger values. Or just in general one far-away landmark would complete nullify any inpu…
Re: Improving Heuristics for A* Pathfinding
#26This Red Blob Games blog post would be accessible to a wider group of readers if it spent just a few sentences up front on motivation and terminology. If you don't already know exactly what the heuristic function is and that L is something called a landmark marker, and anyway what is a landmark marker anyway, you need to read quite a long way through the blog post to make sense of it. And when you do finally get to t…
Re: Improving Heuristics for A* Pathfinding
#27Re: Improving Heuristics for A* Pathfinding
#28It uses df as an example, but it (unlike the others) has the problem that the set of valid paths between any two points can be constantly changing.
The landmark data can be calculated in a background thread. For DF I imagine you'd have a background thread running all the time, updating one landmark every so often. But what happens if you look for a path before the landmark data is updated? I haven't tested this yet but I believe this is how it'd work: 1. If the cost of a tile decreases, the precalculated heuristic will be too high, so A* might find a non-shortes…
Besides that blocker, your idea sounds like a nice win.
Re: Improving Heuristics for A* Pathfinding
#29Usually I would not point out a typo, but this one makes it difficult to grasp the magnitude of potential improvements: > the number of nodes A* has to explore decreases from 12693 to 12693
Good catch. I was thinking people would read that after they have moved the green L but I should handle both before and after moving L.
Re: Improving Heuristics for A* Pathfinding
#30This Red Blob Games blog post would be accessible to a wider group of readers if it spent just a few sentences up front on motivation and terminology. If you don't already know exactly what the heuristic function is and that L is something called a landmark marker, and anyway what is a landmark marker anyway, you need to read quite a long way through the blog post to make sense of it. And when you do finally get to t…
This blog post is like a story. It doesn’t start with the ending.
I read your comment first, expecting to go to the article and see a bunch of undefined math terms, but that isn’t what happened at all.
Of course you need to know what a heuristic function is, so maybe you’re right in that sense. You absolutely do not need to know anything about landmarks to enjoy the post. I didn’t, and it was no trouble at all to follow.
Perhaps you found the “discovery” method of presentation not to your liking. Discovery means there’s a demo where you move the L around before its purpose is defined. Building an intuitive understanding before producing a rigorous definition is (now) considered a good teaching method.