In the past, the mechanical ethos was to assign a class a number of reserves based on their class die. A baseline amount of per-day healing from reserves was built off of that; classes with more reserves than the baseline (i.e. d10 and d12 classes) would need to have abilities with a reserve cost (that hopefully "made sense" thematically) built into them. These costs were effectively reverse-engineered onto the abilities, in order to fit the class die. With the "two-dice" ethos, what we can do is instead work from the assumption that the number of reserves will be scaled down to the die that most easily aligns with the baseline, and only scale it up if it makes sense thematically for the class to have a "reserve-burning" mechanic. What this means is that only classes with a d10/d10, d10/d12, or d12/d12 loadout will necessarily have to have 10 or more reserves.
The other direction to take, which might make also sense, would be to streamline reserve calculations a little bit, wherever possible. To wit, it could make it easier to outright remove the d4 expression, or at least roll it up with the d8 expression. I think the same could probably be done for d6 and d12; the previous number-crunching on the subject seems to suggest that the sweet spot is about 6-8 reserves per day (and above that, you have to start adding extra mechanics to burn reserves on.) Rather than having to pump d12 classes up with such mechanics, we could simply have d12 and d6 use the same math.
That would leave us with something like this:
- d4 or d8 -- 8 reserves, 4-20 HP restored per = 32-160 HP
- d6 or d12 -- 6 reserves, 12-20 HP restored per = 72-120 HP
- d10 -- 10 reserves, 10-20 HP restored per = 100-200 HP
Admittedly, this looks a little screwy. The d4/d8 and d6/d12 expressions (in terms of per-day healing) "average" out the same, but I can't help but feeling there's more that should be done, to smooth out the variance. Perhaps the way to do approach it, is to have the smaller die always used for the number of reserves, while the larger die is used for the "surge value." This would be a bit of a logistical... well, maybe not "nightmare" but at least a "headache" -- it also doesn't do anything to resolve the issue, with regards to single-die classes.
(It's also probably worth mentioning, that each class having two dice can potentially allow for the separation of HP calculation from Reserve calculation; a class or subclass may use the HP calculation from one of their dice, but the Reserve calcucation from their other die, for example.)
What I think this all would ultimately prescribe, is making the d10 into the de-facto "reserve burning" class die, in order to bring their "daily HP" pool more in line with the other expressions. We might still be able to boost reserves to 12 (for classes that have d12 as one of their dice) if they are a class that we want to have reserve-burning as part of their shtick. This could also be used as for "specs" such as the proposed Psionic or Runepriest mechanics, for example; in such a case, it probably makes sense for those archetypes to boost your character's reserves to 12 (or "reserve calcualtion to d12" if we want to be somewhat pedantic.)
Conclusions
I guess what I would take away from all of this would be:
- HP calculations probably won't change; it will still be "maximum value of [d20 + class die]" but for two-dice classes, the exact die will have to be specified, and/or may be different depending on subclass.
- Reserve calculation will effectively default to the lower of the two class dice, with d4 being the exception. This means either d4 will necessarily get 8 reserves, or there will be some other sort of blended calculation that both d4 and d8 will use.
- If the smallest die a class has is d10 or d12, then that should be a class with a rational justification for having a reserve-burning mechanic.
- Archetypes/Domains that call for the addition of a reserve-burning mechanic to a character will likely necessitate the character's reserve calculation being boosted to the d10 or d12 calculation.
One other thing (I didn't talk about it above, but should still be mentioned in this conclusion) is the idea of using reserves as a benchmark or modifier. What exactly I mean by this is that, if we're able to hypothetically narrow the number of "maximum" reserves down to a range of 6-10, this should make it more effective to use "current reserves" as a number by which class mechanics can function. The first example that popped into mind would be as a limitation to the number of creatures that could be summoned by a particular ability, or to the number of summoned creatures that could be under your control at any given time. Admittedly the latter would be far more punishing as the adventuring day went on, and no doubt there could be other mechanics that might leverage this more effectively.
This (admittedly) is sort of a roundabout way of getting to the design mechanic of "ability modifiers" into a game where everything is supposed to be designed off of the dice. But looking over some of the mechanics, I can see where the utility of a hard, flat number would be desirable -- and since reserves are still a function of class dice, it fits into the existing ethos, albeit in a roundabout way. At this point, it's just a question of whether or not a modifier that degrades over the course of an adventuring day is a mechanic with wide enough application to really be useful.
Side note:
In going back through some old literature for TNP, I had originally intended that spending a reserve would always heal you to your maximum HP. However, what actually got implemented was the "surge value" system -- which, in combat, can produce "overhealing" as sort of a way of replicating the design space of "temporary HP" (mentioned in this post here.) I think going forward, the assumption will use a blend of these systems: if you're in combat, or at 0 HP (i.e. "under duress") then spending a reserve to regain HP will require a roll; otherwise, spending 1 reserve will restore your HP to its maximum.
...
Next scheduled blogging day will be Friday, June 5th -- so check back then!
No comments:
Post a Comment