Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spawners #328

Open
tukkek opened this issue Apr 4, 2022 · 0 comments
Open

Spawners #328

tukkek opened this issue Apr 4, 2022 · 0 comments

Comments

@tukkek
Copy link
Owner

tukkek commented Apr 4, 2022

A Dungeon Feature for certain (or all) Monster Types that would work more like an de-spawner compared to most spawners in other games. They would exist in a Dungeon, generated based on a floor's Encounter Table: a Summoning Portal for Outsiders, an Assembler for Constructs... a player would then have to take-ten for the appropriate Skill check with Difficulty Class from the standard level Feature DC Table (Craft for the Assembler, Spellcraft for the Portal...) to reduce the amount of enemies of said type from the Level.

Failing said check would give the player a chance to "brute force" the spawner. This is a guaranteed disable with the same positive outcome but then results in a Fight, with the initial suggestion being just two stacks of the same Encounter (+2 Encounter Level being difficult but doable). The text prompt would be something like *You have failed to disable this Spawner#description. You can attempt to destroy it but this is likely to active unwanted attention or some form of defense mechanism"...

With each Spawner targeting a single matching Encounter on the Encounter Table, the idea is, once successfully disabled, that Encounter is replaced with null, which currently means no further Encounter when that line is roll upon for a Random Encounter, effectively making the Floor safer by a small amount per Spawner - this way, it also guarantees that the effect will be theme-appropriate rather than just disabling.

Given that 1:1 relationship, upon interaction, the Spawner should check that no other mechanic has already disabled the given Encounter and if so, display instead this Spawner#description seems inert and then remove itself accordingly. Player's have no way of knowing for sure the state of the Encounter Table so they wouldn't know if a Spawner was ineffective even if it seemed to work but given that the extra Difficulty could result in a Deadly Fight, it would be unfair to expose them to the risk without the possibility of a fair reward.

For similar reasons, upon creating a new Spawner, Encounters that have not yet been matched should be given priority. If all potential matches have already been made, then repeats can be produced: it just means players will have multiple chances to remove an Encounter, with later Spawners being inert after the fact. To make this less deterministic, some soft way of enforcing this can be implemented, like adding all encounters to a pool but then adding a second instance for those still un-matched before drawing a result, prioritizing them.

@tukkek tukkek added this to the Long-term milestone Apr 4, 2022
@tukkek tukkek mentioned this issue May 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant