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:
Here's a quote from Wikipedia explaining the concept:
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:
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:
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:
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:
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.
"Good, Fast, Cheap: Pick two."
Here's a quote from Wikipedia explaining the concept:
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.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 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
Bulky
Powerful
- 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.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)
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: