Policy Review Build Triangle aka. "Fast, Powerful, Bulky: Pick two."

DougJustDoug

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 Smogon Discord Contributor Alumnusis a Top Tiering Contributor Alumnusis an Administrator Alumnus
Moderator
In software development, there is the concept of a "Project Management Triangle" that refers to tradeoffs when managing the outcome of a project. I've heard this principle mentioned with building things other than software, but I'll stick to software, since that's what I am most familiar with. The principle is often referred to with the phrase:

"Good, Fast, Cheap: Pick two."

Here's a quote from Wikipedia explaining the concept:

Wikipedia said:
You are given the options of Fast, Good and Cheap, and told to pick any two. Here Fast refers to the time required to deliver the product, Good is the quality of the final product, and Cheap refers to the total cost of designing and building the product. This triangle reflects the fact that the three properties of a project are interrelated, and it is not possible to optimize all three – one will always suffer. In other words you have three options:
  • Design something quickly and to a high standard, but then it will not be cheap.
  • Design something quickly and cheaply, but it will not be of high quality.
  • Design something with high quality and cheaply, but it will take a long time.
I frequently refer to this principle when dealing with customers or other managers who invariably always want ALL THREE. And who wouldn't want all three!?! No one wants to embark on a project that will intentionally be Late, Overpriced, or Low Quality. But the reality of software development is that any time you want to increase one aspect of project delivery, you will do it at the expense of another aspect. Grappling with these tradeoffs is the reality of project management, and good project managers are very good at managing these tradeoffs.

I would like to introduce a more formal system of managing tradeoffs on CAP projects.
Basically, I'd like a project management triangle for CAP that I'll refer to as the "Build Triangle" aka:
"Fast, Powerful, Bulky: Pick two."

