Layering system approach

[silly freak]

okay, there's much coming now. it's pretty much only about how a card's characteristics are determined

my goal was to support split and flip cards too, and to make it minimally error prone, read: not to have to trigger for card getting into/leaving the range of an effect

first of all, I made a few separations. in my aproach, there are
card parts - this is the set of stuff printed on a single card (or side or half for split/flip). the information of a card part is not modified. it is just like printed card text - the basis for determining characteristics, and shared between individual equal cards
card templates - this is an oracle card a card template has a layout - normal, split or flip - and a set of card parts, which are treated acording to the layout
card object - a single card. a card object has a card template, and a characteristics for each card part.
characteristics - this stores the actual characteristics derived from the card part. there are three different characteristic types (the characteristics object has a characteristic object for every characteristic):
Overriding characteristic - for things like name, mana cost. the only change that can be done to them is completely replacing it.
set characteristic - can be added to, removed from, set or unset (meaning the characteristic has all but the specified values). this is for things like supertype, type, subtype
pt characteristic - pt is such a strange matter, it has its own characteristic. changing is performed in a fashion special to each layer

the way how characteristics are modified are continuous effects already. there are overriding, adding, removing, setting, unsetting, p/t setting, p/t modifying and p/t flipping effects.
getting the card part's values into the characteristics is done by intrinsic continuous effects that can't be removed and are applied in "layer zero". i don't know how much of a hack this is, but after all it was easier to store and to process - frees me from individual code for all the set characteristics, which only differ in type, and the property name in the card parts

effects from static abilities are stored on game scope - when examining characteristics of any card, they are considered, and then decide if they apply or not. this way, I only have to look after the ability starting and stopping, not individual cards gaining/losing boni

continuous effects from one-shot effects are currently stored at the granularity of characteristics. i've decided that quite a while ago, and now I think if not the card is the right place? can you think of a situation where an effect applies only to one half of a split card?

[Marek14]

Situation when effect applies to one half of a split card might occur when the card is on stack - since there the other half effectively doesn't exist. But I assume you take that into account.

Otherwise, the game rules are not able to see the details of split card when it's elsewhere. As long as they can ask them questions and cope with the answers, it should be fine

Any ideas what to do about dependencies?

[silly freak]

i wonder if the situation split card on the stack matters... i think it can't become the other side and then not be affected anymore. and if a characteristics that doesn't exist is affected, it doesn't matter too
i think a case is something like an ordinary temporary pump and a flip creature:
the pump comes from a one-shot-effect, so it is stored in the characteristics. then the card flips. the other half now wouldn't get the pump - which seems wrong to me.

for split cards, i'm more concerned about when they are not on the stack. but then again, comparisons work on the full card and therefore effects also do. thanks for your ideas here!

yeah, dependencies are hard. timestamps and layers are running for me, by a sorted set of effects, but i haven't thought of dependencies too much (read: though much but found nothing). I think it could be handeled somewhen by changing the comparator. i think it might be a while before I come up with text changing and ability adding/removing effects

[Marek14]

The pump effect should definitely apply to a flip card after it flips... flip changes the base characteristics, but not the later effects.

[silly freak]

quick update:
i was applying the effects characteristic for characteristic. that isn't a problem for effects from one-shot effects. however, facing those of static abilities, there's a problem.
when an effect determines a characteristic to see if it applies, it should see the state exactly before it is applied. with my current approach, it would see the final value, which may result in infinite recursion

my new approach is to compute all characteristics at once, every time the effects applying have changed. during such a refresh, the "uncomplete" characteristic is returned, not recursively computed. this way, static effects see the value they are supposed to see

[silly freak]

ok, i'm facing problems. could anyone make the situation clear to me

the thing is mana cost and color. color is derived from mana cost by default, but i'm struck with the details. look at these situations:
(to make it easier, here are the layers for reference:
1: Copy effects
2: Control-changing effects
3: Text-changing effects
4: Type-changing effects
5: Color-changing effects
6: Ability-adding/removing effects)

• if a card's mana cost is changed, the color changes too. that's how a copy gets its color. i think that's a text-changing effect, but does it also get the new color(s) in layer 3, or in 5?
• what is with color defining abilities when a card looses it? i'd say the color has already changed, but that's pretty counter-intuitive.

currently, my program works with an effect that initializes a characteristic to its value, and that's of course also done for color. so, changing mana cost does not automatically change color. do you think that applying a color-changing effect in layer 3 will yield correct results?

[Marek14]

ok, i'm facing problems. could anyone make the situation clear to me

the thing is mana cost and color. color is derived from mana cost by default, but i'm struck with the details. look at these situations:
(to make it easier, here are the layers for reference:
1: Copy effects
2: Control-changing effects
3: Text-changing effects
4: Type-changing effects
5: Color-changing effects
6: Ability-adding/removing effects)

• if a card's mana cost is changed, the color changes too. that's how a copy gets its color. i think that's a text-changing effect, but does it also get the new color(s) in layer 3, or in 5?
• what is with color defining abilities when a card looses it? i'd say the color has already changed, but that's pretty counter-intuitive.

