spRegrowth

[Chris H.]

I'm considering making a keyword using the code from Regrowth. There are a number of similar cards that I may be able to add to forge via this type of keyword. And this would also give me some experience with the filtering methods.

I'm comparing the Regrowth code with the Raise Dead code and I notice some differences which may or not be important. The Regrowth code uses an "Input runtime = new Input()" and there are several other lines of code that I did not see in the Raise Dead code. There is an " Input_PayManaCost()" and a "setBeforePayMana(runtime)".

I think that it might be easiest for me to adapt the Raise Dead code and convert it to work with the Regrowth type of spells. Then again, my lack of knowledge may be preventing me from seeing that there is some important difference in the way Regrowth must be handled.

I realize that Rob, Dennis and Zerker is really busy and may not be able to respond right away to my inquiry. I can continue to look at the code for the moment, I may be able to figure out why these two spells look so different from one another.

[Rob Cashwalker]

I don't know why they're so different, but there should only be one keyword for this type of effect, therefore you have to figure out which code makes the most logical sense or can become the most generic.

When I start looking at some of these types of conversions, I look at the code for all the previous examples of code. When Rares wrote some of the original spells, he seems to have reinvented the wheel a couple times by doing the same effect slightly differently each time, whereas later on, a lot more copy and paste was used. (evident by the names of variables)

[Chris H.]

Dennis recently pointed out while he was modifying the token creating cards that he found one of them was coded in a different format than the others. I think that I am seeing a similar sort of situation with the Raise Dead, Regrowth and Resurrection spells. Rares may have had different creative inspirations at times and then coded similar cards using different coding techniques.

I think that I may be capable of re-using the Raise Dead keyword code and modify it to work for the other two similar spell mechanics. It would give us three separate but similar keywords to start with … at some point I may advance my skill base and then combine all three keywords into one.

[Marek14]

Dennis recently pointed out while he was modifying the token creating cards that he found one of them was coded in a different format than the others. I think that I am seeing a similar sort of situation with the Raise Dead, Regrowth and Resurrection spells. Rares may have had different creative inspirations at times and then coded similar cards using different coding techniques.

I think that I may be capable of re-using the Raise Dead keyword code and modify it to work for the other two similar spell mechanics. It would give us three separate but similar keywords to start with … at some point I may advance my skill base and then combine all three keywords into one.

BTW, when using Raise Dead effects in MTG Forge, I seem to remember that I got to choose what to return on resolution of the spell... but it's targeted, so target should be chosen on announcement. Will the new keyword allow that?

[Chris H.]

BTW, when using Raise Dead effects in MTG Forge, I seem to remember that I got to choose what to return on resolution of the spell... but it's targeted, so target should be chosen on announcement. Will the new keyword allow that?

`
The Raise Dead keyword is the same, it asks you to pay the mana and then select the target. The Regrowth spell asks you to select the target first and then asks you to pay the mana.

The Input runtime code in the Regrowth code may (?) be there to address your targeting and resolving issue. I am not familiar enough with the Java code at this time to be able to tell.

There is a line in the Regrowth code which states:

Code: Select all

spell.setBeforePayMana(runtime);

[Rob Cashwalker]

There should only be one keyword, no reason to make them separate, they all do the same basic thing.

And I believe they all should work more like Regrowth - target before pay mana. The setBeforePayMana passes an Input object that implements the target selection.

[mtgrares]

The normal flow of execution for a Magic card in MTG Forge is first you choose the target then pay for it. (Duh, I know.) The graveyard in MTG Forge is not shown to the user so the user can't easily target a card in the graveyard, so you have to pop up a little window. The "runtime" Input pops up a window that shows cards in the graveyard so the user can target them. ("runtime" is an Input which is "executed at runtime" and you can do sick, twisted things with it, see planeswalkers. Please note that Input.getMessage() is ALWAYS the first method that is called so that is why runtime only uses that one method.)

p.s.
At first I misunderstood the rules of Magic and I made the player pay for a spell BEFORE choosing the targets. You have to always review your ABCs.

[Chris H.]

@ Rares

Thank you. I am now trying to modify the Raise dead code to get it to use an Input to perform the target selection. It will take me a wile but I think I will figure it out.

@ Rob

I agree, but sometimes we have to cut back in order to have achievable goals.

[Rob Cashwalker]

Then you should revise your code to use the more correct implementation. The variable details are the same, only the logic needs to be transplanted.

[Chris H.]

Then you should revise your code to use the more correct implementation. The variable details are the same, only the logic needs to be transplanted.

`
Yeah, I'm working on it now.

