json-against-humanity
json-against-humanity copied to clipboard
Custom Deck Support
Adding a CLI argument to include custom decks is a change I really want to include.
node update-from-sheets.js --add custom.csv
There's a discussion below about supporting custom black cards without counting underscores.
How about adding another character (e.g. ~
) that indicate to pick a card, that is removed in the treatCards
function?
https://github.com/crhallberg/json-against-humanity/blob/master/compile.py#L35-L40
I'm happy to submit a PR if you agree with the approach.
An alternative would be to use a special comment at the beginning or end of the line for this,
e.g. <!--- {"pick":3} --->
I like the special comment idea... maybe just check if a line of the file is a JSON object or not so it can be:
Boring CAH card.
That meme from high school.
{ "text": "Make a Haiku.", "pick": 3 }
Cats. The Movie?
Can do, but then the individual files are not really markdown anymore. If we stick to comments at the end of the line, we could do:
Boring CAH card.
That meme from high school.
Make a Haiku. <!--- {"pick":3} --->
Cats. The Movie?
To be fair, comments aren't really markdown either but many processors (including GitHub flavored markdown) allow them.
@crhallberg please advise :)
The haiku issue is resolved with v2 (see cah-all-compact.json). Renaming this issue to move the conversation to custom deck support.
To continue the conversation, would it be a good choice to support CSV? Blank third column counts underscores? Maybe with a metadata JSON?
type | text | pick |
---|---|---|
white | I'm a white card | |
black | I'm a prompt card | 3 |
black | A _ and _ sandwich | 2 |
black | What did I dream about last night? |
As a heads up, we are consuming JSON Against Humanity data as a part of Massive Decks, and have a repository of custom decks people make in Many Decks.
Our format has some features that wouldn't be supported by an ingestion format like that, and while I can understand if you just don't want to support them, I figure I'll give them here for context:
- Slot (the underscore in a black card) transforms (e.g: UpperCase so the white card text is made upper case when played into the slot).
- Repeated slots, where the same white card is used multiple times in the black card.
You can see example of this in this issue.
As I say, I get if these are just out of scope for the format, but if they were supported it would be cool to use the same ingestion format for Many Decks' import functionality.
(As a side note: it might be nice to try and do some integration if you were open to it, e.g: the ability to submit decks built in Many Decks to JaH directly, or at least the ability to export to this format to make it easier).
Hey, @Lattyware! Lots to think about! While I imagined the custom deck support being a local compilation, your use case is definitely one to strongly consider. I looked through your links and recommendations and I had a couple of ideas:
- There is an opportunity for custom data on custom cards for sure. So call cards might look something like:
{
"text": "_?! I **HATE** _!!",
"pick": 1,
"slots": [
{ "index": 0, "transform": "UpperCase" },
{ "index": 0 },
]
}
- There is a branch where I supported the AllBadCards format, so this is also an angle we could support.