While it is the case for the existing official Skills, Skill implementations shouldn't be required to conform to a strain based approach.
There are other valid approaches to calculating skill difficulty that can be supported by abstracting the strain logic into its own StrainSkill class.
Samuel Cattini-Schultz
·
2021-04-03 20:52:39 +11:00
As strains are an implementation detail of the current Skill calculations, it makes sense that strain related logic should be encapsulated within the Skill class.
Samuel Cattini-Schultz
·
2021-04-03 20:47:43 +11:00
There is no reason we should be limiting skills to knowing only the previous 2 objects. This originally existed as an angle implementation detail of the original pp+ codebase which made its way here, but didn't get used in the same way.
Samuel Cattini-Schultz
·
2021-04-03 20:28:51 +11:00