Other Mega CAP


We have the technology.
is a Top Artistis a Top CAP Contributoris a Top Smogon Media Contributoris a Site Content Manager Alumnusis a Battle Simulator Admin Alumnusis a Super Moderator Alumnusis a Community Contributor Alumnus
This alleviates many of the concerns I had earlier. Thanks to DougJustDoug for proposing a plausible system with which we could base a Mega Evolution CAP. The phrase "we should just get it over with," resonates with me the most, but that doesn't mean this won't be worth doing. It will give us the opportunity to attempt something new for the CAP process. I am most concerned with its effect on the Concept Workshop, which could now potentially skewer some concepts while bolstering others that may have previously been poor or outright illegal. nyttyn and I will have to meet to discuss how this will look within the workshop. But other than that, we can make this work with Doug's proposal serving as our general guideline. The past several CAPs have been quite "by the books," so it should be an exciting endeavor to veer off our normal path.

Take the next 48 hours to consider Doug's proposal and comment on specific details. If there are no further objections, we'll move forward and declare CAP 21 as our first Mega Evolution CAP.


Like ships in the night, you're passing me by
is a Site Content Manageris a Forum Moderator Alumnusis a CAP Contributor Alumnusis a Tiering Contributor Alumnusis a Contributor Alumnus
It's worth pointing out that very few, if any, of the concepts currently approved in the workshop would work at all with a mega cap.


Maize and Blue Badge Set 2014-2017
is a Forum Moderator Alumnusis a CAP Contributor Alumnus
I'm not sure if we should declare CAP 21 our first Mega CAP yet, at least not until we've decided the other measures we're considering in Policy Review at the moment. While I like Doug's proposal, we're also considering fundamentally changing the way we create and look at Pokemon right now. I don't think it's smart to declare CAP 21 The Mega Evolution Project just yet; in fact, I believe we shouldn't decide on when to make a Mega Evolution project until we're finished with the other active PR threads.
Considering Bughouse's point regarding the currently approved Concepts, I'm not sure if we can work on a Mega CAP quite yet, but we always have CAP 22 for that. By that time, I suppose the active Policy Review threads will be finished.


Knows the great enthusiasms
is a Site Content Manageris a Top Artistis a Programmeris a Forum Moderatoris a Top CAP Contributoris a Battle Simulator Admin Alumnusis a Live Chat Contributor Alumnusis a Tiering Contributor Alumnusis an Administrator Alumnus
I'm really surprised anyone thinks a Mega evolution requires much in the way of a specific Concept. Almost all of the currently approved Concepts could work for a Mega CAP. The only Concepts that won't work for a Mega are along these lines:

  • Concepts that encourage a pokemon to have shitty stats -- since the whole point of a Mega is to have +100 BST
  • Concepts that encourage a pokemon to have a shitty ability -- since almost every Mega has a good, if not great, ability (except MegaGallade and MegaMewtwo, wtf?!?)
  • Concepts that encourage a hold item of some kind -- since Megas require a mega stone and can't lose it or give it away

I'm sure there might be others that won't work, but from a mechanics standpoint, there are very few limitations on Megas. And current Megas in the actual game range all over the map, in terms of the role they play on teams.

From the current Approved Concepts in the Concept Workshop, only these two won't work:

  • Mediocre Mon - emphasizes not-great stats, ability, and typing
  • Choiced Choice Scarf - requires a Choice Scarf

All the rest can be done as a Mega just fine. Also looking at the past 17 CAP projects (formal Concepts started with Fidgit), all of those concepts could have been done as a Mega too. So why does anyone think lack of a suitable Concept is somehow a problem for doing a Mega CAP on the next CAP project?

I already said in my last post that I agree a Mega project COULD be a platform to explore some cool Concepts that possibly could ONLY be accomplished by a Mega evolution. But that does not mean we REQUIRE a special concept tailor-made for a Mega evolution execution. And I'll also reiterate my concern that if we did try to make a Concept specially targeted just for a Mega -- I think it would probably be such a nuanced and specific Concept that it will be incredibly hard for us to pull off, considering that the CAP process is VERY HARD to direct in specific ways.

Mega evolution is just an additional game mechanic for us to deal with as we build a competitive pokemon. Yes, it will dramatically affect the choices we make on each step of the project. But the fact that we are choosing to implement our CAP with the Mega Evolution mechanic "in the mix", so to speak -- places very few, if any, meaningful limitations or boundaries on the direction we choose to take.
After reading some posts on this, I am convinced that a Mega CAP can and should be done for CAP 21. It will bring something fresh back to CAP and reinvigorate some of those on the edge contributors and bring back some of the spirit after making some frankly subpar CAPmons in the last few projects. On top of this, it really emphasizes our goal in CAP to learn about the metagame, as mega evolution is probably the most important new concept in Gen6 barring maybe Fairies. However, it has definitely shifted the OU metagame completely and is something that we will have to take a look at in the future, so I think now is the best time. DougJustDoug pretty much pointed out the best points in his post so I am just posting add my support here!


used substitute
is a Community Contributoris a Top CAP Contributoris a Forum Moderator Alumnusis a Battle Simulator Moderator Alumnus
I'd like to second what Doug is saying here. We don't need specific concepts for a mega, and frankly, while people could submit such concepts, I don't think they necessarily provide any benefit for a Mega project. Look at the pool of awesome mega Pokemon. How many of those Pokemon are cool and unique. A lot, sure. But is there anything about them that is only cool and unique because it is a mega? Maybe on some, but not most. For most, the fact that it is a mega is simply a balancing factor that limits its item choice. Basically, what I am saying is that you don't need a cool unique concept that can only be done with a mega Pokemon to make the mega interesting. The same is true of this project. Even if the concept doesn't specify that it is for a mega, a mega should still be able to fulfill it, and I think it is a misguided point of view to think of using such a concept for a mega project to be a waste, or anything of the sort.

A mega project comes with a different set of rules and restrictions, but the discussions and debates don't need to be completely focused only on the fact that the project is different. I'd like to see us go ahead with this, and I think many of the concepts we see now, or have seen in the past, would make a very awesome mega CAP project.


when everything you touch turns to gold
There has been no real discussion on the distinction between the two forms of the CAPs yet. Doug addressed that we should be a middle ground in terms of how much we change the base CAP -> mega CAP, but how should the concept affect both CAPs?

-To what extent should both forms fulfill the concept? I assume that we would want both forms to be able to match the concept's goal, but should they be able to do so equally. We could have the base form be a mini-success whereas the mega is a complete success. Or, we could have both forms be equally successful, in which case they would have to do so through item / typing / stats.

Likely this would be another topic for the Concept Assessment along with whether we are even doing a Mega for the project but I would just like for it to be put down formally should this be the route that is best.


Let's Keep Fighting
is an Artistis a Forum Moderator Alumnusis a CAP Contributor Alumnus
I'm going to try to keep this short since I have to go quite soon, but I hope my reasoning can still be somewhat followed.

First off, I completely agree with Doug and Jas that we do not need some sort of super special mega-related concept to base a Mega CAP around.

I do, however, see a minor issue with the process that Doug proposed in regards to stats. Essentially, every stat slate requires two sets of stats, one for the base and one for the mega. Because of this format, however, I think that it's very much possible for some people to love the base stats and hate the mega stats for a single item on the slate, and this could ultimately lead to compromises while voting. I'm not saying that this will definitely happen, but rather just that to me it makes so much more sense to have base stats and mega stats be separate stages. This would avoid compromises made during a shared slate and would make sure the single most supported base stats are then worked on to get the mega increase. Mega stats are inherently based around the base stats, and it seems weird that we wouldn't solidify the base stats first and then work with the mega stats.

For the other stages such as typing and ability, I do not believe that the issue of separation of the mega and base is quite as important since on paper the slating looks to be a lot simpler (though shared stages/slating is still not my overall preference). Overall, I'm not a huge fan of shared base and mega stages for the majority of the process (I really only support shared movepool), but I guess I think that stats in particular is the most important stage that should have separate parts for the base and mega.
I'm heavily in favor of the idea to separate polling between CAP 21's base and mega properties. Discouraging the possibility of voters choosing against options they would generally lean towards because of influence of mega over base form would only be for the better. Seperation promotes a process that focuses on the direction of a base form without disruption. No Pokemon that has currently received a Mega Evolution (with the possible exception of Diancie), has, from our knowledge, been created purposefully to be complimented or fixed by its Mega. I, like Heal, also fear that some might be inclined to favor options in a combined polling system that reduce the competitive viability of CAP 21's base form to solely strengthen the Mega form.

Obviously the moveset poll should be combined, but in my eyes everything else would work best separated.


