Done CAP 30 should be a Framework CAP

[quziel]

Framework CAPs are something that really helps to bring excitement to the project, are fun (this is very important), and give us a chance to explore our boundaries as a project by ignoring some of our usual rules on process and concepts.

I propose the following:

• Allow multi-CAP concepts, with the restriction that well, they have to share a lot so that we can avoid being burned out by mass CAP stuff.
• Allow very limited custom elements (aka only if we legitimately cannot accomplish them using standard). This allows forme changes, and some very minor custom elements.
• Process should be:
  • Select TL
  • Select Concept
  • Determine requisite size of TL Team
  • Vote
  • Proceed.

I do not have a huge amount of bandwidth today, so please give your thoughts.

 

[Voltage]

I'm in favor of a framework process for CAP30. As an engineer, I have found that some of the best work comes from imparting limitations in one way or another in order to ground a project as its being processed. Since the last Framework CAP, the starters, CAP has really grown a lot in terms of developing a proper process. I am confident in our community's ability to work through a new framework and ultimately create a successful project. There's plenty of avenues to explore as well since there are a number of old and new mechanics that CAP has never touched, including forme-changing, "legendary" / mythicals / ultra beasts, regional variants, etc. that would all be quite interesting to investigate over the course of a process. This exploration will, as Quziel has said, prevent some serious CAP process burnout, considering how notably quickly we were able to get through CAP28 and CAP29.

Additionally, one of the most appealing things to consider for frameworks is that a LARGE number of contributors in this community were not around for the Caribolt / Smokomodo / Snaelstrom processes, and have little to no experience with the process of making a mon through a framework. This allows CAP to reconsider how to build under a framework with a new set of eyes, which then will create a brand new product. These frameworks, whether ultimately flavor based or competitively based, would be a really fun way to explore the construction of a Pokemon (or two).

TL;DR Yes, CAP30 should be a framework

 

[Mova]

I fully support the premise of a framework CAP this time. I have mostly supported the idea of making one of these per generation, since Crucibelle and the starters qualify as these, and possibly Aurumoth.

There are other ways to make it less exhausting than 25 than limiting the number of mons from it, such as making them more similar to each other than the starters were. I would prefer we make up to two in the same process, if we touch any more than one, but that's just me. Prominent proposals for these have included Special Legendary Pokémon, regional forms of an existing CAP with an evolution, and even hard-coded form changes, which have been quite popular for the most part.

 

[spoo]

Throwing my support towards this proposal. I don't think it's a stretch to say that most people support doing a framework cap as a general idea, the only question is when frameworks should actually happen. Having cap30 be a framework makes perfect sense to me, especially as cap25 was already a framework, and if this proposal succeeds then we would essentially be setting a unspoken precedent for frameworks to happen every 5 processes. I am proposing that we just codify this exact precedent, so that this same prc thread doesn't have to be remade for cap35 and so on

I think this is also something that's difficult to argue against unless you believe that a) frameworks are bad as a whole and we should stay away from all of them, b) frameworks should always happen at the beginning of a generation/new game, c) frameworks should happen at specific anniversaries for the project itself, or d) they should not happen in any set pattern and should be done in exceptional circumstances just whenever we feel like it. Won't get into point A but I think doing frameworks at the beginning of a gen is a horrible idea because that is an incredibly chaotic time period competitively speaking, and it would make far more sense to take on a more difficult/risky process when the tier is in a stable place. Doing frameworks at, say, cap's 10/15/20 year anniversaries also seems strange because five years is frankly an unnecessarily long waiting period, and I don't see the point in doing frameworks only "when the time is right/when we feel like it" as this just seems unorganized and I'd rather not leave something so important totally up in the air. This prc thread is an easy time to codify a proper schedule for frameworks, and I feel it that if the proposal to make cap30 a framework ends up receiving enough support, then we should go all the way and make them happen every fifth process to eliminate any ambiguity for this in the future.

As far as custom elements go, I think this needs to be extremely well-defined or else we reopen the huge can of worms that we have been trying to avoid for like a decade at this point. I am fine with custom elements happening for a framework, but only in these circumstances-

• the "custom element" allows us to use a signature move/ability we would never get otherwise. the custom element here isn't really "custom" per se, but we would still be breaking the rules that gamefreak has given us that we would normally be constrained under
• the custom element allows us to access something that is hard-coded but still exists inside the base game. this is where stuff like forme change abilities come into play, because many of them are hard coded and we would likely need a custom ability if we wanted to pursue a forme change framework. we would never be introducing something completely new into the game, only cloning something that's hard coded in order to give ourselves access to it

Maybe I forgot something, but outside of these situations I laid out I don't really believe that "breaking gamefreak's rules" and diverging from the base game has a place in the cap project anymore. That's all I really have to say about this at the moment but I'm looking forward to where this proposal ends up

 

[dex]

I’m not opposed to a framework CAP, I didn’t get to participate in CAP 25 so I’d be super excited to see what craziness would ensue, but I do wonder about what precedent this sets for CAP. Are we saying that every 5 CAPs there will be a framework CAP? Or is it just that the time is right for one and it’s up to the CAP mods to determine when we do one?

 

[kjnjkmjk1]

I'm mostly ambivalent on doing a framework for CAP30. The framework was originally formalized as part of a celebration for both CAP's 10 year anniversary and CAP25. (I am going to be a stickler here and point out that Crucibelle happened before the framework for frameworks was finalized and does not count.) I am not exactly sure if there are things being celebrated here, besides managing to get to another multiple of 5, so if this goes through, I think this also serves as a separation of frameworks from the idea of celebrating something. If people want a framework, then I won't be opposed to it, but we should be aware that this is solidifying frameworks as a more "regular" part of the process, rather than an extremely special thing.


I generally agree with 2spoopy4u's points above on formalizing a schedule for frameworks if we are determined to make them a regular thing, although I think the timing should be different. Our sample sizes for the number of projects per generation is not very large, but for reference, Gen 4 had 11 projects, Gen 5 had 6 projects, Gen 6 had 5 projects, and Gen 7 had 4 projects. There are obviously a lot of factors into these different numbers (particularly that one of Gen 7's projects was the extremely long CAP25), but the number of projects per generation is both dependent on changes within the process and Game Freak's release schedule, meaning that while doing a framework every 5 CAPs can work out now, there is a scenario where CAP 50 ends up at the beginning of the generation, and I agree with the principle that this is not the best time to do a framework, as things will be rather chaotic between generational updates being finished and figuring out the meta (not to mention the possibility of DLC).

