Multi-sided cards #746

distributive · 2023-01-12T16:49:06Z

This is a WIP attempt to formalise double-faced cards (e.g. Hoshiko) and cards with functional variants (e.g. Jinteki Biotech).

My approach has been to give cards and printings an optional "sides" field (working name) that defines a series of objects representing a subset of fields of their parent. This allows the sides to only redefine properties that are different, while leaving the rest implicitly the same:

{
  {
    "title": "Card Name",
    "text": "Flip this card to see side 2.",
    "sides": [
      {
        "text": "Flip this card to see side 1."
      }
    ]
}

The downside of this is it's a bit asymmetric and can't always accurately represent what the flip side/other variants represent.

For instance, each copy of Matryoshka has its own flavour text, but none of them (printing order aside) takes precedence over the others, even though this implementation requires that. Also, while flip cards are trivial to understand (one side is always the initial side) Jinteki Biotech is actually three double-sided cards, represented here as 4 objects (the parent card and its three sides).

Applying this system to the Terminal Directive Campaign cards has similar issues, and rewriting the validation tests is going to be a real hassle.

An alternative system might be to represent the sides as separate cards/printings and have them reference each other in some way (this is effectively how it was implemented for TDC). This makes them easier to search for and avoid some of the above issues, but we'd need a way to coalesce cards/printings that represent the same card.

…le variants

NoahTheDuke · 2023-01-12T17:50:23Z

Scryfall splits multiface cards into different "faces" that are referenced in a card_faces array on the base card object, and has a "layout" attribute that arranges the different faces. If a given card is "normal", then instead of card_faces, the single face info is merged into the base object.

I don't think magic has cards like Biotech where the same base card has multiple different flipped sides, but I don't think that fundamentally invalidates the model.

Think that would work for nrdb?

NoahTheDuke · 2023-01-12T18:15:48Z

Examples from Scryfall/Magic the Gathering (make sure to click through to "Copy-pasteable JSON"):

Here's the full list: Scryfall layouts

distributive · 2023-01-12T20:18:47Z

Magic is weird.

distributive · 2023-01-12T20:20:50Z

That's handy though. It looks like they do it broadly like I've done. Does Magic have an equivalent to Jinteki Biotech or a TDC card like Machilocation (A and B)

Edit: I suppose the split cards are like Machilocation.
Edit 2: I completely missed your first comment mb

NoahTheDuke · 2023-01-12T23:16:46Z

No worries. Glad I could help.

NoahTheDuke · 2023-01-12T23:30:49Z

Something to be explicit about, I think Scryfall's faces are not just properties that are different from the base card. I think they're intended to be "full" information that is merged into the base card object.

From my reading of the json, the double face cards don't have a base "text" property, each face has that. I think the first face entry in the array is considered the "upright" or "front", depending on the style, but that is less meaningful with the split cards (which we don't have to worry about).

I don't want to saddle you with a bunch of work lol, so please ignore any and all advice I give if you think it's too much work.

That said, I think it might be smart to determine a set of card data that can or could change depending on face, maybe treating each like a printing? And then put the full info into the face entries.

Having individual card entries for each side would complicate our data model, but would allow us to accurately handle biotech and matrioshka and sync (which I think has the same name on both sides).

lol This is a classic case of edge case poisoning. So annoying.

NoahTheDuke · 2023-02-12T15:31:15Z

Your layouts have nice names. 👍

distributive · 2023-02-12T15:39:12Z

The MtG system makes this so much easier to work with. I think it lets us deal with all the flip cards, the campaign cards, and Biotech trivially.

Matryoshka on the other hand...

distributive · 2023-02-12T15:44:32Z

The problem with Matryoshka is as far as the card is concerned it's a regular card, but the printing itself has multiple versions.

I don't want the card object to know it has differing flavour text, but shoehorning the layout system onto printings feels weird to me.

distributive · 2023-02-12T17:37:33Z

v2/layout.json

+    "id": "flip",
+    "description": "A card with a front and back side.",
+    "name": "Flip"


e.g. Hoshiko

distributive · 2023-02-12T17:38:09Z

v2/layout.json

+    "id": "copy",
+    "description": "A card that is made up of multiple distinct cards with the same name.",
+    "name": "Copy"


e.g. Machilocation and other campaign cards, and possible Matryoshka

distributive · 2023-02-12T17:38:45Z

