What is a card?

This post is about ambiguity, but this post is not about Ambiguity. (Don't forget to look at the card topsy turvy as well. And don't forget to look at the card Topsy Turvy as well)

Okay, enough with the puns... at least if I don't find any others while writing... what I really want to write about is how overloaded the term "Card" is in Magic. Let's see how many different meanings I can come up with.

Cards are those things that Wizards designs. For example, Grizzly Bears is a card, and Llanowar Elves is as well.

What about two Grizzly Bears? A card can also mean the physical object, sold in boosters and put in decks. But you can't even simply say that the physical card is "a Grizzly Bears", because there's a few different ones. And there's foil as well, and probably other things I'm forgetting. So the physical card is actually not an instance of what Wizards R&D designed, but of one translation of one printing of such a card, either in foil or not.

Getting to the actual game, cards are a kind of object, in contrast with tokens and copies of cards, which are not cards but serve almost the same purpose.

Noncard objects exist in a few different forms: emblems are always in the command zone; tokens can only exist on the battlefield; ability objects exist on the stack; copies of spells exist on the stack; casting a copy of a card creates that copy in the original card's zone, which in then put onto the stack as a spell while casting.

Permanents are objects that can be either cards or tokens, so another thing a card can be. Compared to other objects, permanents have state:  tapped/untapped, flipped/unflipped, face up/face down, and phased in/phased out.

The comprehensive rules on spells are worded a little strangely: "A spell is a card on the stack", "A copy of a spell is also a spell", "if the player does [cast a copy of a card], that copy is a spell as well". It sounds contradictory at first, but it's manageable.

So what have we got here:

• What Oracle says a card is, identified by the English name of the card.
• A printing of such a card, identified by English name together with an expansion. This extends the Oracle card by rarity, artist, illustration, collector number, card frame style, guild symbols and similar in the text box, ...
• A translation of a printing, identified by a multiverse ID, or alternately by English name, expansion and language; I wouldn't trust that the translated name is unique. The translation adds obviously anything language specific about a card. This includes printed, non-oracle wording including reminder text, as well as flavor text.
• A piece of cardboard that has a Magic card printed on it. To my understanding, this interpretation of "card" can be uniquely identified by a function defined on an interval of the timeline that maps every instant in that interval to the volume of space that is occupied by the card at that time. Or, a card is a card.
• A digital representation of such can also be considered a card in that sense.
• A card is an object that can be in a zone in a game of Magic.
• Some permanents are (represented by) cards.
• Some spells are (represented by) cards.

You can imagine that all this ambiguity makes it quite hard to come up with a proper software model for a game of Magic!

Quantum Mechanics and Magic AI

Okay, the title is kind of a stretch, but Quantum Mechanics sounds so much cooler than probability...

So what do I want to talk about? One thought that I often have is that the computer has the advantage of perfect memory. If it once views your hand, it can perfectly memorize all the cards in it. It follows that it can say that as long as a card doesn't leave your hand, you still have it in hand. But when the game progresses, things get more vague: You shuffle cards into your library without revealing them before. Here, probability comes into play.

I assume that the computer knows my deck list for simplicity. (It could even use heuristics to guess what cards might be in your deck, but that only complicates the matter.) At the beginning of the game, before even drawing your opening hand, each card in the library has an equal chance of being one of the, say, 60 cards in your deck. For example, in your mono green deck, a card has a 24 in 60 chance of being a forest. These chances don't change as you draw seven cards, at least from the computer's point of view. Even so, the computer can say that the probability of you having a Giant Growth in hand is (# Giant Growth in deck)/(# cards in deck)*(# cards in hand), and it can have "fear" that you might play that card during combat. The greater the probability, the greater the fear.

Now comes the "collapse of the wave function": the computer observes the cards in your hand. (You see, I can even use QM terminology here ;)) Suddenly, the probability of every of the cards in your hand becomes 100% for the card the AI has observed. Technically, as the hand is not a sorted zone, the AI should not remember which card is which. Let's say you have 4 different cards in hand, then the AI can assume that every of the cards has a 25% probability of being any of these cards.