It follows on the general tradeoff proposition of normal project management, but operates on the proposition that any good, but not overpowered, pokemon cannot have "everything". And in this context, I define "everything" in three broad categories: Speed, Offensive Power, and Defensive Capability. To keep it simple, I use the words Fast, Powerful, and Bulky to describe these aspects of a pokemon.
(I'm not entirely happy with the term "Powerful", but no great alternative that was noticeably better came to mind)

The idea is that when CAP builds a pokemon, we get to exploit up to two of these aspects, and we must hinder at least one aspect. In effect, we commit to never making a pokemon that has "everything". In looking through the list of OU pokemon, most of them can be broadly described in terms of Fast, Powerful, or Bulky -- and most of them have at most two of those things. Yes, there are some pokemon that have "everything" -- they are Fast, Powerful, AND Bulky. But I don't think these are the sorts of pokemon that CAP should strive to emulate. I think we should FORCE OURSELVES to hold back in at least one of these general areas when making our pokemon.

I call this the pokemon's "Build", because it refers to the combined effect of several aspects of the pokemon (discussed below). I think we should decide the Build during our concept assessment. I'm not sure it needs to be a formal vote or anything. But I think we should insist that a formal Build be stipulated in the final post of the Concept Assessment, and we abide by the specifications of the Build in all subsequent project steps.

Despite what some people may think -- the concept of Fast, Powerful, and Bulky are NOT strictly related to Stats. They MAY be a result of certain stats, but not always. In fact, in most OU pokemon, these aspects are achieved by a combination of Typing, Stats, Ability, and Moves.

Here's some details on how these three characteristics of the "Pokemon Build Triangle" might be achieved:

Fast
  • A high Speed Stat
    • The midpoint Speed stat in OU is 90
  • Access to speed boosting Moves
    • Agility, Rock Polish
    • Dragon Dance, Quiver Dance, Shell Smash, Shift Gear
  • Access to Priority Moves
    • STAB Priority moves make it even Faster
    • ExtremeSpeed
    • Mach Punch, Bullet Punch, Shadow Sneak
    • Sucker Punch
  • Speed-boosting Abilities
    • Speed Boost
    • Swift Swim, Chlorophyll, Sand Rush
    • Motor Drive
    • Unburden
    • Rattled
    • Quick Feet
    • Steadfast
  • Priority altering Abilities
    • Prankster

Bulky
  • High defensive Stats
    • The midpoint Defense or Special Defense stat in OU is 90
    • The midpoint HP Stat in OU is 85
  • Typing or abilities that provide resistances or immunities
    • Immunities are HUGE
    • Steel Type
    • Levitate
    • Thick Fat
    • Flash Fire
    • Sap Sipper
    • Dry Skin
    • Heatproof
  • Typing or abilities that resist passive damage
    • Magic Guard
    • Stealth Rock
      • Steel Type
      • Ground Type
      • Fighting Type
    • Spikes and Toxic Spikes
      • Flying Type
      • Levitate
    • Weather
      • Cloud Nine, Air Lock
      • Overcoat
      • Sandstorm
        • Ground Type
        • Rock Type
        • Sand Veil
        • Sand Rush
      • Hail
        • Ice Type
        • Ice Body
        • Snow Cloak
    • Recoil
      • Rock Head
  • Healing Abilities
    • Poison Heal
    • Volt Absorb
    • Water Absorb
  • Abilities that reduce damage
    • Multiscale
    • Intimidate


Powerful
  • A high attacking stat (Attack or Special Attack)
    • The midpoint Attack or Special Attack stat in OU is 100
  • Access to high Base Power Moves with high Accuracy
    • Too many to mention
    • STAB makes Moves even more Powerful
  • Access to attack-boosting Moves
    • Too many to mention
  • Abilities that boost attacks or damage
    • Too many to mention
  • Good offensive typing


My proposal would be to overtly identify the Build we will pursue by the end of the Concept Assessment.

Fast, Powerful, Bulky
Pick two. Any single build characteristic to extreme counts as two. That gives us the following six discreet Builds to choose from:

Fast and Powerful (not Bulky)
Fast and Bulky (not Powerful)
Powerful and Bulky (not Fast)
Very Fast (not Powerful or Bulky)
Very Powerful (not Fast or Bulky)
Very Bulky (not Fast or Powerful)
The point of this exercise during Concept Assessment is NOT to stipulate anything exact in terms of Typing, Stats, Abilities, or Moves. I'm not too concerned with getting into a boring technical argument of how fast is "Very fast" or which exact combination of limitations constitutes "Not bulky" or whatever. The point is to set a general tone for what we all want to pursue, even if our exact interpretations about specifics are different. We all will be arguing over specifics in every thread anyway. But with a Build stipulated at the conclusion of the Concept Assessment, we would set a good general expectation of what we plan to achieve from the Typing, Stats, Abilities, and Moves in combination.

I am not saying these six Builds describes every conceivable concept of pokemon we may choose to build. But it describes a helluva lot of them, and I would rather have some more clarity over the process, rather than have everything completely open-ended and every option open for discussion in every thread. I am intentionally sacrificing some flexibility, in the interest of focusing discussion and imposing some MUCH NEEDED limitations in how we build and discuss CAP pokemon.

Which brings me to the reason I am introducing this concept in this PR -- I think the tradeoffs between Typing, Stats, Abilities, and Moves is a key problem in our process ordering. I don't think we'll ever be able to completely "solve" this problem as long as we have a rigid step-by-step process. It's just the nature of the beast, when it comes to CAP. But I think we can improve the process to handle the tradeoffs BETTER than we do now.

Typing will always come first in the process and Moves will come last, I think that is a given. But Stats and Abilities are always contentious as to which should come first. If we put Stats before Ability, we are biasing ourselves to implement our "build" mostly with Stats. If we put Ability before stats, then we will tend to choose defining Abilities off the bat, and most abilities deeply impact the Build characteristics I mention above. So by choosing Ability first, we will tend to implement the Build mostly via Abilities. This situation was helped by changes in the last PR cycle when we decided to interleave Abilities and Stats discussions, but we still have the dilemma that one of those MUST happen before the other (currently Primary Ability comes first).

My hope is to mitigate the tendency to implement the Build on whichever step comes first. If we overtly choose a Build in Concept Assessment, and commit to stick to it -- then everyone will know the Build we plan to have in the end, and perhaps we won't feel the need to jump in and implement the whole Build on the first competitive step. We can afford to wait until a later step if that makes sense, without fear of the Build going in a different way.

I hope this makes sense. My intention is for the pokemon to gain definition gradually, but still follow a consistent path in every step. Incorporating this with our current process, it might go like this:

  • Concept Assessment
    • Discuss general strategy and playing options in the first part of the thread
  • Concept Assessment
    • Discuss which of the discreet Builds we think fits best in the latter part of the thread
    • In the final post, amongst other assessment info, the TL posts the consensus choice for the Build.
  • Typing
  • Primary Ability
  • Stats
  • Secondary Ability

In this way, I think the Build gives us more concrete direction than the Concept Assessment does normally. I think the Build will indicate whether certain Abilities should be on the table or not, and how it will impact Stats if we choose them. Also, with Typing and one Ability chosen, Stat Spread creators will have a much clearer picture of how Stats should be crafted to achieve the desired Build. Even later in the process, it will give direction and limitations to Movepool creators, as well.

I started thinking about this during the last Policy Review cycle when Korski suggested we interleave stats and ability threads. But after talking it over with Birkal, we agreed this proposal was just too much to digest at that time. We had enough on our plate then. But now the decks are clear, and we have time to consider this as a way to give our project more direction and improve our process.
 
Last edited:

Nyktos

Custom Loser Title
I think this is a very interesting idea. I recall seeing Doug mention it on IRC a while back and I liked the idea at the time, but I'd forgotten all about it. I still do like it, and I think it would definitely have made certain aspects of the last two CAPs (at least) better if it had been around. That being said, I have a couple of reservations.

The first is build being chosen during Concept Assessment. I worry that with concepts that could be done in multiple ways with respect to build (and that's most concepts, really), Concept Assessment will just turn into Build Discussion. Recall that there were some fairly heated discussions (mainly on IRC, but some on the forums as well) about Malaconda's Speed stat, and that was something that ultimately was never formally decided: both fast spreads and slow spreads were allowed and slated, and Speed was decided along with all the other stats in the stat spread poll. If we'd had to formally decide on whether or not we want Malaconda to be "fast" before stat spread submissions, there would have necessarily been a lot more debate on the forums about that issue; easily enough for its own thread I think. In Aurumoth's case we just went ahead and took all three, but I'd imagine that if we has been forced to choose a build there would have been a lot of discussion there as well (probably full of endless circular arguments about the definition of risk).

It's possible that giving direction to the Concept Assessment thread (which as of now is somewhat abstract) in this way is not a bad thing, but I think that there's a very strong risk of pushing the types of discussions that we currently have at that stage out of the spotlight, and those discussions are quite valuable. Moving build to its own thread is a good way to prevent people from jumping the gun and discussing builds before we've gotten a handle on what exactly we want our creation to achieve. This is especially true when you consider that there will need to be TL approval for a general direction before build discussion can happen in earnest anyway. Looking at Malaconda, could we really have meaningfully discussed a build before deciding that we wanted to help sun?

My second reservation is that I worry it may limit the variety of options available during the abilities and stats stages. This is not necessarily a bad thing (to some extent, doing this is the whole point), but looking again at Malaconda both of those polls offered a wide range of options that fell into different builds. On the abilities side, we had four options on the poll. Two of those completely dictated build: Chlorophyll more or less automatically means Fast, and the arguments in favour were based on Fast and Bulky in particular; and Flower Gift makes a Pokémon Powerful and Bulky all on its own. The stat spread we ended up with probably comes closest to Very Bulky, so it's easy to imagine that had we had a build discussion neither of those abilities would have ended up on the slate, and we'd have ended up with an even stronger case of "Harvest and a bunch of dorks" than we already had. The same was true for stats: like I said, that stage was all about the Speed. If we'd decided ahead of time that Malaconda would not be fast, we'd have ended up with a lot less variety in stat spreads to vote on. If you look back at the paste I made during that stage, you'll see that within any of the given speed categories, spreads were broadly quite similar within each speed category, and if we'd had to limit it to just one of them we would not have been able to make a very large slate without including near-duplicates.

Again, this is not inherently a terrible thing; after all, we're just "factoring out" the build into its own thing as opposed to voting for it by proxy during stats and abilities. But I do think it runs the risk of making stats and abilities less interesting stages as it's a lot more likely that you run into one "obvious" ability or general range of stat spreads when you already know the build ahead of time. I don't think this will happen every CAP, but it will happen some of the time.

Ultimately I do think the idea is worth giving a try. It's got some very good things going for it: it helps prevent an Aurumoth-style monster, it allows ability and stat discussions to have everyone on the same page, and means there's an actual place where "should this be fast or slow?" is actually what we're supposed to be arguing about. It also allows Stat Limits to be the boring technical thread that it's probably best off being while allowing the general "shape" of the stat spread to be discussed in a manner that's easier for the average user to follow. I would say that I am (slightly hesitantly) in favour, provided we make Build Discussion a separate thread.
 

Quanyails

On sabbatical!
is a Top Artist Alumnusis a Community Leader Alumnusis a Community Contributor Alumnus
When I read through this idea, I thought it should be tried. The limitations that CAP 5 had made Malaconda focused rather than compromised at points here and there, diminishing many a CAP to bulky attackers, not to mention an aversion to the dichotomy between actual pokemon and the stigma of CAPs. The implementation, though, seems to require modification to Concept Assessment, and deciding on a build causes later steps to be less variable. Nyktos wrote out my concerns about that (thank you, Nyktos), though I think that solidifying ideas at that stage rather than discussing and ending up with a vague "direction" would give the CAP needed focus.
 

nyttyn

From Now On, We'll...
is a Forum Moderator Alumnusis a CAP Contributor Alumnus
Most pokemon in OU and UU tend to subscribe to this philosiphy, and I see no reason why we shouldn't follow in turn. This both gives us more structure, and helps keep the project on rails. I also don't see any issues in the OP.

I'm not particularly concerned about limitations either. There's still a ton of options to explore, we just can't have all three at once. We can have a fast and bulky mon, a powerful and bulky, a very fast, etc etc, but we can't have a powerful, fast, and bulky mon.

As for any issue of arbitraryness, I think we should leave it up to the TL and TLT to decide what constitutes as "bulky," "fast," "powerful," etc for any given CAP project. Their job is to guide discussion and make sure the project doesn't get out of hand, after-all. Sure, this would be a step back towards the strong TL model, but I don't (pre-emptively) see it as a slippery slope, since what a "fast" or "powerful" mon counts as will depend on typing, the meta at the time, etc. Too many factors to dictate as hard and fast rules.
 

jas61292

used substitute
is a Community Contributoris a Top CAP Contributoris a Forum Moderator Alumnusis a Battle Simulator Moderator Alumnus
While I like this idea in theory, I honestly think that putting it as a concrete stage at or around the time of concept assessment would have an overall negative effect on the discussion quality of the project. The fact is, the discussions that we would need to have to decide on this that early (or really, at all) would essentially be a condensed version of every single discussion throughout the entire project. This would really be a piss poor discussion as everyone would be trying to say way too much while knowing way too little. Not only that, but once a decision is made, I feel it would too greatly limit the discussions (and thus discussion quality) of those stages that come later. Often times the certain discussions that would be majorly affected by this (notably talks about Speed stats) are some of the best and most interesting debates we have in this project. With a system like this, those discussions would likely be killed. Instead of a great debate on speed, we would have a big mess of a discussion early on that would somehow end up saying we are either "fast", "very fast" or neither, which honestly doesn't even mean that much. I do like this idea in theory, but I don't really think we can have a stage like this enforcing it without detracting from the good things we already have.

With that said, I definitely think it would be a good idea to put something like this formally into the responsibilities of the TL. I don't think it is so important for us to formally decide which of the options we do, but I do think it is very important that we alway do limit ourselves to a maximum of two of these characteristics. As TL myself, I was always very much aware of how strong a Pokemon we were and I consciously made sure that we were never drifting too close to doing all three. Fortunately for me, we were never all that close this past project, but it was always something in the back of my mind nonetheless. This is how I think it needs to be approached: a formal policy that we will never have all of "power," "bulk," and "speed," but no more direct approach other than saying that the TL (with possible help from section leaders) is responsible for making sure this is the case. Even if we don't have specific statistical rules for what this means, making it an official policy should go a long way towards preventing things like what happened with Aurumoth.
 

Bull of Heaven

Guest
Concept Assessment
    • Discuss which of the discreet Builds we think fits best in the latter part of the thread
    • In the final post, amongst other assessment info, the TL posts the consensus choice for the Build.
I have mixed feelings about the whole proposal, largely because of the concerns Nyktos and jas mentioned, but for now I just want to bring up the one part I completely disagree with. The Build would be a huge defining aspect of the creation, can't inherently break it so early in the process and is something that's often decided in competitive polls right now. It would need a vote, even if not all options were slated.
 

Bughouse

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
The biggest issue I see with this is how it interacts with our new TL/TLT model. I think it places a lot of power on one or two TLTs who then force the hand of other TLTs. Say Moltres didn't exist and the goal was to be the "ultimate scizor counter." A bulky build is chosen, followed by Fire/Flying. This then forces the hand of the ability leader to heavily consider Regenerator or Magic Guard, etc. this is an extreme example, but I think dictating this sort of overall 100% follow the bouncing ball is detrimental when combined with the segmented leadership. A huge part of the TLT's success in my mind is the diversity of styles and opinions that can come from each stage.

I think this would have been a good way to combat the strong TL and would have been a different, effective measure to ease the TL process. But in the new era of leadership format, I'm less convinced this is necessary or even good.
 

DetroitLolcat

Maize and Blue Badge Set 2014-2017
is a Forum Moderator Alumnusis a CAP Contributor Alumnus
I will have more to say on this later, but I agree greatly with what jas61292 and srk1214 have said. After reading the OP of this thread, the first thoughts that came to mind were "this system will interact poorly with the TL+TLT model" and "This decides way too much way too early".

Proponents of this system claim that it adds more structure to the CAP project. My rebuttal is this: "Since when does CAP need more structure?" At the moment, we have clearly defined steps where nearly every conceivable aspect of the Pokemon is considered, discussed, and voted on. We have a set order of events, discussions and assessments where we evaluate our options, and an open forum (#cap on IRC) where we can air our concerns and speak directly to the "upper management" of CAP. Aurumoth notwithstanding, we have done a very good job already of loosely deciding "Build" during the Concept Assessment and especially the later stages of the project. For clarification, by "later stages" I'm referring to Typing, Abilities, Stats, and Movepool.

If by "structure" you mean "direction in which this project will move after the Concept has been determined", then a gradual approach has been successful and I fear that a "Build Discussion" would front-load the project and decide a great deal of our Pokemon before we even know what we're doing with it. To emphasize how early in the process this discussion would be, let me remind you all that the only piece of information we have at this point concerning our Pokemon is the Concept. At this point, we have not discussed stats, abilities, or even typing in earnest. As jas61292 has stated and the OP has implied, this discussion would encompass Typing, Abilities, Stats, and Moves. The OP has implied that this discussion would primarily focus on Abilities and Stats though it would not neglect the other two aspects. However, we run the risk of providing too much direction with this hypothetical Build Discussion while robbing ourselves of the creative liberty CAP is known for.

Allow me to delve into hypothetical situations. If, during a Build Discussion, we were to decide on a Very Bulky or a Bulky and Powerful Build, then we would heavily diminish the value of our Movepool discussion. For example, if a Very Bulky build were chosen and we gave the Pokemon a moderately high Speed stat or a Speed boosting/Priority-altering ability, then there would be no chance of the Pokemon receiving priority moves, Speed-boosting moves, or any other move associated with mitigating Speed. Consequently, we would have no need to discuss these potential features. If a Very Powerful build were chosen and the Pokemon received Regenerator, a Base 105 HP stat, or some other bulk bonus, then we would not even need to (or get to) discuss a recovery move, Wish, or any other move associated with preserving bulk. While some might see that added focus as a benefit to our CAP because it allows us to focus on more germane issues, I ask "issues like what?". What makes our Movepool, Stats, and (newly reformed) Ability discussions so great is that we start with dozens if not hundreds of ideas and, over time, our TL (or TLT member nowadays) guides the discussion and we end up with the ideas that work. We start out with either carte blanche or whatever direction the Leader provides and winnow our ideas until we create a slate of ideas. With this Build Discussion as an overarching guideline, we preclude numerous topics that could have been insightful, useful, or just plain fun to discuss. If this Build Discussion is put into effect, I see many otherwise great discussion threads riddled with comments such as "that doesn't go along with the Build" or "We can't give it 120 Speed because we said Powerful and Bulky".

As Malaconda's Stats Leader, watching the community's dichotomy into "CAP5 should be fast!" and "CAP5 should be slow!" camps was very enjoyable to preside over. We exposed ourselves to two very interesting, equally valid schools of thought on how a defensive, Harvest-abusing Pokemon would benefit Sun teams. If the Build Discussion had already taken place, one of those camps would have had to fight an uphill battle to be slated, most likely would have been eliminated early in the discussion, and the discussion would have progressed to "which slow spread is best". In my opinion, that discussion would have been much more monotonous and just plain boring. Topics such as "Should CAP 5 be able to survive Specs Latios Draco Meteor" would have been one of the Stats Discussion's few points of interest instead of one of its many points of interest. Even though no consensus was formed in the thread and both fast and slow spreads were slated, it allowed us to settle our differences through viva voce rather than a Discussion based on literally nothing besides the Concept.

Which brings me to my next point: a Build Discussion is largely incompatible with the TLT. We implemented the TLT model because we felt that placing too much influence in the hands of a single person was a detriment to our Project, not an asset. DougJustDoug himself stated in the Policy Review on Topic Leadership that
DougJustDoug said:
I think the benefit of a single person's vision is way overrated.
I contend that placing too much influence in the hands of a single discussion is way overrated-we generate much more quality discussion from four open-ended, TLT-guided discussions than from one megathread that dictates the direction of the next two months of process. Furthermore, TLT members who did not get their way during the Build Discussion will most likely become dissatisfied with their position. If the Abilities Leader believed that Speed (or priority) boosting Abilities achieves the concept but the Build was Very Powerful or Bulky and Powerful, the Abilities Leader would be stuck between a rock and a hard place. The Ability Leader's options would be to either comport with the Build Discussion and leave out (or heavily reduce the discussion value of) an entire family of Abilities or ignore the Build Discussion and go his own way resulting in one step not comporting with the pre-determined Build. The concerns of "Frankenstein's (Pocket) Monster" become much more pressing.

One potential benefit outlined in the OP is that we don't have to front-load our CAP and accomplish the Build early on. As DougJustDoug said,

DougJustDoug said:
My hope is to mitigate the tendency to implement the Build on whichever step comes first. If we overtly choose a Build in Concept Assessment, and commit to stick to it -- then everyone will know the Build we plan to have in the end, and perhaps we won't feel the need to jump in and implement the whole Build on the first competitive step. We can afford to wait until a later step if that makes sense, without fear of the Build going in a different way.
Although that is a great ideal, I have concerns about it actually functioning as intended. If we choose to accomplish most of our Build early-on, we leave almost zero direction for the later stages. For example, if we chose a Powerful and Fast Build, gave our Pokemon a Dragon/Fighting type, high Attack, low Defenses, a high Speed and a nice Ability like, say, Guts to top it off, we would have very little direction for the Movepool discussion. We could go any which way, but the Build Discussion would fail to provide any structure since no matter what we did, we would accomplish the Build. On the other hand, if we waited towards the end to accomplish our Build, we would spend the later steps of the CAP "playing catch-up" to make up for the less Build-friendly steps early on. For example, if we chose a Fast and Powerful Build and gave our Pokemon a Poison/Steel typing to give it a little bulk early on, we would probably have to spend the entirety of the CAP tacking on Speed boosts, power boosts, and other Build-friendly aspects while entirely ignoring bulky options. The latter of the two situations concerns me the most, as it severely limits the options available in the last stages of our CAP.

I do not doubt that the Build Discussion would be a wonderful, high-quality discussion. I do, however, fear that the results of the Build Discussion would front-load the process, place way too much emphasis on the early stages of the CAP (I understand that this Discussion attempts to mitigate that problem. I do not believe it will do so.), and diminish the four TLT-lead discussions during the main CAP. I fear that this model is in direct opposition to the TLT model we recently implemented and will diminish the effectiveness of that model.

As I said earlier, I have no doubts that the Build Discussion will be a high-quality discussion. However, is it worth "demoting" the four major discussions and decreasing the quantity of opinions available in the later discussions and polls? As someone who leads discussions and creates slates based on quantity of opinion, I have serious concerns about this proposition. The points raised by jas61292 and srk1214 intensify these concerns.
 

DougJustDoug

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 Smogon Discord Contributor Alumnusis a Top Tiering Contributor Alumnusis an Administrator Alumnus
Moderator
After reading comments in this thread, I think we should discuss this as two separate proposals (maybe three), which hinge upon the concept of a Build Triangle comprised of Fast, Powerful, and Bulky aspects.

I am assuming there is general consensus that the Build Triangle is a sound CONCEPT. Meaning, we agree that most aspects of a competitive pokemon build can be summarized in terms of three broad areas -- Fast, Powerful, and Bulky. Yes, there are other niche aspects of a competitive pokemon that are not encompassed by the Build Triangle (utility, annoyance, luck-altering, etc). But the Build Triangle captures a very broad range of the most important general aspects, and expresses them in three simple, intuitive terms.

If you disagree with the basic concept of a Build Triangle, feel free to bring it up and we can debate it further. But if there is no objection, for the rest of this thread, let's assume we all generally agree on what the Build Triangle means, and we think it is a decent (but not perfect) way to talk about the Build of a pokemon. I'm not trying to railroad the general definitions, but I just want to move on to the points that appear to be real points of contention in the OP.

So, I'd like to propose two separate proposals. The second proposal is predicated on acceptance of the first, but we could adopt the first proposal and not adopt the second.


Proposal 1: We will not make CAP pokemon with an end result Build that has everything. Through the course of the project we will strive to adhere to the principle of "Fast, Powerful, Bulky: Pick two."

This proposal does NOT mean we will identify a Build at the beginning of the project, or otherwise. It means that we all agree that a good-but-not-overpowered OU pokemon should not have a perfect Build. CAP pokemon should be intentionally limited in at least one of the Build aspects. Throughout the CAP project we can use the Build Triangle and the six discreet Builds described in the OP as a yardstick to discuss our progress, and to evaluate various options in each step. The TL/TLT can use the policy of Build limitation as justification for making certain decisions where they deem it appropriate.

Jas is the one who pretty much made this proposal in his earlier post, and I appreciated his insight to separate this concept from the rest of the ideas mentioned in the OP. I definitely agree we should, at a minimum, formally establish this as a desirable end goal for our CAP pokemon, and introduce the concepts and terms related to the Build Triangle as part of the language of competitive CAP discussions.


Proposal 2: We will hold a Build Discussion in the early stages of the CAP process, where we explicitly identify a Build that will be observed throughout that CAP project.

The main point of this proposal is to see who agrees that we should make an explicit Build decision early on in the project. Based on some feedback, there are people who are concerned that an explicit Build will unnecessarily limit the project and topic leadership. I can understand the fear there, but because all three aspects of Fast, Powerful, and Bulky are so broad, and capable of being implemented in so many ways, I'm not as worried on that front.

I think most involved project participants have an idea of a Build in mind from the outset anyway. And because they have that "hidden agenda" they tend to want to implement the Build as soon as possible on every project. So if they have "Very Bulky" in mind, they argue for Steel typing, then they argue for Regenerator as an Ability, and they argue for big HP and defensive stats. Meanwhile, the "Fast and Powerful" crowd is pushing for Electric typing, Swift Swim, and huge attacking stats. And the end result is the oft-mentioned "Frankenstein's Monster" effect, that results from each faction winning different steps of the project.

I personally get sick of the same basic faction war happening in every step of the project. Good topic leadership helps mitigate this problem, but I think we can do better. Since the idea of a Build is on many people's hidden agenda anyway right from the very start, I'm thinking we should just get it out in the open and decide on it. And since the definitions are vague, it really only serves to guide general perception, rather than place formal limits on any actual competitive steps.

So yeah, if we decide "Bulky and Powerful" is the way we want to go, and there are people who are thinking a mon with 130 speed and multiple priority moves would be great for the Concept -- then yes, they are shit out of luck. But I think this is a good thing to get this massive disconnect out of the way early, rather than having wildly divergent factions arguing in every thread.

ALSO, I am intentionally not indicating when we will hold the Build Discussion, I am open to suggestions. It appears that many people don't think we should do this in the middle of the Concept Assessment, and I can understand the arguments against it. But I want to point out that we have had many problems with Concept Assessments in the past, because USUALLY nothing meaningful ever gets decided! We have a broad ranging discussion about the Concept and sometimes the TL posts their "conclusion", but no one in the project usually has a clue what the "assessment" is or what it means for later steps.

CAP 5 was an aberration in that regard. I applaud Jas for being a fantastic TL by communicating a clear conclusion to the assessment in CAP 5 that was vague enough to leave lots of room for interpretation, but direct enough to actually guide every subsequent step. This is definitely NOT the norm in CAP, even with some of best Topic Leaders in the past. It is not a failure of the TL if the concept assessment has no substance -- it's because most Concepts are very difficult to "assess" in terms that are vague but still meaningful. Jas was brilliant to hinge his assessment on Sun-support, but we can't do weather-based assessments on every CAP concept.

Without this policy in place, my bet is that future Concept Assessments will go like most past CAP projects: We talk about the concept for a few days and then we move on to the competitive steps and everyone fights it out to implement their own personal assessment in every thread. The assessment just allows people to air their opinions ahead of time, but nothing really gets accomplished.

My hope was that by requiring a Build to be identified in the conclusion of the Concept Assessment, we could put some real substance in the Concept Assessment thread and give the Topic Leader something to hang their hat on. If we want to do a separate Build Discussion right after the Concept Assessment, or after the Threats Discussion, or maybe even after the Typing is decided -- I'm OK with that too. But I think the Concept Assessment is usually just fluff, and it is in need of a clear purpose.
 

Bughouse

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
I really do appreciate the effort you are making, Doug, on improving Cooncept Assessment. I am in complete agreement that most of the time it is not a productive step. Often it even ends more confused than it begins. I think if we are to implement an actual process, then Concept Assessment is the place to do it. And even if we don't, I do support including Proposal 1 in CAP's literature.

That said, I share the concerns that this decides too much too soon. I think a compromise can be reached where we do limit our options, aka focus, to some degree in that early stage. I just don't think this current procedure is it. I could imagine a scenario where maybe we limit ourselves to 3 or 4 options early on from the 6, but not 1 or 2. Realistically that's not a good option either, but I guess I'm saying I would support something that still stayed somewhat open-ended and didn't decide too much at once.

I'll spend more time thinking of a proposal myself, but I think someone will probably beat me to the punch.
 

DougJustDoug

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 Smogon Discord Contributor Alumnusis a Top Tiering Contributor Alumnusis an Administrator Alumnus
Moderator
Obviously I have posted a lot of words in favor of the proposals mentioned above, but I'm not as fanatically enthusiastic as it might seem. My main goal is to get CAP discussion participants to openly manage tradeoffs as we build pokemon, and give us some basic language and structure to discuss tradeoffs. So, I'm mostly interested in adopting Proposal 1.

Proposal 2 may be a bit too much for some people to comfortably endorse right now, so I can see the concern there. If that is the case, I'm fine if we adopt Proposal 1 and see how things go with this new Build Triangle concept as an accepted part of CAP discussions. And if it works out well, maybe we'll decide to adopt Proposal 2 or a modification of it for a later CAP. I often push for bold changes, but I understand that we may need to ease into something like this and take a more gradual approach to it.

Here are two fundamental questions that I'd like to hear other opinions on:

Do you think the Concept Assessment should have a substantial conclusion?

More descriptive: Do you think the Concept Assessment thread -- or potentially a combination of threads at the beginning of the project where we are "assessing" at a high level how we will implement the Concept -- should have a discreet conclusion where a tangible decision is made at the end of that assessment period? Currently there is no policy for what should result from the Concept Assessment, and most CAP projects do NOT get any meaningful result from the Concept Assessment. Is that a problem or not?


Do you think a discreet Build decision (by vote or discussion consensus) would be an appropriately "substantial" decision after assessing the Concept? Or do you think it would decide too much too soon?

Feel free to post on any of the stuff presented in this thread so far, but if any PRC members are following the thread and wondering exactly how they should weigh in -- the two questions above might help you frame your opinion and your response.
 

Quanyails

On sabbatical!
is a Top Artist Alumnusis a Community Leader Alumnusis a Community Contributor Alumnus
A definite goal early in CAP focuses the project without a defined goal, previously, people may decide on one CAP component for one reason and another, another. Various interpretations on where to go with the CAP can end up with a CAP that only tangentially relates to the original concept, while a defined task, at least, narrows submissions to interpretations of how the CAP will fulfill it instead of what task it will fill and if it adheres to the concept. This may cause later discussion to stagnate if this goal is set too early, though; Concept Assessment is an early step. Nevertheless, I say it's good to have a defined and tangible conclusion at Concept Assessment's end.

That being said, I'm not sure how a separate build discussion, especially one that's early on, will interact with the other steps in determining stats. People will, at some point or another, discuss over what build/stats they think works best for the CAP. I don't know of any obvious pros or cons to relocating the step, though I'd like to see it in action.
 

Stratos

Banned deucer.
It's easy for people to say that it's too constricting to come to a definite conclusion on build after CAP5 just happened. Surely, after the great focus jas had already given us, adding a build to that would have virtually railroaded the process. But remember that only very recently was everyone pinning the failure of a CAP project on the lack of any direction at the end of the Concept Assessment. Rarely, due to people thinking that straightforward concepts are 'so boring' do we have something as cut-and-dried as a Sun Assistant. I would have loved having a definite build in place for CAP4, for example, because there would still have been many directions to take the build and it wouldn't have ended up being ALL of the builds (personally i think CAP4 would have been fun to take in the Very Powerful direction but i digress). my point is that we definitely do need a better direction at the end of our concept assessment, and the build is just another way to accomplish this. I don't know if we need to make deciding a build mandatory, but the TL should use it as a tool and push the community to consider builds if no other means of narrowing down the concept is forthcoming.

(Come to think of it, deciding on a build is basically what we did in CAP1 and CAP2's concept assessments. It worked then!)
 

DougJustDoug

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 Smogon Discord Contributor Alumnusis a Top Tiering Contributor Alumnusis an Administrator Alumnus
Moderator
Pwnemon raises an interesting possibility -- instead of making a Build decision mandatory at the end of the Concept assessment, it could be optional based on TL discretion. Basically, if the TL doesn't have a good vague-but-guiding conclusion to the assessment, they can use a Build as a go-to conclusion device for that step.

It would allow for situations like CAP 5, which was great and would have been too restrictive with a Build on top of it from the start. But for most CAP projects, a Build could be just the tool the Topic Leader needs to wrangle a workable conclusion to most Concept Assessments. If we want Build to be voted on, the Topic Leader could host a poll and then conclude the Concept Assessment after it is decided, and post the Build along with any other concluding directions.

If we did it this way, we would need to make sure no negative stigma is attached to TL's using Build as part of the Assessment conclusion. We don't want people thinking,
"Wow, LeaderDude is a lame TL on this CAP, because they couldn't come up with a cool and innovative Assessment conclusion like Jas did on CAP 5. They bailed out and went with a boring Build decision. Fail."
My guess is most CAP concepts would probably do well with a Build as a guide. The CAP 5 assessment was a Black Swan event, and we shouldn't expect every project to work out like that.

If we put Build as a tool in the Topic Leader's hands to use where they feel it is appropriate, that might be the best way to implement this sort of thing.
 

jas61292

used substitute
is a Community Contributoris a Top CAP Contributoris a Forum Moderator Alumnusis a Battle Simulator Moderator Alumnus
It's easy for people to say that it's too constricting to come to a definite conclusion on build after CAP5 just happened. Surely, after the great focus jas had already given us, adding a build to that would have virtually railroaded the process. But remember that only very recently was everyone pinning the failure of a CAP project on the lack of any direction at the end of the Concept Assessment.
This is very important, both for and against these policies. I think the later part, the part where we have had projects like CAP4 where there was a lack of direction, shows that having a policy like Proposal 1 would be very good to have. Even if we don't have to have an official statement of declaration of the direction we chose, we wouldn't be allowed to just do everything. As the project evolves we would be forced to choose one direction eventually.

At the same time, the former part of that quoted paragraph is why I would not be in favor of Proposal 2. Now, of course, I can only see things from my own point of view, and I'll only ever have my one experience as TL to look on in great detail, but with that said, I don't want this proposal to pass as a mandatory thing because in my honest opinion, had something like this been in place for CAP 5, the project would have not gone nearly as well. We had direction without it, and the things it would have decided would have eliminated the quality discussion down the road. As Pwnemon said, having the direction we had PLUS a build "would have virtually railroaded the process." I believe that a good, non-build related concept assessment is infinitely more valuable than simply having one of these builds determined, and having both together is possibly the worst thing of all as it could choke the quality out of the debates that are the lifeblood of this project.

Pwnemon raises an interesting possibility -- instead of making a Build decision mandatory at the end of the Concept assessment, it could be optional based on TL discretion. Basically, if the TL doesn't have a good vague-but-guiding conclusion to the assessment, they can use a Build as a go-to conclusion device for that step.
This I like. I mean, really, its not actually any sort of proposal at all. TLs can already do this, and in the past already have some times. I don't think builds are the best form of concept assessment, but in the absence of any more formal conclusion to that thread, a build can serve to at least provide some structure to the project. So, basically saying "officially" something to the effect of "Hey TL! Having trouble getting concept assessment to come to a coherent consensus? Try talking about builds and using that." Not so much a rule but some good advice, and I can see no reason for us not to support this "policy."
 

Korski

Distilled, 80 proof
is a CAP Contributoris a Forum Moderator Alumnus
These Iron Triangle proposals actually constitute a very satisfying solution to what I believe is a problem with the way the Stats Limits discussion stage is handled. I posted this post during CAP5 stat limits out of frustration with the way some users were non-transparently fudging the numbers. This was a problem only in that it was non-transparent and also unexpected; people like me felt compelled to post reactionary complaints about losing a debate that never really even took place, even though there was nowhere to actually have that debate except informally on IRC (I'm not a sore loser; CAP5 came out very well). My point is that there is no such thing as a "Speed Stat Discussion" or anything like that in CAP, which is why I think the proposed "Build Discussion" should just replace the Stats Limits discussion in the CAP process entirely.

The Stats Limits Discussion, in practice, is essentially just a less-comprehensive version of Doug's Iron Triangle proposal.

We have a sophisticated system for measuring the "quality" of our stat spreads that easily facilitates the balancing of stats when scoring ranges are imposed by the Stats TLT. Higher Speed means lower Attack (and vice versa) and higher HP means lower Defense (and vice versa); this is how it's always been and always worked since X-Act created the original BSR calculator. We already balance Power by way of Speed, just not while also factoring Bulk into the equation. There is no good metric currently for comparing all three of Power, Speed, and Bulk at the same time, which is ironic, considering that's the entire point of imposing limits of stat submissions in the first place. To incorporate Bulk into the Speed/Power relationship, we rely on BSR, the most easily-manipulated rating we use, which has resulted in an assembly line of groan-inducing "typical CAP" bulky attackers. Doug's three-dimensional approach to stat levels is impressively simple for how much more abstract it is than the simple dichotomous math comparisons we've been using.

I think imposing individual limits on SS, PS, ST, and PT is what keeps us from adequately balancing Speed, Power, and Bulk.

Newer users won't remember this, but our stat limits used to include restrictions on ODB and PSB, restrictions that were lifted for being misleading in terms of balance. Well, here I am saying we should add all of SS, PS, ST, and PT to the list of misleading statistics. We have tricked ourselves into compartmentalizing "balance" separately into each of these four categories, each of which is only a balancing of two stats, meaning that at no point do we really have to consider, for example, the simultaneous interactions that Speed can have with both Power and Bulk (and what that could mean for the competitiveness of the CAP, or for the concept, or for the direction). Speed is the best example of this, but the same can be said for Power and Bulk. BSR can't accommodate for this gap in critical thinking because it is basically an arbitrary "goodness" rating we've invented to self-regulate our stats in relation to currently existing Pokemon. Also, since Abilities and Movepool can affect all of Speed, Power, and Bulk beyond the reach of the BSR, our heavy reliance on these four numbers can only ever err on the side of brokenness. In my opinion, this is a huge part of how CAP4 spun out of control (besides Abilities, which I believe we've fixed for the most part) and how CAP5's Stats Limits thread became a secret proxy for the actual stat spread submission stage.

The Build Discussion should be about focus, not about categorization or limitations.

We have a Stats TLT, a Project TL, and Forum Mods to provide oversight on inappropriate stat spread submissions. I am not worried about CAPX being a 120 Atk / 135 Spe Dragon coming off a 10-minute submission post or whatever because we have an excellent leadership structure in place. When I read through this thread I was looking to see if anyone had any ideas on how to actually pursue a method of comparing the three of Power, Speed, and Bulk all at the same time, mathematically or otherwise, but as I thought about it, the more I realized that what the Stats stage needs more than limits is a refocusing on the concept and direction. This proposal is perfect for that purpose. By the time Build Discussion comes around (replacing Stat Limits ideally, so after Primary Ability and before Stat submissions), we will have a concept, a concept assessment, a typing, and a primary ability from which to glean clues about the growing relationship amongst the three pillars of Doug's proposal. We should use the Build Discussion to analyze where our trajectory is headed and to refocus ourselves toward how we want the three of Power, Speed, and Bulk to lean on each other before we tackle the two historically most difficult stages of the CAP project, Stats and Movepool. I would think of it as a 'Concept Assessment 2' sort of thing and a means for everyone in the community to come together to discuss direction with some actual concrete information to work with.

Oh and I think the TL should run it, and it should be mandatory; I hope that was obvious.
 

Deck Knight

Blast Off At The Speed Of Light! That's Right!
is a Forum Moderator Alumnusis a Top CAP Contributor Alumnusis a Top Smogon Media Contributor Alumnus
I'd like to propose a radical offshoot from the general discussion, started with a question:

Why do we need to decide on a single Build?

I mean this not in the sense that we shouldn't decide one, but rather we should accept a spectrum of builds (two would be preferable, no more than three or else the purpose of doing so is defeated.)

The problem with a singular build definition is that it makes most stat discussions turn into a contest of cookie cutter tweaked builds that are essentially slightly modified clones of each other.

I for example consider Speed an aspect of Bulk because of Speed's inherent place in determining attack order. A Pokemon with mediocre statistical bulk but a fast Recover or Will-O-Wisp is much more easily able to stall out opponents. Let's say we choose a Build of Very Bulky and I decide to go with decent defenses and 113 Speed (Serperior model) utilizing the argument that the Pokemon will be able to cripple foes before they can move. Except I can't really do that because it would be assuming moves in the movepool that would bias the Pokemon that way.

My suggestion then, instead of selecting a specific build at the Concept Assessment, we literally "Pick Two." That is, we say that generally the CAP should have the qualities of being two of Fast, Powerful, and Bulky - and then letting the submitters choose between every valid iteration on that spectrum.

So if we choose "Fast and Bulky" as our emphasis points for example, Submitters could submit stats and abilities that would (in isolation) fit builds of Very Fast, Fast and Bulky, or Very Bulky - on the assumption that whatever they classified their build as, we would work as a community to balance the remaining steps to provide the other category.

Examples would be something like:

Build Emphasis: Fast and Bulky
Ability: Speed Boost
Stats: Very Bulky, Low Power / Mid-Low Speed OR Bulky with Mid-High Speed, Low Power.
Movepool: Basic defensive staples, maybe attacks like Leech Seed, with direct recovery moves depending on overall parameters so as not to make it *both* Very Fast and Very Bulky simultaneously. In the latter instance, moves like Screens that can last multiple turns and be Psuedo-passed.

Build Emphasis: Fast and Bulky
Ability: Regenerator
Stats: Very Fast, Low Power / Medium Bulk OR Fast, Medium-High Bulk, and Low Power.
Movepool: Turn-grabbing moves like Fake Out, Disruption like Taunt and Will-O-Wisp, U-turn / Volt Switch / Baton Pass., in the latter case, moves like Rock Polish.

Build Emphasis: Fast and Bulky
Ability: Limber
Stats: Highly Variable (Must emphasize both speed and bulk and limit power)
Movepool: Highly Variable (Works directly based on previous decision)

Truthfully I don't forsee a CAP where we focus on just one aspect because those Pokemon tend to do fairly poorly. Ninjask is what happens when you do all Speed and Rampardos is what happens when you do all Powerful. Blissey is what happens with All Bulk, but Bulk is obviously the most desirable in a vacuum.
 

Birkal

We have the technology.
is a Top Artistis a Top CAP Contributoris a Top Smogon Media Contributoris a Site Content Manager Alumnusis a Battle Simulator Admin Alumnusis a Senior Staff Member Alumnusis a Community Contributor Alumnus
I will keep my thoughts brief. I'm a huge fan of the Build Triangle and would like to see it implemented to CAP in some way. At least, I could see it serving as a limitation; we could make a hard rule that each CAP cannot have all three points of the triangle. I'm fine with us adding an extra stage to discuss this, or making it a part of our Concept Discussion. I'd even be alright with Korski's recommendation of making it a part of Stat Limits. I'll leave Doug to lead and conclude this thread, but note that I will be happy with any implementation of the Build Triangle into the project.
 

Nyktos

Custom Loser Title
Thoughts before this wraps up:

I think Doug's proposal 1 should definitely become part of CAP's "philosophy", even if it doesn't "do" anything in particular. It doesn't seem like anyone strongly disagrees with that though.

I do still think that making the Build Triangle an official part of the CAP process is a good idea that's worth trying at least once. I also stand by my position that it should be its own thread. The idea of making it an optional part of Concept Assessment is fine too, but I would prefer it to be a mandatory discussion that happens on its own. Korski's post gives good reasons as to why it should be mandatory; I too had thought of it as a cure for some of the problems the Stats stage has. And I think if it is mandatory, it can't be part of Concept Assessment, because it will dominate that thread even in those projects where there are other major issues to discuss at that stage.

The exact point in the project that it appears I don't have a strong opinion on. It needs to be before Stats, but I think more or less any point between the end of Concept Assessment and the beginning of Stats would be a reasonable place to insert it. Putting it earlier gives more focus in stages like Typing and Primary Ability, while putting it later allows already-made decisions to have an impact on the build and prevents the possibility of removing variety from those stages.
 

jas61292

used substitute
is a Community Contributoris a Top CAP Contributoris a Forum Moderator Alumnusis a Battle Simulator Moderator Alumnus
I know it has picked up some steam with these last few posts, but I want to again state that I don't think these proposed ideas would do good for the project, and may in fact cause significant harm to our best discussions, if it is required. As myself and some others have already said, we need look no further than our most recent project to see a case where adding a step like this would turn the supposed direction that this stage is supposed to give into project railroading. I really don't get why, after such a successful project we are trying to change something fundamental in the way we do things. While, as I have said already, the general philosophy behind this is something that I have always thought was good and in fact used in my own mind when making posts for many past projects, this worked well because we were allowed to debate everything out at each individual stage where it was supposed to be debated.

Overall, I think what we have to keep in mind is that the single most useful thing that this "build triangle" provides is balance for our Pokemon, not direction. A good concept assessment provides better direction than a build ever could. I do admit that good concept assessment is not an easy thing to get, but we should not be looking to just throw this in as a required step when it is not always needed (and, as I said last post, could be harmful to the debate quality down the road), and when the way people are suggesting it be used is not even to use it in its most optimal way (direction rather than balance).

Personally, I think what would be good to do would be to make this a stage either after concept assessment or before stats (though the latter might be redundant with stat limits, which is another reason I don't love this as a step in general) with wording similar to that for the current Counters Discussion: somthing to the effect of "The build discussion stage is non-mandatory. It can be invoked by either the TL or the forum moderators based on their interpretation of the concept assessment stage and how the project has proceeded since." Basically, the goal here is to make it so the such a stage can exist at an appropriate point, IF NEEDED, but is not stuck in there forcing things on us if we are able to get a solid concept assessment without it.
 

DetroitLolcat

Maize and Blue Badge Set 2014-2017
is a Forum Moderator Alumnusis a CAP Contributor Alumnus
I would like to echo what jas61292 posted. I am in the majority when it comes to Build Triangles being a solid concept; limiting ourselves in one of power, speed, and bulk is a good idea and we should definitely try to limit ourselves in at least one of those characteristics when designing a Pokemon. I would also get behind an optional "Build Discussion" at TL discretion. Other than that, I am against implementing a mandatory Build Discussion, especially at any stage in the process other than directly after the Concept Assessment.

The foremost issue with Build Discussions I have is that it is a solution looking for a problem. CAP5 had an excellent Concept Assessment, and I believe reflecting on CAP5's excellent Concept Assessment and learning what jas61292 did to foster discussion and draw constructive (but not overbearing) conclusions. Instead of improving Concept Assessment with a large-scale change such as Build Discussion, we should just look at examples of Concept Assessments that have improved future discussion as a whole and Concept Assessments that have failed to do so.

Obviously, this topic is tied to Concept Assessment. I would like you all to consider the risks and rewards of implementing a Build Discussion and deciding not to. If we implement the Build Discussion, we run the risk of letting the Topic Leader railroad the discussion by dictating the degree of bulk, power, and speed the CAP will have before we even start discussing Typing. The upside to Build Discussion is that we get a degree of specificity that will be perfectly suited to our concept...something that we have already accomplished with CAP5's Concept Assessment. Meanwhile, the potential downsides to a poor Concept Assessment are arguably smaller than those of a failed Build Discussion. We have had Concept Assessments go badly in the past, yet CAPs do not fail because of a poor Concept Assessment. You can point to CAP4, but the lack of conclusions in the Concept Assessment was not what forced the wheels off the cart during that project. The point I'm promoting in this post is that Concept Assessments, as they're currently managed, possess the same upside and less of a downside than Build Discussions. As jas put it,
jas61292 said:
Overall, I think what we have to keep in mind is that the single most useful thing that this "build triangle" provides is balance for our Pokemon, not direction.
We accomplish this goal by adopting Doug's Proposal 1. Any other capacities in which we implement the Build Discussion add direction to the project that is not needed.

If CAP6 and or any future CAP fails in large part due to an inconclusive Concept Assessment, then I will adjust my position on this issue. However, I do not see this as a probable scenario given the past few Concept Assessments. I believe we can be reactive rather than proactive concerning this issue given the history of Concept Assessments (at worst Concept Assessments have been useless, at best they have all but guaranteed successful discussion in the future).

Disclaimer: the above paragraphs assume that Build Discussion will occur either following or in place of Concept Assessment.

Now, I will explain why I do not believe Build Discussion should proceed or replace Stat Spread Discussion. First and , the terms of Build Discussion as outlined in the OP is supposed to include Typing, Abilities, Stats, and Moves. If Build Discussion is reduced to only include Stats and Moves, it would extremely railroad the process because we would have implemented a build and have only two steps to fulfill it. For example, if our CAP had a typing that was not conducive to priority attacks and Abilities that are not related to the Speed stat and the Build Discussion determined a Fast build then we would have already decided much of the next two steps.

You can understand my analogy; I fear that a Build Discussion any time after Concept Assessment means that we won't have enough balance before the Build Discussion and too much direction afterwards.

CAP 5's (and CAP as a whole) somewhat unpredictable discussions and balance between structure and chaos make the project enjoyable and the most recent project one of the most enjoyable projects in CAP history. I hesitate to implement radical changes such as the implementation of a mandatory Build Discussion or replacing the Stat Spread Discussion. If the Stat Spread discussion needs to be amended or replaced, I advocate for that being done in a separate PR thread.
 

DougJustDoug

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 Smogon Discord Contributor Alumnusis a Top Tiering Contributor Alumnusis an Administrator Alumnus
Moderator
Conclusion:

We will implement Proposal 1:

Proposal 1: We will not make CAP pokemon with an end result Build that has everything. Through the course of the project we will strive to adhere to the principle of "Fast, Powerful, Bulky: Pick two."

We all generally agree that a good-but-not-overpowered OU pokemon should not have a perfect Build. CAP pokemon should be intentionally limited in at least one of the Build aspects, as described in the OP. Throughout the CAP project we can use the Build Triangle and the six discreet Builds described in the OP as a yardstick to discuss our progress, and to evaluate various options in each step. The TL/TLT can use the policy of Build limitation as justification for making certain decisions where they deem it appropriate. We formally establish this as a desirable end goal for our CAP pokemon, and introduce the concepts and terms related to the Build Triangle as part of the language of competitive CAP discussions.

We will look into writing an article describing the Build Triangle, and perhaps link it into the OP's of the formative steps of the CAP project (Concept and Concept Assessment for sure, but maybe others) to help inform the community of this new general policy.

We will not implement Proposal 2 as a requirement. If the TL deems it necessary, they may introduce a selection step for the community to explicitly identify a Build, at a time to be determined by the TL.
 

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

Top