An alternative is to do it for the Xth CAP of the generation. CAP25 was the third project of its generation, and if this goes through, CAP30 will be the fourth, so I think either of these numbers are fine. This does have the potential issue of what happens if there is not enough time in the generation to do X CAPs, although we could just automatically have the last CAP of the generation be the framework if we do not reach X CAPs. There is also the issue of what happens if there is an exceedingly long amount of time between generations, such that there are many CAP projects after the Xth CAP within the given generation, although given the current, mostly consistent rate at which generations change, this is not likely to be an issue soon.


As for the talk about custom elements, I think it is pretty important to discuss and establish something about this, because 2spoopy4u's proposal as-is mostly breaks with the previously established precedent of our previous custom elements. To iterate:

• Syclant's Mountaineer: entirely new ability preventing Syclant from being destroyed by Stealth Rock and losing viability
• Fidgit's Persistent: entirely new ability designed to help Fidgit directly achieve its concept of serving as utility for lesser used utility moves
• Stratagem's Paleo Wave: the highest power special Rock move of its time (base 85), in order to give Stratagem a useful STAB besides Base 70 BP Power Gem and non-Technician Base 60 Ancient Power. Essentially a modified Aurora Beam.
• Kitsunoh's Shadow Strike: the highest power physical Ghost move of its time (base 80), in order to give Kitsunoh a useful STAB besides Base 70 Shadow Claw. Closest equivalent is Crush Claw with +5 BP and Ghost type.
• Colossoil's Rebound: new ability designed to help Colossoil directly achieve its concept of blocking secondary effects of moves (Magic Coat existed, any form of auto-Magic Coat/Magic Bounce did not at the time)

Notably, none of the elements had proper analogues at the time, and particularly in the case of Paleo Wave and Shadow Strike, they are filling a need that is otherwise not fulfilled by existing elements. 2spoopy4u's proposed rules limit us to using or imitating what already exists, which is more consistent with the project's current philosophy of not straying from what Game Freak has provided, but is completely different from the philosophy used for previous custom elements. I'm mostly fine with this, especially since it will help keep custom elements to a relative minimum if we are making frameworks a more regular occurence, although I question the necessity of "allowing" otherwise blocked moves when we already have a system in place if they are relevant to the concept (see move concepts like Necturna's Sketch, as well as Equilibra's process allowing Doom Desire based on relevance to the concept).

One more thing I want to discuss regarding custom elements: we should probably avoid using custom elements to bring back a snapped move, as it can potentially be very confusing to have a move suddenly show back up, and has weird implications if the snapped move returns in the future.

EDIT: We also need to figure out where the line for modification is regarding creating elements for form changes. If we wanted to clone Stance Change, is it too much to change King's Shield to something else? Is it too much to change the biases of the forms (say physical to special instead of bulky and weak to frail and strong)? What about something like Gulp Missile? Can we change the moves it activates on, or the health threshold at which the effect changes, or what triggers the counterattack?

 

[quziel]

Posting to mainly summarize a conversation on discord.

I would like to propose the following constraints:

1) Custom Elements should be restricted unless entirely necessary (e.g. Forme Changes are typically keyed to the mon itself, allowing flexibility there is necessary beyond a simple reskin).

2) Frameworks should list the specific modifications to process that are necessary, rather than aspects of the design itself.

3) A maximum of two CAPs can be created through a process, and if multiple CAPs are created, they should share significant elements to ensure that the process proceeds smoothly. (An example is Urshifu-RS vs Urshifu-SS and Nidoking vs Nidoqueen)

4) A Framework can include minor flavor elements (see Starters), but should have some competitive basis

5) Frameworks should not reference existing pokemon, nor existing CAPs

Under this ruleset, frameworks do not directly determine the design itself, but instead help us decide what modifications to the process need to be made for the creation of the CAP(s). An example Framework would be Starter Trio, which, while implying certain things about the pokemon, is not actually the concept. Instead it requires a secondary Concept submission period, which could include elements such as Move Ability Interactions. It is worth noting that this ruleset does not necessary allow for the same diversity in frameworks that is usually present in concepts. I would expect that framework slates may not be as large as concept slates.

 

[Zephyri]

I dont really have much to say, but I wanted to try and talk about this point in Quziel's proposal:

1) Custom Elements should be restricted unless entirely necessary (e.g. Forme Changes are typically keyed to the mon itself, allowing flexibility there is necessary beyond a simple reskin).

I think this should be more restrictive, and altered to be:
Custom Elements should be restricted unless they are exact replicas of existing elements, that are unable to be added onto the CAP due to hardcoding and similar constraints (after reading through thread again, i realize that this is basically just spoo's proposal i think, so full support for that)

Standard custom elements were removed from the standard CAP process a while ago, and for good reason. For the most part, they act as copouts that a) Simplify interesting discussions
b) Remove the restrictions of CAP that allow for creative, out of the box solutions
c) Have optics issues

But there are situations (Like forme changes and hardcoded stuff) where custom elements might be useful. That's why i think custom elements should only be restricted to replicas of elements that are already in the game, because then we're abiding by gamefreak's rules for the most part and we're not introducing any "new" elements to the table.

(sorry if this was a short or rambly post i think i got everything i wanted to say across okie bye :])

 

[Birkal]

I hate to be an old curmudgeon, but I'm not very pleased with the OP of this thread, as it left out some key details and background considerations. For example, this post is the original proposal for how "framework CAPs" should be assembled, but quziel I think used the term 'framework' interchangeably with 'concept' in the OP of this thread. This thread also doesn't seek to address the reason why we made CAP25 a celebration in the first place: it was a milestone date for CAP, and we wanted to celebrate that as a community by doing something outside of our normal scope.

It seems that this thread is attempting to make framework CAPs a more regular thing. And in my opinion, there's nothing wrong with that, but we should also have a good reason for allowing frameworks. Here are a few examples I can think of to not do a framework CAP off the top of my head:

1) The metagame is in a relatively stable place right now. All of the DLC is released, and there likely aren't going to be too many metagame shifts between now and the release of CAP30. Making this next CAP a more 'zany' project could feel like a waste of a stable metagame that could make for a very solid project.​

​

2) CAP29 was probably more like a 'framework' than any other previous CAP. Through its process, we chose our ability first (never been done before), run multiple concept assessments (similar to a framework CAP), and even make flavor considerations due to the winning 600 BST stats. The CAP process essentially allows for frameworks to exist in a more limited capacity, so why extend that even further?​

​

