CAP 30 - Part 1 - Concept Assessment

[StarFalcon555]

If we ultimately decide to go the Primary Ability => Typing => Primary Ability route, which form should we focus on first, 30b or 30i?

I already touched on this in my previous post, but I think we should focus on 30i's ability first. This is for one big reason: its item. A x1.2 STAB boost is HUGE, and if paired with certain abilities, could potentially be extremely broken. Doing 30i's ability first will help it ensure that it is balanced.

The framework only mandates one typing be shared between the forms, at least from my understanding. Given any possible ordering of stages, how would we need to account for this?

I really don't want to offend you Wulfanator, but I think that you're interpreting the wording in the framework incorrectly here. The framework said that CAP 30b and 30i "will share a typing and a movepool", which to me implies that both of their types have to be the same. If only one typing had to be shared, I think Pipotchi would have worded it as "these Pokemon will share at least one type and a movepool". Then again, Pipotchi is really the only one who knows the exact wording, so I tagged her here so she can clarify. :)

Even if only one typing did need to be shared, I think it would be better to have both of their types be the same anyways. Like flying moose said, we would have to go Ability -> Typing -> Ability -> Typing if that was the case, and that would end up being wayyyy too convoluted. It would be much simpler for 30b and 30i to have the same typing.

 

[quziel]

I wonder about the efficacy of just allowing free-for-all ability submissions and then deciding which forme the ability fits post-facto. This would create a bit of chaos, and perhaps result in a slightly less optimal cap, but would give us a lot more design space.

Edit: I suppose I should clarify that by free-for-all I mean submitting for either forme, rather than like any ability.

 

[Explosion Badger]

If we ultimately decide to go the Primary Ability => Typing => Primary Ability route, which form should we focus on first, 30b or 30i?

The framework only mandates one typing be shared between the forms, at least from my understanding. Given any possible ordering of stages, how would we need to account for this?

1) I feel like 30i should be focused on first. People have brought up 30i's item disadvantage, but I feel like it's important to note that 30i's item also boosts its STABs, meaning that typing is more important to it than to 30b. While it wouldn't necessarily be to hard to consider 30i when coming up with 30b's type, I feel that 30i should be considered foremost so that its type and ability match well with its item.

2) I don't think we should change types at all between forms. All it would accomplish is confusing the layout of the process more than it already is.

 

[StarFalcon555]

I wonder about the efficacy of just allowing free-for-all ability submissions and then deciding which forme the ability fits post-facto. This would create a bit of chaos, and perhaps result in a slightly less optimal cap, but would give us a lot more design space.

No offense, but this is a really bad idea. It seems really unfiltered and could be easily abused by other participants. I can easily see someone submitting something completely broken like Intrepid Sword and being like "iT's oNlY aVAiLaBlE oN oNe pOKeMoN sO iT cAn bE cOnSIdErEd uNoPTiMizEd". It would be much better for us to make a list of abilities that could be seen as needing optimization (which flying moose already did/is doing) and go from there.

 

[Da Pizza Man]

No offense, but this is a really bad idea. It seems really unfiltered and could be easily abused by other participants. I can easily see someone submitting something completely broken like Intrepid Sword and being like "iT's oNlY aVAiLaBlE oN oNe pOKeMoN sO iT cAn bE cOnSIdErEd uNoPTiMizEd". It would be much better for us to make a list of abilities that could be seen as needing optimization (which flying moose already did/is doing) and go from there.

To be honest, that's a non-issue. An obviously broken ability is likely not going to get much traction to begin with, and even if it somehow does, either Wulf or Tadasuke are going to be fairly likely to shoot it down before it takes up too much of the thread. Creating a list of abilities ahead of time just constrains us for really no good reason. People should absolutely be able to make cases as to why they think a certain ability isn't optimized right now but can be made optimizied, and not just be given a list and told "Here is a bunch of abilities the Topic Leader and the Ability Leader think are unoptimized and are the only ones worth considering, start debating which one you guys like the most. Is the ability you were hoping to discuss not on this list? Tough Shit".

 

[Earthflax]

If we ultimately decide to go the Primary Ability => Typing => Primary Ability route, which form should we focus on first, 30b or 30i?

30i and the 1.2x STAB boost it gets should be accounted for first. If we lock into an ability optimal for 30b, and pick a typing that complements it, that could heavily limit 30i due to the unKnockable boost to its STABs that it gets. IMO if it were the other way around it wouldn't limit 30b as much.

