[Dev]: Handling MTG Cards

[djpiper28]

Squire Lib is used by many projects, including Squire Desktop, at current it stores a formatted deck list and, cards from MTGJson in memory.

The issue is the repeating of data and, having to store a large JSON file.

Solution 1:

• Squire lib only stores oracle ids for cards, so a deck will consist of something such as this:

{
  "name": ..., /*name and, deck info*/
  [
    {
      "oracle-id": ...,
      "quantity": 1,
      "sideboard": false
    }, ...
  ]
}

• Squire core, desktop and, other dependents will then have to store:
  • A map of oracle ids -> card objects
  • A set of indexes for searching (squire desktop most notably)

To recap

• The squire library would load the map of oracle id -> card objects at launch
• The squire library dependent (desktop or, core) will store cards and, anything similar.
• The data can be stored in a minimal json state for squire lib i.e:

{
  [
    {
      "oracle-id": ...,
      "card": {...}
    }
  ]
}

[TylerBloom]

Minor corrections: SqurieLib is agnostic to how a client is storing data for cards. SL just takes a Deck (defined here). At present, SB is using an AtomicsCollection (see here), which it derives from all the atomic cards mtgjson has.

That said, the deck representation used should be more minimal. I would estimate 90+% of the data an AtomicCard stores isn't used by SL (or SC).

As for client-side card collections, I like the idea of SC being able to distribute this. I've made Rust data structures that would allow us to map oracle ids and card names to cards with any duplicate data (see GroupMap). I'm not sure if that's what we are looking for, though. It still makes the card name lookups inflexible.

[djpiper28]

How do we want to handle card translations? Should it be an option for cards to be in language X? if so then we would need the large mtgjson file in full. thankfully it can be gzipped

[TylerBloom]

The SC server can maintain a complete version. The foreign data in the atomic cards has a language field. We could make the minimal card collection request have an optional language field that we use to select a translation. We could easily cache each language when first requested and clear the cache when new json is loaded.

All of this would be handled by SC. If a client needed a different representation, we can supply the full data set too or they can construct their own.