I am having a hard time getting Eclipse to generate a serialVersionUID for the

Input runtime = new Input()

method. I kept getting an error, thankfully, I just got a successful serialVersionUID.

I wonder if the next version of Forge with the CardFactory divisions will help to alleviate these types of problems.

[frwololo]

For the keyword, Have you thought about something more general such as:
move target to destination

destination could be the following keywords: myHand, opponentHand, ownerHand, myBattlefield, etc...
target could be, in a first time, the same kind of keyword as destination, maybe becoming more complex with time.

in wagic we have:
moveTo(destination) target(card)

regrowth is written:
moveTo(myHand) target(*|myGraveyard)

This allows you to code one big class that handles moving cards from one zone of the game to the other, and you could code hundreds of cards with the same keyword. The only difficult point is "hidden" zones such as libraries and opponent's hand. These zones can probably be ignored in a first version of the algorithm.

[Rob Cashwalker]

But then the AI becomes confusing, as it needs to be ready to handle all combinations.
Returning a card from the graveyard to your hand would have a slightly different AI evaluation than returning it to play, but a vastly different AI compared to returning a creature from play to its owners hand. (Ignoring the usefulness of a Boomerang to save a creature from combat damage or something)

spRaiseDead is Chris' first major keyword, and as such, it did replace the code for a number of cards and introduced a number of new ones. That's what's more critical at the moment - replacing simple card code that has been repeatedly copied and pasted for each new card. If Regrowth had an almost identical return on investment, then we're still ahead.

I'm testing a new generalized abPump[Tgt] keyword that itself replaces 5 keywords. I can always come back to these keywords and clean them up into more generic blocks of code.

[frwololo]

The code for the AI wouldn't be that complex. You just hardcode each case, for example, "moving from the library to hand or inplay is usually a good thing". "Moving from inplay to the hand is usually a bad thing", etc... the AI can take its decisions based on that.

[Sloth]

I just noticed that the keyword spRaiseDead can already be used for spells that return a card of a specific type to your hand (and I added 4 of them). I think it would be easy to also allow multiple types (for Regrowth, Relearn, Nature's Spiral or Argivian Find).

I haven't looked into the issue of targeting first and then paying the cost. That might be pretty complicated.

Are you still working on this keyword Chris?

[Chris H.]

I just noticed that the keyword spRaiseDead can already be used for spells that return a card of a specific type to your hand (and I added 4 of them). I think it would be easy to also allow multiple types (for Regrowth, Relearn, Nature's Spiral or Argivian Find).

I haven't looked into the issue of targeting first and then paying the cost. That might be pretty complicated.

Are you still working on this keyword Chris?

`
I have gotten busy with other areas of our project. I keep meaning to get back to this one. spRaiseDead was my first attempt and it needs a lot of work. This in turn would give me experience for spRegrowth.

At some point a spMoveCardToZone keyword would combine several separate keywords into one. So, it would combine spRaiseDead with spRegrowth with spBounce with spResurrect with spExile with ...

Rob once said we should try to move forward in small baby steps. These giant do-all keywords sound nice but are beyond my own abilities. The AI might be different from one another. As you can see, I have wrestled with a number of issues.

I need to revisit spRaiseDead and implement the issue of targeting first and then paying the cost. I may have learned enough over the last year to be able to do it correctly this time around. I got close last year but had several errors that I could not resolve at that time.