Other CAP 25 Celebration!

Status
Not open for further replies.

Birkal

We have the technology.
is a Top Artistis a Top CAP Contributoris a Top Smogon Media Contributoris a Site Content Manager Alumnusis a Battle Simulator Admin Alumnusis a Super Moderator Alumnusis a Community Contributor Alumnus
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."
I am glad you posted! Feedback is better than deadpan silence. I had edited in your suggestion.

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.
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?

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

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!

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'
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.
 

Deck Knight

Blast Off At The Speed Of Light! That's Right!
is a Forum Moderator Alumnusis a Top CAP Contributor Alumnusis a Top Smogon Media Contributor Alumnus
After mulling it over and thinking through a few ideas of my own, I support Birkal's suggestion of a maximum of two stages altered, with the caveat that the second can only be altered incidentally to the first. A Forecast CAP would be a good example of this. Mandating Forecast as the ability would put some strain on typing because it would make little sense to start as any of the main types (interestingly it might actually bias Rock initial typing because Forecast doesn't have a Sand Forme), but in and of itself Forecast CAP doesn't have to mandate Normal typing. It's sort of a soft natural restriction rather than "Fairy type BoltBeam" inherently aping both typing and movepool. When the mods make a slate of Frameworks we should be able to keep this principle in mind

The "two stages altered" limit is supposed to account for incidentals, not to allow overly-specific, concept choking entries.
 
Last edited:

jas61292

used substitute
is a Community Contributoris a Top CAP Contributoris a Forum Moderator Alumnusis a Battle Simulator Moderator Alumnus
I think that what Deck suggests makes a lot of sense. I agree that straight up determining two stages from the get go is just too much. However, by making so that we allow a framework to greatly alter, without outright deciding, two things, it allows for a greater quality of discussion. After all, even if an element is greatly restricted by a first element, so long as it is not specifically mandated, there will always be differences of opinion, and thus things to discuss.

More generally though, it will just make the project more interesting. While this special project is an opportunity for us to break some rules and do things we don't normally do, it is still a CAP project, and I think it is important that it still ultimately be about the process more so than the final product. The more we allow people to restrict the process, the less interesting it becomes. This project should be an opportunity to explore things we wouldn't normally, but only because the process as it normally is would make exploring such things hard or impossible to do. It should not be someone's individual Pokemon idea given life, and the more we allow one person to dictate, the less of a CAP project it becomes. Restricting some stages should only be done to breath a new life into the other stages, by forcing us to tackle something we would not otherwise be able to. It should not simply be done for the sake of picking elements that someone thinks are cool.
 
First, in response to Birkal - Closing a decision on customs in discussion sounds perfect to me! And also the clarification on the multiple Pokémon frameworks sounds good too (though I personally still have reservations about said FWs).

And secondly I'd like to address something about the two-one limit issue that's been on my mind. Have we set a clear definition for 'limit' or 'alter' or 'modification' yet? I had been operating off of what Birkal's suggested opening post said, which appeared to define whatever term you want to refer to the changes in process as, as "dictates CAP25's typing and primary ability. An illegal framework would also mandate a specific stat bias on top of those restrictions." Notice the harsh, restrictive verbs here. "Dictate" and "Mandate" are very hard-line words that indicate an illegal framework would only be illegal if it pre-decided 2 things in a meaningful manner. My interpretation of that phrasing was along the lines of a change/alteration/limit/whatever being something that would go beyond slightly limiting discussion, but instead eliminates discussion entirely. As jas said, restriction can coexist with discussion as long as the caveat exists that a restriction is not classified as a 'limit.'

With this in mind, I would then look to the past posts on this issue and question what their definition of a alteration/change to the process/what have you is (For the sake of less '/' I'm just going to refer to them as changes from here on out, because it's getting annoying for me). I would argue that BIrk, jas, and Deck have a different interpretation than mine; one that is inherently less rigid in what counts as a limit. I think the UB framework illustrates this perfectly. According to my interpretation, a UB has one change. According to you all, it has two, one being the mandate that the only ability is Beast Boost. I would agree on that. It is 100% something that obstructs the process by bypassing a stage. However, the second part is where we get a bit trickier. Y'all argue that a UB FW also puts a change on stats, because it mandates 570 BST and that each individual stat be prime numbers.

