Collectible Card Game Headquarters

Has someone found the function(s) the game uses to produce mana ?
I can't find a single vanilla card (created by Stainless Games that is) that produces mana...
Riiak perhaps ?

I've found 2 lands (SUNPETAL_GROVE_348517.XML and ROOTBOUND_CRAG_350182.XML) but they're not coded...

You can use this to produce mana per the vanilla version of the game.

Code: Select all

   <MANA_ABILITY>
      <COST type="TapSelf" />
      <PRODUCES amount="{G}" />
   </MANA_ABILITY>

I believe this is inherent to a basic land which is why you will not find this type of code on basic lands made by stainless. Sunpetal Grove and Rootbound Crag were added to the game for a challenge. They were never intended to work.

Thanks sweetLu, i've effectively seen that code in lands we made, and it must be the way Magic 2015 dual mana lands produce mana (if only we could open zed archives we would know...)

I've decided to recode all dual mana lands to make them completely compatible with the game engine and the AI, because the actual solution is not a correct one in my opinion.

Take a card like Boros Guildgate for example. What we are doing now is to check in player hand if a color of the first type is present, and default to the second type if not...

Code: Select all

<RESOLUTION_TIME_ACTION> local filter = ClearFilter() filter:SetZone( ZONE_HAND, EffectController() ) if filter:ChromaCount(COLOUR_RED) == 0 then LinkedDC():Set_Int( 0, 1 ) end </RESOLUTION_TIME_ACTION>

<CONTINUOUS_ACTION layer="6"> local colour = LinkedDC():Get_Int( 0 ) EffectSource():GetCurrentCharacteristics():GrantAbility(colour) </CONTINUOUS_ACTION>


That is far from correct as this is really a minority case, most of the time the player will have the 2 colors in his hand. With this code, the AI can't play a card like Boros Charm because it won't be aware that the gate has also white mana ability...

The problem is that it's easy for a human player to choose which color we want, but how can we simulate that for a computer player ? We know that the game engine is simulating all future states and evaluates the most favorable for it, so my idea is to take advantage of that and give it the 2 possible states, coding a separate hidden AI part for Boros Guildgate that does :

: Add to your mana pool.
: Add to your mana pool.

This way the computer can simulate the or easily and i think it will work far better when playing versus AI
I will try this now and make some tests.

logoliv wrote: : Add to your mana pool.
: Add to your mana pool.

This way the computer can simulate the or easily and i think it will work far better when playing versus AI
I will try this now and make some tests.

If that works, that would be awesome. It would add a new range of decks feasible as AI opponent. I don't use AI decks with dual lands to avoid the unfair advantage on the human side.

That does not work (it will allow the AI to play cards some cards for free). There are hosts of problems associated with how mana works in DotP. Unfortunately, there is no good solution for the AI. The most fair way to work for the AI would be to make the mana that a dual land produces change each main phase so that each colour would be available in the AI's turn. This change would also need to be independent for each instance so it could be possible to have both colours from different instances available at each point. This would also mean that as a dual land comes into play it would need to select a colour (possibly randomly) to allow for the AI to use that first phase it comes into play.

There are no mana functions built into the game engine that we can use as the game does not provide any way to generate mana. It fakes the mana generation by auto-tapping cards to meet a specified cost. Due to this, there is no mana pool and mana is never generated (even though conceptually generating mana in a pool is pretty easy, it could even be done with conditions if it were implemented by the engine).

If there were a good way to select and use mana in an approach that worked for both humans and the AI we would likely be using that instead of Manual Mana or other more cumbersome auto-tap solutions.

Magic 2015 has implemented all 10 guild gates, if only we could have a look inside zed archives...
I've perhaps found a solution, is there a way to delay the cost of an activated ability until it has resolved ?

Not a way that would leave everything else working correctly.

I've actually been intending for awhile to try and fix this issue. My idea was simply a function which feeds in all possible colors a card can produce, and then having the function return the color it should be producing and the land is set to that particular ability. The function would count all cards in hand, graveyard, and the top card of the library. The real problem would be the abilities on the field. While it's possible to check all of the cards in other zone, checking them on the battlefield would only work well for non-granted abilities, and that would require hard-coding every card with an activated ability which includes colored mana in the cost, which simply isn't feasible.

I'll probably just ignore the battlefield for the ai. I don't like that, but I don't know of any good solution to it.

For the other areas, it would be possible to check for cost changing cards, but I'd probably ignore those in favor of speed. Just count all cards which can currently be cast from all zones, the highest amount of each color of mana, test if it's possible to make the highest needed available for all colors, and if so, use that setup. If not, test for only the hand. If still not, reduce the highest one by one until it is (choosing the more common of the highest should they be tied, and randomly if none is more common). It would be one hell of a function to try and write, but if it works, it could help the AI immensely.

