Card game maker: the rules engine is the hard part

Anyone can describe a card: costs two, deals three damage. The difficulty starts when two cards interact. One card says "whenever a creature dies, draw". Another says "destroy all creatures". Now you need an order, a queue, and a decision about whether the draws happen before or after the second effect resolves.

Multiply that by a hundred cards and you have a rules engine, which is a real piece of software with a real design behind it. This is why so many card game projects stall: the cards are fun to write and the resolution system is a month of careful work.

It is also why the genre suits this arrangement well. The month of careful work is code, and the fun part is design, and those go to different halves.

You write the cards in plain language, the way you would explain them to a person at a table. Flockbay writes the GDScript that implements them inside your project: the cost system, the play validation, the effect queue, the triggers, the priority order when things collide.

When two cards interact badly, you find out by playing, which is the only reliable way. You say what happened and what you expected. It gets fixed. Then you find the next one. That is card game development and it does not go away, but it stops requiring you to debug a script.

The same applies to the surrounding systems: deck construction, shuffling that is actually random, a discard and exile zone, mulligans, a turn structure with phases, and an opponent that plays reasonably rather than randomly.

A new project in Flockbay opens on one question, shown as two pictures: 2D or 3D. There is no default and nothing gets made until you answer. For a card game you pick 2D, and the builder stops offering you terrain, water and weather — none of which a card table has ever needed.

What a flat project gives you instead is the part a card game does need. You place a picture, or a scene from your own project, at an exact position, turn and size, by hand with the mouse: card faces, the board they sit on, the felt, the counters, the discard pile in the corner. Most of that can be furnished before you draw anything, because the Catalogue is 55,073 sprites out of 60,648 objects — 90.8% — searchable by name with a picture of each one before you take it.

A new 2D project also arrives running: a sky colour, a band of scenery, ground with a ledge in it and a person who walks and jumps. For a card game that is not your game and most of it comes back out. What it buys you is that the project answers from the first second, so a change to a layout is a change you look at rather than a change you queue up behind six other missing pieces.

The 3D case has not gone anywhere, and it is where a card game does something a card-specific toolkit cannot. A deckbuilder attached to a map you move across. A card battler where the fight happens in a real arena. A roguelike where the run happens in a world and the combat happens in cards. Pick 3D at creation and the same chat writes the same rules engine into a real Godot project you own.

More on this: A strategy game maker, and an honest note about the genre

Card games live on feel. The weight of the draw, the arc of a card leaving your hand, the pause before the opponent responds, how legible the board is at a glance. Those are movement and timing, which is to say they are code: you say the draw is too quick and Flockbay changes the numbers that move the sprite.

Drawn frames are the different thing, and worth knowing before you plan around them. There is no animation editor here and nothing that produces a multi-frame sprite, so a card that is meant to burst into flame needs those frames from somewhere else. Card art comes from generation — Flockbay will make a single flat image on request — from the Catalogue, from your own files, or from an artist you work with. Importing what you already have is a normal path, not a workaround.

The game runs locally on the copy of Godot bundled with the app, so animation timing is your machine's rather than a server's. Building needs an internet connection; playing does not.

Digital cards can do things physical cards cannot, and that is where a digital card game earns its existence. Hidden state that resolves later, effects that track history, costs that change based on what has already been played. Ask for those early rather than building a paper game on a screen.

More on this: Godot puzzle templates: three of the four are card games

Card games are balanced by playing them, repeatedly, against people who are trying to break them. There is no substitute and no tool changes that.

What a tool can change is the cost of each iteration. Changing a card should be a sentence and a restart, not an afternoon. That is what having the rules engine written for you actually buys: you get to change your mind about a card forty times in a week.

Build in the boring conveniences early. A quick restart, a way to force a specific opening hand, a way to jump to turn ten. They feel like a detour and they pay for themselves within days.

The trap in the other direction is doing so much with hidden state and history that nobody can follow what happened. If a player cannot reconstruct why they lost, the depth you added reads as randomness.