The grid is going to contain information about the terrain. Each cell will contain something like…
- terrain type (water, ground, mountain, etc.)
- possibly terrain height if you want to make calculating cost more accurate, or useful for flying units avoiding certain elevations.
- the unit occupying this cell
- flags indicating which vehicle types this cell blocks
You will probably want to code your A* algorithm in such a way that it is stateless, and allows you to pass in state, i.e. a struct that contains the current solver state for a single path. This will allow you to specify a budget per unit for pathfinding and solve for a group of units simultaneously per frame, while amortizing the cost over many frames. This will allow you to begin moving along the path while still solving the path, and will also help prevent hitches in the frame rate since you can set a total budget of 1-2 milliseconds and continue the work next frame once you reach the per frame budget.
For a unit larger than a single cell, you will mark its footprint in the grid for however many cells it takes up, so 2x2 or 4x2 whatever it is. Those cells are marked impassable by ground unit types and all cells refer back to the unit. When testing for the next location of a unit, you need to check all cells in its footprint (ignoring cells currently occupied). Only when you know a unit can move to a new location do you unmark the cells and remark the cells in the new spot.
The higher resolution your grid is, i.e. the more cells a unit occupies, the better I think the units will cluster together, since you will waste less space if a unit is only slightly in some of the cells. You can take the bounding polygon of a unit and intersect it with cells to determine which cells the unit occupies.