Whenever I create a card game, I tend two write my own domain specific language to specify the mechanics of my cards.

This also happened for my entry to the game jam "Meat'n'Jam 2023". In my game "Waiting for Wind" you are playing a flock of birds, migration to Africa. Whenever the birds land, a stack of cards simulates what adventures the birds have in that area – until the wind comes and carries them away.

Syntax

My DSL had the following syntax (written in Elm): 

type Action
    = AddFoodAndThen Int Action     
    | IfEnoughFoodAndThen Int (List Action) (List Action)     
    | AddBirdAndThen Action     
    | LooseBirdAndThen Action     
    | FilterDeck (Card -> Bool)     
    | DrawCard     
    | Shuffle     
    | RemoveDeckAndThen Action     
    | ChooseNewDeck     
    | NewDeck Deck     
    | DiscardCard

An Action always results in an animation or a popup.

There are also actions that end with "AndThen". These are actions don't have an animation and therefore need to be followed by another action.

To avoid having negative food, I added a special "if"-condition, that checks if the player has enough food before playing an action.

Additionally, I also have a filter action for filtering cards in the deck. This is used for the competition card ("Remove all food cards from the deck" ).

Semantics

The game has a list of actions and every 500ms the next action will be processed.

To apply an action, I implemented a "applyAction" function. 

applyAction : Action -> Game -> Generator ( Game, List Event )

This function takes an action and a game and returns (based on some random seed) a game with a list of events.

Actions like "Shuffle" will use randomness (while most other actions will not result in random behavior).

type Event     
    = AddActions (List Action)     
    | ChooseDeck (List Deck)     
    | PlaySound Sound

Actions can also spawn three types of  events:

• Adding new actions to the stack of actions
• Request the user to choose a deck
• play a sound

Event vs Actions

Both Events and actions look very similar, but the difference is that actions can be handled by the game, whereas events are handled outside the game. So events can depend on actions, but not the other side around.

I hope you now see why DSL are such a nice design pattern for designing card games.