Low-priority.

Issue:

• Due of limitations on how patching can be done (requires a static patch method, thus static field variables), it makes sense that only one instance any type of rule exists (multiple instances will only operate on the same static fields).
• However, this limitation means that even rules without patching requirements (e.g., OnPatch()) are limited to a single instance per class.

There are several reasons for why it would be beneficial to have multiple instances per rule type:

1. Increased granularity. Instead of a single large PieceConfig rule, can have multiple PieceConfig rules (e.g., 1 per piece type).'
2. As a result of more granular (although still generic) rules, printing rule descriptions can incorporate value changes rather than just generic descriptions.

Proposal:
Splitting rules into static and non-static would look like the following:

• Rules with patch requirements (e..g, Onpatch()) would be one rule sub type, and those without would be another sub type.

"printing rule descriptions can incorporate value changes rather than just generic descriptions." - I was wondering if there was a way to parameterise these descriptions using the values being passed to generate the description text dynamically.

"PieceConfig(s) Adjusted: Sorcerer StartHealth +5, Guardian ActionPoints +1, WolfCompanion AttackDamage +3" etc

Python classes have an init function which is great for this kind of thing, but I lack the necessary C# skills to know if the same can be achieved here.

"printing rule descriptions can incorporate value changes rather than just generic descriptions." - I was wondering if there was a way to parameterise these descriptions using the values being passed to generate the description text dynamically.

For sure! The non-parameterized nature of the descriptions were mostly a function of not knowing exactly how the descriptions would be used (e.g., for printing on screen, or only used to describe the rule to users rule pre-initialization, etc.).

👍🏾