Policy Review Frameworks and CAP 35

[spoo]

With CAP 35 quickly approaching, I think it’s about time to have a broad conversation about frameworks, and whether or not we want to continue this informal tradition (if you can even call it that) of every fifth process being a framework CAPs after CAP 25’s starters and CAP 30’s Venomicon forms.

Frameworks are a pretty contentious subject from my experience. A lot of people enjoy them and think they’re a valuable opportunity to explore parts of game design that we’d normally never be able to. (I’m personally in this camp.) Many other people think that the extra workload of frameworks, and the various problems that come with it like contributor burnout, throwing off the process timeline, and metagame ramifications of releasing these highly experimental mons, just simply aren’t worth it. These are all fair points.

As for what even is a framework––well, it’s hard to definitively say. We do have some rules for what counts, but they are not super specific or well-documented. Frameworks generally come in the form of a restriction that changes the very foundation of the CAP process’s rules, differing here from a normal CAP concept that just provides a central idea, goal, or direction for a Pokemon's creation. The frameworks of CAPs 25 and 30––a starter trio, and Giratina-style forms, respectively––don’t actually offer a clear direction or competitively-minded goal in the same way that previous concepts like “Offensive team support” or “Optimal Doom Desire user” do. But the line here is not always clear. Just one look at previous framework submission threads will show you that not everyone is on the same page as to what a framework truly is––or *should* be. Many submissions are either better categorized as concepts, are illegal or outlandish submissions, or are legal but boring flavor-centric submissions (e.g. make a Route 1 Bug-type). Many submissions also lean heavily into pursuing custom elements, something that CAP normally tries very hard to stay away from, but makes certain exceptions for when it comes to frameworks (e.g. Venomicon-Epilogue's custom unremovable item Vile Vial that parallels Griseous Core). This aspect of frameworks that allows for certain custom elements is something that polarizes opinions about this topic even further.

Are frameworks worthwhile to continue pursuing? If they are, do we need to change the current rules around frameworks to allow them to run smoother? And maybe most importantly––should CAP 35's process be a framework? These are the main questions I'm hoping to get answered in this thread.

=====

Okay, taking off my TL hat and putting on my regular contributor hat, I'd also like to suggest a proposal that answers these questions. Despite my pro-framework personal leanings, there are definitely problems with the current structure, some of which I've outlined already. Bear in mind that some of these points below are very subjective; other users may see additional problems, or disagree that these are problems at all.

1. Frameworks are a lot of work. TLT and contributor burnout is something I have experienced and don't take lightly.
2. Because frameworks take additional time, our process schedule and tournament schedule are left playing catch-up, sometimes for the whole year, even possibly bleeding into the next year's schedule.
3. I am adamantly opposed to most custom elements. Minor things such as Venom-E's item, or "reskins" of hard-coded elements that already exist in the game, are fine with me, but otherwise I think custom elements are terrible. The current rules are also somewhat ambiguous as to which custom elements are actually allowed.
4. Many of the framework submissions last time lost the plot. If we apply a more narrow definition of frameworks (which I would argue is better), the actual pool of total legal frameworks is probably quite small. And even within this small pool, there are only a handful of legal frameworks I would personally be interested in exploring.
5. Balancing multi-mon releases really sucks. Venomicon was made at the end of SS when the tier was quite stable, and still resulted in two largely overtuned products that took a long time to balance. We're currently in a less-stable period of much more volatile generation than SS. Our track record so far has not been amazing with Hemogoblin and Chuggalong both being very broken on release.
6. Running a framework every fifth CAP is not sustainable long-term. I'd rather resign than oversee a framework process at the start of the generation or during a DLC drop. Just a total mess.

With these issues in mind, here is my proposal.

• Addressing point 2: start framework processes slightly sooner than normal. Heavily timebox the projects to stay on track. 7 days for each discussion thread, two days of voting, and run polls on time. Miasmaw's process is a good example of this strategy working well, though this admittedly requires more diligence from the mod team and TLT.
• Addressing points 1, 2 3, and 4: do away with framework submissions entirely. Let moderators internally come up with a small slate of frameworks that would be voted on. I am thinking two to five options here. Frameworks would be voted on before TL applications.
• Addressing point 6: commit to running a framework once every generation. Mods would internally decide the exact timing, or could make a PRC thread to gauge the community's temperature. For Gen 9, CAP 36 probably makes the most sense?
• Not part of this proposal, just an observation addressing point 5: with the recently passed PRC that allows for minor nerfs before the Post Play Lookback, we have an additional lever to quickly balance CAPs if we mess up and the mon is ridiculous on release.

This is a pretty simple proposal, but it cuts time off the beginning of the process, spares the TL extra work that comes with handling framework submissions, attempts to keep the process from dragging on for too long, and ensures that we end up with something quality (as opposed to ending up with a framework that is really just a concept in disguise, or one with a heavy focus on messy custom elements). I look forward to hearing everyone else's opinions.

Resources for discussion:
Last PRC on frameworks
CAP 30 framework submission thread (OP contains the current rules for legal frameworks)
CAP 25 framework submission thread

 

[Samirsin]

Frameworks are absolutely worthwhile to continue pursuing, as they add a unique flavor to the CAP project, making them special and noteworthy by allowing us to explore creative aspects of design beyond typical constraints. CAP's mission is to explore the OU metagame, and there are definitely things worth exploring that without a framework would not be possible. I do have to say that, as cool as the end product is, the process is messy, as there are many thing trying to get done without a previous example, so it becomes a "we'll see how to do it on the way", although by now we have experiences to look back on.

