Policy Review Issues With Threats Discussion

Status
Not open for further replies.
Approved by Birkal

After participating in a few CAPs, I think that the threat discussion is the weakest stage in the entire process. I think that one of the biggest issues is the general vagueness and lack of direction of this stage. Even the description on the CAP site (https://www.smogon.com/cap/process/events/threat_discussion) doesn't explain what the objective of the stage is, and everything seems to be left to the TL discretion. I do not think that the stage is broken, because it certainly served its function just fine on the last projects, but I think that there are many ways in which it could be improved. Here are some of my suggestions:

-Have a basic template of how the final threatlist should look. Here are last posts of the last five projects:
On CAP 20/21/22, the final threatlist is divided in two groups, Pokemon that we threaten, and Pokemon that should threaten us (On CAP 20, the list is further divided for each one of Calm mind and Dragon Dance, but the basic structure is still the same). However, on the last two CAPs, the lists use a clearly different format, making a clear divide between Pokemon that should counter or check us, and between things that we should pressure and things we should outright beat. Of course, I believe that for certain projects, the TL should be able to make certain changes to the basic template to better fit the concept, but here we can see a clear point where the structure of the list changed. Some might blame the Topic Leader, for not adhering to the previous template, but I think that this misses the point: there was never any template to begin with. To try to fix this, I propose that we decide on the format that the final threatlist should use. This should help standardize the process, and would serve as a clearer goal to this stage.

As for how should the template look, the two obvious models would be, on one hand, the way that most old threatlist work, divided simply between Pokemon that we should threaten, and ones that we should be threatened by. This has the advantage of being very straightforward, and allows greater flexibility on later stage. However, it is also pretty vague, and doesn't give any particular priority to anything inside each label, which doesn't tell us how important each one might be. On the other hand, the model used on the two last CAP Projects is divided between mons we beat, mons we pressure, mons that check us and mons that counter us. This is a much more precise method, and gives us a more in-depth analysis of how the current CAP should interact with a list of some the most relevant Pokemon in the tier. Despite that, the fact that here we have a fixed list of hard counters to us, can have a negative impact on later stages, because it places some very hard restrictions on them. Personally, I think our best choice here is to try to find a balance between these two models, as both have their own strengths and weaknesses. For this reason, I propose we divide the final threatlist into 3 basic sections: Switch in, Pressure, and Check/Counter. Here is a brief description of each one:

Switch in: Here would be the list of Pokemon on which we should be able to have a easy time switching in and then forcing them out, at least twice in a game. Of course, this doesn't necessarily mean that we should be able to come into any of their moves, just their most commonly used moves. This would mean that things in here would be our highest priority targets, and we should prioritize trying to beat them.

Pressure: This would be the place where we place mons that might threaten, but should not be able to switch in easily. This means that beating them is not a priority, but we should still actively try to avoid making them good checks to the current project.

Check/Counter: This would basically be the old "threatened by" list. This section is intentionally left more open than the others, because it lets us decide the exact role of each individual mon in here later, which gives us greater flexibility on later stages.

-Refer to Pokemon during the discussion and on the final threatlist by specific sets. For any Pokemon, their set is the main thing that determines what they're able to check. For example, if you are using SD Garchomp, then you are checked by Krilowatt, as it is faster and Ice Beam is a guaranteed OHKO. However, if you are using a Choice Scarf, the roles are reversed, and now Garchomp serves as a Krilowatt check, as it threatens it with Earthquake. This is true in countless cases, and certain mons might have completely different roles depending on their set. This can cause troubles in the discussion, as we might want to check/be checked by only one set, while we might want the opposite for other sets. For all this reasons, I think this will greatly improve the quality of the discussion, as we will be able to pinpoint how a project should interact with specific sets, and what kind of EV spread each member of our threatlist uses.

-Always assume the same entry hazards by default: The presence of Stealth Rock can significantly alter whether or not you can check/counter something. Therefore, I believe we should agree on the amount of hazard that we should assume when discussing threats. Personally, I think that this should be left at the discretion of the TL, as the popularity of hazards will inevitably fluctuate in the future, and they should be the ones to make this decision on each process. TL should also be able to dictate a particular set of hazards for a specific Pokemon (For example, CAP X should hard checked by mon A, even with Stealth Rock and 3 layers of Spikes on the field, while mon B only checks if there is no SR on its side).

-Have a standard definition for each part of the threatlist on the Opening Post, to make sure that everybody clearly understands what each term means. Here is the list of definitions I propose:

Full counter: Able to repeatedly switch into the opposing Pokemon against ALL sets and then beat it, even if the opponent predicts correctly every turn.
Hard counter: Able to repeatedly switch into the opposing Pokemon against most sets and then beat it, even if the opponent predicts correctly every turn. There are some sets capable of winning, but they are very specialized and generally outclassed.
Soft Counter: Able to repeatedly switch into the opposing Pokemon against some sets and then beat it, even if the opponent predicts correctly every turn. However other common sets might be able to beat this.
Hard Check: Able to repeatedly switch into most of the opposing Pokemon moves and then beat it, but can be beaten with the right prediction, or by wearing it down through the game.
Soft Check: Able to switch into the opposing mon at least twice in the game with a free switch, and then beat it.
Beat (1v1): Beat the opposing Pokémon after both mons switch on the same turn with 100% HP, no hazards and without a Focus Sash.


Of course, I imagine that others might have other ideas about how this discussion could be improved, so I would love to hear feedback on my suggestions and other possible ways on how to improve this stage.
 
Last edited:

david0895

Mercy Main Btw
The general concept is a really good idea.
But I'm not sure on having an heavily detailed check/counter list.
Even on the analysis, most of the checks and counters are not defined as hard or soft.
In my opinion the list should be something like this:

Switch-in: list of pokemon sets

Pressure: list of pokemon sets

Checks: list of pokemon sets

Counters: list of pokemon sets
 
The general concept is a really good idea.
But I'm not sure on having an heavily detailed check/counter list.
Even on the analysis, most of the checks and counters are not defined as hard or soft.
In my opinion the list should be something like this:

Switch-in: list of pokemon sets

Pressure: list of pokemon sets

Checks: list of pokemon sets

Counters: list of pokemon sets
The problem with having separated lists for checks and counters is that defining what Pokemon should outright counter us isn't the point of this stage, instead we should be focusing more on what could counter us, while leaving the fine details for later stages. Having hard defined counters so early in the process heavily dictates later stages, as certain options cannot even be considered if we want to follow the list, because they would mess with the already dictated counters. The Threat Discussion for Pajantom serves as a good example of this issue, as the decision to have M-Scizor and Ferrothorn as full counters meant that we had to make a physical attacker, because we would otherwise be able to break them using Hidden Power Fire, and also restricted our movepool too, because things like Fire coverage and Taunt couldn't even be considered. Now, I think that in the end, Pajantom turned up just fine, but I think that this was despite the threat discussion, not thanks to it; the Final Product doesn't even really follow the list, as Skarmory and M-Scizor can be prevented from healing with a well timed Heal Block, while Celesteela, Ferrothorn and Fini can't switch into Spirit Shackle repeatedly, and take massive damage from Ghostium-Z sets.

Overall, I think that there are no real benefits for separating checks from counters in this stage. If the TL believes that having a discussion about Checks and counters specifically would be beneficial, they can always choose to do the optional Counter Discussion, like we did in the last project.
 

DougJustDoug

Knows the great enthusiasms
is a Site Content Manageris a Top Artistis a Programmeris a Forum Moderatoris a Top CAP Contributoris a Battle Simulator Admin Alumnusis a Smogon Discord Contributor Alumnusis a Top Tiering Contributor Alumnusis an Administrator Alumnus
Moderator
The problem with having separated lists for checks and counters is that defining what Pokemon should outright counter us isn't the point of this stage, instead we should be focusing more on what could counter us, while leaving the fine details for later stages. Having hard defined counters so early in the process heavily dictates later stages, as certain options cannot even be considered if we want to follow the list, because they would mess with the already dictated counters.
I agree with the sentiment of the above quote from mxmts, the portion I bolded in particular, and I think we need to emphasize this more broadly in every CAP project throughout the creation process, with regards to how Threats should be considered in later stages.

Threats is a hard stage to manage, because we want to add some direction to the CAP process without narrowly constraining the outcome of future steps. It isn't too hard to make a short list of threats that, if adhered to exactly, will almost dictate the exact outcome of future steps.

Confining options in any step is a Big No-No™ in CAP. We need to have plenty of room to discuss multiple viable options with an interesting variety of pros and cons for each option. If we don't have that, then we don't have an interesting discussion, and we don't have an interesting poll. And if it's not interesting, people don't participate. And if people don't participate, we don't really have a community project, which is the entire purpose of Create-A-Pokemon. Remember, the purpose of CAP is not to create a Pokemon. It's to have a fun and interesting community project where we all work together -- and the result of working together is a new Pokemon. As we have been saying forever around here, "It's about the journey, not the destination."

Too often on CAP projects we see people harping on and on about how we aren't following the defined Threats list. And I don't have an issue with us trying to stay on course, when options come up that could whipsaw the project in an unhealthy way. But if following the Threats list requires us to only consider a narrow list of options (sometimes even a single option or NONE at all), then we have gone off course in the worst way possible, not just for that CAP creation, but for the principles of the entire CAP Project.

By increasing the specificity in defining our Threats, I fear we will give even more bias to constrain options in future steps, if we don't do something to prevent it. I'm not opposing the push to improve the Threats discussion. I think the definitions and models discussed here could be a good thing. But we need to somehow remind the community that the Threats list is a list of what we would like to happen or what we are hoping for. It is not a mandate that must be followed strictly.

It is hard to walk that line, and we rely heavily on the TLT and influential discussion participants to navigate the gray area. Let's not somehow let improvements to the Threats discussion lead to an increase in bad behaviors in later steps that are contrary to CAP community principles.
 
I agree that there are situations where we should consider not to follow exactly the threatlist, and people take it way too seriously. However, the current model for this stage goes way too far in the other direction, because there is too much stuff being left at the discretion of the TL, as they can basically choose everything on how the list is, or even if there is one in the first place, as currently there are no guidelines for how this discussion should end.

I don't think that the proposals I made in the OP are capable of completely fixing the problem of people taking the threatlist too seriously, but they should be able to address most of the ambiguities and consistency issues that currently plague this stage, and make the discussion easier to follow for everyone. However, to better address this particular issue, I propose that we add a reminder in the OP that the final threatlist should not be set in stone, and might be altered in later stages if the TLT deems it necessary. This should clarify that the threatlist might be altered later, making this clearer for everybody.

Here's an updated version of the OP that incorporates my proposals.

--Introduction, chosen typing, TL leads discussion--

In this stage, we will try to analyze which Pokemon sets could threaten or be threatened by us. Based on our typing and concept we will also decide which specific threats we should focus on later stages, and which ones should be mostly left alone. Then, the Topic Leader will organize them into a list, following this basic format:
  • Switch in: The list of Pokemon on which we should be able to have a easy time switching in and then forcing them out, more than once in a game. This doesn't mean that we should be able to come into any of their moves, just their most commonly used ones.
  • Pressure: The list of Pokemon that might threaten us, but should not be able to switch in easily. They should not be able to check us easily.
  • Checks and Counters: The list of Pokemon should, in some way, threaten us. This might mean that they will probably be able to beat us 1v1, or at least severely cripple us. Certain Pokemon, in particular Revenge Killers might be included both in here and in Pressure, because once they switch in, they should be able to check us.
This threatlist should serve as a guideline for the rest of the project. However, this is not set in stone, and might change later if the Topic Leadership Team deems it necessary.

The following is a set of questions that we should try to answer during this discussion:
  • Going specifically by typing, what Pokemon found in the CAP metagame will be able to comfortably give this project trouble?
  • What Pokemon will be major threats to this project right off the bat?
  • What Pokemon have the potential to become counters?
  • What Pokemon may end up as threats, but must be contained or dealt with per the concept?
  • Will the concept succeed with this list of threats?
  • Is this list of threats acceptable for the project?
  • What Pokemon will be threatened by the CAP based off of typing?
  • Are these Pokemon targets that we want CAP to hit?
  • Will these targets be "unavoidable" to threaten based solely on the typing?
  • What direction must the project go in now that a set list of basic threats has been identified?
  • What must be done in order to make these threats "wanted counters" or these threats be eliminated from counter discussion?
  • Are there any Pokemon that we want to completely counter?
No individual post has to answer every question.

Guidelines:
1) Pay close attention to the Topic Leader during this discussion. Their job is to keep us focused and to bring insight.​
2) Do not poll jump. Poll jumping is a serious offense in these threads, and you can get infracted for it. Poll jumping is when you discuss something that should be discussed in the future, like specifying a CAP's stats or typing. You're allowed to hint at such things to conclude a point or to provide an example, but do not centralize your post on a poll jump. Poll jumping hurts the focus of early threads and can cause us to go off on a tangent. If you're not sure if a particular argument is poll jumping or not, err on the side of caution and don't post it.​
3) Refer to Pokemon by specific sets. This way we can clearly identify which specific sets we should be focusing on, and what specific characteristics makes us threaten or threatened by them. Adding complete movesets, EV spreads and Natures is recommended, but not mandatory.​
4) Assume that Stealth Rock in on both sides of the field, unless otherwise specified. This can be changed by the Topic Leader during the discussion.​
4) This are the exact definitions of check and counter that we will be working with:​
-Pokémon A checks a Pokémon B set if, when Pokémon A is given a free switch into that Pokémon B set, Pokémon A can win every time, even under the worst case scenario, without factoring in hax.​
-Pokémon A counters a Pokémon B set if Pokémon A can manually switch into that Pokémon B set, and still win every time, even under the worst case scenario, without factoring in hax.​
------------------
CAP X so far:

User said:
Winning Concept
Typing: Selected typing

--TL gets first post in this thread--


I've also made a few small adjustments:
-The fist question assumed that we're building for OU by default; I changed that to CAP, as it was decided that we should focus on that metagame for future projects
-The last question was originally "What Pokemon do we want this project to counter entirely?". I changed it to "Are there any Pokemon that we want to completely counter?", because the original seemed to imply that we need to completely counter at least some mons, which would be almost impossible to do for frailer stat spreads.
-On the guidelines, I changed the examples of poll jumping from "stats or typing" to "abilities or stats", because the typing should be chosen before this discussion starts, so using it as an example seems a bit confusing.

25/6 EDIT: I forgot to add the definition of check and counter, thanks Quanyails for noticing! I've used a simpler definition than what I originally proposed, because after rethinking it, that was unnecessarily specific. The definitions used come from here (All credits for it go to MattL, the writer of that article).

4/7 EDIT: Slightly reworded the checks/counters definition, to make them refer to specific sets instead of Pokemon in general. Once again, thanks Quanyails for the suggestion.

If anyone finds something wrong with this OP, please let me know (If it's something small like a typo just send me a PM or contact me on Discord)
 
Last edited:

Birkal

We have the technology.
is a Top Artistis a Top CAP Contributoris a Top Smogon Media Contributoris a Site Content Manager Alumnusis a Battle Simulator Admin Alumnusis a Senior Staff Member Alumnusis a Community Contributor Alumnus
Does anyone have any issues with mxmts proposed new OP? If not, we'll approve this and make the necessary adjustments.
 

Quanyails

On sabbatical!
is a Top Artist Alumnusis a Community Leader Alumnusis a Community Contributor Alumnus
Full counter: Able to repeatedly switch into the opposing Pokemon against ALL sets and then beat it, even if the opponent predicts correctly every turn.
Hard counter: Able to repeatedly switch into the opposing Pokemon against most sets and then beat it, even if the opponent predicts correctly every turn. There are some sets capable of winning, but they are very specialized and generally outclassed.
Soft Counter: Able to repeatedly switch into the opposing Pokemon against some sets and then beat it, even if the opponent predicts correctly every turn. However other common sets might be able to beat this.
Hard Check: Able to repeatedly switch into most of the opposing Pokemon moves and then beat it, but can be beaten with the right prediction, or by wearing it down through the game.
Soft Check: Able to switch into the opposing mon at least twice in the game with a free switch, and then beat it.
Beat (1v1): Beat the opposing Pokémon after both mons switch on the same turn with 100% HP, no hazards and without a Focus Sash.
Shouldn't this go in the OP? I approve otherwise, and I'd like to see the Threats OP updated before CAP 25 gets there.
 
In my proposed OP, I simplified those definitions in favor of just these two:
-Pokémon A checks Pokémon B if, when Pokémon A is given a free switch into Pokémon B, Pokémon A can win every time, even under the worst case scenario, without factoring in hax.
-Pokémon A counters Pokémon B if Pokémon A can manually switch into Pokémon B and still win every time, even under the worst case scenario, without factoring in hax.
I did this is because I think my initial proposal was way too specific, there is no real reason for why we should need all those definitions when simply defining check and counter would be enough.
 
Status
Not open for further replies.

Users Who Are Viewing This Thread (Users: 1, Guests: 0)

Top