Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[chipperMDW]

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?

Imagine there's a new instruction called "profit."  For a player to profit means for him to gain a card costing up to $3.  Some cards also do something when a player "would profit" (maybe gain a Gold instead or get +$5 instead; whatever); the intent is that these cards are supposed to work whenever a player is told to profit, even when there are no suitable cards left.

Profit and gain are two events defined at different levels of abstraction.  Profit is an operation on a player that encompasses the evaluation of a card specifier ("a card visible in the supply costing up to $3") and (potentially) entails a gain.  Gain is an operation on a player and a specific card, so it requires any card specifiers to have been evaluated before it can happen.

Now imagine there's a card called Profit whose only instruction is "profit."  Playing Profit and playing Workshop result in the exact same logic being followed: choose a card matching a set of criteria from the supply, then, if you found one, gain it.  Yet things that happen when you "would profit" happen before the choice (just on Profit, clearly), while things that happen when you "would gain" happen after the choice, and only if you were able to choose a card (on both Profit and Workshop).

Just because Profit does the same thing as Workshop doesn't mean "would profit" is required to happen at the same time as "would gain."  If it did mean that, there would be no way to create anything like "profit" because you would be forced to make it identical to gain, so you couldn't make it do what you want.

So why would the fact that "would gain" works at one level of abstraction mean that "would draw" should happen at the exact same level of abstraction?  Why shouldn't you be able to define draw at a higher level of abstraction, similar to that of "profit"?  Especially if defining it that way keeps other things consistent? (Yeah, I know; I understand that you don't think the token is a real "would draw" so you don't think it's inconsistent.)

Or do you think that, since "gain" is already defined to work at one level of abstraction, there should be no other events at any other level of abstraction, so defining something like "profit" would actually be impossible without being inconsistent?

[Jeebus]

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.)

I agree with your premise that it introduces another level of abstraction, in that it gives a name to something that is already defined by using another name ("gain") + some criteria. I also agree that "when you would profit" would work as you say. However, I believe that if "profit" existed in Dominion, there would never be a "when you would profit", because the whole point of "when you would" is to change the event. As you say, "profit", unlike "gain", could end up actually firing without any possible card to gain. 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 ), and in line with how Dominion usually is built.

[chipperMDW]

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 argued that you didn't need to check for a card before initiating (my definition of) draw (because the check is internal to the draw).  That'd be analogous to not needing to check for the existence of a suitable card before initiating a profit (because the choice is internal to profit).  I intended both to be events that always "would" happen when you were instructed to do them.

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.)

Well, "buy" is an event that does some stuff followed by initiating a "gain" event.  So, in some sense, that idea already exists in Dominion.

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).

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.  (Plus the changed interaction with Trader, but you said that.)

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 ), and in line with how Dominion usually is built.

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.

In order to match the rulings, "while you're drawing" must begin after you've been instructed to draw (obviously), and at a point when you wouldn't have reshuffled yet (because you'd remove the token instead of reshuffling).  So, at this start point, you check whether the player has his token and put a null card on top of his deck.  If you placed a null card, the player draws it immediately, and you take the token away from him.

(And I guess "while you're drawing" ends once you've either moved a card, removed the token, or decided there's no card to move.  But the end condition isn't too important because there's never any need to do anything at that time; any null card will already be gone.)

So "while you're drawing" starts before you know whether or not you have a card to draw.  "While you're drawing" always starts whenever you're instructed to draw.  That sounds familiar...

Well, hey, the point where you want your "while you're drawing" to begin is the exact same point where I want to fire my "would draw" event.  And where you want to remove the token and place a null card to prevent the remaining draw instructions from having an effect, I just want to replace the draw event with getting rid of the token.

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. And you're just faking out the instructions with a null card instead of canceling a draw event outright.

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.


Now, whether the "would draw" on the token is representative of a real "would draw" we might see on future cards? Maybe or maybe not. If those got defined to have different timings (like if your hypothetical didn't get $ on an empty deck), then I'd obviously need define something (DrawSpecificCard) similar to your idea of a draw event in order to handle those.


* Ok, you actually said "when you're drawing" and I changed it to "while."

[Jeebus]

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".

My first post:

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.

And later:

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 right I'm reinterpreting the token in my assumption. But it was based on the post from Donald that I quoted, and also the knowledge that mechanics like this are often developed in Dominion with physical cards, and the fact that the token resembles a card and is actually placed on the deck. But even without this assumption (about the text on the token), it's true that "when you would" is inconsistent on Trader and on the token (unless you "redefine" the draw event).

So, to sum up/repeat, and hopefulle conclude: To me the default position is to assume that "would gain" was not just arbitrarily made up because Donald preferred that you couldn't use Trader on an empty supply pile, but rather that it tells us something about how "when you would" events actually are supposed to happen in Dominion. And then accept whatever follows from that. You see it differently, but I guess we've said all we can say about it.

[chipperMDW]

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 want to place a restriction (derived from gain) on what sequences of instructions can be called events. Can you give a simple rule that describes exactly what restriction you want to use?

[Jeebus]

Ok, let's go with calling them "events", as we have sometimes done in this thread, although "instructions" would be better probably.

Movement events (the essence of the event is to move a card or cards)
call - move from Tavern mat to play area
discard - move from specified location (or else: hand) to discard pile
draw - move from top of deck to hand
gain - move from specified location (or else: supply) to discard pile, but the destination can be changed by the gain instruction (or Nomad Camp) before actually moving the card
set aside - move from specified location to set-aside area
trash - move from specified location to trash pile
put - move from specified location to specified location

Events to give players information, but in terms of game state they are also movement events:
look at from deck - move from deck to "set-aside area"
reveal from deck - move from deck to "set-aside area"

Non-movement events
buy - pay the cost of the chosen card (when-buy happens after this) [see below]
play - nothing (when-play happens after this, whether or not the card was moved in the put event) [see below]
choose - information is given to the game
resolve - carry out the specified events

(There are also book-keeping events like pay and +$ and +Actions etc.)

Often a shorthand is used in ability texts:

* All of the movement events that could move just one or some of several possible cards ("discard", "gain", "set aside", "trash", "put") sometimes entail a choose event first (meaning, before the movement event), from the specified location. For example "discard 2 cards from your hand" really means "choose two cards from your hand, and discard the chosen cards".

* "Buy" always entails a choose event before the buy event, from the specified location (or else: supply), and then entails a gain event after the buy event. (You said that buy is an event that initiates a gain, but as we can see from when-buy abilities, the gain has to happen after the buy is completed.)

* "Play" always entails a put event before the play event, from the specified location to the play area, and then entails a resolve event after the play event. (So actually the play event itself does nothing except trigger when-play abilities (like Moat): Even if you can't move the card to the play area, you still trigger when-play, and then resolve the played card.)

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".

[chipperMDW]

Ok, let's go with calling them "events", as we have sometimes done in this thread, although "instructions" would be better probably.

The things you listed are what I would call instructions.  Not all of those need to be thought of as generating events.  I think we're really not speaking the same language when it comes to events.

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.

To me, it violates causality to have an event that has to begin happening before it decides whether it "would" or wouldn't happen.

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.

Except, from what you describe, you don't have "when-would" triggering just before the thing you call the actual event begins to happen... you have it triggering in the middle of the event, after the instructions in the event make a check to see if... itself... is "really" going to happen. In which case, why make the distinction that the check is "a part" of the event rather than saying it's an instruction that's always present leading up to the event?

I mean, for me, the "when-would" and "when" are the things that define the boundaries of an event. The whole reason to call something an event in the first place is because something triggers on one or both of those things and you need to figure out the timing of the triggered things with respect to what happens in between.  It's meaningless to me to say that some instruction happens before "when-would," but is still "part of" the event somehow.

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".

I agree that your event timing works out, but I don't like that you require a definition of draw that makes the token not work with events. But ok, I'll try not to argue about that anymore.


All right, well, I didn't mean to type that much in this post. I got the hint that you want to wrap this up; I'm trying to get there, but I'm apparently not doing a very good job of it. Sorry.

[Jeebus]

It seems that you're just nitpicking now, and I can't really see the relevance of what you're saying.

All we're doing is grouping things into "events" or "instructions" to make a clear picture of the game mechanics. There are several ways of grouping things that all make sense and end up the same. If it's important to you what can be called an "event" (even though you agree that the model in my last post works out), I'll address it by saying the following.

My usage of "event" does not violate causality. The movement events are like the two Gain and Draw functions I wrote earlier. First they check, then they trigger "when would" abilities, then they check if the movement is cancelled, then they do the movement, then they trigger "when" abilities. 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. If you want to separate the actual movement into a low level function called gain, and call the high level funtion initiate_gain, whatever. It makes no difference.

I can't see that you yourself have a clear definition of an event. You seem to contradict yourself. You say, "My concept of an event is just a sequence of instructions that you distinguish with a name and refer to in other instructions." And you say that the tings I called events are instructions to you. Ok, so an event is a collection of instructions, like maybe for instance "buy", which contains the instructions to first choose, then pay, then gain. But then you say that this event can have triggers just before or after it, and these define the boundaries of the event. That doesn't fit at all with the other definition. That's actually at a lower level than my events (what you called instructions). Is an event like a matryoshka doll, that contains instructions which themselves contain more events? Is it events, events, events all the way down?

[GendoIkari]

Did anyone ask about Ironworks/Possession ever before Trader came out?

No.

I'm willing to bet that most people played it incorrectly and took the bonuses. With Possession, the correct ruling feels less intuitive than it does with Trader (I guess because the card it still being gained). I remember in the initial Blue Dog thread that you said that it is an unfortunate side effect of the ruling that Possession/Ironworks no longer works.

[chipperMDW]

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.

[Jeebus]

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.

[chipperMDW]

So actually I have no idea what constitutes an event in your mind.

Short answer: an event is anything that needs to be handled with this general logic:

Code: [Select]

Event:
handle "when-would"
if still happening:
carry out instructions comprising event
handle "when"

[Jeebus]

Now I'm even more confused. 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.

[chipperMDW]

So there are only two events in Dominion then, gaining and drawing?

I said events are things that need to follow that general logic. Either of the two trigger instructions might never do anything and could therefore be ignored, meaning nobody has to care exactly when it happens.  (Well, "when would" still has to care when the event ends so it knows what goes inside the conditional.)  Of course, if neither ever does anything, there's no real point in identifying the instructions between as an event.

(Note also that another implication of that being general logic is that the "instructions comprising the event" might themselves be blank. For something like "At the beginning of your turn," the event doesn't need to "do" anything itself; it just needs to trigger other things.)

Now, the two events you identified are the only ones (along with +$ for the other token) where it's necessary to define the timing of "when would."  No other event can currently have something happen "when it would" happen, so it's sufficient to understand "when" for everything else.

You could go ahead and describe where you imagine the event begins in anticipation of there someday being "when-would" effects for it. I'd probably imagine "trash" being defined analogously to gain, and would place the "when would" just after a specific card has been determined and before a move happens. But a (currently) equivalent definition would be to just have the entirety of the "trash" event be a null sequence of instructions (just like "beginning of turn") occurring immediately after a card is moved to the trash. It's a distinction without a difference until something needs "when you would trash."

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.  What's relevant is for people to agree that things like "choose" come before "when-would" when dealing with a gain event. I describe that as "choose" not being part of the event. (And we do agree about the timing, if not the terminology.)

However, I pretty clearly did not identify the trigger instructions as "instructions comprising the event." I said that an event (i.e. the instructions comprising the event) needs to be handled with that general logic: stuff might happen just before it happens; some of that stuff might stop it from happening after all; and other stuff might happen after it's done if it actually happens.

Long ago, when I designed a system for handling events in a Magic rules engine (hobby program, never even close to finished), the events were essentially objects with an "occur" method that performed the "instructions comprising the event" (i.e. just that one line of "code" in my previous post). An event object could be examined to see what type of event it represented (damage, life gain, etc.) and what parameters it had (how much damage, to what, from what...), and its parameters could even be modified (gain twice that much life).

An event object was passed to an event handler that would examine the event type and parameters to see if it matched what some registered replacement effect (a "when-would") or triggered ability (a "when") was looking for. The event manager would handle running any relevant replacement effects (which might modify the event or replace it with a different event) and deciding whether to go through with calling the event's "occur" method and subsequently running any relevant triggered abilities that matched what it did. (It also logged the event if it occurred so there was a way for things to examine what had happened in the past: functionality that might be relevant for something like Smuggler in Dominion.)

So in that implementation, the "when-would" and "would" were distinctly not a part of any event itself, but were part of a separate event manager where they were used to handle all events. That's how I tend to think of it.

If I were implementing a Dominion program (sometimes this thread feels like that's what I'm doing), I think that full-fledged event objects and an event manager would be overkill. I would probably just have functions that looked like what I wrote above, which made sure that the "when-would," the "instructions comprising the event," and the "when" happened with the correct logic for the relatively small number of existing events.

[Jeebus]

Oh man.

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.)

[chipperMDW]

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've been arguing the definition because you told me the -1 Card Token can't be represented using the existing event concept.  Even though it can be handled using the same logic used to handle events.  I was trying to figure out what about your definition of events precludes such a representation. Or to try to convince you to consider a broader definition.

(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 do agree that that's obviously how it should work.  I mean, I said that's the way I would define it.  I just also said that it doesn't really matter how I'd define it because nothing requires that concept yet.  I'm being descriptive, not prescriptive.

I think you're just arguing to avoid conceding some points now.

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.

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.

[Jeebus]

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".

[markusin]

*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.

[Seprix]

*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.

!!!