v2/layout.json

+    "id": "facade",
+    "description": "A card that is made up of multiple cards with the same front face, but distinct flip sides.",
+    "name": "Facade"


Only Biotech

distributive · 2023-02-12T17:39:32Z

v2/layout.json

+    "id": "progression",
+    "description": "A card with iterations on its values.",
+    "name": "Progression"


e.g. Evidence Collection and other campaign cards with the sticker mechanic

…ity' attribute

… ignoring tdc)

…a property of cards

… quantity attribute

plural

First, thank you for tackling this!

A few thoughts.

TD Campaign cards: I'm not sure we should care about them. They aren't now and don't plan on being legal in any formats, they are mostly here as a historical record. Should we do anything to them at all? I'd give some thought to not doing anything with them.
V1 cards. I would also consider doing the minimal change here to keep existing NRDB useful and treating V1/V2 differences for just these cards in the test files. I am certainly not against changing V1, but not losing info in the current system is probably useful. That being said, this is a mild take. :)

I have one open design question for you, but this is overall great!

schema/v2/cards_schema.json

test/validate_v2.ts

plural · 2023-02-22T03:14:45Z

v2/printings/parhelion.json

-    "quantity": 6
+    "quantity": 6,
+    "layout_id": "copy",
+    "copy_quantity": 1,


how about dropping this field out here, but keeping "quantity" in the sides? You can still sum the quantities up for the test, but move all instances of the field into sides where they vary, rather than treating one differently.

wdyt?

We are going to need to do some formatting shenanigans for these cards either way.

Technically the base printing is also a copy. I know it's sort of weird to have 6 equal cards have one arbitrarily denoted to dominant version, but see my comment below.

plural · 2023-02-22T03:16:59Z

test/validate_v1_v2_equality.ts

      expect(c[v1Field], `${v2Field} mismatch for ${code}`).to.equal(printingsById.get(code)[v2Field]);
    });
  }

