Preloading is a touchy subject. It allows for simulation and fast loading but is subjected to the user's memory availability. If you use Minecraft for example, the preloaded area is the active chunks surrounding the player. The catch of preloading is that if the chunk is not loaded into memory, its not simulated.
Preloading can me summarized into a balance of the following items
- The need to simulate
- The availability of memory
- The requirement of continuity (whether the player have to pause and load the next chunk)
Ill talk about these 3 points briefly.
This depends on the accuracy of the world you are creating. Whether the world need to "continue" when you are not watching it. Most tile based games have a set area that confines the player to avoid this issue. The only area it needs to simulate is the only area the player can play in. But if you need to have a large/open world there is two solutions I have seen before.
- Discard continuity and only simulate the area you are playing in
- Examples of this is Minecraft. Where crops dont grow unless theres a player in the area.
- Discard accuracy and simulate in a lower resolution
- I cant give an example of this but in a project I previously worked in, open world AI is simulated in a lower resolution. They have no colliders, no physics and path finds in a limited fashion. The only issue with this is that you need to resolve any issues that happens during the limited simulation when they are loaded into real simulation. ie. whether they morphed into a wall when they have no collision.
- Check out this question for a more detailed explanation for your second question
Good way to handle offscreen AI?
For your third question, since your design of the world is chunk based, your reference would probably be the entire chunk. Load your AI together with the chunk so that the AI can interact with the chunk. Apply the lower resolution simulation if necessary for AI outside the current chunk.
On the subject of rendering stuff outside the screen, A simple positional calculation would serve the purpose with the least computation requirement. Simply not render any object that is X distance away from the center of your screen (Assuming it is a top down orthogonal view). For 3D solutions id recommend frustum culling as a solution.
Generally speaking Unity does a great job of doing this automatically. You can keep sprites and objects active and they wont render unless they are within view of the camera.
Do note that you are dealing with an optimization issue. While this is good, as Donald Knuth would say, Premature optimization is the root of all evil
Unless your AI is highly complex, most games are able to simulate a significantly large area at 3-5 times speed with no issues. Consider other solutions like multithreading if your AI is too compute intensive. One interesting strategy I have seen in an old game is to slow down the game when its really busy.
Most games suffer from not properly using the available CPU cores than actually have issues with simulation.