What about a way to “reinforce” or “fortify” map tiles. Something along the lines of setting up a fence or some traps across a road, through a building, etc. which would prevent zombies hordes moving through that map tile so we can fortify decent sized areas without worrying about hordes waltzing in.
I think there have been concerns about how to detect that entire area is fortified, when parts of it aren’t really in the reality bubble. Though if a map tile was marked as “fortified” and that just prevented hordes from moving into it, I think you’d get close to expected behavior: if you have a 3x3 fortified mansion with 3 hordes on the north side while you’re in the south side, when you move north the hordes will resolve into the reality bubble at the edge of your vision, just outside your fortifications on the north side, and then can go kill themselves/smash your fortifications as appropriate.
But it’s still hard to detect that something is fortified, especially if you want to do things like fortify a 3x3 ranch where each tile only has partial fortifications and it’s only when the entire ranch is considered that you have a continuous barrier.
Just spitballing, but maybe create flags for BARRIER_EAST (a continuous barrier across all a map tile from north to south within 3 tiles of the east edge), BARRIER_NORTH (same, but east to west wtihin 3 tiles of the north edge), BARRIER_SOUTH, and BARRIER WEST. A single tile can be fortified if it has all four flags or if a continuous path of tiles exists with the appropriate flag.
So you’d build a barrier (stone wall, double line of barbed wire or deep pits, whatever) from one side of a tile to the other and then construct the “establish barricade” construction that would set the flag. And when you had a continuous series of barricades, you could construct the “establish fortification” construction that would verify your continuous series of barriers and set the FORTIFIED on all tiles.
I might mock up some code for this.
3 Likes
An issue with that flag method is the corners:
it would be natural to build a wall that comes from, say, the east, makes a 90 degree turn, and exits to the south. But the flag system as proposed wouldn’t detect this, because there is no wall covering the entire north edge of the overmap tile, and there’s no wall covering the entire west edge either.
It also doesn’t cover creating a square fortification within a single overmap tile. The pits, walls, barbed wire, fences and turrets may form a square, but they don’t go all the way to the edges of the overmap tile, so they wouldn’t count as having the four flags.
The ‘from 3 tiles of the east edge’ part is also an issue, since it is unintuitive for the player to know the wall has to be there and not in the middle of the map tile, or on the first third of the next map tile.
I’m fairly certain this kind of thing is going to need to be something like a “fortify this area” command, which initiates construction of fences, pits, etc at predefined locations, and once those are done it marks the overmap tile as fortified.
That runs into the issue that it’s not terribly compatible with things being in the tile already. What if there is a river of magma breaking the potential barrier? Or a chasm?
Or what if you don’t have quite enough to fully enclose with a stone wall or a pallisade, but you do have enough to do half and half?
Fortifying one tile is, at least, not terribly difficult. Zombies can go around it, so it doesn’t affect their overmap movement as part of hordes, and when it comes the time to unfold that space, it’s just a matter of ‘detecting’ if there are fully-enclosed spaces within the map tile, and not spawning zombies from hordes inside those spaces.
Not being able to fortify across obstacles like that is IMO acceptable. Just work around it.
For this to be meaningful, we’d expect to enclose a many-overmap-tile area. That leaves plenty of room for some sections to be made of different kinds of walls.
I look forward to your implementation, I don’t see a simple solution to this problem.
As I said, I only consider it a viable solution for a one overmap tile fort, not multi-tile forts.
For a one-tile fort you can just throw a bucket of paint on the outside and see if there’s areas that remain unpainted, but for multi-tile that’s a no-go, for the obvious reason that it’d just keep greedily eating the whole overland map trying to find borders.
The pre-set solution you proposed is certainly the easiest one. It’s not terribly organic, but it is by far the most implementable.
Any more organic solution would need to handle that the fortification line can be from any point in a border to any other point in another border, so it’d need to consider if it matches the lines on it’s neighbors; not to mention, that there could be multiple lines, or lines that more resemble kudzus.
How do you propose to handle breaches? The first thought that came to mind is a flag system, flagging the overmap tile as, say “Fortified [corner/vertical/horizontal]” or “Fortified [corner/vertical/horizontal] (breached)”, and relying on the same “build a fort” menu that was used to create it for the repair, because connecting manually repairing the fortification with correctly reflagging it is a bit problematic.
Okay, so in addition to the previous barrier flags, there could be BARRIER_CORNER_NE, BARRIER_CORNER_NW, BARRIER_CORNER_SE, and BARRIER_SW, which handle walls that don’t stretch from side to side but do turn corners.
Construction menu entries already give their requirements, so if the “establish barricade” construction entries say “continuous barrier within 3 tiles of the edge” then you sort of know where you need to build. Maybe add a “mark valid barrier locations” construction that would highlight the legal squares.
My suggestions for a continuous barrier would be:
- solid wall
- double line of deep pits
- double line of barbed wire
any of which could be interrupted by metal doors, armored windows, or any piece of impassable terrain like open space or lava.
Since you create barricades on a per tile basis and all of a tile is always within the reality bubble, the code can just trace the paths and set the appropriate flags. Or possibly appropriate fields, if you think it’s more useful to list the connector locations for each barrier, which it probably is.
My big point is that you declare barriers on a per tile basis while you are standing on a tile, so the tile is in the reality bubble, and that information is attached to the tile in the map file. When you declare a fortification, you path through the barriers in on your tile and tries to find a continuous set of barriers, and you can do that because the barrier information isn’t just connected to the squares on the local tile(s) but is cached in the map data.
I think it’s flexible enough to work, but haven’t really poked too hard at the implementation.
1 Like
Issue: mismatched borders
Take the following situation at the north edge of two overland tiles:
Tile 1 Tile 2
====== ......
...... ......
...... ======
both have a full east-to-west northern border within 3 tiles of the edge, qualifying for the flag, but these don’t align with one another.
Possible solution: triplicate flags, one for each of the 3 available border ‘lines’.
Possible solution: you can make a ‘fortification wall’ that goes on tile X from the border, say, X being 3~5. This is the only thing that counts for fortifying. The player can, of course, add more ditches, traps and whatever beyond the fortification line, but those only matter when the map tile is being played and there’s actual zombies in play rather than just overmap hordes.
That would work for single tile fortifications, but what concerns me is that it suddenly stops working when it exceeds its supported size, potentially forcing the player to re-do some of their construction. It also forces the player to interact with the underlying map tiles in a way we want to avoid. Multi-tile fortifications are definitely something people are going to want immediately (and they’re not going to understand why it’s so hard to “just make it bigger”).
Regardless of the details, once a fortification is created (manually or via auto-detection), it should have some metadata stored on the overmap to make interacting with it cheaper, e.g. “find gaps in defences”, “go repair gaps in defenses”, “locate nearest breach” etc. I.e. a breached fortification persists even though it’s no longer fully functional.
Re: auto-detection of enclosures by labeling overmap tiles with which portions of tiles are fortified, it’s certainly possible to do so by hoisting supporting data to overmap scale*, but it still ends up being a potentially intractable flood-fill algorithm that executes every time certain terrains are created or destroyed.
* If we did hoist fortification data to the overmap, I’d prefer to do so as a simple bitmap of blocked vs unblocked squares, with a supporting larger data structure indicating the identity of the obstacles so that hordes can interact with them. Avoiding over-minimization of this data helps with things like concentric rings of defenses, sections of which may occupy the same map tile.
Much like players can flag portions of ground as “NPCs shouldn’t pick up items here”, would it be possible for them to flag a contiguous set of overmap tiles they have cleared as “there is a fortification here”? It would cheapen the flood-fill approach by letting the algorithm discard all other overmap tiles.
Once the impassable vs passable bitmap is generated, an outside-in approach to this flood fill could mean not having to check any overmap tiles that are surrounded by fortification.
Construction and destruction of terrain would still cause re-checking of the fortification’s integrity, this could be alleviated by starting with re-evaluating that overmap tile, straght from the tile that just fell.
I don’t know if it’d be better to drop the bucket of paint on the tile and seeing where it goes, or running along the wall that just broke, trying to find the smallest room it belongs to, and then painting the room.
In either case, the flooding wouldn’t need to extend to adjacent map tiles unless the paint reaches it’s edge.
Since this is all happening using a bitmap+support data structure rather than the actual map, it doesn’t really matter if the entire fortress is loaded on memory or not.
Hmm, this could be accelerated by remembering what tiles were painted ‘outside’ by the previous run of the flood algorithm. Perhaps with a second bitmap, or perhaps by extending the number of colors to “inside, outside, impassable”, or even “inside, outside, inner_wall, outer_wall”.
I like the seocond one. No need to re-run flooding if what fell or what changed was an inner wall, or if a wall was added on a place that was already inside terrain.
If you’re interested in implementing a flood-fill approach, get cracking, if I’m implementing it I’m going to follow the approach I outlined.
Hmm… A “central” hub furniture/appliance could be used, a sort of ‘solar powered electric fence main box’ thing which when placed and then used allows the player to “paint” the bit-map of their defenses in a “v” view style way might be a good first step.
The player would be required to run the line out and then back to the box before being able to “activate” it. There could be restrictions on how far a gap it can bridge without a “stake” or passing through a “defensive”/“trap” tile The area inside would then be painted as fortified. And could be not be spawned inside by hordes and such.
creatures (not possesing the ‘small’ or similar flag) passing through the single wire “fence” while loaded would break that point painting it as a breach point. Multi layers of defenses would require multiple “fences” to be recognized. Should allow for lines of defense along lava and the like, walls, and other naturally occuring obstacles. Help layout planned defenses.
Downside would be allowing for potentially larger than holdable areas to be claimed “fortified” but would be broken by even a dog passing through.
No idea how this might function on an overmap level. But, by painting single tile line it would put the burden on the player rather than the system to determine where the “fortified” line is although that is its own downside as well.
other notable possibilities:
-
single side defenses and such could be set by running the wire throuh the same defenses twice
-
Every “defensive” and gap space now costs the player a small resource to claim
-
“gap” bridging stakes could be replaced by “insulated” ground wire, which would not count towards “fortified” defenses, but not be broken by creatures either.
-
Costs could be plausibly reduced to 1 wire per tile (maybe even less?) Or as much as several pieces and some plastic chunks, especially on gates and other openings without breaking immersion.
If I’m forted up in a gun shop, brick firehouse, or similar nigh-invulnerable structure, why do I have to set up a solar powered electric fence to be fortified?
All I want is to ensure that zombies don’t spawn inside a fortified area. I think establishing barriers through the zone or construction menu on a per tile basis is a way to start, but I don’t think people should have to build something when they do that: the construction entry is just a hook so that C:DDA can run the calculations to determine the barricaded area and eventually the fortified area.
I see this as something like you declare your barriers and eventually your fortification, which internally to the program is a collection of contiguous barriers. If a barrier is breeched, then the fortification stops providing benefits.
1 Like
yeah, that makes a lot of sense. I was thinking along the lines of it also being an alarm system, or upgradeable to an alarm system so you would know your defenses are breached, and having to manually paint the “fortified” safe zone feeling sort of… like achieving more than just telling the game that you consider the area fortified. The solar charger would be a very common kit in many knids of stores, so I didn’t see to much problem with requiring it to declare a safe-zone, especially BECAUSE it would be in its own way a way to keep the player from just “declaring” a zone safe without having to put SOMETHING into it.
Figured the player would go into a sort of ‘paused’ edit mode while they declared where the ‘fence’ would be, (to get around reality bubble issues of larger claims) then have some in-game time ‘setting’ it up, interruptions pausing how much is ACTUALLY built, untill the player gets back and invests the rest of the time required to finish the ‘fence’
All-together adding up to very low cost and investment to a player that only wants to secure a preexisting building/barrier.
Maybe pre-existing structures could at some point get some way to check if they have been fully cleared, and doors closed (with no smashed windows), to get the same tag?
Hmm… Some kind of fortification test would be nice if it could streamlined… although if the number of hordes gets to large every cleared building getting tested constantly until it fails might slow things, so maybe an either/or there.
Eventually a way to run a script for horde (soft test) attempts to enter defenses returning fail or success, with both giving to horde -zoms for traps encountered, +dead zoms in traps would be nice. Then if something like defense_noise returns positive (defensive turrets, noisy terrain destruction etc…) horde (hard test) tries again, if not the horde simply continues its overmap wander randomly. But I can’t think of a way that wouldn’t slow things too much, even in a simplified simulation. or even be truly attempt-able
Again, I think it’s best if the player chooses a tile to declare as barricaded - which does nothing but generate the bitmap of barrier locations - and then a set of barricaded tiles to declare as fortified. It shouldn’t be something that’s happening all the time in the background, but only at select times of the player’s choice. There might need to be some smarts in the interface, like barrier declarations that don’t turn into fortifications expire after a short period of time, and barriers can’t be declared if there are zombies nearby.
Damage to barriers either happens in the player’s presence - when it shouldn’t take too much extra time because you’re only dealing with the barriers inside the reality bubble - or happens abstractly by hordes outside the reality bubble and can be adjusted to happen at a frequency that doesn’t overwhelm play.
I think there’s space for alarms and proximity sensors and whatever, but I think the basic use case should be someone squatting in a 1 or 4 tile firehouse, being religious about closing the doors, and never coming home to hordes zombies inside the building[1] or having horde zombies spontaneously appear inside the building while the survivor is sleeping.
You should be able to fortify a 1 tile firehouse as soon as you clear out all the nearby zombies, without needing any extra equipment, because the 1 tile firehouse is already fairly zombie proof.
[1] Obviously if a horde contains hulks or brutes and your defenses aren’t very strong, the brutes might punch through them and get inside. But if that happens, you should see structural damage. Just having a Z on your map tile and then a bunch of decayed zombies spawning inside your structure because that’s a valid location when they enter the reality bubble shouldn’t happen.
Yeah. All makes sense,I was just explaining my thoughts behind why I suggested it like I did.
Though do hulks just bash walls and such down if there is no sound attracting them? If fortifications become an actual feature, then making it so a passively walking hulk doesn’t tear up things that don’t have something noisy behind them, like a turret, might be nice.
huh… bit of a tangent, but a sniffer/marker zombie would be scary to run into late game. Something that marks places that have player/ Ai human scent with some kind of hulk smash here attractant.
All in all it sounds like a nice plan, trial by fire should be interesting.
hmmm… I’m actually wondering now if we’re over thinking this whole thing. If we can hoist “just enough” data up to the overmap level, then hordes can just interact with just those obstacles in a really direct way, and we don’t need to worry about all of this designation or flood-fill stuff.
I had outlined a similar approach for fire in Spread of Eternal Fire, but if we do the same thing for obstacles, we can treat hordes the same way, interacting with obstacles even when they’re “off-map”, and applying the results of those interactions once the affected map tiles are loaded again.
Quick sketch of how this applies to monsters:
- Each square is represented by a tiny number, roughly speaking 0 for no obstacle, and increasing values indicating how hard the obstacle is to destroy. This number might be as small as 4 bits, giving 15 levels of toughness, which is a pretty wide range. Even for a whole overmap that’s just a MB or so.
- When hordes are processed, they move around and potentially smash obstacles in their way.
- If an obstacle is smashed, it gets set to 0, or possibly a special number that means “smashed”. When that map area is loaded, the map is edited to destroy the corresponding tiles.
- If they can’t smash an obstacle, they will tend to wander “around” the obstacle, because they would do the same “stumbling” behaviour that they do when loaded on the map.
- They only persistently smash at an obstacle if they get stuck trying to get to something, and even then they eventually lose interest and go back to wandering.
- Defenses like traps and turrets might also get hoisted to the overmap so that monsters can interact with them. This is something that’s going to tend to make your base “sticky”, because most effective defenses are going to be a bit noisy and keep attracting monsters.
If you limit it to 7 levels of toughness, you can have a flag for ON_FIRE in the last bit and still stay within ~1MB per overmap. Alternately, use a full byte per tile with 15 levels of toughness, a flammable flag, an ON_FIRE flag, and 2 other flags.
Then the same timer process that handles fire could also handle hordes.