Archetype Swapping Concerns
Contents |
Background
Note that the basics for Replacing Archetype Controls is available
Challenge
Class Archetypes: in some instances a Class Feature is not replaced, but a portion of the feature is negated in order to gain another new feature.
Example
Rogue gains Sneak Attack (Class Feature), which has level dependent gains.
Every odd level, the rogue gains an additional +1d6 to the Sneak Attack Damage.
Broken down:
1 = 1d6 3 = 2d6 5 = 3d6
However, we encounter this:
1 = 1d6 3 = New Class Feature 5 = 2d6
This section is not well understood how it relates to the example
We need to manage several things:
- When a new bonus is applied (We cannot remove/negate a bonus until the correct level is reached)
- We cannot grant new features until the minimum level has been reached
- And in odd cases, when features are granted, there can be level dependent bonuses on those as well...
Principles & Discussion
I've articulated a number of different principles that will come into play here. These include, but are not limited to:
- Be direct. Don't set a variable to go do something somewhere else, rather, directly set the variable needed
- Keep things as aligned as possible to how the rule construct actually works.
This example is useful, because it clarifies what I mean by "direct", in that it is still the owning object making the modification, but that being super-literal about being direct being the actual *result* can have bad implications.
As a note, in the Example provided above, we should go back to how the rule is actually designed.
I believe in this case it's something like "At level 1, you are granted 1d6 Sneak Attack Damage". At Level 3 it's "An additional 1d6".
There are 2 possible interpretations of what to do at level 3:
- Think in Set Dice: Set the total directly to 2d6
- Add a Die: Add 1 additional die to the running total
Unfortunately, I'm not sure I understand all of the listed things that need to be managed (since I'm not sure they are all handled in the example, and generalizations about things I don't understand are dangerous... :) )... so it's probable that other examples need to be provided so that additional implementations can be provided.
Potential Solutions
Note: This presumes you are familiar with how items would be replaced, since it will work in a similar fashion to other Archetype replacements. This is only dealing with the incremental dice and how it would be managed to have a "middle one" replaced.
Thinking in Set Dice
One solution is to think fully in set values of dice:
In VARIABLE file:
LOCAL:CLASS|DICE=SneakAttack
On some class feature:
DoAtLevel3 <> MODIFY:SneakAttack|SET|2d6|PRIORITY=400
I think this has a critical flaw:
- If there needs to be an interrupt (as in the example above), then this will fail (or there will need to be some variable passing around what did or didn't happen earlier). In general, while this is "brute force" correct, it fails to have any flexibility and thus can't meet the requirements.
I happen to think this also fails to follow the principle summarized as "do directly what the book says". While direct, this is direct to the *result*, not to the *operation specified by the book* (the operation being add 1d6)
Adding a Die
One solution is to think in modifying dice:
In VARIABLE file:
LOCAL:CLASS|DICE=SneakAttack
DoAtLevel3 <> MODIFY:SneakAttack|ADDDIE|1|PRIORITY=300
Some considerations:
- This solves the issue in the first example, in that missing a class feature at a given level will not cause the total to be incorrect.
- This is flexible to different sizes of dice, so if for some reason there is a method of increasing the die size of Sneak Attack, then this will still succeed.
Other Commentary
Why doesn't Dice support ADD?
Based on the literal rules of adding 1d6, you might ask why you can't do this:
DoAtLevel3 <> MODIFY:SneakAttack|ADD|1d6|PRIORITY=300
If ADD was supported for DICE, this would solve the issue in the first example, in that missing a class feature at a given level will not cause the total to be incorrect.
However, this introduces a major problem.
Remember that the DICE format is equal to:
XdY+Z
If we allow ADD, we end up with a problem. What if we SET it to 1d8 and then try to add 1d6? We now have two different values for Y, so it can't be processed with the format DICE.
So wait, what about my sword damage?!?
I need 1d8+1d6(fire). How do I get that?
The answer is the damage on a sword will be FORMAT of ARRAY[DICE].