Collectible Card Game Headquarters

Ok it looks like I found something that I might actually be able to help with. As far as I know, the AI is completely unable to use cards with the "fight" keyword (Time to Feed, Pit Fight).

There appears to be a missing NOT operator on Line 56 of FightAI.java at "if (humCreatures.isEmpty() && aiCreatures.isEmpty())". Adding it will make Prey Upon work.

For Line 85 of FightAI.java, should the AND be switched to an OR? I think this path only affects Blood Feud which allows the caster to make the opponents' creatures fight each other. The AND forces the AI to only choose two creatures that can kill each other which is not really necessary since it might end up waiting forever. Without "TargetsFromDifferentZone", the AI will be forced to only use Blood Feud on the opponent's creatures while the card allows for free targeting.

Why are the other "fight" cards like Time to Feed and Mutant's Prey coded as "Pump" abilities when they are functionally the same as Prey Upon? PumpAI will reject all creatures as targets since these cards do not actually pump the creatures.

excessum wrote:Ok it looks like I found something that I might actually be able to help with. As far as I know, the AI is completely unable to use cards with the "fight" keyword (Time to Feed, Pit Fight).

There appears to be a missing NOT operator on Line 56 of FightAI.java at "if (humCreatures.isEmpty() && aiCreatures.isEmpty())". Adding it will make Prey Upon work.

For Line 85 of FightAI.java, should the AND be switched to an OR? I think this path only affects Blood Feud which allows the caster to make the opponents' creatures fight each other. The AND forces the AI to only choose two creatures that can kill each other which is not really necessary since it might end up waiting forever. Without "TargetsFromDifferentZone", the AI will be forced to only use Blood Feud on the opponent's creatures while the card allows for free targeting.

Why are the other "fight" cards like Time to Feed and Mutant's Prey coded as "Pump" abilities when they are functionally the same as Prey Upon? PumpAI will reject all creatures as targets since these cards do not actually pump the creatures.

Hey Excessum,

Thanks for wanting to contribute, I'd suggest posting patches as opposed to just lines in files, as it's easier to tell which part needs to be changed.

Looking at Prey Upon it seems incorrect as it would allow you to have two creatures you don't control (but controlled by different players) to fight each other. The extra Ability line for Time to Feed and Mutant's Prey is there for two different reasons. For Time to Feed, the opposing creature gains you life if it dies this turn, so it needs to be targeted individually. For Mutant's Prey, you can only target your own creature with a +1/+1 counter. "Dummy" pumps are occasionally used two separate distinct targeting parameters for a singular ability, it'd probably be better to have a more generic effect type that has AILogic to say what it's targeting for and pass the target parameter through to another class.

It seems forge.gui.player.TargetSelection.getValidCardsToTarget() is broken. Prey Upon can target two creature controlled by one opponent. We'd better fix this bug first.
I suggest move all of these codes to SpellAbility.canTarget so this would not be human specific code any more.

friarsol wrote:Hey Excessum,

Thanks for wanting to contribute, I'd suggest posting patches as opposed to just lines in files, as it's easier to tell which part needs to be changed.

Looking at Prey Upon it seems incorrect as it would allow you to have two creatures you don't control (but controlled by different players) to fight each other. The extra Ability line for Time to Feed and Mutant's Prey is there for two different reasons. For Time to Feed, the opposing creature gains you life if it dies this turn, so it needs to be targeted individually. For Mutant's Prey, you can only target your own creature with a +1/+1 counter. "Dummy" pumps are occasionally used two separate distinct targeting parameters for a singular ability, it'd probably be better to have a more generic effect type that has AILogic to say what it's targeting for and pass the target parameter through to another class.

Looks like I misinterpreted how "TargetsFromDifferentZone" allows Prey Upon to have a simpler logic than the other examples I mentioned. Would it be better to have the targeting code for both targets within FightAI instead of as a generic target since both targets have to be evaluated to make a rational decision? I am thinking of subsuming Polukranos, World Eater and Fall of the Hammer together with this proposed new targeting since they all require evaluating P/T and/or deathtouch for both targets.

swordshine wrote:It seems forge.gui.player.TargetSelection.getValidCardsToTarget() is broken. Prey Upon can target two creature controlled by one opponent. We'd better fix this bug first.
I suggest move all of these codes to SpellAbility.canTarget so this would not be human specific code any more.

