Dominion Strategy Forum
Dominion => Dominion Online at Shuffle iT => Dominion General Discussion => Goko Dominion Online => Topic started by: SCSN on April 09, 2013, 11:36:43 am
-
(http://www.stichtingopen.nl/images/unfamiliar.JPG)
-
Wow. Another bug in Goko. Why am I not surprised?
-
I would consider that a Familiar bane.
-
Ugh... this was apparently supposed to be fixed, but I guess not. I hope they didn't fix it by just manually listing the cards that couldn't be banes because they had P in their cost, and just forgot familiar.
Well, I reposted it on getsatisfaction at https://getsatisfaction.com/goko/topics/familiar_as_young_witch_bane?rfm=1 , hopefully they'll fix it eventually.
-
I got P.Stone as a bane just yesterday, so it's not as simple as that.
-
Ugh... this was apparently supposed to be fixed, but I guess not. I hope they didn't fix it by just manually listing the cards that couldn't be banes because they had P in their cost, and just forgot familiar.
That's gotta be it, which is hilarious. Listing the cards manually sounds harder than just checking the cost properly...
-
Ugh... this was apparently supposed to be fixed, but I guess not. I hope they didn't fix it by just manually listing the cards that couldn't be banes because they had P in their cost, and just forgot familiar.
That's gotta be it, which is hilarious. Listing the cards manually sounds harder than just checking the cost properly...
public class Cost
{
private int Potions;
private int Coins;
bool operator < (Cost cost1, Cost cost2)
{
return cost1.Potions < cost2.Potions && cost1.Coins < cost2.Coins;
}
}
Hey, look at that. I did their job for them.
-
Perhaps this is hard after all. ;)
return (cost1.Potions <= cost2.Potions && cost1.Coins < cost2.Coins) || (cost1.Potions < cost2.Potions && cost1.Coins <= cost2.Coins);
-
Ugh... this was apparently supposed to be fixed, but I guess not. I hope they didn't fix it by just manually listing the cards that couldn't be banes because they had P in their cost, and just forgot familiar.
That's gotta be it, which is hilarious. Listing the cards manually sounds harder than just checking the cost properly...
Well, the person just above your post said they got pstone as a bane, so that's not it.
-
Perhaps this is hard after all. ;)
return (cost1.Potions <= cost2.Potions && cost1.Coins < cost2.Coins) || (cost1.Potions < cost2.Potions && cost1.Coins <= cost2.Coins);
:-[
I did it quickly, without testing or QA!
-
From ACM practice, general strategy for implementing lexicographic comparison with fields ordered by f1, f2, f3, ...
if (a.f1 != b.f1) return a.f1 < b.f1;
if (a.f2 != b.f2) return a.f2 < b.f2;
if (a.f3 != b.f3) return a.f3 < b.f3;
...
It always works, it's obviously correct (okay, to be fair, maybe this takes getting familiar with the pattern), etc. you waste no time thinking about edge cases or demorgan's law.
-
Ugh... this was apparently supposed to be fixed, but I guess not.
I reported this about 2-3 months ago on getsatisfaction, was told last week that it was fixed.... clearly not... :(
-
Comparing costs lexicographically is how we got into this mess in the first place. ;)
-
Are saboteurs and sages still finding vineyards?
-
From ACM practice, general strategy for implementing lexicographic comparison with fields ordered by f1, f2, f3, ...
if (a.f1 != b.f1) return a.f1 < b.f1;
if (a.f2 != b.f2) return a.f2 < b.f2;
if (a.f3 != b.f3) return a.f3 < b.f3;
...
It always works, it's obviously correct (okay, to be fair, maybe this takes getting familiar with the pattern), etc. you waste no time thinking about edge cases or demorgan's law.
As qmech says, the problem is that Dominion card costs aren't lexicographic. Which costs more, Familiar or Witch?
-
Definitely familiar. Potion > $2.
-
Neither. Potion is incomparable to $2. If you have enough money for a familiar, that doesn't mean you can buy witch instead, or vice versa.
-
Definitely familiar. Potion > $2.
Not sure if trolling...
The thing is that potion costs form what mathematicians (and I presume computer scientists and others) call a partial order. While Possession most definitely costs more than Alchemist, and most definitely costs more than Gold, it costs neither the same, more or less than a Province.
-
Neither. Potion is incomparable to $2. If you have enough money for a familiar, that doesn't mean you can buy witch instead, or vice versa.
Right! That was the point of my rhetorical question.
-
A reminder for all of us:
I suppose another way to look at this is on a grid. It might not serve as an effective aid, so feel free to ignore this.
Before Alchemy, cost was on a one-dimensional number line. You could map cost from 0 to 8. An increase or decrease in cost was pretty easy to map out.
Now comes Alchemy. Look, a new cost. We no longer can measure cost on a number line. Now we get to use a Cartesian plane (the x-y coordinates you learned in algebra). On the x-axis, you have the cost in coins. On the y-axis, you have the cost in potions. The costs of most cards will still be a line where the coin cost is 0-8 (and soon 11) while the potion cost is 0-1. No card requires multiple potions, but there could be in theory. You can draw a rectangle to illustrate the cost of potion cards.
Cards like Bishop and Salvager only care about the cost on the x-axis. The y-axis does not matter. Apprentice specifically looks at the cost on the x-axis and then assigns a number based on the cost on the y-axis. If you're familiar with complex numbers, it'd be like saying that you get $2 for each multiple of i. If you're not, then you probably shouldn't be reading my unnecessarily complicated analysis anyway.
Cards like Remodel and Expand give you a wide range. You can Remodel into something that costs up to 2 more. So, take the cost on the x-axis and add 2 to it. It doesn't change the y-axis at all. You now have a slightly larger rectangle. You can gain a card which cost lies in that rectangle. If Potion=1 then the new cost can also include Potion=1. Saboteur does the same thing. Shrink the rectangle down by 2 and look for a cost that falls in that rectangle. If that rectangle is actually a line, then you cannot take something that costs a Potion.
Cards like Upgrade and Remake are more specific. They say exactly 1. The understood rule is that the number refers to the number of coins. So, you go up or down on the x-axis, but the y-axis does not change. If the card has no Potion cost, then you have a line illustrating the cost. Add 1 to the right of the cost and mark it with a red dot. The new cost must be that dot. If the card has a Potion cost, you do the same thing. The problem is that you don't change the y-axis at all. So, the red dot is one higher on the x-axis, but the Potion cost does not change. If there were a card that says, "Gain a card costing exactly 1 more Potion," then you could go up on the y-axis.
I would love to add actual illustrations to this, but I don't really have to time to fidget with that. Sorry. Not really sure that my explanation is really any better. It's just a different way of approaching it.
-
Oh hey, I never noticed before that Apprentice doesn't give +2 Cards per Potion in its cost. Rather, it's just a flat +2 Cards bonus if there is at least one Potion.
-
Ugh... this was apparently supposed to be fixed, but I guess not. I hope they didn't fix it by just manually listing the cards that couldn't be banes because they had P in their cost, and just forgot familiar.
That's gotta be it, which is hilarious. Listing the cards manually sounds harder than just checking the cost properly...
public class Cost
{
private int Potions;
private int Coins;
bool operator < (Cost cost1, Cost cost2)
{
return cost1.Potions < cost2.Potions && cost1.Coins < cost2.Coins;
}
}
Hey, look at that. I did their job for them.
Actually i would not recommend redefining the < method with a partial order operator that would probably screw your ordering algorithms. Much better to keep the lexicographical order (money first potion second) for the < operator and then do a Is_Cost_Inferior(cost a,cost b) function using the partial order.
So that you could separate kernel calls (like ordering cards by cost for GUI displays) and game calls (applying any game effect comparing cost like the YW setup effect).
And thinking about it they may have done exactly the same mistake since correcting a bug and then rolling back and forth the correction is usually the sign of regression caused by conflicting requirements.
-
It always works, it's obviously correct (okay, to be fair, maybe this takes getting familiar with the pattern), etc. you waste no time thinking about edge cases or demorgan's law.
I thought the point was to not get Familiar.
-
From ACM practice, general strategy for implementing lexicographic comparison with fields ordered by f1, f2, f3, ...
if (a.f1 != b.f1) return a.f1 < b.f1;
if (a.f2 != b.f2) return a.f2 < b.f2;
if (a.f3 != b.f3) return a.f3 < b.f3;
...
It always works, it's obviously correct (okay, to be fair, maybe this takes getting familiar with the pattern), etc. you waste no time thinking about edge cases or demorgan's law.
Two problems:
1. As pointed out by others, cost comparison isn't lexicographic. That would be the model we want if one potion were "worth more" than any number of coins, or vice-versa; e.g. if a card costing $9 could be purchased with $p. What we generally want to do, to get a "costing less than $X" condition, is compare each component (coins and potions) and make sure each is satisfied.
2. But YW doesn't even involve a "costing less than $X" condition. The card says that the bane is a card "costing $2 or $3". It can't be Poor House, for example.
-
Well, the problem is that X+P > 3 for X >= 3, but for X < 3 it's incomparable. You can't say that 2P is greater than or smaller than 3. I mean, having three boxes of oranges and one box of apples beats having just three boxes of oranges (by one box of apples). If however you have two boxes of oranges and one box of apples we can't say that you have more than just three boxes of oranges.