The framework only mandates one typing be shared between the forms, at least from my understanding. Given any possible ordering of stages, how would we need to account for this?

I think the most simple solution would be Primary Ability -> Typing 1 -> Primary Ability -> Typing 2 (with the obvious restraint that the typings discussed/submitted have to share 1 type with Typing 1's outcome. It's not really an exceptional idea, but my brain isn't working rn and this sounds like it would work just fine.

No offense, but this is a really bad idea. It seems really unfiltered and could be easily abused by other participants. I can easily see someone submitting something completely broken like Intrepid Sword and being like "iT's oNlY aVAiLaBlE oN oNe pOKeMoN sO iT cAn bE cOnSIdErEd uNoPTiMizEd". It would be much better for us to make a list of abilities that could be seen as needing optimization (which flying moose already did/is doing) and go from there.

I think leaving the field open for at the very least a few days is better so people can make their cases. Wholly unrealistic submissions, like DPM said above, will likely be dismissed relatively quickly, and this allows us to explore in all directions as opposed to looking at a list and discussing those like they're talking points.

 

[Wulfanator]

I wanted to clarify the reasoning for the question pertaining to typing since I have already received messages both public and private regarding my interpretation of our framework. The only information we have pertaining to our typing is the line "The mons, like Giratina, will share a typing, and movepool" which is the first listed restriction. The framework submission op said that

"This framework should not impose an undue burden upon the CAP creation process. Any framework should not require a substantial amount of effort and time beyond that of a standard CAP. It may include a maximum of 2 Pokemon/forms, which should share at least 1 of the exact same typing combinations, set of abilities, statlines, and full movepools, and among the remaining 3 stages, at least 2 should have heavy similarities (eg at least one shared typing, at least one shared ability, etc). If the Pokemon/forms share 2 or more stages completely, there is no requirement for the non-shared stages to be similar."

Using the literal interpretation of "share a typing" and the rules from the framework submission op, "share a typing" would equate to "share one single typing." I do not like the idea of sharing only half our typing, but it is allowed since movepool is clearly identical between forms

 

[StarFalcon555]

Creating a list of abilities ahead of time just constrains us for really no good reason. People should absolutely be able to make cases as to why they think a certain ability isn't optimized right now but can be made optimizied, and not just be given a list and told "Here is a bunch of abilities the Topic Leader and the Ability Leader think are unoptimized and are the only ones worth considering, start debating which one you guys like the most. Is the ability you were hoping to discuss not on this list? Tough Shit".

I just realized that I messed up my wording on the list part. What I meant was that we should make categories of abilities that could be optimized (flying moose has already started doing this) and then people could submit and make their arguments as to why their ability could fit into a certain category. I'll make sure to word things better next time.

Edit: I suppose I should clarify that by free-for-all I mean submitting for either forme, rather than like any ability.

This makes a lot more sense than what I originally assumed, and I'm not opposed to this. I do feel, however, that this would only work if we choose each form's role before we choose the ability. If we do go ability before role, how are we supposed to decide what form fits the ability best? It would be like a coin flip.

...unless the coin flip aspect was what you were going for, in which case it would spice up the process a bit...

I wanted to clarify the question pertaining to typing since I have already received messages both public and private regarding my interpretation of our framework. The only information we have pertaining to our typing is the line "The mons, like Giratina, will share a typing, and movepool" which is the first listed restriction. The framework submission op said that

"This framework should not impose an undue burden upon the CAP creation process. Any framework should not require a substantial amount of effort and time beyond that of a standard CAP. It may include a maximum of 2 Pokemon/forms, which should share at least 1 of the exact same typing combinations, set of abilities, statlines, and full movepools, and among the remaining 3 stages, at least 2 should have heavy similarities (eg at least one shared typing, at least one shared ability, etc). If the Pokemon/forms share 2 or more stages completely, there is no requirement for the non-shared stages to be similar."

Using the literal interpretation of "share a typing" and the rules from the framework submission op, "share a typing" would equate to "share one single typing." I do not like the idea of sharing only half our typing, but it is allowed since movepool is clearly identical between forms

With this in mind I can definetely see the argument for the forms maybe only being allowed to share one type. I really think it would make the process more difficult if only one type was shared, but I can see the ideation for it. It would be great if Pipotchi could clarify what she meant soon so that we can solve this question :)

 

[Astra]

Echoing what's already been said here, I think it would be best to choose the ability for CAP30i first. While choosing the ability for CAP30 (or I guess CAP30b now) would have much more freedom, beginning with CAP30i's ability first would allow us to build around its item with a higher degree of freedom. For example, if we want to establish that CAP30i should be able to take advantage of the x1.2 damage boost to its STAB moves thanks to its item, not only would we be able to choose an ability to complement it, but we would also be able to choose a typing for it as well while still having CAP30b in mind. In contrast, choosing CAP30b's ability first does give us a lot more freedom, but we would need to always keep CAP30i in the back of our mind, as we wouldn't want to screw CAP30i over by giving it a typing that can't really take advantage of an extra x1.2 damage boost to its STAB moves as well as the neat quirks they may come thanks to its nonremovable item.

Edit: This was written assuming that both formes would definitely going to share both typings instead of just one, and I personally believe that the framework was meant to be written that way and that the process would be more interesting if both formes shared both typings.

 

[Mova]

I'm here to agree with choosing 30i's ability first, then typing, and finally 30b's ability. This is under the impression that there is no secondary ability, correct? Either way, I also agree that both forms should share the full typing, rather than give a different partial typing to either. It would be easier and more interesting to see what kind of typing can take advantage of 30i's extra x1.2 STAB boost.

 

[snake]

The framework only mandates one typing be shared between the forms, at least from my understanding. Given any possible ordering of stages, how would we need to account for this?

While I see how the framework wording is ambiguous, it first says “The mons, like Giratina, will share a typing, and movepool.” In my reading of this statement, I emphasize “like Giratina.” This statement is detailing what aspects of the two formes must be the same. The two actual Giratina forms share both Ghost and Dragon typing, as well as movepool.

Then, in two following bullet points, the framework reads off:

-The abilities can be completely different between forms.
-The stats can be different between forms, while maintaining the same base total. Note that this does not need to swap offenses and defenses like Giratina's forms, though this is not to exclude that option either. The way that stats differ between these two mons should be decided at the stats stage.

The framework then goes into specific details on the differences between the two forms’ abilities and stats. If the typings could be different, surely it would be detailed as such, just as these two bullets do for abilities and stats.

I would find it confusing if a potential difference in typing a) was not explained as thoroughly as abilities and stats, b) was included in the same statement that explains that movepool must be the same between both forms, and c) was prefaced with “like Giratina,” which has forms that share the same entire typing.

Thus, I believe that the framework intends to keep both typings the same between both forms, and “share a typing” is just poor wording choice.

 

[Astra]

I also want to add that choosing the ability for CAP30i first based on its item would mean that our freedom would be less, but it'll still be free enough for us to get really creative. In other words, if we wanted to establish some restrictions, we don't need to do it through locking each forme into a certain role; instead, we'll use the restrictions that's already given to it, which, in this case, is the item required for CAP30i.

 

[shnowshner]

If we ultimately decide to go the Primary Ability => Typing => Primary Ability route, which form should we focus on first, 30b or 30i?

30i is definitely the more constrained of the two forms, so we should definitely prioritize it first as 30b will have much more room to work with thanks to having access to items. There's not much else to say.

The framework only mandates one typing be shared between the forms, at least from my understanding. Given any possible ordering of stages, how would we need to account for this?

Right, so this is the controversial part.

The use of "typing" to me implies the whole instead of the parts. If it were simply "type," that would be a lot more ambiguous.

The wording of our framework, however, is the biggest reason this seems like a stretch. When it says, " The mons, like Giratina, will share a typing," that implies that the makeup of our two forms will mimic that of Giratina. Since both of its forms have the Ghost/Dragon typing, and we are not supposed to go beyond the restrictions of our framework, that implies our two forms must have the exact same typing. To have them only share one type doesn't make them like Giratina's forms, but something else entirely.

This makes it a bit hard to answer your question directly, as we wouldn't need to account for something we end up avoiding anyhow. So what if we did decide to go such a route, despite what discussion suggests, if more support comes in?

Right now I think the best route for the beginning of the process looks something like this:

Discuss "unoptimized" Abilities -> Choose 30i's Ability -> Choose 30i's Typing -> Discuss "unoptimized" Abilities suited to given Typing -> Choose 30b's Ability

Should we only require one shared typing, this adds a few new sections:

Discuss "unoptimized" Abilities -> Choose 30i's Ability -> Choose 30i's Typing -> Discuss, if possible, which part of 30i's Typing is shared -> Discuss "unoptimized" Abilities suited to given Typing -> Choose 30b's Ability -> Finalize Typing

Two new sections were added. The first has us decide what is shared between forms of our typing. Obviously, if we have only one type, this is easy, but a dual-typing would be more complicated. If we had a Water/Ground typing, for example, what would be shared? Would it be only Water, only Ground, or both? The second stage has us complete the typing of 30b. From my understanding of Wulfanator's understanding, there's nothing saying that both forms must be dual-typed, and that in turn means even if we had a mono-Water typing, we could still give 30b a secondary typing, as all that's required is one shared type.

If any of that sounded arbitrary, out-of-touch with the concept, or just confusing, then it's probably not worth the hassle and we should just stick to both forms having the exact same typing. It's what I expected going forward and what I imagine most people did as well. Semantics are definitely an issue here and I'm glad we're getting this out of the way now instead of later; I certainly had never considered how our framework wasn't as explicit as we may have intuitively thought.

 

[Amamama]

The framework only mandates one typing be shared between the forms, at least from my understanding. Given any possible ordering of stages, how would we need to account for this?

I want to echo shnowshner here, that the confusion regarding the types of CAP 30 probably comes from semantics. I agree, with shnowshner that „typing“ would refer to the combination of „types“ and thus the framework would imply, that the forms have to share both of their types/the whole typing.

If we ultimately decide to go the Primary Ability => Typing => Primary Ability route, which form should we focus on first, 30b or 30i?

I think that focusing on 30i first has merit, as it is the already more restricted form and we want our ability choice for it to be as free as possible. The same is true for typing, as we have to consider the knock off interaction, not being able to chose another item and the stab boost the item provides.
That said, I think Quziel makes a fair point in the quoted below post, about not assigning the first ability, until we have chosen it, as that would leave the first ability discussion entirely free of any limiting factors.

I wonder about the efficacy of just allowing free-for-all ability submissions and then deciding which forme the ability fits post-facto. This would create a bit of chaos, and perhaps result in a slightly less optimal cap, but would give us a lot more design space.

Edit: I suppose I should clarify that by free-for-all I mean submitting for either forme, rather than like any ability.

No offense, but this is a really bad idea. It seems really unfiltered and could be easily abused by other participants. I can easily see someone submitting something completely broken like Intrepid Sword and being like "iT's oNlY aVAiLaBlE oN oNe pOKeMoN sO iT cAn bE cOnSIdErEd uNoPTiMizEd". It would be much better for us to make a list of abilities that could be seen as needing optimization (which flying moose already did/is doing) and go from there.

I don’t think, we have to worry about this, because I think we will or should have a step during ability discussion, where we weed out ambiguous abilities, that don’t really fit the requirements of the Concept, only technically do so or don’t hold enough depth to make for an interesting process.

 

[Brian Geniouse]

Pitching in my 2 cents on a handful of points

Both forms’ primary abilities should be chosen before typing. Choosing typing after only one ability has been decided tautologically results in typing being warped around the first form, and the second form having to play catch-up. ie, it immediately results in one being more “optimized” than the other. This, in my mind, completely defeats the point.
Choosing a type only after both forms have their abilities decided constrains the type stage, yes, but it does so by forcing us to choose it with both forms in mind, which is what we should be doing anyway.

Beyond that, my opinions aren’t as strong. I agree with the general consensus that abilities should be chosen before roles. Finding a role that best utilizes the decided ability falls much more in line with the spirit of “optimization” than trying to shoehorn an ability into an arbitrarily-decided role.
I particularly like MrDollSteak’s suggestion, of “blindly” voting on a first ability, then doing a Concept Assesment 2 to decide on what roles it suits and which form it belongs on, and using that information to guide us during the second form’s ability phase.

TLDR, afaict the ideal order of operations would be:

1. Primary Ability A
2. Concept Assessment 2
3. Decide whether Ability A goes on 30b or 30i.
4. Primary Ability B
5. Typing

On the topic of shared typing: I agree completely with snake_rattler. Given that we’re modeling after Giratina, whose typing is identical in both forms, there is no reason whatsoever 30’s two forms should have different typings. Any ambiguity that suggests otherwise is merely the result of poor word choice.


On the topic of what kind of ability is eligible for optimization, I agree with quziel, in that both gen7 and gen8 OU should operate as blacklists. We already know what OU-viable Contrary, Scrappy, etc looks like. There’s no use pretending we don’t just because it doesn’t happen to exist right this very moment.
I’d go even further to include mons that aren’t OU by usage but are clearly still viable (thinking in particular of Adaptability on Crawdaunt). Again, there’s no point in pretending we don’t know what these abilities look like when used viably.


On what “optimization” exactly means in the context of CAP 30 (or, more generally, how we should approach building around the ability): putting aside the obvious and uncontroversial definitions (“competitively viable” and “actually uses the ability”), I think there’s another layer, of “optimizing for interesting decisionmaking” over merely optimizing for power.

• Magnezone is a fun user of Magnet Pull specifically because it can’t take out all Steel-types for free. That it can lose the 1v1s it forces makes it much more fun to play, both with and against. Magnet Pull on Heatran would just be obnoxious.
  • IMO, Magnezone is exactly the kind of ability optimization we should aim to achieve.
• Ice Scales is clearly meant to enable Frosmoth’s horrid defensive typing. Bug/Ice offers basically zero defensive utility, but Ice Scales allowing it to stay in on or switch into things it otherwise couldn’t, without just negating its matchup spread.
  • However, Frosmoth’s movepool is so bad that it’s usually walled by the things it was aready weak to, so in practice Ice Scales barely changes the dynamic.
  • Separately, I think most would agree with: that Frosmoth could realistically survive Volcarona’s Flamethrower is exciting in a way, say, Ice Scales Blissey or Kartana wouldn’t be.
• Coalossal’s Rock/Fire typing alongside Steam Engine means there are scenarios where it can benefit from taking a super-effective hit. It adds an element of risk-vs-reward that’d be completely absent if it were, say, Water/Dragon.
  • However, Coalossal dumps so many points into the bulk needed to survive Water moves that it has no points left to invest in attack, so it doesn’t benefit much from the speed. Splitting its stats further between both mixed offenses and defenses certainly didn’t help.

 

[Amamama]

Choosing a type only after both forms have their abilities decided constrains the type stage, yes, but it does so by forcing us to choose it with both forms in mind, which is what we should be doing anyway.

The issue is, if the constrains on the typing stage are such, that it is impossible for us to find a typing, that is optimal for both abilities, we would have to compromise the optimization of one or both types. Obviously this is not guaranteed to happen and we might have an easy time finding a fitting typing.
But we can’t control the outcome of the ability stages, if we let it run entirely free, which is why the restriction of doing ability two after typing is a lot safer, as we can control that the second ability fits the typing and is in fact an optimal combination.

I also believe, that having an entirely free ability stage and one, that is restricted by typing and maybe role, could lead to two very different ability discussions and might highlight different ways, in which abilities can be optimized, which would imo benefit the goals of the concept.

 

[sneakyjeans]

But we can’t control the outcome of the ability stages, if we let it run entirely free, which is why the restriction of doing ability two after typing is a lot safer, as we can control that the second ability fits the typing and is in fact an optimal combination.

I completely agree here. I think this is our best chance at getting a balanced result. There is less freedom here but design constraints are a critical part of the process and create a more cohesive and viable product. Both abilities up front could lead to a typing that attempts to support both but doesn't do a great job for either option.

I originally did advocate for doing roles before ability, but with the ability-typing-ability flow I agree that a second assessment for roles after the first ability stage makes more sense.

Starting with 30i makes sense to me for abilities as well, we will be less restricted with the 30b ability discussion.

 

[Pipotchi]

I really don't want to offend you Wulfanator, but I think that you're interpreting the wording in the framework incorrectly here. The framework said that CAP 30b and 30i "will share a typing and a movepool", which to me implies that both of their types have to be the same. If only one typing had to be shared, I think Pipotchi would have worded it as "these Pokemon will share at least one type and a movepool". Then again, Pipotchi is really the only one who knows the exact wording, so I tagged her here so she can clarify. :)

If it counts for anything, "share a typing" was meant as in "shares its whole typing", like Giratina. The only place where the mon would differ from Giratina's form's differences was in stat allocation which was explicitly written to be rearrangeable in a more fluid manner, everything else should be covered by the term "like Giratina" which was written wrt typing and movepool.

 

[kjnjkmjk1]

I'd be preaching to the choir regarding sharing one type vs both types (I also agree that we should really just go with sharing the full typing), so I won't expound on that.

Instead, I'd like to throw my support behind not setting a specific role for the first ability stage (assuming we do ability 1 -> typing -> ability 2), and just letting people propose abilities freely. I think opening the design space up is worth the effort of manually deciding the role later on (potentially in an assessment after the ability is chosen, which some people have already suggested), and I don't think it would be significantly more chaotic than the current suggestion of picking the ability for one form before the other. I think giving ourselves more freedom in our starting ability plays into how this is such an ability-focused concept, and in the end I don't think it should play out too much different from the current popular option of 30i ability -> typing -> 30b typing.

 

[NitioWO]

1) I think abilities before roles is a good idea.

2) I think they should share both typings.

3) I was initially in support of ability 1 > ability 2 > typing, but my stance is not super strong. I don't think it will differ too much from ability 1 > typing > ability 2. The former forces you to reconcile two abilities with a typing, which may not go smoothly. The latter reduces the pool from which we can choose the second ability, but is less likely to cause a major mismatch. The tradeoff for the latter is just the restriction on ability choice, which may or may not be super constraining anyway. My logic was that I would rather have typing constrained than an ability for this ability-focused concept, but that comes with a higher risk. I would not mind either way.

4) I will say though, that I am in favor of choosing 30i's ability first, because there are simply more factors to consider given the information we already have about this mon:
a. 1.2x STAB boosts are greatly influenced by typing
b. Un-knockability influences whether we are able to switch into knock offs consistently, based on typing.
c. Inability to hold an item restricts us from a subset of abilities.

I wonder about the efficacy of just allowing free-for-all ability submissions and then deciding which forme the ability fits post-facto. This would create a bit of chaos, and perhaps result in a slightly less optimal cap, but would give us a lot more design space.

Edit: I suppose I should clarify that by free-for-all I mean submitting for either forme, rather than like any ability.

I don't know how this will actually work in the next step. When submitting abilities, will users have to justify/explain their inclusion based on both 30b and 30i, or perhaps specify which mon they're submitting for? Certainly, there are abilities that will work for both mons, but there are a lot of abilities that are better suited to 30i, or simply won't work with 30i. After we choose the ability, will we have to do another poll to decide which mon gets it?

Given that most everyone thinks it makes more sense to choose 30i's ability before 30b's, the chance that this process will lead to the selection of 30i's ability anyway is high. And if we do end up giving it to 30b, that runs counter to what most everyone here has stated as their preference.

I can see the merits design space-wise, but I think it would introduce "chaos" (as quziel put it). I would rather have a focused discussion based on what we know about 30i, then choose the typing, then choose 30b's ability, if we choose to go that route. Obviously, either way, abilities subbed in the first round should not be excluded from being subbed again in the next ability round.

 

[Rapti]

Instead, I'd like to throw my support behind not setting a specific role for the first ability stage (assuming we do ability 1 -> typing -> ability 2), and just letting people propose abilities freely. I think opening the design space up is worth the effort of manually deciding the role later on (potentially in an assessment after the ability is chosen, which some people have already suggested), and I don't think it would be significantly more chaotic than the current suggestion of picking the ability for one form before the other. I think giving ourselves more freedom in our starting ability plays into how this is such an ability-focused concept, and in the end I don't think it should play out too much different from the current popular option of 30i ability -> typing -> 30b typing.

Honestly, I don't think this is feasible simply because the item already puts some limitations on the abilities 30i can viably have

for example, we already know that abilities such as Ripen or Sticky Hold are useless on 30i

thus I propose we go Ability that Supports 30i's Item - > Role for 30i Ability - > Typing - > Ability for 30b - > Role for 30b Ability
yes, this does limit our options, but if we want 30i item to do something for it (and we better do cause it's the only item it'll ever have) we have to make sure it has synergy with the ability we'll give to it

 

[SHSP]

