hordes 2.0 braindump
| existing hordes live in overmap::zg; | |
| 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 | |
| methods for spawning and despawning monsters live in overmapbuffer::{spawn,despawn}_monster() | |
| need an act method, overmapbuffer::move_hordes() | |
| In overmapbuffer since they will need to cross overmap borders. | |
| Store references to monsters on a queue keyed by turns, after acting monsters insert themselves in the queue a number of turns in the future based on their speed. | |
| Treat each submap of monsters as a group that gets processed at once, that would be slightly less turn-accurate, but have MUCH better memory coherence. | |
| 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 monst\ | |
| er_map if necessary, and re-inserts them in the appropriate monster_turn_sequence (might be on a new overmap). | |
| Needs O(1) lookup for next group to process (will likely iterate on it). | |
| O(1) insertion into a new monster_group iff next update for it is sooner than the next update for the monster being inserted (likely, it just took a turn), O(logn) insertion if new monster group updates later t\ | |
| han the new monster, or does not exist, requiring an insertion into monster_turn_sequence. | |
| O(logn) re-insertion into the current monster_group, since its turn count is definitely changing. | |
| Optimizations: Batch insertions into neighbor monster groups to minimize number of insertions of the group. Process monsters slightly ahead of schedule (based on distance from player?) to reduce number of upda\ | |
| tes. | |
| Reacting to stimuli: (mostly sound, vision is checked on own turn) | |
| Iterate over monster_map locations in range of the sound (O(n^2) in sound range) and check for replacing existing sound event (loudest sound wins). Weird special case, underground gets extra extra attenuation.\ | |
| At a minimum queue these up and process them once per turn, with only loudest sound per submap (or possibly loudest per map? being applied to all monster groups. | |
| For flavor it would be nice if there were some random-ish noises on the overmap as well. | |
| Save/load: | |
| When an overmap is savesd, the monster groups can be written out in no particular order. | |
| When an overmap is loaded, re-inserting the monster groups should repopulate the data structures properly. | |
| API on monster_map | |
| add_monster(monster new_monster) | |
| add_monster_group(monster_group new_monsters) | |
| save_monsters() | |
| load_monsters()? | |
| monster_group_info get_monster_group_info(tripoint location) // For overmap display | |
| move_hordes() | |
| API on monster_group | |
| add_monster(monster new_monster) | |
| merge_monster_group(monster_group new_monsters) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment