Imagine you’re lost in a city and trying to get to a specific building. You can’t see the streets ahead, but you can see the building’s roof in the distance. That general sense of “it’s roughly over there, about that far away” — that’s a heuristic. It’s not exact, but it helps you pick which direction to walk next instead of wandering randomly.
In pathfinding algorithms like A-star, a heuristic function is a quick estimate of how far you are from the goal. The algorithm uses it to decide which paths look the most promising, so it can focus on those instead of exploring every possible direction equally.
Why does it matter?
Without a heuristic, a pathfinding algorithm has to check every possible route equally (this is what Dijkstra’s algorithm does). It works, but it’s slow — imagine checking every single street in the city instead of generally heading toward the building you can see.
A good heuristic dramatically speeds things up by telling the algorithm: “don’t bother going north, the goal is to the south.”
The one rule: don’t overestimate
A heuristic is called admissible if it never overestimates the real distance. This is important — if the heuristic says “the goal is 10 km away” but it’s actually only 3 km, the algorithm might skip a perfectly good shortcut because it thought the goal was too far.
Straight-line distance (Euclidean Distance) is a classic example of an admissible heuristic. The straight line is always shorter than or equal to any actual path, so it never overestimates.
Common heuristics
- Euclidean Distance — straight-line distance. Always safe, works in any dimension.
- Manhattan distance — count the blocks if you can only move in straight lines (like a grid of city streets). Named after Manhattan’s grid layout.
- Zero — always guess zero. Technically admissible, but useless — the algorithm gets no guidance and degenerates into checking everything (Dijkstra’s algorithm).