I can't find a resource for understanding at a high level how to approach a collectible card game or deckbuilder where each card may have its own ruleset, effects and exceptions. I'd rather approach it correctly from the start rather than discover it's not scalable enough in the future. How should I think about each card?

xicus said:
how to approach

Approach meaning code structure layout? Do you program or just randomly looking into doing this?

I've been programming about a year, so don't have broad experience with engineering. Currently I'm imagining a state machine for turns/phases, a messenger singleton all the cards can communicate through, and maybe a bunch of modular ‘abilities’ I can assign to each card, but I'm not confident I'm on the right track, or what all I'm overlooking.

It is a game design project first: implementation as software or on paper (or probably both) requires having some definite ideas of what your game will be like, of what you need and what you don't need.

If you are more interested in programming than in game design, collaborate with someone else (ideally expert players of multiple card games, who should know what they are doing) or implement an existing, mature game or a close variant of it.

Currently I'm imagining a state machine for turns/phases, a messenger singleton all the cards can communicate through, and maybe a bunch of modular ‘abilities’ I can assign to each card, but I'm not confident I'm on the right track

You are not confident because these concerns are premature: your game design is too vague to decide what techniques are a good fit for unknown requirements.

For example, are “cards” represented as entities that can really “communicate” with one another, or do they interact indirectly and more informally by creating and altering other elements of the game state with specific elementary actions in their scripts? How mutable are the “modular” abilities of cards, and how complex their interactions and state changes?

Seconding LorenzoGatti's vote to paper prototype again and again and again. Paper is cheap, easy, and fast. Make sure the game is fun first and foremost.

For implementation, I'd spend some time browsing through various CCG engines that already exist before starting your own. TCG Engine and Card Game Core both immediately spring to mind, and I know there are more.

As for features, many games form a database of features along with numbers. Basically any number of entries in the form of {cost}:{ability}. A card may have multiple entries. Costs often take variables, abilities often take variables.

Implementing abilities then becomes a matter of processing each ability one at a time. Attempt to match cost #17 variable 1; if cost is met, play ability #24 with variable 3. Attempt to match cost #4 variable 3B; if cost is met play ability #32 with variable 8,4,2,1. As you add abilities to the possible features to card you'll implement ability #33, then ability #34, then ability #35, expanding and building and growing until you've got all the features in the game. CCGs tend to introduce new abilities all the time, so three months later you'll add another five abilities in the next expansion. Creating new cards is then as simple as adding a new row to the database; card ID, card name, type ID, cost, ability string, power, toughness, artwork ID, whatever else you need.

But implementing the abilities in code is expensive and time consuming, and tuning is slow. Far better to do it all on paper first, where you can write one or two words and refine them with the other humans you playtest the ideas with until you've made sure the idea is fun.

@frob thanks for the actionable tips!