Conditions in AF

[friarsol]

Originally I was thinking Conditions would exist as a separate AbilityFactory, but as time has gone on I realized that doesn't make sense. It should exist as something similar to a Restriction. On Resolution, we check if the Condition is true, and if it is, resolve the ability as normal. Otherwise, try to run any SubAbilities.

So today I present to you the initial carnation of Condition. It is remarkably similar to IsPresent (with an added bonus we might want to provide for IsPresent).

I used Molten Rain as a Proof of Concept for AF$Damage, but it should be a simple C/P to get it functional for other AFs. You'll probably want to add a line in the StackDescription with the Conditional Text as I did for Damage.

At some point, we will want to the AI to consider the Conditions before playing cards. If the Condition is on the Parent Ability (like Pyroblast) then the Condition should be abided (otherwise it's just a wasted spell). If the Condition is on the SubAbility, it probably should reduce likelihood of playing, but not outright return false if it can't.

And here's some wiki page for it: http://www.slightlymagic.net/wiki/Forge_Condition

[slapshot5]

Hey Sol, I'm interested in expanding this, so we can have conditions like Threshold or "if you have more life than all opponents"

Have you thought at all about where this is heading?

Is there an advantage to having a SpellAbility_Conditions class? Maybe SpellAbility_Restrictions and SpellAbility_Conditions both extend a parent class since there is a fair amount of overlap?

Ideally, in my mind, defining conditions and restrictions in the card text file would be as similar as possible.

Threshold, Hellbent could be handled something like:

Condition$ Hellbent
Restriction$ Hellbent

instead of the current use of:

ActivatingCardsInHand$ 0

or perhaps everything related to restictions would use "Activating" since that's what most things use now.

There are several different things we could do syntactically, but I think making them as similar as possible with the "Activating" vs. "Condition" distinction would make things the simplest moving forward.

If anyone has thoughts/questions/comments/concerns, please post.

-slapshot5

[friarsol]

Makes sense. There is a lot of overlap between the two, and the simpler and more consistent we make the scripting language the better. Plus it looks like AbilityFactory class is now over 1200+ lines of codes, so anything we can pull out of there is probably for the best.

Feel free to take this over and run with it. I probably won't have much time to work on anything significant for a few weeks as things are getting busy at work, which is mostly why I was trying to get the targeting/triggered thing done this past weekend.

[slapshot5]

Makes sense. There is a lot of overlap between the two, and the simpler and more consistent we make the scripting language the better. Plus it looks like AbilityFactory class is now over 1200+ lines of codes, so anything we can pull out of there is probably for the best.

Feel free to take this over and run with it. I probably won't have much time to work on anything significant for a few weeks as things are getting busy at work, which is mostly why I was trying to get the targeting/triggered thing done this past weekend.

Will do. I'm starting a new job on Monday, and this weekend I'm reffing a lacrosse tournament. So, I have today, tomorrow, and Friday before my contribution numbers start decreasing too...

-slapshot5

[Rob Cashwalker]

There are at least two categories of how conditions matter - (Hellbent as an example)

A condition may enable an ability like "Hellbent - play this ability only if you have no cards in hand." Which may be close enough for implementing "Hellbent - cardname gets +2/+2 as long as you have no cards in hand."

A condition modifies an ability like "Hellbent - if you have no cards in hand, ability does 4 damage instead."

[Sloth]

There are at least two categories of how conditions matter - (Hellbent as an example)

A condition may enable an ability like "Hellbent - play this ability only if you have no cards in hand." Which may be close enough for implementing "Hellbent - cardname gets +2/+2 as long as you have no cards in hand."

A condition modifies an ability like "Hellbent - if you have no cards in hand, ability does 4 damage instead."

Now that Rob mentions static abilities, you should consider taking a look at specialConditionsMet in GameActionUtil, in case you want to streamline/use that too.

[slapshot5]

Now that Rob mentions static abilities, you should consider taking a look at specialConditionsMet in GameActionUtil, in case you want to streamline/use that too.

I agree that consistency when related to any kind of condition is favorable.

However, this may be a Phase 4 project, and I'm still on Phase 1. There seems to just be too much difference between the st[Keyword] stuff and AbilityFactory to marry the two at this point.

-slapshot5

[slapshot5]

Ok, I have a first pass checked in for this. Not much changed, it's largely as it was before with slight renamings for consistency. Wiki has been updated with the biggest of the changes.

-slapshot5