PRC Thread Approved by... me! And a few others, but still.
Hey all.
This is the first in a series of threads on the CAP Process. Y'all get me as the lead on thread one, which goes over a few proposed changes to our stages and ordering. I want to quickly discuss the aim of each change, anything that staff can see as a potential problem... and then open up the floor to discussion!
Concept Assessment Addition - Stage Re-Ordering
This has been floating about for a while - I believe since CAP25 when we all said, "can't we choose the abilities, the key parts of this concept, first?". The proposal here is straight forward - during Concept Assessment, if the TL and Community come to the consensus that it's needed, we can re-order our process of competitive stages (Typing, Stats, Abilities, Movesets, Checks + Counters, and so on) to better suit the needs of the concept.
Goal: Create a process that is more flexible for concepts that focus on different competitive aspects.
Potential Pitfalls: Art Submissions can't realistically start until Typing goes up - whilst a lot of designs aren't finalised until competitive stages are all but done, it's not feasible to open an art thread without typing at a minimum.
Defining Moves
Another one that has been tossed around a few times recently is the idea of declaring Defining Moves for a CAP - essentially being able to remove the poll-jumping block on certain concept-relevant moves. Examples of where this would have been potentially quite useful for the sake of discussion include Jumbao (Weather Ball) and Smokomodo (Flame Charge).
We’re proposing two different ways to implement this stage. The first is to have this tied into discussion of Checks and Counters - and could focus on moves to "lock" in (basic STAB options, anything concept demanded), as well as allow certain moves to be named in other discussions without being guaranteed a place in the final movepool.
Alternatively, ‘defining moves’ could also be ran as a sort of ‘overarching’ thread, remaining open throughout the entire process - this would have been useful for Astrolotl, where I think we developed an entire new vocabulary of ways to refer to Inferno, Knock Off, and various other support moves.
Goal: Improve the validity of discussing certain abilities, remove blocks to discussion that often feel like playing an elaborate game of charades as opposed to getting to the point.
Potential Pitfalls: Could this be overly-restrictive by essentially locking moves in early in the process? And what do we do if we realise we need to change our mind - Jumbao’s Weather Ball, for instance.
Full Movepool Submissions
Dogfish, on movepools again?
So, coherent movepool design is difficult, and doubly so when you don’t have information on the pre-evolution(s). Movepool is so twisted between every faucet of pre-evolution design that the fact we complete it so early means a lot of pre-evolution design is locked in ridiculously early. The proposal here is pretty simple: When a CAP is first released, it’s movepool is essentially a placeholder of moves which are required as a result of the moveset stage. Full Movepools are instead submitted during the Pre-Evolution Process, alongside the Pre-Evolution’s Movepool.
Goal: Improve coherency of Pre-Evolution and Final Evolution Movepools, improve quality of discussion in Pre-Evolutions by removing the large constraint of the Final Evolution’s Full Movepool
Potential Pitfalls: Optically, it means CAPs will be released - at first - with a fairly barebones movepool.
Quality Control in Sprites and Movepool
MrDollSteak first came up with this idea - and it’s something that is essentially already done as part - but we should probably formally describe the idea. For thoughts on QC, this post sums up the ‘Why’ we need it rather succinctly.
QC for Sprites isn’t actually new - the Equilibra Sprite had a couple of touch-ups around it’s neck shortly after it won. Ideally this process for Sprites and Movepools is something that could be done in a live chat - it should foremost be a discussion of minor technical tweaks, ideally completed fairly quickly, think around 72h tops.
Goal: Improving the quality of more technical flavour stages through the introduction of Quality Control to match current-Generation flavour standards/rules.
Potential Pitfalls: Ensuring that original creators - and the wider community - are not excluded from the QC process, especially if the most efficient way is through live discussion.
We’d like to see the following discussed in this thread to begin with:
Stage Adjustments and Quality Control
Hey all.
This is the first in a series of threads on the CAP Process. Y'all get me as the lead on thread one, which goes over a few proposed changes to our stages and ordering. I want to quickly discuss the aim of each change, anything that staff can see as a potential problem... and then open up the floor to discussion!
--------------------------------------------------------------------
Concept Assessment Addition - Stage Re-Ordering
This has been floating about for a while - I believe since CAP25 when we all said, "can't we choose the abilities, the key parts of this concept, first?". The proposal here is straight forward - during Concept Assessment, if the TL and Community come to the consensus that it's needed, we can re-order our process of competitive stages (Typing, Stats, Abilities, Movesets, Checks + Counters, and so on) to better suit the needs of the concept.
Goal: Create a process that is more flexible for concepts that focus on different competitive aspects.
Potential Pitfalls: Art Submissions can't realistically start until Typing goes up - whilst a lot of designs aren't finalised until competitive stages are all but done, it's not feasible to open an art thread without typing at a minimum.
--------------------------------------------------------------------
Defining Moves
Another one that has been tossed around a few times recently is the idea of declaring Defining Moves for a CAP - essentially being able to remove the poll-jumping block on certain concept-relevant moves. Examples of where this would have been potentially quite useful for the sake of discussion include Jumbao (Weather Ball) and Smokomodo (Flame Charge).
We’re proposing two different ways to implement this stage. The first is to have this tied into discussion of Checks and Counters - and could focus on moves to "lock" in (basic STAB options, anything concept demanded), as well as allow certain moves to be named in other discussions without being guaranteed a place in the final movepool.
Alternatively, ‘defining moves’ could also be ran as a sort of ‘overarching’ thread, remaining open throughout the entire process - this would have been useful for Astrolotl, where I think we developed an entire new vocabulary of ways to refer to Inferno, Knock Off, and various other support moves.
Goal: Improve the validity of discussing certain abilities, remove blocks to discussion that often feel like playing an elaborate game of charades as opposed to getting to the point.
Potential Pitfalls: Could this be overly-restrictive by essentially locking moves in early in the process? And what do we do if we realise we need to change our mind - Jumbao’s Weather Ball, for instance.
--------------------------------------------------------------------
Full Movepool Submissions
So, coherent movepool design is difficult, and doubly so when you don’t have information on the pre-evolution(s). Movepool is so twisted between every faucet of pre-evolution design that the fact we complete it so early means a lot of pre-evolution design is locked in ridiculously early. The proposal here is pretty simple: When a CAP is first released, it’s movepool is essentially a placeholder of moves which are required as a result of the moveset stage. Full Movepools are instead submitted during the Pre-Evolution Process, alongside the Pre-Evolution’s Movepool.
Goal: Improve coherency of Pre-Evolution and Final Evolution Movepools, improve quality of discussion in Pre-Evolutions by removing the large constraint of the Final Evolution’s Full Movepool
Potential Pitfalls: Optically, it means CAPs will be released - at first - with a fairly barebones movepool.
--------------------------------------------------------------------
Quality Control in Sprites and Movepool
MrDollSteak first came up with this idea - and it’s something that is essentially already done as part - but we should probably formally describe the idea. For thoughts on QC, this post sums up the ‘Why’ we need it rather succinctly.
QC for Sprites isn’t actually new - the Equilibra Sprite had a couple of touch-ups around it’s neck shortly after it won. Ideally this process for Sprites and Movepools is something that could be done in a live chat - it should foremost be a discussion of minor technical tweaks, ideally completed fairly quickly, think around 72h tops.
Goal: Improving the quality of more technical flavour stages through the introduction of Quality Control to match current-Generation flavour standards/rules.
Potential Pitfalls: Ensuring that original creators - and the wider community - are not excluded from the QC process, especially if the most efficient way is through live discussion.
--------------------------------------------------------------------
We’d like to see the following discussed in this thread to begin with:
- Your general thoughts on the above proposals - if you can see any problems, please raise them so that we can address them!
- If any potential pitfalls look too serious to be willing to consider.
- Artists and Modellers in particular, your feedback on timings this PRC will likely be incredibly valuable, as we are looking at timings - if at your end you’re seeing any changes that would leave you rushing too much, please raise them!