Newsletter - Learn Card Architecture Series
I just finished a three-part series I have been working on for the past few weeks. It started as a single article about card game design tools, but the deeper I went, the more there was to say. The result is the Card Architecture series: three articles that trace the full arc from the scripting trenches of 2006 to the AI-native card generation systems of 2026.
Part 1: Three Waves of Card Game Design Tools
The history of how card game design went from pixel-coordinate scripting (nanDECK, Squib) through visual editors (Component.Studio, Dextrous) to AI-native pipelines that understand your game. I am a software architect by profession, and when I first looked at how card games get made, I recognized the pain immediately: hundreds of interdependent data fields living in fragile spreadsheets, manual rendering pipelines where a three-pixel change means recompiling an entire deck.
If you have ever wondered why prototyping a card game still feels like it is stuck in 2010, this is the history of why, and where it is going.
Part 2: How AI Actually Designs a Card
I spent a month in 2021 reverse-engineering Race for the Galaxy, parsing Keldon Jones's C source code and mapping every card power across 114 unique cards. Five years later, when I started building a system that generates card games, I realized the pipeline I needed was a mirror of what I had already done by hand. This article goes inside the multi-agent pipeline: the Theme Weaver, the Mechanics Architect, the Component Designer, and how each one mirrors a stage of human card design.
The question is not whether AI can design cards. It is which parts of card design are mechanistic, which parts are not, and what that means for the human designer's role.
Part 3: Card Grammar — Teaching Machines the Rules of Complex Card Games
This is the one that surprised me most. We took 13 of the most influential card games ever published and stress-tested them against the pipeline's five-field card schema. Dominion mapped perfectly. Sushi Go worked trivially. Then Wingspan shattered the box, Terraforming Mars overwhelmed it, and KeyForge broke it entirely. The results sorted into four coverage tiers, from perfect fit to total structural mismatch, and the solution required not better algorithms but a fundamentally different way of thinking about what a card actually is.
The concept we landed on, Card Grammar, gives each game its own structured definition of what fields exist on its cards, when those fields trigger, and how cards are allowed to talk to each other. Three layers: anatomy (what a card is made of), triggers (when things happen), and costs (what you pay and what it means).
The Thread
The three articles are designed to be read in order. Part 1 gives you the landscape and the history. Part 2 shows you what works. Part 3 shows you where it breaks, and what we built to fix it. But each one also stands alone if you want to jump straight to the part that interests you.
Try GameGrammar
If you want to see these ideas in action, GameGrammar is live and free to try. You can generate a card game from a concept, import your own existing design, run automated balance testing against different player archetypes, and iterate with Nova, the conversational co-design partner.