- Feb 26, 2023
- 287
- 71
- 61
What does this suggestion add:
This suggestion seeks to implement a new breach system as a compromise to past suggestions that have been denied for either being unfeasible, due to technical limitations, or unfair to GOIs such as CI.
Upon flagging onto/being recontained an SCP, players spawn with 50% of their max HP (affecting by and according to current HP scaling on low-pop). As they wait to breach, their HP will scale upwards percentage-wise by 1%/minute, so at 50 minutes after initial flag, SCPs will breach at maximum HP. If player population increases to warrant a higher maximum HP, SCP HPs should increase in this same manner until they are breached or 100% HP is achieved.
EDIT: 0.5%/minute was changed to 1%/minute
This effect won't apply to non-HP-affected SCPs such as 079 or 106, because the main issue this addition is targetting is under use of such SCPs in a majority of breaches.
EDIT: The HP value upon breaching will be set to this maximum value, regardless of the SCP's current health. It's an invisible attribute that prevents SCPs from being weakened before legitimate breaching, similar to how the current system sets the HP of an SCP to full if they are damaged while contained.
Has something similar been suggested before? If so, why is your suggestion different?:
https://www.civilgamers.com/community/threads/breach-queue-change.21622/
https://www.civilgamers.com/community/threads/scp-hack-cooldown.20411/
This suggestion does not involve changing breach frequency, nor does it limit the way breaches can occur. It's a compromise designed not to encroach too heavily into absolute denial of breaches or delaying breaches, but rather to make it less frustrating for players to combat repeated SCP rebreaches which usually conclude after literal hours. In other wrods; nerf the breaches in a way that rewards the intention of the breach queue, but not the SCPs individually or the queue itself.
Possible Positives of the suggestion:
This suggestion serves as a fairer middle ground between randomly adding 30 minutes to prevent the snowballing of breaches or putting a hard-coded nerf on GOI interactions.
The reason this suggestion should not be considered as a clear-cut nerf to SCPs is because of the indirect buff to non-meta SCP involvement in breaches. Breaches feel stale because they are often prolonged indefinitely and comprised of SCPs that don't have noteworthy, SCP-specific interactions that can be played around.
Many players will agree that, while TYPE-GREEN can be fun to fight as a pseudo-juggernaut with a weapon lottery as an arsenal, it's not as fun to have your head exploded from across HCZ because the TG player clicks two buttons on their mouse. There's no counterplay possible; you can't anchor yourself to prevent his effects, and you aren't within range to anchor him either. On the other hand, an SCP like 082 is never breached intentionally because his entire ability is literally just range-limited explode head: underpowered. Now, compare and contrast TYPE-GREEN at 50% HP and 082 at 100% HP; even though 082 is objectively worse in abilities, his increased health factor makes up these shortcomings for the most part. If you then ask whether you'd want to counterplay against either SCP, but with this new system, there's room for debate.
In short, the meta SCP breach cycle has become such an effective but mind-numbingly boring routine that it both defeats the purpose of the queue and often kills other RP avenues in areas such as research or GOI relational matters. Implement a system that takes away from SCP players who can simply flag onto the role and be breached in a matter of minutes, whereas another player would have to wait out the full queue without a second thought of being breached manually.
This suggestion seeks to implement a new breach system as a compromise to past suggestions that have been denied for either being unfeasible, due to technical limitations, or unfair to GOIs such as CI.
Upon flagging onto/being recontained an SCP, players spawn with 50% of their max HP (affecting by and according to current HP scaling on low-pop). As they wait to breach, their HP will scale upwards percentage-wise by 1%/minute, so at 50 minutes after initial flag, SCPs will breach at maximum HP. If player population increases to warrant a higher maximum HP, SCP HPs should increase in this same manner until they are breached or 100% HP is achieved.
EDIT: 0.5%/minute was changed to 1%/minute
This effect won't apply to non-HP-affected SCPs such as 079 or 106, because the main issue this addition is targetting is under use of such SCPs in a majority of breaches.
EDIT: The HP value upon breaching will be set to this maximum value, regardless of the SCP's current health. It's an invisible attribute that prevents SCPs from being weakened before legitimate breaching, similar to how the current system sets the HP of an SCP to full if they are damaged while contained.
Has something similar been suggested before? If so, why is your suggestion different?:
https://www.civilgamers.com/community/threads/breach-queue-change.21622/
https://www.civilgamers.com/community/threads/scp-hack-cooldown.20411/
This suggestion does not involve changing breach frequency, nor does it limit the way breaches can occur. It's a compromise designed not to encroach too heavily into absolute denial of breaches or delaying breaches, but rather to make it less frustrating for players to combat repeated SCP rebreaches which usually conclude after literal hours. In other wrods; nerf the breaches in a way that rewards the intention of the breach queue, but not the SCPs individually or the queue itself.
Possible Positives of the suggestion:
- Incentivizes CI and D-Class pre-planning by necessitating players to be flagged onto SCPs for a decent timeframe in order to unlock full breach potential
- Stifles the effectiveness of quick-succession rebreaches without entirely stopping them
- (usually non-meta, but meta alike) SCP players in the queue for the long haul are likelier to be rewarded with a hack or breach tool (ex. 2 939s at 100% vs 076 at 50%)
- Increases probability of containing site-wide breaches where killing the catalysts (035, 079, CI) that perpetuate the breach indefinitely may not always be readily possible
- Technical limitations; constantly varying HP regeneration as a percentage of maximum, scaled with player count
- Breach longevity for shortly-waiting players is hindered
This suggestion serves as a fairer middle ground between randomly adding 30 minutes to prevent the snowballing of breaches or putting a hard-coded nerf on GOI interactions.
The reason this suggestion should not be considered as a clear-cut nerf to SCPs is because of the indirect buff to non-meta SCP involvement in breaches. Breaches feel stale because they are often prolonged indefinitely and comprised of SCPs that don't have noteworthy, SCP-specific interactions that can be played around.
Many players will agree that, while TYPE-GREEN can be fun to fight as a pseudo-juggernaut with a weapon lottery as an arsenal, it's not as fun to have your head exploded from across HCZ because the TG player clicks two buttons on their mouse. There's no counterplay possible; you can't anchor yourself to prevent his effects, and you aren't within range to anchor him either. On the other hand, an SCP like 082 is never breached intentionally because his entire ability is literally just range-limited explode head: underpowered. Now, compare and contrast TYPE-GREEN at 50% HP and 082 at 100% HP; even though 082 is objectively worse in abilities, his increased health factor makes up these shortcomings for the most part. If you then ask whether you'd want to counterplay against either SCP, but with this new system, there's room for debate.
In short, the meta SCP breach cycle has become such an effective but mind-numbingly boring routine that it both defeats the purpose of the queue and often kills other RP avenues in areas such as research or GOI relational matters. Implement a system that takes away from SCP players who can simply flag onto the role and be breached in a matter of minutes, whereas another player would have to wait out the full queue without a second thought of being breached manually.
Last edited: