Policy Review Stage Adjustments and Quality Control

Dogfish44

You can call me Jiggly
is a Forum Moderatoris a Community Contributoris a CAP Contributor
Moderator
PRC Thread Approved by... me! And a few others, but still.

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
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:

  • 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!
 

MrDollSteak

formerly pokehimon
is a Pre-Contributor
Awesome to see this thread Dogfish44, I think it includes a lot of important suggestions that should hopefully make CAP 28 run even more smoothly, and address the few quibbles that came up in 27 as a result of the transition to SwSh. I'll address the points separately.

Concept Assessment Addition - I don't have anything to add, I think the proposal here covers everything it needs to. I think the re-ordering process being decided through discussion in this stage, with the Topic Leader having the final say is completely appropriate. I think the concerns for artists not getting typing first are minor. As a semi-artist (emphasis on semi), I can only speak from personal experience, that having typing open up early leads to a lot of early designing, that is often just thrown out when contradictory abilities and stat lines come into play. In some ways, by having typing occur once one or two other things are decided, although the overall time that an artist might have to prepare a submission is lower, I think there is less of a chance that artists will have to throw out designs completely.

Defining Moves - I think that defining moves while obviously intended for certain move-based concepts, can also be something to bear in mind for normal concepts too, and as such I think I prefer the idea of having a 'defining moves' thread open up and be decided before the stats and moveset submissions. I personally think that the way that the move sets stage operates is less democratic than other ones, not for any fault of topic leaders or anything like that, but unlike other CAP processes where the final decisions are made by the community, in movesets, the topic leader can veto certain moves, even if there is wide support for them due to competitive implications in a way that doesn't happen as frequently in other stages such as ability. Obviously abilities aren't always slated, but in the case of movesets, I think optically it is harder to gather support for or against moves, or with separate polls such as the CAP 27 Fire Lash poll being necessary. I think that a defining moves thread where a range of competitive moves are suggested and then voted on whether to be included, will be incredibly helpful for the stat stage, as spreads can run accurate calculations, and be esigned to complement moves, so that a situation where a winning stat spread is too powerful with a chosen move (ie. Weather Ball Jumbao or Flame Charge Smokomodo) doesn't occur. I think in the rare situation that the power level of moves in relation to the stat spread is underestimated, and a move needs to be removed, I think this can be decided through some sort of testing phase either during the 'moveset' submission phase if we keep that, or after the release of the CAP, and be reflected as part of the 'full movepool' process that Dogfish raises, ie. when the prevo process begins. I think this subsequently circumvents the need to have a formal nerfing process, and ties into already existing processes minimising overall difficulties. Of course if the issue is deemed to be with the stats and not the movepool, well that would have to lead to a normal nerfing process, but I think that doesn't necessarily act as an argument against the idea of having the defining moves stage.

Full movepool submissions - I don't have anything to add. I think the proposal is reasonable, and personally don't think that not having a complete level-up / breeding / TM/TR movepool is bad optics, considering it is pure flavour and only able to be accessed in threads about the CAP. I think the benefits outweigh this minor quibble in any case, and as mentioned in my response to defining moves, can allow for flexibility in regards to the removal of moves if they are found to have been too powerful after sufficient testing (ie. Phasing and Toxic on Equilibra).

Quality Control in Sprites and Movepool - I agree that we need QC on both, but don't personally think that these two stages should be grouped together in this proposal. I think that the QC for movepools will largely be resolved by having the prevolution's move pool and evolution method be decided first, as in this regard the finalised CAP movepool only needs to be consistent with the prevolution. I think that ensuring fitting Gen 8 movesets are made won't need much more than clear resources and comments about how movepools fit in relation to the prevolution.

Sprite QC on the other hand I think needs to be handled differently, and ideally by some sort of sprite council which could be comprised of the submitter of the winning sprite, the sprite topic leader, and other people in the community with extensive spriting experience. The reason that I say this, is that if a winning sprite is able to be QC'd by anyone, or is obligated to touch up a sprite based on any comment, it is possible that the sprite may actually be made worse, as recommendations don't necessarily always come from people that are familiar with the Gen 5 spriting style. While this may initially seem to be excluding other submitters, I think that having a Sprite Council to QC sprites will conversely actually allow for more diversity in terms of winning sprites, as polls will be based primarily around poses, proportions and colours, with the knowledge that the Sprite QC council will be able to touch up elements of the sprites that can be deemed incomplete or inaccurate. Obviously this suggestion is quite a bit more ambitious than Dogfish44 originally suggests, so it will require further discussion, especially in regards to the parameters of, what aspects of the sprite would the QC council be able to amend for example.
 