Regarding the TLT and contributor burnout, my suggestion is adding a new leader only present in framework CAPs, which would be Framework Leader (FL), this would take the pressure out of the rest of the team while allowing more people and thus ideas into the leadership. This person would take care of the first stages, slates, discussion and process, as if it were a mini TL.

Removing submissions and leaving them to the hands of moderators is complicated, at least in my perspective, as it takes out the whole "community" part of the project for this first step, although I understand why taking this path would be better for the project. Maybe we can find a middle ground?

Framework CAPs do not need to happen each 5 CAPs, but they should definitely happen at least one per generation, (for example next gen a mega in ZA and another framework). This allows exploration, a way to "break" the common routine, and becomes a good challenge for the community.

Embracing the challenge will allow us to continue making memorable, innovative Pokémon that showcase the variety and creativity at the heart of the CAP project.

 

[Zetalz]

As spoo outlined in the op, frameworks have become a very touchy subject in the community these past few years. Speaking of my own personal experiences, the first CAP project I myself started to seriously post during was CAP 25. Even as a newcomer at the time it was readily apparent to me that the large and complex workload demanded by the framework was causing a lot of stress to the project and community alike. When CAP 30 rolled around and framework discussion started up I was nervous to do another complex project so relatively soon after the ordeal that was the starters. But I remained cautiously optimistic that the winning submission's smaller scope would, hopefully, result in a less stressful time.

CAP 30 was, perhaps, the single most vitriolic CAP process I've ever involved myself with. Negativity felt like it was at an all time high among community members (myself included). Every stage of the process was met with some kind of outrage or toxic arguments over what to do/not do, how best to fulfill the concept and framework given, peaking by far the worst during the ability stage. It's one of few moments in my time with the project that I look back on with disdain for how dreadful it was to slog through, not even mentioning the headaches that came with post-release balancing.

Whether the level of stress the community was going through at the time is entirely the fault of the framework process itself, or due to several factors compounding on each other, I cannot say for certain. What I can say for certain, is that I never want the community to get as bad as it did during CAP 30 again. I do not want to see history repeat itself for the 3rd time, resulting in yet more unpleasant memories to look back on. To that end, I firmly agree with the op that the framework process must be radically overhauled if we are to continue using it.


With my personal ramblings out the way, I'd now like to chime in one some of the points proposed thus far:

Frameworks are a lot of work. TLT and contributor burnout is something I have experienced and don't take lightly.

Wholeheartedly agree, if my previous paragraphs did not make that obvious already.

Because frameworks take additional time, our process schedule and tournament schedule are left playing catch-up, sometimes for the whole year, even possibly bleeding into the next year's schedule.

Addressing point 2: start framework processes slightly sooner than normal. Heavily timebox the projects to stay on track. 7 days for each discussion thread, two days of voting, and run polls on time. Miasmaw's process is a good example of this strategy working well, though this admittedly requires more diligence from the mod team and TLT.

Addressing point 6: commit to running a framework once every generation. Mods would internally decide the exact timing, or could make a PRC thread to gauge the community's temperature. For Gen 9, CAP 36 probably makes the most sense?

While the specifics of the timetables mentioned are arbitrary at best rn, I do agree with the greater point of wanting to both trim and accelerate the framework process so as not to bog things down. More important than specifics of process timetable I think however is the greater timing of the project itself. Beholding ourselves to the unofficial every-5-CAPs tradition was never going to work out long term. We do not have the foresight for when game/gen/dlc releases may happen, among other things that would further complicate the schedule. I firmly believe that defaulting to the judgment of CAP's tour managers and process leadership for when to do such projects is a necessity for future frameworks. Given that the next mainline title is a "side game" with an as-of-yet unknown release window, I'd say that either of 35 or 36 should be eligible, with a leaning toward 36.

1. I am adamantly opposed to most custom elements. Minor things such as Venom-E's item, or "reskins" of hard-coded elements that already exist in the game, are fine with me, but otherwise I think custom elements are terrible. The current rules are also somewhat ambiguous as to which custom elements are actually allowed.
2. Many of the framework submissions last time lost the plot. If we apply a more narrow definition of frameworks (which I would argue is better), the actual pool of total legal frameworks is probably quite small. And even within this small pool, there are only a handful of legal frameworks I would personally be interested in exploring.
3. Balancing multi-mon releases really sucks. Venomicon was made at the end of SS when the tier was quite stable, and still resulted in two largely overtuned products that took a long time to balance. We're currently in a less-stable period of much more volatile generation than SS. Our track record so far has not been amazing with Hemogoblin and Chuggalong both being very broken on release.

Custom and flavor driven elements are perhaps the most difficult thing to address when it comes to these discussions, as they are largely what justifies the very existence of frameworks. This is further complicated by the design of official mons becoming more unique and centered around their own 'custom' elements as the gens have passed on. I do agree that direct clones of existing elements should be tolerated, as they are both easier to implement and easier to explain to the CAP uninitiated.

With that in mind, there is the gambit that any custom element has to run in the form of user optics. Optics to those outside the community; to those who do not have the deeper knowledge and experience of CAP development, are an extremely underrated factor of CAP development that all to often falls to the wayside in lieu of the wants of those within the community. I cannot stress enough how much poor optics have the potential to damage the reputation of a CAP, or CAP as a whole. I personally have had lengthy conversations with people who have shown interest in CAP only to feel immediately turned off by things like CAP's tendency for extreme movepool bloat and questionable flavor inclusions. Regardless of how much we pride ourselves on being a competitive project first and foremost, and no matter how much we tell ourselves that we are not beholden to the flavor whims of randos online, remaining considerate of a mon's public perception is in my opinion quite vital to a CAP's success.

