Skip to content

Instantly share code, notes, and snippets.

@kevingranade
Created June 9, 2015 07:48
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kevingranade/c57295f234bc9212e387 to your computer and use it in GitHub Desktop.
Save kevingranade/c57295f234bc9212e387 to your computer and use it in GitHub Desktop.
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