One of the main problems with the idea that I foresee is the limited ability to make multiple mana producers coordinate to produce the desired effect. My idea for that is to create a manager which does all of the testing and contains a chest of all mana producers for a given player. When the manager finds the best mana setup, it sets an int on each mana producer corresponding to the color it should be producing.

The lands themselves (well, their ObjectDCs) would contain the variables deciding which colors can be produced, and so you could still do everything necessary for granting abilities and so on. The real difficulty, in my opinion, will be remaking all of the cards currently in existence. However, on that front, a large majority of them, I imagine, could be made automatically. There would be difficulties mainly with OTHER abilities on the cards.

logoliv wrote:Magic 2015 has implemented all 10 guild gates, if only we could have a look inside zed archives...

We can look at some of the 2015 cards but it doesn't help since they changed the way the engine handles lands/mana.

I had completely forgotten that we had the Magic 2015 cards, thanks. By the way, i had a look at these : the 5 triple mana lands are missing and there's only 1 card that produces mana apart from lands (Darksteel Ingot).
It's a dead-end as it uses the same mana ability as dual lands, that's not implemented in Magic 2014 engine. No way to make it work

@Xander : what a mess it would be to code such a function
My idea was simpler : as producing double mana and paying a hybrid cost works well we could replace :

Code: Select all

<MANA_ABILITY>
  <PRODUCES amount="{R/W}" />
</MANA_ABILITY>


by something equivalent to :

Code: Select all

<MANA_ABILITY>
  <cost="{R/W}" />
  <PRODUCES amount="{R}{W}" />
</MANA_ABILITY>


but for that we must find a way to pay the cost after the mana has been produced...

I've gotten started. Only planning, so far, and I won't be done for a long time (I still don't have a lot of free time).

I haven't familiarized myself with exactly how Riiak's mana functions work, but once I do, I'll use those functions wherever possible (such as replacing CW_AM_MarkCanProduceMana with Riiak's function if it'll work for what I need, and I imagine it will).

RSN_ObjectDC():Get_Chest(CW_AM_CHEST_REGISTER)
Parent chest in a card's ObjectDC within which all other data is stored.
0 (int 0-5): Current colour
1 (chest): Producible colours
2 (chest): Extra costs

RSN_ObjectDC():Get_Chest(CW_AM_CHEST_REGISTER):Get_Chest(1)
A list of integers which determine if a given card is able to produce a given colour.
0 (int 0-1): Colourless
1 (int 0-1): White
2 (int 0-1): Blue
3 (int 0-1): Black
4 (int 0-1): Red
5 (int 0-1): Green

RSN_ObjectDC():Get_Chest(CW_AM_CHEST_REGISTER):Get_Chest(2)
A list of integers which determine if a given producible colour has extra costs associated.
The purpose of this chest is to prevent the code from telling a card to produce a colour which has other costs associated but still be able to allow cards such as Exotic Orchard to work.
0 (int 0-1): Colourless
1 (int 0-1): White
2 (int 0-1): Blue
3 (int 0-1): Black
4 (int 0-1): Red
5 (int 0-1): Green

On card:
CW_AM_MarkCanProduceColour("{W}{U}{B}{R}{G}{1}"}
EffectSource():GetCurrentCharacteristics():GrantAbility(RSN_ObjectDC():Get_Chest(CW_AM_CHEST_REGISTER):Get_Int(0))
Manager generation.
Activated ability to set produced colour, auto, or manual.
Auto mana abilities for all relevant colours.
Manual mana abilities for all relevant colours.


On manager:
Index mana producing permanents.
For each mana producing permanent, determine producible colours.
Create array from producible color sets.
Determine identical sets so they can be handled together.
Determine needed mana from hand, graveyard, and top of library if face-up (ignore top card if too difficult determine face-up status).
Remove from needed mana all producible mana from cards which produce only one color.
Determine which needed colours are available.
From available needed colours, determine maximum amount available per colour.
From available needed colours accounting for maximum available count, determine if full needed mana array can be produced from available mana producers.
If full needed mana array cannot be produced, restrict to hand and try again.
If full needed mana array cannot be produced, decrement highest needed colour count and try again until success.
When solution is achieved, for each mana producing permanent, pass that permanent's Colour to RSN_ObjectDC():Get_Chest(CW_AM_CHEST_REGISTER):Set_Int(0, Colour).

Even now I can see a few things which will need switched around and reworked slightly, but I'll do that as I go. (For instance, if I reduce the most expensive colour, causing the card that needs that number of that colour to be uncastable, I should make sure the other colours aren't now higher than necessary.
Example:
Hand: Brilliant Ultimatum, Cruel Ultimatum
Battlefield: 2 Boros Guildgate, 2 Golgari Guildgate, 3 Simic Guildgate.

It'll find it can't make 2W, 3U, 3B, and 2R, so it'll reduce U or B (let's assume the better outcome: B). It'll be left with 2W, 3U, 2B, and 2R. It still can't make that combination, so it reduces U, and still can't, so it reduces another one. No matter what it chooses, U is at less than 3 now, so when it finds a "solution", it won't allow either card to be cast. Work it such that it checks the maximum of each card before counting ANY of the card's mana, and it'll only try to produce 2W, 3U, and 2B, which it can do. A few other simple things like that need fixed, but it's at least a workable function. It'll be complicated, but doable.

