Splitting CardFactory

[Rob Cashwalker]

Charms - Shouldn't need it. Each effect on a charm is a separate ability. Forge should by default pop up the list of spell descriptions. Whether or not it's needs to say specifically "Choose one" or whatever it does say (don't recall off the top of my head) isn't critical.
The critical part of making charms work, by keyword or otherwise, is that the spellAbility list is cleared only once before any abilities are added. One way we could do this easily is splitting the spEffect code and the abEffect code into their own CardFactory_ files. Then the spEffect file would have a single Clearing of the card's SpellAbilities.

[Chris H.]

The critical part of making charms work, by keyword or otherwise, is that the spellAbility list is cleared only once before any abilities are added. One way we could do this easily is splitting the spEffect code and the abEffect code into their own CardFactory_ files. Then the spEffect file would have a single Clearing of the card's SpellAbilities.

I also noticed while looking at the code for Funeral Charm that there was a 50% chance that the computer would or would not use one of the two included effects.

Otherwise, The computer would always use the first one, discard a card. The second effect to pump target creature would never get evaluated. Or am I just confused? I may not have had a chance to thoroughly examine how this would work.

[Rob Cashwalker]

Well, that's a different problem altogether, another good catch!

That may be a trickier behavior to correct. The AI needs some way of identifying multiple choice and to evaluate all choices before choosing.... Ugghh.

One thing I've been throwing around after playing with Count$ and Drawback$ and their handler functions... is to rewrite the keyword system again to build the abilities through a factory system like I know someone else suggested.... (maybe zerker?)

Then the charm (or command) is built as a wrapper around the three simple keyword-defined abilities that are generated dynamically. The wrapper ability's canPlayAI actually queries each sub-ability's canPlayAI and of the ones that return true, it picks one at random.

Another practical upshot of the keyword rewrite - you could actually give an ability (like regenerate) to a permanent dynamically.

[Chris H.]

Code: Select all

That may be a trickier behavior to correct. The AI needs some way of identifying multiple choice and to evaluate all choices before choosing.... Ugghh.

`
For a moment I considered including in my idea of a Charm keyword a function that would randomly re-order the other keywords. This way Funeral Charm would not always appear to have the discard keyword ahead of the two pump keywords. I am not sure if this approach would be practical or not. Just thinking out loud.

Code: Select all

One thing I've been throwing around after playing with Count$ and Drawback$ and their handler functions... is to rewrite the keyword system again to build the abilities through a factory system like I know someone else suggested.... (maybe zerker?)

Then the charm (or command) is built as a wrapper around the three simple keyword-defined abilities that are generated dynamically. The wrapper ability's canPlayAI actually queries each sub-ability's canPlayAI and of the ones that return true, it picks one at random.

Another practical upshot of the keyword rewrite - you could actually give an ability (like regenerate) to a permanent dynamically.

`
This sounds like more work but it would give us additional cards that we could cover with our keywords.

[zerker2000]

One thing I've been throwing around after playing with Count$ and Drawback$ and their handler functions... is to rewrite the keyword system again to build the abilities through a factory system like I know someone else suggested.... (maybe zerker?)

Yes, that was me, check page 2 of this thread(and I think I have a version of that class on svn as CardParser). I did get swamped with problems when I tried to get it working though .

EDIT: Adding keywords dynamically wouldn't be hard if there was a KeywordFactory, which housed all of the keyword parsing code and was used by invoking KeywordFactory.addKeyword(Card c, String keyword), which was called for each keyword in readCard(and defaulted to adding the keyword). Hmm: I feel like I am repeating myself...