Dominion Strategy Forum
Dominion => Dominion Online at Shuffle iT => Dominion General Discussion => Goko Dominion Online => Topic started by: Beyond Awesome on September 21, 2015, 06:03:13 am
-
I have been playing a few games on the new client, and a lot of times it will seem like key cards are at the bottom of the deck, all scrunched up, like all my villages on the bottom after every reshuffle.
Anyway, I have been encountering a lot of games like this and finally had my suspicions confirmed when I played a game (against a bot) where I hit the opponents potion five times with Swindler and then hit Scavenger 7 more times in a row with Swindler. Statistically, I am pretty sure this is impossible.
Anyway, the shuffling problem does not seem to always occur, but it does exist and something funky is going on. I know this is absolutely not my imagination. The decks are not shuffling properly and cards are being stacked. I have played more than enough games to be 100% positive about this.
-
I haven't played it yet, but LOL, that's great. 'It's not just my imagination, guys.'
+1
-
Can you start to collect logs of games where this happens?
Are there any sequences of cards you can consistently reproduce? Maybe get two players to buy the same 5 cards, then use Swindler on each other without buying anything over and over again and see what happens?
-
There's definitely something pseudorandom going on!
I once made a method that did new Random() every time it was called, but the gaps between the calls were so small that it often used the same seed!
A simple seed is often based on time, like number of milliseconds since 1970. Now this in itself isn't a huge problem, but it is exacerbated by inaccurate system and operating system clocks. For instance Windows' clock doesn't really "tick" every millisecond, but it sometimes skips certain values. So even the same program can behave very differently on different systems with different clocks.
This is all to point out it's really easy to mess up random shuffling.
-
It sounds really hard to make it accidentally mess up in the way BA described, and I can't imagine them being stupid enough for soing it on purpose.
Also, isn't the deck randomization part of the stuff that actually didn't change with the new client,, since it's happening server-side?
-
You'd think so, but then realize we're talking about a company with a less than stellar reputation when it comes to development.
-
There was something like this reported a while ago on their forums
http://forum.makingfun.com/showthread.php?7064-Shuffle-Bug
-
Anyway, I have been encountering a lot of games like this and finally had my suspicions confirmed when I played a game (against a bot) where I hit the opponents potion five times with Swindler and then hit Scavenger 7 more times in a row with Swindler. Statistically, I am pretty sure this is impossible.
It's worth considering that even if your opponent's deck was ordered exactly the same way after every shuffle, the opponent was likely to have drawn a different number of cards from the deck beforehand (excluding chancellors) so the swindler would have still been hitting different targets. If the swindler itself was in error, perhaps using an old card reference rather than finding a new one, then there would probably be many more obvious symptoms for the user to see.
If you want to find evidence that the shuffling is not random then try to find ways of predicting the deck order.
-
The hard part would be noticing whether you're drawing different Coppers or the same ones, and always play with Shelters so you don't have the same issue with Estates.
-
The hard part would be noticing whether you're drawing different Coppers or the same ones, and always play with Shelters so you don't have the same issue with Estates.
Lol
I'd actually be doing a lot more playtesting if we got to, you know, choose things like that. Things that would make it possible for people to playtest their software.
-
I once made a method that did new Random() every time it was called, but the gaps between the calls were so small that it often used the same seed!
A simple seed is often based on time, like number of milliseconds since 1970. Now this in itself isn't a huge problem, but it is exacerbated by inaccurate system and operating system clocks.
And while this sort of thing can be a problem, it's highly unlikely to be a problem when the calls are spread out over not just seconds but minutes.
Humans suck at seeing randomness. This is likely to be true until the end of time.
-
Humans suck at seeing randomness. This is likely to be true until the end of time.
This. A million times this. I'm so tired of seeing people complain online about the "stupid RNG" in their game of choice. I mean, there are ways to implement a naive shuffler that does stupid things, but I wouldn't expect a professional developer of a card game to make that mistake. It's quite literally the first thing they should get right. Having said that, these guys have defied my expectations in other ways. :)
There's definitely something pseudorandom going on!
Unless the Making Fun guys have an amazing new technology they're hiding from the world then it's definitely pseudo-random. ;)
-
Unless the Making Fun guys have an amazing new technology they're hiding from the world then it's definitely pseudo-random. ;)
One can generate random numbers. Count particles from radioactive decay or measure analog electric noise somerwhere in your hardware. That's nothing new and not pseudo-random. ;)
-
Unless the Making Fun guys have an amazing new technology they're hiding from the world then it's definitely pseudo-random. ;)
One can generate random numbers. Count particles from radioactive decay or measure analog electric noise somerwhere in your hardware. That's nothing new and not pseudo-random. ;)
I just have my computer physically roll a die and look at the result.
-
Humans suck at seeing randomness. This is likely to be true until the end of time.
While this is true, it's also true that if the exact same winning numbers for the lotto are drawn 3 weeks in a row, it's reasonable to suspect that there may be something broken with the machine that draws numbers.
-
Unless the Making Fun guys have an amazing new technology they're hiding from the world then it's definitely pseudo-random. ;)
One can generate random numbers. Count particles from radioactive decay or measure analog electric noise somerwhere in your hardware. That's nothing new and not pseudo-random. ;)
I just have my computer physically roll a die and look at the result.
Obligatory xkcd
(http://imgs.xkcd.com/comics/random_number.png)
-
Unless the Making Fun guys have an amazing new technology they're hiding from the world then it's definitely pseudo-random. ;)
One can generate random numbers. Count particles from radioactive decay or measure analog electric noise somerwhere in your hardware. That's nothing new and not pseudo-random. ;)
I just have my computer physically roll a die and look at the result.
You do know that's not only been done, but automated to a great extent?
http://gamesbyemail.com/news/diceomatic
-
I'm so tired of seeing people complain online about the "stupid RNG" in their game of choice.
Except in games like Chess and Prismata, where whining about the RNG is just for the sake of irony.
-
I'm so tired of seeing people complain online about the "stupid RNG" in their game of choice.
Except in games like Chess and Prismata, where whining about the RNG is just for the sake of irony.
You can legitimately complain about going second or going first, though.
-
Unless the Making Fun guys have an amazing new technology they're hiding from the world then it's definitely pseudo-random. ;)
One can generate random numbers.
Prove it. ;)
-
Unless the Making Fun guys have an amazing new technology they're hiding from the world then it's definitely pseudo-random. ;)
One can generate random numbers.
Prove it. ;)
321321
-
I'm so tired of seeing people complain online about the "stupid RNG" in their game of choice.
Except in games like Chess and Prismata, where whining about the RNG is just for the sake of irony.
Traversing parts of the game state tree that neither player truly thought about is very similar to RNG. It's an argument I've heard made.
Also, there's RNG in whether buying a 5th Scorchzilla will make my computer overheat so do I just buy a Steelsplitter instead? Life's hard.
-
back to the subject at hand -- can others confirm this? this is just awful if it is true.
-
back to the subject at hand -- can others confirm this? this is just awful if it is true.
I can confirm that the chance of this being true is so low that it's barely worth the time I'll spend rebutting it, much less any time I might theoretically spend trying to reproduce it. Feel free to spend your time reproducing it if you think it's likely.
-
There is a lot of gray area between "there are easy, repeatable, provable tests that demonstrate that the randomness this game is severely flawed" and "the shuffler is generating perfect random numbers, string happen even in random numbers, don't be superstitious."
One of my favorite games, Final Fantasy Tactics Advance, has a broken random number generator and I never even remotely suspected a thing on multiple playthroughs. The way the random number generator was modded made it 30% more likely to get a value less than .6 when generating numbers between 0 and 1, or something like that. Very minor, yet definitely a bug. Very difficult to prove. Despite having been played for thousands of manhours like any other A-list videogame, word of mouth and repeated testing didn't expose the RNG to be bugged, it was found to be bugged because some guy who cracked the game's ROM open to examine it noticed it while he was looking at other mechanics people wanted to know about (mostly the hidden stat potential values across various classes).
I'm pretty sure that trust in the person providing a random number is inherent to random number generation. For instance, I could start at the 9,674 digit of pi and produce "random" numbers for your all day, going in order. Those numbers would not be random, yet no test you could devise would predict future digits based on past digits (although there is at least one test I could devise that would predict future digits based on past digits perfectly).
Based on the relative reputations of Square Enix and Making Fun, from my point of view I don't have nearly as much skepticism that it's possible MakingFun is dropping the ball. I do think it's unlikely just because lazy programmers usually copy a very popular RNG implementation, and very popular RNG implementations are usually good, so that's how things usually work out well. But I definitely would not call it "so low it's not even worth the time spent rebutting it", and I wouldn't say that about the Hearthstone shuffler, League of Legends shuffler, or Magic online shuffler either. Generally the best way to know that something is actually and truly random is to see the manner in which the value was obtained : just like in real life, verifying that you see your opponent using proven shuffling methods is a better indicator than looking at outcomes.
Keep in mind that it's not necessarily the core random number generation method itself that is in error, it's also possible that something is done with that value in-between that causes outcomes to tend towards certain values. That's what was happening with the FFTA thing. If there's something not kosher about the way "give me a random number between 1 and 1,000,000" is translated into "give me a deck ordering" then you can get certain orderings to appear more frequently.
I think I will spoiler this post.
-
On the topic of choosing random numbers, I came across an interesting phenomenon when working on my thesis.
I had to choose points on the surface of a sphere to evaluate a function. I could choose more points to get more constraints to (hopefully) get a more accurate solution down the line. So at first I figured, well, there sphere can be parameterized by an angle in [0,2\pi] and an angle in [0, \pi]. So, let's draw two random numbers from that range and look at
<cos(theta)cos(phi), sin(theta)cos(phi), sin(phi)>
However, a uniform distribution of the angles will not actually lead to "uniformly" spaced points on the unit sphere. The reason, of course, is that the sphere is curved and the area element (sin(phi)*dtheta*dphi) is maximal around the equator and minimal around the poles. So the points would "bunch" up, which ultimately lead to a higher probability of rank deficiency in a big matrix as more and more points were chosen.
It took me a while to understand that was what was going on (though it's clear once you think about it). I ended up taking a more quasirandom approach. (Taking points that were solutions to some standard polynomial family (Legendre I guess)).
I think I will not spoiler this post.
-
I don't think there's anything to pursue here unless they post the relevant code. If they do then interested parties can look to see if they can find a bug. There could certainly be a bug, but the chance of someone perceiving flaws in the RNG is large whether or not there's a bug; it doesn't tell us much.
-
I'm so tired of seeing people complain online about the "stupid RNG" in their game of choice.
Except in games like Chess and Prismata, where whining about the RNG is just for the sake of irony.
Traversing parts of the game state tree that neither player truly thought about is very similar to RNG. It's an argument I've heard made.
Also, there's RNG in whether buying a 5th Scorchzilla will make my computer overheat so do I just buy a Steelsplitter instead? Life's hard.
By Richard Garfield no less, and I find it a very compelling argument:
https://www.youtube.com/watch?v=dSg408i-eKw
He starts talking about luck via complexity at 8:30. He talks about chess a bit shortly after 10:20 (and more specifically at 11:20). The whole talk is very interesting.
-
There could certainly be a bug, but the chance of someone perceiving flaws in the RNG is large whether or not there's a bug.
This is really the most important point to make here.
I've posted this once before, but I think it is a good article, so here it is again.
http://www.wired.com/2012/12/what-does-randomness-look-like/
Maybe there is something wrong with their shuffler, and maybe there isn't. It's definitely not something that is going to be remotely possible to determine by observation.
-
They should just make it nonrandom and see if everyone thinks it's more random.
-
Well, nonpseudo and nonquasi
-
But really, a standard
rand() % N
for not large N is biased towards lower numbers or something, right?
-
They should just make it nonrandom and see if everyone thinks it's more random.
I think we've had this conversation before. :P It depends on what kind of non-random. If it makes them win more, then yeah, it's totally more random.
-
But really, a standard
rand() % N
for not large N is biased towards lower numbers or something, right?
Right, assuming the number of integers rand() can return is not a multiple of N.
Example, if rand() gives a truly random number in the range [0,6], and N is 3, 0 is a more likely result than 1 or 2:
rand() -> rand() % 3
0 -> 0
1 -> 1
2 -> 2
3 -> 0
4 -> 1
5 -> 2
6 -> 0
-
But really, a standard
rand() % N
for not large N is biased towards lower numbers or something, right?
Yes, that was the problem with FFTA.
On the topic of choosing random numbers, I came across an interesting phenomenon when working on my thesis.
I had to choose points on the surface of a sphere to evaluate a function.
High dimensional spheres (really balls, because I want to include the interior) are really weird. The unit ball in n dimensions has volume O(1/(sqrt(n))^n), which is ridiculously small; the ball with volume 1 is quite large, with radius on the order of sqrt(n). If you look at slices through this ball in some fixed direction, then almost all of the volume of the ball lies in a slab of constant width near the equator (independent of the dimension, even though the radius of the ball is growing to keep the total volume correct). This is true in every direction, so most of the volume is in the centre right? No, it's in a thin shell near the surface, as the volume further in than that shell is exponentially small.
-
It took me a while to understand that was what was going on (though it's clear once you think about it). I ended up taking a more quasirandom approach. (Taking points that were solutions to some standard polynomial family (Legendre I guess)).
I'm not a mathematician, but wouldn't it be safe to choose random x, y, z, then scale that to the unit vector? I'm positive there's going to be a reason that doesn't work, but I'm not sure what it would be.
-
It took me a while to understand that was what was going on (though it's clear once you think about it). I ended up taking a more quasirandom approach. (Taking points that were solutions to some standard polynomial family (Legendre I guess)).
I'm not a mathematician, but wouldn't it be safe to choose random x, y, z, then scale that to the unit vector? I'm positive there's going to be a reason that doesn't work, but I'm not sure what it would be.
That still might not uniformly cover the area. But any way, I had to parameterize with angles for the calculation, so it was natural to use those.
-
http://mathworld.wolfram.com/SpherePointPicking.html
Amusingly, my method works if x, y, and z are chosen by Gaussian distribution, not linear distribution. (Eq 16 in that link)
-
Once we figure out quantum computing, this will all be trivial.
-
I once made a method that did new Random() every time it was called, but the gaps between the calls were so small that it often used the same seed!
A simple seed is often based on time, like number of milliseconds since 1970. Now this in itself isn't a huge problem, but it is exacerbated by inaccurate system and operating system clocks.
And while this sort of thing can be a problem, it's highly unlikely to be a problem when the calls are spread out over not just seconds but minutes.
Humans suck at seeing randomness. This is likely to be true until the end of time.
That is true, but it's also easy to screw up your implementation. You could also be using a simplified implementation (new Random()) when you can use a better one (new SecureRandom()) for instance.
-
Slightly off-topic, but related:
One of the interesting side-effects of the card areas (hand, in-play, discard, deck etc.) and shuffling rules in Dominion is that cards can get segregated from each other or clumped together. Very rarely are you shuffling your entire deck. You may just be shuffling 1/3 of your deck, so even with an ideal shuffler your deck is not going to be truly randomized.
Has anyone attempted to model this behavior? It would make a great paper.