3) This proposal is putting up a lot of red tape, to the point where it might not even feel like something special. Was doing three starters for CAP25 kind of a nightmare? Yeah, but it was what we voted on as a community. It was grueling work at times, but we ended up with some great end products and learned a lot on the way. If you're making artificial constraints (no more than X mons, limiting custom elements, etc), then why even call it a framework CAP?​

​

4) Framework CAPs take extra time. Has there been any thought put into how those 2-3 extra weeks to gather and vote on frameworks would bleed into the release of the DP remakes?​

Ultimately, I don't have too much of a horse in this race. I personally enjoy the framework process; it's why I championed it for CAP25 in the first place! I just think we need to seriously consider both sides of this debate before making a decision. CAP25 being a celebration CAP was greeted with an emphatic "YES!" from the CAP community. It feels like the consideration for CAP30 to follow a similar path has been "sure, why not?" as the previous celebration was only 3 years ago.

---

I'm going to spend the remainder of this post providing feedback to the post quziel made above from a Discord conversation to help clean it up a bit. Again, I am pretty neutral on which path CAP30 ends up taking; I just want to make sure we're prepared if we decide to go down the framework path. Like my feedback for CAP29 Concept Submissions, my feedback may seem blunt. I think quziel (and y'all) are amazing, but I want to give meaningful feedback that helps strengthen CAP.

1) Custom Elements should be restricted unless entirely necessary (e.g. Forme Changes are typically keyed to the mon itself, allowing flexibility there is necessary beyond a simple reskin).

Is this considerably different than the current guidelines on custom elements in the Framework OP? It feels like you're trying to re-invent the wheel here, only with additional red tape that prevents creativity. Your example is not very clean (what does 'restricted' even mean in this context?), and this is all probably covered well enough in the current Framework OP.

This creation will not allow any non-intuitive custom elements. This includes custom typings, abilities with entirely new mechanics, or moves with entirely new mechanics. 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.​

2) Frameworks should list the specific modifications to process that are necessary, rather than aspects of the design itself.

This is already covered in the Framework OP:

Do not refer to any part of the Pokemon's artistic design. For example, the following phrases would be illegal:​

3) A maximum of two CAPs can be created through a process, and if multiple CAPs are created, they should share significant elements to ensure that the process proceeds smoothly. (An example is Urshifu-RS vs Urshifu-SS and Nidoking vs Nidoqueen)

Needless red tape. If you polled the current CAP community about whether or not they want to make another 3 CAPs (or more) in a single process, we'd be met with an unanimous "no." People learned there lesson from CAP25, so why make this a rule that inhibits future frameworks?

4) A Framework can include minor flavor elements (see Starters), but should have some competitive basis.

This needs a lot more explanation. If a framework is supposed to have a competitive basis, then why not just make it a concept submission? How are you delineating between those two terms at this point? Newer contributors: read the CAP25 framework submissions thread before replying to this question. Submitters did post at least some competitive basis with their contributions. This is built into how CAP works; maybe it could use some clarification in the Framework OP, but a lot more than the point quziel brings up here.

5) Frameworks should not reference existing pokemon, nor existing CAPs

Yes, this is a rule that applies to all CAPs in general. It is missing from the OP though, so perhaps it should be included.

Under this ruleset, frameworks do not directly determine the design itself, but instead help us decide what modifications to the process need to be made for the creation of the CAP(s). An example Framework would be Starter Trio, which, while implying certain things about the pokemon, is not actually the concept. Instead it requires a secondary Concept submission period, which could include elements such as Move Ability Interactions. It is worth noting that this ruleset does not necessary allow for the same diversity in frameworks that is usually present in concepts. I would expect that framework slates may not be as large as concept slates.

Overall, my biggest critique is that this post seems like it's trying to invent a Framework process, when it already exists. Why not make a proposal about how to edit the OP of the previous framework thread and we work from there? A lot of thought went into that OP by the CAP moderators and the Policy Review Committee, and I think it's generally usable as a baseline for future Framework processes. Again, my critique here is meant to be constructive so that we can build a better CAP process in the future for all of us. Any vagueness or confusion at this stage will create massive headaches later on, so it's better to address them now than when we're halfway into a process.

 

[Brambane]

So I am obviously not quziel, so everything I say below is from my own interpretation of the proposals and the Framework process. I also don't really have much of a response to every point in Birkal's post because some of them I really don't have a take on/seem to an expression of Birkal's opinion, which I am not here to call shit.

It seems that this thread is attempting to make framework CAPs a more regular thing. And in my opinion, there's nothing wrong with that, but we should also have a good reason for allowing frameworks. Here are a few examples I can think of to not do a framework CAP off the top of my head:

1) The metagame is in a relatively stable place right now. All of the DLC is released, and there likely aren't going to be too many metagame shifts between now and the release of CAP30. Making this next CAP a more 'zany' project could feel like a waste of a stable metagame that could make for a very solid project.

I think this confuses "zany project" with "zany creation." I don't think a framework is going make a project any more likely to creating some meta-defining CAP anymore than a regular process. Frameworks seem to be of either three varieties: an alteration to process order, creating multiple mons in one project (assuming you consider form changes as a separate entity), or some form of restriction. Sometimes these are combined. Starters restricted typing and BST while also creating multiple Pokemon, for example. It's not like a framework creation is inherently more likely to imbalance the meta.

2) CAP29 was probably more like a 'framework' than any other previous CAP. Through its process, we chose our ability first (never been done before), run multiple concept assessments (similar to a framework CAP), and even make flavor considerations due to the winning 600 BST stats. The CAP process essentially allows for frameworks to exist in a more limited capacity, so why extend that even further?

Because concepts have limited capacity which doesn't reach the general interests of the community to explore alterations in the standard CAP process, thus frameworks are a solution. An while you could expand the scope of concepts, I think one of the boons of a frameworks is using it to interact with the concept stage. Using the same example you did with Chromera, let's say we do the framework "Ability First." You can bet your bacon that the concept stage would be justifying how exploring ability first would interact with their concept. Consider past concepts like "Momentum" or "Ultimate Weather Abuser," and how different the approach would be with ability first. That kind of exploration of the CAP process is what I think frameworks should achieve, and establishing it before concepts allows us to submit concepts we think best compliment that process.

3) This proposal is putting up a lot of red tape, to the point where it might not even feel like something special. Was doing three starters for CAP25 kind of a nightmare? Yeah, but it was what we voted on as a community. It was grueling work at times, but we ended up with some great end products and learned a lot on the way. If you're making artificial constraints (no more than X mons, limiting custom elements, etc), then why even call it a framework CAP?

