AI mana pool

[Sloth]

My next plan is to add a mana pool for the AI. I think we had the consensus to put it in the player class. I want to make the following simple functions:

addToManaPool
getManaPool
removeFromManaPool

I don't plan to revolutionize the mana paying AI, but the AI should use the mana in the pool before using its mana producers. Then, at least triggered mana abilities will be avaiable for the AI: Mana Drain, Braid of Fire, Gauntlet of Might, Priest of Gix, ...

I think this is a first step and easy to pull off. But since it has to grow into something more complex I would like to hear your opinions first.

[slapshot5]

Will you still have a mana pool class, and will it still extend Card?

I'm guessing this won't change the way it's displayed at all, will it? Just that the AI will have a mana pool "card" in his battlefield.

-slapshot5

[Sloth]

Will you still have a mana pool class, and will it still extend Card?

I'm guessing this won't change the way it's displayed at all, will it? Just that the AI will have a mana pool "card" in his battlefield.

-slapshot5

I don't plan to change anything for the human. The AI doesn't need a "card" as the mana pool. The pool will be invisible (until we can agree on a representation).

[slapshot5]

Would the human ever want to see the AI's mana pool?

[juzamjedi]

It's unusual to care what is in the AI's mana pool. The typical decks where that matters are combo (ANT, Belcher, Mind's Desire, Dragonstorm, Prosbloom, and surely others I'm forgetting). At some point people will care about Mana Drain mana vs. their Spell Pierce / Daze. Overall I think it's not a big deal... I wouldn't expect AI to play combo decks, and for Mana Drain I could look at the spell I countered last turn.

[Sloth]

I can imagine getting information on the AI (including content of mana pool) by mousing over the AI life.

[Sloth]

Now that the mana pool is there, I will improve AI mana ability handling step by step:

1. Using mana abilities with additional (non-mana) costs (Vivid Crag, Abandoned Outpost, Horizon Canopy, ...) - DONE (note that the AI will waste limited resources)

2. Using mana abilities with subabilities (Underground River, Pristine Talisman, Rainbow Vale, ...)

3. Using mana abilities that produce more than one mana (Sol Ring, ...)

4. ???

5. Profit

[jeffwadsworth]

This is great news.

[slapshot5]

Can you look at making the compy not pay mana using lands it has animated? Might be tricky differentiating a land it has specifically animated using the AF vs. lands when they are all animated by a static animation (Kormus Bell, etc).

-slapshot5

[Sloth]

Can you look at making the compy not pay mana using lands it has animated? Might be tricky differentiating a land it has specifically animated using the AF vs. lands when they are all animated by a static animation (Kormus Bell, etc).

-slapshot5

I will look into this.


Step 2 has been made. There is a problem with lands producing more than 1 color, that can lead to inefficient mana usage (and can produce a bug with X costs). I'm working on it.

[Sloth]

Step 1 and 2 are now well supported with close to optimal AI decision making. I'm now trying to cleanup the code and I stumbled over determineLeftoverMana. This functions needs a lot of duplicate code and is prone to causing AI cost pay errors. Isn't it better to just iterate through the X starting at 0 and run canPlayCost with the complete cost until the first cost can't be paid?

If noone objects I will test to change this.

Can you look at making the compy not pay mana using lands it has animated? Might be tricky differentiating a land it has specifically animated using the AF vs. lands when they are all animated by a static animation (Kormus Bell, etc).

-slapshot5

This proves to be very tricky indeed. I improved this situation though, by restricting the usage of AF Animate to the Combat_Begin phase.

[alexAG76]

I need a method to fetch the ManaPool for a specific Player. Should I add a non-static getManaPool() method to Player or should I add a static one (*shudder*) to AllZone (as getManaPool(Player p) )? For the former, I can control the initialization when bootstrapping the game-state.

I need to make the code more species-agnostic for Minimax.

...
3. Using mana abilities that produce more than one mana (Sol Ring, ...)
4. ???
5. Profit

I couldn't stop laughing for at least 30 seconds... Underpants Gnomes!

[slapshot5]

I need a method to fetch the ManaPool for a specific Player. Should I add a non-static getManaPool() method to Player or should I add a static one (*shudder*) to AllZone (as getManaPool(Player p) )? For the former, I can control the initialization when bootstrapping the game-state.

I need to make the code more species-agnostic for Minimax.

...
3. Using mana abilities that produce more than one mana (Sol Ring, ...)
4. ???
5. Profit

I couldn't stop laughing for at least 30 seconds... Underpants Gnomes!

Put it in Player. I think the mana pool access methods are going there eventually anyway.
-slapshot5

[alexAG76]

Put [getManaPool()] in Player. I think the mana pool access methods are going there eventually anyway.

Done... but you won't see a commit-action for a good while. Patching won't work, either, because the patch to converge the game-state into a single class is, well, huge.

Thanks for the input, though.