i'm in the midst of expanding asset ability annotations. it's not live yet, but the WIP (in YAML) is here: https://github.com/rsek/dataforged/blob/main/_master-data/Starforged/Assets.yaml
couple notes:
- currently, these are more structured than may be advisable in the long term, but i decided the best way to get a feel for what's really important in asset abilities was to start annotating and see what the pain points were.
- my focus isn't on exposing the numeric values for calculation, but instead the content/triggers of the asset ability. i reckon stuff like "moves A, B, and C are altered with X on outcome Y" or "move A offers a reroll of die B on outcome C" are the most useful information when deciding what shortcuts to present to the user.
- that said... there's an awful lot of things that are really close to being numbers already, particularly where "Add +X" and "Take X momentum" strings are concerned 🤔
Alternatives
a more sustainable/extensible (and less structured) approach might be some kind of tag system. each asset ability could include an array of keywords describing rules elements it references. for example, an ability with the following text:
When you Set a Course, choose one.
- Follow the fastest path: Take +2 momentum on a strong hit.
- Follow the safest path: Add +1
On a strong hit with a match, you charted a new path during the journey; mark 1 tick on your discoveries legacy track.
... might have the following keyword array:
["take +X momentum", "add +X", "mark discoveries legacy"]
these keywords would all have documented meanings, and then developers could decide what to do with them. for example, "take +X momentum" might mean including a shortcut for the user to increment momentum.
annotating this by hand wouldn't be any faster than what i'm currently doing... but short, uncomplicated phrases like these are pretty easy to regex for, so i could conceivably just extract them from asset text when i build dataforged's JSON.
couple things that occur to me about this approach
- i'm not sure to what degree this would overlap with trigger data; programmatically extracting nice self-contained trigger phrases is tricky
- the best way to test whether it would work would be for me to code something to do it, so i'm not sure it'll save me any labour in the short term ;) long term it could pay off, though
- is there hybrid approaches that might be fruitful?
- if i build a dataforged-compatible asset builder, would it be possible to build these keywords/structures into that?