Tier 3 Audino sub
is a Tiering Contributor Alumnus
In regards to making a Mega CAP, I believe that we should make a regular CAP then when its all finalised, make a mega for the next project for that said CAP made (so CAP X is made, so CAP X+1 shall be the mega for it). The reasoning for this is that if we decide to do both at the same time, I fear that people are gonna focus on one part of it more than the other, resulting in something that, most likely, a really mediocre CAP mon but with an astounding mega. I know that there are cases like this that exist (Mawile, Sableye and Altaria to name a few), but hopefully, we could make a CAP that can already fit into the OU metagame as that is what we do. We make things that'd balance out the OU metagame if they were to exist.

I don't wanna make an NU/RU mon for the purpose of focusing on the mega part of it. I wanna see this CAP being able to stand its own ground in both regular and Mega, like Scizor or Slowbro; 2 solid pokemon that function in OU well.
QueenofLuvdiscs has a great point regarding the Scizor and Slowbro examples. We should make a CAP (whether it be 21 or 22) whose base form isn't fully outclassed by its Mega Evolution, rather than simply making an RU/NU Pokemon with a Mega.

Not sure about Tyranitar, because the base form outclasses the Mega. Not sure if that's good or bad for the base form, considering the base form is pretty good, but we don't want that for a Mega CAP.


Robot from the Future
is a Community Leaderis a Community Contributoris a Live Chat Contributoris a Pokemon Researcheris a Smogon Media Contributor
Orange Islands
This is from ginganinja and aimed at the post made by QueenOfLuvdiscs

Unfortunately, the CAP Community hasn’t made a CAP to balance out the OU Metagame in like…years. Just to take a sweeping glance at the last 3 or so CAPs reflect underpowered projects with gimmicky or situational concepts that don’t turn out how we plan. Some of these CAP’s don’t even see usage in their respective playtests, even by the “Top” ladder players. You can try and split up the process into base form and then CAP X+1, but this means two CAPs in a row with the same concept. Or alternatively, two different CAP’s with no real connection to each other. Why don’t we just make the next CAP a Mega Evo of Navi and call it a day? Under your system, we couldn’t guarantee that we end up with a really mediocre CAP mon (ie what you don’t want), because seriously, take a look at the last three CAPs. There is a separate PR thread calling them mediocre, and those are CAPs that the community tried to make as good as possible! There is no real point trying the CAP X - CAP X +1 idea, because it wastes time, and doesn’t even fix any of the problems you claim that it would fix. You still (very probably) end up with a mediocre CAP, who then gets an astounding mega. Why wait a year to get the same result as what we would get if we started now?


Let's Keep Fighting
is an Artistis a Forum Moderator Alumnusis a CAP Contributor Alumnus
Just wanted to very quickly say that I *think* I'm agreeing with ginga in respects to CAP X and X+1 being base and megas respectively. It's too much of a disconnect and also leaves X+1 being a very short process in comparison... Making the base and the mega as a single CAP project just seems to have better continuity.


Knows the great enthusiasms
is a Site Content Manageris a Top Artistis a Programmeris a Forum Moderatoris a Top CAP Contributoris a Battle Simulator Admin Alumnusis a Live Chat Contributor Alumnusis a Tiering Contributor Alumnusis an Administrator Alumnus
In CAP, we have learned some hard lessons about making Pokemon. One of those lessons is:

Things that need to "work together" on a pokemon must be "submitted together" and "voted together" in CAP.

For example -- Typing. For years, we voted on Typing as two discreet steps -- Primary Type and Secondary Type. I won't get into why one was considered "primary" and the other "secondary", but realize these were two completely different steps. As they were two different steps, you couldn't even MENTION secondary typing during the primary typing discussion, because that would be poll-jumping. Once again, I won't get into why poll-jumping is bad for CAP, suffice to say, it's just another one of those lessons we have learned the hard way over the years. So we decided typing as two completely separate steps.

This made it VERY difficult to get typing that was cohesive with the Concept. Because everyone voting on Primary Typing was making ASSUMPTIONS about what Secondary Typing would be chosen on the next step! Then when the Primary Typing was decided, tons of people would be pissed off because our typing was "ruined" and would make haphazard choices for Secondary Typing. Also there are many people that prefer unique new type combinations, regardless of whether it best fits the concept or not. So between the people that were "stranded" from the primary type poll and the people that always vote for unique type combos -- we would often end up with sub-optimal or difficult typing to fit in our Concept. And since Typing was the first step of CAP, it would start CAP off with lots of bitching and "We're doomed" complaints right out of the gate.

The fact is that Typing combinations (we have only made one mono-type ever) need to "work together". And the only way to do that with any reliability is to vote on Typing as a pair. We tried all sorts of other things to make typing work as two separate steps. Nothing worked. Typing has to be a package deal. Period.

Now some of you might say:

"Wait a minute, Doug. Doesn't every aspect of a competitive Pokemon need to work together? Typing needs to mesh with Abilities, and both of those need to mesh with Stats, and all of that needs to work well with the Movepool -- RIGHT?!?!? If so, then why don't we submit and vote on entire Pokemon as a single so-called 'package deal'."

The answer is very clearly: Yes, every aspect of a competitive Pokemon needs to work together.

Unfortunately, this clashes with the very foundation of the CAP project that we create Pokemon as A COMMUNITY. And we allow everyone to participate. That means we MUST break the process of creation into separate steps in order to facilitate everyone being part of the process.

So we are continually forced to weigh the tradeoffs of allowing things to be decided as a "package deal" versus breaking decisions into multiple discreet steps. Fairly recently, we decided to collapse the competitive movepool into more of a "package deal" than we did in the past. We used to decide Attacking and Non-Attacking moves as separate steps. While that was good enough from a community participation standpoint, it really sucked for producing a cohesive movepool, and, more importantly, cohesive MOVESETS. So we combined movepool steps into one, with the hope of producing more cohesion, i.e. the attacking and non-attacking moves "work together" better.

A viable competitive MegaEvolution must "work together" with its base form.

This is not a statement about how GameFreak makes Megas. I get it that every Mega in the real game was made separately, and long after, its base form was introduced. So, there is an argument to be made that CAP should do it the same way, if we want to be consistent with GameFreak. I don't care about GameFreak. To be more accurate -- I am willing to tradeoff on consistency with GameFreak's process if I can get a Pokemon whose base form and Mega form work well together (or work better together than they likely will if decided separately).

Another HUGE reason I advocate deciding each step of a MegaCAP as a "package deal" -- We make very little change to our existing CAP process. Changing up the CAP process is a big deal, particularly adding and removing steps. It is more of a pain than most of you think. If there is any way we can do a Mega with only minor changes to our existing steps, we need to do it that way.


used substitute
is a Community Contributoris a Top CAP Contributoris a Forum Moderator Alumnusis a Battle Simulator Moderator Alumnus
After reading Doug's point, I would have to say that I definitely agree on his reasoning, but that, with regard to specific steps, I may draw a slightly different conclusion. I'm not going to rehash why related parts should be done together. If you want to know that, read the above post. What I am going to argue is that not ever stage, specifically abilities, are related enough for them to be better done together. Typing, sure. Assuming we don't break all precedent and say we can change more than one type, then by its very nature, a Mega Evolution's type is dependent on its base form. The same is true with Stats regarding the standard +100 bonus. However, abilities are not like that at all. Nothing about the base ability has really anything to do with the Mega ability. At the same time, what is good as a mega ability generally is not influenced by what is good as a normal ability. As such, I would argue that we would be best served by having primary/mega abilities be two separate polls. Having discussion together might be fine, but tying abilities together in polls would be very arbitrary and not really all that helpful.


We have the technology.
is a Top Artistis a Top CAP Contributoris a Top Smogon Media Contributoris a Site Content Manager Alumnusis a Battle Simulator Admin Alumnusis a Super Moderator Alumnusis a Community Contributor Alumnus
I believe we are ready to make a decision on the direction of this thread. DougJustDoug and I sat down for a chat (with some other friends) last evening to hash out the community consensus on this thread. In conclusion, we will move forward with CAP21 being our first Mega Evolution created in the CAP forum. In order to create this Pokemon, there will (currently) be no change to the current process. Rather, polls will be determined with the "arrow nomenclature" that Doug noted in his proposal. While there will definitely be kinks to work out in the process, many are unforeseeable until we have some hindsight on this project. CAP frequently tries new things and does the unexpected. Therefore, CAP21 will be a leap of faith for all of us, the moderators, the topic leadership team, and the community at large. Be prepared for unique discussions and opinions that we have not yet dealt with in our seven years of history.

I've included the chatlog we had last night in #cap below. It is a rehash of what I've written above, but feel free to read it if you're curious on the considerations that went into this decision.