currently, my program works with an effect that initializes a characteristic to its value, and that's of course also done for color. so, changing mana cost does not automatically change color. do you think that applying a color-changing effect in layer 3 will yield correct results?

I'd suggest to start color-changing effects (layer 5) by initializing the color from the mana cost of object. It really doesn't matter when you do this, as long as it's before anything that would change the color later, and after anything that would change the mana cost (currently that can be only done by copy effects).

Color-defining characteristic-setting abilities are applied in layer 5. The adding/removing of abilities is later layer, so even if the ability is lost, it's AFTER application. It's the same with changeling - if the changeling ability is lost, the object still has all creature types. This is also reason why cards like Amoeboid Changeling say that something "gains all creature types" and not "gains changeling" - gaining changeling wouldn't do anything to creature types since it would be gained too late to apply.

[silly freak]

cool, i didn't even know this changeling issue, thanks.

about "it doesn't matter where if it's soon enough", i fear the problem is with effects like "all red creatures are goblins".
say you change the mana cost (layer 3) to something red. the type changing effect (layer 4) is (not?) applied before color changing effects. the question is, has the color already changed?

[Marek14]

cool, i didn't even know this changeling issue, thanks.

about "it doesn't matter where if it's soon enough", i fear the problem is with effects like "all red creatures are goblins".
say you change the mana cost (layer 3) to something red. the type changing effect (layer 4) is (not?) applied before color changing effects. the question is, has the color already changed?

Well, I don't think you need to worry about this particular effect. Wizards, as a rule, don't make abilities that would work "backwards" in layers.

As an example, have a look at Witch-Maw Nephilim. It reads "Whenever Witch-Maw Nephilim attacks, it gains trample until end of turn if its power is 10 or greater."

Why doesn't it simply say "Witch-Maw Nephilim has trample as long as its power is 10 or greater."? Because that would be backwards effect. It would check its power back in layer 6, before any modifications occur. It's an ability that is easy to understand intuitively, but it wouldn't work in the rules framework (this is also part of reason why so many Naya creatures give out abilities to "power 5 or more" for low mana cost, but none have static abilities that would affect such creatures).

"All red creatures are Goblins" has similar problem. It simply doesn't work the way players would want - and expect! - it to. Forget mana costs - even straightforward color change effects wouldn't work correctly with such ability.

Note, though, Dralnu's Crusade - that one checks subtype and affects color based on the result. This works, because color is later in the layer system.

If the ability DID exist, though, my guess is that it would take into account mana cost changes in layer 3 - and that CAN be done, I forgot about Volrath's Shapeshifter in my previous message.

[silly freak]

update for everyone interested, and special thanks to marek. your rules knowledge is impressive

the game has a GlobalEffects object that stores a map of effects from static abilities and matchers. the Matcher differentiates between cards the effect should apply to, and those it shouldn't.
for example, Glorious Anthem would store a +1/+1 P/T changing effect, and a matcher that matches only creatures you control.
every card itself has a set (no use for a matcher) of the effects applied to them. for example, Giant Growth stores a +3/+3 P/T changing effect on the card it affects, and removes it at end of turn.

now comes the really interesting thing - how the characteristics are refreshed.
at first, a sorted map is created from merging the local set (with a null matcher) and the global map. the sorting order is set by a comparator that currently takes layers and timestamps into account, dependency still missing
then the map is iterated effect by effect. if there's a matcher, it's checked, and the effect is only applied if it matches. the matching operations happen between the effects, so every matcher sees the right value - that after applying every previous effect; nothing "older", but also not trying to look in the "future"

i feel a bit unwell for creating the map every time, but I don't come around that - java collections don't keep their order with changing keys (timestamps), so it's necessary to create a new one - or refilling an old one.

[Marek14]

update for everyone interested, and special thanks to marek. your rules knowledge is impressive

the game has a GlobalEffects object that stores a map of effects from static abilities and matchers. the Matcher differentiates between cards the effect should apply to, and those it shouldn't.
for example, Glorious Anthem would store a +1/+1 P/T changing effect, and a matcher that matches only creatures you control.
every card itself has a set (no use for a matcher) of the effects applied to them. for example, Giant Growth stores a +3/+3 P/T changing effect on the card it affects, and removes it at end of turn.

now comes the really interesting thing - how the characteristics are refreshed.
at first, a sorted map is created from merging the local set (with a null matcher) and the global map. the sorting order is set by a comparator that currently takes layers and timestamps into account, dependency still missing
then the map is iterated effect by effect. if there's a matcher, it's checked, and the effect is only applied if it matches. the matching operations happen between the effects, so every matcher sees the right value - that after applying every previous effect; nothing "older", but also not trying to look in the "future"

i feel a bit unwell for creating the map every time, but I don't come around that - java collections don't keep their order with changing keys (timestamps), so it's necessary to create a new one - or refilling an old one.

If the computer can handle it then why not? Constant re-creation is probably the most precise way to do it.