Working with stage order if it's necessary would definitely be useful for some CAP concepts, such as the Sketch, Belly Drum, Spirit Shackle, and Doom Desire concepts we have worked on before. Defining moves would also work for other CAPs if we can focus on a coverage move we'd think it would need, even if we have to remove it if the move turns out to be over-powered, as seen with Weather Ball Jumbao and Flame Charge Smokomodo. It sounds like a pitfall at first, but we can always work around or against that move if we really need to.
 
About the movepool quality control stage and relationship the pre-evolution movepools, I brought this up some time ago (emphasis added now):

There is however a characteristic which is often unrealistic without any need to be such, as it has no competitive impact whatsoever. That is, the internal organization of level-up movepools.

- Actual Pokémon tend to follow patterns in the way the learn moves, such as every 4 levels, every 3-4-5 levels in a recurring loop, and so on. The intervals of CAP Pokémon tend to be way more random, sometimes with oddly large gaps. This isn't really unprecedented, as the level-up movepools of several G6 Pokémon appear similarly random (including Chespin which has a huge 9-level gap between 18 and 27); this randomness might be a result of in-game considerations, however.

- Most moves are learnt by real Pokémon in a variedly fixed range of levels. For example, on average Fake Out is an early move (never after level 22), while Wring Out is among the last moves a Pokémon learns (never under 37); yet Kitsunoh learns Fake Out at 35 and Revenankh (pre-update) learned it at 9.

- Finally, CAP movesets tend to make little sense when compared to their pre-evolutions; for example Scratchet's levels are wildly different from Tomohawk's (which make even less sense on their own). Most importantly, when actual Pokémon evolve by level in most cases the levels at which they learn moves are consistently delayed, the usual delay being 1 level for the first move after the minimum evolution level, 2 levels for the seconds, and so on; some Pokémon (such ar Mareanie) get higher delays (e.g. increasing by 2/3 instead of 1), while some get no delays at all. This is not as consistent for CAPs, mainly because the pre-evolutions are always designed later and whoever makes the movepool has to abide to the precedent set by the evolved form.

I do think all of this is somewhat of a problem, flavour-wise. Encouraging those who submit movepools to have a look at how actual movepools work would be nice, but the pre-evolution problem still stands. The main issue, I think, is that the evolution line is not designed as a unit. TM and tutor moves pose no problems as they can be just removed from the pre-evolution's movepool, so this only applies to level-up (and possibly egg) moves. I could see two solutions:

1 - Design the level-up movepool of a full evolution line in one shot. This would be the most consistent outcome, however it would create logistic problems as the very existence of pre-evolutions is decided later in the process, and mandating it earlier would be burdensome.
2 - Design the whole thing as usual (final form only); then, in the pre-evolution stage, allow for slight shuffling of the final form's levels to account for delays and evolution moves (the new G7 mechanic). No new moves of any kind would be allowed to be added at this stage.
Option 2 is the most conservative with regards to the current, traditional process. Option 1 is a more radical change, but considering how it lines up with what is proposed here it does not feel so far-fetched anymore. I think it is a valuable idea because:
- It allows a more natural-feeling final movepool, and I assume it is closer to how actual Pokémon movepools are designed
- It allows competitive considerations to come into play when attempting to design a balanced pre-evolution for CAP LC and not have moves forced on the base form (Belly Drum Cawdet).

A combination of these points and the "placeholder movepool" proposal seems the most consistent way to proceed, as it can result in a more natural movepool flow while providing a shortcut to release the most important parts of the actual CAP as soon as possible. Just be carefult not to let overly competitive moves sneak in in the full submission.

I also do not think having to design a whole line together would be too burdensome:
- Evolutionary delays (as well as normal level gaps) can be easily calculated, even automatically (e.g. with a spreadsheet software)
- It should remain possible to design pre-evolution movepool as it can be done now - that is, by starting with the final form and removing unfitting moves from earlier stages.
 

Birkal

We have the technology.
is a member of the Site Staffis a Top Artistis a Community Leaderis a Community Contributoris a Top CAP Contributoris a Top Smogon Media Contributoris a Battle Simulator Admin Alumnusis a Super Moderator Alumnus
CAP Head Mod
Dogfish44 let me know what else you need to clean up to get these changes pushed forward. It seems like the community consensus is in favor of what you've proposed. It'd be good to have this set up by the time CAP27 fully gets under way.
 

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

Top