To this end, establishing some harder criteria on what is and is not an acceptable level of custom/flavor element inclusion would go some distance in helping both the problems of the framework process, and it's greater impact on the project as a whole. It won't answer all the problems with them, but it is a good start. I also strongly agree with the dissolution of multi-mon/form projects entirely. These are the number 1 contributors to burnout and toxicity within framework projects, and we would be remiss to include them after the showing's they've had previously. There is no shortage of ideas that could be explored without these available as options either.

Addressing points 1, 2 3, and 4: do away with framework submissions entirely. Let moderators internally come up with a small slate of frameworks that would be voted on. I am thinking two to five options here. Frameworks would be voted on before TL applications.

This I'm not so sold on. While I do think the turnout of framework submissions from previous projects was a bit... iffy, I don't think this means we should jump straight to entirely leadership based work. I think a smarter step would be to have leadership be more assertive in directing how to create a solid framework for users to submit, and giving them a great deal of control over slate selection. If there ends up only being 2 or 3 options that's fine imo, if it results in less boring flavor driven ideas. Agree frameworks should be decided on entirely before TL apps, knowing what they are getting themselves into is absolutely critical.

Regarding the TLT and contributor burnout, my suggestion is adding a new leader only present in framework CAPs, which would be Framework Leader (FL), this would take the pressure out of the rest of the team while allowing more people and thus ideas into the leadership. This person would take care of the first stages, slates, discussion and process, as if it were a mini TL.

Heavily disagree with this proposal. Adding another layer of 'bureaucracy', as it were, to the process will further stall and complicate things more than it seeks to relieve. This individual would still need to communicate heavily with everyone, and would still have to remain active in the process well after their stage in order to ensure the conclusions that are reached during their time remain in the minds of everyone participating for the whole duration of the project. I think a more apt application of this idea would be to heavily impart upon TL subs during framework CAPs the extra time and energy that will be required of them, to ensure they're adequately prepared, rather than adding an arbitrary extra TLT member.

 

[Brambane]

Both previous frameworks were effectively flavor decisions that placed limitations on the building process. In its current form, a framework limits design scope from the onset to establish a theme. I think frameworks should be more competitively interesting and less flavor driven, or completely the opposite.

I also think multiple Pokemon frameworks, with the exception of an ability focused form change, should not be permitted in their entirety.

I propose that a framework process is basically the same as a CAP process, but you can propose concepts that are more likely to break convention and radically change the process. I.e. In-Battle Form Change wouldn't work as a standard concept, but if we go into the project accepting concepts like that, then we can go from there. As such, a good future framework has a clear intent and direction; the aforementioned would be based around the ability for direction.

The other thing would be how much we would allow custom elements, which will always be controversial within the community. I will say that the Fakemon community outside of Smogon really leans into giving their Fakemons custom moves and abilities, and honestly while I understand the sentiment behind our philosophy it feels a little out of touch. Personally, I don't think we need to dip into the custom bucket every project, but for a framework it should be allowed, if not encouraged, even if it is just a rename of an existing ability or retype of an existing move.

Also, to speak to the above post, optics for CAP will always be less than other projects because:
1. We balance our Pokemon around a very specific singles 6v6 format with a relatively restricted ruleset, which means our competitive design will be fundamentally different from official Pokemon
2. We are Smogon project and some users will always be critical of CAP on that principle
3. Generally speaking, CAP caters to a specific part of the Fakemon and Smogon community; like other niche creative communities, it will have vocal critics outside the community

So I think optics are fine to think about, but take criticism with plenty of grains of salt. With that being said, I believe a CAP that leans in on its own custom signature elements as oppose to stealing signature moves or abilities from other Pokemon is likely going to be more palatable to users outside the project. If we are going to concern ourselves with optics, it reinforces a trend towards custom elements, especially when Game Freak is doing it with Armor Tail being a reflavored Dazzling, or even Dazzling and Queenly Majesty in the same generation.

 

[Wulfanator]

Please retire frameworks. This has been my stance since leading CAP 30.

The most pressing issue is multi-mon frameworks. They pose an unnecessary burden on the TLT and they bloat the time it takes to complete the process. I mostly attribute this to the fact that multi-mon frameworks lack meaningful direction, so they heavily rely on the concept to shape the mon. Unfortunately, our history with frameworks shows the struggles of selecting framework-concept combos that have no immediate direction. Leading 30 felt like a headache every step of the way. I never felt like there was a clear next step/stage. The process was very reactive to the developing discussions and intermediate steps were often invented on the spot to assist with these pain points. This ultimately ballooned the process to 6 months for just the 1.0 release. The full process took 9 months (July 2021 - March 2022). Even with the limitations implemented post-CAP 25, it didn't feel like enough of an adjustment to make multi-mon frameworks palatable.

I have also changed my opinions on custom mechanics for frameworks. Frameworks actively undermine the efforts the community has made to remove custom mechanics from the process for more than a decade now. Frameworks like "making a status move an ability" deviate too far from what we should be permitted in any project. It has been more difficult explaining CAP to newcomers since frameworks were introduced because the conversation often gets very muddy. "We can't consider X because the standard ruleset disallows it, but it could technically be allowed at these arbitrary intervals." It is best to have clear rules that are constant across all projects.

