A* is one of those algorithms people hear about early and then keep using for years.
That is usually because it solves a real problem: given a start and a target, find a good path without exploring the whole map. It is not the only way to do pathfinding, but it is a strong default for game AI because it balances speed and path quality well.
If you are building games in Unity or another engine, A* is worth understanding even if you later use a library. It helps you debug bad paths, tune movement systems, and choose the right grid or navmesh setup.
What A* is trying to do
A pathfinder has two jobs:
- Avoid missing the best route.
- Avoid wasting time checking obviously bad routes.
A* does both by scoring each candidate node with two values:
- g = cost from the start to this node
- h = estimated cost from this node to the goal
Then it combines them:
- f = g + h
The node with the lowest f is the most attractive next step.
That is the core idea. A* is not “smart” because it knows the answer ahead of time. It is smart because it keeps a running cost from the start and a guess toward the goal, then prefers nodes that look promising on both sides.
Why the heuristic matters
The h value is called the heuristic.
For a grid, common heuristics are:
- Manhattan distance for four-direction movement
- Diagonal / octile distance for eight-direction movement
- Euclidean distance for free movement
The heuristic should be cheap to compute and should not overestimate the real remaining cost if you want guaranteed optimal paths. That property is called admissible.
If the heuristic is too low, A* still works, but it may search more nodes than necessary. If it is too high, the algorithm may become faster but can start returning suboptimal paths.
In games, “perfectly optimal” is not always the goal. Sometimes “good enough and fast” is the better tradeoff. Just be deliberate about it.
How the search actually runs
A* usually uses two sets:
- Open set: nodes discovered but not fully processed
- Closed set: nodes already processed
The flow is simple:
- Put the start node in the open set.
- Pick the open node with the lowest
f. - If that node is the goal, stop and rebuild the path.
- Otherwise, move it to the closed set.
- Check each neighbor.
- If a better route to a neighbor is found, update its
g,h, and parent node. - Repeat.
The parent pointer is what lets you reconstruct the final path after the goal is found. You walk backward from the goal node to the start, then reverse the list.
A small grid example
Imagine a top-down game with a grid map. Each tile is a node.
If a wall blocks the direct route, A* will still try nearby tiles that seem promising. It does not blindly spiral outward the way an uninformed search might. It keeps pushing toward the target while still respecting the true movement cost it has already paid.
That is why A* feels efficient in practice. It spends its effort where it matters.
Common mistakes
A few mistakes show up often in game projects:
1. Using the wrong heuristic
If your movement allows diagonals, Manhattan distance can be a poor fit. Match the heuristic to the movement model.
2. Ignoring movement costs
Not all terrain should cost the same. Mud, stairs, water, and slopes may need higher traversal costs. A* can handle that, but only if your node costs reflect the world.
3. Rebuilding paths too often
If an NPC recalculates every frame for no reason, pathfinding becomes a hidden performance problem. Repath when the target changes, the path becomes invalid, or the agent gets stuck.
4. Treating nav data as static when it is not
Doors open. Bridges collapse. Other agents block corridors. If your world changes, your pathing data needs to change too.
5. Forgetting path smoothing
A* often returns a path that is correct but ugly. In a real game, you may want to simplify waypoints, smooth corners, or blend movement so characters do not look like they are walking a chessboard.
When A* is the right tool
Use A* when:
- You have a known map or navigation graph
- You want reasonably optimal paths
- The world is large enough that brute force is too expensive
- You need predictable behavior
It is especially useful for tile maps, tactical games, top-down games, and any system where nodes and costs are easy to define.
If your world is mostly open and continuous, a navmesh or steering system may fit better. If your world is tiny and dynamic, a simpler approach may be enough.
Practical takeaway
A* works because it keeps two truths in mind at once:
- how much you have already paid
- how likely a route is to lead to the goal
That is a simple idea, but it scales well.
If you are building game AI, learn A* once, then reuse that knowledge everywhere. Even when you move to navmeshes, hierarchical pathfinding, or custom routing, the same cost-thinking still applies.
Diagram note
The grid diagram above is the main visual for this post. If you add a second diagram later, a tiny node-cost breakdown can show g, h, and f for one tile.