This is the part where the definition in the opening post becomes important. I can understand why one would classify the change to the stats process as a 'limit' of some sorts. Nobody here would argue that only primes is a bit of a headache, especially if they have to add up to 570. It would probably decrease out submission pool greatly, in fact. However, the current opening post doesn't seem to indicate that type of change as a, well, change. It's a soft restriction, sure, but it doesn't indicate a particular stat bias. It doesn't tell me "You must make your stats fit this general archetype." So, to me, going off of the railroad definition of a change, this wouldn't be a change. It would just be extra baggage for the stats stage.

I can kind of make similar arguments for Birkal's examples as well. Sure, it makes logical sense that Forecast would produce a form with a typing associated with the weather, putting a hard restriction on ability and a soft restriction on type. But there's nothing saying we have to abide by that logic. I could be totally wrong here, but is there anything saying hypothetical Forecast CAP couldn't have a dual typing? A type that stays between all of its forms? Or perhaps it gains a completely new dual type in each form, just to be completely counterintuitive? Similar logic (if the mechanics still hold) would apply to Multitype. It's a form change triggered by ability. Theoretically there shouldn't be anything stopping us from adding a constant secondary type to each form.

I think the best way to go about this would be to edit the opening post in an attempt to aim for absolute clarity. Along the lines of what Deck suggested, let's say each framework cannot exceed two total of railroads (or insert other term here) and restrictions, but only one of which can be a railroad.

Define a railroad as a limitation on standard CAP procedures that completely eliminates discussion on a regular stage of the process. This would be your "This CAP WILL 100% FOR SURE have X Ability, Y/Z dual typing, or Q pure typing." Meanwhile, a restriction would be, as Deck was talking about, a 'soft restriction.' This would be your FWs that say stuff like: CAP must have an ability that allows it to change forms (This restricts ability discussion, but doesn't railroad as there are multiple options here), CAP must be at least partially X type (Restricts part of the typing stage, but leaves open whether or not the mon will have a secondary type, and what that type would be), and basically anything that doesn't explicitly outline every stat in a stat spread, but says something about how the stats should go (e.g. The speed stat will be 255, A strong special tank, must follow UB stat patterns, etc.). I think this approach allows for the most freedom in frameworks by allowing two total breaches of protocol, but also more clearly defines what we're talking about when we say 'trivializes the process.'

Additionally, I think it wouldn't hurt to add a part to the FW submission where submitters specify what railroads or restrictions their project entails. I think it will help streamline framework/concept analysis if we aren't starting off by saying "So what actually does this framework entail in terms of what we can/can't do?" Additionally, it gives those reading the concepts the ability to quickly identify what stages would be impacted by choosing a given framework. Honestly, this is all probably too complicated a way to go about this, and I'm sure someone else here will be able to streamline this better, but I really do think we need to nail this framework definition now in order to save so much headache later.
 

Birkal

We have the technology.
is a Top Artistis a Top CAP Contributoris a Top Smogon Media Contributoris a Site Content Manager Alumnusis a Battle Simulator Admin Alumnusis a Super Moderator Alumnusis a Community Contributor Alumnus
We're done here. I have implemented changed as jas, Deck, and Okamu have described them. Great thoughts!

Basically, we will go with what I have written here, with the modifications being presented specifically by Deck Knight and reachzero modified into the OP of the Framework Submissions post. Furthermore, I'll update the example Frameworks to fit these guidelines. I will link the CAP25 - Frameworks Submission post here when it is created for future posterity.

Let's get creating!

Approved by Birkal, jas61292, reachzero, and Deck Knight.
 
Status
Not open for further replies.

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

Top