Plural vs. Non Plural for sub types

[superpowered]

Hello, Thanks for the API. Super useful.

Sub types for resources & disorders are plural unlike other sub_types in the API. And then in other spots like abilities_and_impairments & fighting arts, the type is plural but the sub type is not.

Would probably be helpful to make these all either plural or non plural to make it a bit more predictable.

[toconnell]

@superpowered Hey! Thanks for opening this.

Reading it, I think I understand what you're saying (and it reminds me of specifying the plurals in Django, for example, so that things look right in the admin panel, which I totally get), but I kind of wonder what your use case would be for the KDM API.

And, since that sounds kind of bitchy, let me give you a five minute history of the attribute just to let you know how we've been using it here and in the other webapps.

Long story short, sub_type started its life as a way to differentiate A&Is: some of them were "ability" type, some were "impairment" type, then others were "curse" type.

But the initial point was that they were a reference to the actual asset, right? So among all A&Is, if you're looking at the "Crystal Skin" A&I, its sub_type says that it's an ability, if you're looking at "Destroyed Genitals", its tagged as an impairment, etc.

We got used to doing things that way--i.e. sort of using it as a tag for the asset--and so now, most of the assets the API knows about have the attribute and that's how it works.

Additionally, assets we never thought to create it for default back to the name of the module they come from.

ANYWAY, that's how they ended up being what they are.

So what are you envisioning? A sort of meta/admin helper? Or something used to facilitate some kind of UI design?

Thanks again!

[superpowered]

It's basically just a simple app that lets you search and filter for cards by deck. Eventually the goal would be to make something that shuffles and serves cards per deck. It has a looong way to go, as I really only originally built it as a quick thing for a job interview. It definitely needs some server side caching and such before I really get into any of the real features.

https://kdm-shuffler.herokuapp.com/

As far as I could tell, for a lot of the decks the only real identifier I had for them was the sub_type. Which is totally fine -- But I found myself in a lot of scenarios where I would write a filter or something similar and then go "Oh, crud, that's right! it's fighting_art not fighting_arts"

            card_type_filters:
            [
                'disorders',
                'fighting_art', //singular
                'secret_fighting_art', //singular
                'basic_resources',
                'strange_resources',
                'monster_resources',
                'vermin'
            ],

I haven't really included gear or anything in the list yet, as those don't get shuffled, but I could see this same logic applying there as well. "sub_type": "weapon_crafter" -> "sub_type": "weapon_crafter_gear"

Obviously any changes would likely constitute a major release, as changing keys can break functionality. I'm considering doing a PR for some of the AI decks, and that could help give a real reason for a v3. But I'm also probably vastly underestimating the time it would take to do that data entry.

[toconnell]

Well, @superpowered, what about a totally new attribute called deck or something that tags cards with a unique handle or string for their deck?

Maybe not something human readable, but something that could be used to distinguish things by their content/release cohort?

So like, say it's something generic, like the Basic Resources 'Hide' resource card, the attrib is like, 'deck': 'core_basic_resources' and for something more exotic, like the 'Lantern Mehndi' from the Lion God expansion, it would be like, 'deck': 'lion_god_rare_gear'?

Would that help, or is that too specific (or not specific enough)?

[superpowered]

@toconnell I definitely think something like that could work.

Although for basic resources I think just "deck": "basic_resources" would be fine. The expansion should probably only exist in the expansion attribute since some decks share expansions, like disorders and fighting arts.

Furthermore this would make it easier to later add something to the expansion endpoint, showing what decks it affects. Maybe a decks_added or decks_extended attribute

[toconnell]

@superpowered Yeah, I think I'm picking up what you're putting down.

So if you hit the /game_asset/resource route, each resource (whether Basic or Strange), comes back with a sub_type that is its deck:

"love_juice": {
  "selector_text": "Love Juice"
   "handle": "love_juice",
  "name": "Love Juice",
  "rules": [],
  "type_pretty": "Resources",
  "keywords": ["organ", "consumable"],
  "desc": "",
  "type": "resources",
  "sub_type": "basic_resources",
  "sub_type_pretty": "Basic Resources"
}, 

...and for Strange Resources:

"1000_year_sunspot": {
  "selector_text": "1,000 Year Sunspot (Sunstalker)",
  "handle": "1000_year_sunspot",
  "name": "1,000 Year Sunspot",
  "rules": [],
  "expansion": "sunstalker",
  "type_pretty": "Resources",
  "keywords": ["bone", "organ"],
  "sub_type_pretty": "Strange Resources",
  "type": "resources",
  "sub_type": "strange_resources",
  "desc": "When you craft with this, nominate a survivor. They suffer the <b>blind</b> severe injury from working with this resource."
},

Disorders has a sub_type of 'core_disorders', which is problematic. And Fighting Arts are, as you pointed out, totally out of whack.

What I think I could do in the next release of the API is start exposing those assets with a new deck attribute that has values such as the ones we've been talking about, e.g. 'fighting_arts', 'basic_resources', 'disorders', 'resources', 'strange_resources', etc.

From there, I think that could get you moving on your project and then...I guess hit me up on this ticket if you run into any issues?

Sounds fair?