If these 2 pillars of frameworks are removed, I really don't see a reason to continue frameworks as a whole. Yes, there are projects that do not fall into either category, but, after actively slating frameworks for 30, I believe there is only a small subset of frameworks that differentiate themselves from the above and that are actually worth pursuing. That being said, I would not be opposed to modifying concept rules to be more permissive of framework-like ideas since this would create more uniformity across all projects. That would be a different conversation entirely though.

 

[SHSP]

I've always been pretty anti-framework dating back to the semi-surprise introduction of them and the starters process of CAP25. Over time, though, I've gotten less and less of a 100% dramatic hater of the idea and more frustrated with some of the implementation around it, and that comes from a few different perspectives:

From the TL perspective, they both seem really intriguing and extremely frustrating at the same time. They're extra work- ranging from not too too much extra work to a "making entirely extra mons on top of an already difficult CAP process" level of extra work. As some of the other posters in thread have mentioned, people get extra frustrated during these projects and the new elements they add are difficult to manage. I also think that in a lot of ways, they act as a barrier to entry both for leadership and for regular users. I remember being a 1x TLT member pre-25 considering a run and being rather bluntly told not to bother going for TL because of not having years of experience and how unforgiving the framework process would be. Wulf may have been a first time TL going into CAP30, but he was well familiar with the process, had TLT'd prior, and was very well established and up to the challenge they presented. It can be extremely difficult even TLTing these sort of projects, and I don't love what that does for those sort of prospective users. Non-leadership users are also now faced with learning several more hoops we're jumping through and often times adapting on the fly to meet the challenges individual frameworks create, which not only can make the process hard to follow but make future processes tricky to adapt back to.

All this being said, the idea of leading a framework has grown on me more and more. They're incredibly unique, and when lead and done well in the case of Venomicon (yes, even with it coming out strong I still would rate the books as some of the best outputs) they can be extremely satisfying projects and really push the envelope. I still don't think I'll ever love multi-mon frameworks, for the above reasons and timing stuff that Wulf touched on, but other ideas can definitely work to some level. To pull from CAP 30's slate of frameworks, there were a few heavily custom frameworks (in-battle form change and weak status move ability) and a few that pull from unique ideas (primal weather setter or pre-Gen 9 nerf Protean user) that could be effective and interesting processes. To be blunt, I think a lot of the common ideas- box legend(s), NFE+Evolution pair, and some other heavily flavor ones like Mythical/Pixie- kinda just suck, and the really good framework ideas are fewer and far between. This is heavily just my own .02$ showing, but in a framework I'm looking for a way to explore more competitive/conceptual space (as Brambane so effectively put it on discord earlier, i'm 100% stealing this line from him jsyk). As much as it was memed and gawked at during CAP25, the idea of "255 speed mon" is this idea taken to the extreme: something we could never do in a regular process, not overly custom, has hooks in making an effective process both competitively and flavorfully.

Bramb also makes a lot of good points about optics and flavor, but I think my two cents on optics could be their own thread/rant at this point and are a little more than off topic for this thread, so I'll spare yall here. Custom elements aren't 100% tied to frameworks in my view- the only distinctly custom thing we've added through two so far is the Vile Vial- and if we can make a way to play on what's more available in-game already, that'd be a way I'd come onboard to the idea. Above all else, though, this thread is hugely important if for no other reason than coming into the next CAP with ideas of what a framework implies for a process (and what it doesn't/can't change), how and when they're set up, and what they mean for the process at large.

It is best to have clear rules that are constant across all projects.

That being said, I would not be opposed to modifying concept rules to be more permissive of framework-like ideas since this would create more uniformity across all projects. That would be a different conversation entirely though.

an aside at the end, but I'm heavily echoing these two notes from Wulf. My preferred route would be more flexibility to break our rules when we want during regular processes, but regardless of what we do we should be clear about how, when and what.

I'm still not going to be super on-board for a framework process, but I don't think I ever would be, so take that with a grain of salt. There's interesting elements in them and if done very well they can produce some really excellent outcomes, but they feel like much more has to go right for that to happen. If they go, I won't be too heartbroken.

 

[dex]

Just let the mod team and TL have a larger say in what frameworks are allowed.

Breaking the rules is fun. Frameworks let us break the rules. I think that frameworks in the past have been very poorly defined, however. “Box Legend” could be a normal process, “NFE + Evo” is too time consuming and stressful, and “Mystical” is too boring. However, SHSP mentioned a few options that I think stand out as shining examples of what Frameworks should be: breaking CAP’s rules in an instructive way. Specifically, frameworks should center around one of two things: a custom element (move, ability, w/e) or messing with the process order.

Defining frameworks in this way takes a massive onus off of mods and the TL not only to work through a trying framework but also to police the whole host of uninteresting or just bad framework submissions. I don’t think that arguing that frameworks are inherently more work is a valid argument; you can absolutely define frameworks like this or similarly to avoid undesirable situations.

Now there is an issue with defining things like this, and that’s that this will reduce the possible number of submissions considerably. However, given that frameworks have the potential to be more wild processes, I see this as a good thing.

I also don’t think that custom elements are a bad thing for frameworks. I’ve long doubted the CAP adage that custom elements raise the learning barrier for CAP. Every CAP you add raises the learning barrier, and at this point, a singular custom ability or move in a once-a-gen(ish) framework is not going to break the bank, or even make a dent. The truth is that custom elements are… fun, at least to think about. Now, obviously CAP processes true should not allow for custom elements. It’s important to work within the scope GameFreak has created. However, it is absolutely the most fun rule to think about breaking, and isn’t that what frameworks are all about?

