How do you manage grids on a seamlessly loading world?

I have a working influence map system that works on a rectangular grid. My AI uses the info from the influence map. Ialso have a seamlessly loading world via additive scenes. The scenes have irregular sprawling shapes (dungeons) that would waste space on a square grid. The AI is spawned on the scenes as they are loaded and they need to have an influence map in their position. So basically, I need grid(s) that will cover the currently loaded scenes which can have an arbitrary and variable total bounding box.

Now, I am currently just limiting the AI to spawn within the player's current scene and keep an influence map grid that's huge enough to a cover any single scene. I just shift the grid based on the scene/zone the player is standing on. I'd like the AI to chase the player between zones but in this setup the enemy would need to move to new zone every time the player enters one( and the influence map gets shifted).This is easily exploitable to cheese the enemy. So I need a different solution.

Note that the size of the grid doesn't affect calculation time much since I only update the grid when AI moves and only in area it can affect. Currently a 200x200 grid is big enough to cover any single scene.

I can think of the following solutions:
1. Keep a pool of small grids with uniform size. Each zone/scene divided into a grid with cells the size of the uniform influence maps. Before runtime, I run physics checks in each cell to see if there is any collider in it. If not, the cell is empty. When the player enters a zone, I will use the pooled grids to fill up non empty cells. Now every enemy spawned will be guaranteed to have access to an influence map. Can be further improved by only picking cells near the player.

2. Different sized huge grids for each scene. Grids are stored and loaded up along the scenes. Will cause dynamic allocation of several 200x200 arrays(or of similar areas) every time the zone changes. Dunno if that's slow but I'm going to guess yes. I guess I can pool those arrays but it still seems excessive.

If any of you have dealt with a similar issue I'd appreciate your insight. Pretty much any grid based pathfinding would need to deal with a similar situation.

 

As you said, arrays can be wasteful especially when large parts of them are empty.

My goto for this kind of thing is an associative array, also known as a Map or Dictionary.

In C# this manifests as a

Dictionary<GridCoordinate, GridCell>

The best part about this is it works for any shaped map (square, hexagonal, etc..) as long as you can express the coordinates in a single Coordinate object. It also doesn't conceptually waste any space for empty cells that haven't been initialized yet, and provides efficient lookup/insertion/deletion operations.

Depending on the size of your map, this still might not be enough, and you will probably need to do some loading/unloading trickery to keep resource usage to a manageable level. 200x200 is 40,000, which is quite a lot. I would avoid using individual GameObjects to represent the grid cells if at all possible.

 

Sounds for me to use here the same technic as is used for a seamless world spawner. The "world arrays" (here several "level chunks" of "grid cells" for each level) surrounding the player in a bigger defined scope (so the AI is not cut off by the loading of a new scene). New level chunks spawns in the "moving direction" of the player (or next loaded scene here) and outdated level chunks will be removed and perhaps reused (pooled), so there is always are particular number of level-chunks of "grid cells " active at the same time. If the player has progressed in game older and not longer needed level -chunks will be removed or reused.

 

Yeah a dictionary would be better here. It can also be generated the same way before runtime.

The grid is just a 2d Array of floats. Keeping 40,000 game objects would obviously be a bad idea
and not at all necessary for what I want. I do need to generate a plane mesh with 201x201 vertices to visualize the map in the editor. That hasn't been much of a problem since I only need one and it isn't used in builds.

My seamless world happens to work on a grid but it doesn't really have any restriction on the size of each zone. That's not a restriction I want to impose right now since I might want to use a graph(each zone keeps a list of adjacent zone that needs to be loaded) later on.