Content Packs and Filters

What are Content Packs

When you're making a deck-builder one thing you'll quickly find yourself dealing with is the sheer number of cards, and how many of those will need to be grouped up in various ways. Color, rarity, type, energy cost, or any number of criteria. When developing a game with potentially hundreds if not thousands of cards, maintaining a list of say all attack cards becomes an impossible task riddled with endless bugs. It's also not very mod friendly, as if someone wants to add a new card to the game they have to figure out how to update those lists.

So instead of that, it's much easier to simply have the game itself figure these things out on runtime through reusable queries. This is where content packs shine.

How do they work

The same work flow is used for all content packs (Cards, Artifacts, and Consumables), but cards will be used.

1. First a Card Pack is made (see. These are usually defined via validators, though options for color and prototype object ids are provided standard. The game will then run through every card in the game for each pack, and create and run it through a CardFilter. CardFilters are objects which take an initial set of cards and actually apply those filters, storing the resulting card lists inside themselves.
2. Afterwards the pack is cached, locking the filter from further mutation and storing the result in Global for reuse. It's also cached under the same object_id as the card pack, making it easy to find.
3. The game can then use card packs to either query cards in a CardPick action, or be assigned to a player's draft options.

Some features worth mentioning:

• Cards can be assigned a card_appears_in_card_packs = false to ensure that even if a card may meet certain criteria, it won't appear naturally in a card pack's query. This is good for cards that you don't want naturally draftable or are only used in very specific contexts.