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
Comments
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. |
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.) |
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 |
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. |
Wait, it's not just its key in AtomicCards that had an "A-" appended to it, its also its actual |
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 |
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... |
@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. |
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 |
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. |
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:
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.
The text was updated successfully, but these errors were encountered: