Apologies for the lateness of this post; I will try and cram 3 posts into the month of August, so check for updates on the 21st and 30th, most likely.
To make a long story short, production has not gone along as far as I would have hoped. In largest part, this is due to the protracted unseasonably warm weather, making it difficult for me to sit down and focus on writing for any length of time. Mostly my at-home time since the start fo July consisted of either laying down with a fan pointed directly at me, or soaking in a tub full of cool water. Add to that some computer troubles, and I wasn't able to get much done over the break; what I did get started on, came pretty early into it -- I'll go over that now.
Archetypes & Domains (aka subtypes)
Part of the process of allocating the various subtypes to all of the classes, was to take the conceptual idea and actually spell out what that meant.
Specifically, it's something like this:
1) Class (and subclass) determine your possible power sources
2) Class Category determines your possible subtypes (either archetypes or domains)
Alright, so most classes get 3 or 4 options for power sources (this might be whittled down by subclass, but we'll set that aside for now.) For the sake of argument, let's assume class category only ever allows for one of the subtypes and not both. In practical terms, this means that every class will have between 6 and 8 possible "builds" -- not including differentiation based on subclass.
To make a long story short, there's just too much going on; particularly so, given the idea that each subtype is meant to function across roughly half a dozen classes. I spent some time working on the Paladin class in particular, and I found that even after adding previously-unplanned restrictions, there ended up being 8 different subtype options per subclass. Also, it became clear that domains would probably have to be tailored to each class, meaning the utility of recycling them would be lost entirely.
So probably what's going to happen, going forward, is one or more of the following:
a) Subtypes will be shelved, at least until classes can be ironed out, possibly longer.
b) Subtypes will be scaled back in number, by some method.
c) Subtypes will be dictated strictly by class, making it easier to (for ex.) have one archetype/domain from a particular power source, but not the other, on any given class.
Part of any restructuring might be a shift away from using certain Archetypes across multiple classes. The example that immediately springs to mind is the Adventurer subclasses (Scout, Skald) being reused as archetypes, for other classes. At first glance, it seems like it'd be alright, because Adventurer would also get subtype options on top of that... but it just seems to dilute the big picture. If we go with option a) as mentioned above, then we can focus more on ironing out Scout and Skald in the context of just one class, which I think will produce better overall results.
Class Dice in the New Ethos
One of the first things that needed to be tackled, was cementing the ways in which class dice would function, regarding some of the basic character math.
Acknowledging that balancing out the different dice against one another inevitably means that there can't be a "one size fits all" rule for most of these mechanics, what I set out to do instead was to have each class die essentially function as a "code" for these features. Reserves and Surge Value represent one linked pair of mechanics based on class dice, with HP and Engagment being another pair.
(For those unfamiliar, the necessity of a limit on Engagement sprouted out of playtesting; tanking was a little too easy if you could use the Engage move to simply corral all of the open enemies. So class dice were used as a cap on this action -- thus, tankier classes tend to have bigger class dice.)
From there, I've basically come up with 5 different expressions; each class will use one expression for Reserves and Surge Value, and one for HP and Engagement:
1d4
- Max HP: 24
- Engagement: 4
- Reserves: 8
- Surge Value: 4
1d6
- Max HP: 26
- Engagement: 6
- Reserves: 6
- Surge Value: 12
1d8 or 2d4
- Max HP: 28
- Engagement: 8
- Reserves: 8
- Surge Value: 8
1d10
- Max HP: 30
- Engagement: 10
- Reserves: 10
- Surge Value: 10
1d12 or 2d6
- Max HP: 32
- Engagement: 12
- Reserves: 12
- Surge Value: 12
So what does this amount to, in practical terms? Well, it allows us more flexibility in class design. One example would be the Rogue, with Assassin and Sorcerer subclasses; even though Rogue only has d6 as its class dice, the Assassin might use 1d6 for Reserves, and the Sorcerer might use 2d6 (to facilitate them having a reserve-burning mechanic) while both would likely use 1d6 for their HP and Engagement. Likewise, a class using d4 (like the Sage, for instance) can have one subclass (Wizard) that is more of a back-line role, and so would use 1d4 for Engagement, with the other subclass (Monk) being more melee-focused, granting it the 2d4 expression for its calculations. We can also do things like use d6 classes to be tanky, instead of having that role almost entirely lean on d10 or d12 classes.
There's even more possible customization, when it comes to classes that use two class dice. For example, the Cleric (d4/d10) might have a reserve-burning mechanic on its ranged subclass (utilizing the d10) while its melee subclass could be designed to use either the 2d4 or 1d10 expression, for HP and Engagement.
The other benefit to having most classes use two dice, is it gives us the option to lower the number of reserves for classes that would otherwise have 10 or 12 by default -- without us having to staple on reserve-burning mechanics, just for the sake of it. In addition, revising the mechanics such that spending a reserve simply restores your HP to its maximum (under most circumstances) de-emphasizes the importance of surge value, with regards to number of reserves per day. With these two ideas in concert, we're better able to flatten the amount of daily "reserve" HP that each class will have, while still having class dice form these mathematical foundations of these mechanics.
---.
I mentioned it in the TNP Discord, but one topic of discussion was the possibility of removing attack rolls from the designs; this will likely be touched on in a post sometime this month, so stay tuned for that.
No comments:
Post a Comment