[WIP] Hordes 2.0 #14240

kevingranade · Nov 30, 2015

I've been poking at this for a while, and I finally sorted some things out to my satisfaction and am implementing it.

There are two key points to the design:

Monsters are stored on a per-overmap-tile priority queue (monster_group) which is itself stored on a per-overmap priority queue. This effectively creates a scheduler for periodically allowing monsters to move, while managing how many updates happen per game tick. The plan is to let individual monster_groups get a little behind, and then catch them up all at once so that each batch of monster updates pulls from a small number of groups and write to a small number of groups, improving locality of reference.
The senses object isolates monster AI from the overmap code, it knows the kind of things the AI needs to know, and knows how to get that information from the overmap. I intend to extend this for use with map-scale monster AI later for similar reasons.

CIB · Nov 30, 2015

CIB reviewed Nov 30, 2015

View changes

CIB · Nov 30, 2015

doc/HORDES.md

+hordes move with calls to overmap::move_hordes()
+These should both be removed, specific monster instances should be created instead of hordes, probably.
+
+monsters outside the reality bubble live in overmap::monster_map


Are these supposed to be TODO items?

Yes, this whole file is simply my brain dump about the design of the feature, it will be cleaned up and corrected as I go, and tidied up into javadoc by the end of the process.

CIB · Nov 30, 2015

CIB reviewed Nov 30, 2015

View changes

CIB · Nov 30, 2015

doc/HORDES.md

+
+Use cases:
+Steady-state processing:
+The overmap is triggered to do a turn, it grabs the monster group at the head of monster_turn_sequence and checks if they are due for processing, if they are, it processes them, moving to new locations in monster_map if necessary, and re-inserts them in the appropriate monster_turn_sequence (might be on a new overmap).


So if the first monster isn't ready to be processed, you stop scanning due to the sorted nature of the queue?

Yes, we can guarantee that we process the "most out of date" monsters in each group.

CIB · Nov 30, 2015

CIB reviewed Nov 30, 2015

View changes

CIB · Nov 30, 2015

doc/HORDES.md

+For map data (navigability, vision, and scent), monster AI can have a persistent "oracle" injected into it, which it can query for map data such as nearest visible enemy, nearest strong scent, and pathing information.  This means the monster AI doesn't have a dependency on the overmap, and creates an injection point for testing monster AI.
+
+Save/load:
+When an overmap is savesd, the monster groups can be written out in no particular order.


Typo on this line.

CIB · Nov 30, 2015

CIB reviewed Nov 30, 2015

View changes

CIB · Nov 30, 2015

doc/HORDES.md

+OMTs should have a move cost derived in a similar way to the load factor.
+Monster pays move cost to exit an OMT
+Eventually monster groups should fight each other if they encounter opposition.
+Dense hordes should mark map tiles for destruction as they cross over them, at some point becoming completely wrecked.


That is questionable since most zombies don't actually destroy terrain when loaded into the reality bubble unless agitated.

They agitate very easily, though.
And in a dense horde, one zombie is enough to start a mosh pit and get the rest to bash down an entire house.

Many players have found that it's currently a viable strategy to stay very quiet in your house and wait for the horde to pass. They will rarely mess anything up. So having them behave differently on overmap scale would be strange.

When I say dense hordes here I mean having the map tile at near capacity, literally wall-to-wall zombies.

Ah, that clears things up, thanks.

CIB · Nov 30, 2015

CIB reviewed Nov 30, 2015

View changes

CIB · Nov 30, 2015

src/monster.h

+         **/
+        void apply_stimulus( const tripoint &location, const monster_group_stimulus &stimulus );
+        int next_overmap_move() const;
+        // Decide on and advance time to next overmap move.


Could make this a doxygen comment.

CIB · Nov 30, 2015

CIB reviewed Nov 30, 2015

View changes

CIB · Nov 30, 2015

src/monster_group.cpp