[03:14] <@~DougJustDoug> The direction thread is a really big deal, imo. And although it would be great if we could conclude it before CAP 21, I just don't think it's reasonable to do so. I'd like the direction thread to be something we simmer on while CAP 21 is happening. I realize that puts a few wrinkles in CAP 21, but I think it can be managed.
[03:14] <@~DougJustDoug> So yeah, lets talk about Mega first
[03:14] <&@Birkal> yes, I agree. I just think the wait it would cause for CAP21 is unreasonable
[03:15] <%ginganinja> I think quick summary is : People like Mega, just disagree on interpretation
[03:15] <&@Birkal> and I don't think we're going to get unanimous decisions on what the process should look like immediately
[03:15] <&@Birkal> these sorts of things take experience to polish
[03:15] <&@Birkal> so I think your proposal was the most solid of the ones presented
[03:16] <@~DougJustDoug> Yes, I think consensus is OK with us just saying 'CAP 21 is gonna be a mega' and going with it. The biggest question is what process to follow.
[03:16] <&@Birkal> we can probably work with that as a base and then discuss between the TLT and the moderators on any minor issues
[03:16] <%ginganinja> there /seems/ to be a majority about making base + Mega together
[03:16] <@~DougJustDoug> I think people were generally in favor of my "don't change the process approach" -- but many people differed on how hardcore we should be about not changing anything.
[03:17] <&@Birkal> no one proposed what an "off-the-process" process would look like though
[03:17] <&@Birkal> and it would take a lot of time / effort to do that, when this whole thing is going to be a shot in the dark regardless
[03:17] <@~DougJustDoug> My stance was literally -- add no new steps. Others thought, "Add just one new step". Others were "Just add two steps". And so on.
[03:21] <@~DougJustDoug> I do not think adding one step or two is the end of the world. But I do have a hard time saying which aspect of a Mega is so important that it must be diecided separate from the base form. I think that leads to somewhat of an "all or nothing" decision that needs to be made. And with that, I very definitely would go with "nothing". Meaning, we just declare that we'll add no new steps.
[03:21] <@~DougJustDoug> Not because we absolutely cannot add steps. But because we shouldn't have an extended debate to decide which steps to add and how to execute the new steps.
[03:22] <@~DougJustDoug> "Not adding new steps" =/= "Everything is the same on the base and mega form"
[03:23] <&@Birkal> I'd say that's the smartest move going forward, Doug
[03:23] <&@Birkal> we have no way of knowing whether or not we need to add steps until we actually try this out
[03:23] <&@Birkal> and the topic leader has always had the ability to extend discussions to suit the concept
[03:24] <@~DougJustDoug> Yeah, thats where I was coming from Birkal.
[03:24] <Agile_Turtle> also yeah doug that's whatg i'm thinking
[03:24] <&@Birkal> I don't see why that would change when a mega evolution requires an extra topic, or a few days of discussion
[03:24] <Agile_Turtle> if we're adding extra steps
[03:24] <Agile_Turtle> it just feels like dit would be easier to do all then to only do a few extra
[03:24] <@~DougJustDoug> And, during this process of making a Mega -- we're gonna learn a lot about which steps would be better done separately and how to pull them off "next time"
[03:25] <&@Birkal> right, I think it will be a good learning process for us all
[03:25] <@~DougJustDoug> Quoted , next time, because we aren't saying if or when there will be a next time
[03:25] <@~DougJustDoug> Because the learning we get may be "We should never try a Mega again". Only half joking, there
[03:27] <&@Birkal> So, I think that realistically, we can close the thread and state that CAP21 is going to have a mega evolution. There is no change in process, just that Pokemon will have to be discussed with its mega in mind. Polls will feature shifts in regular to mega with an arrow "=>"
[03:27] <@~DougJustDoug> There's no science to when we need to do any CAP. But it sure feels like we're at a point where we need to get moving with another CAP. I can't back that up with any stats or anything. Just seems the right time, imo
[03:29] <@~DougJustDoug> Yes, Birkal, I agree with that. It is certainly simple from a policy standpoint, which is the main selling point of it. I think we need to make sure the TL of this project is aligned with the general intent though.
[03:29] <&@Birkal> right, pointing out the philosophy you discussed in your post (e.g. beedrill / scizor)
[03:30] <&@Birkal> that can also be part of the closing statement
[03:32] <&@Birkal> alright, I feel comfortable moving that thread forward
[03:32] <@~DougJustDoug> Yeah, and we can put something in the TLT noms OP (and maybe even chat with TL candidates directly) about the "leap of faith" we are asking from the TL on this CAP.
[03:32] <&@Birkal> I'll prepare a closing statement tomorrow morning and get TLT noms up at the time
[03:33] <@~DougJustDoug> If a TL is of the mindset "Hey, I really want to TL a CAP, and I guess I'm willing to deal with this Mega thing you have imposed" -- well that's a misfire right off the bat.
[03:33] <%ginganinja> who would actually TL a Mega CAP
[03:34] <@~DougJustDoug> If we have TL that are jazzed about being the TL of the first CAP mega project and are excited to make it work, however it turns out --- that's the kinda attitude we need.
[03:35] <@~DougJustDoug> Not to put too much pressure on anyone, but honestly I'm hoping we get someone that takes the attitude Jas took when leading Malaconda.
[03:36] <&@Birkal> Yep, I think so too
[03:36] <@~DougJustDoug> Where the whole "How do you TL now that you have this TLT thing that might just 'get in the way'" -- And Jas jumped in with both feet and rolled with the inevitable curveballs the changes threw at us.
[03:36] <&@Birkal> jas did do a nice job with that project; he had a good mentality about it
[03:39] <@~DougJustDoug> I think this project will be a lot of fun.
[03:39] <@~DougJustDoug> But I like trying new stuff.
[03:39] <Agile_Turtle> i agree
[03:39] <Agile_Turtle> i think stats will be really fun
[03:40] <&@Birkal> Alright, then I think I can get this all arranged then
[03:40] <&@Birkal> glad we found some time to chat about it
[03:40] <@~DougJustDoug> OK
[03:40] <Agile_Turtle> thinking on it now though, if we do add any extra steps, stats would probably be a prime candidate
[03:41] <Agile_Turtle> just based on the fact that if we do them as a package deal it might be hard to work with
[03:42] <Agile_Turtle> and i think if we do the base form first, we could talk about the direction the mega's stats should go after the base form's stats are decided
[03:43] <Agile_Turtle> and if we don't do them as a package deal but don't add an extra step for it and just have two separate polls
[03:43] <Agile_Turtle> and submissions
[03:44] <Agile_Turtle> then people could easily vote for a stat spread on the mega that's a lil unconventional for the stat spread we have on the base form
[03:46] <Agile_Turtle> (although the BSR guidelines should at least restrict them enough that no matter how the base stats and the mega stats relate, they both will work, but there is always the possibility that the voters could screw it)
[03:47] <@~DougJustDoug> I do not think package subs/voting is ideal -- but I do think it will be manageable. And it will be "safer" in the cases where things "go wrong" with CAP -- which happens a lot.
[03:47] <Agile_Turtle> yeah
[03:47] <Agile_Turtle> i mean
[03:48] <Agile_Turtle> i think the only problem i have with the whole package deal
[03:48] <Agile_Turtle> is that if we vote for one stat spread
[03:48] <Agile_Turtle> we have to vote for the stat spread that the submitter had for the other form as well
[03:49] <Agile_Turtle> and the issue with that is maybe you like one spread but not the other
[03:50] <@~DougJustDoug> Agreed, that's not great. But we deal with this exact thing on Sprites, for example. Which is a flavor step, but still --- for as long as I remember, people bitch when they love the front sprite of one submitter, but prefer the back sprite for another submitter.
[03:51] <Agile_Turtle> and you end up having to vote for something that barely has anything you want in each spread in order to get decent spreads (as far as what you want for the CAP goes) for both forms
[03:51] <@~DougJustDoug> So yeah, voters have to decide which package they like the best.
[03:52] <@~DougJustDoug> Because stylistically we feel that we are better served by two sprites that "agree" stylistically -- even if one sprite is inferior in absolute terms with another.
[03:52] <@~DougJustDoug> I hope that made sense
[03:52] <Agile_Turtle> the only way to solve that problem without making an extra step is to have two separate polls
[03:52] <Agile_Turtle> but then we have the issue of the seperate type stages you mentioned in your post
[03:52] <Agile_Turtle> where people could vote for something unconventional in relation to the winner of the first poll
[03:53] <Agile_Turtle> the only saving grace for this is that there will be BSR restrictions for both stat spreads
[03:54] <Agile_Turtle> however the HP would also have to be the same

