DEV Community: Vav Labs

Tower Defense Path Validation in Godot

Vav Labs — Wed, 24 Jun 2026 15:15:50 +0000

In a tower defense, a player can drop one tower that walls off the path and softlocks the wave. The fix isn't to place it and hope pathfinding recovers — it's to validate first: treat the tower as a temporary blocker, ask if a route still exists, revert if it doesn't, and only then commit.

I built a playable Godot 4.7 demo for it: place towers, watch the path reroute, try to seal it and get rejected. The guide also measures the cheap vs expensive way to run that check, with a runnable project.

https://vav-labs.com/blog/tower-defense-path-validation-in-godot/

Godot's NavigationObstacle2D has two modes (and other NavigationServer2D gotchas)

Vav Labs — Tue, 23 Jun 2026 09:42:09 +0000

Godot's NavigationServer2D is powerful and quietly confusing. Most of the pain isn't the API — it's a handful of distinctions that look similar and behave nothing alike. The ones that eat afternoons:

NavigationObstacle2D has two modes, and people conflate them. avoidance_enabled makes your agents steer around an obstacle, but the path query still runs straight through it — so your tower-defense blocker doesn't block the route. affect_navigation_mesh is the other one: it carves the obstacle into the navmesh at bake time, and then the path reroutes.
The empty path. A query returns nothing even though the scene looks walkable — usually because the navmesh was never baked. It's the NavigationServer2D version of forgetting AStarGrid2D.update().
Map-sync timing. NavigationServer changes apply at the end of the physics frame. Query in _ready() or right after editing nav data and you get a stale or empty result — then blame the agent.
NavigationAgent2D isn't the map. The agent is a node-level helper that consumes navigation data; it doesn't make the map valid by itself.

So I wrote the full guide — regions, agents, direct path queries, both obstacle modes, links, and the map-sync trap — checked every claim against the docs and the C++ source, and built an interactive playground for the gotchas. (It's a browser illustration of how the system behaves, not the engine running, and there's no benchmark here — it's a guide, not a measurement.)

Full guide + playground: https://vav-labs.com/blog/navigationserver2d-godot-complete-guide/

If any of it's wrong or out of date for your version, tell me — the navigation API has moved across Godot 4.x, and I'd rather fix it than leave you debugging my mistake.

AStarGrid2D in Godot 4: the gotchas, and an interactive sandbox

Vav Labs — Sun, 21 Jun 2026 23:20:15 +0000

Godot's AStarGrid2D is a ten-minute read and a month of gotchas. The API page is small, you skim it, and then your path comes back empty, your units cut through wall corners, or your weighted swamp gets ignored. None of it is a bug. It's the gap between knowing the method names and knowing which handful of settings actually decide the behavior.

The five that get almost everyone:

You forget update(). Change the region or cell size, skip the rebuild, and you get an empty array with no error.
update() wipes your point data. It clears every solid cell and weight, so you have to set those after you call it.
Diagonal corner-cutting. DIAGONAL_MODE_ALWAYS lets units squeeze diagonally between two walls. You usually want ONLY_IF_NO_OBSTACLES.
jumping_enabled silently ignores weight scale. Turn on JPS and your weighted terrain stops mattering. It's in the docs. People still lose an afternoon to it.
Manhattan overestimates with diagonals. On an 8-direction grid it counts a diagonal as two steps, so your "shortest" path isn't. Reach for Octile.

So I wrote the reference I actually wanted (every property and method, the gotcha attached to each, version-honest across Godot 4.0 → 4.7, checked against the official docs and the C++ source), and built an interactive sandbox for the parts you have to see: drag the goal, paint solid and weighted cells, flip diagonal modes, toggle jumping, and watch the path recompute live. (It's a browser illustration of how AStarGrid2D behaves, not the engine itself running in a tab.)

Full reference and the sandbox: https://vav-labs.com/blog/astargrid2d-complete-reference/

If any of it's wrong or out of date for your version, tell me. The API moved across Godot 4.x, and I'd rather fix it than leave you debugging my mistake.

Moving 10,000 agents in Godot without the frame spike

Vav Labs — Tue, 16 Jun 2026 15:08:59 +0000

I kept reading that Godot pathfinding falls apart with a lot of agents, so I actually measured it. 500 agents each calling AStarGrid2D.get_id_path() every frame gave me a 670 ms median frame on an 8-year-old desktop — a slideshow. Swap those 500 per-agent queries for one shared field the whole crowd reads, and the same agents drop to ~2 ms, nothing over the 16.6 ms budget. The fix was the shape of the work, not a faster solver — and the same approach holds 10,000 agents at 77 FPS in a browser tab, pure GDScript.

Full write-up with the measured ladder out to 20,000 agents, a playable demo (drag the goal, flip naive vs scheduled, push the count yourself), and the benchmark JSON for every count: https://vav-labs.com/blog/moving-10000-agents-in-godot/