Collectible Card Game Headquarters

Okay, another basic question(hopefully this will be discussed/solved as readily as the last one ):
Why exactly aren't X costs implemented? It seems like a matter of putting in a Card.X(and Activated_Ability.X) integer in, which is zero initially, gets asked right before you pay for the card(/Ability), and is later used to compute casting(/activation) cost/quantities for whatever effects it is used for. The only problem I can envision would be UI, and that shouldn't be too hard to put in (e.g. copy the "JOptionPane.showInputDialog" approach Rob took for making the Lotus).

I was looking at this much of Saturday.
I think the main reason is because there are certain parts of the card code which get created during initialization, including the PayManaCost stuff. I don't think you can change the mana cost of a card or ability in the middle of casting or playing it. It may be hackable if part of the spell ability resolve method directly interacts with some sort of Input_PayManaCost function, but it's just a guess. For example, Fireball - you pay the R to cast it. Then it asks you for a number. Then it dynamically creates a manaCost to be paid, which you can then use the usual mana sources for. (pool or cards with "tap: add _")
Fireball's a bad example, because of the extra burden of multiple targets... but it's a classic, primary X spell.

Rob Cashwalker wrote:I was looking at this much of Saturday.
I think the main reason is because there are certain parts of the card code which get created during initialization, including the PayManaCost stuff. I don't think you can change the mana cost of a card or ability in the middle of casting or playing it. It may be hackable if part of the spell ability resolve method directly interacts with some sort of Input_PayManaCost function, but it's just a guess. For example, Fireball - you pay the R to cast it. Then it asks you for a number. Then it dynamically creates a manaCost to be paid, which you can then use the usual mana sources for. (pool or cards with "tap: add _")

Erm no,(according to the rules) first you chose targets/{X} costs/modes/whether you're paying for kickers/buyback/etc., then you determine the total cast cost, and then you pay that cost.

So for Forge, that would mean scan the card for keywords that mean "<Cost>,Discard this Card:..."(e.g.cycling), and show a popup window with the options listed; then(assuming the player didn't select one of them, which is the kind of thing I'll leave out from now on) it should give you an apropriate selection popup if the ability has "choose <n>"(and a checkbox for splice if applicable),a dropdown for choosing creature/card types or colors,a checkbox area if the spell is arcane and there's at least one card with splice in hand, a number input line if the spell has an in its cost that isn't defined by the text(or "choose a number" in its textbox), more checkboxes for kickers and buyback, a menu to select alternative costs, a big complicated interface for convoke where you select creatures and which of their colors they reduce the cost by, and finally "toggle switches" for hybrid mana symbols(about which I did not know until I read that part of the rules today, and which can probably be implemented for e.g. reaper king).
Then forge should look through all the abilities being played and find any targets that need to be selected, show the ones that only have one possible choice, and let the player choose the rest.
Then the total casting cost is determined(which means technically you could have a card that says "Spells and abilities targeting <Card Name> cost 1 less to play" ), by taking the printed/alternative base cost, adding any 's or additional costs, and subtracting the cost-reduction effects. If a cost would be less than zero(e.g. having to pay -3BG or sacrifice -2 creatures), it is set to zero instead. That cost then becomes locked in, and we go on to actually paying it:
First we get to play mana abilities, just like before we started to play the spell. Then we have an interface from which you select permanents to tap/untap and sacrifice(with the number and type left on top in big bold letters, and of course the only creatures even in this window are ones of the right type), cards to discard/remove from game(in your graveyard), and any other costs. Then the spell resolves, and we get to try to make forge figure out what happens if there are any effects triggered by this.
Now that we have painstakingly gotten through the full formal format of playing a spell, there is somthing that I noticed:
a) Though this sounds insanely complicated,(to me) it feels like it would be much easier(to program at least) than what we have right now for cost paying. Definently if we strip it down to only the mana/selftap payment, which I think is what we have for forge right now(besides a few hacks).