For the colours a Manual Mana producer can produce you can look at the values in RSN_ObjectDC():Get_Chest(RSN_REGISTER_MARK_CAN_PRODUCE) directly or use RSN_GetCanProduceMana() to see if a specific colour can be produced. Note though that these are set per card rather than per ability and do not include if there are other costs associated with that production.

Good luck with your project... In my opinion, it isn't worth the effort and all the time you will spend on it.
1) You will pull down the lua interpreter to its knees and the game will be extremely slow (or not playable at all).
2) Are you ready to check and eventually modify every card in the 9000+ cards from CW ?
3) Keep in mind that Origins is out in july, with an upgraded engine that will offer much more possibilities and a better AI.

By the way, i had another replacement idea. Why not change :
: Add to your mana pool.
by something equivalent to :
: your next spell cost less to pay until the end of step.

That has really chance to work fine and is codable, and the AI will certainly be able to determine using the 2 possible states evaluation (cost less to pay / cost less to pay) which is the most favorable and allows it to play the best spell.
However i don't know if it takes into account the mana cost of card activated abilities...

We can't reduce the cost of abilities. It would also break cards with, say, sunburst, or anything that considers the mana spent to on it.

As for it being slow, that can help be alleviated by using a manager token which checks once per player per state based action. I'll try a static ability first, but if that's too slow, I can switch it and see if it work out.

As for the 9000+ cards, you haven't been around long enough to know this, but automation is my thing. It's what I do. That why the CW exists in the first place, because I found a way to automate the entire process. I can set up a program to code all typical mana abilities. It won't work for cards with extra costs, but I don't want it to work for those. They would have to be manual mana abilities anyway, and that just means leaving them alone.

As for Origins, you're right that it comes out soon and will probably have much better handling of mana than 2014. But how long has 2015 been out and we still can't mod it? I'm not going to stop modding 2014 just because we might be able to mod with a more powerful engine soon. If it turns out we can, then I might drop the project.

@Riiak: The functions I was considering making would also be per card rather than per ability. Some things I wanted to ask you about if you happen to know off the top of your head. 1: To the best of my knowledge, there should be any problem with having a manual mana ability and an auto tap ability on the same card unless the manual ability has a cost which can be paid (at least partially) with whatever the auto ability produces (and that they both require something that can only be done once, such as tapping). Is that right?
2: What about granted abilities (granted from other cards). I don't recall seeing anyone complain about bugs when some auto-tapland (such as a basic Plains) is enchanted with, say, Caribou Range. This would be uncommon with land because there aren't many Enchant Lands out there, and even fewer with tap abilities that require mana. But there are a good number that enchant creatures, and there are plenty of auto-tap creatures out there. If you're not sure, I guess I'll just have to test it. The thing is, I don't know that there's anything to really do about it even if it is a problem.

Xander9009 wrote:@Riiak: The functions I was considering making would also be per card rather than per ability. Some things I wanted to ask you about if you happen to know off the top of your head. 1: To the best of my knowledge, there should be any problem with having a manual mana ability and an auto tap ability on the same card unless the manual ability has a cost which can be paid (at least partially) with whatever the auto ability produces (and that they both require something that can only be done once, such as tapping). Is that right?

The only conflicts with an auto-tap ability and other abilities on the card (including Manual Mana abilities) is with costs paid for extra ability such as with a mana cost of at least or mana that the auto-tap ability produces. Though this can usually be overcome with changing the availability to only be available when the cost plus the mana produced by the auto-tap is available.

Xander9009 wrote:2: What about granted abilities (granted from other cards). I don't recall seeing anyone complain about bugs when some auto-tapland (such as a basic Plains) is enchanted with, say, Caribou Range. This would be uncommon with land because there aren't many Enchant Lands out there, and even fewer with tap abilities that require mana. But there are a good number that enchant creatures, and there are plenty of auto-tap creatures out there. If you're not sure, I guess I'll just have to test it. The thing is, I don't know that there's anything to really do about it even if it is a problem.

Granted abilities suffer from the same issues as innate abilities when dealing with auto-tapping. The problem with these is that they can't be compensated for by changing the availability because you have no idea what the card can produce because the ability could be granted to virtually any card.