AI Never Chump-Blocks

[rampaging-poet]

Currently the AI never blocks unless its blocker will survive or trade well. It will never chump, not even to save its life. The AI should chump-block to avoid lethal damage if possible.

[JRHerlehy]

The AI has not been worked on in a long time and is not under any active development. Best use is for gold fishing of decks really.

[JayDi85]

I agree -- AI must use all possible creatures on last standing (even if they die).

[jeffwadsworth]

This is being worked on. Just trying to find an efficient algorithm to handle all combinations of attackers and blockers. If that works out, the AI will perform multi-blocking as well....whatever gives the best board score. Any ideas on a algorithm would be appreciated.

[JayDi85]

One of the ideas: use two stage filtering for normal round (not last standing - e.g. alpha strike < max life) -- it's only idea, I'm not an AI programmer and do not know xmage AI code:

On first stage search "kill and survive" attack/defend combinations -- AI card can defend and kill attacker:

1. cycle attackers from most powerful;
2. search all defenders for that attacker card (defend card: can defend, power >= attacker defend, life < attacker power);
3. calc ratio: defender power / attacker life;
4. sort cards by that ratio -- select card with minimum value (e.g. choose 2/2 for killing 1/1 instead choose 5/5 for killing 1/1);
   5. repeat number 2+ for other attackers but do not use used cards from number 4.
   6. if you have boost cards then can random choose one card and boost it for calcs (it's more complicated but big surprise for players -- may be used for AI attack stage, not defend).

On second stage search "block and die" (do not search/use cards from stage 1 -- they are "done"):

1. cycle attackers from most powerful;
2. search all possible defenders;
3. calc ratio: attacker power / defender life;
4. if ratio more than 5 then go father or ignore (no need to block and die);
5. sort by ratio and select card with bigger value (e.g. select 1/1 to block 5/5 instead select 4/4 to block 5/5);

On last standing round (alpha strike > your life) you can change min ratio value in step 4 to 1 (e.g. try to block all cards as possible until alpha strike is gone: block one, recalc, block second, recalc... hmm).

[jeffwadsworth]

I would rather calculate all combinations of attacker->blockers to get the best score from the simulated result. Everything else is done.

[rampaging-poet]

Glad to hear this is being worked on. I've been testing matchups against token decks, and the AI is this close to piloting them well.

@jeffwadsworth, do you mind if I implement something like JayDi85's suggestion as a stop-gap solution while you sort out your all-combinations logic? I think some basic sorting and matching could go a long way in the most common cases.

[jeffwadsworth]

Sure, but that really is half-baked. You have to consider special abilities of cards like Deathtouch, Trample, not to mention any other effects in play, etc. Power/Toughness is about 5% of the problem.

[rampaging-poet]

I agree. Many abilities and effects could change the outcome beyond straight power vs life total checks. Afflict, Double Strike, Infect, Trample (especially Trample + Deathtouch), and various ongoing effects like Protection of the Hekma could all change the math. A full simulation would be much, much better than the current rough guess we have now. (As an aside, the AI currently won't block 1/1 servos with Adorned Pouncer because its "will survive" approximation ignores First Strike and Double Strike).

That said, at least handling vanilla vs vanilla chump blocks is better than letting the AI mindlessly die to a Cryptic Serpent when it has three Sacred Cat tokens and an Anointer Priest to block with or whatever.

Speaking of Sacred Cat tokens, I'd better consider Lifelink here too. Lots to think about. I'll see where I get with it and submit a pull request.

[JayDi85]

Interesting article about MtG AI engine from Magic Duels developers: https://magic.wizards.com/en/articles/archive/duels-planeswalkers-all-about-ai-2014-02-13

[jeffwadsworth]

Yes, I remember that article. The all combinations idea is getting modified due to its high processing usage. Trying a more restricted approach.

[jeffwadsworth]

Removed an incorrect analysis of combat. Explanation below.

[emerald000]

Am I missing something or isn't Glissa supposed to live? 3 Pearled Unicorns are killed in the first damage step, so the last one only deals 2 damage to Glissa.

[emerald000]

I think you are mistaken about how Deathtouch and First Strike interact. Since Glissa has First Strike, only she will deal damage in the first combat damage step. She gets to deal 1 damage to each of Unicorn A, B and C. They die to SBA. Then in the second combat damage step, the remaining Unicorn D will deal 2 damage to Glissa so she stays alive.

[jeffwadsworth]

You are correct. http://tappedout.net/mtg-questions/first-strike-deathtouch-and-multiple-blockers-how-do-they-work/ I read my log incorrectly.

[hooptie45]

I've been wanting to try and apply OpenAI's deep learning to magic. I suspect that if we could get a stream(kafka, or JSON file log) of all the actions played by humans in real games, along with the resulting board state after each move, we'd be able feed it to an OpenAI as training data and build a xmage driver.

However it's unclear to me how you'd drive the game programmatically, or inspect the state of a game outside of the Mage client. The current system seems to be pretty tightly coupled to the UI, and the JBOSS network client make it hard to see exactly what is being sent so and from the server.

This might be an opportunity to expose a server REST API, and make a building an external driver more feasible.

Exposing a server API would also allow more more advanced, and more modern game clients; something I'd be very interested in helping to build; but I'm not very strong in JAVA server programming, so I'd need some help.

I've recently opened a feature request for JSON logging, which is sort of related: https://github.com/magefree/mage/issues/4515