"Dormant" monster attribute.

[I-am-Erk]

Is your feature request related to a problem? Please describe.
Many monsters, including zombies, robots, and magiclysm golems, should not simply wander around all the time in brownian motion when not being observed. They should enter a dormant mode.

Describe the solution you'd like
Dormant monsters should be definable in JSON to allow this behaviour. This would allow us to both make regular zombies go dormant if there's no one to hunt around, and also let us put thousands of dormant zombie corpses into cities to come to life later on when the horde needs reinforcements.

There are a couple different types of dormancy that should be explored. Therefore, dormancy should be a multi-attribute part of the monster definition.

"dormant": { defaults to false.

Dormant zombies should resemble a corpse, perhaps even to the point of just being identified as a corpse on examination. Dormant robots should look like deactivated robots. Dormant golems might masquerade as f_statue. The zombie and golem case could be presented as:
"identify_as": "f_statue" this means that the dormant golem would have the same symbol, graphic, and description as f_statue. It does not show up on the monsters list. If this field is not used, the normal monster data and description would show up, with the exception of:
"dormant_description": "This is an inactive robot, awaiting some trigger that would turn it on." If the dormant_description field is filled, it overrides the description that might have been specified in identify_as as well. So dormant zombies might get:
"dormant_description": "Although inert, this corpse is suspiciously un-pulped and unrotten, and has black goo encrusted around its mouth and eyes."

Different monsters need different triggers for dormancy. These "dormant_triggers": [] could be the same flags as monster aggression/fear/placation uses. Unlike aggression triggers etc, these would be a simple check. If the player approaches and PLAYER_CLOSE is a trigger, the dormant monster awakens. However, to avoid triggering all the dormant monsters in the reality bubble, we should be able to gate it to distance:
"trigger_radius": 5 the radius away from the dormant monster the player needs to be before activation is triggered.

(Side note: It might be more effective to allow a different trigger radius for each trigger, something like:
"dormant_triggers": [ { "trigger": "PLAYER_CLOSE", "radius": 1 }, { "trigger": "HURT", "radius": 20 } ]
While this is preferable it's also a bigger pain for data entry and I would assume for programming.)

Once activated, the monster should remain dangerous even if none of its activation triggers are being met, at least for a while, before deactivating. Some monsters, like a golem guarding a door, might deactivate very quickly if you left their radius:
"active_time": 0
Others, like zombies, might stay awake for quite a while before going dormant again. If a time range is specified, a random length of time within that range is used:
"active_time": [ "20 m", "1 h" ]

Some monsters, like zombies, should just drop back to dormant mode wherever they stand once stimulus to activate is removed and active_time relapses. This would be the default behaviour. Others, like robots and golems, should have the option to return to the tile they spawned in when their active time ends. This could be used, for example, to make manhacks return to a charging station, or golems return to a guard post.
"return_home": true
If the home site is outside the reality bubble, I assume the monster should just head out of the reality bubble while in return_home mode and then just teleport the rest of the way there, perhaps. To prevent monsters being led very far away from their home base and then teleporting unreasonably far distances - and also to prevent luring guard robots away from their posts - we probably want to be able to specify:
"max_chase_distance": 25
If a monster didn't have return_home, max_chase_distance wouldn't make sense, since they don't have a home to measure distance from. However I think we do need both fields, so that we can still potentially have a return_home monster that will chase an unlimited distance.

Dormant zombies should have the ability to evolve into a non-dormant form, allowing us to scatter various dormant zombies around the map to gradually wake up into full zombies, perhaps with different evolutionary trees. I think this could be done just by having a normal evolution flag, I don't think dormancy needs any specific new attributes related to it.

As a secondary thing, we should have a monster ability for leader-type monsters to activate nearby Dormant monsters. This would allow Zombie Necromancers to actually "wake up" surrounding corpses, even if they were some kind of mon_deep_dormant_zombie that wouldn't wake up for nothin' otherwise.

There are probably other dormancy features that could be included, but I think if we have all of these, we could get a pretty cool dormancy system that would make much more dynamic enemies.

In summary

Here is an example dormant attribute using all the fields, a plastic golem:

"dormant": {
  "identify_as": "f_statue",
  "dormant_description": "How odd, this statue is a 3D printed plastic model with action-figure-like articulated joints.  That is not suspicious in the slightest.",
  "dormant_triggers": [ "HURT", "FRIEND_ATTACKED", "FRIEND_DIED", "PLAYER_CLOSE" ],
  "trigger_radius": 5,
  "active_time": "1 m",
  "return_home": true,
  "max_chase_distance": 8
},

[KorGgenT]

I definitely want this for mimics, too.

[Ezsk]

Interesting ! One question, Does Robots that flagged "PLAYER_CLOSE" are sleeping until slapped by zombies? Or wake up when approaching a zombie? I thought the ENEMY_CLOSE flag might be useful.

[I-am-Erk]

Yeah, enemy close would actually be a good trigger flag for aggression too.

[I-am-Erk]

Some things I have thought of on my way home to add to main topic later:

• hibernation: a monster special that makes it go dormant in cold weather specifically, with a bunch of common traits (may also have its own regular dormancy mode)
• activate_message: { snippet: id, volume: int } text that is displayed when the monster activates (the corpse stands up!). Should be a snippet id for variety.
• warning: { snippet: id, volume: int, radius: int } optional text displayed when you enter radius. Eg, "the statue in the corner shudders, its head turning towards you." "As you approach you notice the corpse twitching slightly." "The robot beeps loudly. 'Warning! This is a restricted area!'"
• dormant_message {snippet, volume} the zombie curls up on the floor. "Power saving mode activated". The golem returns to its pedestal and adopts a perfectly still pose. The hideous cat monster spins a cocoon around itself.

[Solusphere]

Would the dormant creatures still be targetable with ranged weapons and/or melee attacks? Also, would they still show up on thermal vision or electroreception?

[I-am-Erk]

If they have an identify_as field, you'd want the game to think of them as whatever they identify as for every purpose. If not, they should show up however you'd normally see them.

We could potentially have battlefields of dozens of dormant zombies, it would be really annoying to have them all show up as potential targets

[Brian-Otten]

Unless there is a special exception they should probably still be targetable with manual aim though. for guns that's just aiming on their tile and for melee weapons smashing their tile.

Really cool idea btw, if done right could make enemy management / combat strategy a lot more dynamic and fun.

[Solusphere]

How would that work when you go to manually (s)mash them? Wouldn't that cause them to, say, collapse into stone rubble if they're posing as a statue?

[Brian-Otten]

Probably just count as an opening attack and wake them up if they have not been instakilled. Some really deep sleepers might stay dormant even when attacked. Depending on the type could also have them be stunned/downed for 1 turn after waking.

[I-am-Erk]

Yeah, smashing would be treated like a melee attack.

[ghost]

Nice idea, but I foresee this resulting in massive save bloating and performance issues if some sort of partial re-initialization and purging of zones that are not 'lived-in'/visited frequently is not implemented beforehand.

[TechyBen]

Nice idea, but I foresee this resulting in massive save bloating and performance issues if some sort of partial re-initialization and purging of zones that are not 'lived-in'/visited frequently is not implemented beforehand.

Could this be sidestepped by only spawning some as "dormant" (so not needing re-initialising, they will spawn as dormant and stay that way on map until activated) and those who spawn as active, would fully go into a dormant state that saves into an object that is map orientated not mob/NPC orientated?

For example, the code that (use to?) spawn cockroaches from rotten food, had both counters to the rotten food, and spawning from the cockroaches... though that might have lagged the game?

[ghost]

@TechyBen if I understand your idea correctly - as partial population with 'dormants' from map local dormant_pool counter and capping number of ones actually being stored as objects - sure, that is the IMO the only way to do it without suffering major save bloating hit.

[I-am-Erk]

Optimization would be nice for giant hordes of dormant zombies, but it's definitely not necessary for this feature to be implemented.

[actual-nh]

Perhaps this could go in 0.G blockers?

[I-am-Erk]

I'm going to rewrite this to use EOC code. It should be entirely doable now.