Restricted use mana

[ArsenalNut]

Well, I must admit that after another couple of experiments I understood that - for the moment - the ManaPool does not need to be absolutely rewritten.
Instead, I achieved the functionality with some minor code inside the Mana class and a very little modification at the ManaPool class.
I haven't tested the code enough to say it's ready, but finally it allows cards like Grand Architect to work as expected.

Thanks for the branch. How can I share the code with other programmers without impacting on the actual code in the svn?

Thank you,
Fabio

Switching your project to use a branch is fairly simple but dealing with modified code into an existing branch can be a hassle (mostly in making sure all the version line up correctly). It may be easier to create a new branch with your modified workspace as the starting point. If you want to post a patch relative to the current trunk head revision, I can get your code changes integrated into a branch you can work with.

[FabioFLX]

Switching your project to use a branch is fairly simple but dealing with modified code into an existing branch can be a hassle (mostly in making sure all the version line up correctly). It may be easier to create a new branch with your modified workspace as the starting point. If you want to post a patch relative to the current trunk head revision, I can get your code changes integrated into a branch you can work with.

Ok, thanks.
Tomorrow I will continue working on the project.
I will share my code with you as soon as possible, maybe tomorrow itself.

See you!

[Max mtg]

I got the idea how the ManaCost class works!
It keeps the mana yet to pay and decides where to spend mana from a source. I can convert it to use my shards instead of a variety of classes!

Will commit into the branch then.

[Max mtg]

I have commited (into the aforementioned branch @15547) a change that simplifies the rules for mana filtering to cast a spell or ability. Old mana classes had incapsulted priority checks, code to check if certain mana can pay for this ManaPart and paid/unpaid flag inside.
The new ManaCostShard represents just an symbol in the card manacost - it has no other logics inside. So the decisions on which manasymbol to pay for first is taken by the controller class now (ManaCost in our case)

I removed the manapart family of classes and placed the ManaCostShard class to forge.card.mana package. Anyone who is about to introduce restrictions on mana usage won't have to deal with ugly manaparts anymore.

This should have been done long ago, but had no good chance till now (when I got insight on how the mana system works). I sincerely hope that this change will make the deploying of mana restrictions simplier.

[ArsenalNut]

Hey Max,

Is there a particular reason that you renamed the Mana class to ManaPaid? Functionally you didn't really change anything. Conceptually, it seems odd that the ManaPool now contains ManaPaid objects instead of just Mana objects waiting to be used. If the change was for clarity, I personally I find harder to read the code now.

[FabioFLX]

To simplify all of my work on the new pool I created a new ManaRestricted class that is stored into an ArrayList of the Mana class.

When a card with a mana ability has certain specific params (for example $UseOnlyForType) they are stored in this array.

As today, what I done is that every time a SpellAbility ask for mana at subtractOne(), this ask to a new getManaFrom() that is able to check for restrictions in the ManaRestricted array I described before.

This seems to allow the functinality, but of course it still needs strong testing.

See you,
Fabio

[Max mtg]

Hey Max,

Is there a particular reason that you renamed the Mana class to ManaPaid? Functionally you didn't really change anything. Conceptually, it seems odd that the ManaPool now contains ManaPaid objects instead of just Mana objects waiting to be used. If the change was for clarity, I personally I find harder to read the code now.

It was exactly for clarity. I needed this to reengineer ManaCost. 'Mana' is too common to describe the entity (piece-of-mana-that-can-be-spent). Although I've renamed the class back, I suggest that someone finds a more specific name for it.

[moomarc]

Hey Max,

Is there a particular reason that you renamed the Mana class to ManaPaid? Functionally you didn't really change anything. Conceptually, it seems odd that the ManaPool now contains ManaPaid objects instead of just Mana objects waiting to be used. If the change was for clarity, I personally I find harder to read the code now.

It was exactly for clarity. I needed this to reengineer ManaCost. 'Mana' is too common to describe the entity (piece-of-mana-that-can-be-spent). Although I've renamed the class back, I suggest that someone finds a more specific name for it.

Some quick suggestions that might be suitable:
- ManaPooled (propably most descriptive grammatically and describes where it is)
- ManaAdded

[friarsol]

Hey Max,

Is there a particular reason that you renamed the Mana class to ManaPaid? Functionally you didn't really change anything. Conceptually, it seems odd that the ManaPool now contains ManaPaid objects instead of just Mana objects waiting to be used. If the change was for clarity, I personally I find harder to read the code now.

It was exactly for clarity. I needed this to reengineer ManaCost. 'Mana' is too common to describe the entity (piece-of-mana-that-can-be-spent). Although I've renamed the class back, I suggest that someone finds a more specific name for it.

