That has to be the one of the most dreaded topics of the comprehensive rules an enthusiast MTG programmer has to face.
It’s not that hard to understand. It’s not very long to read. Yeah, you might have to read it a couple of times to grasp it, and it makes sense. It’s not even really that hard to program (although it’s not trivial). The real pain, for me, comes from the fact that it’s really hard to program efficiently.
When I talk about efficiency, I talk mainly about the performance of the action of changing values on objects (cards). That kind of efficiency is not that important for most applications. I don’t care if changing the zone of a card takes 3 ms more than before when I’m talking about networking, UI, undo/redo. Where efficiency is important, though, is when you got a minmax AI that’s just craving to try out all the possibilities. Then all those 3 ms add up to a huge (measurable) amount. I don’t know the actual figures, they are not actually important, but I think it is a concern when doing minmax AI.
So, where does all this complexity comes from? Well, the rule 612 implies that a change of value on a property of an object can have effects on an arbitrary number of other properties on that same object (changing the color can change the power/toughness if an effect is present). Ouch! That means that I must update all the values of an object each time I make one change! Of course, I can optimize for special cases so that I don’t always pay the price of continous effects, but the bottom line is that I can’t be as efficient as I was before (and trust me, I was pretty efficient).
Add the fact that the changes needed to support continous effects have effects on very core parts of the system (transactions, events) and you have a lot of fun ahead of you!
After staring at a blank screen for a couple of days trying to wrap my head around a viable solution, I finally started producing something. It might not be perfect, but at least I think I’ll get something working, along with the tests. I can optimize later.