AI card game generator: the rules engine is the game
Everything hard about a card game is the rules engine: what happens when three effects trigger at once, and in what order. That is the part Stage Engine writes for you.
The ordering problem
A card game with twenty cards is easy. A card game with two hundred is a system, and the difficulty is not the cards. It is what happens when a card that triggers on death meets a card that prevents death meets a card that copies triggers.
Every card game that has ever shipped has an ordering rulebook underneath it for exactly this reason, and writing that rulebook in code is the part where card game projects stall. It is not creative work. It is a stack machine with priority rules.
Director 1 writes it in GDScript inside your project. You describe the resolution rules you want and get something you can play against, which is the only way to discover that your rules produce an infinite loop.
What generation actually means here
Two different things, and it is worth separating them. Generating the systems — the engine, the turn structure, the targeting, the animations that make a play readable — is the reliable one, because those are specified problems.
Generating card content is the other one, and it is more limited than it sounds. A model will happily produce two hundred card names and effects, and most of them will be variations on the same three ideas at slightly different numbers. Card design is a taste problem, and a set that nobody chose feels like it.
A more useful use is as a sparring partner. You have the idea; you want thirty variants of the cost curve to look at and reject twenty-eight of.
Balance comes from playing
No tool can tell you a card is too strong. It can tell you a card wins more often in simulated play, which is useful, and it cannot tell you that the card is boring, which matters more.
So you play. You notice that one combination ends games on turn four and is not fun for either side. You change the cost, you play again. Being non-technical has nothing to do with your ability to notice that, and the tool is built on the assumption that the judgement is yours.
Simulation has a second use that is easy to miss: it finds crashes. A thousand automated games will hit combinations you never would, and most of what it surfaces early is not balance at all but rules that were never fully specified.
It does not have to look like a spreadsheet
Because Stage Engine sits on Godot and runs locally, a card game here can have a table, a room, an opponent who reacts, weather outside the window. Card games are unusually well served by presentation and unusually often built as flat UI because that is all the tool allowed.
You build the space by hand in the builder, the same as any other project. Whether that is a 2D layout or a 3D table is your call.
Presentation also carries information. Where a card sits, how long a trigger takes to resolve, whether a played card leaves a trace — these are how a player learns the rules without reading them. In a physical game the table does this work; in software you have to build it deliberately.
Practical facts
Stage Engine is a desktop app for Mac and Windows with Godot bundled inside it. The game runs locally when you press play. There is no browser version.
Free to download with a free plan; Indie $10 a month, Pro $50, buying more usage rather than a different engine. Building needs an internet connection; playing what you built does not.
The debugging tools worth asking for early
Card games have an unusual testing problem: the bugs live in interactions, and interactions grow quadratically. Two hundred cards is twenty thousand pairs, and you are not playing twenty thousand games.
The lever is tooling. Ask for a way to set up an arbitrary board state instantly, so reproducing a strange interaction is ten seconds rather than a twenty minute game. Ask for a log of every trigger in resolution order, so when something resolves wrongly you can see where. Ask for a mode that plays a thousand random games and reports crashes.
These are unexciting and they are the difference between a card game you can develop and one that becomes unmanageable at about card ninety. They are also cheap to ask for, which is the whole argument for having the code written rather than writing it.
Nobody builds these first when they are writing the engine themselves, because they are not the fun part. Here they cost a sentence each.
Questions
- Will it generate my whole card set?
- It can produce candidates, but a set nobody chose plays like one. The useful version is generating options you reject most of.
- Can it handle complicated trigger ordering?
- That is exactly the kind of thing Director 1 writes well, because it is a specified problem with a fiddly implementation.
- Can I play against an AI opponent?
- An opponent is code in your project. How good it is depends on the rules you ask for rather than on anything hosted.
- Is it 2D or 3D?
- Either. The game runs on Godot locally, so a 3D table with real lighting is as reasonable as a flat layout.
- Pricing?
- Free plan, Indie $10 a month, Pro $50.
- Can I import cards from a spreadsheet?
- Data loading is code, so ask for the format you already keep your cards in. Most designers have a spreadsheet and there is no reason to abandon it.