Content Suggestion Breach System overhaul

Content Suggestions will be reviewed by Content Team weekly, please allow time as not everything can be reviewed at once.

Phill

Game Master
Game Master
Feb 11, 2025
19
0
41
What does this suggestion change/add/remove:
An overhaul of the current breaching system.

As of current, breaches have become almost monotone. SCP-076, 912, 106, 079, 682, 7722, 8837 and the Type-Green's are almost the sole anomalies that are breached on a regular basis, with SCP-049, SCP-035, SCP-096, SCP-966 and SCP-173 being breaches on a much lower frequency. SCP's such as SCP-939, SCP-082, SCP-9000 (Both) and SCP-457 are rarely, if ever, breached.

Further, in order to breach players often need to sit on an SCP job for hours at a time. Yet these are not frequently SCP's that undergo regular testing, thereby resulting in a boring time for these players as they quite literally sit around and wait.

Meanwhile, we also have the surface breaching system. A queue that players can join to breach as one of two surface anomalies. While in this queue, players can continue regular roleplay and contribute to the server. The queue permits one to line up for a specific SCP.

What I recommend is for the surface queue system to become the standard for all SCP's with the following key points;
  • Players can choose to either queue up for any SCP-breach for which they reach the level requirements, having a chance to be selected whenever said SCP would breach, or;
  • Players can choose to queue up for a specific SCP-breach, getting to play what they wish but risking the duration of their queue being longer if said SCP is not currently in the breach queue but getting priority over 'Any SCP' players should their chosen SCP be selected for a breach.
  • Which SCP is breached becomes randomized, players in the queue for the chosen SCP will be given a pop-up much like the one currently issued for surface-breaches.
  • The placement of an entity/The creation of a command usable by players to request a specific SCP to be active, preferably only accessible while in the relevant containment chamber. This can be utilized for testing or manual breaching by players. Players within either the 'Any SCP' or 'Specific SCP' queues will get a pop up offering testing RP. Accepting this will then result in a higher chance that someone is picked for the SCP breach.
  • Not remove the currently present ability to flag onto an SCP and wait- If thats what a player wishes to do, every right to them.

Has something similar been suggested before? If so, why is your suggestion different?:
The closest I could locate was the recent suggestion relating to a separate passive breach queue, but this suggestion does not relate to the current system for passive breaches and rather focuses on breaches in general.

Possible Positives of the suggestion (At least 2):
  • An increase in breach diversity. The 'Any SCP' queue combined with the randomization of which SCP is breached means that even SCP's such as 082, 9000 and 457 will be seeing much more regular breaches.
  • Better balancing potential for breaches. We all know that an SCP-8837 and TG combo is, frankly, awful to deal with. Due to a forced increase in breach diversity, E-11 will have more enjoyable breaches to contain while CI can still breach specific SCP's should they wish.
  • Removal of long, wasted 'SCP-Sitting' time where players just sit on an SCP for 2 hours awaiting a breach, not contributing to any active RP within the server. Resulting both in better player engagement and enjoyment.
  • An incentive for SCP's to participate in testing, removing the endless 'SCP-457 please flag up' messages in OOC chat and promoting testing by RSD as a result, as researchers know that *someone* will likely pick up the SCP for the increased chance to breach down the line.

Possible Negatives of the suggestion:
  • Devwork. I won't lie about it- I've got no experience coding things. I don't know how much work a change like this would be. I do however know that the framework for this sort of system already exists in the way of the surface breach queue, so I hope that adjusting it as stated above won't be too much effort. And if it is- I believe even just the addition of the surface breach queue system to all other SCP's as-is would be a major improvement to the current situation considering the long waiting times for SCP breaches resulting in players sitting idle.
  • Meta-game potential. Players will be able to queue up for an SCP, deny a pop-up, and immediately move to an SCP's containment chamber to begin recontainment efforts. Randomization will hopefully prevent this from being too-massive of an issue, an players can already use the existing tab-menu to see which SCP's are on currently. Furthermore, the time from pop-up to breach will likely be less than a minute; Therefore using the information of which specific SCP is breached will be limited in usefullness.

Based on the Positives & Negatives, why should this suggestion be accepted:
I believe that the positives here outweigh the negatives. Yes, it will be dev-work and an increased possibility of people metagaming, but the pros' of players no longer needing to sit around for hours twiddling their thumbs, being more likely to engage in much-needed RP as SCP's during testing, and the randomization of SCP breaches resulting in more enjoyable and diverse breaches for Foundation players is a worthwhile effort to pursue.
 

dougdougjones

Well-known Member
Jan 5, 2025
17
2
41
+SUPPORT

I know there’s been talks and other suggestions of changing the breach timer/process but a queue would be nice.
 
...Yeah. Alright. I feel like you should also be able to pop the queue by hacking a containment box - Hack box -> Hack successful -> Player at the front of queue is flagged onto that SCP -> Breach.
That way, you could make asking in OOC for an SCP to flag on for breach against the rules and just hack the box. A bit of a clunky solution to a few ongoing issues, but I think it has some promise, maybe.
+Support
 
I made a similar suggestion in the past regarding the SCP breach queue, proposing a shift away from the monotonous system we currently have toward a more dynamic and engaging experience. The idea was to transform it into a competitive or casual queue that includes mission-based objectives. This would incentivize SCPs to pursue tasks beyond just killing players, offering rewards for completing specific goals during a breach.

Looking back, the biggest flaw in that system is the current meta’s heavy focus on roleplaying collaboratively with all groups, rather than groups working against SCPs as a unified force. That disconnect creates tension between immersion and gameplay, making it difficult to implement more structured SCP objectives.

Below is a framework I proposed for a more dynamic SCP breach system:

  • Neglected containment conditions (such as poor cleaning or lack of maintenance) could trigger breach scenarios.
  • E-11 and Technical staff would receive automated warnings and alerts about chamber integrity, giving them a window to respond.
  • Failure to act in time would lead to progressive containment failure, resulting in an SCP breach.
  • Regular testing protocols would be required. SCPs not tested periodically (either within their CC or through escorted external tests) would become increasingly unstable.
  • This system adds a risk-reward dynamic, where proactive maintenance and scientific interaction directly influence containment success.
  • It creates a loop of meaningful engagement for Technical, Research, and Security roles beyond passive duties.
 
  • Neglected containment conditions (such as poor cleaning or lack of maintenance) could trigger breach scenarios.

  • E-11 and Technical staff would receive automated warnings and alerts about chamber integrity, giving them a window to respond.

  • Failure to act in time would lead to progressive containment failure, resulting in an SCP breach.
Containment maintenance, my beloved
Regular testing protocols would be required. SCPs not tested periodically (either within their CC or through escorted external tests) would become increasingly unstable.
I feel like this specifically would just result in more slop testing "RP" akin to how sampling is now - Making testing more of a chore than a medium.
 
Containment maintenance, my beloved

I feel like this specifically would just result in more slop testing "RP" akin to how sampling is now - Making testing more of a chore than a medium.
Me personally, I don't believe RSD or ETS can be fixed by any, one system ever. It's more the leaders conveying a specific message or idea to gather the small percentage of people interested into the groups. The larger majority will never set foot in that unless there's a reward, ie samplings.

It's all up to motivating the select few to engage meaningfully