MArcomage

T.A.S. Workshop, Rare 11/11/11
Swift Durable
If resources >= cost of selected card in hand, pay that cost, copy the card's effects that are not selection, summoning, keyword, or production, then discard it.


Unfortunately, the game system does not support copying another card's effects.

But if it did, you could (nearly) reduce the text to "play the targeted card in hand."

I went and puttered around the trac source, and eventually found something that the comments make sound like the right thing.
https://netvor.tk/trac/arcomage/browser/dev/inc_refactor/core/Db/Game.php#L707
It looks kinda like you could actually copy a function very much like that for the card effect, except instead get it to disable targeting, use the chosen card instead of $card, then after that override the stuff involved with summon/production (lack of keyword auto-handled!); if so, there would be a bunch of bugs, probably involving it getting confused about which card position should be used for what, but they seem fixable without horrible hacks.

Also, whether I can use "play the targeted card in hand" would depend on exact implementation! Maybe summoning can be allowed to make the card dangerous to play sometimes (cause it would get rid of itself)? Or maybe it doesn't need to be that way...I was thinking that for Conscript army, Far Sight and other similar card position stuff, it would be using the position of the Workshop instead of the chosen card, but that was just an odd assumption.

Edit: Somehow forgot one of the blocked things.

Implementation of such card effect would be unsystematic and would introduce new problems (currently the system does not understand card effect types). Additionally, such card effect is not transparent from the player's perspective as well.

While card ideas with mentioned effect sounds cool, overall it's not worth the trouble.

On the other hand I was considering dividing card effects into two groups:

- basic
- advanced

Basic card effects change directly game attributes (+Tower, +Wall...) and advanced do whatever they need to do (custom code). Currently, both types are handled by custom code, which is not necessary. Basic effects could be handled without the need of custom code.

Let's look at one example:

<card id="22">
<name>Master bricklayer</name>
<class>Uncommon</class>
<cost>
<bricks>9</bricks>
</cost>
<level>3</level>
<effect><![CDATA[Quarry: +1]]></effect>
<code><![CDATA[$mydata->Quarry+= 1;]]></code>
<created>2006-05-01</created>
<modified>2006-05-01</modified>
</card>

As you can see, quarry increase is mentioned twice. After the change it could look like this:

<card id="22">
<name>Master bricklayer</name>
<class>Uncommon</class>
<cost>
<bricks>9</bricks>
</cost>
<quarry>+1</quarry>
<level>3</level>
<effect></effect>
<code></code>
<created>2006-05-01</created>
<modified>2006-05-01</modified>
</card>

This change removes some redundancy as card texts for basic effects can be automatically generated and thus it is not necessary to have card effect mentioned both in code and text.

After this change I think it should be reasonable to have card effects that copy basic effects of other cards, because the system would understand basic card effects.

I guess that would be an ok piece of code-cleanup. It's largely unimportant or bad for this though; it already wouldn't be hard to have a card that searches for attack/castle/stock/facilities changes which aren't in conditionals of some kind.

Anyway, I don't know what "unsystematic" means in this context, since it shouldn't be different from any other metacode; I'm not yet sure why it would matter that the system currently doesn't understand it; transparency to the player is based on the simplicity of an accurate description, instead of the simplicity of thecode; and questions of something being worth the trouble make me wonder "why is any of this game stuff worth the trouble?".
So you know what? I'm going to see about converting the subversion repository to my local git. You don't need to answer this time.

By "System does not understand" I mean the fact that card effect is currently arbitrary piece of code. Sure, you could technically put anything in there and it would work (extract target card code and run eval()), but I would like to abandon this approach as I mentioned above (not to mention we had to handle the case when both played card and target card would have such copy-card effect). By moving the card effect to card attributes the system will no longer be executing arbitrary code, but rather understanding what the card is supposed to do.

Anyway, my general idea is that even though I have the means to put any code in the card, I don't want to put things that are out of context of the specific card. It's not a technical limitation, but rather a design decision. It's the same reason why we don't support cards with dynamically changing cost.

"transparency to the player is based on the simplicity of an accurate description, instead of the simplicity of the code"

We had several instances where it was actually easier for the players to look directly at the card code to understand how the card works. In such cases the description of the card could give you the general idea, but if you want to gain maximum value of the card you really need to understand it down to the small details. However, explaining these details in the description is unnecessary for most of the players. I try to avoid the addition of such cards.

"I'm going to see about converting the subversion repository to my local git"

I also use Git on other projects, this project has SVN for historical reasons. Git supports the import of SVN repository, so it shouldn't be a problem.