Flow Field Navigation System

This week I went down the rabbit hole implementing a flow field navigation system after someone suggested it would scale better than individual nav agents. After researching the concept, it made perfect sense to consolidate expensive pathfinding into a single centralized calculation instead of having thousands of nav agents independently calculating paths every frame. Also, stripping away the complexity of the navigation server and merging multiple nav regions is a welcome change.

Key Features Implemented

High-Frequency Update Zone

The system uses a two-tier update strategy: a smaller central zone (32×32 by default) updates frequently for responsive player tracking, while the outer regions update only when the player moves significantly. When the player stays within the high-frequency zone, only that region recalculates, keeping costs low. Once the player exits this zone, the entire grid regenerates and recenters on the new position. This dramatically reduces CPU overhead while maintaining smooth enemy behavior near the player.

16-Direction Movement

Extended beyond the typical 8-direction system to support 16 directions: 4 cardinal directions (N, S, E, W), 4 primary diagonals (NE, NW, SE, SW), and 8 extended diagonals using knight’s move patterns (e.g., 2 cells in one axis, 1 in another). Uses Euclidean distance-weighted costs during BFS propagation to ensure proper pathfinding with the extended directions. Provides much finer angular resolution so enemies can approach from more natural angles instead of being locked to 8 directions.

Asynchronous Processing

The cost field generation and flow vector calculations run asynchronously using await get_tree().process_frame. Work is spread across multiple frames to prevent hitches. The system processes cells in batches and yields to the engine when approaching the frame time budget.

Frame Time Budget Management

Configurable target frame time (target_frame_time_ms, default 3ms). After processing a batch of cells (frame_time_check_freq, default 25), the system checks elapsed time. If the time budget is exceeded, processing yields to the next frame. Ensures the flow field generation never blocks gameplay, even on large grids.

Obstacle Detection

Physics-based obstacle detection using shape queries with configurable collision mask and detection parameters. Cells containing obstacles are marked with maximum cost and excluded from pathfinding. Obstacles are respected during both BFS cost propagation and flow vector generation.

Grid Recentering

The flow field grid dynamically recenters on the player during full updates. Keeps the player near the center of the grid, maximizing the usable navigation area. Prevents entities from falling outside grid bounds as the player moves around the world.

Some area for improvement

There are still some tweaks I need to make to reduce jitters on the enemies as the grid shifts. maybe I could implement additional layers to my high frequency update zone. I think enemy jittering is most noticable when they are at the outer edges (which aren’t updated until the player’s position has changed significantly.

I’m also not sure what size I’ll settle on for the flow field but right now 64x64 seems decent.

I think for now I’ll call this flow field generator done and move on to some other features next week.