Policy Review Policy Review - Countering

Status
Not open for further replies.

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
If you are not an experienced member of the CAP community, it is strongly recommended that you do not post in this thread.

This thread is intended to contain intelligent discussion and commentary by experienced members of the CAP project regarding CAP policy, process, and rules. As such, the content of this thread will be moderated more strictly than other threads on the forum. The posting rules for Policy Review threads are contained here.
This will be the last of my "Big 6" Policy Reviews (it was originally supposed to be seven, but some recent discussions have led me to put the 7th one on hold). This last one could be the most controversial and difficult to develop a concrete policy revision.


I think we can do more to hone the competitive focus of a given CAP project. The Concept Poll is a bit messy in the beginning, but it has been incredibly successful over the past two CAP's for providing a general compass for the project; preventing discussions from meandering all over the place, which was a huge problem in CAP1-3. But, I think we need to do more in the early phases of the project to point us in a direction that will yield a pokemon with a legitimate competitive role in the metagame.

I suggest we define "Intended Counters" in the early stages of the CAP process.

This would be a new step in CAP process. There would be a discussion thread and two voting threads. The goal would be to decide two things:
1) Which pokemon would the new creation be a counter for
2) Which pokemon would be a counter for the new creation​
The wording on that is a little confusing, but hopefully you understand what I mean. We will be answering the questions, "What does the new pokemon counter?", and "What counters the new pokemon?"

Normally, we don't discuss countering until very late in the process, and we never actually make any concrete decisions as a community. We just kind of hope it works out. But, since different people have different ideas about countering, they are all voting under different assumptions. As such, we frequently get deep in the creation process and realize that we are close to making a pokemon with no counters, and it counters everything else in return! When that happens, we usually "save" the pokemon at the very end in the movepool voting, since countering is heavily influenced by movepool. I don't think these "late game saves" are a good way to run the show. It also unnecessarily heightens the drama in the movepool threads, with never-ending cries of "It's broken!" and other doomsayings.

We had a past Policy Review on "Metagame Role" -- and we decided against it for a variety of reasons that I will not rehash here. But, one of the big reasons was the inability to express role in terms that could be objectively managed in the community creation process. I think defining Counters could provide almost as much competitive focus as Role, and it is MUCH easier for the community to grasp, discuss, and vote.

Almost every pokemon in the metagame is defined by what they counter and what counters them in return. It is arguably the biggest factor in team-building, and it is a common part of any in-depth discussion of an individual pokemon. We need to discuss this on the CAP project, and not as an adjunct to another discussion. It deserves a step all by itself. And if that step is conducted early on, I think it would focus all subsequent steps tremendously -- and that focus would be competitive-based, instead of flavor-based. That would be a big help, IMO.

Let me clear this up right now -- please don't derail this conversation with a bunch of pedantic arguments about "What is the definition of a counter?" I'm sick of hearing the same hackneyed discussion every time someone uses the word "counter".

For the record, I believe the number of "true counters" in the DP metagame are so small, that using the "textbook" definition of counter is basically worthless. I know that many metagame analysts have taken up using the word "check", or "situational counter" to describe a pokemon that can be used as counter in some, but not all, cases.

Call it a "counter", call it a "situational counter", call it a "check", call it whatever you want. But, I think we all know what I'm referring to here. I'm open to other names for the step in the process, if you think the word "counter" is too inviting for the "Let's argue about the definition of a counter" freakshow to commence every time.

Also note that I called the step "Intended Counters". This is because we have no way of knowing whether something is going to counter something or not. All we can do is build a pokemon with the intent to counter or be countered. If we fail to produce a pokemon that actually meets our countering intent -- that's fine. The purpose is to build a pokemon that has a role in the metagame. If we conduct each poll with some specific metagame counters in mind, I think we will be much more likely to produce a competitively viable, but not broken, pokemon.

I do not have a set of specific process guidelines to propose. If this idea is popular with the community, I hope to define the exact process in this thread. But, my general idea is that we would identify a few pokemon in two lists "Is Countered By" and "Is A Counter For" (Better names, please?) I don't think we would make a set number, but it should be small. The goal is not to define an exhaustive counter list. We just want a few "headline counters". I think the step should occur immediately after the typing is decided. Since this is a major indicator of the pokemon's competitive purpose, I think we should get it on the board very early in the process.

As always, I look forward to hearing your feedback on this proposal.
 
I think this is a great idea, as it will give more focus to the project in general. It would be significantly easier to design spreads, movepool and the like (even possibly art since they would know the type of Pokemon it will gear towards) if counters were known earlier in the process. This, to me, would be as much of an extension of a project that the concept poll introduced in CAP4; increasing the focus of the project before jumping right in. This idea has my full support.

Moreso then the what it counters idea, I am strongly for the what counter it idea. This will mean that we will not go into making a totally unbeatable Pokemon. During different parts of the process it seems to me (long time lurker, short time poster) that everyone seems to have a different idea of what they want even if they vote for the same option.

I would post more but there isn't much more to say, I'm all for this idea.
 

eric the espeon

maybe I just misunderstood
is a Forum Moderator Alumnusis a Researcher Alumnusis a Top CAP Contributor Alumnusis a Tiering Contributor Alumnusis a Top Contributor Alumnus
I do not see exactly what this is meant to help, it would influence all of the following aspects in an odd way and people would keep coming out with "we can't give it X because we voted for Y to be a counter" as well as being a pretty complicated poll to run... It seems to me that balancing out how many Pokemon can beat the CaP down is best done throughout the process not in a separate step.

we frequently get deep in the creation process and realize that we are close to making a pokemon with no counters, and it counters everything else in return! When that happens, we usually "save" the pokemon at the very end in the movepool voting, since countering is heavily influenced by movepool.
A Pokemon with no movepool is not overpowering in the least (It is countered by everything and counters nothing), so choosing wisely which moves to give it based on what we have at the time is not a bad way to go IMO.
If we do end up with something that is to strong then we play test it and revise it.


Sorry but I do not think that this would be that useful, and would be really complicated to discuss and poll....
 
This is really a difficult task, and I'm not sure if it can be done well enough so that it doesn't completely dictates the path of the project. But anyway, I have some preliminary ideas about it:

> What it counters should be stated before what counters it: We do know, to a decent degree, the state of the metagame prior to each project, so identifying which pokémon/strategies could use an additional counter should be the easiest (or least difficult) task. Once the intended pokémon to counter are established, the list of pokémon to counter the new creation will be easier to compile, since they should be pretty different from the countered ones: That eliminates the countered ones (obviously), and all the ones that are too similar, whether it be because of stats, typing, or movepool.

> The counters step should be done after the Concept but before the typing. With a concept in mind, it will be clearer which pokémon will it be able to counter better. For example, if our goal is making a special wall, the prime candidates to be countered will be the current most threatening special sweepers, if our goal is to make a priority moves abuser, then its prime target will probably be the best stat-uppers, etc.
 

Bass

Brother in arms
is a Forum Moderator Alumnusis a Top CAP Contributor Alumnus
I strongly support this addition to the process. For starters, I think you make a good point when you mention that defining "intended counters" will not only make sure that the pokemon we create are competitively viable, but also less broken. When Syclant and Revenankth were made, the community couldn't come to a consensus that they were broken until MONTHS after playtesting began (To the point where we had a revision process). However, I somewhat feel that the opposite happened with Pyroak where we were so afraid of creating "another syclant" that we may have (at least in my opinion) not made him good enough (contrary to eric's opinion), which is why it is the least used CAP.

Things improved a little bit when we started using "concepts" as the basis of our creations with Fidgit onwards, where I feel, for the first time we created something that was both, competitively viable, but not broken. But if we are going to add "Intended" counters, then it will be easier to get to this goal. A concept is still a very vague framework to build off of, but knowing what pokemon this thing counters (and what counters it) is much more specific.

My only concern is that we might go a bit too far in this to the point that it may limit creativity (Remember when X-Act submitted "true Garchomp counter" as a concept? People opposed it for this reason). This leaves me to question exactly when in the process will we identify "Intended" counters.
 

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
This is really a difficult task, and I'm not sure if it can be done well enough so that it doesn't completely dictates the path of the project. But anyway, I have some preliminary ideas about it:

> What it counters should be stated before what counters it: We do know, to a decent degree, the state of the metagame prior to each project, so identifying which pokémon/strategies could use an additional counter should be the easiest (or least difficult) task. Once the intended pokémon to counter are established, the list of pokémon to counter the new creation will be easier to compile, since they should be pretty different from the countered ones: That eliminates the countered ones (obviously), and all the ones that are too similar, whether it be because of stats, typing, or movepool.

> The counters step should be done after the Concept but before the typing. With a concept in mind, it will be clearer which pokémon will it be able to counter better. For example, if our goal is making a special wall, the prime candidates to be countered will be the current most threatening special sweepers, if our goal is to make a priority moves abuser, then its prime target will probably be the best stat-uppers, etc.
I agree with both of these suggestions, and the reasoning behind them. In my original proposal, I had not considered the possibility of defining the two counter lists at different times in the project. But, after reading your explanation, it makes a lot of sense.

My only concern is that we might go a bit too far in this to the point that it may limit creativity (Remember when X-Act submitted "true Garchomp counter" as a concept? People opposed it for this reason). This leaves me to question exactly when in the process will we identify "Intended" counters.
I agree if we don't set the right expectation, it could be too severely limiting. But, X-Act's proposal was to make a "true counter" to a pokemon that, up until then, had no counters at all. Such a suggestion almost required an incredibly specific pokemon.

In this proposal, there are two key differences -- we aren't going to try to build "true counters" (see my rant on the definition of a counter in the OP) and there's only one Garchomp. Most OU pokemon have a decent range of countering options. If not, we can discuss it in the countering discussion thread. Countering that requires an excessively specific pokemon design, should be avoided.
 
I disagree with half of this, today's metagame is all about strategy, what something can do, not what something can't do. A lot of Pokemon don't even have 100% counters, like salamence for example, or have counters for certain sets only. Despite his argument, I think Bass made a good last point, in that it could limit creativity, and I'm also afraid of how listing out counter(s) early on could nerf the new creation in the long run. I know CAP tends to be lavish and has thus created agruably broken Pokemon, but I don't think the way to go about preventing that is to make intended counters. I'm also afraid of people picking counters that are already very common OU pokes, like Heatran, Gyarados, Zapdos, etc. I don't think that will push the CAP project forward. However as for listing things it should counter, I suppose I could go for that, but still would it be just for 100% counters or partial counters or specific set counters, seems rather complicated, but if we're trying to design something that specifically is capable of switching in on certain common OU threats, then it could be useful to outline them early on.
 
This seems like a great idea, but I am more supportive of the "what it counters" rather than the "what counters it" because it allows the metagame to be unexpected and we can test our theorymon rather than set something it up to be completely walled by something. It brings a little bit more fun to the playtesting, in my opinion, if we don't have a defined counter.
If we want to design it to counter something in particular, such as a CaP gone broken or a Pokemon that is overcentralizing the metagame, such as Skymin, Scarftran or Zapdos, but only to bring it down to mortality, not to render it useless. This is what I think the next step should be for the CaP project.
 
Im fine with taking counter both ways in consideration when making decisions during parts of the CaP process but like others have said Im worried that creating a specific step based around it is really going to restrict creativity in ever step after it.

Im also worried that it will not only drag out the CaP process by adding another step, but also dragging down design conversations in other threads with arguments like, "It has to be this type if it wants any chance to counter X" or "It cant have that move or ability cause the only pokemon X,Y and Z can counter it as opposed to A,B,C"

In short Im really worried that this step would effectivly railroad the rest of the project when I feel concept focuses it enough while still allowing creative flexibility.
 
Gorm pmed me what he was going to post here so here is his post.

gormenghast said:
First off I'd move for use of "check" simply because it's not as restricitve as the paper definiton of "counter" which restricts typing/movepool pretty severely

First thing we need is a good definition of check


In what way could a pokemon serve as a check for another?

1. Being Neutral or better to their stab attacks/common moves with defenses to back it up (Blissey checks most special attackers bar specsluke/gar, just as gliscor checks most fighting types (lacking ice punch))

2. Being Faster with the ability to OHKO first, or 2hko without the threat of an ohko back (salamence checks

3. Stop their strategy in general (Leech Celebi checks almost all blisseys (bar cm), this is to account for the "non offensive" checks)

Like i mentioned in the other thread, what doug is talking about is pretty much as metagame specific as we can make a pokemon project. There are other factors that decide on a pokemon's niche but what it keeps in check and what keeps it in check is probably one of the most important ones.

eg in the current Pt metagame (I'm not qualified to talk about CaP) Heatran/Zapdos/Scizor used together are rather difficult to bring to a halt, as each of them defeat the majority of the checks for the others. exceptions exist but the 3 remain a gigantic force in OU, and therefor what some might call a "small" unbalance in the metagame. Were there a pokemon that could keep in check a good deal of top threats in any metagame, it's going to have success.

What parts of the CAP process does "keeping a pokemon in check touch"? Pretty much all of them. If people want to do it early on, it severely restricts where we can go further on in the project and i like the attitude of cap that "the journey is just as important as the project".


Basically if this is the last of the PR threads i might as well lay it out; I don't think that this kind of mindset (specifying checks early on) is especially beneficial for CaP, but it is almost always specified early on in EVO's "process" (aka what many of us have agreed on so far for the next EVO project).

In evo, the moment we choose on an evo/niche (the proposed 1st step), the parameters 1. and 2. in the OP are also pretty much laid out for the entire project (as a bonus, the artists already have a concept to build on and are pretty much at liberty to produce quality work from the very beginning of the project!)

I really hope I'm not out of line here but EVO is a pretty exciting thing for me and I don't think it's just going to disappear. I think making EVO more competitively minded than CAP is completely reasonable given that we have less to make in EVO and can conentrate more on the metagame effects early on.
 

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
This proposal is for the regular CAP process. Evo is not up for discussion here.

I'm fine with using the term "Check", if most people think it is less restrictive. I'm also fine with Gorm's definitions for "Check", as a starting point. And although I ranted about hating "Definition of a counter" arguments -- that did not mean it can't be discussed. I just don't want it to turn into the long pedantic argument that seems to always erupt. Ultimately we WILL need a definition of the terms we use, if we decide to do something with this proposal.

But, I hope this thread is more about the overall impact and process of the proposal -- and whether this would be a good thing for the CAP project.
 

X-Act

np: Biffy Clyro - Shock Shock
is a Site Content Manager Alumnusis a Programmer Alumnusis a Smogon Discord Contributor Alumnusis a Top Researcher Alumnusis a Top CAP Contributor Alumnusis a Top Tiering Contributor Alumnusis a Top Contributor Alumnusis a Smogon Media Contributor Alumnusis an Administrator Alumnus
This proposal will greatly influence the base stats, typing and movepool of a Pokemon, and ability to a lesser extent.

To counter a Pokemon, you need the necessary defensive stats and typing to switch in, and the necessary attacking stats and move to attack it. Sometimes a favourable ability also helps (for example, Thick Fat lowers Ice and Fire damage so it helps you switching into those kind of attacks).

While I agree on this proposal on paper, I'm concerned that it might make the CAP process extremely rigid.

Movepools would be basically the same and there might not even be needed a poll to decide it. This already happened in CAP5 to a degree... people naturally created movepools that catered for what was discussed in the movepool thread.

Base stats would also be a lot more similar since if you need something that counters a physical attacker, everyone would have a Pokemon with high physical tankiness. Again this is something that is already happening to a lesser degree due to my applet; if 'balanced' is voted for, you can't go for something offensive or defensive.

Typing would also become a lot more rigid to choose from; if you need something that counters a Pokemon using a frequent Ground attack, you'll need either something that isn't supereffective to Ground or vote for Levitate.

Basically we'll end up with not needing any polls at all to decide a Pokemon. Maybe this is actually a good thing, though... so it depends on what people want, ultimately.
 
Actually I'm against any use of checks for either if we decide to use either. Most OU pokemon have a good deal of checks and serve as checks for a good deal of other pokemon. Determining checks isn't really going to help in any way imo, even though I think it's a term that should be used in discussion alot, but having a step for them is just going to be complicating things and isn't going to help much.
 
I think that "intended counters" should be incorporated into a bigger discussion thread called "Concept Exploration" after the concept poll has been concluded.

In "Concept exploration", we would outline the niche/competitive focus of said concept, including what does it check and counter and vice versa, as well as what basic attacks/ability would it need to perform its role and what the nature of the pokemon will be (bulky, frail etc). This will help us form a good idea of the pokemon we want to create, although I would be hesitant to make an official poll as we wouldn't want voting to be restricted from such an early stage but it would be good to have the community to be on the same wavelength as we were with Fidgit.

Concept submissions are vague and I think something like this is needed. For example Fidgit's concept was "all-round team support pokemon" but that does not exactly tell us what it would do exactly. "Concept exploration" would hopefully create a steady but flexible path to creating the new pokemon. In the case of Fidgit an example post would be all round team supporter "able to use 3 kinds of entry hazards and rapid spin/absorb Tspikes as well as use rarely seen strategies such as TR and Tailwind effectively and check Revenankh, Lucario and Garchomp in particular"

I would also suggest that we have a concept evaluation thread after movepool to check that we haven't eliminated too many counters like imo happened in CAP5 since strata beats has a lot of competitively viable attacks that hit would be counters for SE like Air Cutter for Rev and Energy Ball for Swampert etc. Only Blissey can really counter it full.
 
I think that "intended counters" should be incorporated into a bigger discussion thread called "Concept Exploration" after the concept poll has been concluded.

In "Concept exploration", we would outline the niche/competitive focus of said concept, including what does it check and counter and vice versa, as well as what basic attacks/ability would it need to perform its role and what the nature of the pokemon will be (bulky, frail etc). This will help us form a good idea of the pokemon we want to create, although I would be hesitant to make an official poll as we wouldn't want voting to be restricted from such an early stage but it would be good to have the community to be on the same wavelength as we were with Fidgit.

I think this sort of traits can be decided along with the canonic polls. The Stat spread poll is there to let us decide whether the CAP should be bulky or Frail, physical or special biased etc. Deciding this before would deprive this poll of the variety it needs.

Concept submissions are vague and I think something like this is needed. For example Fidgit's concept was "all-round team support pokemon" but that does not exactly tell us what it would do exactly. "Concept exploration" would hopefully create a steady but flexible path to creating the new pokemon. In the case of Fidgit an example post would be all round team supporter "able to use 3 kinds of entry hazards and rapid spin/absorb Tspikes as well as use rarely seen strategies such as TR and Tailwind effectively and check Revenankh, Lucario and Garchomp in particular"

The same concept I applied above can also be applied here. Typing and movepool polls are there to let us decide such things. We want this thing to know all 3 entry hazards? We want this thing to know Wish? We can discuss it in the movepool thread. And about the checks, you cant foresee clearly what can and cannot counter said CAP, but I'll discuss below

I would also suggest that we have a concept evaluation thread after movepool to check that we haven't eliminated too many counters like imo happened in CAP5 since strata beats has a lot of competitively viable attacks that hit would be counters for SE like Air Cutter for Rev and Energy Ball for Swampert etc. Only Blissey can really counter it full.

It is not the SE "thing" which can tell you whether or not something counter something else. For example, unless Stratagem is behind a substitute or has 3+ CM under its belt (im assuming Timid), standard Revenankh is not OHKOed even by Tech HP flying and OHKOes back with Hammer Arm, while Blissey is much less reliable since, if Stratagem has Tech with CM/Sub/Giga Drain/AP it can set up on Blissey with impunity and knock her out. Was this clear before playtesting? No. Indeed, I remember people whine about Tech being useless on Strata.
The point is that, about counters, you really cant know what exactly you can and cannot counter until you effectively playtest it. Deciding it before severely limit us and can force us to make a worse CAP.
 
All Sub/CM Strategem lose to Seismic Toss Blissey. That is clear and was clear before playtesting.

Revenankh is 2HKOed by Technicianed HP Flying and is OHKOed by a +1 Life Orb HP Flying.

508 Atk vs 300 Def & 384 HP (90 base power): 428 - 506 (111.46% - 131.77%) | Multipliers: 1.3 * 2 * 1.5

Anyone who did a damage calc would then see that Revenakh is not strong counter.

And the problem is before making it to the movepool/typing threads to make the decision is that we will end up making a completely different pokemon to what was expected. Look at Pyroak, people chose Fire/Grass wanting a Chlorophyll sweeper and ended up with a bulky pokemon/annoyer. Fire/Grass is not a very good defensive typing but a fantastic offensive one. People would probably not have voted for the Fire/Grass typing in all likelihood if they thought it would end up as a bulky pokemon. I want to avoid anything such happening again so that we have a flexible but unknown and clear idea of what our end product will be in the early stages of the project.
 
Sub/CM and Sub/Cm/Giga Drain are 2 different things, and Revenankh can come on Stratagem and force it out, maybe even Bulking Up on the switch, so it is more than a reliable answer, but I dont want to get offtopic.

And about your Pyroak example, the way the spread has been decided was very different from now. People realized too late that they almost forced themselves to create a bulky, slow pokemon that does not really suit its type. Now, since we dont decide Off/Def/Bal and such things but only the rating and then the stat spread itself, we have far less room for such mistakes. If, for example, we make a Ghost/Steel pokemon, we all realize this thing would really like a defensive biased spread, while a Rock/Ice pokemon is best used as a sweeper rather than a defensive tank. The system as improved a lot since CAP3, and is more than able to adapt to such issues. Fidgit and Stratagem have shown it very well. Most people fully realized that a Poison/Ground type is best used defensively (maybe Nidos example helped us) and that a pure Rock pokemon have too many weakness but a fantastic STAB and therefore its best suited to sweep.
We dont need to add steps to the project when the existing ones are more than enough. We would only slow down a process we want to spped up

EDIT: I pretty much agree with what X-Act said about Pyroak
 

X-Act

np: Biffy Clyro - Shock Shock
is a Site Content Manager Alumnusis a Programmer Alumnusis a Smogon Discord Contributor Alumnusis a Top Researcher Alumnusis a Top CAP Contributor Alumnusis a Top Tiering Contributor Alumnusis a Top Contributor Alumnusis a Smogon Media Contributor Alumnusis an Administrator Alumnus
The reason why Pyroak ended up defensive is because the definition of 'balanced' was incorrect at that time. Pyroak was actually voted to be balanced, but an incorrect definition of 'balanced' was applied to its stats and it ended up being defensive. This spurred me to speed up my BSR applet and making a correct definition of 'balanced'. By contrast, Fidgit and Stratagem's base stats ended up being exactly as we wanted them to be because BSR helped their creation.
 
Sub/CM and Sub/Cm/Giga Drain are 2 different things, and Revenankh can come on Stratagem and force it out, maybe even Bulking Up on the switch, so it is more than a reliable answer, but I dont want to get offtopic.

And about your Pyroak example, the way the spread has been decided was very different from now. People realized too late that they almost forced themselves to create a bulky, slow pokemon that does not really suit its type. Now, since we dont decide Off/Def/Bal and such things but only the rating and then the stat spread itself, we have far less room for such mistakes. If, for example, we make a Ghost/Steel pokemon, we all realize this thing would really like a defensive biased spread, while a Rock/Ice pokemon is best used as a sweeper rather than a defensive tank. The system as improved a lot since CAP3, and is more than able to adapt to such issues. Fidgit and Stratagem have shown it very well. Most people fully realized that a Poison/Ground type is best used defensively (maybe Nidos example helped us) and that a pure Rock pokemon have too many weakness but a fantastic STAB and therefore its best suited to sweep.
We dont need to add steps to the project when the existing ones are more than enough. We would only slow down a process we want to spped up

EDIT: I pretty much agree with what X-Act said about Pyroak
Which is why a concept exploration topic would be useful. From early on we need a good idea of what type of pokemon we are going to produce.

What you have said after that is irrelevant because ideally the concept exploration would come immediately after the concept poll so we don't have a vague mish-mash of ideas. We should have a good but I have stressed the word FLEXIBLE understanding of what we want to make so we can choose the typing / ability / movepool without taking a stab in the dark and proceeding from there which is like the current process where we choose a vague concept and just have a guess at what type we should use.
 
Which is why a concept exploration topic would be useful. From early on we need a good idea of what type of pokemon we are going to produce.

What you have said after that is irrelevant because ideally the concept exploration would come immediately after the concept poll so we don't have a vague mish-mash of ideas. We should have a good but I have stressed the word FLEXIBLE understanding of what we want to make so we can choose the typing / ability / movepool without taking a stab in the dark and proceeding from there which is like the current process where we choose a vague concept and just have a guess at what type we should use.
First of all you are writing as if we still use the same method for choosing the stat spread we followed with Pyroak, which is false.
Moreover, my concern is not about depriving existing steps of their variety - which is however a risk in my opinion - but rather is the useless delay your idea would introduce in the process. When we decide the type, we already know what that type combination is good to. And when we discuss submitted spreads, we will be able to discuss whether the pokemon should be a sweeper or a tank, bulky or frail, slow or fast... we dont need to add useless steps to discuss things we already have the time to in the existing process
 
I really don't think that this is needed. A lot of the discussion pertaining to keeping counters happens during the move pool section and is the main reason why most moves that are not put on the pokemon are left off.
 
A lot of the discussion pertaining to keeping counters happens during the move pool section and is the main reason why most moves that are not put on the Pokemon are left off.
This may be true, but everyone have different ideas on what Pokemon(s) they want to counter/check each ongoing CAP. Those type of discussions seem like a total messes to me and the fact he haven't made anything that is believed to be broken is still a miracle. Having a separate discussion about what a certain created Pokemon counter/checks and what counter/checks it seem a lot more beneficial and less cluttered than what we were doing before.
 

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
In the current process, we really don't start talking about counters until the movepool threads. However, in those threads, everyone is voting under the assumption of different counters. Perhaps we could discuss counters immediately before the movepool steps? That would get everyone on the same page, and perhaps make the movepool discussions a bit more focused. So instead of this proposal being a sweeping change at the beginning of the project, it's just a refinement of the movepool process, where counters are currently discussed anyway.
 
First of all you are writing as if we still use the same method for choosing the stat spread we followed with Pyroak, which is false.
I did not mention the stat spread process at all, read my post.

Moreover, my concern is not about depriving existing steps of their variety - which is however a risk in my opinion - but rather is the useless delay your idea would introduce in the process.
Did you read my original post or read any of my other posts? I have used the word FLEXIBLE deliberately, we aren't creating the bloody pokemon but more exploring what is already a deliberately vague concept.

How the hell can you call what is a 2/3 day delay maximum useless when it would better the output. You can't take a vague concept and just then launch into the typing polls with no real idea of what we want to achieve.

When we decide the type, we already know what that type combination is good to. And when we discuss submitted spreads, we will be able to discuss whether the pokemon should be a sweeper or a tank, bulky or frail, slow or fast... we dont need to add useless steps to discuss things we already have the time to in the existing process
It annoys me when I read because you haven't understood what I have been saying. The typing, ability and stat spreads are intrinsically linked to the concept and to each other. We don't want the stat distribution to be a poor use of the pokemon's typing or ability. As such it makes sense to have a discussion beforehand so we don't end up with essentially a mish-mash of ideas.

When you are presented a vague concept of "team support" or "break the mold" there is no sense of community direction. When the typing poll follows how is the typing going to be any way representative of the concept if we don't sit down and think about what we want this pokemon to achieve.
 
In the current process, we really don't start talking about counters until the movepool threads. However, in those threads, everyone is voting under the assumption of different counters. Perhaps we could discuss counters immediately before the movepool steps? That would get everyone on the same page, and perhaps make the movepool discussions a bit more focused. So instead of this proposal being a sweeping change at the beginning of the project, it's just a refinement of the movepool process, where counters are currently discussed anyway.
This is basically what I was going to say.

The community already decides on unofficial counters as early as the Base Stat thread. We're just going to make this an official process so everyone is on the same page as to what counters what.
 
Status
Not open for further replies.

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

Top