I’m not sure how feasible a 2nd reality bubble would be, but I can outline some issues and some things that make it easier:
The single biggest issue is that you cannot guarantee just one player base, since there can be multiple players in one game world. Even if they aren’t active at the same time, hordes could end up inside the unloaded player’s base due to the actions of the loaded player, your only real option is to load them all and keep them updated. As long as they’re close enough that is, it might be reasonable to have exclusion zones around them, but then you end up with weird and probably not helpful messages like, “can’t establish a base, too close to a base to the northwest”. Alternately we let the player opt into shitty performance by warning them about it but not enforcing it.
A very close second is limiting the size of this second bubble. The bubble as it exists now would only support a very meagre base, maybe a 50x50 square building or so (leaving about 40 squares of vision). For good support, you might want something with double or more of the radius of the player’s reality bubble. “the ranch” for example is 216x216 squares (reality bubble is 132x132 squares, doubling it would handle the ranch with decent areas outside it so hordes don’t spawn right on the walls). See below though, this might not be as big of a problem as it sounds.
Battles occurring when the player isn’t present would be really problematic, especially if the NPCs took action that made a lot of noise and attracted more hordes. Dozens of NPCs and potentially thousands of zombies would add up fast, though I have some ideas about time dilation* that might resolve heavy load peaks like that, ironically as long as the player is far enough away.
Dynamic lighting could be a major problem, I’m not aware of any shortcuts compared to how we do it already, though we could cache very heavily since the area wouldn’t be moving around all the time like the reality bubble does.
It’s not all bad news though, a number of things aren’t really issues that are problematic in the reality bubble:
Scent, we can just turn it off since the interactions are short ranged.
FoV: we don’t draw the map, so no need to calculate full FoV, just lines between individuals.
Active item updating: This really wouldn’t be an issue since we handled this pretty well for giant player crafting piles.
Pathing: Shouldn’t be an issue normally since we can code NPCs to hold position or follow fixed routes, we’d most likely suppress random stuff like neutral monster pathing, and likely have them avoid these areas. See above for battle royales though.
*Time dilation! How this would work is we’d process ticks in the base in between player turns, if base ticks start getting slow, such as during a battle, we’d start processing fractions of base ticks at a time, and let the base timeline get behind the player timeline. Once the high overhead event is over (zombies are dead or base is overrun), we’d hopefully be able to catch up by processing multiple base ticks for each player tick. We’d be able to catch up very quickly if the player spends time in menus or idle on the main screen. The worst case here is if the the player moves toward the base as quickly as possible, such as by fast traveling. What we would have to do if this happened would be to force the base timeline to catch up to the player timeline by processing multiple base ticks per player tick based on the distance between the two. In short we’d have to catch the base up by the time the player would arrive. To mitigate this, we could also let the base get ahead of the player to some extent to establish a buffer, giving the game more time to catch up. As you might guess, rearchitecturing the turn sequence to handle this might require a lot of code changes.