Birkal
We have the technology.
I am glad you posted! Feedback is better than deadpan silence. I had edited in your suggestion.So, before I get into my personal opinions (which I've been encouraged to post for the sake of posting *grumble grumble*), I'd just like to make a quick comment on Birkal 's outline thingamajig. For the section of "Non-intuitive" stuff, I feel like the phrasing is a bit nonspecific. I personally understand it (I think), but I could also see it being interpreted as "We won't allow a custom ability that isn't a renamed version of an existing one." I might be the only one that sees it that way, but maybe just in case add a specification like, "For example, an ability that changes a Pokémon's form based on terrain would be allowed, but not an ability that summons a new type of weather."
This is a good point, and I really like the example you gave about terrains. In that case, let's plan on "closing the gate" on any custom elements at the conclusion of Concept Discussion. If the Topic Leader deems it necessary at that point, let's stick to it and move forward. Is this fair?Anyways, I'll be bouncing a bit off of some discord discussion I've seen lately - and this isn't really a planned post like some of my others so... yeeeah. I guess I'll start with custom moves/abilities. Personally, I think that they should be allowed, but only if deemed necessary by the framework/concept analysis. For example, if we do a framework of "Mega Pokemon" and a concept of "Viable in both forms, but with different roles" you obviously don't need custom anything. At that point you'd just be complicating the process. However, consider a scenario like this: a framework of "Has a Form Change" and a concept of "Uses terrains in an interesting way." The most obvious (though by no means only) way to approach this is to create an ability that allows for changing forms with terrain changes. Similar interactions between framework and concept can lead to this sort of situation where a custom is strongly desirable, at which point I say sure, go ahead and have a blast. Additionally, the framework itself could call for a custom move/ability with some not-too-limiting parameters. Something like "Uses a custom ability to make an unviable field effect usable" or as Discord suggested "Uses a custom move with an unusually high base power" could all be examples of not-too limiting custom frameworks.
On Discord, I mentioned that we discussed earlier this week the Rule of Twos for breaking the process as a happy medium. Having three parts railroaded is practically no creation process at all, agreed, but one is harshly limiting. If we limit one, we cannot legally make any Ultra Beats, any starter trios, anything with Multitype, any pseudo-legendaries, and so-on. Are these concepts good or bad -- I think that's entirely subjective. But I do feel that only allowing one break in the process really hampers creativity. Two may feel like a lot, but the example of an Ultra Beast still leaves a lot to be done in the process competitively, including Concept, Typing, Stats, and Movepool. Our ability is chosen, and stats have only a soft limit to work around.I guess with that I'll shift over to my opinions on framework. I honestly have an extremely strong distaste for the current "Only limits two" and would like to see it changed to "Only limits one." Even looking at the example in Birkal's format: dictating both primary ability and typing is obscenely limiting! That wipes out two stages of the process, and I would argue trivializes secondary ability as well, since you're explicitly designing the Pokémon to work for one ability. And I know now I'm just getting convoluted, but I'd also like to put a restriction on typing frameworks, so that they can't specify the entire typing. This stipulation would avoid completely marginalizing the typing stage. I understand that this is meant to be a celebration of CAP, but I can't seriously be the only one thinking that part of the fun of CAP is going through the entire process without too many foregone conclusions. It's about exploration of a game we all love, and in my opinion, giving the middle finger to an entire stage is just not something a framework should be doing, especially when I can think of plenty of non-intrusive frameworks that achieve high interest levels.
The frameworks I mentioned were intentionally lame. I am a bit leery of posting better ones, but if anyone has any suggestions, please hit me up on Discord and I'll change them around. I just don't want to steal thunder from people before the project even begins!
Again, I feel it is too limiting to narrow this down to only one Pokemon. I do understand your sentiment though, so I think a clarification is in order. If we do decide on a framework that requires more than one Pokemon to be made (e.g. a framework where the NFE and FE are both viable), we will make them both simultaneously. Making Pokemon one after the other will take far too long. But the moderators have enough savvy to know when to split conversations into multiple threads (e.g. movepools), and when to keep them together (e.g. typing). This is, yet again, another theoretical exercise in trust.I'll also mention here, I guess, that I side with reach on the idea that the project should only build one mon. Sure, we have a year and a third-ish until gen 8 comes out, probably. However, I think that time could be better spent moving on to a new CAP. It's not quite the same as updates, but I distinctly remember that spending too long on one specific project led to a drag in interest, and I'd rather not take the risk of that happening to what's supposed to be a Party CAP because we decided to do a legendary or starter trio because 'LOL PARTY CAP'