Dominion Strategy Forum
Dominion => Dominion General Discussion => Topic started by: PeasantKing on October 01, 2018, 11:50:46 pm
-
Everybody always goes on, on how complicated Magic the Gathering is. And I know when Dominion first came out it was quite simple compared to Magic. With all the newest expansions does anyone think that Dominion is catching/ caught up with complexity?
-
What do you think?
-
If complexity is defined by either the number of rules or the number of words that have special in-game definitions, then no, not even close yet.
-
Magic is clearly way more complicated that Dominion. That's why I like Dominion, but not Magic.
Dominion hits a sweet spot for me as a quick game that's simple to teach and has easy rules with strategic depth as an emergent property. The expansions then add great replayability.
I do think some of the more recent expansions have strayed too far from core mechanics, and become too complex. Adventures got away with it through sheer awesomeness, but I was less happy with Empires and Nocturne. Renaissance looks like a return to form, with cards you could safely let relative novices play with!
And this leads me to another important distinction. In Dominion, the complexity is there on the table in front of you. There are no complexity surprises lurking later in someone else's deck, and the kingdom can be fine-tuned to the tastes and skill levels of the other players if you like.
-
http://media.wizards.com/2018/downloads/MagicCompRules%2020180810.pdf
Pretty big difference.
Also, Magic releases like 1000+ new cards per year.
-
From a strategy perspective, Dominion has been arguably more complex than Standard Magic for a long time. From a rules perspective, Dominion is almost certainly never going to get even close to Magic's level.
-
In Dominion, the complexity is there on the table in front of you. There are no complexity surprises lurking later in someone else's deck, and the kingdom can be fine-tuned to the tastes and skill levels of the other players if you like.
That's the key. This is what I can't handle with Magic. I don't even theoretically know what's possible at the start of the game. It's also one of the reasons I love Dominion so much. You can look at the board, read the cards, and you're theoretically on the same level of understanding as anyone else. Yes, you won't notice some of the interactions straight away, but you theoretically could. There's nothing your opponent knows that you couldn't find out by thinking it through.
-
Interestingly, I tend to find the complexity of Magic to primarily be in the deck building, specifically in thinking of all the ways your cards could interact with each other and trying to anticipate threats from your potential opponents.
Dominion's complexity is in that same place, but presents differently. You don't have to anticipate the threats of your opponents, you know what threats they have available to them. So it's more about analyzing when to add the cards you have available, rather than which cards to include.
Yes, the comprehensive rules of magic is a ridiculously long document, mostly due to the designers adding new defined words in almost every expansion, which has been happening for the past 25 years. Kinda hard to not need a lot of written rules at that point.
-
The base rules document for Dominion is about 8 pages of relatively user-friendly text with pictures (excluding parts that aren't rules). If you tack on the unique rules for all the expansions, it might take another 6 pages if you condense examples. The currently complete rules document would be about 10-15 pages long, depending on formatting and verbosity of the examples given. Most of the expansions rules documents are taken up by the notes (which aren't rules relevant in nearly all cases) and recommended sets (thank you Donald, these are wonderful).
It wouldn't be as detailed in timing as other documents meticulously made by others here, but would be essentially complete.
Seems to me that it is much simpler.
The complexity is in the interaction of the card mechanics, not in the rules, which for me makes it more strategically interesting than Magic, but also more approachable.
-
Interestingly, I tend to find the complexity of Magic to primarily be in the deck building, specifically in thinking of all the ways your cards could interact with each other and trying to anticipate threats from your potential opponents.
It's hard to eliminate deck building from consideration, since that is an essential part of gameplay in Dominion. If you consider deck building, the complexity depends on the range of your collection. The statement
Dominion's complexity is in that same place
would to me only hold for people with one starter and three boosters, or maybe some draft formats, but not for Mr Suitcase.
-
http://media.wizards.com/2018/downloads/MagicCompRules%2020180810.pdf
Pretty big difference.
Also, Magic releases like 1000+ new cards per year.
lmao 229 pages
-
http://media.wizards.com/2018/downloads/MagicCompRules%2020180810.pdf
Pretty big difference.
Also, Magic releases like 1000+ new cards per year.
lmao 229 pages
To be fair; there are intentionally a huge number of repeated rules in there; it's not 229 pages of things you actually need to learn to play the game. The rule that says that a creature who takes too much damage goes to the graveyard is written under the section for damage, and the section for combat, and the section listing things that happen automatically as the game evaluates the state of things.
-
lmao 229 pages
To be fair, even the Laws of Duplicate Bridge are 166 pages long. They're small pages, and they go into enormous detail about how to handle more irregularities than you ever thought possible, but even so, you'd have thought Bridge was a simple game compared with something like Dominion.
-
To be fair, even the Laws of Duplicate Bridge are 166 pages long.
It's because, if you have cost reduction, you can gain a free copy of a card whose baseline cost is more than $6.
-
FWIW v4.1 of Jeebus's Complete Rules for Dominion and All Its Expansions (https://boardgamegeek.com/filepage/131854/complete-rules-dominion-and-all-its-expansions) is 85 pages long. I'm pretty sure it details just about every class of card interaction that has potential for confusion.
-
It's true that there are normally only 10 kingdom cards, but you get a lot of added complexity by additional piles that are not in the supply. This is happening a lot more in later expansions: in the way that Dark Ages added madman, mercenary, spoils, and ruins, Adventures added the page/peasant upgrade ladder, and Nocturne added a ton of other cards with spirits, boons, and hexes.
Playing with a newer player means they have to read all of these. It goes from reading Vampire to reading Bat to reading Hexes to reading Envy.
Nothing near Magic but certainly not simple
-
One section in Magic's big rules document is on "interaction of continuous effects," which explains what order to evaluate abilities that do things like change an object's color or power/toughness. It can matter what order you apply these in, so the game's rules explain how you can determine that order.
Dominion also deals with such effects, albeit in much smaller quantities. The order in which they're applied can matter in Dominion, too. For example, you have to apply Inheritance's type-changing effect before you apply Quarry's cost-changing effect, because the latter depends on the former. But there's no rule that explains why you evaluate them in that order, or that you're not allowed to evaluate them in the other order. There's not even an official name for that type of effect. It's just a thing people seem to know intuitively.
I guess my point is that there are things that are not explicitly covered in Dominion's rules documents, but are nonetheless necessary concepts for precisely describing Dominion's rules (and thus contributing to its complexity).
-
One section in Magic's big rules document is on "interaction of continuous effects," which explains what order to evaluate abilities that do things like change an object's color or power/toughness. It can matter what order you apply these in, so the game's rules explain how you can determine that order.
Dominion also deals with such effects, albeit in much smaller quantities. The order in which they're applied can matter in Dominion, too. For example, you have to apply Inheritance's type-changing effect before you apply Quarry's cost-changing effect, because the latter depends on the former. But there's no rule that explains why you evaluate them in that order, or that you're not allowed to evaluate them in the other order. There's not even an official name for that type of effect. It's just a thing people seem to know intuitively.
They don't have timing; they just always apply. They look like they do that, and they do, so that's why people figure it out intuitively.
This is only possible due to the particular set of effects. If I had both "cards cost $1 less" and "cards cost $1 more" then you'd need timing. Magic of course has contradictory effects and even loops, where there's no possibility for an answer except an arbitrary one, and you have to look up the arbitrary answer.
The rules for static abilities in Magic are the first thing I'd cite as an example of how no-one knows the rules for Magic. They have printed commons, e.g. Snakeform, that routinely created rules questions that normal players simply couldn't answer.
I have certainly blown it in Dominion on some cards; Inheritance, Band of Misfits, and Overlord should work differently as discussed elsewhere, and I shouldn't have done replacements - Possession, Trader. Sans those things I have a pretty tidy rules set. They just don't compare.
-
To be fair, even the Laws of Duplicate Bridge are 166 pages long.
It's because, if you have cost reduction, you can gain a free copy of a card whose baseline cost is more than $6.
This right here is what makes Autolink in the F.DS extension so great.
-
One section in Magic's big rules document is on "interaction of continuous effects," which explains what order to evaluate abilities that do things like change an object's color or power/toughness. It can matter what order you apply these in, so the game's rules explain how you can determine that order.
This particular part of the MTG rules, "The Layer System", is I think the only part that I cannot pretty confidently say I know. I can generally answer any MTG rules question off the top of my head unless it involves that.
-
This is only possible due to the particular set of effects. If I had both "cards cost $1 less" and "cards cost $1 more" then you'd need timing.
I'm pretty certain that having both Quarry and Inheritance means you need "timing" as well. Inheritance's effect modifies types. Quarry's effect cares about types. I'm not aware of a way to evaluate them other than one at a time, and the order you choose matters. One way (the correct way, I believe) makes your Estates $0 because the modifications made by Inheritance's effect are visible to Quarry at this point; the other way makes them stay $2 because Inheritance's modifications are not visible to it.
-
From a strategy perspective, Dominion has been arguably more complex than Standard Magic for a long time. From a rules perspective, Dominion is almost certainly never going to get even close to Magic's level.
I would agree on Standard Magic but think Magic still has an edge in older formats like Legacy.
There's also the slightly infamous 350 page guide (http://www.eternalcentral.com/product/understandinggush3e/) to playing Gush most effectively. People go pretty hard on the MTG theorycrafting.
-
I would agree on Standard Magic but think Magic still has an edge in older formats like Legacy.
Yeah, there's a much wider range of competitive strategies in something like Legacy.
-
I'm pretty certain that having both Quarry and Inheritance means you need "timing" as well. Inheritance's effect modifies types. Quarry's effect cares about types. I'm not aware of a way to evaluate them other than one at a time, and the order you choose matters. One way (the correct way, I believe) makes your Estates $0 because the modifications made by Inheritance's effect are visible to Quarry at this point; the other way makes them stay $2 because Inheritance's modifications are not visible to it.
Both of those are ongoing effects, which will compound in the obvious way: once you've Inherited an Action, all of your Estates cost $0 while a Quarry is in play. The relative ordering of buying Inheritance, taking ownership of the Estate and playing a Quarry is unimportant.
The only fiddly question is question is exactly when an Estate becomes yours (http://wiki.dominionstrategy.com/index.php/Inheritance#Other_rules_clarifications), which has wider implications than just Quarry, and is presumably part of why Donald X. says he "blew it" on Inheritance.
-
I'm pretty certain that having both Quarry and Inheritance means you need "timing" as well. Inheritance's effect modifies types. Quarry's effect cares about types. I'm not aware of a way to evaluate them other than one at a time, and the order you choose matters. One way (the correct way, I believe) makes your Estates $0 because the modifications made by Inheritance's effect are visible to Quarry at this point; the other way makes them stay $2 because Inheritance's modifications are not visible to it.
Both of those are ongoing effects, which will compound in the obvious way: once you've Inherited an Action, all of your Estates cost $2 while a Quarry is in play. The relative ordering of buying Inheritance, taking ownership of the Estate and playing a Quarry is unimportant.
The only fiddly question is question is exactly when an Estate becomes yours (http://wiki.dominionstrategy.com/index.php/Inheritance#Other_rules_clarifications), which has wider implications than just Quarry, and is presumably part of why Donald X. says he "blew it" on Inheritance.
Chipper was thinking like a Magic player. In Magic, the question of which one is applied first is important; and it’s why the confusing layer system exists. In Dominion, presumably; all effects are just always applied at all times until there are no more effects to apply. Which is why you can never have 2 contradicting effects* without a big rules update.
* Like a card that says “while this is in play, all Provinces cost $7”; and another that says “while this is in play, all Provinces cost $6”.
*Edit*: The closest we have is the wording on Outpost, which says you draw 3 cards for your next turn. This needs to be “applied” before Expedition; otherwise you can logically conclude that if you play Outpost and buy Expedition; you should only draw 3. I think the way it works is that the Outpost rule is actually that it makes you draw 2 fewer cards; rather than makes you draw 3.
-
Both of those are ongoing effects, which will compound in the obvious way: once you've Inherited an Action, all of your Estates cost $2 while a Quarry is in play. The relative ordering of buying Inheritance, taking ownership of the Estate and playing a Quarry is unimportant.
First, I think you may have typoed this statement. All your (Inherited) Estates cost $0, not $2, while Quarry is in play. That's the "obvious way" they compound, right?
Second, nowhere was I claiming that the order of buying Inheritance and playing Quarry had any effect on the resulting state. In fact, I'm claiming the exact opposite: the order in which the effects come into being cannot matter; the result must be the same either way (your Inherited Estates cost $0). And in order for that to be the case, there must be an understood evaluation order.
Say Q(x) represents a game state like x, but with Quarry's effect applied. I(x) represents a game state like x, but with the effects of Inheriting Village applied. G is a game state where everything is as printed.
If you evaluate Q(I(G)), you get $0 Estates. If you evaluate I(Q(G)), you get $2 Estates. In order to get a consistent result of $0 Estates, you should only ever be picking Q(I(G)) whenever you have to evaluate both of them.
Now, say you're at G, and you play Quarry. You're now at Q(G). Now Inherit Village. You can't just apply I(x) to the current game state, or you end up at the incorrect I(Q(G)) and you have $2 Estates. Instead, you have to insert the evaluation of I at an intermediate point in order to get Q(I(G)). In other words, you need a rule that says I(x) effects to be evaluated inside the parentheses of Q(x) effects.
Donald says there'd need to be a "timing" if you had both cost increasers and cost reducers. Presumably, that's because cost reducers say they cap the result at $0. Say B(x) is the effect of Bridge and J(x) is a hypothetical effect that increases all card costs by $1. If you evaluated B(J(G)), then Coppers would cost $0 because the effects canceled out; if you evaluated J(B(G)), then Coppers would cost $1 because the cost increase was not "visible" at the point you evaluated B, so it capped at $0. Presumably, you'd always want Coppers to cost $0 in this case, so you'd need a rule that says increasers have to be evaluated "before" (inside the parentheses of) reducers.*
I'm saying that the exact same thing is true with Quarry and Inheritance: the order of evaluation matters. In either case, you can say that the result is "obvious," but you'd still following a rule (perhaps an obvious, intuitively understood rule) to get the result, even if you didn't realize it. And everyone else would need to follow the same rule in order to get the same result you did.
* Or else say that the capping at $0 isn't part of B but something that gets evaluated after all the cost-modifying effects, which I recall was also considered as an option.
-
First, I think you may have typoed this statement.
Ooops, yeah, fixed.
Say Q(x) represents a game state like x, but with Quarry's effect applied. I(x) represents a game state like x, but with the effects of Inheriting Village applied. G is a game state where everything is as printed.
If you evaluate Q(I(G)), you get $0 Estates. If you evaluate I(Q(G)), you get $2 Estates. In order to get a consistent result of $0 Estates, you should only ever be picking Q(I(G)) whenever you have to evaluate both of them.
Not so.
Firstly, I'll clarify that I(x) should actually be with the effects of player P Inheriting Village applied.
Q(x) modifies the algorithm for determining card cost, until the Quarry leaves play. It reduces the cost for any card that has Action type.
I(x) modifies (amongst other things) the algorithm for determining card type, until the end of the game. If a card is an Estate and is owned by P, it does have that type if Village has that type.
If you ask the question "what is the cost of card C?", you'll get the same result on Q(I(G)) or I(Q(G)).
That Q(x) and I(x), rather than instantaneously adjusting card costs or types, alter the algorithm by which costs or types will be determined in future, is what I mean by saying the effect is "ongoing".
-
For a concrete example of why you have to think in those terms, consider this:
- You play Quarry A
- You play Quarry B
- You buy Bonfire and trash Quarry A
- You buy a Village
How much does the Village cost when you buy it? $1. You cannot reach that conclusion by reducing the cost of Village by $2 (minimum $0) when you play Quarry A, then by another $2 (minimum $0) when you play Quarry B, then increasing it by $2 when you remove Quarry A from play.
The only correct option is to think in terms of evaluating the cost of Village at the moment when you buy it, using an algorithm which is dynamically adjusted by the course of play.
-
First, I think you may have typoed this statement.
Ooops, yeah, fixed.
Say Q(x) represents a game state like x, but with Quarry's effect applied. I(x) represents a game state like x, but with the effects of Inheriting Village applied. G is a game state where everything is as printed.
If you evaluate Q(I(G)), you get $0 Estates. If you evaluate I(Q(G)), you get $2 Estates. In order to get a consistent result of $0 Estates, you should only ever be picking Q(I(G)) whenever you have to evaluate both of them.
Not so.
Firstly, I'll clarify that I(x) should actually be with the effects of player P Inheriting Village applied.
Q(x) modifies the algorithm for determining card cost, until the Quarry leaves play. It reduces the cost for any card that has Action type.
I(x) modifies (amongst other things) the algorithm for determining card type, until the end of the game. If a card is an Estate and is owned by P, it does have that type if Village has that type.
If you ask the question "what is the cost of card C?", you'll get the same result on Q(I(G)) or I(Q(G)).
That Q(x) and I(x), rather than instantaneously adjusting card costs or types, alter the algorithm by which costs or types will be determined in future, is what I mean by saying the effect is "ongoing".
Not sure I agree with the bolded part. In order to evaluate I(Q(G)), you have to evaluate Q(G) first. And when you do, you would end up with "Estates cost (http://wiki.dominionstrategy.com/images/thumb/3/3d/Coin2.png/16px-Coin2.png)", because they aren't actions. Then you would evaluate I(result); and the (http://wiki.dominionstrategy.com/images/thumb/3/3d/Coin2.png/16px-Coin2.png) Estates would become Actions.
We know this isn't correct by the rules.
Actually, I think what happens here is an implied version of what Magic calls a dependency. Because the effect of Inheritance would change the resulting effect of Quarry, it's evaluated first. The rules just don't feel the need to have such specifics in it; because it's intuitive. (People ask "Is Estate an Action"? And immediately see "Yes, it is").
Because Dominion doesn't spell out these rules, it avoids any sort of "Dependency loop"; where 2 different effects could be changed by the other. For example, imagine if Inheritance actually said "Your Estates that cost (http://wiki.dominionstrategy.com/images/thumb/3/3d/Coin2.png/16px-Coin2.png) gain the abilities and types of that card". While Inheritance by itself could have worked that way, it would create a dependency loop with Quarry, and thus such a thing would simply be avoided in the card creation process.*
* It's a loop because in order to see if the Estate is an action, we need to check how much it costs, which involves Quarry. But since Quarry only works on actions, we need to check the type, so we look at Inheritance. But we don't know if Inheritance is working or not, because that depends on the cost. Etc forever.
-
In order to evaluate I(Q(G)), you have to evaluate Q(G) first. And when you do, you would end up with "Estates cost (http://wiki.dominionstrategy.com/images/thumb/3/3d/Coin2.png/16px-Coin2.png)", because they aren't actions.
No, you don't end up with "Estates cost $2". You end up with a game state in which if you were to ask "what is the cost of this Estate in my hand?" you would be told "$2".
Then you would evaluate I(result); and the (http://wiki.dominionstrategy.com/images/thumb/3/3d/Coin2.png/16px-Coin2.png) Estates would become Actions.
No, Estates don't become Actions. You end up with a game state in which if you were to ask "is this Estate in my hand an Action?" you would be told "yes".
And, as a result, if you then ask "what is the cost of this Estate in my hand?" with a Quarry in play, you will be told "$0". Because you're asking the entire question of state I(Q(G)), rather than asking Q(G) part of the question, memoizing the result and then asking the remainder of the question if I(Q(G)).
-
In order to evaluate I(Q(G)), you have to evaluate Q(G) first. And when you do, you would end up with "Estates cost (http://wiki.dominionstrategy.com/images/thumb/3/3d/Coin2.png/16px-Coin2.png)", because they aren't actions.
No, you don't end up with "Estates cost $2". You end up with a game state in which if you were to ask "what is the cost of this Estate in my hand?" you would be told "$2".
Then you would evaluate I(result); and the (http://wiki.dominionstrategy.com/images/thumb/3/3d/Coin2.png/16px-Coin2.png) Estates would become Actions.
No, Estates don't become Actions. You end up with a game state in which if you were to ask "is this Estate in my hand an Action?" you would be told "yes".
And, as a result, if you then ask "what is the cost of this Estate in my hand?" with a Quarry in play, you will be told "$0". Because you're asking the entire question of state I(Q(G)), rather than asking Q(G) part of the question, memoizing the result and then asking the remainder of the question if I(Q(G)).
I agree with what you're getting at. I just wouldn't have put that as I(Q(G)) or Q(G(I)) because normally with nested functions, you don't ever "go back" to the inner function once it is evaluated. But really I think we're all saying the same basic thing here.
-
*Edit*: The closest we have is the wording on Outpost, which says you draw 3 cards for your next turn. This needs to be “applied” before Expedition; otherwise you can logically conclude that if you play Outpost and buy Expedition; you should only draw 3. I think the way it works is that the Outpost rule is actually that it makes you draw 2 fewer cards; rather than makes you draw 3.
I don't think the "2 fewer cards" idea works though, because of what happens with Donate. If you play Outpost and then buy Donate, your Outpost turn will have 5 cards because Donate tells you to draw 5. Outpost's wording doesn't reduce this to 3, it just gets ignored. Unless the online implementation got this wrong.
-
*Edit*: The closest we have is the wording on Outpost, which says you draw 3 cards for your next turn. This needs to be “applied” before Expedition; otherwise you can logically conclude that if you play Outpost and buy Expedition; you should only draw 3. I think the way it works is that the Outpost rule is actually that it makes you draw 2 fewer cards; rather than makes you draw 3.
I don't think the "2 fewer cards" idea works though, because of what happens with Donate. If you play Outpost and then buy Donate, your Outpost turn will have 5 cards because Donate tells you to draw 5. Outpost's wording doesn't reduce this to 3, it just gets ignored. Unless the online implementation got this wrong.
No, I think it works... by the time Donate does anything, Outpost will have already made you draw 3 cards instead of 5. You don't do anything for Donate until "after this turn" which includes after you've drawn your hand for next turn. So if you buy Donate on a turn that you played Outpost, you will draw 3 cards instead of 5, then Donate will make you draw everything else, then eventually draw 5.
*Edit* This can actually matter... if you had the -1 card token on your deck, then it's important that you draw your next-turn hand first, before dealing with Donate. That way you still get the full 5 cards from Donate. If you skipped the regular next-turn draw, then you'd have to draw 4 cards instead of 5 when drawing up after Donate.
-
I agree with what you're getting at. I just wouldn't have put that as I(Q(G)) or Q(G(I)) because normally with nested functions
I wouldn't have put it that way either; it's not a natural way to express Dominion.
However, given other people have been using it, I've run with it, in order to explain in those terms how Dominion behaves.
you don't ever "go back" to the inner function once it is evaluated
That's taking a fairly narrow view of what G might be and how I or Q might manipulate it. For example, expressing the slightly simpler Wharf in the Python idiom:
class Wharf:
@staticmethod
def effect(g):
g.cards(+2)
g.buys(+1)
@staticmethod
def onPlay(g):
effect(g)
g.player().startOfTurn.append(effect)Now when you do g = someWharfOrOther.onPlay(g), the start-of-turn part of Wharf becomes encapsulated within g and will, indeed, be called later. In that sense you do "go back" to the inner function.
-
I agree with what you're getting at. I just wouldn't have put that as I(Q(G)) or Q(G(I)) because normally with nested functions
I wouldn't have put it that way either; it's not a natural way to express Dominion.
However, given other people have been using it, I've run with it, in order to explain in those terms how Dominion behaves.
you don't ever "go back" to the inner function once it is evaluated
That's taking a fairly narrow view of what G might be and how I or Q might manipulate it. For example, expressing the slightly simpler Wharf in the Python idiom:
class Wharf:
@staticmethod
def effect(g):
g.cards(+2)
g.buys(+1)
@staticmethod
def onPlay(g):
effect(g)
g.player().startOfTurn.append(effect)Now when you do g = someWharfOrOther.onPlay(g), the start-of-turn part of Wharf becomes encapsulated within g and will, indeed, be called later. In that sense you do "go back" to the inner function.
I get you. It does lead to a potential infinite loop though; as you would end up with in the case of the Inheritance that only works on $2 Estates.
-
For a concrete example of why you have to think in those terms, consider this:
- You play Quarry A
- You play Quarry B
- You buy Bonfire and trash Quarry A
- You buy a Village
How much does the Village cost when you buy it? $1. You cannot reach that conclusion by reducing the cost of Village by $2 (minimum $0) when you play Quarry A, then by another $2 (minimum $0) when you play Quarry B, then increasing it by $2 when you remove Quarry A from play.
The only correct option is to think in terms of evaluating the cost of Village at the moment when you buy it, using an algorithm which is dynamically adjusted by the course of play.
I described Q(x) as a state where the costs of actions are $2 less than they are in x. I would have hoped it was clear that moving one Quarry out of play would cause one Q to be removed from the evaluation order (i.e. the game state would change from Q(Q(G)) to Q(G)), so the resulting final state would evaluate an action's cost by applying a single cost reduction of $2 to the printed cost. It would say Village costs $1. I'm not sure whether something I described actually led you to understand that I'd be trying to add $2 whenever I removed a Quarry from play, but that's not the case.
I think I understand the model you're describing. It's different from how I think about it (which is closer to the layer system described in M:tG's rules), but I think it provides the same results, and it's nice that your algorithm imposes an implicit dependency order on evaluations so that the "intuitive and obvious" result is the only one you can arrive at.
-
To be fair, even the Laws of Duplicate Bridge are 166 pages long.
It's because, if you have cost reduction, you can gain a free copy of a card whose baseline cost is more than $6.
(https://media3.giphy.com/media/pvAdTWkCXMnhm/giphy.gif)
-
The closest we have is the wording on Outpost, which says you draw 3 cards for your next turn. This needs to be “applied” before Expedition; otherwise you can logically conclude that if you play Outpost and buy Expedition; you should only draw 3. I think the way it works is that the Outpost rule is actually that it makes you draw 2 fewer cards; rather than makes you draw 3.
I always interpreted it like this: Outpost changes your next hand to 3, so it has to trigger before you draw (effectively "when you would draw your next hand"). You could interpret Expedition and Flag the same way, but since they tell you to draw more cards, I find it more natural to think of them as triggering afterwards ("when you draw your next hand, draw x extra cards"). This way we don't need to apply any extra timing rule or change the math on Outpost.
-
The base rules document for Dominion is about 8 pages of relatively user-friendly text with pictures (excluding parts that aren't rules). If you tack on the unique rules for all the expansions, it might take another 6 pages if you condense examples. The currently complete rules document would be about 10-15 pages long, depending on formatting and verbosity of the examples given. Most of the expansions rules documents are taken up by the notes (which aren't rules relevant in nearly all cases) and recommended sets (thank you Donald, these are wonderful).
It wouldn't be as detailed in timing as other documents meticulously made by others here, but would be essentially complete.
Well, my rules document devotes 30 pages to the actual rules for all explansions, including going through all contents and setup of all expensions, with a few pictures and examples, but not including most of the special card-specific clarifications and rulings. And the rules are written pretty densely, more so than in the official rules. Sure, there are some very specific and corner-case rules included (in small print), but since we're comparing it to a very detailed Magic document...
Maybe it's better to compare words. Those 30 pages of Dominion rules amount to about 15,000 words. The Magic document has about 116,000 words, so 13% of the complexity maybe?
-
For a concrete example of why you have to think in those terms, consider this:
- You play Quarry A
- You play Quarry B
- You buy Bonfire and trash Quarry A
- You buy a Village
How much does the Village cost when you buy it? $1. You cannot reach that conclusion by reducing the cost of Village by $2 (minimum $0) when you play Quarry A, then by another $2 (minimum $0) when you play Quarry B, then increasing it by $2 when you remove Quarry A from play.
The only correct option is to think in terms of evaluating the cost of Village at the moment when you buy it, using an algorithm which is dynamically adjusted by the course of play.
So, I think I figured out why you made this comment, and why you don't agree that Q(I(G)) produces a different result from I(Q(G)). You must still be thinking that Q(I(G)) is supposed to represent a sequence of states that a game progresses through as time passes. Like, you think Q(x) effectively means "play a Quarry." I explained before that that's not what I mean, and that the notation is intended to describe an evaluation order. The expressions inside parentheses don't represent past states, but substates.
I'm not sure how to explain better than I already have in text, so I wrote this instead. It's a Python script that uses the model I've been describing to process the effects we've been talking about in a very simple Dominion-inspired game state. The evaluation of effects is ordered by a simple priority order, with Inheritance always happening before Quarry (although it could be modified to use a dependency system like you effectively describe). Hopefully the code speaks for itself and makes it more clear what I've been saying. (Assuming you want to read/run it at all.)
(It assumes all Estates are "yours," by the way.)
class Substate(object):
def __init__(self, effects):
self.effects = effects
def has_outstanding_effects(self):
return len(self.effects) > 0
def next_state(self):
effects = sorted(self.effects, key = lambda e: e.priority)
return effects[0](self, effects[1:])
# First element is cost; second element is whether it's an action
carddefs = { "Estate": [2, False], "Village": [3, True] }
class RawState(Substate):
def __init__(self):
Substate.__init__(self, [])
def card_cost(self, name):
return carddefs[name][0]
def card_is_action(self, name):
return carddefs[name][1]
def as_str(self):
return "G"
class ModifiedState(Substate):
def __init__(self, underlying_state, outstanding_effects):
Substate.__init__(self, outstanding_effects)
self.underlying_state = underlying_state
def card_cost(self, name):
return self.underlying_state.card_cost(name)
def card_is_action(self, name):
return self.underlying_state.card_is_action(name)
def as_str(self):
return self.sym() + "(" + self.underlying_state.as_str() + ")"
class InheritanceEffect(ModifiedState):
def card_is_action(self, name):
action = self.underlying_state.card_is_action(name)
return True if name == "Estate" else action
def sym(self):
return "I"
priority = 0
class QuarryEffect(ModifiedState):
def card_cost(self, name):
action = self.underlying_state.card_is_action(name)
cost = self.underlying_state.card_cost(name)
return max(0, cost - 2) if action else cost
def sym(self):
return "Q"
priority = 1
class State:
def __init__(self):
self.raw = RawState()
def upper_substate(self):
substate = self.raw
while substate.has_outstanding_effects():
substate = substate.next_state()
return substate
def card_cost(self, name):
return self.upper_substate().card_cost(name)
def card_is_action(self, name):
return self.upper_substate().card_is_action(name)
def as_str(self):
return "%s: Estate $%u, Village $%u" % (
self.upper_substate().as_str(),
self.card_cost("Estate"),
self.card_cost("Village"))
def play_quarry(self):
self.raw.effects.append(QuarryEffect)
def unplay_quarry(self):
self.raw.effects.remove(QuarryEffect)
def inherit_village(self):
self.raw.effects.append(InheritanceEffect)
print "1. Play Quarry Before Buying Inheritance:"
s = State()
s.play_quarry()
s.inherit_village()
print "\t" + s.as_str() + "\n"
print "2. Buy Inheritance Before Playing Quarry"
s = State()
s.inherit_village()
s.play_quarry()
print "\t" + s.as_str() + "\n"
print "3. How Not To Do It"
InheritanceEffect.priority = 2
print "\t" + s.as_str() + "\n"
InheritanceEffect.priority = 0
print "4. Play Two Quarries..."
s = State()
s.play_quarry()
s.play_quarry()
print "\t" + s.as_str()
print "...Then Remove One From Play"
s.unplay_quarry()
print "\t" + s.as_str()
Here's the output:
1. Play Quarry Before Buying Inheritance:
Q(I(G)): Estate $0, Village $1
2. Buy Inheritance Before Playing Quarry
Q(I(G)): Estate $0, Village $1
3. How Not To Do It
I(Q(G)): Estate $2, Village $1
4. Play Two Quarries...
Q(Q(G)): Estate $2, Village $0
...Then Remove One From Play
Q(G): Estate $2, Village $1
The first two cases demonstrate both orders of playing Quarry and buying Inheritance. They both produce the correct results (which are identical to one another), and they both result in state Q(I(G)) due to the priority used to decide the evaluation order of the two types of effects. The third case temporarily mucks around with the priority ordering to show that evaluating the effects in the order I(Q(G)) produces a different (incorrect) result. Also, the last case demonstrates that the model doesn't have the issue you were describing with playing multiple Quarries and then removing one from play.
-
So, your whole algorithm depends on effects taking place at an instance in time. Which maybe comes from the Magic layers system, I dunno.
But Quarry's effect isn't written to take place at an instant in time...it's a continuous effect. As is inheritance's effect. Which is what crj was trying to get at, I believe. And indeed if you write the 2 effects in a sentence, the order is irrelevant. i.e. Our gamestate is one where:
-"Estate is an action, and all actions' costs are reduced by 2"
-"All actions' costs are reduced by 2, and Estate is an action"
Now when you dig deep and say how did you decide that the estate's cost was reduced by 2? We say, because of inheritance. i.e. Inheritance applies before the cost-reduction...but that's not equivalent to Inheritance applying before Quarry.
When translating such continuous effects into code, or making them instantaneous otherwise, you must add additional constraints, because "we can't go back". I believe in this case rather than saying it's a "priority" thing (which sounds arbitrary), it should be considered as a "dependency" thing. Quarry's cost-reduction depends on type, Inheritance effects type, so Quarry depends on Inheritance. Thus I(Q(G)) evaluated as a single point-effect doesn't make sense, because Q depends on I, and dependencies should always be evaluated first.
-
I believe in this case rather than saying it's a "priority" thing (which sounds arbitrary), it should be considered as a "dependency" thing. Quarry's cost-reduction depends on type, Inheritance effects type, so Quarry depends on Inheritance. Thus I(Q(G)) evaluated as a single point-effect doesn't make sense, because Q depends on I, and dependencies should always be evaluated first.
Right, this is exactly what I was trying to get at. And the rules of Magic even deal specifically with dependencies, saying that the evaluation of A would affect the evaluation of B, then you evaluate A first.
With Inheritance and Quarry, the list of cards that Quarry is affecting is modified by Inheritance. Thus, we either need to apply Inheritance first, OR we need to check Inheritance as a part of checking Quarry. Which why we think about that doesn't matter.
But if you had weird-Inheritance that only worked on Estates costing (http://wiki.dominionstrategy.com/images/thumb/3/3d/Coin2.png/16px-Coin2.png), then suddenly part of checking Inheritance means checking the cost of cards, which means checking Quarry. So either we need to apply Quarry first, or we need to check Quarry as part of checking Inheritance. Either way, we end up with a broken situation; a circular dependency. Dominion avoids this issue by never having circular dependencies.
-
So, your whole algorithm depends on effects taking place at an instance in time. Which maybe comes from the Magic layers system, I dunno.
But Quarry's effect isn't written to take place at an instant in time...it's a continuous effect. As is inheritance's effect. Which is what crj was trying to get at, I believe.
It does not depend on "effects taking place at an instant in time." I'm aware that continuous effects are meant to always apply, and that they don't "occur" at instants in time. There's absolutely no "time" involved in the algorithm I'm discussing (nor is time involved in Magic's layer system, for that matter). In these lines from the last section of my script:
print "1. Play Quarry Before Buying Inheritance:"
s = State()
s.play_quarry()
s.inherit_village()
print "\t" + s.as_str() + "\n"
the concept of "time passing" is present only in the instructions "play_quarry" and "inherit_village". The game has only one state at any given time. Those two are the only instructions that mutate the game's state from one moment in time to the next. Specifically, it starts at an initial state, progresses to a state where a Quarry has been played, then progresses to a state where Inheritance has been bought. The algorithm I'm discussing doesn't involve any of that (and, as is demonstrated, is independent of the time order in which those two things occurred).
The algorithm I'm discussing occurs entirely within the call to as_str(), which does not mutate the game state; it merely determines a string representation of the game's current state at this one instant in time. Of course, the algorithm progresses through a series of steps in order to reach its result, where certain things happen logically before other things. As any algorithm must do. That doesn't mean that those steps represent a passage of time, or that the game was ever actually in the intermediate states you considered on the way to the final one.
Take the equation x = 2 + 3 * 5. In order to determine x, you have to follow a sequence of steps. You have to follow them in the correct order, and one step along the way is that you find one of the subexpressions is equal to 15. That doesn't somehow mean that x is equal to 15 from that moment in time until you finish the next step, after which it "becomes" 17. Just because you're following the steps in a procedure doesn't mean you're representing the passage of time.
Likewise, just because you consider a game state where Inheritance's effect has been evaluated, but not Quarry's, that doesn't mean you're saying the game actually has that state at any given point in time. It's just an intermediate concept you use on the way to evaluating the actual state at a given moment. Just like the subexpression 3 * 5 is an intermediate concept you use on the way to evaluating x.
When translating such continuous effects into code, or making them instantaneous otherwise, you must add additional constraints, because "we can't go back". I believe in this case rather than saying it's a "priority" thing (which sounds arbitrary), it should be considered as a "dependency" thing. Quarry's cost-reduction depends on type, Inheritance effects type, so Quarry depends on Inheritance. Thus I(Q(G)) evaluated as a single point-effect doesn't make sense, because Q depends on I, and dependencies should always be evaluated first.
I entirely agree that a priority order is completely arbitrary, and would probably not be the desirable way to describe an evaluation order in Dominion. I also agree that a dependency order is probably what is intended.
I used the priority order in the code only because my intent was to show that, as I keep saying, the order of evaluation matters. Even if what you're evaluating is a game state at one instant in time. The simplest way to represent an order of evaluation is to assign a number to each thing you're evaluating. I wasn't trying to write a complete Dominion rules engine there.
My point, from the start, was that a hypothetical Dominion "Comprehensive Rules" document would explain what order to evaluate those effects. Nowhere am I saying that "dependency order" is somehow unacceptable. I'm just saying it's not called out anywhere (and doesn't really need to be, as far as I'm concerned). So one reason that the page counts of the rules that have been written for Dominion and those written for Magic are not directly comparable is because Magic's Comprehensive Rules are... more comprehensive. There are topics covered in Magic's rules that are not covered in Dominion's, but are nonetheless present (in fewer instances) there.
-
That doesn't mean that... the game was ever actually in the intermediate states you considered on the way to the final one.
Actually, let me take this one statement back. The game's state actually is identical to all the intermediate states when you consider the intermediate states to include the effects that have yet to be applied, which my script does. Each iteration of the loop in upper_substate() essentially performs a simplification on the game state, transforming it into an exactly equivalent state where one effect that is outstanding in the "lower" state is no longer outstanding in the simpler state "above" it. Sorta like how a + or * "disappears" from an expression when you transform it to an equivalent expression by applying that operator.
-
In Dominion, the complexity is there on the table in front of you. There are no complexity surprises lurking later in someone else's deck, and the kingdom can be fine-tuned to the tastes and skill levels of the other players if you like.
That's the key. This is what I can't handle with Magic. I don't even theoretically know what's possible at the start of the game. It's also one of the reasons I love Dominion so much. You can look at the board, read the cards, and you're theoretically on the same level of understanding as anyone else. Yes, you won't notice some of the interactions straight away, but you theoretically could. There's nothing your opponent knows that you couldn't find out by thinking it through.
I go further.... I bring up all the fine points mentioned in the rulebook for each card's "FAQ". For example, point out that with Embargo, if you gain a card (like with Workshop, which also happens to be in the supply ;)), this gains you the card, but it's NOT buying it, so you can get around having to gain a Curse from any Embargo tokens on it. I'd rather not have an advantage from that knowledge if we'd like a more even game
If they want to discover it all on their own, then I'll respect that request too.