Some insights/opinions

[Larikk]

Koder asked me to check this repo out and provide a second opinion.

Disclaimer: I have no idea what the motivation, vision or long term plans for this project are so some of my points may be invalid.

General

Try to version your database schema so that you can do breaking changes without messing stuff for consumers up. Some random (probably flawed) idea :

• Create a branch called "v1". Make it very clear that consumers are supposed to use that one and not main or whatever.
• Keep the data of v1 updated.
• When you want to make a breaking change to the schema: Branch of v1 to v2. Make your breaking changes.
• Keep v2 updated and dont touch v1. v1 will become stale but at least it wont break anything.

Alternatively add a note that there is no guarantee for stability and to do automatic pulls on the users own risk.

You should also check out YGOPRODECKs API. Some aspects of it can be improved but I'm sure it can also be an inspiration.

Format

It's a bit odd that card data, ocg lists and tcg lists all have different structures. The lists should have the same format/structure at least so that the same code can be used to consume them.

For the lflists I would just provide a cards passcode with its legality. Additional information (like card type and name) can be fetched from the database.

I think json would be a better choice here instead of yaml. While human-writeability of yaml is better, the readability of both is pretty much the same imo. Plus, json parsers are more ubiquitous and even part of some languages standard library and they generally have a better parsing speed which is relevant for such huge datasets. (Disclaimer: I have a huge dislike against yaml.)

Card data

monster_type_line is cool for when you want to output it without having to manually format it (which can be a pain with the correct ordering I assume.) But it would be cool for searching/filtering features if the type would be an additional/separate field and extra properties an array of tags (like "Fusion", "Ritual", "Normal", "Effect", "Toon", "Flip", "Spirit" etc). If you decide to go with the array-of-tags route do the tags explicitly; While on a real card a Spirit tag implies that its an Effect monster, the database should still say that it is a Spirit and Effect monster. That makes searching easier since if you search for effect monsters you do not need to manually include Spirits, Toons, Flips etc.

In addition to the official password I would add an array with unofficial ids that are sorted ascendingly. This array should not include the official password imo. Thats YGOPRO specific but Bastion already lists those rn so I assume you are not against it.

Do not use unicode symbols in the database for the link markers. Just write them out (like "Left", "Top", "Bottom-Right") and make it the responsibility of the consumer to map them to whichever represantion they want.

Avoid mixing types; That will make the life of devs using languages like Java or C# hard. I noticed that this happens with cards that have "?" stats.

For cards with "?" I would use 0 as the stat and add a boolean which indicates that they have that stat as "?". It's a good compromise between not breaking arithmetic operations and giving the consumer a way to display "?" stats properly.

Release dates would be a super useful feature. Adding them to "sets" would be nice and an extra field for the initial tcg release would be super useful for people playing alt and retro formats. There are a couple issues though:

• They are not synchronized for different regions. Just taking the lowest one found would in theory be an option but the Portuguese or Brazilians made this impossible since they released some products weeks(!) in advance and that date would be annoying for the majority of the users. Another option would be to make that information NA TCG centric. Retro and alt formats usually revolve around NAs TCG releases so that would be not an issue imo (I'm not an American btw)
• Some products do not have a concrete release date. Like SJ promos. Yugipedia and Konami list no release dates for them. If you got them a couple days before the start of the month in which the SJ magazine debuted you were allowed to use them. For those cases it is alright to just use the first day of a month as the release date imo and I'm sure most people would agree.

Older versions of names (like Kinetic Soldier) would be cool but that may be hard to get depending on the data sources.

[kevinlul]

As of about two weeks ago, OCG, TCG, and Rush Duel limit regulations are now automatically updated, and the most recent list available is provided in the .vector.json format, a mapping of Konami ID to the number allowed. See https://github.com/DawnbrandBots/yaml-yugi/issues/8#issuecomment-1616748451 for next steps.