Collectible Card Game Headquarters

I know keybone attempted to do this the other day and it turned into a much larger task than he was expecting, so I figured I'd open a discussion topic regarding it.

Currently all of the logic for Auras is in enPump. Which leads to a bunch of Auras having a useless enPump inside it, just so the Targeting is properly set for what is being enchanted.

I don't have time to do this now, but I figured we could open the discussion up and we can get some ideas for the best way to do this. And if anyone was interested they could hash it out.

We should just expand the Enchant Keyword so it takes a ValidTgt. But the keyword would need to have a way for the AI to know what it should cast the Aura on.

I guess we could just have a third parameter for who the AI would prefer to target. Certain Auras can be positive for any creature, like False Demise. It either protects your creature, or steals an opponents. Which leads to maybe something like this, where the second parameter states what the card can target. And the third states what the AI wants to target.

K:Enchant:<ValidTgts>:<PreferredValid>

Just some random examples for illustrative purposes:

Code: Select all

False Demise
K:Enchant:Creature:Creature.nonToken


Code: Select all

Weakness
K:Enchant:Creature:Creature.YouDontCtrl


Code: Select all

Bloodfire Infusion
K:Enchant:CreatureYouCtrl:CreatureYouCtrl.powerGE3


The concept looks pretty good to me. If no one else wants to do it and I have a little more time I will have a look at auras.

Why do it as a Keyword? This should be part of the AbilityFactories. The AI for a pump enchantment is slightly different from a pump spell or ability, it doesn't necessarily want to target the creature that is most likely to attack. However the AI for a creature steal shouldn't be different than a creature stealing instant. The only common element amongst all enchantments is the code that actually attaches it and de-attaches it from their host.

Just trying to brainstorm. I do think the Enchant keyword is necessary, mostly to handle the "illegal attachment" case, where I cast an Aura with "Enchant creature you control" and then the AI gains control of it.

But we can use the AFs logic for the actual casting of the spell.

Codeblocks like this should be cleaned up by using ValidTgts in the keyword..

Code: Select all