It appears that the AI can cast Hunt the Weak without selecting an opponent creature to fight against the rules. It does not appear to enter FightAI at all. Is this bug related to the issue you mentioned?

excessum wrote:It appears that the AI can cast Hunt the Weak without selecting an opponent creature to fight against the rules. It does not appear to enter FightAI at all. Is this bug related to the issue you mentioned?

Nope. Casting a spell by AI are very different from human players (ai: forge.ai.ComputerUtil.handlePlayingSpellAbility(Player, SpellAbility, Game); human: forge.gui.player.HumanPlay.playSpellAbility(Player, SpellAbility)). AI chooses target in related forge.ai.ability, human chooses target in forge.gui.player.TargetSelection. The bug I pointed out is in human specific codes.

Here are a two things I need to understand before trying to devise a fix for the "fight" keyword:
1) Is it possible to have multiple targets for a single effect with different ValidTgts? I guess the answer is no which is why the current implementation uses the dummy "Pump" effect instead.
2) Can an effect pass variables to its subsidiary drawback/sub-ability? Any choice of fight targets would require considering both targets so I would like to pass the selected second target directly to the sub-ability. If not, the search for the second target will have to be duplicated in the sub-ability.

As mentioned previously, the AI is able to circumvent the mandatory second target for the existing fight cards to generate "fighting unknown" effects which is clearly a bug. I am not sure how the FightAI is applied for sub-abilities because the current cards do not seem to enter FightAI at all despite generating Fight effects.

excessum wrote:2) Can an effect pass variables to its subsidiary drawback/sub-ability? Any choice of fight targets would require considering both targets so I would like to pass the selected second target directly to the sub-ability. If not, the search for the second target will have to be duplicated in the sub-ability.

Maybe add a SVar that contains information of both targets to the card. Tribute cards use similar strategies.

Moving posts here so they don't clog up an inappropriate forum thread...

Thanks Marc.

excessum wrote:Here are a two things I need to understand before trying to devise a fix for the "fight" keyword:
1) Is it possible to have multiple targets for a single effect with different ValidTgts? I guess the answer is no which is why the current implementation uses the dummy "Pump" effect instead.

No it's not possible the way Targeting is structured. You can reference a parent abilities targets in a few different ways, mostly through the "Defined" Parameter.

This is the working solution that I have implemented on my local setup:
1) Adding "AILogic$ Fight" to "PumpAI" and the assorted "dummy" blocks
2) Within the new fight logic block:
a. get the valid targets for both fighters using this and sub-ability's targeting restrictions
b. perform the pair-wise check for fighters similar to the existing FightAI code
c. add the targets using this and sub-ability's addTarget methods

Is the above sequence violating any of the existing code-style?

It appears that the canPlayAI for the available abilities are checked sequentially and so the first ability of Domri Rade will always be selected. Is there any way to increase the priority of the second (fight) ability other than by forcing the first (PeekandReveal) ability be random or activated in the second main only?

Here is the prototype fix for the fight mechanic. The code for Domri Rade, Hunt the Hunter, Hunt the Weak, Mutant's Prey and Pit Fight and the relevant base abilities have been updated in this patch.

I havent't really tested your patch yet, but your approach looks good.

If no one objects i would grant you commit rights, if you apply for them.

Sloth wrote:I havent't really tested your patch yet, but your approach looks good.

If no one objects i would grant you commit rights, if you apply for them.

Thanks for your support. Now that I have commit rights, do I just go ahead and commit it to the repository?

Should I bother with fixing the entirety of FightAI and the other cards to remove the obsolete code?

excessum wrote:Thanks for your support. Now that I have commit rights, do I just go ahead and commit it to the repository?

I did a quick test with Pit Fight and the AI used it correctly. Good work excessum.

excessum wrote:Should I bother with fixing the entirety of FightAI and the other cards to remove the obsolete code?

If you find something better to do, then don't bother. If you are up to a challenge you can try to implement an AI for abilities giving Protection to creatures.

Is there a consolidated list of the AI issues with protection from blah effects? I see a bunch of todo's in ProtectAI and incomplete code snippets and I am not sure if multiple authors added different chunks or if a single author left those chunks empty.

Off hand, I can think of the following:
1) shroud from targeted spell/effect (copy from hexproof/shroud logic?)
2) deal unblocked damage (risky due to multi/uncolored creatures)
3) survive chump block (likely to be too fringe)
4) assess cost/benefit of enchantments/equipment dropping off (probably too complicated to implement)