Accepted Accumulating HP Breach System

This suggestion has been accepted for future development.
Status
Not open for further replies.
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:
  • 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
Possible Negatives of the suggestion:
  • Technical limitations; constantly varying HP regeneration as a percentage of maximum, scaled with player count
  • Breach longevity for shortly-waiting players is hindered
Based on the Positives & Negatives, why should this suggestion be accepted:
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:
-support here's some scenarios that will commonly happen if implemented:

  • E11 shooting SCP 076 for fun an hour before he breaches, reducing their max HP when they eventually breach by a considerable amount
  • E11 nerve pre-emptively attacking SCP 7722 from outside his cell when they hear CI is approaching it to reduce his SCP when he breaches, only stopped when CI kill him
  • D-class enters SCP 939s containment cell and stabs him for fun while he's AFK doing considerable damage
  • SCP 912 becomes even worse of an SCP
  • Any SCP who has been moved up in the breach queue will breach with considerably less HP, being punished for the person before them leaving
  • SCP 073 will be able to nuke the site (nerf SCP 073)


did you actually consider any of this before making the suggestion? there is no way to balance this suggestion so the 2,000 cases where the system works against a completely innocent player are stopped
 
  • Haha
Reactions: Emilia Foddg
-support here's some scenarios that will commonly happen if implemented:

  • E11 shooting SCP 076 for fun an hour before he breaches, reducing their max HP when they eventually breach by a considerable amount
  • E11 nerve pre-emptively attacking SCP 7722 from outside his cell when they hear CI is approaching it to reduce his SCP when he breaches, only stopped when CI kill him
  • D-class enters SCP 939s containment cell and stabs him for fun while he's AFK doing considerable damage
  • SCP 912 becomes even worse of an SCP
  • Any SCP who has been moved up in the breach queue will breach with considerably less HP, being punished for the person before them leaving
  • SCP 073 will be able to nuke the site (nerf SCP 073)


did you actually consider any of this before making the suggestion? there is no way to balance this suggestion so the 2,000 cases where the system works against a completely innocent player are stopped
My apologies, I should have specified that the way this would work is that this accumulated health is the HP they will breach with. It's an invisible attribute not correlated with their actual HP. Regardless of their actual current health, upon breaching, their health will be set to that value. Hopefully this resolves your first four examples.

As for the second last example, it is somewhat of a legitimate concern, if not a concern for a very rare edge case. You won't often have many SCPs leaving their queues sequentially that will allow a player who just joins the queue to have sub-100/50-minute queues RIGHT as they flag on. Chalk it up to fortunate/unfortunate timing, but no matter how you see it, I'm sure an SCP player would rather wait less than 100 minutes to breach than the original 150+ that they would've otherwise had to.
 
My apologies, I should have specified that the way this would work is that this accumulated health is the HP they will breach with. It's an invisible attribute not correlated with their actual HP. Regardless of their actual current health, upon breaching, their health will be set to that value. Hopefully this resolves your first four examples.

As for the second last example, it is somewhat of a legitimate concern, if not a concern for a very rare edge case. You won't often have many SCPs leaving their queues sequentially that will allow a player who just joins the queue to have sub-100/50-minute queues RIGHT as they flag on. Chalk it up to fortunate/unfortunate timing, but no matter how you see it, I'm sure an SCP player would rather wait less than 100 minutes to breach than the original 150+ that they would've otherwise had to.
ight
+support only if this "invisible stat" is not only visible but also inherited if the person in the breach queue before you leaves (e.g. if the next person to breach was at 92% HP but leaves, the person who moves into their place gains the 92% HP upon breach)
 
  • Love
Reactions: Emilia Foddg
-Support
-A lot of the time SCP's are asked to flag on in OOC because something is just about to breach. I dont see why this should be changed/nerfed as it is currently fine as is.

How often do you see a 966 breach tooled or hacked out?
This is just a bad argument. If something is bad and you nerf it even more because it was already bad then we have a issue of it now becoming dogshit
 
  • Love
Reactions: Bill Nye The Guy
A lot of the time SCP's are asked to flag on in OOC because something is just about to breach. I dont see why this should be changed/nerfed as it is currently fine as is.
I'm confused - the point of the suggestion is to establish a time-to-breach effectiveness tradeoff. Meta SCPs get all the limelight for very, VERY disproportionate amount of time sitting in a cell. I'm not even sure what you're trying to say here, and this most definitely isn't fun for most players on the US server. If it's different on the UK server, then by all means, this change may indeed not be needed there.

This is just a bad argument. If something is bad and you nerf it even more because it was already bad then we have a issue of it now becoming dogshit
I'm even more confused and convinced that you haven't understood the suggestion. I gave the example with 966 seldom being breached by other SCPs/GOIs because nobody will ever ask a 966 player to flag onto the role. If 966 is breached, its usually because there are no other options left, implying that every higher priority SCP is already breached or not flagged onto the role. Chances are, a 966 player breached in this way will have been flagged onto the role for no less than 2 hours, just waiting down the queue, and by which it has probably reached 100% HP. Like I said, the choice between a full-health 966 versus a half-health 076 gives 966 somewhat of an advantage, if not minute.
 
Jul 10, 2023
211
67
21
Suggestion Approved



Hi @grunger ,

Thanks for taking the time to make a server suggestion.

This has been accepted as having more people flagged on SCP for longer periods of time will encourage RP. Having people wait on SCP instead of just flagging on when a raid happens will allow researchers to easily conduct tests and other RP scenarios.

Your suggestion will now be locked and marked as accepted.​
 
Last edited:
Status
Not open for further replies.