When you now shuffle one card back into your library, nothing really changes, except that there's only 3 cards for a total of 75% per previously observed card.

I hope that it's clear what I'm saying. I have the feeling to make too many words about a simple concept, yet at the same time I feel that all this seems abstract and not very understandable... well, I should have made some images, but I'm too lazy...

Let me end with this: Magic is a game of uncertainty, and luckily the computer has the capabilities to process these. When an AI can make decisions based on what it sees, why not on what it doesn't see? Assigning these possibilities is pretty simple; every card in the game has a total of 100% of being some card from the deck list, and every card in the deck list is represented to 100% among all cards in the game.
The problem is to design the AI to use that information; it's often hard enough to process the known information, so even more the unknown. But in principle, there's no difference. And even if it is too hard, there are some shortcuts: If you have only one Morph card and play a Morph card, the AI knows which it is, even though it's face down. Such probability collapses can happen all the time, and it would be a waste to let them go unconsidered.

Cards - Two views on the same thing

I would really like to know if you can imagine of what two views I'm going to talk about. I guess it's more obvious for people who have thought about how to structure a magic application. If you like, leave a comment and state what's your background.

When you open a booster pack, how do you read cards? They have symbols and text, and of course you can read them and determine what they do. However, the card can't do anything, because you're not playing a game.
During a game, the card has a complex context that influences how you read it; For example, its color may have changed.

Humans can read a card outside the game and inside the game, but it's hard for a computer. The difference between these two views is very important and currently makes me some problems. A card outside the game (template), like the one from the booster, is a constant thing - it can't change between different copies. This means that multipe cards inside the game can share the same template, but those are then individuals. They have the same template, but that's it.
The same thought can be applied to abilities and spells, I think. Abilities and spells have another, even harder problem: Their effects. While cards just sit there, spells and abilities can directly influence the game, and what influence that is depends on how the spell/ability was played.

So what's the solution to the problem? Well, in a nutshell, the data structure for cards, spells and abilities is duplicated.

Outside of the game is CardTemplate and CardParts, inside the game is CardObject and CardCharacteristics. A CardCharacteristics is assigned to a CardObject is responsible for providing the characteristics, respecting effects and the layer system, but also taking into account the values "printed" on a CardParts object.

Outside the game is ActivatedAbility, inside the game is ActivateAction, PlayInformation and AbilityObject.

• ActivatedAbility has a method getPlayInformation() which takes an ActivateAction and returns a PlayInformation.
• The PlayInformation is the real worker of abilities and implements modes, targeting, costs, effects etc. It depends on the game, so an activated ability can only create the PlayInformation if a game is provided.
• And to make things easier, the activate action has some additional infos like who played the ability and what card the ability is on (like I said, ActivatedAbility is outside the game, so it doesn't know which cards it is on. the ActivateAction knows).

All that happens under the surface. The ActivateAction retrieves the PlayInformation and does all the necessary things, like putting an AbilityObject onto the stack etc.

I hope that you had a chance to look into my program; I know that this is very hard to imagine without directly looking at the code, So I won't try to go into more detail unless you wish so ;)

html-Comprehensive Rules

To be precise, the title is a little mis-leading, but it is effectively that.
One part of my program is a parser for the comprehensive rules. It converts the text-version that you can download from Wizards into an xml-File, which is formatted as html with xslt. You can view it like any other html page in your browser.
My file has a very convenient features opposed to those directly from wizards: Links. Everywhere there's a cross reference between rules, you have a hyperlink that lets you directly jump to it. My next version should also have images for the mana- and tap symbols.

You can download the result directly here: xml and xsl, both are needed for proper display.

If you want to run the program yourself, you have to take some preparations (you may just ignore this if you're not into programming):

laterna and treeProperties (both on the SVN) are two distinct projects, you will need both. Additionally, I use jdom for creating the xml. You have to configure laterna's build path to contain the both.

I hope you enjoy it!

Traps in the rules system

I think you can divide the rules in several complexity stages:

• The "dumb" parts, like damage assignment order. These are things that aren't too hard, but you have to do them. When assigning blockers, you have to store a collection of the blockers anyway, letting the user sort it is not much more work. Another thing is mulligan, this is a check at the beginning of the game, and you just do it or not.
  
• The challenging parts. I consider the layering system of Magic is such thing. The layering system is quite complex: Effects that modify different characteristics are applied after each other, so you have to store the basic characteristics (as printed on the cards) and the effects that modify it. it's not enough to store the results, because of cases like:
  some 1/1 creature
  attach Bonesplitter (+2/+0) --> 3/1
  switch P/T --> 1/3
  unattach bonesplitter --> -1/3
  well, this is obviously wrong. you have to do a bunch of work (not dumb work, though) to get this right, but it's not undoable
• The very hard parts. I think text-changing and replacement effects fall under this category. text changing effects require a very good structure for storing card text, that makes it possible to change any interesting part. well it may be simple to change "Goblin" into "Elf", but think about changes like "Choose one" into "Choose two", that don't only affect what the outcome of the effect is, but actually what happens.
  Replacement effects have a similar problem as Triggered ability. Both need an event system that makes it possible to track changes to the game, but replacement effect don't only listen to events, they also negate those events on the fly.

obviously, the second category is the most fun to program. i actually have a working layer system, it took me around 3,500 lines of code in about 40 classes.

What can a Magic Program do?

When you do a program, you have to ask yourself what you want from it - at least in Open Source, in commercial projects you tend to as others what they want from it...
my ambitions usually go very high, and it's not very different with Laterna Magica (that's how I named my project). I basically replace the question "What should it do?" with "What can it do?".
I want to list some features that a Magic program can provide:

• Rules Enforcement
  This is one of the two features that are the most interesting - and most difficult - features.
  Rules enforcement means that you have to teach the computer what a player may do. It's hard enough to teach a human to play Magic, and humans are at least intelligent.
  Implementing a rules system usually means to describe what the parts (cards, players, but also turns and combat) of the game are, what the possible moves and their outcomes are, and what moves are legal for a game state (the rules).
• Human vs Human
  Such a game is imaginable without rules enforcement. It's like paper magic, you make sure yourself that no one is cheating. examples for multiplayer Magic programs without rules enforcement are Apprentice and MagicWorkStation. This is relatively easy to implement, because you can skip the very huge rules enforcement part and can focus on a usable user interface and the network aspects. an upside to the user is that you can take shortcuts easily, a downside is that you may accidentally make illegal moves.
• Singleplayer Magic & AI
  Singleplayer games are harder, because it requires the computer not only to enforce the rules, but also to implement an Artificial Intelligence to make decisions itself, which is likely even harder than rules enforcement itself.
• Multiplayer games
  Games with more than two players are a challenge for several reasons: you're likely to do it over network, so you have to have a server which maintains game state, or connect every player with each other. Additionally, a user interface that shows three players is hard.
• Good User Interface
  "Last but not least": having a good interface is very important, because no matter how correct your rules implementation or AI is, in the end it's about playing a game, and that has to be fun after all. Maybe you're interested in This youtube video about the new MTGO interface. Wizards seems to have taken other Magic programs into account when designing this; some of the features seem similar to Incantus.
  I list it last here because it's far away from the other topics: my other four points are "low level" (although ideally the AI is also independent from the rest), and in a perfect world you could build a user interface on top of a program that was developed with no thought about it.
  

Welcome in the complicated word of Magic: the Gathering!

Magic is a very deep and interesting game. It has several thousand different cards that make every game a unique experience, and hundreds of pages of rules that describe in detail how to manage all those different cards.

while this sounds intimidating for some people, i like the idea of such a well-defined system, and that's why Magic attracts so many programmers, like me.

I hope you enjoy my posts, and please leave comments if you feel like it.