-How strong of an Attack is this?
-Do you ever want more than one?
-What other cards does it work well with?
I think this was mentioned in the Raid thread, but this card's -1 card token attack is stronger than Urchin's attack because the other player cannot choose what card they lose. It's more comparable to a Minion that doesn't cycle.
I think this was mentioned in the Raid thread, but this card's -1 card token attack is stronger than Urchin's attack because the other player cannot choose what card they lose. It's more comparable to a Minion that doesn't cycle.
That is true, though it can't be that much stronger.
I think this was mentioned in the Raid thread, but this card's -1 card token attack is stronger than Urchin's attack because the other player cannot choose what card they lose. It's more comparable to a Minion that doesn't cycle.
That is true, though it can't be that much stronger.
Losing a random card is a lot worse than losing your worst card. It can even be more painful than Militia. Urchin is weak because you almost always have junk to discard. In this case, even if you lose the worst card from your would-be 5 card hand, that junk is on top of your deck. Instead of Minion, maybe it helps to think of it as a mini Ghost Ship where you have no control over what to put back.
Relic's attack is far from weak, and in many decks the value of an attack that does not cost an action is huge. Relic is good in engines, but it helps TDBM even more, as it allows these decks to significantly slow down engines. Even one less card at the beginning of an engine could be enough to derail it once or twice, which in Dominion might be all you need.
Relic's attack is far from weak, and in many decks the value of an attack that does not cost an action is huge. Relic is good in engines, but it helps TDBM even more, as it allows these decks to significantly slow down engines. Even one less card at the beginning of an engine could be enough to derail it once or twice, which in Dominion might be all you need.
I should just probably put a disclaimer that I haven't played with any of these cards yet, and that these are my current impressions. I have the set, I played like one game with my friends with Adventures. I really wish Making Fun would get on that ball with Adventures.
Relic's attack is far from weak, and in many decks the value of an attack that does not cost an action is huge. Relic is good in engines, but it helps TDBM even more, as it allows these decks to significantly slow down engines. Even one less card at the beginning of an engine could be enough to derail it once or twice, which in Dominion might be all you need.
I should just probably put a disclaimer that I haven't played with any of these cards yet, and that these are my current impressions. I have the set, I played like one game with my friends with Adventures. I really wish Making Fun would get on that ball with Adventures.
Adventures is apparently releasing on MF by the end of the month. Just in time for Empires teasers!
Relic's attack is far from weak, and in many decks the value of an attack that does not cost an action is huge. Relic is good in engines, but it helps TDBM even more, as it allows these decks to significantly slow down engines. Even one less card at the beginning of an engine could be enough to derail it once or twice, which in Dominion might be all you need.
I should just probably put a disclaimer that I haven't played with any of these cards yet, and that these are my current impressions. I have the set, I played like one game with my friends with Adventures. I really wish Making Fun would get on that ball with Adventures.
Adventures is apparently releasing on MF by the end of the month. Just in time for Empires teasers!
A lot of people put Relic as "losing a random card out of five". I think more often than not, this is wrong. You already have five cards in hand when Relic hits, and most of the time, you will play some card that draws something during your turn.
Relic's attack is thus weaker as you get to play around it with some cards: Scrying Pool, Advisor etc. (How does -1 card interact with Draw-to-X by the way?) Then once you have drawn your deck, you can play some draw card to remove your token before the next cleanup.
(How does -1 card interact with Draw-to-X by the way?)
Does "drawing" a card when you have no cards left to draw actually remove the token? I'm guessing yes, but I don't know. The wiki doesn't say.
Does "drawing" a card when you have no cards left to draw actually remove the token? I'm guessing yes, but I don't know. The wiki doesn't say.
Let me just read Donald X's mind real quick
Does "drawing" a card when you have no cards left to draw actually remove the token? I'm guessing yes, but I don't know. The wiki doesn't say.Looking at the rulebook I am tentatively going with yes.
So the -1 Card token is like having a blank card that does nothing on top of your deck, that vanishes when you draw it? That seems like it would lead to the most intuitive rulings.But cards like Scrying Pool and Catacombs...
So the -1 Card token is like having a blank card that does nothing on top of your deck, that vanishes when you draw it? That seems like it would lead to the most intuitive rulings.But cards like Scrying Pool and Catacombs...
So the -1 Card token is like having a blank card that does nothing on top of your deck, that vanishes when you draw it? That seems like it would lead to the most intuitive rulings.But cards like Scrying Pool and Catacombs...
Oh yeah...it has to not be there for any non-drawing effects that could interact with the top of your deck.
So the -1 Card token is like having a blank card that does nothing on top of your deck, that vanishes when you draw it? That seems like it would lead to the most intuitive rulings.But cards like Scrying Pool and Catacombs...
Oh yeah...it has to not be there for any non-drawing effects that could interact with the top of your deck.
Interestingly, choosing to "take the top 3" with Catacombs, even with an empty deck, will leave the token there, but choosing "discard, then +3 Cards" will remove it.
So the -1 Card token is like having a blank card that does nothing on top of your deck, that vanishes when you draw it? That seems like it would lead to the most intuitive rulings.But cards like Scrying Pool and Catacombs...
Oh yeah...it has to not be there for any non-drawing effects that could interact with the top of your deck.
Interestingly, choosing to "take the top 3" with Catacombs, even with an empty deck, will leave the token there, but choosing "discard, then +3 Cards" will remove it.
Can Donald confirm?
So the -1 Card token is like having a blank card that does nothing on top of your deck, that vanishes when you draw it? That seems like it would lead to the most intuitive rulings.But cards like Scrying Pool and Catacombs...
Oh yeah...it has to not be there for any non-drawing effects that could interact with the top of your deck.
Interestingly, choosing to "take the top 3" with Catacombs, even with an empty deck, will leave the token there, but choosing "discard, then +3 Cards" will remove it.
Can Donald confirm?
He doesn't need to; it's obviously true. In one case you're putting looked-at cards into your hand. In the other case you're drawing cards.
Pretty sure I know the answer to this, but... if you have 7 cards in hand with the -1 card token on deck, will playing Library remove the token? I would assume no. Though I'm not sure how this is very different from playing Smithy when your deck is empty...No, because Library doesn't try to draw you any cards there.
Pretty sure I know the answer to this, but... if you have 7 cards in hand with the -1 card token on deck, will playing Library remove the token? I would assume no. Though I'm not sure how this is very different from playing Smithy when your deck is empty...No, because Library doesn't try to draw you any cards there.
Pretty sure I know the answer to this, but... if you have 7 cards in hand with the -1 card token on deck, will playing Library remove the token? I would assume no. Though I'm not sure how this is very different from playing Smithy when your deck is empty...No, because Library doesn't try to draw you any cards there.
I'm thinking that the empty deck ruling is inconsistent with Trader rulings. If someone plays Witch while Curses are empty, you can't reveal a Trader to get a silver (right?). This is because "would gain" means "unless you reveal this card, you really will gain". So why doesn't "would draw" mean "unless you have this token, you really will draw"?
Pretty sure I know the answer to this, but... if you have 7 cards in hand with the -1 card token on deck, will playing Library remove the token? I would assume no. Though I'm not sure how this is very different from playing Smithy when your deck is empty...No, because Library doesn't try to draw you any cards there.
I'm thinking that the empty deck ruling is inconsistent with Trader rulings. If someone plays Witch while Curses are empty, you can't reveal a Trader to get a silver (right?). This is because "would gain" means "unless you reveal this card, you really will gain". So why doesn't "would draw" mean "unless you have this token, you really will draw"?
Well, as has been mentioned, you also check if your discard pile is empty before actually giving up on drawing a card. And you checked the token before you check for cards in your discard.
Basically I'm looking for a consistent definition of "when you would do an action". But here we have it defined as "when you are instructed to do that action" in one place, and "when that action will take place if not for this intervening clause" in another.You can always instruct someone to draw a card. Drawing a card doesn't take a "parameter." It's just a sequence of instructions you carry out that (often) end up putting a card in your hand.
Witch:
for each other player P
P gains a card specified by name "Curse"
Player P gains a card specified by name N:
if there's a card C with name N visible in the supply
(currently, there can be no more than one such card)
player P gains specific card C
else
nothing happens
Player P gains specific card C:
fire a "P would gain C" event
if the event triggered something that vetoed the gain
nothing happens
else
move card C to the discard pile (I know it's not that simple)
fire a "P gains C" event
Trader:
while in P's hand, trigger on a "P would gain C" event:
if P wants to reveal Trader
reveal P's Trader
P gains a card specified by name "Silver"
veto the event
else
nothing happens
don't veto the event
--
Player P draws a card:
fire a "P would draw a card" event
if the event triggered something that vetoed the draw
nothing happens
return success (so Library et. al. will continue drawing)
else
if P's deck empty
reshuffle
if P's deck still empty
nothing happens
return failure (so Library can stop)
else
move top card of P's deck, C, into P's hand
return success (Library keeps going)
-1 Card Token:
while player P has his -1 Card Token, trigger on "P would draw a card" event:
P stops having his -1 Card Token
veto the event
Basically I'm looking for a consistent definition of "when you would do an action". But here we have it defined as "when you are instructed to do that action" in one place, and "when that action will take place if not for this intervening clause" in another.You can always instruct someone to draw a card. Drawing a card doesn't take a "parameter." It's just a sequence of instructions you carry out that (often) end up putting a card in your hand.
So instructing someone to draw a card always tries to carry out the draw instructions, triggering the -1 Card Token.
But in order to instruct someone to gain a card (at least as far as what Trader's looking for), you must ultimately tell them a specific card to gain. Gaining a card takes a "parameter." If you can't point someone to a specific card, you can't instruct them to gain it. When Witch tells someone to "gain a Curse," that's not doing the thing Trader is looking for (yet); that's just a shorthand for "if there's a card named Curse visible in the supply, gain that card." If there are no Curses, no actual gain instruction is issued.
So instructing someone to gain a Curse when Curses are empty doesn't trigger Trader because the instructions bail out before a gain is attempted.
Here's some pseudocode that describes how it works in my head:Code: [Select]Witch:
for each other player P
P gains a card specified by name "Curse"
Player P gains a card specified by name N:
if there's a card C with name N visible in the supply
(currently, there can be no more than one such card)
player P gains specific card C
else
nothing happens
Player P gains specific card C:
fire a "P would gain C" event
if the event triggered something that vetoed the gain
nothing happens
else
move card C to the discard pile (I know it's that simple)
fire a "P gains C" event
Trader:
while in P's hand, trigger on a "P would gain C" event:
if P wants to reveal Trader
reveal P's Trader
P gains a card specified by name "Silver"
veto the event
else
nothing happens
don't veto the event
--
Player P draws a card:
fire a "P would draw a card" event
if the event triggered something that vetoed the draw
nothing happens
return success (so Library et. al. will continue drawing)
else
if P's deck empty
reshuffle
if P's deck still empty
nothing happens
return failure (so Library can stop)
else
move top card of P's deck, C, into P's hand
return success (Library keeps going)
-1 Card Token:
while player P has his -1 Card Token, trigger on "P would draw a card" event:
P stops having his -1 Card Token
veto the event
public Card TopCard
{
get
{
if (this.DrawPile.Count = 0)
{
this.ShuffleDiscard();
}
if (this.DrawPile.Count = 0)
{
return null;
}
else
{
return this.DrawPile[0];
}
}
}
public void Draw()
{
Draw(this.TopCard);
}
public void Draw(Card cardToDraw)
{
if (cardToDraw == null)
{
return;
}
bool drawReplaced = Game.CheckWouldDrawTriggers();
if (!drawReplaced)
{
Deck.Remove(cardToDraw);
Hand.Add(cardToDraw);
}
}
This is a decent explanation, and it appeals to me as a programmer. I guess I would argue that "draw a card" takes a parameter as well, which happens now to always be the top card of your deck (separately there are instructions saying that anytime you need the top card of your deck, and your deck is empty, then you shuffle your discard). But your way seems valid as well. Here's my code for how draw works:Code: [Select]public Card TopCard
{
get
{
if (this.DrawPile.Count = 0)
{
this.ShuffleDiscard();
}
if (this.DrawPile.Count = 0)
{
return null;
}
else
{
return this.DrawPile[0];
}
}
}
public void Draw()
{
Draw(this.TopCard);
}
public void Draw(Card cardToDraw)
{
if (cardToDraw == null)
{
return;
}
bool drawReplaced = Game.CheckWouldDrawTriggers();
if (!drawReplaced)
{
Deck.Remove(cardToDraw);
Hand.Add(cardToDraw);
}
}
This is a decent explanation, and it appeals to me as a programmer. I guess I would argue that "draw a card" takes a parameter as well, which happens now to always be the top card of your deck (separately there are instructions saying that anytime you need the top card of your deck, and your deck is empty, then you shuffle your discard). But your way seems valid as well. Here's my code for how draw works:Code: [Select]public Card TopCard
{
get
{
if (this.DrawPile.Count = 0)
{
this.ShuffleDiscard();
}
if (this.DrawPile.Count = 0)
{
return null;
}
else
{
return this.DrawPile[0];
}
}
}
public void Draw()
{
Draw(this.TopCard);
}
public void Draw(Card cardToDraw)
{
if (cardToDraw == null)
{
return;
}
bool drawReplaced = Game.CheckWouldDrawTriggers();
if (!drawReplaced)
{
Deck.Remove(cardToDraw);
Hand.Add(cardToDraw);
}
}
But if the parameter is always the top card of your deck, it really shouldn't be a parameter. That's just making the code unnecessarily complicated.
public void Draw()
{
if (this.TopCard == null)
{
return;
}
bool drawReplaced = Game.CheckWouldDrawTriggers();
if (!drawReplaced)
{
Deck.Remove(this.TopCard);
Hand.Add(this.TopCard);
}
}
Do you expect to use that method with other dates though? If so, being ready for that is cool. If not, it should be easy enough to refactor in the future if needed.
Personally, I think the most logical way to go would be to code the -1 token as if it were a card on top of your deck, but only when drawing. It wouldn't count when revealing/looking or when in your hand (which is where it usually is). I believe that would handle all the interactions properly, and it would work even if you want to first check if there is a card to draw, because it would count as one.
I've always wondered if there could be a way to make this work with Minion. It'd be hard to set up, but the attack (a random 3 cards) could be very mean.
Minion, relic, spy, storyteller pinI've always wondered if there could be a way to make this work with Minion. It'd be hard to set up, but the attack (a random 3 cards) could be very mean.
It's like if they played Outpost.
There is no inconsistency here.Pretty sure I know the answer to this, but... if you have 7 cards in hand with the -1 card token on deck, will playing Library remove the token? I would assume no. Though I'm not sure how this is very different from playing Smithy when your deck is empty...No, because Library doesn't try to draw you any cards there.
I'm thinking that the empty deck ruling is inconsistent with Trader rulings. If someone plays Witch while Curses are empty, you can't reveal a Trader to get a silver (right?). This is because "would gain" means "unless you reveal this card, you really will gain". So why doesn't "would draw" mean "unless you have this token, you really will draw"?
There is no inconsistency here.Pretty sure I know the answer to this, but... if you have 7 cards in hand with the -1 card token on deck, will playing Library remove the token? I would assume no. Though I'm not sure how this is very different from playing Smithy when your deck is empty...No, because Library doesn't try to draw you any cards there.
I'm thinking that the empty deck ruling is inconsistent with Trader rulings. If someone plays Witch while Curses are empty, you can't reveal a Trader to get a silver (right?). This is because "would gain" means "unless you reveal this card, you really will gain". So why doesn't "would draw" mean "unless you have this token, you really will draw"?
When you would gain a card only happens when you're about to physically grab a card from the supply and put it in your discard pile.
When you would draw only happens when you're just about to physically move the top card from your deck into your hand.
Trader and the -1 Card tokens add preconditions to things that would otherwise happen, so if your draw deck is empty, -1 Card doesn't even trigger.
There is no inconsistency here.Pretty sure I know the answer to this, but... if you have 7 cards in hand with the -1 card token on deck, will playing Library remove the token? I would assume no. Though I'm not sure how this is very different from playing Smithy when your deck is empty...No, because Library doesn't try to draw you any cards there.
I'm thinking that the empty deck ruling is inconsistent with Trader rulings. If someone plays Witch while Curses are empty, you can't reveal a Trader to get a silver (right?). This is because "would gain" means "unless you reveal this card, you really will gain". So why doesn't "would draw" mean "unless you have this token, you really will draw"?
When you would gain a card only happens when you're about to physically grab a card from the supply and put it in your discard pile.
When you would draw only happens when you're just about to physically move the top card from your deck into your hand.
Trader and the -1 Card tokens add preconditions to things that would otherwise happen, so if your draw deck is empty, -1 Card doesn't even trigger.
The inconsistency is that he said the opposite (not with Library, but with somethin trying to draw +1 Card with an empty deck). Library doesn't instruct you to draw a card if you have a hand of >7 cards so it isn't even relevant to this discussion. I kind of prefer the ruling as is but I see where there could be some kind of inconsistency with Trader and the logic of when would gain.
It's more like, imagine a card that puts a token on top of the Curse pile that you remove instead of gaining a Curse. Sure, you can't reveal Trader if you just remove the token, but Witch telling you to gain a Curse should certainly remove that token even if the pile is empty. Let's say the token being on the Curse pile does something weird, I dunno.
We could treat the -1 Card Token as a card that is only there when drawing. In effect this means that the token actually triggers when you are instructed to draw a card, rather than when you would draw a card (using the same definition of "when you would" as on Trader and Possession). The actual token uses the "when you would" wording though, so yeah, "when you would" is not consistent with Trader then.
614.11. Some effects replace card draws. These effects are applied even if no cards could be drawn because there are no cards in the affected player’s library.
I guess I would argue that "draw a card" takes a parameter as well, which happens now to always be the top card of your deck (separately there are instructions saying that anytime you need the top card of your deck, and your deck is empty, then you shuffle your discard). But your way seems valid as well. Here's my code for how draw works:Code: [Select]public Card TopCard
{
get
{
if (this.DrawPile.Count = 0)
{
this.ShuffleDiscard();
}
if (this.DrawPile.Count = 0)
{
return null;
}
else
{
return this.DrawPile[0];
}
}
}
public void Draw()
{
Draw(this.TopCard);
}
public void Draw(Card cardToDraw)
{
if (cardToDraw == null)
{
return;
}
bool drawReplaced = Game.CheckWouldDrawTriggers();
if (!drawReplaced)
{
Deck.Remove(cardToDraw);
Hand.Add(cardToDraw);
}
}
If I were going to generalize the draw operation, say to support a card that has you draw from the bottom of your deck, I don't think I would call TopCard and pass the result to Draw. I think I would instead pass the TopCard method itself to Draw (as a callback of some sort) and let Draw call it as appropriate. Then, when the need arose, I could also pass it BottomCard sometimes.
In other words, I'd parameterize Draw with a behavior for determining a card, not with a pre-determined card. Mostly just because that seems more in line with how I'd expect drawing to work (and how the current rulings suggest it works).
And you would be able to pass MinusCardToken instead of TopCard whenever appropriate.
I don't think there's any actual inconsistency. I think there are two events that are being defined differently from one another (and they're allowed to be), but they're unfortunately being expressed using similar-looking phrases that are using the words in subtly different ways, and that's making people feel like the phrases should be exact analogs to one another when they don't need to be.
"Draw a card" is an event that "would happen" before you determine the card you're going to move (and thus before you might reshuffle).
"Gain" is an event that happens to "a card," and it only "would happen" after that card has been decided upon.
"When you would", as you note, is defined differently for "when you would gain" and "when you would draw".
Another thought about this. This is theoretical, but maybe useful. Imagine a card like "while this is in play, when you would draw a card, instead, +$1". Let's say you have this in play and play a Smithy with no cards left in your deck. Do you get +$3? According to your definiton, yes. But that's far from intuitive, and I would think that would be a pretty weird ruling.
That's not quite what I said. I think the "when you would" part means exactly the same thing in both cases.
they're unfortunately being expressed using similar-looking phrases that are using the words in subtly different ways, and that's making people feel like the phrases should be exact analogs to one another when they don't need to be.Aren't you referring to "when you would draw/gain" here? And saying those phrases use the words in subtly different ways?
In one case, X is an event of type "Draw." Events of type "Draw" carry information about the player doing the drawing, but they don't carry any information about what card they're going to pick, or whether they're going to be successful. They are fired before that information is available.
I guess there's an ordering of things?
Otherwise, there could be two things trying to happen at the same time when you would draw with an empty draw deck:
- Shuffle your discard pile
- Remove the -1 Card token
You get to choose the order.
That's not quite what I said. I think the "when you would" part means exactly the same thing in both cases.
You did write this:they're unfortunately being expressed using similar-looking phrases that are using the words in subtly different ways, and that's making people feel like the phrases should be exact analogs to one another when they don't need to be.Aren't you referring to "when you would draw/gain" here? And saying those phrases use the words in subtly different ways?
In one case, X is an event of type "Draw." Events of type "Draw" carry information about the player doing the drawing, but they don't carry any information about what card they're going to pick, or whether they're going to be successful. They are fired before that information is available.
I don't see any basis for that definition of "draw". And I already addressed that argument in this post (http://forum.dominionstrategy.com/index.php?topic=14969.msg580743#msg580743): "Draw a card" per the rules means "put the top card of your deck into your hand". If there is no card in your deck, it fails just like "gain a Curse from supply" fails if there is no Curse in supply.
Actually from the rulebook: "the player immediately draws X number of cards from his Deck." (Implicitly it means from the top of your deck, I'm sure you agree.) So "draw" carries information about what card to draw.
I'm saying that the definition I gave (or a similar one) --- where Draw events are fired as soon as the instruction is given and the determination of which card to act on is made later, "inside" the draw operation --- seems like the definition that has been used to determine the current rulings.
There is only so much room on a token. The -1 Card token reduces how many cards you draw when told to draw cards. It doesn't put it like that on the token but that's what it does. It seems straightforward; I don't feel like it's baffling people.
Trader meanwhile was a mistake. It tries to catch an event at the point at which the only thing that could stop it from happening is Trader (then it turns out there are two of these things, he says for people who were hoping to speak up about Possession). If I had it to do again, and didn't just not do that reaction concept at all, I would probably go with something like "when you gain a card that isn't Silver, you may trash it, to gain a Silver." There were times when Trader was more like that; I guessed poorly as to what would be simplest.
Did anyone ask about Ironworks/Possession ever before Trader came out?No.
So let me get this straight, that is, your definition.
A "gain" effect has a parameter for which card to draw, but doesn't issue a gain command right away. First it carries out an "if", checking if the card is available. If it is, it issues a gain command, and "when would gain" effects are triggered.
There is no basis anywhere for assuming that there is an extra "if" baked into "gain" but not into "draw". Your only reason for making these assumptions is to make it fit your model of how things could work with no inconsistency, not because the assumptions are reasonable.
But in order to instruct someone to gain a card (at least as far as what Trader's looking for), you must ultimately tell them a specific card to gain. Gaining a card takes a "parameter." If you can't point someone to a specific card, you can't instruct them to gain it. When Witch tells someone to "gain a Curse," that's not doing the thing Trader is looking for (yet); that's just a shorthand for "if there's a card named Curse visible in the supply, gain that card." If there are no Curses, no actual gain instruction is issued.
So instructing someone to gain a Curse when Curses are empty doesn't trigger Trader because the instructions bail out before a gain is attempted.
There is only so much room on a token. The -1 Card token reduces how many cards you draw when told to draw cards. It doesn't put it like that on the token but that's what it does. It seems straightforward; I don't feel like it's baffling people.
Another question: I take it that when the token is on an empty deck, but you have cards in your discard, you remove the token without shuffling? Is this stated anywhere?
I'm confused. You seem to be contradicting this:
Player P gains specific card C:
fire a "P would gain C" event
if the event triggered something that vetoed the gain
nothing happens
else
move card C to the discard pile (I know it's not that simple)
fire a "P gains C" event
Player P gains a card specified by name N:
if there's a card C with name N visible in the supply
(currently, there can be no more than one such card)
player P gains specific card C
else
nothing happens
But in order to instruct someone to gain a card In order to call GainSpecificCard...
(at least as far as what Trader's looking for), (GainSpecificCard is the thing that fires a "p would gain c" event)
you must ultimately tell them a specific card to gain. GainSpecificCard takes a card parameter, so you can't call it without that parameter
Gaining a card takes a "parameter." Ditto.
If you can't point someone to a specific card, you can't instruct them to gain it. More ditto.
When Witch tells someone to "gain a Curse," The Witch card has this text. That corresponds to calling GainCardMatchingName with a "Curse" parameter.
that's not doing the thing Trader is looking for Trader is looking for the event that gets fired in GainSpecificCard. Witch is directly calling GainCardMatchingName, which does not fire that event
(yet); Of course, GainCardMatchingName can wind up calling GainSpecificCard, which will fire the event.
that's just a shorthand for "if there's a card named Curse visible in the supply, gain that card." That's, like, the entirety of GainCardMatchingName. EDIT: It performs the gain of the specific card decided upon by calling the lower-level GainSpecificCard, passing it that specific card.
If there are no Curses, no actual gain instruction is issued. If there are no Curses, the "else" branch of GainCardMatchingName gets taken. Nothing happens there.
So instructing someone to gain a Curse when Curses are empty doesn't trigger Trader because the instructions bail out before a gain is attempted. If GainCardMatchingName never calls GainSpecificCard because it took the "else" branch, then no event is ever fired because that only happens in GainSpecificCard.
I'm saying the gain instruction that takes a parameter for which specific card to gain That's GainSpecificCard. It's the one that takes that parameter.
absolutely does fire a "gain" event right away. That's the very first thing it does. That's the first line in GainSpecificCard.
The thing that carries out an "if" GainCardMatchingName would be an example of such a function. It has the "if" statement that bails out if it can't find any Curses.
is a higher-level instruction that does not have a parameter for which specific card to gain. It doesn't. It has a "name" parameter. You can imagine other high-level functions that might take a combination of cost ranges and types as parameters.
Its parameters would be a set of conditions deciding which cards are eligible to select In this case, the set of conditions are "Cards visible in the Supply named Curse."
(or maybe there's just one eligible and that's it). If there's more than one Curse visible in the Supply, something has gone wrong.
Another question: I take it that when the token is on an empty deck, but you have cards in your discard, you remove the token without shuffling? Is this stated anywhere?
Similarly if you have to draw one card, would have to shuffle to draw it, and have the -1 Card token, you don't shuffle.
So in my previous post I was referring to your definition of a "gain" instruction, like on Witch: "gains a Curse". That is, this is your high-level instruction, and it doesn't issue a gain command right away, unlike your high-level instruction for draw. That's the distinction that I don't think there is any basis for.Well, like you said earlier, I'm just making definitions that do what the rulings say. My only basis is the rulings that exist.
All gain instructions that let you choose a card to gain, have an implicit "choose" instruction first. The choose part is not really part of the gain instruction. (I can point you to the relevant ruling on this.)Agreed. The implicit "choose" would be in the high-level function. For example, there might be GainCardMatchingCostRange function that Workshop could use, and it would include a choice.
So all actual gain instructions have an explicit card as a parameter.Yes!
Workshop really says: "Choose a card costing up to $4. Gain it."Exactly.
But Witch just says: "Gain a Curse" (for each other player).I'm not sure what distinction you're making here. I'd say that it "really" says something like: "Select a/the Curse visible in the Supply. Gain it." Either way, I hope we agree that "gain a curse" ultimately means you do an actual (Trader-visible) gain on the specific card that's the Curse on top of the Curse pile, unless the Curse pile is empty, in which case no (Trader-visible) gain occurs.
You're right that a gain instruction first fires when-would-gain, before the actual gain. But that doesn't mean that the high-level part doesn't have the card as a parameter. Actually it does.I disagree.
Player P gains a card with (MIN <= cost <= MAX):
find all cards visible in the supply with (MIN <= cost <= MAX)
if any cards were found:
player P chooses a specific card C from them
player P gains specific card C # using GainSpecificCard(P, C)
else
nothing happens
A gain instruction always has a specific card in mind. Workshop doesn't let you choose an empty pile, because you have to choose a specific card, not a pile. (I can point you to the relevant ruling on this too.)We agree on this. That's consistent with the high-level instruction I just said Workshop might use. You choose a card from among the ones visible in the supply that are in the given price range. There's no way to select an empty pile; there's no way to select a pile at all.
So the high-level gain instruction, which comes after the choose instruction,No. The thing I'm calling the high-level instruction is the implicit choose instruction.
will have a specific card as a parameter.No. Again, you can't pass the chosen card as a parameter before it's been chosen.
For Witch it's the top Curse card in the Curse pile. For Workshop it's the specific chosen card. For Thief it's the specific trashed card.Correct, correct, and correct. But they don't get passed to the high-level instruction; they get passed to the low-level instruction, which is the one that takes a specific card as a parameter.
Similarly, a draw instruction references the top card of the player's deck.It references it internally, yes. Once it exists (and assuming it ever does exist).
So as far as I see, there is no difference between the gain and the draw instructions. Logically, they both first check if the specified card exists in the specified location;Yes, but gain checks if the specified card exists up in the implicit "choose," which we seemed to agree is not actually part of a (Trader-visible) gain instruction. By contrast, draw checks if the specified card exists as part of the (-1-Card-Token-visible) "draw_a_card" instruction.
then potentially fire "when-would" abilities;It happens in that order for gain.
then potentially move the card and fire "when" abilities (currently not existing for draw).Right.
No. Again, you can't pass the chosen card as a parameter before it's been chosen.You keep saying this, in different ways, but you fail to take into account that in my model, which was obviously the one I was talking about, the "choose" instruction comes first, so the card is already specified.
I'm not sure what distinction you're making here. I'd say that it "really" says something like: "Select a/the Curse visible in the Supply. Gain it."You not being sure about that distinction, is the reason you fail to understand my point. Only Workshop lets you choose. Witch already knows exactly which card to gain - the top card of the Curse pile. That's the instruction, independently of whether or not that card actually exists. Compare it with Upgrade telling you to gain a card based on the trashed card. In this case the specified card is the trashed card, independently of whether or not that card actually exists. That's the instruction. Then, when carrying it out, you check whether the card exists. If it doesn't, the instruction fails.
We already agree that there's an implicit "choose" that's not part of the actual gain. The high-level instruction is the thing that does that choosing. (That's the entire reason I make the distinction in the first place.)I actually said that the "choose" is not part of the actual gain, it's a separate (implicit) instruction that comes first. There is no choosing in Witch. Anyway, that's not the entire reason you made the distinction. We need the distinction because of "when-would-gain" coming first. And I agree with that part.
Draw {you, the top card, your deck}
Draw {you, the top card, your deck}
for each other player, Gain {the player, the top Curse card, the supply}
if Card is in FromLocation
fire When-would-gain abilities
if Card is in FromLocation and gain was not prevented
move Card from FromLocation to Player's discard pile
fire When-gain abilities
else
nothing happens
else
nothing happens
if Card is in FromLocation
fire When-would-draw abilities
if Card is in FromLocation and draw was not prevented
move Card from FromLocation to Player's hand
fire When-draw abilities (don't exist in the game)
else
nothing happens
else
nothing happens
Card = the top card
FromLocation = Player's deck
(etc...)
And the instruction on Witch would be: Draw {the player}Yes, but gain checks if the specified card exists up in the implicit "choose," which we seemed to agree is not actually part of a (Trader-visible) gain instruction. By contrast, draw checks if the specified card exists as part of the (-1-Card-Token-visible) "draw_a_card" instruction."Choose" (on Workshop) can end up referring to no card. So can the gain instruction on Witch - which I do not call "choose" but even if you do, it's the same (see above). So can a draw instruction, which is analogous to the gain instruction on Witch. It references a card in a specific location, which can end up not existing.
Drawing, I suppose, could have been defined either way. And it didn't really matter until Adventures. But if you had events on a low-level draw instruction, you'd have weird token interactions described above. And your hypothetical card wouldn't gain you $ on an empty deck. I think that would just seem wrong.
QuoteI'm not sure what distinction you're making here. I'd say that it "really" says something like: "Select a/the Curse visible in the Supply. Gain it."You not being sure about that distinction, is the reason you fail to understand my point. Only Workshop lets you choose. Witch already knows exactly which card to gain - the top card of the Curse pile. That's the instruction, independently of whether or not that card actually exists. Compare it with Upgrade telling you to gain a card based on the trashed card. In this case the specified card is the trashed card, independently of whether or not that card actually exists. That's the instruction. Then, when carrying it out, you check whether the card exists. If it doesn't, the instruction fails.
What I'm saying is that a gain instruction that references a card that is supposed to be in a specific location (the top of the Curse pile) is the same as a draw instruction that references a card that is supposed to be in a specific location (the top of your deck).
You say that you are making definitions to fit the ruling. I agree. I'm saying that there is no reason to define gain and draw your way, other than to shoehorn it into the ruling without having to acknowledge that "when you would" is defined inconsistently.
To me the opposite would seem wrong, and non-intuitive, especially knowing that when-would-gain doesn't do anything on an empty pile. And actually i don't think it would get you $ on an empty deck, as I mentioned. I don't think when-would-draw would be defined that way. I think this is just a matter of the -1 Card token having an unfortunate shorthand text, while really it's just a matter of viewing the token as a card when we're instructed to draw.
Well, Donald wrote: "There is only so much room on a token. The -1 Card token reduces how many cards you draw when told to draw cards. It doesn't put it like that on the token but that's what it does."I think this is just a matter of the -1 Card token having an unfortunate shorthand text, while really it's just a matter of viewing the token as a card when we're instructed to draw.Well, I completely disagree with all that, but it probably doesn't matter. We may never know.
EDIT: I think the thing that seems the most wrong to me about your model is the case where you have cards in your discard pile, but not in your deck. There, your model has you reshuffling before getting the +$. I can't imagine someone guessing that you're supposed to reshuffle for a result that doesn't involve the cards at all.I agree that that's the kind of thing that needs to be specified in a FAQ. (And as I said, I can't imagine someone guessing that you get +$ with no cards to draw.) It also comes back to the question posed by Davio: when is the reshuffle timed? The reshuffle happens when you actually need a card from your deck. Whether this is before or after "would draw" is not really defined. It could be that you "would draw" a card just because you have cards in your discard pile, although I agree that it seems like there should be a physical card on top of your deck before you can say that you "would draw". In any case, sometimes following the rules to their logical and consistent conclusion does get you weird results (like a Possessed player not getting a bonus from Ironworks).
Just for fun, would you expect something like this (http://magiccards.info/on/en/61.html) to work if you had no cards to draw?You already said that it does work. To me I would think that it doesn't, but I don't know the rules of Magic. Going by the rules of Dominion, I don't think it would work.
I agree they both involve "card specifiers." I'm just saying that the specifier has already been resolved into a specific card at the time a "would gain" event happens, but not at the time a "would draw" event happens. According to current rulings.There is no ruling on exactly what "when you would draw" means, only on how the -1 Card token is supposed to work. Donald has not said that the text on the token invokes a general "when you would draw" timing (as I said, I think he indicated the opposite). I'm saying that according to the ruling on the token, the "when you would draw" text on it, taken literally, is inconsistent with how "when you would gain" works. You're saying that it's not, because you're interpreting "draw" and "gain" differently (inconsistently!) so as to make those two when-woulds consistent.
I agree that both ways are equivalent. And whichever model you choose, it should be the same for draw as for gain. I can't see that you have replied to my arguments for this. If you have a high level instruction first evaluating whether "top Curse in the supply pile" exists, then you also have a high level instruction first evaluating whether "top card in player's deck" exists.I can't agree that, just because the definition of "gain" does not encompass the evaluation of a card specifier, the definition of "draw" cannot encompass the evaluation of a card specifier (or is inconsistent if it does). Why shouldn't it be possible to define events at different levels of abstraction?
I think defining "profit" in Dominion is possible without being inconsistent. (Although, part of your argument for why "draw" doesn't have a check for the existence of a card, was that it doesn't need it.
I'm not sure how having an event that does the same as another event can do, can fit into your idea of how Dominion works.)
Since profit is defined as a gain, the whole point of a "when you would" would be to change the gain, so therefore it would in practice instead be "when you would gain a card costing up to $3". That would be clearer and work consistently with normal "when you would gain" (Trader).
We both agree that your definition of "draw" and mine are possible. I just see no reason to define it your way, making an unnecessary distinction between "draw" and "gain". Similarly I see no reason to ever have "when you would profit", since it creates an unnecessary level of abstraction (as you put it) that makes it inconsistent with how Trader works.
I guess I just think that simpler is better (contrary to what it seems judging by this discussion :P), and in line with how Dominion usually is built.
Right, but that wouldn't be an equivalent definition. Now, those cards would trigger on Workshop; the original definition limited them to triggering on cards that specifically had you profit.Yes, that was my point. In practice the game would not have "when you would profit", for the reasons I stated, and that means it won't have that definition.
Your alternative is to say the -1 Card Token is a fake card that's there only while you're drawing*. So you have to define what "while you're drawing" means.
So you're actually using something like my definition of draw to make your fake token appear at the right time. You're just calling it "while you're drawing" instead of a draw event.I already said all this in previous posts in this thread. I just used a sloppy expression now - "when you're drawing".
Now, we could treat the -1 Card Token as a card that is only there when drawing. In effect this means that the token actually triggers when you are instructed to draw a card, rather than when you would draw a card (using the same definition of "when you would" as on Trader and Possession). The actual token uses the "when you would" wording though, so yeah, "when you would" is not consistent with Trader then.
I think this is just a matter of the -1 Card token having an unfortunate shorthand text, while really it's just a matter of viewing the token as a card when we're instructed to draw.
So... I guess it's subjective, but to me, it's much simpler to just define the "would draw" to happen at the specified point (thereby defining a "draw" event as something that always "would happen" when you're instructed to draw, which does make it different from a "gain" event) and then, when the token is there, remove it instead of carrying out the draw event. That way, I use the existing event concept, and I don't have to bother with defining or placing the null card. Or reinterpreting what the token says.You're not using the existing "event concept" that is already defined via "gain" though (which includes "would gain"), you're making up a new one.
You're not using the existing "event concept" that is already defined via "gain" though (which includes "would gain"), you're making up a new one.I'm not making up a new one because my event concept is not defined via gain. My concept of an event is just a sequence of instructions that you distinguish with a name and refer to in other instructions. You can trigger things when the event happens (just after the event's last instruction), and you can also trigger things when the event would happen (just before the event's first instruction) that possibly result in skipping the entirety of the event's instructions (meaning the event didn't happen).
You can trigger things when the event happens (just after the event's last instruction), and you can also trigger things when the event would happen (just before the event's first instruction) that possibly result in skipping the entirety of the event's instructions (meaning the event didn't happen).I agree with this, except as part of all movement events in Dominion, they first thing they do is to make sure the card exists. If not, the event fails outright. For a gain event, would-gain only triggers after that check is successful. And I say the same is true of all the movement events. Note that abilities like "when-would" and "when" always trigger on the actual events, not the shorthands. I think this model is self-consistent and aligned with how timing in Dominion actually works, and see no reason why any of the movement events would be different from each other when it comes to "when would".
Ok, let's go with calling them "events", as we have sometimes done in this thread, although "instructions" would be better probably.
I agree with this, except as part of all movement events in Dominion, they first thing they do is to make sure the card exists. If not, the event fails outright. For a gain event, would-gain only triggers after that check is successful.
And I say the same is true of all the movement events. Note that abilities like "when-would" and "when" always trigger on the actual events, not the shorthands.
I think this model is self-consistent and aligned with how timing in Dominion actually works, and see no reason why any of the movement events would be different from each other when it comes to "when would".
Did anyone ask about Ironworks/Possession ever before Trader came out?No.
Even if I called that whole sequence e.g. gain, it doesn't mean that gain refers to both the whole sequence and the actual movement in isolation, as you seem to think.Then I think we agree on that, at least. I thought we had agreed about that earlier, but it seemed like you were saying the opposite in your last post. I think the problem was I read "first" as "the first instruction of" when I guess you meant "just before."
Is an event like a matryoshka doll, that contains instructions which themselves contain more events?Yeah. Similar to how a programming language procedure is made of statements, some of which may be calls to other procedures. Or a mathematical function is composed of expressions, some of which may be the evaluation of other functions.
Yeah. Similar to how a programming language procedure is made of statements, some of which may be calls to other procedures. Or a mathematical function is composed of expressions, some of which may be the evaluation of other functions.I'm aware of this, and even (as I was actually thinking when I posted that semi-serious sentence), that a procedure can be recursive, i.e. call itself. But that was not what I meant. I meant that your definition of an event was both that it was at a higher level than an instruction and at a lower level, while you also say that these instructions are not events. So actually I have no idea what constitutes an event in your mind.
So actually I have no idea what constitutes an event in your mind.
Event:
handle "when-would"
if still happening:
carry out instructions comprising event
handle "when"
So there are only two events in Dominion then, gaining and drawing?
And you're now doing what you accused me of, having what "comprises the event" as a sub-part of the actual event! Your "boundaries" ("when-would" and "would") are inside the event.
I don't particularly care whether you call the trigger instructions part of the event or say they're like parentheses around it. That's irrelevant.That's what I've been saying, because you argue about the definiton of "event" instead of actually addressing the substance of my posts. I think you're just arguing to avoid conceding some points now. Too bad, because some of the stuff you write is interesting. I agree about your event handler, and have been thinking that it would be the best and most robust way to handle it, but you might be right that it would be overkill. (And I definitely think that should work the same for gain and trash. I mean, if you don't have any cards to trash, you can't say that you would have trashed a card, it's pretty obvious. But not to you I guess. Sigh.)
That's what I've been saying, because you argue about the definiton of "event" instead of actually addressing the substance of my posts.
(And I definitely think that should work the same for gain and trash. I mean, if you don't have any cards to trash, you can't say that you would have trashed a card, it's pretty obvious. But not to you I guess. Sigh.)
I think you're just arguing to avoid conceding some points now.
I do agree that that's obviously how it should work. I mean, I said that's the way I would define it.I'm sorry, I misread your last post to say the opposite.
Ok, here's a point conceded. If I were implementing "when you draw a card," I'd definitely expect to be using the "movement event" you describe for draw. Not the event that I proposed using for the -1 Card Token. "When you draw a card" should not happen on an empty deck.Did you mean to say "when you would draw a card" instead if "when you draw a card" here? Because there's never been any dispute about "when you draw a card" - of course that happens after you actually draw a card. If that's what you meant, I guess you're conceding that my hypothetical card would probably not produce $ on an empty deck.
If the token was described in terms of an event, maybe it would be better to refer to that event as "when you would attempt to draw." I recall the same thing had to happen in the Magic implementation: you needed two different events to handle drawing correctly.Yes, as I mentioned earlier, it would be something like "when you're instructed to draw a card".
*Gasp* I just realized that the -1 Card Token finally makes it so that rearranging your top cards when choosing to put them back with your Oracle is no longer pointless.