Whoa... slow down there.

What the comprehensive rules have to say is one thing, but the architecture of MTGForge is another. Without an architecture re-write like you're proposing, the only way we might be able to handle an X spell is by hacking an ability to execute an additional Mana Payment after asking the user how much mana X shall be. Or possibly by hacking the existing mana payment system to allow X in the cost, and it should loop (and count total payment) until you click OK (which isn't enabled currently, until the whole cost has been paid) at which point, the payment routine sets the card's 'X' property... which hopefully the Ability's resolve method will be able to make use of. (too much stuff gets finalized and can't be changed)

The main problem with X spells is that the card's SpellAbility.resolve() doesn't know what X is. So you could add some method to the Card class like

Code: Select all

class Card
{
  private int manaPaidX;

  public void setManaPaidX(int n)
  {
    manaPaidX = n;
  }
  public int getManaPaidX()
  {
    return manaPaidX;
  }
}

class SpellAbility
{
  public void resolve()
  {
    int x = getSourceCard().getManaPaidX();
    //do x damage
  }
}

You would have to create another Input class to handle X costs, like Input_PayManaX which would also set
Card.setManaPaidX(). And then all X costed spells in CardFactory you would have to set,

Code: Select all

card.setBeforePayMana(new Input_PayManaX() )

This problem is similar to Ravnica block cards like Court Hussar which need to know what colored mana was used to pay for the card.

I think it would be better to have a card.x integer (and change all the implemented cards with "X, where X is" to use it. That way, we could just have Input_PayManaCost check for an X in the card's mana cost, and if it has one pop out an input before paying the rest of the cost, and then set the card's X and replace the one in the cost with that number.

Is there a particular reason ManaCost doesn't have sourceSpellAbility/getSourceSpellAbility()? If I am to make X costs, it would be helpful to have a way to get the restrictions on X ...

zerker2000 wrote:Is there a particular reason ManaCost doesn't have sourceSpellAbility/getSourceSpellAbility()? If I am to make X costs, it would be helpful to have a way to get the restrictions on X ...

Because it typically didn't matter what the source of the mana cost was. You might need to add one.

Rob Cashwalker wrote:

zerker2000 wrote:Is there a particular reason ManaCost doesn't have sourceSpellAbility/getSourceSpellAbility()? If I am to make X costs, it would be helpful to have a way to get the restrictions on X ...

Because it typically didn't matter what the source of the mana cost was. You might need to add one.

Hmm? Didn't you get sunburst working somehow?

We have sunburst? Since when?

Hmm, it seems you didn't, my bad. I thought I saw a sunburst card in the deck editor at some point... but when I checked cardFactory I couldn't find anything related to it .

It would be cool... keep in mind we only had counters figured out as of early spring.

I think it's great you've gotten a grasp of the code to the extent that you know what you need to change in order to make the Mana Pool truely functional. On the other hand, I think my hack for it works out well enough in most cases....

Another thing: if/when manaCost.getSourceSpellAbility is added in, it should theoretically be possible to make mana with restrictions, e.g. make a mana pool whose subtractMana checks whether the source is a creature/upkeep cost/other restriction, and whose clear() removes it from the interface as well as clears it (until its source puts it back in the game with new mana)... or something along these lines.

zerker2000 wrote:Another thing: if/when manaCost.getSourceSpellAbility is added in, it should theoretically be possible to make mana with restrictions, e.g. make a mana pool whose subtractMana checks whether the source is a creature/upkeep cost/other restriction, and whose clear() removes it from the interface as well as clears it (until its source puts it back in the game with new mana)... or something along these lines.

Yes but mana restrictions are part of the Input class like Input_PayManaCost. (And truthfully I don't have a real way to handle mana restrictions and it would be a little bit hacky.)

The Input class handles all of the mouse input such as clicking on a card or a player (and also clicking on the mana pool which is treated like a card unless I'm wrong). So if a spell required only black mana you would have to create a new class like Input_PayManaCost_Black which would only accept black mana. Unfortunately the computer doesn't use the input classes to pay for mana and would use any mana or you could just make the computer not play that spell, canPlayAI() return false.

zerker2000 wrote:Is there a particular reason ManaCost doesn't have sourceSpellAbility/getSourceSpellAbility()? If I am to make X costs, it would be helpful to have a way to get the restrictions on X ...

No not really, I haven't needed manaCost.getSourceSpellAbility() before.

And thinking about sunburst and other cards that care about what mana was used to pay for them, let me update the code that I suggested.

Code: Select all

class Card
{
  private String manaPaid;

  public void setManaPaid(String n)
  {
    manaPaid = n;
  }
  public String getManaPaid()
  {
    return manaPaid;
  }
}

class SpellAbility
{
  public void resolve()
  {
    String s = getSourceCard().getManaPaid();
    //process String s and do damage
  }
}

You could put the get/setManaPaid() methods in SpellAbility instead of Card, I don't know which place would be better. The get/setManaPaid() methods would be set by the input class that pays for the spell/ability like Input_PayManaCost.

mtgrares wrote:

zerker2000 wrote:Another thing: if/when manaCost.getSourceSpellAbility is added in, it should theoretically be possible to make mana with restrictions, e.g. make a mana pool whose subtractMana checks whether the source is a creature/upkeep cost/other restriction, and whose clear() removes it from the interface as well as clears it (until its source puts it back in the game with new mana)... or something along these lines.

Yes but mana restrictions are part of the Input class like Input_PayManaCost. (And truthfully I don't have a real way to handle mana restrictions and it would be a little bit hacky.)

Theoretically, all restrictions would be handled by Input_PayManaCostUtil.tapCard(), since that (in my recently written code) activates the ability and then subtracts the resulting mana from the mana pool, or if the card selected Is a manaPool, runs its subtractMana(manaCost) method. Therefore, it should be easy to make a manaPool.canPay(manaCost) method that is checked at the beginning of subtractMana, is always true for the default manaPool, however could be customised for new manaPool-s'(resulting from e.g. Thran Turbine -s) restrictions (e.g. !manaCost.getSourceAbility.isSpell or something).

The Input class handles all of the mouse input such as clicking on a card or a player (and also clicking on the mana pool which is treated like a card unless I'm wrong). So if a spell required only black mana you would have to create a new class like Input_PayManaCost_Black which would only accept black mana. Unfortunately the computer doesn't use the input classes to pay for mana and would use any mana or you could just make the computer not play that spell, canPlayAI() return false.

Yes, AI using mana abilities is something that needs to be put in. Definently at least figure out a way for AI to use simple mana abilities (the main bug is that with mana abilites, the AI can no longer cast anything ... where is the AI mana paying code anyways?).

zerker2000 wrote:Is there a particular reason ManaCost doesn't have sourceSpellAbility/getSourceSpellAbility()? If I am to make X costs, it would be helpful to have a way to get the restrictions on X ...

No not really, I haven't needed manaCost.getSourceSpellAbility() before.

And thinking about sunburst and other cards that care about what mana was used to pay for them, let me update the code that I suggested.

Code: Select all

class Card
{
  private String manaPaid;

  public void setManaPaid(String n)
  {
    manaPaid = n;
  }
  public String getManaPaid()
  {
    return manaPaid;
  }
}

class SpellAbility
{
  public void resolve()
  {
    String s = getSourceCard().getManaPaid();
    //process String s and do damage
  }
}

You could put the get/setManaPaid() methods in SpellAbility instead of Card, I don't know which place would be better. The get/setManaPaid() methods would be set by the input class that pays for the spell/ability like Input_PayManaCost.

Definently SpellAbility, since cards with multiple abilities that use e.g. are possible. For sunburst, you'd just need the spell that summons the creature/artifact to put counters on the card after it's summoned.