if(c.isAura()) {
   Object obj = null;
   if(c.getKeyword().contains("Enchant creature")) {
      CardList creats = new CardList(play.getCards());
      creats.addAll(oppPlay.getCards());
      creats = creats.getType("Creature");
      obj = AllZone.Display.getChoiceOptional("Pick a creature to attach "
            + c.getName() + " to", creats.toArray());
   } else if(c.getKeyword().contains("Enchant land")
         || c.getKeyword().contains("Enchant land you control")) {
      CardList lands = new CardList(play.getCards());
      //lands.addAll(oppPlay.getCards());
      lands = lands.getType("Land");
      if(lands.size() > 0) obj = AllZone.Display.getChoiceOptional(
            "Pick a land to attach " + c.getName() + " to",
            lands.toArray());
   }


So if we were going to do this without a Keyword, what would we do? Create an Attach AF? I guess we could use it it for Auras, Equipment and SAs like Aura Graft. Although we shouldn't focus on those until down the road.

I think GainControl has a "LoseControl" parameter which we we can generalize to "Duration". This may allow us to handle Auras without any major changes.

Here's how the AF portion might look:

Code: Select all

Name:Giant Strength
Text:Enchant creature
A:SP$Pump | Cost$ R R | ValidTgts$ Creature | TgtPrompt$ Select target creature | NumAtt$ +2 | NumDef$ +2 | Duration$ Enchanting | DB$ SVar=DBAttach | SpellDescription$ Enchanted creature gets +2/+2.
SVar:DBAttach:DB$Attach | Defined$ Targeted


Code: Select all

Name:Control Magic
Text:Enchant creature
A:SP$GainControl | Cost$ 2 U U | ValidTgts$ Creature | TgtPrompt$ Select target creature | Duration$ Enchanting | DB$ SVar=DBAttach | SpellDescription$ Gain control of enchanted creature.
SVar:DBAttach:DB$Attach | Defined$ Targeted


That seems a bit off to me, but maybe it's on the right track?

OFFTOPIC:
I do like the Duration idea since it streamlines something I had been thinking about recently. I added some code as "Permanent$" but didn't really like the inflexibility. Using Duration would be a much better way to do this.

Code: Select all

Flowstone Sculpture
A:AB$Pump | Cost$ 2 Discard<1/Card> | KW$ Flying | Duration$ Permanent
A:AB$Pump | Cost$ 2 Discard<1/Card> | KW$ First Strike | Duration$ Permanent
A:AB$Pump | Cost$ 2 Discard<1/Card> | KW$ Trample | Duration$ Permanent
A:AB$PutCounter | Cost$ 2 Discard<1/Card> | CounterType$ P1P1 | CounterNum$ 1


I was thinking more along these lines...

Code: Select all

A:SP$Aura | AbAura$ svAura | ValidTgts$ Creature | TgtPrompt$ Select target creature | SpellDescription$ Enchanted creature gets +2/+2.
SVar:svAura:AU$Pump | NumAtt$ +2 | NumDef$ +2

The attachment process is dealt with in the Aura API. It uses a similar form of "subability" (AbAura) to handle the specific mechanic's AI and effect.

There is a generic aura keyword.

K:Enchant Creature
K:Enchant Land
K:Enchant Enchantment
K:Enchant Artifact

will all work with no other coding. No enPump needed. The one thing I was going to change on that was to accept lowercase on the second word to match the card text. That will take some editing of cards since many have:

K:Enchant creature
and
K:enPump:0/0

That was about my first and only foray into auras. So far.

But anything else you guys come up with is fine by me for AFs.

-slapshot5

Slap,
I thought some of those were a little generalized but I couldn't find it searching in CF_Auras. We should probably improve that keyword to just take an IsValid Parameter instead of 4 different types.

This would strictly be for removing the Enchantment if it's on an illegal card.

Rob,
How about instead of an AF_Aura we just use AF_Permanent? With a Type$ parameter to say what type of card it is (or just check it's type line).

This would allow us to have a place for Permanents with additional costs or things that need to happen as they enter the battlefield like attaching or choosing a <type/color/etc>? Or Permanents that have other restrictions to being played?

During resolution, if the Type is an Aura then it would attach to the targetted permanent.

Code: Select all

A:SP$Permanent | Type$ Aura | AuraAbility$ SVar=Aura | ValidTgts$ Creature | TgtPrompt$ Select target creature | SpellDescription$ Enchanted creature gets +2/+2.
SVar:Aura:AU$Pump | NumAtt$ +2 | NumDef$ +2


friarsol - I think AF_Permanent is a little TOO generic.... Here's my take -

Permanents that need to think about their ETB effect should be handled in some manner by the underlying effect API.... For example, a card that when ETB pumps target creature, or all creatures, would be handled by AF_Pump (using a string something like "ETB$Pump"). (I might have left some commented code along those lines)

I'm kinda thinking that there would be AF_Aura and AF_Enchantment. AF_Aura worries about attaching and applying an effect to a card. AF_Enchantment would likely be a bit more simplified.

I meant to specify that triggers would not happen here. Those would still happen in an AF_Trigger as we've discussed previously. AF_Trigger with what the trigger is (enters the battlefield, leaves the battlefield, etc), with Pump as a SubAbility.

As you say, we can change the default Spell_Permanent CanPlayAI to look for and consider if an ETB Trigger can be used appropriately.

While Permanent might "seem" really generic, I don't know if it really is. Not too many cards would even need to use the Factory. Just certain Auras and certain Permanents like Belbe's Portal.

If many Auras are going to use the factory, then maybe Auras do need their own Factory. But every other (non-Land) Permanent can probably be lumped into one kind. A large majority of Permanents don't need to use this Factory at all.

Oh well, I don't have any plans do this soon, so however it gets down is fine. But it seems like in general we're on the same page.

Technically, those are replacement effects, and should be coded near "with counters" and "would ETB".
"Enchant" itself should probably be left as a keyword, but there are some corner cases in the Aura rules.