Words that Cards.txt recognizes

[Chris H.]

It's been so long since I did those pumps.... Yeah, PTPump is the right syntax.

Thank you for the information. If I understand correctly, at this time we now have the simple form available:

Pump {cost = single mana symbol}: {effect = power/toughness increase}


Your PTPump, KPump and PTKPump are variants which would allow us to include more cards in Rares distribution. Additional variants of your ideas would allow even more cards.

A variant could allow for other non-mana costs: life, creatures, lands, discards, etc.

Another variant could allow the effects to be permanent rather than till end of turn.

I wonder if the code base would allow these new keyword variants to be used when creating new enchantments, instants and sorceries.

[frwololo]

Another variant could allow the effects to be permanent rather than till end of turn.

As far as I know there is no specific need for a variant permanent/vs end of turn:
Usually when it's a "pump" card and there is no cost to activate it, the "end of turn" or "permanent" thing only depends on the type of the card (enchantment VS sorcery/instant).
So basically the code can guess itself if it's permanent or not, 99% of the time (a specific case that gives problem is a cost of , depending on how this is implemented)
I'm not saying Forge is handling this correctly right now, but that it would be easier to have the code handle it rather than improve the parser here.

[Chris H.]

As far as I know there is no specific need for a variant permanent/vs end of turn:
Usually when it's a "pump" card and there is no cost to activate it, the "end of turn" or "permanent" thing only depends on the type of the card (enchantment VS sorcery/instant).

A variant which would allow you to target another card for the effect the pump would be very useful.

[mtgrares]

I added the "comes into play tapped" keyword to cards.txt, it has been awhile ago and I forgot to mention it.

[mtgrares]

I wonder if the code base would allow these new keyword variants to be used when creating new enchantments, instants and sorceries.

Nope. Cards.txt main goal was just hold the card text of a magic card, then later I realized that simple creatures could be added just using cards.txt and not having to code them with Java. Version 2 will hopefully let you add spells like Shock using cards.txt but version 1, definitely doesn't. (The problem with version 1 is that enchantments, instants and soceries usually require a target and creating the correctly target code is complicated. In version 1 I just cut and paste similar target code everywhere.)

[Rob Cashwalker]

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.

[GandoTheBard]

Hey Rob thanks for sharing that with us. I think I would have approached your task from a slightly different perspective. generally if I have to deal with a logic tree of any kind I try to separate it from the tasks it wants to do. I realize that this is more code intensive (and Im not in the least a java programmer) but it seems like

Code: Select all

If (case a) do this (moduleA())
else if (case b) do this (moduleB())
else do this (moduleDefault())

function moduleA {some code}
function moduleB {some code}
function moduleDefault {some code}

Seems clearer than putting all the code into those branches, particularly when the branches get longer and longer (and perhaps multiple claused.) Using comments to aid you this seems like an easier method to make the code more readable and also at the same time maybe more efficient to boot.

[frwololo]

I started a thread on an similar subject some time ago, you might want to get a look :
viewtopic.php?f=27&t=557

[mtgrares]

Trying to split the card code into reusable chunks is one of the main challenges when programming Magic. Currently I hardcode everything, it isn't a great solution but it sort of works. With version 2 I want to use plaintext to represent the cards because I can reuse the same Java code for Prodigal Sorcerer and Shock. And in the future if I need to change something, I just change the source code behind Prodigal Sorcerer and Shock and I don't have to change their plaintext versions.

I should be able to use the same targeting code and resolve code for both Prodigal Sorcerer and Shock.

Basically these plaintext cards just put the Oracle text into something that I think is machine readable and able to be parsed. A hundred different people would probably do these plaintext cards in a hundred different ways. The idea with these plaintext cards is to make the targeting and resolve code as generic as possible so it can be reused again and again. The resolve and targeting code can take simple arguments like nonblack or an integer.

p.s. I know I've mentioned this before so if this is redunant, sorry.


prodigal_pyromancer.txt
Prodigal Pyromancer
2 R
Creature Human Wizard
1/1

Activated Ability
Text: tap: Prodigal Pyromancer deals 1 damage to target creature or player.
Cost: tap
Resolve: damage target creature or player: 1


shock.txt
Shock
R
Instant

Spell
Text: Shock deals 2 damage to target creature or player.
Target: creature or player
Resolve: damage target creature or player: 2

[Chris H.]

Dennis recently added two new keywords to the recent beta distributions. The two new keywords are Exalted and Lifelink.

It looks like the list of valid keywords that cards.txt recognizes are:

Comes into play tapped.
Cycling:{mana cost}
Defender
Exalted
Fear
Flash
Flying
Forestwalk
Haste
Indestructible
Islandwalk
Lifelink
Mountainwalk
Plainswalk
Pump B: 1/1
Reach
RegenerateMe:{mana cost}
Shadow
Swampwalk
tap: add 1
tap: add B
tap: add G
tap: add R
tap: add U
tap: add W
This creature can block as though it had flying.
This creature can block only creatures with flying.
This creature cannot block
Trample
Unblockable
Vigilance

[DennisBergkamp]

I'm working on adding another: Remove three spore counters from this card: Put a 1/1 green Saproling creature token into play.

Messing around with Fungus / Thallid creatures, and almost all of them seem to have that ability.

[Chris H.]

I'm working on adding another: Remove three spore counters from this card: Put a 1/1 green Saproling creature token into play.

Messing around with Fungus / Thallid creatures, and almost all of them seem to have that ability.

Good job.

I have been reading the various messages in reference to Rob's version of the pump command. His work will add three more: PTPump, KPump and PTKPump.

[Rob Cashwalker]

I have been reading the various messages in reference to Rob's version of the pump command. His work will add three more: PTPump, KPump and PTKPump.

Actually, my work intends to replace the existing pump, for a total of 2 additional keywords...

[Chris H.]

Actually, my work intends to replace the existing pump, for a total of 2 additional keywords...

Thank you for the additional info. I had meant to ask you about that.

There are a number of existing cards in cards.txt that include the old Pump keyword. I realized this morning that a text editor could be used to search and replace the "Pump" keyword with the new "PTPump" keyword. The pump values that follow the older Pump keyword would be left untouched. This should help to ease the transition.

In a message topic elsewhere you mentioned

and I'm not sure if I implemented removal of a keyword like

"KPump W:-Defender"

but I probably should.

I'm wondering if you ever got around to implementing this in your code.

[Chris H.]

The list of keywords recognized as of MTG Forge 02-08-2009 are:

EDIT:

Some changes were recently made to this list. Please view the newer content below:
http://www.slightlymagic.net/forum/viewtopic.php?f=26&t=701&p=9012#p9012