I'm not sure if my pump code ever made it into the source.... That would explain not being able to utilize it with the fake card test.
Targeted pump was on my list of keywords to try, but as Forge points out, while there are MANY targeted abilities, they often get very restrictive in their targeting. So, out of let's say 100 total targeted pump abilities (not pump spells like
Giant Growth) maybe 33 of them would be generic enough, to target any creature. Of those, 11 of them would have simple, mana-only activation costs. I weigh the feasability of writing keyword code based on just how many cards it would apply to.
The simpler self-pumping abilities totalled over 100 cards, before Shards was released. That was worth the time and effort, which I really had done twice! The first time I coded it, I hard-coded the list of cards into a series of If statements for the mana cost, power boost, toughness boost and keyword boost. It was an impressive 400+ lines of "code", though it was really a lot less than that, because the If statements spanned multiple lines. Then Rares released back in september a build with his pump keyword, and I immediately saw the extreme benefit of using this format, however, I also saw the limit of his parsing code - it would only read a single character for the mana cost, power boost and toughness boost. So I tweaked his example for each of the three variants.
The problem with doing permanent pump effects, like
Glorious Anthem, let's say, is that Forge uses explicit code to constantly grow and shrink all cards' P/T. This is really almost how it should be, because it's a State-based effect, and the game state is checked CONSTANTLY. However as a computer game, it's complicated to do this, and processor-intensive. Try running the elf-pump deck with two Immaculates and two Gaea's anthem, and it brings the game to a crawl for my system. I don't like the way Rares wrote that code, and I thought I could attack it from a different direction, but ran into some difficulties when I realized that the information visible to this routine wasn't sufficient to process all cards in play generically. I thought I could loop through all cards in play, and check for a keyword representing "All creatures (you control) get [+/-]x/[+/-]y/[[+/-]keyword]". It's not that easy, and put it to the side, while I worked on the much simpler EOT pump effects.
There is a great difference between a keyword for the "Tim" ability ("T:Deal 1 Damage to target Creature or player") and a keyword to handle
Shock (Deals 2 Damage to target creature or player). I tried that too. Well, I should say I thought I could use the same code for self-pumping and
Giant Growth. All I should have done was check for the card type... but it resulted in very stringy code... the If statements spaced the code so far apart it was difficult to understand where I was at any given point, and I had just written it. This isn't good programming, and I couldn't figure out any better way other than separating the different variants by giving them different keywords. My goal is to provide enough building blocks of abilities that most cards could be strung together from pure keywords. Like the one that pumps and regenerates... which should work, I'll have to get some time to play with that....
Cycling is another example, because it's a mechanic that gets tacked onto a lot of otherwise, vanilla creatures, or simple spells. But like Comes into play tapped, lands don't seem to want to offer the option to the user because they don't get processed for SpellAbilities. another simple keyword I wanted to add was "Cantrip" - many spells offer to draw a card after they do some other effect. However, I was hoping that the single bit of code could work for instants and sorceries, AND creatures that draw a card when they come into play. Well, it's not that simple to make the distinction in code. Two different variants would be needed.
Posted: 07 Dec 2008, 18:27
, depending on how this is implemented)