I am unsure what this point is trying to say. Is it arguing that we should have no limitations to Frameworks, or I think its suggesting that adding constraint somehow impedes the creative process to the point that it is no longer enjoyable? Either way I disagree. I think the proposed limitations are to keep consistent as possible with CAP's stance of custom elements for Pokemon while still facilitating form changes (which there is considerable interest in from the community for both a flavor and gameplay perspective), and to keep the projects scope to a reasonable scale (the proposed number for reasonable being a max of 2, which I agree.) I also think there is more to frameworks than number of mons, modifying an existing creation by giving it a new form/evolution, and custom elements, which seem to be the only things really being addressed by the proposal referenced. The Starters are good example of how a constraint creates something interesting, since starters were incredibly restrictive (forced to have Overgrow/Blaze/Torrent, forced Grass/Fire/Water, forced BST, limited to 2 abilities max.)

4) Framework CAPs take extra time. Has there been any thought put into how those 2-3 extra weeks to gather and vote on frameworks would bleed into the release of the DP remakes?

Considering how little information we have in regards to DP remakes (and how they might impact SwSh metagame, if they interact with it at all) I would disagree letting us get too concerned with the new games. We shouldn't restrict the creative process because Game Freak MIGHT do something to affect the meta. Maybe the DP remake hype could overshadow CAP30 regardless if we pick a framework or not, since we can expect some more information about the games coming out sometime this summer while CAP30 is going on. But I think a framework might help keep interest in that case!

Is this considerably different than the current guidelines on custom elements in the Framework OP? It feels like you're trying to re-invent the wheel here, only with additional red tape that prevents creativity. Your example is not very clean (what does 'restricted' even mean in this context?), and this is all probably covered well enough in the current Framework OP.

I think they both say the same thing effectively, since "non-intuitive elements" is also purposely vague in the same way as using the phrase "restricted unless entirely necessary:" it gives whoever is designing the framework slate the agency to recognize some ridiculous custom element proposal and give it the axe. So agreed that the current Framework OP covers it well, but disagreec that its adding red tape.

This is already covered in the Framework OP:

I interpreted design in the quziel's proposal as the Framework's design, not anything related to art. The rule of listing modifications is to say either what exactly about the process the framework is changing (i.e. process order, number of creations) or what kind of restraints are being placed on the process (i.e forced to have Overgrow/Blaze/Torrent, forced Grass/Fire/Water, forced BST, limited to 2 abilities max.)

Needless red tape. If you polled the current CAP community about whether or not they want to make another 3 CAPs (or more) in a single process, we'd be met with an unanimous "no." People learned there lesson from CAP25, so why make this a rule that inhibits future frameworks?

While true for the current CAP community, this rule accounts for a theoretical influx of new contributors (say someone makes a really popular Youtube video about CAP and suddenly interest surges) as well as future changes in the community composition as older users eventually leave. If future communities want to cut this red tape, they could, but for now its just insurance against a sudden influx of new voters/returning users who never experienced making 3 CAPs at once (like me!)

This needs a lot more explanation. If a framework is supposed to have a competitive basis, then why not just make it a concept submission? How are you delineating between those two terms at this point?/

Because concepts have limited capacity which doesn't reach the general interests of the community to explore alterations in the standard CAP process, thus frameworks are a solution. An while you could expand the scope of concepts, I think one of the boons of a frameworks is using it to interact with the concept stage. Using the same example you did with Chromera, let's say we do the framework "Ability First." You can bet your bacon that the concept stage would be justifying how exploring ability first would interact with their concept. Consider past concepts like "Momentum" or "Ultimate Weather Abuser," and how different the approach would be with ability first. That kind of exploration of the CAP process is what I think frameworks should achieve, and establishing it before concepts allows us to submit concepts we think best compliment that process.

I interpreted design in the quziel's proposal as the Framework's design, not anything related to art. The rule of listing modifications is to say either what exactly about the process the framework is changing (i.e. process order, number of creations) or what kind of restraints are being placed on the process (i.e forced to have Overgrow/Blaze/Torrent, forced Grass/Fire/Water, forced BST, limited to 2 abilities max.)

Same reasoning I had as before. Also I think this post does a good job defining what differs between a good framework submission and a concept submission shoehorned into a framework.

 

[spoo]

okay so, I thought it would be worth elaborating some on my previous post, especially in light of some recent discussion; I will probably be retreading some ground so apologies in advance if that happens. I also understand that this isn't totally within the scope of the original proposal, so I also apologize for hijacking this thread a bit, however, I think the discussion of whether cap30 should be a framework and the discussion of whether we should incorporate frameworks more regularly are tied together in many obvious ways. so, to get into it,

why should we incorporate frameworks more regularly?
well, I think quziel honestly summed this up quite nicely in the OP:

Framework CAPs are something that really helps to bring excitement to the project, are fun (this is very important), and give us a chance to explore our boundaries as a project by ignoring some of our usual rules on process and concepts.

CAP is something we all do because we enjoy it, and frameworks are an embodiment of that. bending the rules on occasion and taking on a bigger, more ambitious project can be massive for community activity and engagement, and allows the project so much more freedom to create something genuinely new and exciting. the entire "framework" structure itself is quite literally going to waste at the moment, because there is no sufficient reason for us to implement it right now and no clue for when the next chance could be, whether that be an important anniversary or something different. do we really want to wait for the next "celebration" cap for the chance to use a framework? I don't believe that there is a good reason for us to wait until a super special occasion to once again implement this feature of the project; it already exists for us to use, there is a growing desire in the community to do it again, and the cost of doing so is not that high. what I am arguing here is essentially that frameworks are good for the project as a whole, that we should seriously consider implementing them on a more regular or expected basis, and in doing so decouple frameworks from "celebration" caps as their own separate entity to use whenever.

so now the question becomes, when is a good time for frameworks to happen?
I went over this briefly in my other post, but neglected to mention a couple alternative ideas (the post was admittedly a bit rushed), so thank you to kjn for bringing them up; I think making every 5th cap a framework or every Xth cap of the generation are probably our best bets. frankly I don't think either are perfect options, as it's definitely possible that, say, cap35 ends up at a really strange time wrt generational releases or even maybe in an unstable metagame, while it's also possible that maybe cap40 is the last CAP of generation 9 while cap44 is the first of generation 11 which also would not be ideal (the numbers themselves don't really matter, just the general idea). there is also the option of just setting a "one framework per generation" rule, and having moderators/the PRC decide when that happens based on metagame state and other general factors that affect timing. I think I favor the previous two options, as I appreciate setting people's expectations in the right place and having fewer hoops to jump through when it comes time for a framework to happen, but I am warming up to the idea of just doing it when the time is right, as that's probably the "safest" option when it comes to the project's success and allows for the most flexibility.
this also brings me to this point made by birkal:

