Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AI Never Chump-Blocks #4485

Open
rampaging-poet opened this issue Feb 5, 2018 · 15 comments
Open

AI Never Chump-Blocks #4485

rampaging-poet opened this issue Feb 5, 2018 · 15 comments
Labels

Comments

@rampaging-poet
Copy link

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
Copy link
Member

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
Copy link
Member

JayDi85 commented Feb 5, 2018

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

@JayDi85 JayDi85 added the AI label Feb 6, 2018
@jeffwadsworth
Copy link
Contributor

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
Copy link
Member

JayDi85 commented Feb 6, 2018

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
Copy link
Contributor

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

@rampaging-poet
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

rampaging-poet commented Feb 7, 2018

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
Copy link
Member

JayDi85 commented Feb 7, 2018

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
Copy link
Contributor

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

@jeffwadsworth
Copy link
Contributor

jeffwadsworth commented Feb 7, 2018

Removed an incorrect analysis of combat. Explanation below.

@emerald000
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

@hooptie45
Copy link
Contributor

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:
#4515

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants