Collectible Card Game Headquarters

I am mainly working on the AI issues so I will be using this thread to post questions/ideas as they come up...

An issue with the AI attacking system is that it fails to consider animated creatures. Looking at the code for the Animate effect, it seems involve a huge amount of effort to animate stuff and then return them to their original form. Is there a way to write a conditional block where the Animate effect "resolves" so that the AI can "see" the possible creatures before declaring attackers? The other alternative is to parse the animated creature stats directly and replace the source Card with the transformed version.

I think it's better to parse the stats directly. Max put a lot of effort into separating AI from rules engine, so it wouldn't make him happy to see a special resolve version just for the AI.

Start with a small goal like vanilla manlands and see how far you can go.

Sloth wrote:I think it's better to parse the stats directly. Max put a lot of effort into separating AI from rules engine, so it wouldn't make him happy to see a special resolve version just for the AI.

Start with a small goal like vanilla manlands and see how far you can go.

OK I hit a snag. How do I create a new Card object to apply the parsed stats to? I am reluctant to modify the actual un-animated Card since it is a hassle to hunt it down after the AiAttackController finishes its work and apply the reverse modifications.

For a normal card, you can use:
"copy = CardFactory.getCard(c.getPaperCard(), controller);"

For a token:
"copy = CardFactory.copyStats(c, controller);"

Why does at all your 'AI' modify cards's stats?

Max mtg wrote:Why does at all your 'AI' modify cards's stats?

I am creating a temporary Card object with the animated creature stats so that they can be added to AiAttackController.opplist without actually resolving the actual AnimateEffect on the original Card.

Sloth wrote:For a normal card, you can use:
"copy = CardFactory.getCard(c.getPaperCard(), controller);"

Using the above seems to work as expected. The AI has issues with canPayCost with multiple man-lands and/or animated mana-sources (two untapped Mutavault = 1 animated Mutavault but the AI sees 2 by paying for one with the other).

If this proposed system is acceptable, I am considering incorporating parts of it into the AnimateAi to help the AI decide if it is worth animating to attack or block rather than wasting mana to do nothing with the animated creatures.

EDIT:
The above method does not take into account the presence of other effects like Spear of Heliod so the calculations are off. It seems that there is no convenient way to do this without implementing a whole bunch of extra stuff.

excessum wrote:Using the above seems to work as expected. The AI has issues with canPayCost with multiple man-lands and/or animated mana-sources (two untapped Mutavault = 1 animated Mutavault but the AI sees 2 by paying for one with the other).

If this proposed system is acceptable, I am considering incorporating parts of it into the AnimateAi to help the AI decide if it is worth animating to attack or block rather than wasting mana to do nothing with the animated creatures.

EDIT:
The above method does not take into account the presence of other effects like Spear of Heliod so the calculations are off. It seems that there is no convenient way to do this without implementing a whole bunch of extra stuff.

It's impossible to take all possible interactions into account (at least without creating code to copy the whole gamestate as an AI playground), so we have to stick to the most likely/basic scenarios.

I'm looking forward to test your changes excessum.

The tentative patch is attached. I am not certain if the addition of the abilities/triggers/replacements/etc. to the temporary Card will cause unintended consequences so please have a look through first. I have tested the following scenarios:
1) Elvish Mystic vs Mutavault (AI will not attack because 1/1 < 2/2)
2) Galerider Sliver vs Azorius Keyrune (AI will not attack as blocker can also fly)
3) Soldier of the Pantheon vs Raging Ravine (AI will attack because of protection)
4) Elvish Mystic vs Svogthos, the Restless Tomb + enough creatures in graveyard (FAIL. AI cannot get proper P/T)

I have no idea how to allow the AI to check other restrictions on activation (Haunted Plate Mail) or wacky effects (Lifespark Spellbomb). I am leaning towards scrapping the entire abilities etc. block and just sticking with the AnimateEffectBase.doAnimate since the AI will probably fail to evaluate them correctly anyway.

The patch looks solid. I think i found a source for possible Null Pointer Errors, but i can fix that myself, after it has been commited.

When i have some time i will try to check restrictions on activations and static abilities (Svogthos, the Restless Tomb).

Which section of the code do I have to look at to change the behaviour for the AI's choice in paying mana costs? Currently it does silly things like tapping heavily-enchanted Opaline Unicorn or Voyaging Satyr in Limited, and the classic tapping animated Mutavault to animate another Mutavault in Standard.

Another question is the possible use of the new AnimateAI.becomeAnimated() to help the AI decide if it should animate for attacking. There appears to be a number of other effects that use AnimateAI but do not actually become creatures. I do not know if it is safe to modify AnimateAI.canPlay() since it might break those other cards unless there is an easy way to tell if the particular SpellAbility actually does make a non-creature into a creature.

excessum wrote:Which section of the code do I have to look at to change the behaviour for the AI's choice in paying mana costs? Currently it does silly things like tapping heavily-enchanted Opaline Unicorn or Voyaging Satyr in Limited, and the classic tapping animated Mutavault to animate another Mutavault in Standard.

Everything about AI's mana payment should be in ComputerUtilMana. The function getAvailableMana produces an ordered list of mana sources. You can enhance the ordering, but currently there is no way to compare the effect to the cost.

excessum wrote:Another question is the possible use of the new AnimateAI.becomeAnimated() to help the AI decide if it should animate for attacking. There appears to be a number of other effects that use AnimateAI but do not actually become creatures. I do not know if it is safe to modify AnimateAI.canPlay() since it might break those other cards unless there is an easy way to tell if the particular SpellAbility actually does make a non-creature into a creature.

The becomeAnimated function should be very useful to enhance AI's animate-for-attacking-decissions. Feel free to modify AnimateAI.canPlay(), it's very undeveloped anyway. But if you want you can check the "Types" parameter for "Creature" to make sure a non-creature is turned into a creature.

The attached protect patch includes the code for protecting against bad stuff on the stack and rescuing attackers and blockers from lethal damage.

The last component I am thinking of adding is if a protection can make a creature unblockable and then computing a probability based on the expected damage over the opponent's current life total. I need a little help on finding out which functions to call because I recall seeing bits and pieces of relevant code when I was searching for other stuff and cannot remember where and what they are. I think I will have to write the "check if unblockable" code but I believe the functions to calculate unblocked combat damage and opponent's life check already exist?

excessum wrote:The attached protect patch includes the code for protecting against bad stuff on the stack and rescuing attackers and blockers from lethal damage.

Wow, that must have been a lot of work. I've found two places for very rare NPE's, but i can fix that after it has been commited. So go ahead if you want.

excessum wrote:The last component I am thinking of adding is if a protection can make a creature unblockable and then computing a probability based on the expected damage over the opponent's current life total. I need a little help on finding out which functions to call because I recall seeing bits and pieces of relevant code when I was searching for other stuff and cannot remember where and what they are. I think I will have to write the "check if unblockable" code but I believe the functions to calculate unblocked combat damage and opponent's life check already exist?

For unblocked damage use ComputerUtilCombat.damageIfUnblocked. For the life of opponents use .getLife() on him.

Are there any plans for AI improvement?

I always thought that Magic could benefit from Monte Carlo method:

1. List possible actions/decisions for AI.
2. For each possibility, make 100 trials: randomize all cards AI doesn't know and just let the current AI play for all players for a few turns. (Alternatively, you can perform just 100 randomizations and let each possibiliy work on each randomization.)
3. Compute average score for each possibility.
4. Choose the possibility with best score.

This could give AI access to approximate answers to questions like "How likely is my spell will be countered?", and it would allow it to see some unexpected actions (like that it can win by casting Murder on its Tormented Hero if opponent is at 1 life), yet it would still use the element of randomness.

Someone has probably thought of this before...

Marek14 wrote:Are there any plans for AI improvement?

The main issue is that Forge has a fair amount of technical debt (a lot less than it used to of course). And the main thing holding us back from this is saving game state (and a better way to calculate how good a game state is). Tthere were a few pushes for it, but the codebase wasn't quite ready for it at the time. I believe it will happen at some point, but it's going to take a dedicated coder who's familiar with all the right places to get things working the way it should.