Instead, I'd like to throw my support behind not setting a specific role for the first ability stage (assuming we do ability 1 -> typing -> ability 2), and just letting people propose abilities freely. I think opening the design space up is worth the effort of manually deciding the role later on (potentially in an assessment after the ability is chosen, which some people have already suggested), and I don't think it would be significantly more chaotic than the current suggestion of picking the ability for one form before the other. I think giving ourselves more freedom in our starting ability plays into how this is such an ability-focused concept, and in the end I don't think it should play out too much different from the current popular option of 30i ability -> typing -> 30b typing.

Want to throw my support behind this. I really don't think we need to be setting roles for the mon(s) so early on and artificially tamping down on potential options for our initial ability selection. It also makes a lot more sense to me personally to optimize an ability by fitting it to its preferred role after its selection, including which of our forms we end up wanting to put the ability on.

I also want to make a quick note of my .02$ about how I think we just need to pick our first ability and then figure out what form it's going on after the fact. I don't think that the item itself should mandate us doing one form's ability before the other when we can look at the selected first ability and fit it to our preferred form. Some abilities are going to work better on one form or the other, and I think we should avoid limiting ourselves to trying to force our first ability to fit one or the other from the jump. Instead, if we select that first ability and then put it on whatever form is the best fit, we're preventing ourselves from being artificially limited in our first ability selection, and going into later stages of the process with a clearer goal of what's needed for both forms.

 

[Zephyri]

ooo okie, im in full support of kj's idea for the most part; i really disagree with the idea of picking roles first since it limits our ability pool and railroads the process and generally feels a little arbitrary+it makes the most sense to start an ability focused process with, yknow, the ability. i want to mention, however, that i really really think a second concept assessment stage is necessary after the selection of ability1. figuring out a role immediatly after the ability1 stage gives us more direction and justification basis in the typing stage and helps us define the mon more clearly, and i think a lack of role-defining would lead to a shoddily put together typing stage and a lack of direction as to where we're going with either form and how we'd make them both viable.

Both forms’ primary abilities should be chosen before typing. Choosing typing after only one ability has been decided tautologically results in typing being warped around the first form, and the second form having to play catch-up. ie, it immediately results in one being more “optimized” than the other. This, in my mind, completely defeats the point.

im sorta on the fence with this proposal; i agree that optimizing both forms is really difficult when you're putting one form/ability on the forefront but at the same time i think thats kinda inevitable? i genuinely dont think its possible to completely optimize two different abilities when you have two mons that share 2/4 characteristics (especially when you consider that the ability pool for this concept is significantly smaller than normal). you can definitely come close to that, and have one mon thats completely tailor made for its ability and another that uses it very very well, but im doubtful of the possibility that we'll be able to create two completely tailor made optimal mons for their ability; someone's going to have to compromise.

if we were to do both abilities at once i think we'd have a very messy discussion and a tiny slate with each option completely railroading the process in a specific direction. thats def a fair way to fulfil the concept and itd prob result in a more accurate representation of the concept but i doubt we'll learn much from pairing say, technician and skill link w a movepool full of multihit moves. with that in mind i think itd be a lot better for the process if we separated the ability stage

cheers :)

 

[Krazyguy75]

I feel like too many people are underestimating the CAP forums. We don't need to know a ton of information to do our jobs; we've done so in the past on less info.

“How can we create a balanced typing without knowing a role first" was the silliest underestimation... we've done that for 32 CAP processes! Sure, we'll be doing it with an ability this time, but that's more information known, not less. Then you have questions like "how will we make a second balanced ability that's as optimal as the first for said type"... again, we normally have ability after typing, so... same as normal!

I have full faith that, no matter the order, we will get a functional result. So I would rather people focus their complaints less on "I don't think we will be able to do X effectively" and more on "We shouldn't do X because it is detrimental for reason Y". Cause no matter what, we will be able to work with the X in question, and we will be able to do it well. It's just whether doing that specific thing is beneficial or detrimental.

 

[LucarioOfLegends]

Yea I've changed my mind. I think abilities before roles is a much more interesting way to go since the concept is ability-centric, and we realistically should have roles dictated by the ability as opposed to the other way around. Throwing my support behind specifically kj's suggestion, as that will likely be the cleanest foundation, as what ability we choose will most likely assist in deciding how to make 30b and 30i distinct enough from each other role wise. Locking ourselves into something before we even decide what abilities we want will just hurt the variety of options going forward.