@Ter Rowan:
oui, et c'est bien la raison pour laquelle le MdJ aura du mal à bien piloter son jeu en intégrant de l'aléatoire: la plage des possibles s'étale très rapidement.
Attention: y'a 10, 50, 250, ou 1000 tours (tours de jeu) mais à chaque fois, 5.000 simulations. Je te laisse faire le calcul analytique exact (qui serait une vraie preuve, là, justement comme toute stats, je ne fais qu'éventuellement m'en approcher), ou faire plus de simulations (t'as les sources en fin de post, tu peux donc convertir cela en autre chose que du PHP, ou le faire tourner pendant 20 minutes )
@niahoo
Je ne vois pas masse de différence? Là, je t'ai monté un exemple avec un joueur qui mène un (s'il meurt tôt) ou plusieurs combats (s'il meurt tard, ou s'il ne meurt pas) avec des attaques aléatoires (+/-5HP par attaque, ou +/-5% si on veut faire de la proportion)? Là, ce que cela prouve, c'est que si on retire le skill (vu qu'on ne s'intéresse ici qu'à la partie aléatoire des formules), alors:
• le modèle arithmétique (+/-5HP) amènera "forcément" un vainqueur au terme des 1000 assauts (la probabilité d'être encore aux environs de 100HP est faible; note que dans la pratique, elle serait même encore plus faible que le modèle, car ledit modèle considère qu'une simulation faisant 100HP->0HP->100HP termine à 100HP, alors que la pratique aurait fait mourir le joueur au milieu, à 0HP), ce vainqueur étant aléatoirement l'un ou l'autre des joueurs
• le modèle géométrique (+/-5%) amènera lui aussi "forcément" un vainqueur au terme des 1000 assauts, mais la majorité des joueurs aura été blessée (plus de la moitié des simulations tombent en dessous des 100HP initiaux) alors que certains se seront "envolés" et auront tout déchiré (parce que la moyenne reste à 100, donc si plein de monde [plus de la moitié] est sous la moyenne, cela veut dire que certains sont très très largement au dessus).
Et le modèle géométrique est très courant: ce n'est pas parce que ton épée fait 30DPS+/-5 que ton modèle est arithmétique: en effet, ton épée de niveau supérieur fera-t-elle 60DPS+/-5 (ce qui serait alors proche de l'arithmétique) ou 60DPS+/-10 (ce qui devient géométrique: l'intervalle random est de 1/6e de la valeur de base)? Et si le modèle est arithmétique, le sera-t-il pour tous les niveaux, même faibles (ie: l'épée de base fait 5DPS+/-5?).
D'ailleurs, ce que je trouve surtout intéressant (pour rappel, mon post s'appelait "curiosité mathématique", ce n'est pas forcément qu'une question de hasard et de jeux web), c'est l'application du modèle au monde réel. Imaginez que vous entrez dans un casino avec 100€, et vous misez 5% de cette somme dans un jeu de "pile ou face" équitable (ie: vous misez sur "pair" à la roulette, et on va dire qu'elle ne comporte pas de "0"). Après 1000 tours de roulette, vous avez alors plus de 50% de risques de ressortir de là avec moins que vos 100€ initiaux (la médiane est à 85€), mais vous avez des chances (faibles) de voir votre pactole s'être envolé pour atteindre des sommets
Faudrait que j'essaie un jour, pour voir ^^
Bref, je trouve que l'aléatoire est bel et bien complexe a gérer, malgré son apparente simplicité qui est en fait la "solution du pauvre": on laisse la qualité de son jeu dans les mains du pif et de la chance. Cette apparente simplicité est, pour moi, la raison pour laquelle cette complexité de bien gérer l'aléatoire est sous-estimée.
Edit: @Ter Rowan: voici le même mécanisme, en SQL, sur 100k simulations de 1000 tours: les résultats sont similaires (la médiane dans le modèle +/-5% est par terre, la moyenne est à 100). Ce SQL requière une table "integers" contenant des entiers, de 1 à 100k.
oui, et c'est bien la raison pour laquelle le MdJ aura du mal à bien piloter son jeu en intégrant de l'aléatoire: la plage des possibles s'étale très rapidement.
Attention: y'a 10, 50, 250, ou 1000 tours (tours de jeu) mais à chaque fois, 5.000 simulations. Je te laisse faire le calcul analytique exact (qui serait une vraie preuve, là, justement comme toute stats, je ne fais qu'éventuellement m'en approcher), ou faire plus de simulations (t'as les sources en fin de post, tu peux donc convertir cela en autre chose que du PHP, ou le faire tourner pendant 20 minutes )
@niahoo
Je ne vois pas masse de différence? Là, je t'ai monté un exemple avec un joueur qui mène un (s'il meurt tôt) ou plusieurs combats (s'il meurt tard, ou s'il ne meurt pas) avec des attaques aléatoires (+/-5HP par attaque, ou +/-5% si on veut faire de la proportion)? Là, ce que cela prouve, c'est que si on retire le skill (vu qu'on ne s'intéresse ici qu'à la partie aléatoire des formules), alors:
• le modèle arithmétique (+/-5HP) amènera "forcément" un vainqueur au terme des 1000 assauts (la probabilité d'être encore aux environs de 100HP est faible; note que dans la pratique, elle serait même encore plus faible que le modèle, car ledit modèle considère qu'une simulation faisant 100HP->0HP->100HP termine à 100HP, alors que la pratique aurait fait mourir le joueur au milieu, à 0HP), ce vainqueur étant aléatoirement l'un ou l'autre des joueurs
• le modèle géométrique (+/-5%) amènera lui aussi "forcément" un vainqueur au terme des 1000 assauts, mais la majorité des joueurs aura été blessée (plus de la moitié des simulations tombent en dessous des 100HP initiaux) alors que certains se seront "envolés" et auront tout déchiré (parce que la moyenne reste à 100, donc si plein de monde [plus de la moitié] est sous la moyenne, cela veut dire que certains sont très très largement au dessus).
Et le modèle géométrique est très courant: ce n'est pas parce que ton épée fait 30DPS+/-5 que ton modèle est arithmétique: en effet, ton épée de niveau supérieur fera-t-elle 60DPS+/-5 (ce qui serait alors proche de l'arithmétique) ou 60DPS+/-10 (ce qui devient géométrique: l'intervalle random est de 1/6e de la valeur de base)? Et si le modèle est arithmétique, le sera-t-il pour tous les niveaux, même faibles (ie: l'épée de base fait 5DPS+/-5?).
D'ailleurs, ce que je trouve surtout intéressant (pour rappel, mon post s'appelait "curiosité mathématique", ce n'est pas forcément qu'une question de hasard et de jeux web), c'est l'application du modèle au monde réel. Imaginez que vous entrez dans un casino avec 100€, et vous misez 5% de cette somme dans un jeu de "pile ou face" équitable (ie: vous misez sur "pair" à la roulette, et on va dire qu'elle ne comporte pas de "0"). Après 1000 tours de roulette, vous avez alors plus de 50% de risques de ressortir de là avec moins que vos 100€ initiaux (la médiane est à 85€), mais vous avez des chances (faibles) de voir votre pactole s'être envolé pour atteindre des sommets
Faudrait que j'essaie un jour, pour voir ^^
Bref, je trouve que l'aléatoire est bel et bien complexe a gérer, malgré son apparente simplicité qui est en fait la "solution du pauvre": on laisse la qualité de son jeu dans les mains du pif et de la chance. Cette apparente simplicité est, pour moi, la raison pour laquelle cette complexité de bien gérer l'aléatoire est sous-estimée.
Edit: @Ter Rowan: voici le même mécanisme, en SQL, sur 100k simulations de 1000 tours: les résultats sont similaires (la médiane dans le modèle +/-5% est par terre, la moyenne est à 100). Ce SQL requière une table "integers" contenant des entiers, de 1 à 100k.
résultats en SQL a écrit :simulations: 100000
nombreTours: 1000
plusMoinXPc: 5 (ie: entre -5% et +5% par tour)
valeurInitiale: 100
moyenne: 100.3380515625841
mediane: 66.25819618877651 (à ce niveau d'effondrement, on ne peut pas parler "'d'erreur statistique" ou de "manque de simulations")
maxiValue: 4039.522693430985 (= des joueurs auront une chance d'enfer qui pourra faire passer le jeu pour "non fair-play", ou ces joueurs pour des tricheurs)
miniValue: 1.172326956987247 (= personne n'est tombé assez bas pour que le epsilon machine soit en cause je dirai)
stdDeviation: 114.58038256176197
populationStdVariance: 13128.664067999725
sampleVariance: 13128.795355953285
Code :
SET @simulations := 100000;
SET @interval := 0.05;
SET @tours := 1000;
SET @startValue := 100.0;
SET @k := 0;
SET @median := NULL;
SELECT
COUNT(finalValue) AS simulations,
@tours AS nombreTours,
ROUND(100*@interval) AS plusMoinXPc,
ROUND(@startValue) AS valeurInitiale,
AVG(finalValue) AS moyenne,
@median AS mediane,
MAX(finalValue) AS maxiValue,
MIN(finalValue) AS miniValue,
STD(finalValue) AS stdDeviation,
VAR_POP(finalValue) AS populationStdVariance,
VAR_SAMP(finalValue) AS sampleVariance
FROM (
SELECT
IF((@k := @k + 1) = FLOOR(@simulations/2), @median := s.finalValue, NULL) AS isMediane,
s.*
FROM (
SELECT DISTINCT * FROM (
SELECT
i.n AS numeroTirage,
@val := @startValue AS startValue,
BENCHMARK(@tours, @val := @val * (1. - @interval + (RAND()*2.*@interval))),
@val AS finalValue
FROM integers AS i
WHERE i.n BETWEEN 1 AND @simulations
) AS t
ORDER BY finalValue ASC
) AS s
) AS s
;