En fait, l'algo ne crée pas une série de lancers (sinon, par exemple, comment saurait-il combien il doit en générer pour chaque type de dés ? Si un match dure 50 tours avec 20 jets par tour, on pourrait arriver au bout de la pile), tout ce qu'il fait c'est un seul random géant (généralement basé sur l'horloge système) au début du match qui va créer une clef gigantesque, qui sera communiquée aux deux joueurs (dans wiki ils appellent ça une graine :
http://fr.wikipedia.org/wiki/Graine_al%C3%A9atoire ).
Ensuite, il utilise une fonction (un mini algo) qui n'est pas du tout random, mais qui donne toujours le même résultat si on lui donne les mêmes paramètres.
Exemple : je donne à ma fonction un nombre de faces ( 6 faces, quitte à convertir le chiffre en résultat de bloc ensuite ), un numéro de tour ( 5 ), le nombre de lancers déjà effectués dans ce tour ( 14 ), et notre clé géante.
Il fait un calcul à la con du genre : je prends la clef géante, je la convertis en un nombre en base 6, et puis je vais voir ce qu'il y a comme valeur à la position 5 x 14 en repartant 'au début' si j'arrive au bout de ma clef.
=> et paf ça donne le résultat.
L'intérêt c'est que l'hôte/serveur/whatever comment c'est fait n'a qu'une seule variable à communiquer aux différents clients en début de match (y compris les observateurs maintenant) et que la fonction traitera tous les cas de figure de dés à x faces et ne pourra pas se déphaser si on choisit bien les paramètres, donnant toujours le même résultat à tout le monde (du coup même dans les replays, t'as pas besoin de stocker les résultats des jets, c'est encore de l'espace gagné dans les fichiers).
Le problème c'est que si un malin choppe la clef au début et qu'il connait la fonction de calcul, il peut anticiper tous les jets de dés, donc il faut 'camoufler' cette clé, mais là ça devient des problématiques de crypto que je ne maîtrise pas :-)