Frameworks are fun, keep them. Cutting down on the space of allowable frameworks keeps them manageable and is a no-brainer answer to everyone that disqualifies frameworks for being too work-intensive. They simply don’t have to be.

 

[Samirsin]

I want to add to the custom things debate that the argument of "it makes it hard for newcomers to learn or know about it" that as someone who is always in low ladder and in CAP chat, new people are always coming and are eager to learn about it, and are really excited about it. Even as of today people still go and ask about things like Mountaineer or Shadow Strike, so another new thing would not be a problem whatsoever, and it's nothing that a !dt command or a question in chat can't answer.

 

[Wulfanator]

That being said, I would not be opposed to modifying concept rules to be more permissive of framework-like ideas since this would create more uniformity across all projects.

I've been dwelling on this comment since yesterday and wanted to expand a bit on it.

I believe that marrying frameworks and concepts is a better path forward if we want to retain some of the freedoms frameworks can permit. Ultimately, CAP should prioritize the exploration of mechanics regardless of how it shapes the process. Under the current rules, ideas like "Booster Energy Mon" and "252 Stat" are disallowed as concepts since one necessitates an ability and the other explicitly defines a stat. I don't necessarily see the harm in lifting restrictions like these for a standard process. You aren't removing community agency by allowing them since the community selects the concept through a democratic process. I think this would need to be a larger discussion on where to draw the line, but there is room to modify the existing rules to allow more "rule breaking." We do not need a specific process to codify "WE ARE BREAKING THE RULES" (SHSP, 2024).

There is valid concern that we risk trivializing specific stages by expanding the definition of a legal concept, but that concern is only valid because of the existing process structure. Given that TLT polls are held before all other steps, it artificially necessitates these stages be open for discussion. For all the problems that frameworks can cause, it actually handles this issue exceptionally well. TLT polls occur after the framework has been selected. This grants us the flexibility to determine the necessity of each stage and shape the team structure to the needs of the framework. It would be beneficial to use this ordering if we relax concept rules. It would actually be a beneficial adjustment to the standard process anyway.

 

[Mova]

My best 0.02 USD here is that I'd appreciate committing to frameworks once per generation, preferably the fifth and/or final CAP of that generation, and only once per generation at the maximum. It could be every five or six CAPs, but closer to the tail end of a generation would help. We usually use the period between the last generational CAP to settle the meta and any other issues the tier has before a new major game releases, but I think the workload would be somewhat easier once DLC 2 is mostly established, and then we would still have time to resolve any last issues the mons from CAP have, including a buff or nerf of an older CAP.

 

[Brambane]

Here is a more formal proposal of changes.

1. A Framework Process occurs once per generation, and is never the first project of a generation. When we decide to do a framework is going to be somewhat arbitrary by definition, but I think jumping into a framework at the start of a new generation when the format is more nebulous is dubious. If we are going to push the limits of the project, we should have a more confident idea of what the generation looks like competitively.

2. A Framework Process has fewer restrictions during Concept Submissions. Frameworks are concepts that may propose specific elements of a CAP that either trivialize a later stage, or necessitate the creation of additional stages. Examples would include a Framework that states a specific ability, i.e. Protean User, that would lessen the needs of the ability stage. Alternatively, a framework may have a custom or modified element, i.e. Retyped Knock Off, that would require additional stages to assess.

3. A Framework Process doesn't decide the TLT until the end of the first round of Concept Assessment. Contributors can apply for the TLT once the Framework Concept has been decided. This so we don't have someone sign-up for a TLT spot that doesn't need to exist for a concept, such as one that states a specific ability or typing.

4. A Framework may not include multiple Pokemon, or multiple forms of a single Pokemon distinct from each other in traditional Smogon tiering policy. This means that forms such as Arceus forms, Giratina forms, or Sylvally forms would be banned, while Aegislash forms or Cramorant forms would be allowed.

5. The Topic Leader for a Framework Process is allowed to select a slate of Framework Concepts, similar to the standard CAP process. Framework Concepts should have considerable competitive merit. Similar to a standard concept, frameworks should ask interesting questions about competitive Pokemon, encourage an unexplored direction for a Pokemon within the larger CAP metagame, or invoke discussion and reflection about the CAP process itself. "Create a Pseudo-Legendary" is vague, does not explore new ground or ask meaningful metagame questions. "Unconventional Protean User" challenges a specific archetype of Pokemon in the game, has evident metagame relevancy, and also pushes our creative process in a direction that is hard to actualize in a standard process due to the unique aspects of the ability.

6. Custom Elements should not be overly complex to require excessive and specific coding to implement. Custom Elements must be explicitly stated in the Framework Concept, not added later. Custom elements should be simple modifications of something that already exists, i.e. Fairy-type Armor Cannon or a stronger Mortal Spin. I am not opposed to custom elements, but we do need to draw a line in the sand somewhere. My stance is that you should say "this is ____, but instead of x it is y". For example, this "Ability is Solar Power, but instead of sun it activates in rain." Or alternatively this "move is Ceaseless Edge, but instead of Dark-type it is Steel-type." As examples, an appropriate Framework Concept with a custom element could include "Move Retype" or "Power Boost, where a move is modified to have a higher BP while maintaining all other attributes." These clearly state that there is a custom element, and what that custom element will entail.

 

[quziel]

I'm inclined to agree with a lot of the above points.

1) If we're doing frameworks we need to minimize the number of extra stages (that includes flavor stages) to avoid TL and Mod burnout.

