Drawback vs. Multi-targeting

[friarsol]

So I was in the process of doing some multi-targeting work today for cards like Plow Under, and I realized that DrawBack (in it's SubAbility form in the AFs) isn't really compatible with having more than one target.

Generally, I've moved the stored Target from the SpellAbility into the Target class. It also is now stored as two Lists (one for cards, one for Players). For Abilities (like Damage) that can target either creatures or Players the two lists are combined before being returned. For cases where both a creature and a player are targeted, the separate lists can manage that as well.

So, the main issue here is Drawback only expects one target into the function. Now I can't just call the Drawback for however many targets there are. Usually drawback only wants to be called once.

I feel like most of the functions that have drawbacks that care about the Target Card, don't have multi-targeting. So for now, if there is only one target I can send that in, and otherwise send in null. But if multi-targeting + drawbacks caring about multiple targets exist , we would need to fix DrawBack to be more flexible before we could implement them.

Any thoughts?

[Hellfish]

DISCLAIMER:The following post is very much a spur-of-the-moment idea that I havn't thought about for more than a few hours. (In terms of Forge, anyway)

Spellblocks. Basically what they are is a class inherited from SpellAbility class(or compatible with it, so we can just plop it on the stack and call it's resolve() as is) but instead of representing a single SpellAbility, it has a list of them, and it's resolve() calls it's listed SpellAbility's resolve(). So to implement SubAbilities we could do in a card's txt:

Code: Select all

Name:Brush with Death
ManaCost:2 B
Types:Sorcery
Text:no text
SpellBlock:Start
A:SP$LoseLife|Cost$2 B|Tgt$Opponent|LifeAmount$2|SpellDescription$Target opponent loses 2 life.
A:SP$GainLife|Cost$2 B|LifeAmount$2|SpellDescription$You gain 2 life.
SpellBlock:End
K:Buyback:2 B B
End

Name:Drain the well
ManaCost:2 BG BG
Types:Sorcery
Text:no text
SpellBlock:Start
A:SP$Destroy|Cost$2 BG BG|ValidTgts$Land|SpellDescription$Destroy target land.
A:SP$GainLife|Cost$2 BG BG|LifeAmount$2|SpellDescription$You gain 2 life.
SpellBlock:End
End


This could also help implement "Splice Onto Arcane".

[Sloth]

I agree with Hellfish. Combining spelleffects with the same syntax looks way more flexible and easier than adding all possible effects to doDrawback.

It looks strange though that both abilities have a cost. If we are discussing big syntax changes here, I would like to add my (quick) proposal:

Code: Select all

Name:Brush with Death
ManaCost:2 B
Types:Sorcery
Text:no text
A:SP§Cost$2 B§LoseLife|Tgt$Opponent|LifeAmount$2§GainLife|LifeAmount$2§SpellDescription$Target opponent loses 2. You gain 2 life.
K:Buyback:2 B B
End


So an ability would have a Type (AB,SP, etc), a Description and any number of effects.

A:[Type]§[Cost]§[Effect1]§[Effect2]§...§[Desc]

[Rob Cashwalker]

Couple ideas -

a) revise doDrawback to accept a Target object. If the Target object remembers all details, then use those details internally to the drawback handlers.

b) Hellfish is on the right track, however, I already planted the seeds for this... notice how AbilityFactory expects "Drawbacks" - "SubAbility$". I realized that most of the drawbacks are mostly effects and mechanics just like other simple, generic AbilityFactory effects. So why not point the SubAbility$ to an SVar containing the syntax for it. AbilityFacotry syntax uses "AB$ and SP$, so add "DB$", which can be checked as a condition for requiring the cost parameter. The AI of the parent AbilityFactory would be able to query the AI for the child AbilityFactory. (if present) A new AI method would need to be added to SpellAbility specifically for evaluating the effect as a drawback.

Then there's another variation - Wildfire. In the other thread, I already described how Charms and Commands are really just one AbilityFactory wrapped around two others. Wildfire's two clauses are essentially both positive and negative. What's the primary motivation? Dealing the damage to creatures OR saccing the lands? So a parent AbilityFactory would actually construct the Abilities in both combinations such that the AI could evaluate both concepts, if either is true, play it.

[friarsol]

Sending in Target to doDrawback doesn't really help with the multi-targeting issue. Either way, I think it would be better to continue to build up, rather than patch older code that would be replaced soon.

So, combining AbilityFactories is definitely the way to go. But I guess the important question is: Where do the blocks fit together?

Our canPlayAI() functions need to be able to call SubAbility.canPlaySubAI() for considerations and our resolve() needs to call SubAbility.resolve().

[Rob Cashwalker]

Right.

I think we should start with new naming convention for SpellAbility AI methods. In theory, at some point we should be able to support an AI method for nearly any phase stop. I guess canPlayAI_{phase} is good enough, but I always thought canPlay and canPlayAI were a bit confusing. canPlay limits IF the spell can be played at all (ie: timing) and limits both players. canPlayAI is really asking the question "SHOULD the AI play the spell?"

[friarsol]

I'm down with that. shouldAIPlay() would be more descriptive, this function (whatever the name) could be an umbrella function that would call other functions based on Turn/Phase. Certain phases could easily be grouped together here depending on what the Ability is. And that way we have a single entry point into these group of functions.

I'll continue with my original idea for the multi-targeting handling drawbacks. Once we get, far enough along we can just make sure that multi-targeting is accounted for in the new SubAbility() code.

[Rob Cashwalker]

The sub ability would need to know who its parent ability is, and then be able to access the parent's target list, because the target object the sub ability creates wouldn't know about the parent, and wouldn't always have the same targets, it may require new targets. (ie: "deal damage to target creature, then deal damage to target player")