CardFactory.java

The following quote is fairly important and I decided to split it off into it's own forum topic.
In message:
Re: spPumpTgt - Targeted Pump Spells
In message:
Re: spPumpTgt - Targeted Pump Spells
Rob Cashwalker wrote:The trick with multiple keywords, like spPumpTgt and Cycling is that the order of processing in CardFactory.java needs to be changed. The permanent ability keywords need to be first. Then the spell keywords need to be second. Then the "tack-on" keywords need to be processed last, possibly at the very end of CardFactory, allowing for "tack-ons" to be used for explicitly coded cards.
Cantrip isn't implemented like the others. It's checked upon resolution of any spell - if the card contains the keyword, then it just draws a card. Quite separately from any other card code.
The tricky part I've been trying to think about lately, is the Charms or Commands. Each individual ability of Chaos Charm for example, is something that we have keywords for. But we can't just do it like this:
Chaos Charm
R
Instant
Choose one - Destroy target Wall; or Chaos Charm deals 1 damage to target creature; or target creature gains haste until end of turn.
spDestroyTgt:Creature.Wall
spDamageC:1 (OK, we don't have creature-only damage yet, but it's easy enough)
spPumpTgt:Haste
Because each of the sp___ code blocks clears out the spell abilities of the card. (because all cards are assumed to be permanents, and given a default spell ability to be put into play).
So it would process spDestroyTgt (never mind the fact that the code needs the text formatted a certain way in order to extract the input dialog text) removing the default ability.
Then it would process the spDamageC ability, removing the spDestroyTgt abilty.
Then it would process the spPumpTgt ability, removing the spDamageC ability.
And that's just a rough example, because that's not the order of code blocks... spDamageC would be first, up by the spDamageCP and spDamageP blocks; then spDestroyTgt, and spPumpTgt would probably be inserted last when Dennis merges it.
I think the best way to handle this may be something like the following:
- Code: Select all
public boolean hasSpKeyword()
{
ArrayList k = card.getKeywords();
for (i = 0; i < k.length; i++)
if (k(i).startsWith("sp")
return true;
return false;
}Then remove the clearSpellAbility() from each individual code block. Oh, and make sure each one has a spell.setDescription().
- Code: Select all
if (hasSpKeyword)
{
card.clearSpellAbility();
if (shouldSpDamageCP)
{
...
}
if (shouldSpDamageP)
{
...
}
if (shouldSpDestroyTgt)
{
...
}
if (shouldSpPumpTgt)
{
...
}
...
etc
...
}
When you go to play the spell, the game will now present each spell option. This won't work for the Commands, which want two choices... but that's OK... for now.