+  function checkTdc(v1: any, code: string): boolean {


you have this function defined twice, but with different signatures. Which do you need?

They're in separate blocks:

describe('Card Sets v1/v2', () => {

describe('Printings v1/v2 equality', () => {

v2/cards/bmi_buffer.json

v2/cards/jinteki_biotech_life_imagined.json

NoahTheDuke · 2023-02-22T05:40:24Z

Idk how much weight my voice has, but I think y'all should support the campaign cards. They don't require much to track and they're interesting and mildly relevant. I'm a maximalist in this respect.

distributive · 2023-02-22T09:14:27Z

I'd prefer to keep the campaign cards in as well, at least in part because the work for it is now done and "we might as well". One of the layout types (progression) becomes unused without the set.

I also think despite NSG not having anything to do with the cards, we can't assume nobody wants that data.

distributive · 2023-02-22T09:20:07Z

I think the only changed I made to v1 were in the flavor text and Biotech, which I just changed to make the validation convenient.

If you want I can change the standard for flavour back to "\nFlip side:\n" (although I'd still like to make the ft on Matryoshka a bit more aesthetic).

Biotech we can just ignore if we really want, but I made the change since there's no way to validate the existing text without hardcoding something.

…rds (if both have the property)

plural

there is also still one warning for 'code' being an unused parameter as well.

test/validate_v2.ts

distributive · 2023-05-16T07:23:26Z

As per our last meeting the plan is to accept the schema for this will be a bit janky and put an issue up to eventually revisit this. If someone can have another spool through this and confirm it looks good I'll merge it.

Separated the differences in cards/printings with two sides or multip…

83ff918

…le variants

Formalised abnormal card layouts

e2b0211

distributive commented Feb 12, 2023

View reviewed changes

distributive added 9 commits February 21, 2023 11:01

Updated card id

eef9232

Updated to new system for multi-sided cards and added new 'copy_quant…

674dfdb

…ity' attribute

Updated v1 side-dependent data to match the new schema

b9b3938

Removed extra side

b533f05

Add missing formatting

c680151

Updated positions of the condensed tdc cards

fabdcd6

Updated schema to accept the new flip/copy/etc type cards (largely by…

97ce2d2

… ignoring tdc)

Added schema validation for layouts and updated name to specify it's …

3d933f4

…a property of cards

Added test to ensure copy_quantity attributes sum to their associated…

272e9eb

… quantity attribute

plural reviewed Feb 22, 2023

View reviewed changes

distributive added 2 commits February 22, 2023 09:42

Removed unused const

132890d

Added test to ensure layout_id is consistent between printings and ca…

b228d4f

…rds (if both have the property)

plural requested changes Feb 23, 2023

View reviewed changes

test/validate_v2.ts Outdated Show resolved Hide resolved

distributive and others added 3 commits February 24, 2023 00:16

Removed unused variables

834fa46

Renamed normal layout to be more descriptive ('single_sided')

29d9be2

Merge branch 'NetrunnerDB:main' into main

7d724c6

distributive force-pushed the main branch from f7f0c39 to 7d724c6 Compare March 24, 2023 14:44

distributive mentioned this pull request May 16, 2023

Flip card support NetrunnerDB/netrunnerdb-api-server#174

Open

distributive marked this pull request as ready for review May 16, 2023 07:21

distributive requested review from plural and NoahTheDuke May 16, 2023 07:22

plural approved these changes May 20, 2023

View reviewed changes

distributive merged commit 810859d into NetrunnerDB:main May 20, 2023

This was referenced May 20, 2023

Clean up the multi-sided card schema #758

Open

Expose multi-sided card/printing data NetrunnerDB/netrunnerdb-api-server#177

Closed

distributive mentioned this pull request Jun 22, 2023

Expose multi-sided card/printing data NetrunnerDB/netrunnerdb-api-server#185

Draft

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Multi-sided cards #746

Multi-sided cards #746

distributive commented Jan 12, 2023 •

edited

Loading

NoahTheDuke commented Jan 12, 2023 •

edited

Loading

NoahTheDuke commented Jan 12, 2023

distributive commented Jan 12, 2023

distributive commented Jan 12, 2023 •

edited

Loading

NoahTheDuke commented Jan 12, 2023

NoahTheDuke commented Jan 12, 2023

NoahTheDuke commented Feb 12, 2023

distributive commented Feb 12, 2023

distributive commented Feb 12, 2023

distributive Feb 12, 2023

distributive Feb 12, 2023 •

edited

Loading

distributive Feb 12, 2023

distributive Feb 12, 2023

plural left a comment

plural Feb 22, 2023

distributive Feb 22, 2023 •

edited

Loading

plural Feb 22, 2023

distributive Feb 22, 2023

NoahTheDuke commented Feb 22, 2023

distributive commented Feb 22, 2023

distributive commented Feb 22, 2023 •

edited

Loading

plural left a comment

distributive commented May 16, 2023

Multi-sided cards #746

Multi-sided cards #746

Conversation

distributive commented Jan 12, 2023 • edited Loading

NoahTheDuke commented Jan 12, 2023 • edited Loading

NoahTheDuke commented Jan 12, 2023

distributive commented Jan 12, 2023

distributive commented Jan 12, 2023 • edited Loading

NoahTheDuke commented Jan 12, 2023

NoahTheDuke commented Jan 12, 2023

NoahTheDuke commented Feb 12, 2023

distributive commented Feb 12, 2023

distributive commented Feb 12, 2023

distributive Feb 12, 2023

Choose a reason for hiding this comment

distributive Feb 12, 2023 • edited Loading

Choose a reason for hiding this comment

distributive Feb 12, 2023

Choose a reason for hiding this comment

distributive Feb 12, 2023

Choose a reason for hiding this comment

plural left a comment

Choose a reason for hiding this comment

plural Feb 22, 2023

Choose a reason for hiding this comment

distributive Feb 22, 2023 • edited Loading

Choose a reason for hiding this comment

plural Feb 22, 2023

Choose a reason for hiding this comment

distributive Feb 22, 2023

Choose a reason for hiding this comment

NoahTheDuke commented Feb 22, 2023

distributive commented Feb 22, 2023

distributive commented Feb 22, 2023 • edited Loading

plural left a comment

Choose a reason for hiding this comment

distributive commented May 16, 2023

distributive commented Jan 12, 2023 •

edited

Loading

NoahTheDuke commented Jan 12, 2023 •

edited

Loading

distributive commented Jan 12, 2023 •

edited

Loading

distributive Feb 12, 2023 •

edited

Loading

distributive Feb 22, 2023 •

edited

Loading

distributive commented Feb 22, 2023 •

edited

Loading