Here are a few examples I can think of to not do a framework CAP off the top of my head:

1) The metagame is in a relatively stable place right now. All of the DLC is released, and there likely aren't going to be too many metagame shifts between now and the release of CAP30. Making this next CAP a more 'zany' project could feel like a waste of a stable metagame that could make for a very solid project.

this reasoning seems counterintuitive to me. if we accept that doing a framework is a substantial increase in the ambition and scope of a project, and also presents a larger risk for the end product's viability/conceptual success, then it absolutely makes sense that a stable metagame is the ideal time to do it. it is exactly because the metagame could make for a solid project that we should look at doing a framework, as doing a framework in a shaky and unstable metagame could very well lead to disaster.

this is all to say, yes, cap30 should be a framework, but we should also be looking beyong cap30 to see how frameworks can be utilized in the future. if we go through with this, I think it would also be wise to re examine the initial proposal for frameworks to see what could be changed. I wasn't aware of this proposal until birkal brought it up, and it does seem to be competing with the OP in a couple ways, so it may just be easiest to take the original proposal and refine it.

 

[MrDollSteak]

I don't have all too much to add that hasn't already been said at some point, except for the fact that I think a loose aim for one framework towards the end of a generation is worth trying to cement. Part of the reason that I suggest this is that over the course of a generation as more and more gets explored, concepts will naturally start becoming more ambitious to feel interesting and fresh. I think that having a framework at a similar point allows more flexibility for fleshing out interesting concepts that can't really be done at the strat of a generation when there are too many unknown variables, especially if future generations follow Gen 8's example.

As for CAP 30, I think that this fits perfectly, and has a pretty serendipidous occasion in being a fairly landmark number in 30, as well as the fact that it will more or less coincide with the release of Brilliant Diamond and Shining Pearl. Considering that CAP itself began as a project in Generation 4, I think that this is a particularly momentous time to reflect upon CAP's history, and try something more out of the ordinary. While I do understand that CAP 29's process to many extents might have felt like a framework in terms of stage order revision, the use of previously banned abilities and an end-product that is for all intents and purposes a Legendary, I do think that a framework still offers more room to try something new, and doubt that people are waiting for a more usual and tame process. If anything, I think considering how exciting Chromera's process was, it would probably be quite disappointing to move back to a more classic CAP process. Unlike what occurred with CAP 25, I don't think contributors are feeling stretched thin or burnt out by Chromera, as it didn't drag on in the same way, and of course relied on less investment.

As for the specific limitations on concepts, I think that letting the TL have some discretion in regards to interpreting the submitted frameworks isn't a bad idea, as at the end of the day even if some are primarily flavour oriented (as in the case of the Starters from 25) so long as the potential for high quality discussion exists I don't think we should be banning them on technicalities. Something like 'Normal-type CAP' I would argue does not really fit this category, even if it is currently legal, not necessarily because it more or less invalidates a whole stage, but because it doesn't really provide a whole lot of meaningful discussion for the future stages. I think the comparison to something like Equilibra's process makes this clear, where in as much as Doom Desire was chosen, a Steel-type was all but guaranteed, the discussion was still firmly centered around an interesting mechanic. While there is an opportunity for a Normal-type framework to then be paired with an interesting concept, I think it is still rather vague and would rather see it paired with something else to frame discussion.

 

[Brambane]

Discussion has fizzled, and the question that keeps popping up on Discord is "Do people even want to do a framework for CAP30?" I would like to see a general vote on Framework or No Framework so we can put that question to rest.

 

[kjnjkmjk1]

Now that we've officially decided to do a framework for CAP30, I would like to suggest pumping the brakes on deciding to make frameworks a regular thing for now. In this thread, we have already begun discussing a number of modifications to the original framework structure (restricting the number of Pokemon that can be made, eliminating custom elements except for very small exceptions, requiring some competitive basis for a framework). We have no idea how any of these will go over once we start, particularly eliminating custom elements, as a pretty sizable number of frameworks from CAP25 were rooted in creating a custom element, and this limitation is a notable departure from the much more open original framework proposal. On top of this, if the Discord conversations are any indication, we will be spending a lot of time trying to figure out what to do with just CAP30, and I think we should prioritize settling this for now, with a discussion on whether to create a regular schedule for frameworks being settled afterward.


In an effort to practice what I preach, I want to make a point about how we should structure the frameworks section of the process.

As opposed to the suggestion in the OP, which has the TL nominated before framework submissions, I think we should continue to have both TL and TLT nominations after framework submissions. This allows us to avoid scenarios where a TL is stuck with a framework they are not ready to take on. While you could argue that, if someone applies to TL a framework CAP before frameworks start, they should already acknowledge that there is a risk of very large projects, there is also the issue that TLs that would be willing and able to handle smaller frameworks would get scared away from applying for TL if there was a risk of getting handed larger projects, which can compound with the already tiny pool of TL applicants (a reminder that all three CAPs this generation have had exactly two candidates each, and this is for regular processes).

As a consequence, continuing to slate every framework, as was done for CAP25, seems like the best option. I'll admit that it seems like it would turn into a slog for voters to dig through (I was not around for that poll); even if we implement all of the proposed restrictions and shrink the number of options, the number of options will still be considerably higher than the average slate. This is potentially compounded by the fact that likes will be enabled, increasing the risk that voters just use the number of likes as a filter for what framework submissions they actually pay attention to, rather than considering them more carefully. On the other hand, I have been told that it's easier to go off of the more straightforward names and descriptions compared to concepts or other "slate-all" polls, so this may be less of an issue. If we are without a TL to oversee the creation of a framework slate, I am not a big fan of our other options (having the mods somehow construct a slate, or making the requirements for a submission much stricter, potentially even stricter than quziel's proposal), so slating everything may continue to be the best option.


Also making some minor comments on quziel's proposal:

Frameworks should list the specific modifications to process that are necessary, rather than aspects of the design itself.
I agree with this, although I am mostly confused why this is an "instead". I agree with the principle of requiring people to explain how the framework changes the process, but I feel like adding the requirement is sufficient without then excluding this part about "aspects of the design itself", unless "design" means the artistic design, in which case we are already covered.

Frameworks should not reference existing pokemon, nor existing CAPs
I'm fine with the existing Pokemon part of this (as Birkal pointed out, it's already a standard rule for CAPs), although it would be nice to get a few more opinions on the existing CAPs part. The collateral for this rule is additional/regional evolutions (which has the problematic consequence of allowing presumably OU-level Pokemon hold Eviolite), regional forms, and split evolution. These ideas do get mentioned from time to time, but the cans of worms that could be opened as a result of these concepts (especially since we now have a buff process in place) is potentially not worth letting these frameworks through.

