Talk:Set attribute

Should this be titled "Set attribute"? It sounds cleaner and more professional, but it would then include stuff like Bright-eyed Scout, Kirin Tor Mage, and Wilfred Fizzlebang, right? It would also takes up more space in the infoboxes.--Vanasbry000 (talk) 23:58, 1 May 2017 (UTC)

Perhaps "Set Attack", "Set Health", and "Set Cost" as three separate options? -- BigHugger (talk) 23:07, 1 May 2017 (UTC)

It's not a terrible idea. Though 14 of the 25 cards currently in here do both Attack and Health at the same time, so I don't think splitting up Attack and Health into separate pages is a perfect solution. A big part of why I wish I did "Set attribute" is that while a card like Humility only sets a single stat, I didn't go for the singular "Set stat" because it sounded so weird without context. As for "Set cost", there's already a lot of good stuff for it over at Mana cost and it really isn't that distinct from incremental changes in Cost. It might be a good idea to have the page be "Set attribute" and just use hiddentags to split them into different sections with Mana Cost at the bottom. I think I'll do that, thanks! --Vanasbry000 (talk) 23:58, 1 May 2017 (UTC)

Modular/multiple vs combined/single hiddentags

I noticed you're using a "modular" system here where each hiddentag applies to a single attribute, and you list multiple tags you want on the cards that have more than one. This will get all the cards listed, and it is how we've done tags/abilities which have different pages. However, this has the drawback of listing the multiple-tagged cards multiple times on this one page, which can add up to quite a lot of redundancy.

You actually already saw and applied the alternative with the targeting tags: you can use separate, single tags for each combination, e.g. target - character, target - enemy character, target - minion, target - enemy minion, target - friendly minion, etc. I don't think it's too many combinations here with only a few attributes, although I realize it's a pain to change the work you already did. If I recall correctly we only need:

• Attack, Health, Cost (individually)
• Attack and Health (or you could use something like "Set attribute - combat stats")
• Attack and Health and Cost (or "all minion stats")

I don't believe Set has anything else. For increment, you'd also need:

• Durability
• Attack and Durability (or "weapon stats")

Side note, I don't think we have an article for "Remove 1 durability from opponent's weapon" or "This loses 1 durability". I propose we simply include those in Increment attribute, since even though they're conceptually and contextually different, the mechanic is the same. There is no "max durability" for a weapon, so the "restore Health"/"modify Health" distinction does not apply.

- jerodast (talk) 03:15, 2 May 2017 (UTC)

Is it even necessary to treat "increasing"/"decreasing" an attribute separate from "setting" it? Setting is already not always to a strictly constant value, e.g. Divine Spirit, Scaled Nightmare, Inner Fire, etc. If "set attribute" can apply to setting atack to "current attack * 2", why can't it also be used to set durability to "current durability - 1"? -- BigHugger (talk) 11:22, 2 May 2017 (UTC)

I'm fine with that too. All these distinctions can be hiddentags under the Set attribute ability. I recommend still calling it Modify though, which is more open-ended as to whether it's a relative or absolute change, and matches Modify cost.

Speaking of Modify cost, there's a question whether we want to merge that "ability" or not. Strategically, changing costs is quite different from changing combat stats. On the other hand some of the mechanics of it may actually be the same, like Attack and Cost have an effective minimum of zero. And as I mentioned, increasing vs decreasing stats (or absolute-setting stats) is different strategically anyway. This one may require some drafting to see how much overlap there'd be in the combined version.

- jerodast (talk) 17:04, 2 May 2017 (UTC)

After leaving the suggestion of "Set", I was actually tempted to go back and add "Modify" as an equally neutral alternative. But I decided to see what others think first. So yeah, I'm okay with "Modify" as well.

My gut feeling is that merging "Modify cost" into a generic "Modify attribute" would have more benefits than drawbacks, but I must admit that I have not yet studied the pages enough to assess whether there would be too many special cases for Cost only.

(You use the word "ability" above, and I almost accidentally copied that. Note that all abilities are attributes, but not all attributes are abilities. Especially cost is not an ability. It is an attribute, or alternatively a property)

-- BigHugger (talk) 19:11, 2 May 2017 (UTC)

I meant the ability "Modify cost", including the verb. The attributes themselves are definitely not abilities, for sure.

Full disclosure: I think I'm the one who created Modify cost, so I'm a little biased toward that verb :) But it seems to have worked out, and it has identifiable advantages. - jerodast (talk) 19:25, 2 May 2017 (UTC)