This is fairly self-explanatory, but the more stages there are the longer of a commitment being TL for the project becomes. Wulf brought up a great point above with how Venomicon stretched out to be half a year, which is just a way longer commitment than most TLs are willing to sign up for (even if they think they are, stuff can happen).

2) Frameworks should have major process implications.

This is fairly simple one, but we're a competitive first project, and any framework we should do should have major implications on the process. This means major changes to at least one stage. Without that we're practically just running a standard project, or well, as we've seen in the past, three standard processes. I'm inclined to also argue that any framework should be competitively focused. While there's probably desire to do, for example, art first, I don't think that would lead ot a good process. Same for frameworks that have major flavor implications rather than competitive implications, e.g. Paradox CAP.

3) We should probably have a framework also specify a concept.

A problem we've had with existing frameworks is that you're sorta left in an awkward space where the framework isn't enough to design a cap by itself, and then we have to staple a concept onto the framework that ends up being a bit lacklustre. Doing a "framework concept" or just letting the framework specify a lot more of the design questions we're gonna answer would both speed up the process, and likely result in a better process.

EDIT:

Pick concept before TLT in general, lets do protean cap.

 

[spoo]

The responses to this thread have confirmed that frameworks are controversial at best, and that there's a clear desire to change some of the rules surrounding them – if we even continue to do them at all. There's too much left to resolve about this issue, and we simply can't postpone CAP 35 until we figure it all out. Given this, CAP 35 will begin immediately after Kitsunoh's buff process concludes, and will not be a framework project.

With that said, I'm not ruling out the possibility of a framework for CAP 36. I'll push this thread along in a more meaningful way at a later point so that we can come to a concrete decision on what to do with frameworks moving forward. I encourage people to continue posting in this thread if you've got something to say on the matter.

 

[Amamama]

Most of what makes Frameworks iffy has been touched upon by previous posts. Strain on leadership, processes that lack focus from the onset and outcomes which need quite a bit of reassessing alongside fatiguing interest during long drawn out processes, have shed a questionable light on Frameworks.
But I have to agree with Dex. Frameworks can be fun. And CAP should first and foremost be fun for those involved.
For Frameworks to be fun and not tiring as it has been some of the seasoned Framework veterans, there needs to be a much clearer image of what a framework should be though.
The status quo of Frameworks is kinda based on a whim rather than a bulletproof decision and a lot surrounding frame works feels happenstance for that reason.
In this thread several users have already brought up some solid reglementations, which should help easing the strain of frameworks and putting fun first.
1) Scope: Some of the resentment against Frameworks probably is related to both of them having been multi Mon processes. One can also imagine that a framework meddling too much with the process would cause similar issues, as having to work out how to do something while doing it usually is time consuming and entails much more mental effort.

For that reason I agree that Frameworks - if we want to further consider them - need to not be Multi-Mon processes as Brambane frames it here:

A Framework may not include multiple Pokemon, or multiple forms of a single Pokemon distinct from each other in traditional Smogon tiering policy

I also think that modifications to the process reglementation should be small in scope (I am not sure how much is too much though) but in general I believe changing process order or predetermining some part of the process in the concept is fine, while creating additional elements or changing our focus away from competitive first should be applied minimally if at all. More importantly a framework should state exactly what changes are going to be made to a regular process in the description so there’s clarity from the start.
Lastly custom elements, which I’m generally fine with should still be based on existing options for reasons stated in other pro custom arguments.

2) Timeframe: I agree, that given the possibly larger scope and generally higher uncertainTy around a Framework, that the decision if a framework is feasible should be in the hands of mods and meta council or whoever is in charge of timeframing both creative and competitive parts of the project. In general I believe that a “last cap of the gen is a framework” should be doable, but the stability of the meta and time framing of the entirety of the process should take precedent over any sort of sentiment coming from the community.
I don’t necessarily believe that tighter schedules are quite necessary if we hold ourselves to what I outlined under 1)Scope.
.I actually think given how some Frameworks likely end up rendering some stages irrelevan, that - as long as they aren’t multi Mon FWs - they will come out shorter than other projects.

 

[Rabia]

As someone that's been wanting CAP35 to be a framework, I agree that not making the same mistakes that prior iterations did in terms of time spent is a must. But, we need to remember that the point of frameworks is to deviate significantly from what the standard CAP process is about. Frameworks as they stand only happen every 5 full processes, which ends up being about every 3 years/roughly once a generation, if that. I think that ultimately means while there's room to optimize to what extends we break tradition, we shouldn't be afraid of letting the process be noticeably more special than usual.