Some quick suggestions that might be suitable:
- ManaPooled (propably most descriptive grammatically and describes where it is)
- ManaAdded

Mana that is Floating in a ManaPool could just be FloatingMana/ManaFloating, right?

[ArsenalNut]

Hey Max,

Is there a particular reason that you renamed the Mana class to ManaPaid? Functionally you didn't really change anything. Conceptually, it seems odd that the ManaPool now contains ManaPaid objects instead of just Mana objects waiting to be used. If the change was for clarity, I personally I find harder to read the code now.

It was exactly for clarity. I needed this to reengineer ManaCost. 'Mana' is too common to describe the entity (piece-of-mana-that-can-be-spent). Although I've renamed the class back, I suggest that someone finds a more specific name for it.

I disagree that the Mana class really even needs to be renamed. Mana is a fundamental object that gets produced when a Mana ability is activated and placed in the ManaPool. I believe the confusion with Mana and ManaCost is due to poor names for the containers that hold Mana objects and some of the names used in the function calls that subtract Mana from the ManaPool. For example, take the following line from ManaPool.subtractMana

Code: Select all

 m = this.subtractMultiple(sa, cost, m);


cost is a String array with the mana produced by the mana ability and not a "cost" at all.

Rewritten as

Code: Select all

manaCostLeftToPay = this.subtractMultiple(spellAbilityBeingPaidFor, manaToBeSubtracted, manaCostLeftToPay);


and it's pretty clear what the method is trying to do.

[ArsenalNut]

I checked in some code that implements checking a "RestrictValid" parameter in a Mana Ability. It is only implemented so far for the human player and only when directly tapping a source to pay a cost. I was looking at how the same code could be reused in the ManaPool to handle the case where the Mana already resides in the pool. Is there any reason a mana object couldn't reference the source Mana ability either in addition to or instead of the source card?

Edit: I added support so AI won't try to use restricted mana abilities for costs that don't meet the restrictions.

[FabioFLX]

Hi all,
my version of Forge allows AI to use restrictions in the mana abilities, because these are stored inside the ManaAbility and Mana classes.
When AI cycles the Spell_Ability's for avaiable mana these classes know the source and eventually apply saved restrictions.

The code is not yet complete but as now I'm having both the AI and the Human playing Grand Architect and Ancient Ziggurat without problems.

[silly freak]

Hey Max,

Is there a particular reason that you renamed the Mana class to ManaPaid? Functionally you didn't really change anything. Conceptually, it seems odd that the ManaPool now contains ManaPaid objects instead of just Mana objects waiting to be used. If the change was for clarity, I personally I find harder to read the code now.

It was exactly for clarity. I needed this to reengineer ManaCost. 'Mana' is too common to describe the entity (piece-of-mana-that-can-be-spent). Although I've renamed the class back, I suggest that someone finds a more specific name for it.

Do you use Mana as a name in another place, too? I think that Mana is a good name for what is contained in a Mana pool, but FloatingMana sounds ok too. In my program, I'm using Mana, ManaSymbol (with subclasses like Snow, Colored, Generic, Variable and Hybrid, which is recursive), ManaSequence (generic container for both costs and Mana producing abilities), ManaCost (contains the logic for a cost defined as a ManaSequence), just in case you're looking for names for something...

[friarsol]

Is there any reason a mana object couldn't reference the source Mana ability either in addition to or instead of the source card?

Nope, storing the generating Ability is fine, and the source card should be able to be gleaned through that if it's really necessary. I don't have the code with me, what do we use the source card for? Undoing costs?

[FabioFLX]

Is there any reason a mana object couldn't reference the source Mana ability either in addition to or instead of the source card?

Nope, storing the generating Ability is fine, and the source card should be able to be gleaned through that if it's really necessary. I don't have the code with me, what do we use the source card for? Undoing costs?

This is interesting.
My version of Mana, ManaPool and ManaAbility classes are using modified methods that know the requesting SpellAbility.
Mana restrictions of the cards are stored while processing the card params, so the A.I. only see the ManaAbility which are really playable for each SpellAbility.
For the Human player this is even easier because the application can avoid a restricted Mana to be used for a not valid SpellAbility.

CU
Fabio

---
News:
I created a fictional deck with Ancient Ziggurat, Grand Architect and Chimeric Mass cards only.
It seems working good: the A.I. uses the Ancient Ziggurat just to cast the Grand Architect and uses this to cast and activate the Chimeric Mass. Meanwhile human player can play these cards just in this way as well.

Can you tell me how can I share my provvisory code with you? I'm not familiar with SVN...