@vis2k - Here's an analogy ... if I'm understanding the situation correctly. If we accept that we need to be located near the origin, with a radius of 1500m, 2000m, or whatever, placement of instances on the map becomes similar to creating a texture atlas. If I'm making all of my instances at edit time, it's like making my texture atlas at edit time. The tiles are fixed / static in size and location. If I'm going with a resolution of 1500m for my map / atlas, I can fit 9 square 1000m (0.6 mi) instances within it. The instances are set at edit time, and all run concurrently (they may have no activity, but they are allocated on the map / atlas). If I want to expand my options and become more dynamic, it's like building an atlas at runtime using a rendertexture. I just need to be sure the server can dynamically load the navmesh and whatever for the dynamic instance. With this I need to do some management to make sure I'm keeping track of which instance spots are available, and be able to handle situations where I cannot create another instance. That's not bad, but still potentially limiting. What seems like a better approach, to continue with the analogy, is using a texture array, with one instance per cell. This way I can allocate out the whole 1500m map / texture for a single instance, but I can have multiple map / textures referenced by an array index. The server just needs to keep track of which array goes for which player / instance. In theory, I can keep adding new instances to the array, so long as my CCU is acceptable and other server resources can handle it.