I am trying to write a kind of a trading card game here, in some way, it is similar to Magic The Gathering, or the Yu-Gi-Oh! card game.

For those of you who are not familiar with it, basically, in the game, there is a special kind of card (Spell cards/ Trap cards/ etc.), which have special effects that can bend the rules of the game. What I totally have no idea is, how to implement the logic of these cards. I have some idea of storing the card's data with some flags that can signal what kind of ability it has, but that would be very limited in what it can do (only some simple stats modification, maybe).

To give you an idea of what kind of effects these cards can have, here is some example of the spell card effects that are present in the Yu-Gi-Oh! card game:

  • Revive a creature that has been destroyed
  • Take control of the opponent's creature
  • Modify stats of the creature based on some conditions (e.g. Number of creature with certain names that have been destroyed)
  • Special summon a certain creatures if the some conditions are fulfilled.
  • Fuse two or more creatures into a stronger creature.
  • Immunity to some of the special cards' effect.

Konami has made several video games of the game, complete with the AI and thousands of cards variety. I don't think it is actually possible to hard-code the entire database, is it?

Now, of course what I am trying to do is in no where as complex as those games, but I am curious, how do they implement these?


3 Answers 3


There are several open-source projects of this nature, with different approaches to implementing the rules. Here is a blog entry from the creator of one of the more well-known MtG implementations, CardForge. It may not be a complete list, but it contains several open-source projects where you can simply browse the code, or visit the forums for specific questions.

As an actual answer: Your best bet for a robust framework is to strictly employ Object-Oriented Programming. Every Action, every Trigger, every Ability is an object. Zones like Hand, Library are objects too, needless to say. In the Rules engine, never pass around dumb objects like strings or integers to describe game objects, but your objects only.

Every action puts a number of trigger on a stack, where every other ability can check whether or not they care about that particular trigger, and if they do, they fire their own actions, potentially creating new triggers, and so on.

Then you work down those stacks according to the game's rules, until the stack is empty, at which point new actions can be taken etc.

Ideally, if you perfectly implement the game's rules, your rules code does not contain a single hardcoded card. Hardcoding cards can create convenient shortcuts, but in the long run, this will bloat your code and create potential pitfalls, such as when new cards are released that interact with those cards in a novel way. In a game like MtG with over 12,000 unique cards and no end in sight, there are MANY such interactions.

  • 1
    \$\begingroup\$ Good answer. Coming at it from the functional programming world, I would have each card be a closure over the game environment, to be even more ridiculously generic. For example, a card could acceptably create a new "Area" by adding a list of cards to the list of areas. Concretely: Zombie Monster Mayhem: All defeated creatures are revived in the new "Communal Cemetery" without their special abilities, and randomly attack a player based on the roll of a dice. \$\endgroup\$
    – brice
    Commented Apr 27, 2012 at 9:06
  • \$\begingroup\$ Additional link: github.com/Fluorohydride/ygopro-core for a famous open source YGO implementation, since YGO was also mentioned in the question. \$\endgroup\$
    – SK19
    Commented Mar 2, 2018 at 15:13

It is quite futile task to try incorporate all that with switches and variables alone. You would have to either hard code functions or, more likely, have a script that you interpret during the runtime. You would expose necessary functions to check status of the board and decks and graveyards to the script and the functions to execute actions, and so on. The script is then just a simple string to store along with the other variables associated with the card.

  • \$\begingroup\$ Or like hackworth suggested, having some sort of common blocks that are combined to get the behavior required. It would require some logic-blocks as well in addition to what he suggested, i think. Having shared blocks of behavior could make it easier to filter for cards that have some sort of shared qualities. \$\endgroup\$
    – Toni
    Commented Apr 26, 2012 at 15:25

I also am planning out card game using web languages with mysql db. I am currently going for a very generic setup so it keeps very flexible to new unique cards. For example instead of :

reduceHitPoints() { } 
reduceMana() { }
reduceSpeed() { }

it could easily be:

reduce($attacker, $target, $reduceWhat, $amount) { }
massReduce($attacker, Array $targets, $reduceWhat, $amount) { }

applying this concept for all actions will simplify classes, allow for new cards to be created by simply adding a single row into your cards table.

All the options and abilities will get defined in the db in that single row.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .