Harad
Joined: May 11, 2014
|
  Posted:
Aug 29, 2017 - 16:04 |
|
Mori-mori-mori, I'm confused, I've watched your three replays and I can't see a single triple skulls. You do roll a triple pow, but this doesn't seem to have incurred the same ire
Where did I miss them?
Anecdotally, I'd say that the dice look pretty random with a healthy mix of good and bad results, with if anything more in your favour than against (your players put in an awesome streak of 1d pows that would have had me grinding my teeth but then a snaked dodge always hurts). But that's anecdotal obviously and it's not like I've studied the games in detail. |
|
|
MattDakka
Joined: Oct 09, 2007
|
  Posted:
Aug 29, 2017 - 16:15 |
|
Harad, it was fabrizionano complaining about triple skulls, not Mori-mori-mori.
|
|
|
Harad
Joined: May 11, 2014
|
  Posted:
Aug 29, 2017 - 16:17 |
|
Ah right LOL my bad! Not sure I have the strength to watch 54 replays. |
|
|
Christer
Joined: Aug 02, 2003
|
Mori-mori-mori wrote: | That's interesting read, but makes me wonder: is those random numbers are generated at fumbbl's server, then distributed to clients, or at clients themselves? I believe Cyanide uses the latter approach in both their games, with some cross-checks, when clients of 2 playing coaches controls each other's RNG streams, to ensure the opposition doesn't meddle with their dices, or something like that. How exactly does fumbbl client handle this? |
The previous client we used here had the RNG running on the client side, with a synchronized random seed. In its naïve implementation, this is a terrible idea as you could extract the random seed and by doing so predict dice rolls. At the time, there were rumors that this had happened for the client we used, although no actual evidence was brought to my attention.
The current client uses a server-side implementation which is immune to this type of exploit.
That being said, even a peer to peer implementation *could* be made secure in theory (even though it would require a more complex dialogue between the peers). Simplified, when a dice roll were to be made, one peer generates a random number (using their unique, unknown, seed or algorithm) between 1 and 6, encrypts it and sends it to the other side. The other side generates a random sequence of the numbers 1 to 6 (such as 4,2,6,3,5,1), encrypts it and sends it to the opponent. Once both messages have been sent, the decryption keys are sent over and both sides decrypt. The single random number is used as an index into the list provided by the other side to come up with the result. At that point, both sides will have the roll result in a secure fashion. (Note that the exchanges are done slightly differently to maintain security, but the principle is as I described).
Funny stuff to read about, but a server-side dice roller is significantly easier to implement |
|
|