Idea on how to truly secure a "base" area with hordes on

So, I’ve been looking at Dwarf Fortress again for the first time in several years (this game took me away from it), and one of my kids has gotten back into Minecraft againm and it got me thinking.

One of the things people talking about wanting is a “secure” area where zombies can’t magically teleport past the walls, and possibly more NPC/your own faction things (animal husbandry type tasks could also fall in here, since one of the difficulties is handling those things when not in the reality bubble). The grand idea in my head is a bit crazy to contemplate, but I have some fairly concrete suggestions in moves in the general direction without being crazy (I hope).

In Minecraft, there’s the concept of the “spawn chunk” - it’s always in memory, always “live”, always being processed. In Dwarf Fortress, you’ve got a fortress of, basically, NPCs doing the tasks that you set up (and also, the z-level handling there is amazing).

If the player could set a “base” area (just one) that’s always in memory and being processed (basically, a second, stationary reality bubble), then the zombie hordes that come by wouldn’t be in a horde, they’d be actually be “live”, so they could only go where they could go. NPCs set to guard (or traps or turrets or walls or whatever) could interact with them in the necessary ways. The player could go off into the world, having their own reality bubble as normal, but the home base would remain, handling things that need to be handled in a base.

This would obviously have some level of increased memory requirements… but some things already stay in memory all the time, so it might not be as bad as it first looks. Handling what happens when the two reality bubbles split/merge sounds like the hardest single part of this. NPCs guarding behaviour would definitely need some improvement.

Thoughts?

No, second bubble isn’t really an option. At least not without a very important issue to fix.

Limiting horde movement based on terrain is much more feasible. By calculating how much strength is required to move from one overmap tile edge to other edges, a rough limit could be set. This calculation can be done on map unload. For hordes with high interest, their effective strength could be bumped, to represent them piling up.

http://smf.cataclysmdda.com/index.php?topic=13999.msg293715#msg293715

A previous suggestion of mine is relevent: a completely impassable block that horde cannot phase through. 2D mountain is also mentioned in the discussion. When you live in mostly enclosed valley, horde usually cannot reach you.

[quote=“Coolthulhu, post:2, topic:13452”]No, second bubble isn’t really an option. At least not without a very important issue to fix.

Limiting horde movement based on terrain is much more feasible. By calculating how much strength is required to move from one overmap tile edge to other edges, a rough limit could be set. This calculation can be done on map unload. For hordes with high interest, their effective strength could be bumped, to represent them piling up.[/quote]

The biggest problem with that is that it doesn’t take multi-tile issues into account.

Moving north/south BESIDE a strong wall works fine, but moving east-west would be very difficult. For a sort of “worst-case” scenario, image a 3x3 (map tiles) walled in area, but in one of the corner squares, only one square of the wall is in that tile (one corner). Is that whole square now horde impassible? Or is it a huge weak point in the wall because it IS passable and hordes can move diagonally (I assume)? Or is it only a large weak spot because, having only one square of wall in it, the strength is calculated as very low?

And all those problems get worse with oddly-shaped “secure” areas, or with varying levels of wall strength for a “secure” area.

And with some kind of turret/NPC system, even an area that is not technically secure could be MORE secure than just a wall, as the zombies could be funneled into the turret kill zone, the smashed by the NPC guards.

The second reality bubble solves a LOT of problems. I’m sure the initial setup for it would BE a significant problem on its own (my day job is computer programmer, so I get it), but I really don’t see any other way to solve many of these problems in any kind of useful fashion. Not being familiar with the code, I can’t comment on how hard that initial change-over would be…

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.

I see the following shortcuts:

[ul][li]Encapsulate light fields. Do not recalculate the entire light map if nothing has changed since last turn. If changes since last turn are small (a single dude with a flashlight makes a step), it might be possible to hackily recalculate only that area (but beware of floating point errors due to repeated subtractions+additions). Most of the time nothing at all changes, the most common changes are weather and daylight.[/li]
[li]It isn’t actually lighting itself that is the costliest thing in inter-creature conflict, but n^2 sight checks. Could be alleviated by creature IDs or hacks imitating those, but also by more complex techniques like kd-trees.[/li]
[li]Sight checks themselves could be precalculated for uniformly transparent submaps: when encountering a submap where every single tile has same transparency (has to be precalculated during transparency caching), the cost of crossing is just distance*transparency rather than sum(transparency). Since most skirmishes occur in mostly open fields, this could easily cut down 80% of processing power wasted on sight checks[/li]
[li]Our current dynamic lighting uses the exp(x) function from core library. It is used a lot. Even with --fast-math, it easily makes it near the top of profiler output. Replacing it with an approximation that doesn’t break for values near sqrt(2)2radius_of_bubble could easily speed things up.[/li][/ul]

Thanks for the feedback and thoughts.

Is multiple active characters in the same world at all common? It seems like a weird thing to do, to me, but maybe I’m the outlier. It does have some other significant problems - this one would just be a performance problem instead of logical problems like the rest (BOOM! Instant building! that’s my favorite - instantly grown crops out of season is another).

You could link this second reality bubble to the character, not the world, so only that character’s base is loaded. That removes the performance problems and puts the problems back into the logical problems area, like the other existing problems. Also, it would prevent serial characters in the same world (much more common, I would assume) from building up a performance problem over time.

On base reality bubble size, I would think it would be useful to possibly make that adjustable. How big is your base? How much base bubble can your machine afford you? Somebody on a monster machine with a low spawn setting could probably build a large base and do all kinds of ridiculous things, while those of us on more modest machines and high spawn settings would probably want to keep it very small (at least, above ground), with a full “default” reality bubble being quite sufficient.

Other than agreeing with your comment on heavy caching (and possibly in several area beyond just lighting), I don’t think I can speak much to the other issues you raised. Thanks for taking the time to actually think through it. I hope something like this can make it into the development list at some point - that would be really nifty.