+}
+
+void monster_group::add_monster( monster &new_monster ) {
+    // Reset the strongest stimulus since this new monster might not have received it.


On the other hand, the newest monster might simply follow its group. Heuristically, it might be a better solution for now to keep the stimulus, but decrease the interest in the stimulus.

Another note, for the common case of the player just barely escaping a monster and putting it on the reality bubble, it might be good to still have the monster pointing in the direction they were going on the overmap.

The rationale is expanded a bit on line 28, but I need to bulk up the explanation some. This isn't denying input to the monster, but rather a work-avoidance mechanism. As stimuli come in, they will be applied to each monster on the list, who will each make their own decision about the stimuli, but if a stronger stimuli is followed by a weaker stimuli, we can avoid applying it. This is upset by new monsters being inserted into the group though, because we don't have any information about the strongest recent stimuli those monsters experienced, so to be safe I'm just resetting it.
I completely agree that when monsters leave the map, or when they shift from one overmap square to another they should remember their previous goals.

I just realized though, we need to track stimuli of each type separately, if a clearly visible stimuli is followed by a relatively quiet sound, the sound still needs to be applied in case there are blind monsters in the group.

CIB · Nov 30, 2015

CIB reviewed Nov 30, 2015

View changes

CIB · Nov 30, 2015

src/monster_overmap_move.cpp

+
+static int effective_strength( const monster_group_stimulus &stimulus, const tripoint &location ) {
+    // TODO: different scaling for effective strength based on stimulus type?
+    return stimulus.strength - ( stimulus.occurence - calendar::turn ) -


( stimulus.occurence - calendar::turn ) will always be negative, so personally I'd find it more intuitive to do + ( caldar::turn - stimulus.occurence).. In fact, putting it like that, I'm pretty sure that's not what you had in mind. ;)

Yep, this is backwards.

CIB · Nov 30, 2015

CIB reviewed Nov 30, 2015

View changes

CIB · Nov 30, 2015

src/senses.h

+/**
+ * Object to inject into monster AI to isolate AI code from map or overmap accesses.
+ */
+class senses {


CIB · Nov 30, 2015

Very good code, I have few complaints.

When you write a description of a function or field, it would be nice to make it a doxygen comment, even if it's just a one-liner (~~I think /// works as one-line doxygen comment~~ Doxygen is dum, you pretty much have to use /** */).

When this goes in, there should be a clear distinction between status quo and TODO in the documentation.

kevingranade · Dec 2, 2015

Both points taken, will do.

mugling · Sep 14, 2016

Appears stalled

kevingranade added some commits Nov 29, 2015

Return an empty vector if you are asked for the path to the current s…
…quare.

007eaf4

Added initial implementation and unit tests for monster group AI.

Loading status checks…

6ca8731

kevingranade force-pushed the kevingranade:hordes-2.0 branch to 6ca8731 Nov 30, 2015

kevingranade referenced this pull request Nov 30, 2015
Merged
Move effect of climate control to the end of bodytemp calc #14241

mugling closed this Sep 14, 2016

kevingranade added this to Input Queue in Hordes Mar 4, 2017

kevingranade added this to To Do in Increase engagement ranges via automation Jan 24, 2018

alanbrady referenced this pull request Sep 13, 2018
Open
Check out initial wander spawn behavior #16

CleverRaven/Cataclysm-DDA

Join GitHub today

[WIP] Hordes 2.0 #14240

Conversation

kevingranade commented Nov 30, 2015

kevingranade added some commits Nov 29, 2015

kevingranade force-pushed the kevingranade:hordes-2.0 branch to 6ca8731 Nov 30, 2015

kevingranade referenced this pull request Nov 30, 2015

CIB reviewed Nov 30, 2015 View changes

This comment has been minimized.

This comment has been minimized.

CIB reviewed Nov 30, 2015 View changes

This comment has been minimized.

This comment has been minimized.

CIB reviewed Nov 30, 2015 View changes

This comment has been minimized.

CIB reviewed Nov 30, 2015 View changes

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

CIB reviewed Nov 30, 2015 View changes

This comment has been minimized.

CIB reviewed Nov 30, 2015 View changes

This comment has been minimized.

This comment has been minimized.

CIB reviewed Nov 30, 2015 View changes

This comment has been minimized.

This comment has been minimized.

CIB reviewed Nov 30, 2015 View changes

This comment has been minimized.

This comment has been minimized.

CIB commented Nov 30, 2015

This comment has been minimized.

kevingranade commented Dec 2, 2015

This comment has been minimized.

mugling commented Sep 14, 2016

mugling closed this Sep 14, 2016

kevingranade added this to Input Queue in Hordes Mar 4, 2017

kevingranade added this to To Do in Increase engagement ranges via automation Jan 24, 2018

alanbrady referenced this pull request Sep 13, 2018

kevingranade force-pushed the kevingranade:hordes-2.0 branch to `6ca8731` Nov 30, 2015

CIB reviewed Nov 30, 2015

View changes

CIB reviewed Nov 30, 2015

View changes

CIB reviewed Nov 30, 2015

View changes

CIB reviewed Nov 30, 2015

View changes

CIB reviewed Nov 30, 2015

View changes

CIB reviewed Nov 30, 2015

View changes

CIB reviewed Nov 30, 2015

View changes

CIB reviewed Nov 30, 2015

View changes