When developers talk about movement in Game AI, the conversation usually starts, and often ends, with A* and NavMeshes. And for good reason: A* pathfinding solves about 95% of what most games need.
But movement isn’t always about getting from point A to point B as fast as possible. Sometimes you need to find instead of just travel, sometimes you’re moving hundreds of units at once, sometimes the goal isn’t the fastest route but the safest.
That’s where other algorithms come in. In this article, we’ll explore movement techniques that go beyond A*, showing why production teams should treat A* as the foundation, not the whole toolbox.
The Usual Suspects: A* and NavMesh
Why A* is popular
A* is efficient because it combines Dijkstra’s algorithm (exploring all possible paths) with breadth-first search (systematically spreading outward) plus a heuristic (usually straight-line distance). This allows it to find the fastest path between two points without wasting resources on irrelevant nodes.
Why NavMeshes dominate
In 3D environments, Navigation Meshes (NavMeshes) make A* practical by dividing walkable areas into polygons. Characters don’t need to think about every grid square; they just traverse polygons connected by portals. This reduces complexity and produces more natural movement.
Limitations
-
Great for single-target pathfinding, but inefficient if you need to check multiple goals.
-
Running per-unit A* quickly becomes expensive in RTS or crowd simulations.
-
Doesn’t handle “soft” goals well (e.g., safest path vs. fastest).
When A* Isn’t Enough
Finding, Not Just Reaching: Dijkstra
Imagine your AI is looking for the closest health pack out of 50 scattered across a map. Running A* once for each would be wasteful.
That’s where Dijkstra shines: it expands outward from the unit, exploring until it finds the first valid item. You don’t need to commit to a specific target up front, the algorithm discovers it for you.
-
Tradeoff: more memory + exploration, but less repeated computation.
-
Best use: resource gathering, NPCs searching for nearest interactable objects.
Many Units, One Goal: Flood Fields
What if you have 200 enemies all going to the same location? Running A* 200 times is a recipe for lag.
Flood fields flip the problem: instead of computing from each unit, you compute once from the goal outward. Each unit then just looks up its next move based on its position.
Think of it like filling a maze with water, units don’t calculate the path, they just follow the “flow.”
-
Tradeoff: constant-time lookups at runtime (fast!) but higher memory usage.
-
Best use: RTS minions, tower defense enemies, large swarms.
Moving as a Group: Boids
Sometimes movement isn’t about reaching a destination at all, it’s about moving together.
Boids simulate flocking behavior with simple rules: separation (don’t crowd), alignment (match direction), and cohesion (stick with the group).
The result feels natural: stampedes, schools of fish, or even battle formations.
-
Tradeoff: looks emergent, but harder to direct precisely.
-
Best use: crowds, formations, herding behaviors.
Safe > Fast: Node Graphs with Safety Weights
Fastest isn’t always best. In survival, stealth, or tactical games, AI should prefer the safest route.
By weighting nodes (e.g., danger zones, traps, enemy vision cones), the pathfinding system balances speed with risk. A longer but safer path might be the correct choice.
-
Tradeoff: more complex setup, but smarter behavior.
-
Best use: stealth AI, survival horror, escort missions.
Why This Matters for Production
Most developers stop at A* because it “just works.” But the other 10% of movement cases can make or break gameplay:
-
RTS games with hundreds of units.
-
Survival/stealth games needing risk-aware navigation.
-
Multiplayer projects where performance bottlenecks can ruin flow.
That’s why good production planning means knowing which algorithm to use and when. Choosing the wrong tool can waste weeks or months of dev time.
Closing
A* and NavMeshes are the backbone of game AI movement, but they’re not the whole story. Algorithms like Dijkstra, flood fields, Boids, and weighted node graphs expand your toolkit, helping you design AI that’s more efficient, believable, and suited to your game’s unique needs.
The key takeaway: don’t stop at “it works.” Smarter AI comes from using the right tool for the right job.
If you’re exploring AI beyond the basics, our Technical Expertise services can help you design and implement movement systems that fit your game, not just copy generic solutions.
FAQ: AI Movement in Games
What is A* in game AI?
A* is a pathfinding algorithm that combines Dijkstra’s exploration with breadth-first search and a heuristic (usually straight-line distance). It finds the shortest path between two points efficiently, which is why it’s the default for most games.
Why isn’t A* enough for every game?
While A* works for 90% of use cases, it struggles when:
-
You need to search for the nearest of many possible goals.
-
You’re moving hundreds of units at once.
-
The goal isn’t just the fastest path, but the safest or most strategic.
That’s where algorithms like Dijkstra, flood fields, or node-weighted graphs step in.
When should I use Dijkstra instead of A*?
Use Dijkstra when the goal isn’t fixed — for example, finding the nearest resource, power-up, or health pack. Unlike A*, which requires a specific target, Dijkstra explores outward until it finds the first valid option.
What are flood fields in pathfinding?
Flood fields precompute paths from the goal outward, creating a “flow map.” Units then check their position on the map and move accordingly, instead of running their own pathfinding. This is faster for large groups but uses more memory.
What are Boids and why use them?
Boids simulate flocking, herding, or crowd behavior using simple rules: separation, alignment, and cohesion. They’re great for RTS armies, wildlife, or large groups where emergent movement feels more natural than rigid pathfinding.
How do games handle ‘safe’ vs. ‘fast’ movement?
By adding weights to nodes in the pathfinding graph. A swamp, trap, or enemy vision cone might cost more than a normal tile. This lets AI choose safer routes even if they’re longer, crucial for stealth or survival games.
What’s the production risk of sticking with just A*?
Using A* everywhere can cause performance bottlenecks (e.g., RTS swarms), shallow AI behavior (e.g., stealth enemies always charging head-on), and wasted development time. Good production planning means choosing the right algorithm early.
Do I need to know all these algorithms to make a game?
Not necessarily. Many games get by with A* and NavMeshes alone. But if your game involves large unit counts, risk-based navigation, or complex AI behaviors, learning alternatives like Dijkstra, flood fields, and Boids gives you a real edge.
