Intégration de l'aléatoire

[Ter Rowan]

mouais ce que tu écris est une lapalissade : plus on fait des tirages aléatoires +-5 autours de 100 géométriques, plus on étale les résultats

De plus, pour moi, conclure sur 1000 tirages n'est pas suffisant.
je te propose l'expérience suivante: réalise 1000 courbes et vois si les 1000 courbes sont les mêmes, donnent les mêmes conclusions, etc...

[niahoo]

Arf désolé, oui j'auras du mieux lire. Tu commences par un homme de paille ceci dit, pourquoi faire ?


Heu Xenos tu n'as pas bien lu mon post non plus je crois, je parlais d'un exemple avec de l'aléatoire sur les dégats d'une epée ...

Là ça n'a aucun sens, on ne veut pas que les joueurs aient toust leurs PV au terme d'un combat. On ne peut pas el conclure qu'avoir des dédats aléatoires est intrinsèquemet mauvais.

[Xenos]

@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.

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
;

[niahoo]

J'ai pas compris comment on pouvait gagner de la vie en se mangeant un coup d'épée. Tes formules doivent prendre en compte que quand la vie arrive a 0 les coups suivants n'existent pas.

Ton histoire de moyenne qui s'envole ça marche que avec le modèle en pourcent. Mais si tu prends un truc classique dans un domaine borné, comme dans la plupart des jeux vidéo, ça ne démontre rien.

Bref, dans cet exemple, y a rien de complexe a mettre une plage aléatoire de dégats sur une épée si on veut faire entrer un peu d'incertitude dans le gameplay.

[Xenos]

Tes formules doivent prendre en compte que quand la vie arrive a 0 les coups suivants n'existent pas.

C'est un modèle, qui ne s'applique pas qu'aux PV. Si tu l'y appliques, j'ai déjà dit que, justement, je ne considérai pas les tirages avec une "mort" au milieu, qui ne feraient d'ailleurs que renforcer le résultat final (une fois à 0, on ne remonte pas). Sans compter que, de toute façon, une fois le joueur à 0PV, la partie recommence soit au tour précédent soit au tour 0. On retombe sur le même problème du coup.

J'ai pas compris comment on pouvait gagner de la vie en se mangeant un coup d'épée.

Considérer que l'ennemi a mangé 5PV de dégat ou que t'as gagné 5PV, c'est assez similaire. Tu peux toujours considérer que ce modèle ne représente pas un combat spécifique, mais la progression du joueur au fil du jeu (là où l'aléatoire n'est souvent plus maîtrisé par le designer justement). Le "score" de 100 n'est pas ses PV, mais la puissance de son équipement en général (PV, armes, magie, peu importe).

Mais si tu prends un truc classique dans un domaine borné

Sauf que "le classique dans un domaine borné", c'est généralement "épée niveau 1 = 10DPS+/-1, épée niveau 2 = 20DPS+/-2... épée niveau 5 = 50DPS+/-5". Les bornes sont en pratique proportionnelles aux points dégats (si non, alors l'aléatoire n'a plus d'effet passé un seuil, donc je considère qu'il ne fait qu'encombrer).

y a rien de complexe a mettre une plage aléatoire de dégats sur une épée

Y'a "rien de complexe" tout comme un débutant en code vient nous dire "je veux faire un jeu, c'est facile, je sais faire du HTML". Le gamedesigner passe très facilement à côté de tout un tas de petites considérations qui débouchent sur un jeu du pif absolu. C'est sur que balancer un RAND au milieu, c'est pas dur. Bien moins dur qu'étoffer son gameplay. Mais le faire bien, c'est beaucoup plus délicat.

---

Mais bon, j'ai l'impression de me répéter et de ne pas forcément être lu (ou compris, ou tenté d'être compris)... Je vous laisse écouter les Extra credits à ce sujet, et vous ferez comme vous voulez sur vos jeux.

Strategic uncertainty https://www.youtube.com/watch?v=PJKTDz1zYzs
Uncertainty != Randomness: cela peut venir des autres joueurs (facteur humain), d'infos cachées (qu'on n'a pas vues, ou que le MdJ nous a sciemment masquées, ou qu'on a décidé d'ignorer). Je vous laisse voir à 5:37

Egalement:
• Plan, practice, improvise (https://www.youtube.com/watch?v=s9xkfPLJWf0), pour la notion "d'improvisation", qui n'est pas nécessairement basée sur l'aléatoire
• Procedural generation (https://www.youtube.com/watch?v=TgbuWfGeG2o) pour le surcout du random (dans le cas de la PG), et des difficultés que cela amène (ie: est-ce jouable?).
• The Delta of Randomness (https://www.youtube.com/watch?v=0V5eq4IQ6Go et https://www.youtube.com/watch?v=GiOA_CS25Kw) où le jeu de carte a l'avantage d'être "réinitialisable" d'une partie à l'autre, et pour les 3 pts de départ qui sont en fait liés à "Player's uncertainty" (et non "Game designer's uncertainty", qui l'aléatoire amène souvent)
• Perfect Imbalance (https://www.youtube.com/watch?v=e31OSVZF77w) qui s'éloigne du random, mais où l'aléatoire va complexifier (selon moi) la mise en place de ces "déséquilibres qualitatifs" (cf 5:33).

[Air]

Bonjour a tous

Débat passionnant. Dans ma réflexion pour la création d un jeu, j étais plutôt un adepte de l aléatoire. Je me disais que ça rajoute un peu de piment. Mais xenos m a convaincu. C est l inconnu des l ensemble des paramètres qui rends l aspect aléatoire pou la vision joueur. De plus, par exemple l analogie avec les jeux de plateaux, j ai horreur des jeux full chance avec le lancement de dé. J aime pouvoir planifier mes actions et voir ensuite ce que j ai planifié a fonctionné ou pas. La part d aléatoire/plutôt de surprise provient des interactions avec les autres joueurs. Du genre mon plan était super mais je n avais pas imaginé que l autres joueurs allait procéder de tel façon. Du coup, mon plan tombe a l eau ?.

Merci à vous pour vos arguments

[niahoo]

Ah ouais ? Moi ce que je vois c'est que si t'enlèvesle jargon inutile, les faux problèmes et les généralisations à outrance, j'ai l'impression qu'il ne reste de l'argumentaire de Xenos que ses goûts et des considérations toutes personnelles. Bon ensuite mettre un calcul aléatoire est rarement nécessaire, il faut savoir pourquoi on le fait, je ne défend pas particulièrement son usage.

[Xenos]

@niahoo
J'ai justement l'impression que tu te focalises trop sur un point atomique du jeu (ton épée 20DPS+/-5), quand je te parle de l'effet macroscopique de l'aléatoire sur l'ensemble du jeu. C'est mon propos: l'impact d'une petite altération aléatoire sur un jeu entier peut très facilement échapper au concepteur. Et quand on n'a pas une équipe de pros à plein temps mais un amateur tout seul (ou presque), alors cela fait prendre de gros risques (ou cela amène des maths bien plus poussées que la simple intuition, qui ne sert parfois pas à grand chose en terme de probabilités et statistiques).

PS: Quand j'entends jargon inutile, les faux problèmes et les généralisations à outrance, j'ai l'impression d'avoir un débutant face à moi. Peut-être as-tu raison sur le "jargon" (je veux bien savoir lequel d'ailleurs?!) inutile, le problème faux et la généralisation abusive... ou alors, il y a justement des éléments qui t'échappent et qui sont les causes cachées (c'est marrant: on va tomber sur un exemple "d'incertitude non aléatoire" dans l'argumentaire lui-même!) de ce jargon (qui, pour moi, n'est que de la précision dans les terme), de ces problèmes (qui sont peut-être des vrais problèmes en approche, que tu n'as juste pas aperçus) et une généralisation qui, certes, ne sera pas valide pour 5% des projets, mais évitera à 95% des autres de se vautrer.

[niahoo]

Bah déjà, j'ai jamais prétendu ne pas être un débutant en création de jeux. Ensuite, ce qui me fait tiquer, c'est que tu annonces que la médiane/moyenne s'écroule / s'envole dans ton post, mais tu prends un modèle qui fonctionne comme ça exprès. Et discrètement tu montres qu'avec un truc mieux pensé ça marche « ah oui mais on a des nombres négatifs ». Bah oui, mais sinon le modèle est nickel pour un jeu. Du coup l'entièreté du post qui montre que l'aléatoire c'est pas contrôlable est un gros écran de fumée. C'est simplement que l'aléatoire ne te plaît pas, ou ne te paraît pas assez pure, ou trop une solution du pauvre.

Et c'est probablement le cas souvent. Sauf que là tu annonces de manière dogmatique que l'aléatoire c'est mal et qu'il faut l'éviter à tous prix. Un tel dogmatisme n'est pas souhaitable en développement logiciel.

Ensuite, peut-être que je me focalise trop, mais en attendant tu ne m'as pas démontré que pour mon épée l'aléatoire était une mauvaise solution pour faire entrer en jeu la chance ou l'incertitude. Et que vas-tu conseiller au prochain qui voudra implémenter un jeu de poker ?

Si je relis le premier post, il semble que sur ECLERD tu aies mis de l'aléatoire partout et que ça n'ait pas fonctionné. Il y a surement des choses qui m'échappes mais tu n'as pas forcément toi non plus une pleine vision du problème, de la création de gameplay et de son implémentation. Donc le dogmatisme est malvenu.

Enfin, je le répète, je suis d'accord sur le fait que souvent il y a plus malin à faire. Allez, j'arrête de vous saouler, je vais regarder tes vidéos.

[Xenos]

un modèle qui fonctionne comme ça exprès

Parce que ce modèle est applicable un peu partout:
• Un joueur qui a 100 pts au début du jeu, et qui évolue au fil du jeu: la grande majorité des jeux proposent une évolution "proportionnelle" au score actuel du joueur (ie: tu gagnes généralement 1% de score en plus par jour, et non pas "10 points absolus")
• Des aléatoires sur les armes (ou autre) qui sont proportionnels à leurs caractéristiques (plus l'arme fait de dégâts, plus l'intervalle random est large: épée 5DPS+/-1 et épée 50DPS+/-10 par exemple)
• Des patients qui arrivent dans un hôpital (pour reprendre le propos d'origine du topic [PS: très bonne idée d'avoir demandé à scinder du coup ^^]): si tu as 1 hôpital, tu as 1 à 5 patients qui arrivent par heure; si tu as 10 hopitaux, tu as 10 à 50 patients qui arrivent chaque heure

etc. J'essaie justement d'expliquer que ce modèle (géométrique, celui qui a une médiane se pétant le nez) est très répandu.

Par exemple, pour l'épée, le modèle géométrique va se retrouver sur l'ensemble de tes armes, à moins que ton "+/-5 DPS" soit absolu et appliqué à chaque arme. Généralement, quand tu vas progresser et monter en puissance dans les armes, tu auras cet effet géométrique car tu passeras de l'épée 20DPS+/-2 à l'épée 40DPS+/-4 Et au-delà d'un seul combat, ce qui va compter sera (probablement!) le fait qu'un combat gagné amènera un "bonus" au joueur (plus d'XP, ou plus de vie, ou tout autre bonus) qui l'aidera pour le combat suivant (ie: plus on gagne de combat, plus on est fort). C'est une autre application éventuelle de ce modèle.

Après, n'hésite pas à monter des simulations spécifiques à ces cas-là, ça peut être intéressant à visualiser. Mais je pense que tu retomberas dans ce genre de modèle (peut-être moins marqué, à cause des "paliers" des armes: il n'existe peut-être pas d'arme à 30DPS+/-3).


Pour le côté "dogmatique", j'ai du mal à voir comment tu veux présenter cela autrement. Je veux bien laisser les autres se retaper la réinvention de la roue statistique. Pour ma part, quand je cherche une réponse à un problème (type: "alors, je dois mettre du random ou pas?"), je n'ai pas envie de lire 4 pages d'ergotage et de relativisation qui ne m'avanceront pas plus au final. Donc, oui, dogmatiquement, "ne foutez pas du random dans vos formules". Il sera toujours temps de pondérer après, quand le jeu tournera déjà un peu.