One of the points I most agree with is reigning in vagueness/making frameworks more focused from the onset. This could just mean framework proposals are more than "this CAP has a move that doesn't currently exist", or "there are three of them" (not saying this is how it's ever gone). If the process of the framework gets laid out in a way where a timeline is clear--or the framework itself just isn't forced into needing a super unique process--then I think that would help clarify potential stress down the line for the TLT team.

 

[spoo]

Alright, let's get this thread sorted out. As expected, frameworks themselves still divisive. Some people want to retire the idea. Some people don't. For the purpose of this thread, let's assume we are keeping them and try to come up with the best rules moving forward. If we really cannot come up with a satisfactory set of new rules for frameworks, then we will retire them, but let's give it our best shot.

Here are some semi organized thoughts:

Problem: People hate multi-mon frameworks
Solution: Have stricter rules about the shared elements in multi-mon frameworks. Or we just retire multi-mons, including in-battle form change stuff, even if your name is Morpeko. One mon = one mon.

• Speaking from a process POV, is there a significant workload difference between making a Battle Bond Gren vs a Mega Evolution? What about making a Mega Evolution and an NFE? Let's try to get more specific on what makes Giratina forms an unacceptable multi-mon but Stance Chance an acceptable multi-mon. These were the rules for Venomicon:

  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, and among the remaining 3 stages, at least 2 should have heavy similarities (eg at least one shared typing, at least one shared ability, etc). If the Pokemon/forms share 2 or more stages completely, there is no requirement for the non-shared stages to be similar.

  I say we revise this to: must share two of (typing/ability/etc), must have heavy similarities in at least one of the remaining two. AKA only one fully unique aspect between two distinct mons. No Venomicon or Mega Altaria, but Aegislash/Mega Crucibelle/Cramorant/Ash Greninja still OK. Whether it's an in-battle form change mon or two cover legends, I don't care, as long as the workload is manageable.

---

Problem: Customs.
Solution: We need to find a line between what's acceptable and what's not. Where do we stand on the spectrum below? Where does something like this framework fit on the spectrum? Also, what is "small scale" vs "large scale" –– can we get better definitions than this? E.g. this framework, or even a move like Paleo Wave, is not obviously small or large scale to me. We need clearer definitions. But... if that's not possible, we can simply put together examples of acceptable and unacceptable custom elements to create some guidelines, and then legality check submissions by vibe. Personally speaking I draw the line between 3 and 4.

1. Allow no customs.
2. Allow reskinning existing move, item, or ability (literally just flavor)
3. Allow reskinning hard-coded move, item, or ability (e.g. Vile Vial; aka, only when mechanically necessary)
4. Allow small-scale tweaks of existing move, item, or ability (e.g. Special Intimidate, Paleo Wave(?), Stance Change but with Spiky Shield, Steel-type Ceaseless Edge, 80BP Mortal Spin)
5. Allow large-scale mechanically new move, item, or ability (e.g. Persistent, Sound Typing, Weak Status Move Ability (?), Spooky Terrain)

---

Problem: If we do away with "small-scale" customs and multi-mon frameworks, what's even left for us to work with?
Solution: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 submissions on the first page alone of Venomicon's framework submissions.

• These generally fall into one of three categories: flavor based (Route 1 CAP, cover legend CAP), dictating the result of a given stage (Wonder Guard CAP, Normal-type CAP), or messing with process rules (Random Slate CAP). There are some outliers, such as the form change one.

---

Problem: Frameworks sometimes lack direction. Granted, our sample size is pretty much just Venomicon, but structure and direction is incredibly important for these sorts of projects, and it's been hard to come by in the past.
Solution: Let people submit frameworks and concepts together ("framework concepts"); this should help impose some structure on these inherently loose processes. It risks further complicating a stage that's sorta esoteric to begin with, though.

• Alternatively: just relax rules around concept submissions, and get rid of frameworks altogether. E.g. let people submit stuff like "protean CAP" for your normal CAP process. This also means holding the TLT poll after Concept Assessment, once stage order and # of stages is decided. I would rather not go down this route, but it is a route that exists. Are there other solutions we're missing here?

---

Problem: Frameworks are long, they are stressful, and generally end with a burnt out and unhappy community; the process needs to be trimmed and accelerated, and the amount of extra stages needs to be minimized.
Solution: Idk, what does this actually look like in practice?

• For one, I think we can be more strict about timeboxing; make abundantly clear the TLT has X days to run each stage, barring serious irl circumstances that get in the way. Should we also put a limit on extra stages? E.g. no more than two Concept Assessments, no random stuff like Role Discussion, etc? Mods can be more proactive about policing vitriolic discourse; I agree with Zetalz that some of Venomicon's discussion stages really got out of hand. We can also give more downtime after a framework process finishes to recover from potential burnout. Some ideas.

---

Feel free to discuss whatever you want here, but I believe the best course of action is:
- Deciding how to handle customs and multi-mon frameworks
- Depending on how much we want to limit those elements, deciding if the remaining design space for frameworks is even worth pursuing, or if we should limit it even further (e.g. banning "flavor-based" submissions)
- If we still want to pursue frameworks with those new rules, we can then get into the specifics of how to optimize their runtime, how to impose more direction, how to reduce TLT and mod stress, how often we want them to be run, etc

 

[dex]

Deciding how to handle customs and multi-mon frameworks

I think the solution you laid out is perfect. Megas (gen allowing) and forme changes should be on the table. Venomicon (only sharing a typing and move pool and having no other similarities) should not.

Depending on how much we want to limit those elements, deciding if the remaining design space for frameworks is even worth pursuing, or if we should limit it even further (e.g. banning "flavor-based" submissions)

I’m mixed on flavor based submissions but ultimately I believe they should not be allowed. There’s stuff like Box Legend which I think could be allowed by being a framework with a predetermined very high BST that may seem flavor based, but true flavor subs shouldn’t be a thing.

Problem: Customs.

I feel extremely strongly about this topic. Frankly, just allow it! Now, these sort of frameworks have to be worded well. “This mon has an ability that lets it remove hazards on entry” doesn’t fly because it deletes a whole stage. “This mon has an ability that is a status move” or “this mon has a unique high BP move” or the ilk do work very well. I know that customs are a bit weird in CAP, but given just how many custom-ass abilities and moves Game Freak has started to put out now (Purifying Salt, Good as Gold, Gigaton Hammer, Triple Arrows, the list goes on and on), I think its completely fine to have a custom as a framework.

If we still want to pursue frameworks with those new rules, we can then get into the specifics of how to optimize their runtime, how to impose more direction, how to reduce TLT and mod stress, how often we want them to be run, etc

I think this is easily manageable via the TLT and mod team at the framework slating stage. A framework would probably need a certain kind of TL that wants to do it, but I think the previously discussed restrictions do a good enough job at managing this. As for how often we want to do them? Let’s just do it as the fifth CAP of every gen! Seems like a milestone enough to me that CAP survived long enough into a gen to even make a fifth mon!

Be all end all: frameworks are fun. The restrictions spoo poses are good. Customs should be allowed within reason (I.E. doesn’t screw the stages too heavy). Let’s have a good time.

 

[Amamama]

AKA only one fully unique aspect between two distinct mons. No Venomicon or Mega Altaria, but Aegislash/Mega Crucibelle/Cramorant/Ash Greninja still OK.

This is the way to go. Limiting the difference for multi Mon to one entirely unique aspect should end up manageable. It's still slightly more work, but it's a significant reduction of workload compared to Venom.

I feel extremely strongly about this topic. Frankly, just allow it!

I completely agree with this.
While Customs obviously should be a no go for regular processes, Frameworks should be very open about them.
Realistically custom elements are the best justification to keep Frameworks.
And given the tendencies in new gens for a huge portion of newly released mons with custom elements I don't think we need to hold back as much as we did in previous gens.
Signature moves and abilities are going to be much more prevalent if the current trends hold. The entry barrier to a new gen is going to be higher anyway - one CAP with some unique mechanic more or less doesn't matter.
For me the most important aspect for this is that the Framework needs to be very clear about what aspect is gonna be custom, while allowing many paths forward. How exactly a good proposal for a custom elements framework needs to look is something we'd have to figure out.

Frameworks sometimes lack direction.

Solution: Let people submit frameworks and concepts together ("framework concepts"); this should help impose some structure on these inherently loose processes.

I don't think this is a good solution.
The issue of lacking direction applies to both Frameworks and Concepts and I think it's actually necessary to be more thorough with Concept subs instead of Frameworks.
In my opinion a framework should simply tell us which Process Rule we are allowed to bend. It doesn't need to give direction other than that.
The direction instead has to come from the concept.
If the framework process feels unfocused I feel that will in large part be due to the concept lacking direction.

As an example the concept for 35 provided incredibly little info on how a possible result could look like, as it allowed for so many interpretations.
This lead to a more extensive concept assessment phase and less direction for the community to work towards to.
This concept would have been incredibly awkward if layered into a framework.

Thus imo the solution is a stricter monitoring of what concepts actually are "good" concepts and slating accordingly.
While this is subjective I think a concept needs to have a clear outlook on the final result.
"Fast Wall" or "uses delayed" moves clearly states the goal of the concept.
"Has an element that works against its role" does to a small degree but remains very vague overall.

Tldr: It doesn't matter if the Framework is vague or doesn't give direction.
What matters is the clarity and stringency of the concept that is paired with the framework.
Fusing Framework and Concept subs imo would lead to the opposite result, ending up with even muddier concepts.
In my opinion the TL has to be more strict considering the clarity of concepts instead.

For one, I think we can be more strict about timeboxing; make abundantly clear the TLT has X days to run each stage, barring serious irl circumstances that get in the way

Tbh I think putting stricter time limits on the stages would actually lead to more burnout. Having to manage a stage when irl gets in the way and knowing you only have a few days to finish something, when you believe it needs more time to cook seems like it would do the opposite of helping against overworked TLT

Should we also put a limit on extra stages? E.g. no more than two Concept Assessments, no random stuff like Role Discussion, etc

Again I think having extra stages has more to do with the quality of the concept.
I've been part of processes with regular concepts, that had additional steps because of this.
I still think that there should be room for extra discussion if they are necessary.
I just don't think that the issue lies with framework subs as much as it does with concepts.
As long as we don't add stages bc of multi Mon framework (those are shit) I don't think any limits are necessary.


Overall my takeaway from this is:

- Frameworks are fun and we should keep them.
- A framework once a gen if the timing of other more work intensive stuff like dlcs etc allows for it is probably best. (Idt we should constrain ourselves to arbitrary milestones and instead work on community feedback like we did with 35
- frameworks should focus on bending process rules.
- Multi Mon frameworks are a no go
- Limited form differences are fine if they focus on ONE unique area
- Custom elements are cool and probably the best justification to continue Frameworks. Obviously this has to be within reason (new types no, custom moves/abilities fine)
- frameworks can be open ended, vague or provide little direction, so long as they are creative with their prompt and would stimulate interesting discussion
- fusing Frameworks and Concepts will not be good for direction and clarity
- direction instead has to come from stringent and clear concepts, that provide a good outlook on the goals of the cap (this means the TL has to be more thorough with monitoring the concept slate)
- keep the general structure we have rn and see how the new guidelines perform in keeping the workload at bay (after all the only reference we have are multimon Frameworks)

 

[Rabia]

So much of this thread is really bad and missing the point of frameworks. The entire point of frameworks is extra freedom and acknowledging they will take more time. This section is premised around having fun with the notion of building Pokemon from the ground up while working within confined limits. Frameworks let us break those limits, and I see a ton of posts wanting to deny that? For what? Saving time? That's really weak imo and completely misses the point of why frameworks are rare to begin with and defeats the purpose of doing them to begin with. Just kill the concept of a framework entirely if the community is unwilling to spend the effort into doing them lol.

sorry spoo this turned into a paragraph instead of the one-liner I promised.