For Ways, it's the rules for Ways that change which instructions you're following, and for Enchantress, it's Enchantress itself.
Ok, I agree. Ways don't trigger directly; the rules for ways set up a delayed ability.
But the actual instructions you end up following, are instructions given on Enchantress ("+1 Card, +1 Action") and on the Way card. This is straight-forward.
They are
printed on those things, but they are not
given by those things. "Printed on" and "given by" need not be equivalent. You keep saying they have to be, and I keep saying they don't. I think you have to allow for them being different concepts in order the get a clean solution, here. I dunno; let's see if the script at the end of this post helps out at all.
3.1. With Ways/Enchantress, you're following the Way's/Enchantress's instructions (pretty sure everybody has agreed with this). Why does that count as something the Instance "does" anymore than Adventures tokens would?
You're following the instructions
printed on Way/Enchantress, but the Instance is what's
issuing the instructions.
Why does it count as something the instance does? Well, I guess it's because the instance is what was going to do
something all along, and the Way came along and changed what it was going to do. Why doesn't that apply to Adventures tokens? Because there, the triggered effect is not to change what instructions the instance is going to "do"; the triggered effect is to actually do the thing (e.g. +$1) itself.
If "Instance of a card" is whatever you end up doing as a result of playing that card, then Adventures tokens, Priest's +$2, another Cultist, etc., are all included.
It's not everything that happens "as a result of" playing that card; it's every instruction issued by the instance, and nothing that triggered as a result.
If "Instance of a card" is supposed to exclude all those things, then it has to refer to just the card's instructions.
It doesn't have to specifically refer to the card's instructions; it refers to whichever instructions the instance is going to issue. Maybe instructions printed on the card, and maybe instructions printed on a Way.
If it's also supposed to include instructions from Ways or Enchantress, then we would have to define that specifically somehow (either with tagging instructions, or by calling out Ways/Enchantress by name or similar).
Or by saying that the instance issues instructions that are printed on a Way/Enchantress. By separating those concepts.
To illustrate the problem with your model: Let's say gaining a card with Ironworks creates an Instance of gaining a card, which is set to the card you've chosen to gain, and then Trader 1E triggers and changes the Instance's pointer to Silver instead. So the Instance of gaining which was "gain a Mill" is now "gain a Silver" instead. Is the card you gained with Ironworks Silver? Well, that would mean Ironworks gives you +$1 for gaining a Treasure. And if Ways worked like that, it would mean the Way's instructions count as the card's instructions. What if there were a Farber Village that asked if playing the Ironworks made you gain a Silver? The answer should be no, but with the Instance model it seems to be yes.
Why would we use the Instance model for gaining, though? As you demonstrated, it doesn't give the intended results there. If we use an Instance model for playing cards because it gives the intended results there, why would that mean we were forced to use it in other places?
Then how the frack do we solve it*? It's remarkable to me that nobody can answer this and still claim that this ruling makes any sense.
I mean, I feel like I explained a way it can work. The ultimate test, I guess, is can I explain it to a computer and have it give the expected results?
So I threw together a little Python script both as a sanity check and an attempt to explain what I'm trying to say. It's supposed to represent a player playing Smithy under four different circumstances. That player's +$1 Token is on the Smithy pile the whole time, so it always gives +$1. Way of the Sheep is in the setup, and it asks the user to choose on each play, so I alternate between playing Smithy normally and using the Way. The first two times, Harbor Village isn't involved; the second two times, we'll say that a Harbor Village was played just before the Smithy. (I don't actually simulate playing HV; I fake it.)
Here's the output:
$ python demo.py
Player 1 plays Smithy:
Play as Way of the Sheep? n
Player 1 gets +$1 [issued by delayed ability set up by +$1 Token rules]
Player 1 draws 3 cards [issued by instance #0 (of Smithy)]
Player 1 plays Smithy:
Play as Way of the Sheep? y
Player 1 gets +$1 [issued by delayed ability set up by +$1 Token rules]
Player 1 gets +$2 [issued by instance #1 (of Smithy)]
Player 1 plays Smithy:
Play as Way of the Sheep? n
Player 1 gets +$1 [issued by delayed ability set up by +$1 Token rules]
Player 1 draws 3 cards [issued by instance #2 (of Smithy)]
Player 1 plays Smithy:
Play as Way of the Sheep? y
Player 1 gets +$1 [issued by delayed ability set up by +$1 Token rules]
Player 1 gets +$2 [issued by instance #3 (of Smithy)]
Player 1 gets +$1 [issued by delayed ability set up by Harbor Village]
The first play is a normal play, so it draws cards, and the token gives +$1 beforehand. Note that the Instance is listed as the issuer of the +cards instructions and the token rules are listed as the issuer of the +$1 instruction.
The second play is a Way play, so it gives coins. The token gives its extra beforehand. Note that the Instance is listed as the issuer of the +$2 instruction and the token rules are still the issuer of the +$1 instruction.
The third play is a normal play "under the influence of" Harbor Village. It draws cards, but first gets a coin from the token. Note that the issuers of these instructions are the same as for the first play. Note also that, because the Instance never issued a +coins instruction (the +coins instruction was issued by the token rules), Harbor Village does not trigger and no additional coin is produced.
The fourth play is a Way play "under the influence of" Harbor Village. It gives coins and first gets an extra one from the token. Note that the issuers of these instructions are the same as for the second play. Note also that, because the Instance this time issued a +coins instruction, Harbor Village does trigger afterwards and produces an additional coin; the delayed ability set up by the Harbor Village is what issues that +coin instruction.
Are those the expected results?
And here's the script itself. It should run on any Python installation. I'm not sure if this is something you know how to read or not. If you need me to explain parts of it in English, I can do that; it's just that English wasn't helping us much before.
class Card:
def __init__(self, name, instructions):
self.name = name
self.instructions = instructions
class Way:
def __init__(self, name, instructions):
self.name = name
self.instructions = instructions
class Trigger:
def __init__(self, cond, effect):
self.condition = cond
self.effect = effect
def handle_triggers(triggers, player, card, instance):
for trigger in triggers:
if trigger.condition(player, card, instance):
trigger.effect(player, card, instance)
class Instance:
id = 0
def __init__(self, card, player):
self.id = Instance.id
Instance.id += 1
self.name = "instance #{} (of {})".format(self.id, card.name)
self.instructions_to_follow = card.instructions
self.player = player
def resolve(self):
self.instructions_to_follow(self.player, self.name)
# just a log of instances that gave coins (for Harbor Village)
coin_log = []
class Player:
def __init__(self, id):
self.id = id
def plus_cards(self, count, issuer):
print "\tPlayer {} draws {} cards [issued by {}]".format(
self.id, count, issuer)
def plus_coins(self, count, issuer):
print "\tPlayer {} gets +${} [issued by {}]".format(
self.id, count, issuer)
global coin_log
coin_log.append(issuer)
def play_a_card(self):
# player always plays Smithy in this example
the_card = smithy
print "Player {} plays {}:".format(self.id, the_card.name)
instance = Instance(the_card, self)
# Handle "when you play, instead" triggers
handle_triggers(on_play_instead_triggers, self, the_card, instance)
# Handle "when you play, first" triggers
handle_triggers(on_play_first_triggers, self, the_card, instance)
instance.resolve()
# Handle "after you play" triggers
handle_triggers(after_play_triggers, self, the_card, instance)
#
# Smithy definition
#
def smithy_instructions(player, issuer):
player.plus_cards(3, issuer)
smithy = Card("Smithy", smithy_instructions)
#
# +$1 Token definition
#
def token_trigger_cond(player, card, instance):
return player.id == 1 and card.name == "Smithy"
def token_trigger_instructions(player, card, instance):
player.plus_coins(1, "delayed ability set up by +$1 Token rules")
on_play_first_triggers = [
Trigger(token_trigger_cond, token_trigger_instructions)]
#
# Way of the Sheep definition
#
def way_of_the_sheep_instructions(player, issuer):
player.plus_coins(2, issuer)
ways = [Way("Way of the Sheep", way_of_the_sheep_instructions)]
#
# General rule for Ways
#
def way_trigger_cond(player, card, instance):
global way_save
for way in ways:
if raw_input("\tPlay as {}? ".format(way.name))[:1] == 'y':
way_save = way
return True
return False
def way_trigger_instructions(player, card, instance):
global way_save
instance.instructions_to_follow = way_save.instructions
on_play_instead_triggers = [
Trigger(way_trigger_cond, way_trigger_instructions)]
#
# Harbor Village delayed ability definition
#
def harbor_village_trigger_cond(player, card, instance):
return True
def harbor_village_trigger_instructions(player, card, instance):
global coin_log
if instance.name in coin_log:
player.plus_coins(1, "delayed ability set up by Harbor Village")
coin_log = []
#
# Main program
#
# first two plays don't use Harbor Village
after_play_triggers = []
p = Player(1)
p.play_a_card()
p.play_a_card()
# second two plays do use Harbor Village
after_play_triggers = [
Trigger(harbor_village_trigger_cond, harbor_village_trigger_instructions)]
p.play_a_card()
p.play_a_card()
Some notable points:
- A player is given an instruction by calling a method on a Player object. (This script only considers +cards and +coins instructions.) Each such method accepts a parameter for the issuer of the instruction. An Instance "does" something when its (unique) name is passed as the issuer. In fact, in this script, that's the
definition of an Instance "doing" anything: having its name passed as the "issuer" parameter to a method that represents giving a player an instruction to do that thing.
- Things that are not Instances can also be issuers of instructions in this script. Like delayed abilities from previous plays of cards or from the rules themselves. You can also imagine events and projects to be valid "issuers" of instructions. Is that concept really needed in Dominion? Well, nothing in the game (that I know of) cares about any of those things "doing" stuff, so... no, it's not needed yet, anyway. But using them here lets me print things that hopefully clarify what I'm saying, so I did.
- Harbor Village triggers after playing a card, so it has to go back and check what happened in the past. I do that by having the plus_coins method log the issuer of the instruction, then when Harbor Village actually triggers, it can go back and check the log to see if the Instance in question issued a plus_coins instruction. I clear the log after each play. That's not actually a correct way to do it in a real implementation; if I Throne a card, then I shouldn't clear the log after either play of that card because the Throne Room is still being played. But it's close enough for this toy program.
- See how the Instance has a resolve method? Every instance is resolved in the same way: issue the instructions that it's most recently been told to use. It could issue instructions printed on a card (Smithy), or instructions printed on a Way (WotS). It issues them to the player whose playing of a card produced that Instance. It passes its own name as the issuer.
- But, I hear you saying, Smithy just says "+3 Cards"; it doesn't say anything about an "issuer." I've just added a bunch of stuff that the card doesn't actually have printed on it. Well, the card doesn't say anything about Player 1, either. Even if it said "you," that wouldn't mean anything without further context. Who's "you"? Is it Bob? Is Bob even in a game right now? Is the card? The instructions written on Smithy (or any card) are unbound; they require further context in order to be interpreted. The instance binds them to a context. For sure, the instructions need the context of who played the card; they might also need the context of the card itself (the instructions might say to trash "this"). So why is it so weird to acknowledge that part of that context needed for some instructions is an implicit "issuer"? Especially when it's been established that some cards (like HV) are definitely looking for such a thing?
- I completely half-assed passing the chosen Way around using a global (way_save). It's ugly and bad, but it's probably more readable this way than the alternative.
- Don't ask me what Way of the Chameleon looks like in this or I'll have to make it self-modifying and then nobody'll be able to read it.
I dunno if any of that helped or not. I'm trying.
Author
Topic: Lantern, Elder, Harbor Village, Moat (Read 19273 times)