In general, I'm a bit split on the harder restrictions here (no customs except when absolutely necessary, max of 2 CAPs, frameworks must have competitive implications). I can definitely understand why they are being suggested, particularly with the max of 2 CAPs aiming to avoid the issues that happened during CAP25, but I also see the view that Birkal has established that the voters will most likely self-regulate without us placing these restrictions for them, and that it does have an effect on the spirit of frameworks by taking their intentionally broad scope and shrinking it. Ultimately, I'd like to see more discussion on this.

 

[quziel]

So, we're doing a framework CAP, which means a lot of rules need to be set:

We will adhere to the following for the duration of CAP25:

• This Pokemon will be playable in the CAP Metagame. Furthermore, it will be reasonably balanced for competitive battles, specifically not a broken threat that negatively centralizes the metagame.
• The creation of this Pokemon will ONLY break CAP creation guidelines based on the Framework we select. For example, if we choose to create a Pokemon with an illegal ability as our Framework, we will not also allow a custom move for it during Movepool Submissions.
• This creation will not allow any non-intuitive custom elements. This includes custom typings, abilities with entirely new mechanics, or moves with entirely new mechanics. 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 creation will be designed with positive optics in mind. As this Pokemon will join the past 24 Pokemon in our playable metagame, it needs to be something we are proud of presenting to the public.
• This Pokemon will have a Framework that alters, at maximum, two stages of the process. An example of this would be a framework that dictates CAP25's typing and primary ability. An illegal Framework would also mandate a specific stat bias on top of those restrictions. Furthermore, the two stages trivialized must be linked (e.g. an Ultra Beast that requires Beast Boost and a 570 BST).

For a fully detailed list of reasoning for each of these rules, please consult this thread. Other rules that will continue for Framework Submissions are as follows:

• One submission per person. You may edit your Framework, but you may not change the fundamental premise after it has been posted. If editing your Framework, please edit the original post instead of posting a new revision. Do not bump your Framework after you have posted it. If people do not comment on it, so be it.
• Do not duplicate or closely-resemble Framework already posted by others. It is your responsibility to read through all previous submissions in this thread to ensure you are complying with this rule. Ignorance or laziness is not an excuse.
• Do not refer to any part of the Pokemon's artistic design. For example, the following phrases would be illegal:

"This is a bright blue Pokemon..."
"The Pokemon looks like a..."
"The Pokemon uses its long tail to..."

• A Framework Submission must be submitted in the proper format. The format is described below. If the proper format is not used, the moderators will not evaluate the submission, regardless of content.

Framework Submission Format

Use this format for all concept submissions: Here is the format with tags. Just copy/paste this into your post, and fill it out:

• Name - Unlike Concept Submissions, your name CANNOT be anything cutesy. Please list EXACTLY which process rule(s) you intend to break with the name. Some examples would be "Multitype CAP" and "Ultra Beast CAP."
• Description - This is the official description of the concept, and must follow ALL the content rules listed above. Do not make this a long description. Long descriptions are invariably too specific or too convoluted. Keep it short. Any more than a sentence or two is TOO MUCH. Do NOT include your Explanation of the concept in the Description. See "Explanation" below.
• Explanation - This can contain just about anything. This is where you can explain your concept without restraint. You may make suggestions, even specific suggestions, regarding the possible implementation of the Framework. This explanation should help facilitate discussion of the Framework -- but the Explanation is NOT part of the Framework and will be omitted from the polls and any future use of the Framework. Since your explanation is non-binding, regarding future polls and threads, it will not be evaluated for purposes of determining if your Framework is legal or illegal. Although it is tempting, refrain from making too long of an explanation; it will deter readers from fully considering your Framework.

It is the submitter's responsibility to figure out how to make a legal submission within the rules listed above. Do not complain about the difficulty of making a submission in this thread. There are many, many legal Frameworks that can be presented within the rules. The Framework is a very basic guide for the creation process. It is hard to provide solid concept descriptions without basically designing the entire Pokemon right off the bat. Submissions should be written and chosen very carefully to avoid these problems.

In one week's time, the CAP moderators will make a large slate of CAP25 Frameworks into a large, multibold vote, similar to Art Poll 1. In order to be slated, make sure that you are following the guidelines listed above.

Best of luck, and enjoy our celebration!

The above is the previous OP for the Framework submissions in CAP 25. I propose the following changes:

1) Change Custom Elements:

Init:
This creation will not allow any non-intuitive custom elements. This includes custom typings, abilities with entirely new mechanics, or moves with entirely new mechanics. 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.

Change:
This creation will not allow any large-scale custom elements. This means that custom typings, fully custom abilities, or fully custom moves will be disallowed. Any changes must be entirely flavor (eg renaming), or minor changes to existing moves/abilities. An ability that swaps defensive stats with offensive stats when using the move Spiky Shield would be allowed, however an ability that summons a new terrain effect would not be.

Comments: This change is one I expect to be controversial, as many believe that any custom elements should be shunned, but if a forme change framework is selected, I think allowing a small amount of freedom could be helpful. I am open to restricting this to remove any/all custom elements.

2) Remove Positive Optics:

I am in favor of striking this rule; it does not inform concepts much and imo appears to be a way for the TL to just strike frameworks arbitrarily.

3) Add in Work Issues:

Add in:

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. For example, creating an entire starter trio was too much work in the past, but creating a pairing along the lines of Nidoking and Nidoqueen would be allowable.

Comments: This is here to ensure that we are able to adequately process the framework; starters in the past are generally agreed to have been too much work, and it shows. By restricting it to very similar creations we do allow some deviation from the norm, but also won't burn out contributors out.

---

Please give any comments.

 

[Brambane]

I think these are good changes to the Framework work OP. I am also in support of the custom elements change. There are a lot of cool Pokemon mechanics (i.e. form changes, especially those tied to abilities) that are worth exploring. Allowing some degree of customization really benefits the creative and development process, particularly by removing some artistic restrictions tied to things like Hunger Switch or Shields Down.

 

[Mova]

