X costs?

[DennisBergkamp]

Multikicker seems to work alright... we could probably use the same code for X costs. What do you guys think?

[Chris H.]

Multikicker seems to work alright...

`
I put together a test deck and it worked fine for the human. When I gave the same deck to the computer, well I guess that the AI part is still a work in progress.

[DennisBergkamp]

Ahh oops, I messed this up after my second update on the SVN. It should be fixed though for the AI if you add a "push(sa);" right after the while (in MagicStack.java) :

Code: Select all

else //computer
               {
                   while(ComputerUtil.canPayCost(ability)) ComputerUtil.playNoStack(ability);
                   push(sa);
               }

Anyway, I've been playing around with X costs, tested using Prosperity and it seems to work alright (both for AI and player).
The thing I'm more concerned about though, is that with X cost we should probably be using those Mana classes, currently I'm not doing this at all...

Also, we should probably be combining this with the existing keywords (spDrawCards, spDamageTgt, etc.).

[zerker2000]

Combining should be easy: just use card.setSVar("X", n), and write x for the number.

[DennisBergkamp]

Oh, that's good to know, I've added a separate int xManaCost, I guess I should just be using X.

[DennisBergkamp]

I'll just commit what I have so far... will convert to using keywords later.

[Mr.Chaos]

Call me crazy if you must, but I am happy to say I see a Hurricane on the horizon.
As a matter of fact, I even predict a serious Blaze coming this way!
And that is just the tip of the iceberg.

[zerker2000]

Eh? Iceberg? That shouldn't be hard at all actually; I do think that "Comes into play with counters" and "{cost}: add n TYPE counters" should be keyworded better though.

[apthaven]

Definitely will LURK this thread more often for updates regarding this.

X costs are going to make Forge even more awesome than it already is

[Huggybaby]

As a red/green player I'm really looking forward to this.

[juzamjedi]

I would be pretty thrilled to see a Fireball in my booster drafts. R/U draft decks are overpowered why not make them stronger

[DennisBergkamp]

Well, I sort of got this stuff working through some hacks. I don't think it's possible to use SVar directly, since I have to use some form of recursion (each time the X is increased by 1, when a mana source is used). So I still store the amount of X that's paid in a separate variable xManaCostPaid in Card.java.

The trickiest part is the AI, since determining the value of X is difficult... I currently just base it on ComputerUtil.getAvailableMana() - convertedManaCost of the card.
Then resolving is different again, since it needs to base the value of X on how much it actually paid (card.getXManaCostPaid()).

Anyway, at least what works so far is that Blaze can be coded like this:

Code: Select all

Blaze
X R
Sorcery
no text
spDamageTgtCP:X:Blaze deals X damage to target creature or player.
SVar:X:Count$xPaid

What doesn't work (yet) :

- spDamageTgtCP:X will still need a following description, since X in "deals X damage" can only be an int.
- No matter what the AI will target, it will attempt to spend a max amount of mana on X... if I play a Savannah Lions, the AI will hit it with a Blaze of 6 damage if it has 7 mana available. This will be tricky to get working correctly...

[Rob Cashwalker]

Don't worry about the description. I think it's just fine to use "X" in the description without exact numbers.

Did you have to hack the AI of spDamageTgt to know how much X would be before selecting a target? Or is the X chosen before the canPlayAI is called?

[DennisBergkamp]

I hacked xCount so it will return X used in getNumDamage in spDamageTgt for canPlayAI().
Then I added a getNumXDamage to spDamageTgt which is used by resolve() (and is based on how much was actually paid).

There might be a smarter way of doing this... but in either case, the way of obtaining X for the canPlayAI() and the resolve() are going to be different.

[Chris H.]

Adding the "push(sa);" did the trick. It was fun watching the computer use Multikicker.

I noticed something UI related and I am not an expert in this area.

While casting a Gnarlid Pack the Cancel button is the only active button and we can cancel the casting before the full mana cost of "1 G" is paid. Great.

Once the full mana cost is paid, MagicStack.java prompts us for the extra kicker mana cost. The cancel button remains the only active button. Would it be better and possible to switch over to the OK button being the only active button at this point?

I am not sure that the result would be worth the effort. It is just one of the things to consider as we implement X costs, particularly as it relates to something like Multikicker.