See the card variants section of the card database conventions for an explanation on how card variants currently work.

Issues

1. Some card variants inherently have two or more types

Take the Yellow A Alternate and Pokémon League card variant types for example. They can both exist separately, but also together. The current solution is to simply create a new card variant type by combining their names together using the , character, e.g., Yellow A Alternate, Pokémon League.

2. The card variant type doesn’t include all descriptive properties in its name

Additionally, it could also be the case that the Pokémon League card variant features a certain holographic pattern, which ideally should also be included. Taking the Yellow A Alternate, Pokémon League example, this would make the total number of card variant types three.

3. There’s no proper way to visually describe “conceptual” card variants

The best example here is the Normal (standard set) card variant type. It doesn’t describe what holographic pattern it has or what kind of stamp it features. Because only one type can be assigned to a card variant, there’s no way of knowing what conceptual card variants really look like.

Technically it’s possible to combine multiple card variant types to make it more descriptive, e.g., Normal, Cosmos Holo, but this should only be done if there also is a conflicting non-holographic card variant, because it would inevitably cause the name to become very long and hard to read.

4. Combining multiple card variant types as a single separate type makes filtering on a single type impossible

5. All variants of a card share the same image (and text)

Possible solutions

• Allow multiple types per card variant.
• Add a new name property to card variants instead of directly using the card variant type names. This way, filtering on certain types is possible without the name becoming too long.

To be thought more deeply about…