I also agree that these are good changes to the Framework Submissions OP. There are several possible reskins of hard-coded abilities that are worth exploring and elaborating upon further. Stance Change is but one example of this, but the reskin can use Spiky Shield instead of King's Shield. This is only one example above the tip of the iceberg, but it is also a possibility.

 

[kjnjkmjk1]

For the first change, people seem to be in favor restricting customs to some degree to be more in line with how normal processes work, and I think this is an OK compromise, although it would be nice to have another example. Would a Special Attack version of Huge Power or a Special Defense version of Body Press be out of the question, since those aren't exactly large-scale but aren't directly in the game?

For the second rule, I see the argument that it's somewhat redundant with existing CAP rules and is less necessary with the proposed restrictions in place, but I don't think it's completely necessary to strike this, as it serves as a reminder to not get too crazy with frameworks. I ultimately don't feel that strongly about this rule, though; if people want to strike it, then fine.
I do want some clarification about this part here:

imo appears to be a way for the TL to just strike frameworks arbitrarily.

I would like some clarification about whether we are doing TL voting before or after frameworks. The statement seems to imply that the TL voting will happen before frameworks so that they can actually strike the frameworks from the slate (striking the framework after it's been selected is an entire different can of worms). I made this point earlier, but even if it is decided to separate TL applications and TLT applications, per this PR thread, I'm currently still in favor of having the TL picked after the framework is selected, as was done for CAP25, as I think it's more important for the TL to completely understand what restrictions they are working with before they sign up. In theory, if a TL is selected beforehand, they can exert some control by selecting frameworks for a slate, but they could still get stuck with something they aren't completely ready to take on but slated due to popular demand.

The third rule I don't really have objections to, given how CAP25 seems to be universally hated from a logistics standpoint.

 

[Amamama]

I think the proposed additional ruleset is fine.
I do think that the language of rule one needs clarification.
I think it’s not exactly clear what qualifies as minor from the proposal.
The example given clearly is meant for a „reskin“ of Stance Change with a slight modification to its mechanics, namely its trigger.
I want to ask if something like any Form Change on move trigger (eg: fast<>bulky, High Atk<>High SpA), would be allowed as minor or if it has to be specifically Defensive <>offensiven case of a stance Change reskin?

Or rather, Again considering Stabce Change.
The Ability has three elements which are: Form A<>Trigger<>Form B. Would a minor change mean only changing any one of these parts? Or even only allowing one particular part to be changed?
What about changing one part of a move?
If we consider these the parts:
Type-BP-Bias-Priority-Primary Effect-Secondary Effect
Would be any of these be allowed or just some. Which would be minor which would be major etc? Can more than one part be changed?
Edit: Can the distinction of major minor be conditional of its other traits (eg changing priority on a 120BP move vs. 40BP)
Would we be allowed to edit items?

Edit: And last but not least, does the alteration need to be defined in the framework or can it be „random“/chosen freely.

 

[snake]

I would like some clarification about whether we are doing TL voting before or after frameworks. The statement seems to imply that the TL voting will happen before frameworks so that they can actually strike the frameworks from the slate (striking the framework after it's been selected is an entire different can of worms). I made this point earlier, but even if it is decided to separate TL applications and TLT applications, per this PR thread, I'm currently still in favor of having the TL picked after the framework is selected, as was done for CAP25, as I think it's more important for the TL to completely understand what restrictions they are working with before they sign up. In theory, if a TL is selected beforehand, they can exert some control by selecting frameworks for a slate, but they could still get stuck with something they aren't completely ready to take on but slated due to popular demand.

You just beat us to this. In discussing CAP30 and how it's a framework, CAP Moderators would like to try a variation of the separate TL and SL applications. Here is the sequence of events we'd like to propose for the beginning of CAP30:

1. Finalize the Framework Submissions OP in this thread.
2. Post CAP30's TL nominations (only TL) and then poll after noms close.
3. Post Framework Submissions. TL will slate 5-8 frameworks, the usual number range of items that goes onto a slate. CAP Moderators will review slate to ensure that the frameworks indeed fall within the bounds of the Framework Submissions OP. Then, we'll poll the slated frameworks with the usual voting process.
4. Post CAP30's SL nominations and then poll after noms close.
5. Post Concept Submissions. TL will slate 5-8 concepts as usual. Then, we'll poll the slated concepts with the usual voting process.

In our discussion, we noted that the TL should have some control of the project they'll be working on, similar to concept submissions. However, SL nominations and voting will occur after the framework is chosen because it'll be more obvious how the individual stages will change once the framework is chosen (though the stage changes / order might not be finalized until after concept assessment, potentially).

What does everyone think of this? Thoughts, comments, questions, concerns? I'd like to have an open discussion on this plan - is it a good one? Are there problems? We'll have to close the separate TL/SL applications PRC thread also, but I figured framework scheduling fit better here than it would in the other thread.

 

[MrDollSteak]

I'd like to speak to Point three of Snake's post "Post Framework Submissions. TL will slate 5-8 frameworks, the usual number range of items that goes onto a slate. CAP Moderators will review slate to ensure that the frameworks indeed fall within the bounds of the Framework Submissions OP. Then, we'll poll the slated frameworks with the usual voting process." in order to hopefully assuage any concerns that any users might have and to explain why we reached this consensus.

The first thing I'd like to bring up is, if anyone has had the chance to look over CAP 25's framework stage, it should be obvious that the first poll with its 20+ options was really quite unwieldy. Furthermore, it's clear to see that even with having such a massive poll a ton of options were culled almost immediately. While it's not really my place to determine the viability of such frameworks, I think it's clear that many of these were culled for being not particularly interesting, in the sense that a majority of them were standard mandate a type, ability or move that were in themselves not particularly flavorful, or something that could realistically happen during a concept. The second poll only included the top 7 anyway, so realistically what starting off with 5-8 chosen by a TL will accomplish is ensuring that the second and third polls are narrowed down to be more representative, such as three, then two. In comparison to the 30+, 7, 3, winner approach that happened with 25.

Secondly, the benefit of having the TL choose frameworks that appeal to them, similarly to concepts, is that if there are two or three or even four that engage with a similar gimmick, for example the difference between like Nidoqueen/Nidoking counterparts to Gyarados/Milotic counterparts to a divergent evolution like Slowbro or Slowking, rather than having all three distract the voting, the topic leader is able to pick the one with the most merit to give it a fairer representation. Plus, considering that with many of these particular examples the difference is primarily in regards to flavour, it is still possible that following the actual framework discussion or concept discussion phases the choice to make them related or not can be made later.

Finally, by allowing the TL to choose the frameworks, we're able to ensure that we're not going to have a TL that's unprepared to deal with what comes up. If there are some truly ludicrous frameworks that they don't feel comfortable approaching, as much as it sucks to have it left off the slate, it makes it so we're not stuck with one that forces us to lose motivation and momentum trying to make it work as occurred with the starters.

On an unrelated note - I'd like to propose a minor amendment to the line "This Pokemon will have a Framework that alters, at maximum, two stages of the process. " to instead state " This Pokemon will have a Framework that constrains the results of, at maximum, two competitive stages of the process." What this clarification in my mind effectively allows, is for frameworks that alter how every stage operate, for example with some extreme examples like 'randomly-generated slate' or 'there are no discussion questions for this stage and users are instead free to submit whatever they like and argue for them,' while continuing to ensure that a framework can't outright limit the results of multiple stages by saying something like 'Early route Normal-type with Strong Jaw and a maximum BST of 450." I think the benefit of opening up the former is that we can really attempt a very different CAP experience without specifically predetermining the results, with the framework being less of an alteration of the end-product, and more of an alteration of the process itself. As for clarifying the latter, the Starters were an example of how far you can effectively take it, with the results of typing forcing, Grass, Fire and Water at the very least respectively, and a maximum BST of 535. While the Primary and Secondary abilities are also forced to be Overgrow, Blaze and Torrent, they can in a sense be treated as mostly flavour abilities than anything else, and still allowed for flexibility with the Hidden Ability as the competitive ability discussion.

 

[Mx]

The CAP Mod team is currently planning to begin the TL applications for CAP 30 this Friday, which will last for 72 hours. In the meantime we will be finalizing the details regarding how we'll handle the frameworks, so if you have any additional suggestions please post them soon.

 

[Mx]

Before we start the TL Applications, here's the final look at the Framework OP, which contains all rules that have been decided for CAP 30:

WARNING
The following thread is intentionally designed as an offshoot of the typical Create-A-Pokemon Project. If you are new to the CAP Project, please read through previous processes to gain a full understanding of what is different here.

Join us on Discord if you have any further questions!​

As per this PR thread, we will be using a Framework for this project. We will adhere to the following rules for the duration of this process:

• This Pokemon will be playable in the CAP Metagame. Furthermore, it will be reasonably balanced for competitive battles, specifically not a broken threat that negatively centralizes the metagame.
• The creation of this Pokemon will ONLY break CAP creation guidelines based on the Framework we select. For example, if we choose to create a Pokemon with an illegal ability as our Framework, we will not also allow a custom move for it during Movepool Submissions.
• This creation will not allow any large-scale custom elements. This means that custom typings, fully custom abilities, or fully custom moves will be disallowed. Any changes must be entirely flavor (eg renaming), or minor changes to existing moves/abilities. An ability that swaps defensive stats with offensive stats when using the move Spiky Shield would be allowed, however an ability that summons a new terrain effect would not be.
• This Pokemon will have a Framework that constrains the results of, at maximum, two competitive stages of the process. An example of this would be a framework that dictates our typing and primary ability. An illegal Framework would also mandate a specific stat bias on top of those restrictions. Furthermore, the two stages trivialized must be linked (e.g. an Ultra Beast that requires Beast Boost and a 570 BST).
• 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 2 of the exact same typing combinations, set of abilities, statlines, and full movepools.

Additionally, please follow these rules when posting in this thread:

• One submission per person. You may edit your Framework, but you may not change the fundamental premise after it has been posted. If editing your Framework, please edit the original post instead of posting a new revision. Do not bump your Framework after you have posted it. If people do not comment on it, so be it.
• Do not duplicate or closely-resemble Framework already posted by others. It is your responsibility to read through all previous submissions in this thread to ensure you are complying with this rule. Ignorance or laziness is not an excuse.
• Do not refer to any part of the Pokemon's artistic design. For example, the following phrases would be illegal:

"This is a bright blue Pokemon..."
"The Pokemon looks like a..."
"The Pokemon uses its long tail to..."

• A Framework Submission must be submitted in the proper format. The format is described below. If the proper format is not used, it will be considered invalid, regardless of content.

Framework Submission Format

Use this format for all concept submissions: Here is the format with tags. Just copy/paste this into your post, and fill it out:

• Name - Unlike Concept Submissions, your name CANNOT be anything cutesy. Please list EXACTLY which process rule(s) you intend to break with the name. Some examples would be "Multitype CAP" and "Ultra Beast CAP."
• Description - This is the official description of the concept, and must follow ALL the content rules listed above. Do not make this a long description. Long descriptions are invariably too specific or too convoluted. Keep it short. Any more than a sentence or two is TOO MUCH. Do NOT include your Explanation of the concept in the Description. See "Explanation" below.
• Explanation - This can contain just about anything. This is where you can explain your concept without restraint. You may make suggestions, even specific suggestions, regarding the possible implementation of the Framework. This explanation should help facilitate discussion of the Framework -- but the Explanation is NOT part of the Framework and will be omitted from the polls and any future use of the Framework. Since your explanation is non-binding, regarding future polls and threads, it will not be evaluated for purposes of determining if your Framework is legal or illegal. Although it is tempting, refrain from making too long of an explanation; it will deter readers from fully considering your Framework.

It is the submitter's responsibility to figure out how to make a legal submission within the rules listed above. Do not complain about the difficulty of making a submission in this thread. There are many, many legal Frameworks that can be presented within the rules. The Framework is a very basic guide for the creation process. It is hard to provide solid concept descriptions without basically designing the entire Pokemon right off the bat. Submissions should be written and chosen very carefully to avoid these problems. If you have any doubts about anything, feel free to contact a Mod via PM or Discord and we will answer your questions.

At the end of this discussion, the TL will select a slate of Frameworks. The CAP Mod team will perform a final legality check of the slated frameworks. Those that pass will then go to a poll, where the winning submission will be decided.

 

[quziel]

This is perhaps the definition of last minute, but I'd like to argue that we should change the OP to:

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, with the remaining stages having at least 2 heavy similarities (eg at least one shared typing, at least one shared ability, etc).

 

[dex]

This is perhaps the definition of last minute, but I'd like to argue that we should change the OP to:

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, with the remaining stages having at least 2 heavy similarities (eg at least one shared typing, at least one shared ability, etc).

I really like this change, I think it frees certain multimon concepts to be more inclusive of some of the ideas going around Discord while not being too open-ended.