Dans l'idée, l'ordinateur devrait être le roi du déterminisme : une action doit toujours donner le même résultat. Typiquement, quand je double-clique sur l'icone D2, le jeu se lance. La complexité des ordinateurs ayant très fortement augmenté, ce déterminisme est de moins en moins vrai : parfois au lieu de D2 j'obtiens un écran bleu... Néanmoins on a tendance à penser que c'est du à un bug de programmation quelque part (et en général on accuse Windows), c'est à dire qu'il y a une cause cachée mais qui est toujours déterministe.
Maintenant arrivent des gens qui ont besoin de hasard en informatique (pas seulement des joueurs. Des scientifiques/ingénieurs par exemple. On peut vouloir calculer des intégrales avec des tirages aléatoires). Notez donc que a priori, on a deux notions incompatibles.
Précisons vite fait qu'on peut ramener tout l'aléa informatique à des nombres aléatoires compris entre 0 et 1. On pourra ainsi générer des entiers entre 1 et N, décider aléatoirement du comportement des monstres...
Pour générer des nombres aléatoires, on peut se servir d'une source exterieure de hasard, comme l'horloge de D1, ou on peut simuler le hasard. On a alors quelque chose de déterministe (on parle de "pseudo aléatoire"), mais on souhaite qu'il n'y ait pas de différence visible avec un "véritable" hasard (parce que la hasard dans la vie courante, c'est un vrai sujet de débat. Imaginez ce que vous voulez, ce n'est pas le sujet du jour).
La question est "quel comportement est ce que j'attend de mes nombres aléatoires ?". Pour le jeu, les critères ne sont pas très restrictifs : on veut que tous les tirages soient bien répartis entre 0 et 1, et que les tirages successifs semblent indépendant (ou même que les groupes de tirages soient indépendants).
La méthode classique graine+fonction bien choisie permet de faire tout cela (en passant, ce principe de graine(seed) est un gros avantage pour le débugage). Il reste a bien choisir la fonction passant d'un tirage au suivant. Beaucoup de gens y ont travaillé, y compris des gens biens. Il en ressort qu'une méthode très facile et très efficace est la suivant :
*On va générer des entiers compris entre 0 et 2^n - 1, qui donnent des réels en les divisant par 2^n.
*Mettre ce que vous pouvez comme graine (nombre de millisecondes depuis la nouvelle lune par exemple) en début de session.
*On passe d'un nombre au suivant par la formule :
A(suivant) = A(précédant) * a + b [mod 2^n]
a et b étant correctement fixés (b=0 est très mauvais, b = 1 marche très bien). Différents livres/articles donnent des bonnes valeurs pour a et b (j'ai ca quelque part si ca vous intéresse).
*en fait les derniers bits ne sont pas vraiment aléatoires. Donc pour obtenir un entier entre 1 et N, il ne faut pas faire A[mod N], mais ceil(A*N/2^n)+1.
Comme 2^n est beaucoup plus grand que les nombres intervenant dans les probas de D2, le comportement est bien indépendant d'un tirage à l'autre : si vous savez que vous avez obtenu la bonne chance sur 100 000, il y a en fait 42900 valeurs possibles pour le tirage, ce qui laisse toute la latitude possible pour les suite des tirages.
C'est d'ailleurs ainsi que marche le générateur aléatoire du C/C++. Les valeurs de a, b et n sont quelque part dans la documentation.
Le choix d'une telle méthode pour D2 serait donc assez logique. Cela dit, cette fonction particulière ou une autre, ça ne change pas grand chose. Ce qui compte c'est que :
+Comme on se sert beaucoup du hasard, deux parties avec même graine vont très vite se différencier.
+On ne peut pas prédire la suite des évènements. On bon drop par le premier monstre venu n'est ni un bon ni un mauvais présage.
Bref, tout ca pour dire que (sous réserve que les nombres aléatoires de D2 soient bien générés comme indiqué) :
-les séries de bons drops ne sont effectivement que de la chance. Il n'y a pas de méthode particulière.
-la facon exacte dont sont générés les nombres aléatoire n'a pas d'importance (du moment que c'est bien fait)
(J'espère que ce message fait avancer la discussion malgré les répétitions...)