AI card game maker: from an idea on paper to something you can play

Card game designers usually start on paper, and paper is a good medium for it. You can shuffle index cards, play a hand, and know within an hour whether the core is interesting.

Then the project needs to become software, and that is a different discipline entirely. Shuffling, state, a hand you cannot see the opponent's version of, animations that make a play legible, an undo that does not corrupt the board. That is where the paper prototype sits in a drawer for two years.

Stage Engine is a way through that. You describe the rules and Director 1 writes them as GDScript in your project. You get back a thing you can click, and the design work carries on rather than stopping.

You say what the card does in the words a rulebook would use. When this enters play, look at the top three cards of your deck, put one in your hand and the rest at the bottom. That is unambiguous, and unambiguous is all a code-writing layer needs.

Then you play with it. Usually you discover the card is fine and the interaction with another card is broken, which is the actual work of card design and is not something anyone can do for you.

The loop of describing, playing and revising is the normal way to work here. Handing it back with "this is too strong when combined with the other one" is expected, not a failure.

A card game feels good because of small things: the weight of a card landing, a slight delay before a trigger resolves, the way the board tells you whose turn it is without a label. These are all code, and all cheap to ask for once the engine exists.

Because Stage Engine sits on Godot and runs locally on your machine, you are not limited to flat UI. A table in a lit room, an opponent sitting across from you, a window with weather behind them — all reasonable. Card games are often flat because the tool made them flat.

Readability is the other thing worth spending on early. If a player cannot tell what just happened, they cannot learn the game, and card games are almost entirely about learning the game. A short pause before a trigger resolves does more for comprehension than any tooltip.

Card art can be generated, sourced, or drawn by you. Plain typographic cards are also a genuine style, and an excellent placeholder while the rules are still moving. The tool will tell you which route it took rather than blurring it.

What it will not do is decide whether your game is fun. You play it, ideally with someone else, and you find out.

Sound is worth a line too. Card games get an unusual amount out of very little audio: a shuffle, a deal, a distinct note for a trigger firing. It is a small ask and it changes how finished the game feels more than most visual work does.

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

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

Even once the game is software, paper stays useful. Testing a rules change with index cards takes minutes and testing it in software takes a build. For big structural questions — should there be a resource at all, should hands be public — paper is still faster.

The sensible split is that paper answers the structural questions and software answers the ones about volume and feel. Whether two hundred cards hold together, whether an animation makes a play readable, whether the game is pleasant over twenty games rather than two.

The software version also lets other people play it without you sitting there explaining the rules, which is where you find out what your rules actually say rather than what you meant.

That test is uncomfortable and it is the most valuable one available. Watching someone misunderstand your card is worth more than any amount of your own play.