AI deckbuilder maker: synergies you can only find by playing

The pleasure of a deckbuilder is discovering that two cards you picked for different reasons combine into something absurd. As the designer you cannot plan those. You put cards in, you run twenty runs, and you notice.

That means the value of the tool is almost entirely how fast it gets you from an idea to a playable run. A month of programming before the first run is a month you spend designing blind.

Director 1 writes the run structure, the card engine, the reward screens and the encounter logic as GDScript inside your project. You are playing runs in the first session, which is when the actual design work starts.

A run map with branching paths and node types. A draw, discard and exhaust pile that behave correctly at the edges. Energy or whatever resource you use. Relics or permanent modifiers that change how other cards behave. Rewards after a fight, with rarity. A run that can be abandoned and resumed.

All of that is standard structure with a lot of fiddly detail, and the detail is where projects die. What happens when you draw from an empty deck mid-effect. What happens to a buff when the card that granted it is exhausted. Ask precisely and get it right the first time.

Ask for the debug conveniences at the same time. Starting a run with a chosen deck, skipping to a specific floor, and forcing a particular reward are all trivial to add early and painful to live without once you are testing the same fight for the fortieth time.

Some of balance can be measured. Ask for run statistics, or for a way to simulate a thousand runs with a fixed strategy, and you will find the card that wins too often. That is a real use of code and it is worth asking for early.

The rest is taste. A card can be statistically fine and still make every run feel the same, and that is a worse problem. Only playing tells you. Being non-technical does not affect your ability to notice that a run got boring — that is the judgement the whole loop is built around.

Deckbuilders are usually 2D because the tools that make them are 2D. Stage Engine runs on Godot locally, so the encounter can happen in a place: a room, a corridor, a clearing with weather, with the cards over the top.

Whether that is right for your game is a taste question and both answers are legitimate. The point is that the tool is not making the choice for you.

Whatever you choose, the encounter needs to be readable at a glance. A deckbuilder asks the player to hold a lot in their head, and every second spent working out what is on the board is a second not spent on the decision. Presentation here is a mechanic rather than decoration.

A desktop app for Mac and Windows with Godot bundled inside. Free to download, free plan, Indie $10 a month, Pro $50 — more usage rather than a different engine.

Building needs an internet connection because Director 1 and asset generation come over the network. Playing what you built does not.

A deckbuilder needs a lot of cards to feel alive, and this is the part people underestimate. Not because writing a card is hard, but because every card has to interact correctly with every other one, and the interactions are where the bugs and the balance problems live.

That is an argument for building the engine to be generous early. If adding a card is a five minute job and adding a new kind of effect is a sentence, you can afford a hundred and fifty cards. If each one is an hour of programming, you will ship forty and the game will feel thin.

So the thing worth asking for first is not cards. It is a card system flexible enough that the card you think of in month three does not require rewriting anything.

That is a design conversation you can have in plain language, and it is worth having before you have written a hundred cards against a structure that cannot hold them.