class Node
{
    private Vector3 _flowDir;
    private int _weight;
    private float _distance;

    // getters and setters
    // constructor(s)

    public void UpdateWeight()
}

Node

For the node, the basic data you need is the direction an agent should move when in that cell, it's weight (higher weight signals 'tougher' terrain) and distance (from the target node). The last two are what's used to calculate the flow direction. I also include the world position and a reference to the flow field it is contained in.

You also need the constructor and any getters and setters you may need, then i also have an update weight function. In my implementation, the node's weight is based on how many colliders are within its bounds (using an OverlapBox).

class FlowField
{
    public Vector3Int dimensions;
    public float spacing = 2f;
    public int batchSize = 25;
    
    private Node[] _map;
    private Vector3 _target, _centerOffset, _halfDims;
    private int _numNodes;
    private float _worldToMap;
}

Flow Field

For the flow field, the basic needs are its dimensions, the size of the nodes, the target location and the array that holds all of the nodes in the flow field. I have my implementation process nodes in batches to lessen the impact on framerate, and I also have offset and conversion variables for centering the flow field in world space.

From there, you just need the actual flow field functionality along with other helper functions to help facilitate the whole process.

As I said before, calculating the flow field, at least conceptually, is not too difficult. Basically, you start with your target node, then move outwards using an algorithm like Dijkstra's updating the distance from the target as you go. To do this, you maintain an open and a closed list, or, nodes that are next to be processed (open) and nodes that have already been processed (closed).

The target node is the 'seed' for the open list and the first node that you process. For the target node, you set the distance to 0. Then, you continue to populate the open list by adding the neighboring nodes to it and moving the node you just processed to the closed list. To process a node, you can calculate distance by either setting a neighbor's distance to 1 + the current node's distance, or use Manhattan distance: | tx - cx | + |ty - cy | where t is the target node and c is the current node.

// keep going until no more new neighbors to process
while (openList.Count > 0)
{
    // get node to process from front of list
    Node curr = openList[0];

    // move from open to closed
    openList.RemoveAt(0);
    closedList.Add(curr);

    // get the connections
    List<Node> neighbors = GetNeighborsOf(curr);

    // check all the connections
    foreach (Node neighbor in neighbors)
    {
        // first check if in either list yet
        if (InList(ref openList, neighbor) == -1 &&
            InList(ref closedList, neighbor) == -1)
        {
            // if it hasn't been touched then add to open
            openList.Add(neighbor);
            neighbor.Distance = curr.Distance + 1f;
        }
    }
}

// Find flow direction for every processed node
// (comes after the while loop)
foreach (Node node in closedList)
{
    // get the node's neighbors
    Node[] neighbors = GetNeighborsOf(node);

    // lowest total cost of the neighbors
    float lowestCost = neighbors[0].Distance;
    // index of the neighbor with that cost
    int lowIn = 0;
	
    // cycle thru the rest of the neighbors to 
    // check if a lower cost option is available
    for (int i = 1; i < neighbors.Count; i++)
    {
        // if the neighbor's cost is less than the lowest
        if (neighbors[i].Distance + neighbors[i].Weight < lowestDist)
        {
            // then log it as new lowest
            lowIn = i;
            lowestCost = neighbors[i].Distance + neighbors[i].Weight;
        }
    }

    // make current node's direction face the closest one
    node.FlowDir = (neighbors[lowIn].Position - node.Position).normalized;
}

Making it Interruptible

A smaller quality of life thing I implemented was making the flow field calculation interruptible. While you could likely calculate a smaller flow field fairly quickly (especially if you were able to optimize the process more, and were not also rendering it), large flow fields can cause a brief stutter as you try to process hundreds and hundreds of nodes. This necessitates either reducing overall runtime or spreading it out over multiple frames, to prevent the calculations to compromise the user experience.

A 45x30 grid processing 3 nodes/frame