Earlier quoted context omitted.
Not counting radioactive decay as a physical process because you've chosen to define physical processes as deterministic is some intriguing mental gymnastics.
for the purposes described in the comment - I was quite clear that a certain level you get down to quantum effects. But for the context of the physical processes the OP was talking about those effects are not significant and so I excluded them.
Show HN: A Set of Dice That Follows the Gambler's Fallacy
211–220 of 243 posts
Re: Show HN: A Set of Dice That Follows the Gambler's Fallacy
#212How exactly does the roll() method work? Can't seem to parse the meaning of `runningSum` and `mark`. roll() { const sum = this.state.reduce((p, c) => p + c, 0) const r = Math.random() * sum let runningSum = 0 let result = -1 for (let i = 0; i size of die return (result + 1) }
At the outset, `this.state` is initialized as an array of `1`s — [1, 1, 1, ... , 1] — the number of `1`s is based on the `size` parameter passed to the `Die` constructor. So for a 4-sided die, `this.state` would initially be `[1, 1, 1, 1]`.
`sum` is the accumulated sum of `this.state`, but it helped me to think of the `sum` variable as a number line. Continuing with the 4-sided die case, we'd have a number line of length 4 at initialization (sum of `[1, 1, 1, 1]`).
In the context of a number line, though, `this.state` can be thought of as giving the geometric positions of each possible result. `this.state[i]` simply gives the length of the valid region for a certain result. At initialization, each result of `1` to `4` of our four-sided die would have a length of 1 on the number line (again, `[1, 1, 1, 1]`).
In concrete terms, the region [0, 1) on the number line would yield a roll of `1`, the region [1, 2) would yield a roll of `2`, ... , the region [3, 4) would yield a roll of `4`.
With that in mind, we can think of `r` as choosing a random point on the number line between 0 and the end of the number line. At initialization, it simply chooses a point on [0, 4), since 4 is the length of our number line.
`runningSum` is our location on the number line. The code chooses a result here using the boolean expression `(r In essence, we're traversing the number line starting from 0.
Back to our four-sided die example: let's say `r`, the random point on the number line we got, was 2.5. At initialization we'd start by checking the region of the number line where `1` would be our result. Since `this.state[0]` (the length of the valid region for the result `1`) is 1, we can say that if we choose a point randomly on the number line [0, 4) and it is on the interval [0, 1), our roll is a 1.
However, 2.5 is not on [0, 1), so we add the length of the region where `1` is valid to `runningSum` (our location on the number line) so we can move on to the next region - the interval where `2` is our result. The length of this interval is stored in `this.state[1]`, and is also equal to 1 (`this.state` = `[1, 1, 1, 1]`). In terms of our number line, the valid interval is thus [1, 2). At this point, our location of the number line, `runningSum`, is 2: still less than 2.5.
Next, we'd get to the region for the result `3`, `this.state[2]`, and we'd be at [2, 3) on our number line. At this point, our `runningSum` (location on the number line) is 3, which is greater than `r` (the randomly chosen point on the number line), 2.5, and we have our result. (sidenote: the variable `result` being equal to `-1` is a sentinel value and prevents `4` also being considered a valid roll by virtue of it being greater than 2.5 as well. After this iteration, `result` is set to `2` - changed to `3` in the return statement).
The "magic" of the die comes in when traversing the number line over the non-valid regions, however. While we're traversing the number line, we're also resizing the valid regions for each result and extending the line for the next roll. If we go back to the example in the previous paragraphs with the 4-sided die, we saw that since `r` (our randomly chosen point on the number line), 2.5, was not on [0, 1), the result of our roll was not `1`. To increase the likelihood of `1` in the next roll, we increase the length of the number line and the region where `1` is our roll: `this.state` becomes `[2, 1, 1, 1]`, the valid region for a roll of `1` becomes [0, 2), and the size of the number line grows to 5 (however, this expansion of the number line does not apply to the current roll).
At the culmination of our first example above, `this.state` would be `[2, 2, 1, 2]` — we'd increase the size of the valid region for each result except for `3`, our result from the previous roll. For the next roll, we'd choose a random point on the number line between 0 and (2 + 2 + 2 + 1 = 7). In terms of probabilities, another `3` would be half as likely as a `1`, `2`, or `4`, independently.
Re: Show HN: A Set of Dice That Follows the Gambler's Fallacy
#213There was an old flash video game I worked on a long time ago where I did exactly this. I had a boss with two main attacks, and I didn't want it to be super predictable A/B/A/B, so I had it pick between A and B randomly, then reweight the probabilities, so if it picked A, instead of 50% A, 50% B it'd now be 25% A, 75% B. If it picked A again it'd be down to like 12.5% A, 87.5% B. If B then got chosen, it'd flip flop…
Re: Show HN: A Set of Dice That Follows the Gambler's Fallacy
#214Earlier quoted context omitted.
Also: - don't play too many songs from the same artist in a row (and too many is probably 2) - don't play too many slow/fast/sad/angry/... songs in a row - ... instruments - ... genres - ... "feel" - ... Deep AI is definitely needed to create playlists that "feel random". :)
I don't think what people want is random when they say that... they want intelligently mixed playlists that meet a few criteria. no back to back songs from the same artist unless the pool of songs doesn't have sufficient variability in artists, not too frequent repeating of the same song, if you have a live version of the song it should be lowered sufficiently in probability of playing when another cover/live version…
Re: Show HN: A Set of Dice That Follows the Gambler's Fallacy
#215Interesting, and at first I was excited about the possibilities in something like D&D, where a series of bad rolls can have you feeling down. "I'm due for a critical hit any swing now..." Players would love that! Make my hero feel more heroic! The inevitable comeback! But then I thought about the inverse case -- you are doing really well, and now you are due for a failure. Or series of failures. That would feel awful…
Time for an Annoying Nerdy Rant! Randomness is what makes a game more realistic but true randomness will not make it more likable. True randomness dictates that in half of your games, your players will have a harder time achieving anything. It is not uniformity of results that the players are looking for, it is uniformity of successes weighted by the importance of the rolls. Failing a perception check in an empty roo…
In general, things are heavily weighted towards actual player skill and also character skills accrued over time for the important interactive elements.
For things like loot drops, it's strictly random from a chart per enemy type, but they monitor the overall economy and use that to set the weights for the various items. If one group of people has figured out some trick to farming an extremely valuable item, they will nerf it to keep the economy where they want it. For a number of years, the company actually kept a professional economist on full-time to keep track of these things. I think that got eliminated when CCP was having a rough financial time several years ago. And I think that game has gotten a bit worse as a result.
But in terms of stuff that counts RNGs are a fairly small part of the action, and in some cases not at all, so you can pick your poison: lower overall damage to a target but more consistent, allowing for one kind of play style. Or you can have more variable damage with higher potential if you're willing to take risks. And there are a couple of flavors along the spectrum.
It's a pretty interesting game design. And, of course, tons of people complain about it. Loot drops really are pretty damn random (with between 30-40 thousand people online at any given time, there's a lot of entropy to seed the PRNG). And you get the clusters you would expect from random data. But everyone really hates random outcomes. People want uniform outcomes. It's baked into our psychology.
But in terms of things that determine who lives and who dies in a fight. The random element is really downplayed, and it boils down to player skill more than anything.
There's a whole thing where people who have been playing for a long time will start brand new accounts with low skill levels and shitty equipment and still be able to blow people out of the water because they have a superior understanding of the game mechanics. In fact, there are entire "corporations" who really do nothing but this. Fine people who have been around for long enough to make some money and buy some expensive things and then lure them into fights and slaughter their bling-bling.
It's an interesting approach to game balance, and one I quite admire. It does keep me coming back, and paying that sweet, sweet monthly sub.
EVE is also one of the games that really capitalizes on the technology component. As much as I love Skyrim, for example, I don't think there's anything going on with the actual game interaction mechanics that couldn't be easily replicated on a table with some dice. I'm also willing to eat my words if I'm completely wrong about that.
EVE Online has the luxury of hammering out fairly complicated formulas based on the current state of things, and it does so very well. It does it for every ship in space (again, typically 30-40k), once each server tick (usually a tick is 1 second, but for really huge fights, they dilate time and slow the ticks down).
So they can make things like damage calculated for each gun or missile or drone on each ship based on every relevant ship's current speed and direction relative to every other ship, etc.
It's an impressive use of technology for an RPG, and I find it especially cool that you are your own gamemaster. The only story is the one you make for yourself.
But now I sound like a fucking fanboi, so I'll shut up.
I've never heard of Amber Diceless before. I'm curious and will check it out. Thanks for mentioning.
Re: Show HN: A Set of Dice That Follows the Gambler's Fallacy
#216There's a probability model called the Pólya urn where you imagine an urns containing numbered balls (colored balls in a typical example, but to draw the comparison with dice we can say they're numbered 1-6), and every time you draw a ball of a certain color, you put back more balls according to some rule. A few probability distributions can be expressed in terms of a Pólya urn, see https://en.wikipedia.org/wiki/P%C3…
Thank you for that link - a great read!
Re: Show HN: A Set of Dice That Follows the Gambler's Fallacy
#217Earlier quoted context omitted.
A good way to show how the "Randomness is not what we expect" phenomenon manifests is the following. Given a fair coin that outputs Heads (H) or Tails (T), which of the following sequences is more or less probable HHTHTT or HHHHHH Answer: Both are equally probable strings to be generated by the fair coin and each should occur once in every 64 sequences (~1.56%)
True But I would like to show you an interesting counterexample which requires changing the rules slightly. If we toss a coin and keep tossing until one of the below sequences turn up then which sequence is more likely? HHHHHH THHHHH Answer: THHHHH. Only 1/(2^6) of the time it will be HHHHHH. The only way to get HHHHHH will be if the first 6 flips are heads. If you don't flip a head you must have got a tail which mea…
We tend to use the fair coin or the fair die as a common way of talking about things, but I've found that this is problematic for a lot of people.
First off is the use of the word fair. People not from a background in statistics don't think of that word the way we do. They think of it as an attribute of the object itself. The the coin or die is 'fair' in the ethical sense of the word.
Second is the experiential understanding: 'This coin is fair and therefore should flip heads and tails with equal frequency. It's the same damn coin, and I flipped it a thousand times! Why are these crazy stats people telling me it comes up heads and tail equally often? It doesn't, dammit!'
What I've had some success with helping people understand independent trials is to get them to envision flipping 6 different coins at the same time. Then you can sort of walk them back into understanding that flipping 6 different coins once is no different from flipping the same one 6 times. The events are totally unrelated, and a past event is not a predictor of the future.
Plus, you can actually map out the math for them on the spot. .5 * .5 * .5, etc.
That's just my experience trying to explain things though. Would love some criticisms if there are better ways to go about this.
Re: Show HN: A Set of Dice That Follows the Gambler's Fallacy
#218Earlier quoted context omitted.
Obligatory relevant XKCD: https://xkcd.com/904/
And for those who are really in to this topic, Taleb's "Fooled by Randomness" is great. There's a section on how financial traders often end up ranked like this. Somebody makes an effectively random bet, but it pays off big so they're treated as a genius. It made me see all sorts of organizations differently.
Re: Show HN: A Set of Dice That Follows the Gambler's Fallacy
#219It's always nagged me that statistical problems are scoped so small. Surely in saying there's 6 outcomes on a dice you'd obfuscated the billions of interactions between atoms and input possibilities in doing so. Thrower A and thrower B will undoubtedly throw slightly different which might actually constraint the outcomes and skew the 1 in 6 percentages? It's similar to me to condensing 30 characters to 5 via an algor…
Outside of games, for which this was explicitly created, these kinds of things are learning tools to understand distributions and dependent vs. independent events, and it also makes a separate point about assumptions.
In reality, if we were wanting to predict the outcome from a real dice-throwing event, we would either sample the results from actual people throwing dice, or we would simulate the results based on parameter inputs for exactly the types of things you are talking about.
Of course, no one really cares that much about dice, other than people who play board games with dice. :) So substitute any other stochastic method for generating an outcome that does matter, and the statistical approach will generally be the same: either sample or simulate.
Obviously there are exceptions, but that's really the basic idea.
Re: Show HN: A Set of Dice That Follows the Gambler's Fallacy
#220I had a friend think of a playing card and any number (1-52). She picked the 6 of spades and the number 15 which is exactly the position where the card was located. It was only the third time I had done this trick with anybody.
Obviously, card and number picking is not uniformly random, especially when you influence their choice (e.g. "pick a large number"). But the odds of someone guessing the exact combination should still be extremely low.
A lot of what you see from David Blaine on TV is exactly this. He always has a backup plan but more often than not he doesn't need it.