In terms of the process and philosophy we will use, please refer to DougJustDoug's post below. One of our proclaimed goals is that CAP21 will fall in the middle of the "extremes spectrum" of how powerful the Mega Evolution is in relation to its base form. The Concept Workshop can now entertain concepts that specifically relate to Mega Evolution. All of our submission stages will have to perform double duty, with their works presented as a package deal. Finally, we will host a "Post CAP21 Discussion" here in Policy Review to determine what we could do better in the future. Other than that, we will roll with the punches as they come. Thanks for all who participated in this discussion.

If we are going to do a Mega CAP, I think we should just get on with it. I think we should just declare that the next CAP will be a Mega CAP, choose a Concept like normal, and then proceed to make our CAP pokemon. I don't think we need to make this harder than it needs to be. I think we should make the process map as closely as possible to the existing CAP process. And I think we can justify that approach competitively too. Let me explain...

Mega Evos range across a broad spectrum of "change to the base species". On the upper end of the change spectrum, you have Megas like MegaBeedrill and MegaPidgeot. Their base forms are total dogshit. Their MegaEvos are pretty badass (I'm not here to argue how good they are or not in OU. But their megas are a fuckton different than their base forms.) Then on the other end of the change spectrum, you have stuff like MegaScizor. Lots of people agree that while MegaScizor is certainly good, it still plays a lot like base Scizor (Once again, not arguing about total effectiveness in OU, just saying the delta is much less than the previous examples).

I think a Mega CAP should target somewhere in between these extremes on the "change spectrum", when it comes to the differences between the base form and the Mega Evo. If we try to make something with a big "mega delta" (like Beedrill), we probably need to have a lot of extra steps to the CAP process, because we are making effectively two very different pokemon. If we seek to make a MegaCAP with a small "mega delta", we probably ruin a lot of the excitement, novelty, and learning of making a Mega Evolution in the first place. So I think CAP should seek to make a Mega Evo with a significant-but-not-huge "mega delta".

How do we define "significant-but-not-huge mega delta"? We don't. We leave that to the interesting rollercoaster of CAP discussion threads. We use something like MegaBeedrill (there are many others) as an example of "too much mega delta", and something like MegaScizor (there are many more like this as well) as "too little mega delta" -- and then leave it to the so-called intelligent community consensus to figure out what makes sense in between those two examples.

It's not too important to define the middle ground. What matters is to overtly eliminate the proposals for extreme mega delta (which may be a lot of fun, but will probably attract more fantastical fanboyism than we really want to deal with), but also stifle the wet blanket conservatives that push for a mega with nothing more than 100 extra BST along the same stat bias as the base form (which will hopefully encourage people to push the ability, typing, and stat boundaries a bit, without fear of being labeled a fanboy noob).

If we don't try to get too extreme with the amount of change, then we can simply piggyback the MegaEvolution characteristics with the regular CAP steps to which they apply. More on this in a minute, but first, let me cover the impact to Concept, which has been debated a lot in past discussions of Mega CAP's.

If we aren't making effectively two different pokemon (a la MegaBeedrill, etc), then we don't need to get too fancy with defining a special Concept tailored for a Mega Evolution. Any CAP concept will do. Looking back at past CAP concepts, any one of those could have been done as a Mega Evolution. Because, at the end of the day, a Mega is nothing more than 100 extra BST (excluding HP), and POTENTIALLY a different ability, and POTENTIALLY different secondary typing. That's it. Admittedly, those three things can produce a wide range of "change spectrum", but not necessarily.

Yes, a Mega CAP COULD be a unique platform to accomodate some amazingly interesting Concepts that would be virtually impossible to do with a regular CAP. But I think that is simply too ambitious for a big project like CAP. Create-A-Pokemon is about the "art of the possible". Don't know that phrase? Look it up. We need to focus on what we can actually get done here. And making fancy nuanced Concepts has never been our thing. CAP cuts with a broadsword, not a scalpel. Even with our new Concept Workshop (which has been a very good thing), special tailor-made Mega Concepts are just wishful thinking, in my humble opinion.

So, assuming we can pick a Concept like normal, the relatively minor modifications to other steps for a Mega CAP would look something like this.

Concept Assessment
This is the big "decision" step when it comes to a Mega really. Because this is where we get an idea of how good the pokemon will be pre and post evolution. Will the base form be relatively weak or different in terms of what they bait before mega evolution? Or will the base form be viable on its own? How the base form and mega form interplay is VERY concept-dependent (meaning different Concepts will have a different "right answer" here) , so we won't even try to put any rules on this ahead of time. Other than the general instruction that we are NOT intentionally trying to make two completely different competitive mons (a la MegaBeedrill, or whatever better archetype the rest of you want to throw out for us to use for reference purposes). Beyond that, let the TL wrangle the discussion and somehow chart a general direction for the project. Business as usual, right?

We already slate and vote on Typing as a "package deal", so we simply continue that tradition with a Mega CAP. We don't add a separate step to explicitly decide whether we want the Mega to have a different typing or anything like that. We have a single discussion thread for typing, and we consider the base form typing and the mega typing as a single "package". The base form typing and the mega typing should be proposed and discussed together, along with the interplay of the typing potentially changing upon megaevolution and the risk/rewards of the typing changing or not. Meaning, typing proposal posts might look something like:

"I think CAP 21 should be mono-Normal, just like Kangaskhan and MegaKang. <Insert great reasoning here>"

"I want this pokemon to be Poison/Fairy, all the way, both the base and mega forms. <Insert great reasoning here>"

"I want the base form to be Electric/Ground and the mega to be Electric/Fighting. <Insert great reasoning here>"

If those all made the slate, the slate would be:
Electric/Ground -> Electric/Fighting

I'm sure CAP will probably have a bias towards unique typings and cool typing combinations, but that's certainly nothing new here. We might institute a restriction that only one type may change on the mega evo, if that is, in fact, a rule observed in the actual game. I think it is, but I haven't checked specifically.

On a Mega CAP, I think we should consider the Primary Ability as a potential "dual package", kinda like Typing. Since Mega Evolutions have a single ability, and that ability may be different than the ability of the base form, we should vote on Primary Ability with the potential for a pair. Of course, we may have only one Primary Ability for both the base form and the Mega. That's fine. But we allow discussion proposals for two Primary Abilities as a package, with the first being the base form Primary Ability and the second being the Mega's Ability. We can use the same arrow notation ("->") I suggested above for Typing combinations to indicate a pair of Primary Abilities in the slate. For example, a Primary Ability might look like:

Klutz -> Magic Guard

The first option means the base form Primary Ability and the Mega Ability will be Intimidate. The second option means Klutz will be the Primary Ability for the base form and Magic Guard would be the ability for the Mega.

There does not need to be any change to our existing steps for Secondary Ability and Flavor Ability.

Yes, I can envision some messy discussions about Abilities with a mega ability in the mix. But Ability discussions are already messy much of the time, so I really don't see this as an added burden.

Base Stats
Continuing with the same thinking as with the previous steps, Stats will be presented as a packaged pair. Submitters will create two stat lines, one for the base form and one for the Mega evo. The Mega stats need exactly 100 more BST than the base form stats and the HP stat needs to be the same in both stat lines. The stats "package" will be slated and voted as a single voting option. We can use the arrow notation ("->") to indicate the pair. A slate option would look something like this:

80/100/75/75/100/105 -> 80/135/100/80/125/115

This will require more work and damage calcs by submitters, and choosing a slate will be more complicated for the Stats Leader -- but I don't think it's too much for us to handle.

Not surprisingly, art will probably be the step most affected by doing a Mega CAP. But I think we can take a straightforward approach, and not try to get to fancy or nuanced with our process. We can treat it just like all the previous competitive steps and make Art a "package submission" too. Artists will submit two designs for a legal submission -- a design for the base form and a design for the Mega. Yes, this will be more work, but I will be stunned if top artists aren't up to the challenge. I don't see this much different than what spriters have been dealing with forever, in having to make both a front and back sprite for a legal submission.

We will definitely have to amend the art posting rules, since each submitter will be working on two designs, so they will post twice as much art as usual. But, I can work out these details with the other CAP art mods in short order.

Sprites and/or 3D Models
Twice as much work will be required here, and that could be a problem from a scheduling perspective. But these steps have a very low number of participants that do the heavy lifting and submissions, so I think we can work out the process details for these steps with the people that do the work. At a high level, I'll continue to advocate we treat these steps with the same "package deal" mentality as all the other steps.

That's it. I know I wrote a lot for all those steps, but if you look at it overall -- it really is not a very big change from a process standpoint. Yes, several steps have additional discussion and slating complexities. But there are no new steps, and the intent and outcome of every step is thematically the same as always. We'll just produce "more" on several steps with a Mega CAP.

Onward, to Mega Evolution!

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