Open Freedzio opened 4 years ago
I like this, but I think it would be nice if the choice property was nested under some kind of feature_specific
attribute.
This would just keep the Feature model organised a bit more as we go through and add structures like this to all features. Rather than giving each different kind of feature (of which there are many) a different structure, we would be giving all features the same structure, where one of the attributes has an arbitrary shape (within reason).
{
...
"feature_specific": {
"subclass_option": { Choice<subclass> }
}
}
Hmmm
Maybe put subclass giving features in feature_choices
prop in data from classes/${class)/levels/${level}
endpoint? This way, IMO there is even more consistency
Example:
data from level
endpoint
...
"feature_choices": {
"index": "otherwordly-patron",
"name": "Otherwordly patron",
"url": "endpoint-to-that-feature"
}
and then in the feature itself, the structure you proposed
I dislike that, personally. The SRD doesn't read as allowing the character to choose between multiple features; it grants one feature that allows a choice of subclass.
If you allow a choice of subclass in feature_choices
, then you're introducing an inconsistency where otherwise all the choices would be for features.
When you put it that way, ye, my propositon would stir some disinformation. feature_specific
approach is cleaner. It indicates that this feature has some logic/complexity behind it and allows the api cosnumer to deal with it the way it needs to. Just like class_specific
data
As I work on my app, I am having more and more ideas.
Given there will be feature_specific
prop, how about putting there data about bonuses? For example, in Fighitng style: archery
...
feature_specific: {
bonus: {
type: "damage"
amount: 2
for: ["ranged"]
}
}
or something among those lines. To make features more computer friendly
Yeah, this is exactly what I meant when I was talking about how the feature_specific
property would help keep things organised as we expand on all the features in this way.
Just like the title says. There are feautres, where you choose something form an array of opitons, be it expertise, eldritch invocation or fighting style. Why not treat subclasses the same way?
Proposed structure:
I know there is only one subclass in the SRD, but as y'all mentioned before, if something comes from a feature, you like to keep it within that feature, so why not add information about subclass choices to the feature giving you a subclass?