Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop treating card names as unique identifiers in Atomic Cards (v6) #1004

Open
KingSupernova31 opened this issue Jan 7, 2023 · 12 comments
Open
Labels

Comments

@KingSupernova31
Copy link

KingSupernova31 commented Jan 7, 2023

At this point, it looks like Wizards has completely abandoned the idea of card names as a unique identifier of all the card data. We have things like:

  • Alternate names on the godzilla cards.
  • Unquenchable Fury being both a regular card and a completely different card from the Theros challenge.
  • Smelt // Herd // Saw.
  • Different versions of Very Cryptic Command.
  • Different versions of Tamiyo's Journal.
  • Arena cards with power level tweaks from their paper version.

I expect this problem to get worse in the future as Wizards releases more variants. As such, I think it no longer makes sense to treat the card name as the canonical way to reference a specific card object. For example, AtomicCards has a single entry for Unquenchable Fury, and its sub-entries are two completely unrelated cards. There's no conceptual reason they should be paired together.

I think v6 should move from storing the data as an object to storing it as an array, no longer treating a card's name as any different from its other characteristics.

@ZeldaZach
Copy link
Member

AtomicCards is a gross file/setup imo, and I only kept it around from v4 for legacy reasons. I'd rather folks generate these sub-components from the AllPrintings file and build up their own formatting. I'm open to suggestions on improvements, but storing as an array loses the O(1) access folks might have enjoyed with the file setup.

@ZeldaZach ZeldaZach added the v6 label Jan 8, 2023
@KingSupernova31
Copy link
Author

I already create my own formatting from AtomicCards, but doing it from AllPrintings is more of a pain, since it's a much larger file and things in it tend to break more frequently, and if AtomicCards is removed I'd have to redo all the work that MTGJSON has already done in condensing it down to the relevant information.

What fraction of downloads are for AtomicCards vs AllPrintings? Most applications that I'd expect to want this sort of data (decklist builders, etc.) won't care much about expansion, so I think it makes sense to keep that around as a simple way for people to get the data they need.

(After all, it's possible for people to just get their data directly from Scryfall, but they don't, because MTGJSON is easier to work with. Convenience is the primary offering.)

@jsimpson523
Copy link

I use AtomicCards for my application, where I just need 'oracle' information about a card and the set doesn't matter.

My primary motivation for this is that I don't want to have to choose which of the many eg Sylvan Libraries to pull the data about all Sylvan Libraries and risk picking the wrong one. AllPrintings feels very WET and AtomicCards feels more like the single source of information I'm looking for in a data source for an app.

If I were to make a suggestion for v6, mine would be to put the card at 'top' level where set currently sits, and let each card have a set object with the set codes as the keys with the value being an object containing the set-specific qualities of that card.

I would much rather do the extra work required to generate a set-of-cards by digging into that 'sets' object looking for my selection criteria, and then appending the set-specific card stuff inside it to the set-agnostic stuff outside it, if it meant that I had that top-level, set-agnostic info (the stuff that would be in AtomicCards) only written once.

I guess what I am saying is that, even though v5 was out when I started building it, I chose AtomicCards as my data-source because I am concerned about each printing of a card having its own text attribute and having to trust them to all be the same and work around them if/when they are not.

@KingSupernova31
Copy link
Author

KingSupernova31 commented Jan 8, 2023

Oh, and in fact MTGJSON is already breaking from card names as printed on the cards. The files include a card named "A-Armory Veteran", despite its actual name being "Armory Veteran". (The Arena version.) This is inconsistent with how MTGJSON handles other name collisions, such as with Unquenchable Fury. Whatever solution is decided on, it shouldn't be treating different types of name collisions inconsistently.

@KingSupernova31
Copy link
Author

Wait, it's not just its key in AtomicCards that had an "A-" appended to it, its also its actual name property. That's just incorrect. I've opened a separate issue about that. #1005.

@ZeldaZach
Copy link
Member

Thanks for your insight @jsimpson523 ! Really appreciate community feedback to help drive the project.

You have an interesting proposal for an alternative file, which is something we can look into supporting with v5, if there's enough demand.

@KingSupernova31 brings up a good point about how Arena Alchemy cards and Unquenchable Fury are handled differently, and it's something we will take into consideration if further fixes are warranted

@jsimpson523
Copy link

I disagree that 'A-Armory Veteran' is an unreasonable name for that object. That is how the name appears on the card, and is how the object is named upstream at Scryfall, as seen here...

@KingSupernova31
Copy link
Author

@jsimpson523 Um, no it isn't? I just followed your Scryfall link and there is no "A-" in the title. You can use control f to confirm this yourself.

I also just checked on Arena and it's the same story there.

This discussion should probably move to #1005 though.

@KingSupernova31
Copy link
Author

Oh, another one: Attraction cards can have different numbers lit up despite having the same name.

@ZeldaZach
Copy link
Member

Oh, another one: Attraction cards can have different numbers lit up despite having the same name.

Attraction lights aren't assigned to AtomicCards due to this reason. The AtomicCards only gets printing-to-printing consistencies

@KingSupernova31
Copy link
Author

Why are the Very Cryptic Command variants included then? They're effectively the same thing (cards with the same name but different gameplay-relevant attributes), so they should be handled the same way.

@mallardduck
Copy link
Contributor

Um, no it isn't? I just followed your Scryfall link and there is no "A-" in the title.

I know it's been a few months - so maybe the context of time has changed things.
Yet there is for sure the iconized A in the name/title, which can be interpreted into "A-" prefix.

Card name from scryfall

I would say we can reason that this isn't a new component of the card, nor is it a distinct feature from the name. While it is an Icon/emoji/symbol rather than a latin character it's part of the name. We know it is part of the name proper because how the card uses the name itself in the description.
A Icon in name used in textbox

IMHO, with this card - and other Arena/Alchemy variants - it is an instance of the same name, but not the same card. If the effects, stats, or abilities of the card are different it's better they be listed as a different card entity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants