Doesn't that assumption remove the entire problem though? I thought the whole reason for the method was that people can't easily think of an unbiased random number.
Or put differently, if that's your starting point, what's stopping you from simply doing (A mod 6) + 1?
Of course as others note this is a convoluted mod n process.
Is all this angular difference stuff a fancy way of saying mod 6?
I'd say the only unbiased and non crappy method here is to feed the 2 participants' numbers into some sorth of hash function.
As such, while randomness is best, the given method is quite sufficient for having fun, and both players can agree that it's fair: they each have equal influence over the result.
Perhaps it’s just the feeling of “I took a risk and it didn’t work” vs “I chose badly and was outsmarted by the dm” seem different to me in an important way.
You could reframe this all easily as well for “I’m thinking of a number between 1 and 100, guess it within Y distance to succeed”. That’s mathematically equivalent I think, if you allow it rolling around.
One could put his hands behind his back with one hand palm open and the other hand in a fist. The other one then guesses which hand is open and him being right or wrong generates either a 1 or 0. Repeat N times for an N-bit binary number. Both players can influence their choice equally and also equally make assumptions about the other player's intentions when making their own choice.
1-Knight defeats Troll 2-Troll defeats Knight 3-Troll is wounded but escapes 4-Knight is wounded but escapes 5-Another character or party comes into scene
Then Player2 decides which outcomes are assigned to which numbers (1-5), keeping them a secret and Player1 picks a number not knowing the outcome it stands for.
It's quicker and within reach of us, mere mortals.
(However, if the stakes are high enough, the party that learns the outcome first can choose to exit the protocol if they are unsatisfied with the result.)
https://darkcephas.blogspot.com/2017/07/fair-random-number-g...
BTW a "classic" method of generating random numbers is to look at the second hand of a watch mod n.
Edit, I realize you’d have to drop 111 and 000 to get 6, not sure what I had in mind in the original, either way it balances. It’s also nice because I don’t think you can intentionally lose rock paper scissors.
It is virtually impossible.
E.g. HHHHT -> HHT -> 6
Then depending on the next 2 throws
HH -> keep going
HT -> 6
TH -> 5
TT -> 4
For TTT similar with K,1,2,3
When you're in competition, this cannot be assumed. You'll each bias the numbers you come up with towards your preferred outcome. Even with A + B mod N, you can still bias the results when you know what your opponent is trying for.
A fairer approach would be to make a long series of randomized values. Your opponent secretly chooses a starting offset, and you pick an offset to add.
So for 1d6:
2 5 1 3 6 4
4 3 5 2 1 6
5 6 3 4 2 1
1 4 3 2 5 6
3 1 2 6 4 5
You don't need a ton of rows. Each possible roll value must appear once in each row.Your opponent places a marker on one of those numbers and keeps that information hidden.
- Let's say they choose the "1" at row=2, col=5.
Now you pick a number from 1 to 6.
- Let's say you choose 5.
Now they reveal where the marker is set (row=2, col=5).
Now you advance from the marker by 5 (wrapping around in the row if necessary).
- so from row=2, col=5, you advance by 5 like so: 6, (wrap) 4, 3, 5, 2 (ending at row=2, col=4).
You "rolled" a 2.
Of course it would work fine without the table, just using simple maths, but I think having unique tables on each page to scramble the result removes some of the ability of players to try to mind-game each other.
It would not work as well for ranges other than 1-5.
Oh shame I though you were going to solve that problem.
As a bonus, the other person doesn't know what you "rolled" unless you tell them, which was important for the game I was making.
Might not be unbiased, but good luck proving it.
I'd prefer that one person choose a non-square integer, and the other choose (very large) n.
In [18]: n = 10000000
In [19]: tally = [0,0,0,0,0,0]
In [20]: for i in range(n): ...: tally[(random.randint(0,9)+ random.randint(0,9))%6]+=1 ...:
In [21]: tally Out[21]: [1600008, 1600460, 1699599, 1799697, 1699604, 1600632]
Each player chooses simultaneously an integer from [1, N]. (Like, draw a chit and reveal them simultaneously.) Sum the draws. For a sum of N+1 or more, subtract N.