Intégration de l'aléatoire - Version imprimable

Intégration de l'aléatoire - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Gameplay, gamedesign (https://jeuweb.org/forumdisplay.php?fid=48)
+--- Sujet : Intégration de l'aléatoire (/showthread.php?tid=7822)

Pages : 1 2 3 4 5

RE: Intégration de l'aléatoire - Ter Rowan - 29-06-2017

(29-06-2017, 10:23 AM)Xenos a écrit : Par exemple, au lieu d'avoir un tirage aléatoire RAND() au milieu d'un jeu en tour par tour, je trouve bien plus futé, maîtrisable et intéressant d'avoir une "table de hasard" (ie: une table SQL [id,rand]) remplie initialement par le MdJ, dans laquelle le jeu piochera les effets de chaque tour. Cela permet au MdJ de corriger cette table (au fil de la partie ou au départ)

donc là y a de l'aléatoire non ?
après bien gérer l'aléatoire pour moi ca veut dire

1) le concepteur du jeu maitrise toutes les issues possibles mais pas quand elles arriveront
en d'autres mots, je considère donc que dans un jeu web (après ca dépend des jeux évidemment, pour un livre dont vous êtes le héros ce n'est pas forcément utile de mettre de l'aléatoire, mais si ca peut pimenter un peu) le concepteur est plus proche d'un dieu que d'un maitre de jeu : il a donné des règles, un cadre, il peut créer des choses de sa propre volonté quand il le souhaite, mais, s'il ne fait rien, sa création (les humains la nature, etc...) évoluera dans un sens globalement prévu mais pas dans le détail absolu

le maitre du jeu décide de tout
le dieu a donné une partie de ses pouvoirs à ses créations

2) si toto est vraiment plus fort que tutu, alors toto aura 80, 90 ,95% de chances de battre tutu

3) si toto est dans les mêmes conditions que tutu dans sa recherche il n'aura pas les mêmes résultats que tutu

4) mais aussi que le random ne provoque pas n'importe quoi : je ne loot pas une côte de mailles sur un hasticot, je ne trouve pas un ours polaire sur une ile du pacifique (enfin si, dans lost) (==> ca revient a ta table (id, rand), du moins ce que j'en comprends)

5) ca veut dire aussi que si des dérives sont identifiées : 1 chance sur x (trop grand pour etre accepté) que pouf le monde, alors il faut mettre en place des gardes fous

6) que dans tous les cas ca doit être expliqué et simple : pas des dizaines de facteurs pour calculer un jet. Le pouvoir de l'aléatoire c'est justement ca : la goutte de sueur qui aveugle un court instant le maitre d'armes, le pauvre gars en face qui trébuche et sans faire exprès via un angle improbable trouve le défaut de l'armure sans avoir à multiplier des règles dans tous les sens. Ca veut pas dire j ai deux caractéristiques et c'est fini, mais ca veut dire j'ai pas 50 paramètres intégrant de l'aléatoire qui font que je ne maitrise pas ce qui se passe :

aka rand( facteur 1 x facteur 2 x facteur 3) >>>> rand(facteur1) x rand(facteur 2) x rand(facteur 3)

par contre on peut après imaginer un deuxième rand pour expliquer (juste du texte) le truc aberrant (pas probable) qui s'est passé

RE: Intégration de l'aléatoire - Xenos - 29-06-2017

Il n'y a pas d'aléatoire au sens qu'il n'y a pas d'indéterminisme pour le MdJ. Si le MdJ ne regarde pas le contenu de la table avant de l'uploader dans le jeu, alors, oui, c'est à peu près pareil que balancer du random. Mais s'il l'observe et intervient dessus, là, cela change la donne. Pour moi, le random, c'est comme si le MdJ d'un JDR ne pouvait pas décider de tout, et qu'un autre mec venait lui changer ses règles sans prévenir. Changer les règles des joueurs, c'est le boulot du MdJ. Changer ce que fait le MdJ et ses choix, c'est le boulot l'aléatoire. Et je trouve cela... pas terrible :/

Citation :le concepteur du jeu maitrise toutes les issues possibles mais pas quand elles arriveront

Expérimentalement, je peux donc te dire que c'est très très compliqué de réussir cela, voire impossible, car l'aléatoire a souvent (voire toujours) tendance à se télescoper. Si, à chaque arbre de la foret, tu as une chance sur deux de rencontrer un ennemi (peu importe la proba en fait), alors le MdJ ne maîtrise rien des issues possibles car *toutes* sont possibles: tu peux avoir une partie où tu feras face à un ennemi tous les 2 mètres, et une autre partie juste vide. Ce sera très improbable, certes, mais possible. Et là, le cas est simple: dans un cas plus complexe, avec de l'aléatoire "un peu partout mais pas beaucoup" (ie: façon ECLERD, où chaque formule a un random de +/-5%) alors les issues possibles sont trop nombreuses pour être maîtrisées par le MdJ (et souvent, encore moins par les joueurs :/ ).

Et le reste de ta description correspond alors à l'évolution d'un jeu contenant des humains, et sensible aux variations. Tiens, par exemple, j'ai refais le petit jeu du Yack https://xenos.reinom.com/deviantart/cynderheart-game/game.html J'en ai viré l'aléatoire. Je maîtrise donc plutôt bien les premiers lapins qui apparaissent, mais après, en fonction des actions du joueur, la suite finit par différer. Comme les échecs: si tu joues exactement les mêmes coups, t'auras l'exacte même partie. Mais la probabilité que les humains jouent les mêmes coups est très faible (l'aléatoire vient des décisions humaines).

2) Le problème, c'est ce qu'il se passe quand tutu es battu alors qu'il avait 95% de chances de victoire. Quand on est du côté de toto, vainqueur, ça va, quand tu joues Tutu, t'es honnêtement prêt à recommencer des jours/semaines/mois voire années de jeu juste pour avoir perdu sur un coup du sort? Moi, non. Et je pense que beaucoup de joueurs se mettraient alors à harceler les gros, même avec 1% de chances de gagner, car s'ils jouent assez, il y aura bien un petit qui battra le gros.
L'aléatoire risque d'amener du coup des "triches" où les joueurs tentent de chopper les évènements très bénéfiques et à très faible probabilité.

3) Cela plaide plutôt en faveur de l'absence d'aléatoire donc... Car dans un tel cas, Dieu ou le MdJ peut recréer les conditions, et voir ce qu'il s'est passé pour savoir comment améliorer le gameplay. Mais côté joueur, toto peut-il refaire les mêmes conditions que tutu? Là, ce qui entre en compte, c'est que le jeu évolue dans le temps. Par exemple, après un combat avec des caractéristiques précises, les combattants auront gagné de l'expérience: jamais les conditions exactes de ce combat ne pourront être réunies de nouveau par les joueurs (mais pas le MdJ, oui, en local par exemple). C'est un choix du gamedesigner que de donner cette opportunité de "rejouer" une scène du jeu.

4) Le problème, c'est que cela te semble facile à maîtriser dans le cas du RPG et de l'item trouvée sur un cadavre. Mais cela se complexifie quand tu prends du recul. Ok, tu peux maîtriser ton aléatoire pour ne pas mettre la cote de mailles sur l'asticot. Mais si tout ton donjon est aléatoire, tu arrives à des situations où le joueur tue l'asticot, ce qui fait tomber la pomme de l'arbre (10% de chances), qui tombe sur une trappe en bois (10%) et l'ouvre, ce qui libère un dragon (5%). Je ne sais plus comment s'appelle ce genre de phénomène (une chaîne de Markov? ... hum... pas sûr... j'essaierai de retrouver): la chaîne de petits aléas n'est mathématiquement *pas* maîtrisable le jour où l'évènement totalement improbable se déclenche.

5) Ce qui rajoute de la complexité... Je trouve que cela n'en vaut pas le coup (surtout sur nos jeux qui ont déjà du mal à exister en essayant d'être simple)

6)

Citation : aka rand( facteur 1 x facteur 2 x facteur 3) >>>> rand(facteur1) x rand(facteur 2) x rand(facteur 3

Ca, j'ai pas compris ce que tu voulais signifier?

Sinon, mouais... A l'inverse, je trouve que l'absence d'aléatoire permet de faire cela plus facilement, car tu peux ou bien faire une explication simplifiée, masquant des paramètres, et donnant au joueurs des probabilités de résultat, ou bien donner une explication complète et exhaustive, avec un résultat précis (voire, laisser le joueur crafter et chercher cette explication exacte lui-même, perso, je trouve que cette dernière approche amène tout un pan de nouveaux joueurs qui peuvent participer à la popularité d'un jeu bien mieux que les joueurs lambdas: un joueur qui "rétro-engineer" un jeu aura envie de partager ses découvertes, et pourrait entraîner d'autres joueurs comme lui à faire de même).

Je vais prendre un exemple: disons que tutu a 100PV et toto 10PV. Toto attaque Tutu et lui cause des dégats. On va dire que les deux persos ont des caractéristiques: PHabileté, PForce, PChance (rien n'interdit de nommer une caractéristique ainsi: elle est déterministe, c'est une grandeur comme une autre, mais je l'appelle ainsi, parce que j'aime le RP), PExpérience.
Je peux alors l'expliquer de plusieurs façon:

• La carrée:
toto A(10PV, 5PH, 20PF, 50PC, 10PE) vs tutu D(100PV, 10PH, 10PF, 10PC, 10PE) = (PV_A / PV_D)*EXP(-PH_A/PH_D)*PC_A/100*(1-PC_D/100) + (PC_A+PE_A)/(PC_D+PE_D) = 10/100*EXP(-5/10)*50/100*(1-10/100) + (50+10)/(10+10) = 3 points de dégat
Oui, c'est lourd comme formule. Mais qui demande au joueur de la calculer avant d'attaquer? Personne. Le joueur *peut* faire ce calcul s'il en a envie (c'est d'ailleurs, me semble-t-il, intéressant de favoriser les joueurs qui s'investiraient ainsi). Rien ne l'y oblige. Toto peut y aller "au pif" et "à l'instinct", en se disant qu'il a vachement moins de stats que son adversaire, donc que le duel sera *certainement* perdu (bon, ok, du coup en pratique, Toto fait le contraire: son instinct lui dit de ne pas aller à la marave). Cette question d'aléatoire, de chance et de probabilité se fait alors non pas dans le serveur (dans le jeu), mais dans la tête du joueur.

• La résumée:
Je peux aussi faire le calcul par le serveur, en *prévision*, et dire à Toto "là, tu vas faire 3 pts de dégâts: t'y vas ou pas?". Cela peut donner un jeu abordable et agréable: le joueur se contente de prendre des décisions par rapport à ce que le jeu lui révèle (on est encore proche de la méthode carrée, la différence étant que le joueur ne s'emmerde pas à faire des prévisions: le jeu les fait pour lui).

• La brouillée
Le serveur peut également brouiller le résultat avant de le donner au joueur, et rajouter une légère déviation, non aléatoire (par exemple, multiplier par (1+SIN²(numero_du_tour/10))/2. Le joueur n'aura pas tout à fait le résultat exact du combat, mais une approximation. C'est ici important de ne *pas* mettre de l'aléatoire, surtout si le joueur peut demander cette prévision plusieurs fois sans altérer les conditions du combat. En effet, si la déviation était aléatoire, le joueur pourrait demander des centaines de prévisions, et faire une moyenne pour avoir une bonne idée de ce qui l'attend réellement. C'est un cas qui s'est d'ailleurs posé sur la 2nde version d'Eclerd (https://beta.eclerd.com): je voulais faire des sondages avec un brouillage aléatoire, mais en fait, il suffit de demander 10 sondages pour avoir la bonne réponse... Impossible de maîtriser alors l'effet de l'aléatoire sur le gameplay :/ (sauf éventuellement à rendre les sondages payants, bref, à devoir éviter la situation de "le joueur peut demander cette prévision plusieurs fois sans altérer les conditions")

• La probabiliste
Enfin, on peut faire exactement comme la version brouillée, mais en présentant ce brouillage comme une "probabilité". En pratique, le serveur ici *sait*que l'attaque fera 3 points de dégât. Le MdJ le *sait* (et il a donc conçu son scénario de jeu en conséquence). Mais le joueur, on va lui dire "tu as 20% de chances de faire 5 pts de dégât et 80% de faire 3pts" (on peut ergoter ma façon de le calculer/formuler).

PS: ne pas se méprendre hein si quelqu'un lit cette conversation: *j'adore*. C'est, je trouve, un des rares topics où on se concentre vraiment sur le coeur d'un jeu, et sur ce qui les différencie des autres projets (parce que bon, les archi, les langages, tout ça, c'est beau, mais cela s'appliquerait tout aussi bien aux CMS et autres ERP).
Perso, je ne cherche pas franchement à te convaincre, Ter, et je ne pense pas être dans l'optique de me laisser convaincre. Mais écrire ainsi ma réflexion, cela m'aide à la comprendre et à la poser, et à trouver pourquoi j'ai cette tendance à haïr l'aléatoire (je retiens facilement les foirages des mauvais tirage, et ma façon outrageuse de les ignorer ou de tricher avec, soit en zappant le combat Loup Solitaire que j'aurai perdu juste parce que le hasard en a décidé, soit en recommençant un niveau de jeu vidéo jusqu'à temps que ça passe, par chance).

PPS: Note que les formules déterministes deviennent également inversibles aisément pour le MdJ. Si je reprends l'exemple de l'attaque de Toto sur Tutu et des points de dégats, je peux faire en sorte d'établir la formule qui construira un ennemi que Toto pourra (ou non, suivant mon besoin) battre. En injectant de l'aléatoire dans la formule, cela aurait été plus délicat, et je n'aurai pas eu la maîtrise, en tant que MdJ, sur le fait que Toto battra (voire puisse battre) l'ennemi ainsi crafté. En fait, dans le cas de l'aléatoire, le MdJ "délègue" alors à la chance la réflexion et la décision sur "Toto battra-t-il cet ennemi?". Ce qui oblige le MdJ à s'adapter aux coups du sort (et non pas le joueur à s'adapter aux paramètres auxquels il n'avait pas pensé).

PPPS: (c'est pour ça que je disais "ce débat m'aide à structurer ma pensée")
En fait, quand je dis "jeu déterministe sans aléatoire", j'ai l'impression que tu entends "le joueur va devoir tout planifier et tout dérouler sans aucune surprise, ce qui sera chiant". Mais ce n'est pas une conséquence obligatoire du déterminisme. En pratique, le joueur a le choix:
→ Il planifie en gros, et après, ben, il se lance et advienne que pourra: on retrouve le même "gout du risque" que dans l'aléatoire classique (auquel tu fais référence je dirai?)
→ Il planifie tout, prend tous les paramètres en compte, établit son plan et le déroule, sans aucun accroc.
Déjà, il n'y est pas obligé. Mais même s'il le choisit, il y a une composante que tu perds de vue: en tant que joueur, le mec n'est pas certain de n'avoir rien oublié. Quand tu fais ta planification, et que tu déroules ton plan, les imprévus existent aussi. Non pas parce que de l'aléatoire est entré en jeu (= non pas que des trucs imprévisible même d'un Dieu n'existe), mais simplement parce que tu as oublié un paramètre à un moment, ou que tu l'as approximé, ou tout simplement parce que la situation a changé (un autre joueur lance une attaque à laquelle tu n'avais pas pensé). Je trouve d'ailleurs au contraire que dérouler son plan prévisionnel est beaucoup plus angoissant que de se lancer dans un truc où on sait que, de toute façon, y'a de la pifométrie. Quand mon plan s'est parfaitement déroulé, je suis aux anges, et cela donne un effet de "coucou Suisse" et de belle mécanique vraiment jouissif. A l'inverse, si un élément foire, je ne pleurerai pas sur la table: je me dirais "merdre, j'ai donc oublié un truc quelque part... mais quoi?" et boum, je repars dans l'exploration du jeu, dans la tentative de comprendre ce qui a foiré. Ou alors, je peux m'en ficher et me dire "bon, pas de chance".

L'astuce est là: pour le joueur, si le jeu a mis du hasard, alors il y a du hasard, point. Si le jeu n'en a pas mis, alors le joueur peut croire que c'est le hasard qui est entré en jeu, ou bien il peut essayer de comprendre ce qui s'est passé. Cela laisse finalement plus d'opportunités et de choix au joueur.

PPPPS: Un évènement improbable à fortes conséquences, qui émergera quasi-forcément de tout gameplay aléatoire un tant soit peu intéressant (prouvez-moi le contraire?!) s'appelle "un cygne noir" https://fr.wikipedia.org/wiki/Th%C3%A9orie_du_cygne_noir
Ce qui me semble important à retenir est alors:

Citation :L'impossibilité de calculer la probabilité de ces événements rares à l'aide de méthodes scientifiques (due à la nature même des très faibles probabilités).

Qui tent à dire

Citation :le MdJ (ou Dieu) ne *peut* pas (au sens mathématiques du terme) maitriser son gameplay et les possibilités du jeu

RE: Intégration de l'aléatoire - Ter Rowan - 30-06-2017

(29-06-2017, 11:41 PM)Xenos a écrit : 2) Le problème, c'est ce qu'il se passe quand tutu es battu alors qu'il avait 95% de chances de victoire. Quand on est du côté de toto, vainqueur, ça va, quand tu joues Tutu, t'es honnêtement prêt à recommencer des jours/semaines/mois voire années de jeu juste pour avoir perdu sur un coup du sort? Moi, non. Et je pense que beaucoup de joueurs se mettraient alors à harceler les gros, même avec 1% de chances de gagner, car s'ils jouent assez, il y aura bien un petit qui battra le gros.
L'aléatoire risque d'amener du coup des "triches" où les joueurs tentent de chopper les évènements très bénéfiques et à très faible probabilité.

je ne comprends pas le comportement du bcp de joueurs qui se mettraient à harceler le gros. soit l'impact de la défaite est importante (cf ce que tu décris dans le "dégout" du joueur de tutu perdant) et alors bcp de joueurs vont perdre (stratégie pourrie) soit l'impact est faible pour tutu, et rentable pour lui potentiellement

A l'inverse si tutu est à 100% sur de gagner, on se retrouve avec le gros bill qui tape sur le petit sans aucun risque histoire de farmer

(29-06-2017, 11:41 PM)Xenos a écrit : 3) c'est que le jeu évolue dans le temps. Par exemple, après un combat avec des caractéristiques précises, les combattants auront gagné de l'expérience: jamais les conditions exactes de ce combat ne pourront être réunies de nouveau par les joueurs (mais pas le MdJ, oui, en local par exemple). C'est un choix du gamedesigner que de donner cette opportunité de "rejouer" une scène du jeu.

C'est un choix de design que tu décris, le "jamais" n'est pas vrai systématiquement : xp ne veut pas dire amélioration systématique du perso, on peut très bien se retrouver avec besoin de réussir 100 actions pour que le score progresse donc 100 actions identiques, au résultat identique ? (on peut même imaginer, 100 actions avant qu'un tirage aléatoire décide si oui ou non la compétence progresse, voire pour réduire la variance, un tirage aléatoire avec la proba qui progresse de réussir a chaque tirage)

(29-06-2017, 11:41 PM)Xenos a écrit : 4) Le problème, c'est que cela te semble facile à maîtriser dans le cas du RPG et de l'item trouvée sur un cadavre. Mais cela se complexifie quand tu prends du recul. Ok, tu peux maîtriser ton aléatoire pour ne pas mettre la cote de mailles sur l'asticot. Mais si tout ton donjon est aléatoire, tu arrives à des situations où le joueur tue l'asticot, ce qui fait tomber la pomme de l'arbre (10% de chances), qui tombe sur une trappe en bois (10%) et l'ouvre, ce qui libère un dragon (5%). Je ne sais plus comment s'appelle ce genre de phénomène (une chaîne de Markov? ... hum... pas sûr... j'essaierai de retrouver): la chaîne de petits aléas n'est mathématiquement *pas* maîtrisable le jour où l'évènement totalement improbable se déclenche.

effet papillon ? mais là aussi tu complexifies l'idée :

si rencontre asticot voulu par le concepteur alors le concepteur décide que le dragon a une chance d'apparaitre
si la rencontre est aléatoire (un asticot, un ogre, etc...) alors la rencontre a lieu et c'est tout, quel intérêt de rajouter une chance de rencontrer le dragon ? (autant mettre le dragon dans la liste des rencontres potentielles) sauf si c'est clair dans le jeu (quete, lore, ...) qu'il faut tuer des asticots pour espérer invoquer le dragon, mais la encore c'est un choix décidé.

asticot --> pomme --> trappe --> dragon = complexité non maitrisée
asticot --> dragon = simple = choix du concepteur

(29-06-2017, 11:41 PM)Xenos a écrit : 5) Ce qui rajoute de la complexité... Je trouve que cela n'en vaut pas le coup (surtout sur nos jeux qui ont déjà du mal à exister en essayant d'être simple)

non, c est la base du gd : que faut il pour jouer correctement. ne pas le faire revient a faire des formules sans comprendre un minimum les maths (je parle pas de ton niveau, mais d'un niveau raisonnable)

(29-06-2017, 11:41 PM)Xenos a écrit : 6)
Citation : aka rand( facteur 1 x facteur 2 x facteur 3) >>>> rand(facteur1) x rand(facteur 2) x rand(facteur 3
Ca, j'ai pas compris ce que tu voulais signifier?

je préfère rand( hasticot, orc, pomme, trappe, dragon) -> fin de la chaine
à
rand(asticot) -> rand(pomme) -> rand(trappe) -> rand(dragon) -> fin de la chaine

Pour tes formules :

• La carrée:
toto A(10PV, 5PH, 20PF, 50PC, 10PE) vs tutu D(100PV, 10PH, 10PF, 10PC, 10PE) = (PV_A / PV_D)*EXP(-PH_A/PH_D)*PC_A/100*(1-PC_D/100) + (PC_A+PE_A)/(PC_D+PE_D) = 10/100*EXP(-5/10)*50/100*(1-10/100) + (50+10)/(10+10) = 3 points de dégat

j'aime la formule (je l'aurais pas trouvée) mais j'aime pas le principe : ce sera toujours 3pv, sauf si toto et tutu évoluent différemment

• La résumée:
Je peux aussi faire le calcul par le serveur, en *prévision*, et dire à Toto "là, tu vas faire 3 pts de dégâts: t'y vas ou pas?". Cela peut donner un jeu abordable et agréable: le joueur se contente de prendre des décisions par rapport à ce que le jeu lui révèle (on est encore proche de la méthode carrée, la différence étant que le joueur ne s'emmerde pas à faire des prévisions: le jeu les fait pour lui).

j'aime l'idée de "t'y vas ou pas", c'est ce que je voulais faire MAIS avec une information probabiliste (donc derrière aléatoire) : t'as x% de chance de gagner OU t'as quand même l'impression que c'est pas gagné si tu y vas (% gp ne veut pas forcément dire %rp)
toujours pareil j'aime pas le c'est 3 dans tous les cas

• La brouillée
Le serveur peut également brouiller le résultat avant de le donner au joueur, et rajouter une légère déviation, non aléatoire (par exemple, multiplier par (1+SIN²(numero_du_tour/10))/2. Le joueur n'aura pas tout à fait le résultat exact du combat, mais une approximation. C'est ici important de ne *pas* mettre de l'aléatoire, surtout si le joueur peut demander cette prévision plusieurs fois sans altérer les conditions du combat. En effet, si la déviation était aléatoire, le joueur pourrait demander des centaines de prévisions, et faire une moyenne pour avoir une bonne idée de ce qui l'attend réellement. C'est un cas qui s'est d'ailleurs posé sur la 2nde version d'Eclerd (https://beta.eclerd.com): je voulais faire des sondages avec un brouillage aléatoire, mais en fait, il suffit de demander 10 sondages pour avoir la bonne réponse... Impossible de maîtriser alors l'effet de l'aléatoire sur le gameplay :/ (sauf éventuellement à rendre les sondages payants, bref, à devoir éviter la situation de "le joueur peut demander cette prévision plusieurs fois sans altérer les conditions")
pour moi tu es sur une forme d'aléatoire pour le joueur : numero du tour, sauf que sur un tour t'auras toujours le même résultat donc : une fois que j'ai compris ça, je tente un coup, le résultat est bénéfique sur mon tour ? je le retente tant que je peux. Le résultat est négatif ? j'attends le prochain tour.
ca revient exactement au même qu'un rand ce n'est pas de l'aléatoire mais du pseudo aléatoire techniquement, à une nuance près: le tirage n'est pas identique sur ton tour
après si sur eclerd tu as besoin que de 10 sondages pour avoir la "vérité" c'est ton choix de formule

tu peux très bien faire l'effet trump :
tu as tes sondages, et pour le vrai tir ... tu fais un tirage qui a x% de chances de ne pas tenir compte de la bonne réponse
ou bien c'est que ton brouillage n'était pas assez fort( si 10 c est pas assez), ou encore que tu devrais imaginer une évolution de la vérité dans le temps

• La probabiliste
Enfin, on peut faire exactement comme la version brouillée, mais en présentant ce brouillage comme une "probabilité". En pratique, le serveur ici *sait*que l'attaque fera 3 points de dégât. Le MdJ le *sait* (et il a donc conçu son scénario de jeu en conséquence). Mais le joueur, on va lui dire "tu as 20% de chances de faire 5 pts de dégât et 80% de faire 3pts" (on peut ergoter ma façon de le calculer/formuler).

bah dans ce cas, pkoi ne pas faire un rand(100) ?

PS: pareil (enfin j'adore pas, :p mais ca me fait réfléchir, et je récupère des formules hahaha)

PPS: oui c est clair c' est plus (+) réversible, c'est après une question d'approche, je suis prêt à prendre le risque de rater mon choix en donnant grosso modo un adversaire au niveau de ce que je veux, mais advienne que pourra, je ne veux pas maitriser l'issue, sinon autant faire une partie de rp par forum

PPPS: j'entends bien, mais tu t'adresses dans cette approche qu'a des joueurs qui vont se poser pour chercher à s'améliorer. les autres vont s'emmerder. Dans mon approche (si l'aléatoire ne fait pas tout et n'importe quoi) j'espère ne perdre qu'une partie des joueurs auxquels tu t'adresses

PPPPS: oui c'est vrai je suis d accord avec ta conclusion
apres charge au concepteur si il constate une divergence forte par rapport a son scenario de :
-ne rien faire
-introduire un événement majeur scenaristique (explosion de mana ? attaque d'extraterrestre ? eruption du volcan islandais) pour corriger le tir . Soit en dur : j'efface l'effet au moins partiellement, soit en mou (?!) je lance un nouveau truc qui devrait corriger le tir, et on verra ce qui se passe (quitte a prendre un risque sur l'univers)

RE: Intégration de l'aléatoire - Xenos - 30-06-2017

2) Tu as ce comportement de farming indépendamment de l'aléatoire. Le comportement de farming infini n'est pas là "parce que Tutu a 100% de chances de gagner", mais "parce Tutu a 0 dégats". Quand tu injectes de l'aléatoire, Tutu (et le MdJ) ne savent pas trop s'ils auront des dégats, ce qui "fix" ton problème. Dans le cas de l'absence d'aléatoire, le fix peut alors être *décidé* par le MdJ: si la simulation (ou si le calcul analytique du MdJ, plus performant mais qui revient au même) si "0 dégât pour Tutu", alors le MdJ peut décider que Toto n'est pas attaquable. Il devient en fait (à mon sens) bien plus simple de maîtriser les règles du jeu pour l'équilibrer (en tant que MdJ).

3) Justement: tu peux donc décider, en tant que *créateur* jeu, de faire un jeu répétable (façon le Yack; c'est souvent adapté aux jeux par parties), ou un jeu non répétable (souvent bien plus étoffés, et adaptés aux jeux persistants).

4/5) Je n'arrive pas justement à expliquer autrement que cette apparente simplicité n'est pas réelle. Ton asticot, tu le combats sur la base du hasard. Mais du coup, tu ne maîtrise plus combien d'asticot le joueur devra combattre (le Mdj n'est plus le créateur, mais le PC, et le créateur va s'éreinter à faire du PC un MdJ "intelligent"). Pour des jeux lourds et pros, admettons, ça se tente. Pour les jeux web amateurs...

6) Dans ce cas, tu dois travailler avec un rand(tout le jeu) car ton rand( hasticot, orc, pomme, trappe, dragon) va se téléscoper avec le prochain rand() du niveau ou de l'étape de jeu suivante. Tu auras donc rand(asticot, orc, pomme, trappe, dragon) * rand(chien de guerre, vampire, cachot) * rand(mage, sorcier, poulet)...

j'aime pas le c'est 3 dans tous les cas
Tout vient du fait que, de base, c'est le MdJ qui sait que c'est 3, et qu'il est alors à sa discrétion de le révéler ou non au joueur Smile

une forme d'aléatoire pour le joueur
Et c'est exactement le but de la manoeuvre: le déterminisme est vu du MdJ, car cela simplifie son boulot (je trouve) un peu comme un langage qui serait capable de te dire, à la compilation, qu'il n'y aura aucun bug à l'exécution, mais ce déterminisme n'est pas forcément vu du joueur (le MdJ est libre de le montrer ou pas). S'il n'est pas vu, pour le joueur, c'est kiff kiff. Mais pour le MdJ, le travail est simplifié (surtout, clarifié car non probabiliste).

tu fais un tirage qui a x% de chances de ne pas tenir compte de la bonne réponse
Le résultat sera le même *pour le joueur*, mais sera bien plus compliqué à piloter par le MdJ, car il doit alors "faire équipe" avec ce que le tirage réel donnera. Les probas ne sont efficaces que sur des grands nombres, pas sur un tirage spécifique. Or, à moins d'avoir 10000 instances du jeu, tu n'auras au final qu'un seul tirage de ta proba (ou très peu). C'est pour cela que, dans un jeu par parties façon le Yack, l'aléatoire n'est pas forcément dramatique. Dans un jeu persistant en revanche, l'impact est plus grand.

bah dans ce cas, pkoi ne pas faire un rand(100) ?
Car faire un rand ne change rien *pour le joueur* mais rend le MdJ dépendant du tirage de dés. Quand le MdJ est présent en continue (comme un JdR), il a quelques facilités à s'adapter (mais bon, dur quand même parfois, quand le dé ne te sors que des échecs critiques). Quand il n'est pas là en continue (type jeu web persistant), c'est plus hardu.
Tu peux concevoir ce déterminisme comme un MdJ qui connaîtrait le résultat du dé avant que le joueur ne le lance: libre au MdJ d'en avoir rien à f**tre, ou d'en tenir compte et de se dire "bon, en fait, je ne vais pas faire rencontrer un dragon au joueur, plutôt une poule". Tu peux t'en approcher avec du rand, en faisant une "simulation" par le jeu puis en la déroulant, mais alors, le MdJ est le PC, et tu tentes de l'éduquer pour que lui décide d'amener une poule au lieu du dragon.

PPS: réversibilité
C'est l'atout du non-aléatoire: le MdJ peut se moquer de prévoir les choses (et cela revient au RAND), ou décider de les prévoir. Le déterminisme est, en somme, "plus puissant".

PPPS: les joueurs cherchent les fomules
Non, je ne perds pas nécessairement les joueurs qui ne veulent pas réfléchir, car le déterminisme du MdJ *n'oblige pas* les joueurs à réfléchir Wink

Ceux qui le font auront certainement plus de "chances" de gagner, mais *s'ils le font bien* uniquement. Le mec qui réfléchit mais s'est gourré dans un paramètre se dira "je fonce, j'ai le succès assuré!" et boum, non, raté. A l'inverse, celui qui prévoit, se dit "merde, je vais forcément perdre... alors j'y vais quand même: avec un peu de "chance", j'ai fait une erreur de planning" peut réussir.

PPPS: le cygne noir
Effectivement, le MdJ peut choisir de s'adapter. Mais cela fait une charge de travail supplémentaire. Note qu'il peut aussi devoir s'adapter dans le cas du déterminisme, s'il a fait comme le joueur précédent (celui qui avait la flemme de réfléchir): le MdJ peut rajouter une carte dans un jeu, ou un donjon sans tout calculer pour être certain de l'équilibre. Le déterminisme (et le fait que le MdJ connaisse tous les paramètres du jeu [sauf l'aléatoire humain des joueurs! qui peut l'oblige à s'adapter]) offre le choix au MdJ: je prévois tout ? Ou je m'adapte?

PPPPS: Bonne idée la couleur. Désolé, je voulais mettre "green" comme couleur parce que rouge clash un peu, mais le green ne se voit pas du tout >.>

RE: Intégration de l'aléatoire - Ter Rowan - 30-06-2017

PPPPS: oui c est malheureux le vert se voit jamais mais je ne m'offusque pas du rouge

bon globalement, je pense que sans sang neuf, on a fait le tour du débat à deux, on ne se convaincra pas :p

j'attends de voir d'autres avis pour réagir

RE: Intégration de l'aléatoire - CaptainJS - 30-06-2017

Salut à vous deux (et aux autres qui lisent),

Je me lance parce que votre discussion est très intéressante et je pense qu'il n'y a pas de solution miracle, mais que les 2 sont intéressantes.
Bon déjà mes exemples concrets :

1/ Battle Arena (jeu de combat de gladiateurs, vue de dessus, actions en mode texte) : les formules ont été données par le MdJ et elles contiennent de l'aléatoire au niveau du % de touche de l'ennemi, puis des dégâts (bornes min et max fixées). Mon constat est qu'on rage un peu quand on fait un mauvais tirage, on rage un peu quand l'ennemi survit avec 2 PV mais finalement ça passe, et perso je trouve ça normal que sur 2 situations identiques on puisse ne pas avoir le même résultat, ça correspond assez bien à l'idée du coup / de l'échec critique

2/ Shop Heroes (jeu de craft) : il y a un bout d'aléatoire dans la fusion d'item. En gros on fusionne 2 items solides pour 100% de chances d'obtenir un item super, mais si on fusionne des items supers pour un faire un impeccable on peut soit :
- en fusionner 2, pour une chance de 75%
- en fusionner 3, pour une chance de 100%
Et pareil à plus haut niveau, donc moi j'en crafte par 2 et quand la fusion échoue bah ça me soule mais c'était connu et annoncé au départ donc c'est un risque que j'ai pris Big Grin

Du coup votre débat j'ai l'impression qu'on peut le résumer à :
- soit le MdJ veut faire les choses proprement il fait toutes les formules avec des paramètres cachés : ces formules pourront être découvertes par les joueurs (avec les aspects positifs ou négatifs suivant chacun)
- soit le MdJ ne veut pas tout décider et il met de l'aléatoire : il y a des risques, c'est plus compliqué à gérer mais plus simple à mettre en place
Quand je jouais à Travian au bout d'un moment j'ai pas pu résister à créer un fichier Excel pour essayer de faire le meilleur démarrage possible , parce que tout était connu, donc c'était grisant d'avoir le start parfait, mais après ça a enlevé une partie de l'intérêt du jeu, du moins du début du jeu.

C'est assez marrant finalement que Xenos parle de MdJ parce que dans les jeux de rôles on utilise beaucoup le hasard avec les jets de dés, et finalement si les dés devaient disparaitre ce serait assez étrange que tout soit maitrisé par des formules : ça a un côté assez "réel" de ne pas tout maitriser, comme dans la vraie vie en quelque sorte.
Je trouve personnellement que mettre de l'aléatoire dans un lancer pour un coup ou le calcul des dégâts est plus intéressant que des formules fixes avec des paramètres cachés, mais cet hasard doit être utilisé avec parcimonie sous peine d'effets cumulatifs désastreux ...
Perso je partirais plutôt sur un hasard "corrigé", c'est à dire un jet avec des bornes mobiles suivant les tirages précédents, histoire que les joueurs n'aient pas l'impression d'être floués.

Par ailleurs l'aléatoire est "presque" nécessaire quand le MdJ veut jouer à son jeu : typiquement un donjon créée par le MdJ n'est pas intéressant à jouer, mais si la génération du donjon possède de l'aléatoire alors à chaque fois on a un défi différent (que l'on peut pondérer afin d'éviter les runs trop faciles ou pas assez).

RE: Intégration de l'aléatoire - Xenos - 01-07-2017

Petite curiosité mathématique du coup, qui reste dans le thème: si l'aléatoire se cumule au fil du jeu, alors la médiane s'écroule ou la moyenne s'envole

Modèle géométrique
Voici un modèle dans lequel on part d'une valeur 100 au tour 0, et à chaque tour, cette valeur est altérée de -5% à +5% (l'altération exacte est aléatoire à chaque tour). Donc:

Code :
Valeur(tour suivant) = Valeur(tour précédent) * (1 + rand(-5%..+5%))

En abscisse (horizontale), on a la valeur finale de chaque simulation et en ordonnée (verticale), le % de résultats qui sont dans cet intervalle à la fin des simulations. Par exemple, sur les 5000 simulations effectuées, 27% présentaient une valeur finale comprise entre 96 et 100.
On constate que, après 10 tours cumulatifs, la moyenne (somme des valeurs finales divisée par le nombre total de valeurs simulées) et la médiane (valeur finale "au milieu" des autres: autant de résultats inférieurs que supérieurs) des 5000 simulations est de 100, et près des deux tiers des simulations (63.1%) ont une valeur finale proche de 100 (compris entre 95 et 105).

Si on augmente le nombre de tours (= plus on avance dans le temps), alors on s'aperçoit que la probabilité d'être resté au niveau 100 est de plus en plus faible (30%): ou bien on a totalement dévié vers +150 ou bien on s'est écroulé vers 50. En revanche, la moyenne reste aux environs de 100. Vous avez peut-être constaté que la médiane a légèrement baissé, mais on peut éventuellement attribuer cela au hasard

Si on continue à avancer dans le temps (on fait plus de tours successifs) alors on s'aperçoit que cette tendance se confirme.

Au final, si on se projette sur 1000 tours, on constate que:
• La moyenne est restée à 100 (ce qui pousse l'instinct à croire faussement que l'aléatoire n'a pas déséquilibré le jeu)
• La médiane a dégringolé à 85 (ce qui veut dire que la moitié des tirages ont une valeur finale nettement inférieure à 100)
• La probabilité d'être aux environs de 100 est très faible (le jeu s'est totalement dispersé)

Ce modèle cumulatif est *très* courant. Dès l'instant où le jeu n'est pas *intégralement* réinitialisé (et si vous avez un aléatoire qui impacte un paramètre), alors vous avez du cumulatif. Par exemple, si je fais apparaitre des ennemis qui ont entre 40 et 60PV, on pourrait se dire "ce n'est pas cumulatif: les PV d'un ennemi n'influent pas sur les PV du prochain!". Mais les PV de chaque ennemi influent sur les PV du joueur, et l'aspect cumulatif se trouvera là. Idem si vous avez un RPG avec des donjons "indépendants": si l'équipement, les PV, les équipiers, etc sont conservés d'un donjon à l'autre, alors il y a un effet cumulatif.

Modèle arithmétique
Alors, cet effet cumulatif n'est peut-être pas de type géométrique (Valeur(T+1) = Valeur(T)*(1+RAND)), mais de type arithmétique, c'est à dire que la variation aléatoire porte sur un "+" et non sur un "*":

Code :
Valeur(T+1) = Valeur(T)+RAND(-5.0, +5.0)

.

Je me permet d'émettre des doutes sur ce genre de modèle car il est très rare selon moi (le modèle géométrique ne souffre pas du changement d'échelle: on peut tout multiplier par une constante, cela ne modifiera rien; le modèle arithmétique ne permet pas cela: si la valeur de base du modèle géométrique est 1000 et non 100, alors rien ne change, mais si la valeur de base du modèle arithmétique est 1000 et non 100 alors le RAND(-5, +5) n'aura pas du tout le même effet), mais n'ayant pas de preuve, essayons de l'analyser aussi, selon le même schéma.

Au bout de 10 tours, dur de tirer des conclusions, mais l'histogramme ressemble furieusement au précédent... Peut-être cela ne change rien de choisir ce modèle?

Il semble en fait que si: la médiane n'a effectivement plus tendance à s'effondrer

Etalé sur 1000 tours, le modèle arithmétique ne présente effectivement pas de variation de la moyenne ni de la médiane. Mais on a maintenant la présence de nombres négatifs, même si j'ai limité l'affichage aux nombres positions: la barre de gauche s'étale en fait dans les négatifs. De plus, la probabilité d'être resté aux environs de la valeur initiale 100 est toujours très faible.

Revenons au modèle géométrique (le premier, celui qui me semble bien plus courant). Comment expliquer l'effondrement de la médiane? Simplement en constatant que 100 + 5% - 5% != 100, car 100 + 5% = 105 et 105 - 5% = 99.75 (faites pareil dans l'autre sens, avec -5% puis +5% et vous tomberez sur le même résultat). Du coup, peut-on corriger cette déviation? Par exemple, en décentrant l'intervalle aléatoire, pour RAND(-5%, +5.26%)? (Note: Pourquoie 5.26%? Parce que 100 - 5% + 5.263% ~= 100)

Et bien, dans ce cas, la médiane va bien rester aux environs de 100... mais la moyenne va s'envoler ! En effet, l'intervalle n'est plus centré autour de 0%, mais autour de 0.13%, ce qui signifie qu'en moyenne, à chaque tout, la valeur 100 augmentera de 0.13%...

Il semble donc mathématiquement impossible de garder une moyenne et une médiane aux environs de 100, et ne parlons même pas de conserver une probabilité décente de rester aux environ de 100 (dans tous les cas, elle s'est effondrée).

Bilan
En conséquence, oui, à terme, l'aléatoire va ramener d'énorme déviations dans un jeu. On peut tenter de corriger ce phénomène, avec la notion "d'hasard corrigé" de CapitainJS, mais cela rajoute de la complexité, qui rajoute peut-être d'autres défauts au modèle auxquels on n'avait pas pensé...
Franchement, le coup de la médiane qui s'effondre et de la probabilité croissante de ne *plus* être autour de 100, vous y aviez pensé vous?! Smile

Sources (PHP)
Les sources: https://xenos.reinom.com/blog/rand-study/rand-study.7z

En revanche, je ne pense pas non plus que l'aléatoire soit nécessaire pour que le MdJ puisse jouer à son jeu. Je suis d'accord sur ce point si le jeu est scripté, le MdJ aura du mal à le rejouer (tout comme les joueurs: j'adore Dead Space, mais il est très scripté, ce qui rend moins amusant le fait d'y jouer deux fois de suite). Mais si le jeu est déterministe (sans aléatoire) sans être scripté (par exemple, un RTS sans aléatoire), alors je pense qu'il est parfaitement possible d'y jouer et d'y rejouer autant qu'on veut, qu'on ait été le créateur ou non du jeu.

RE: Intégration de l'aléatoire - niahoo - 01-07-2017

Tu peux résumer ton exemple de moyenne qui s'envole avec par exemple un calcul de dégats d'une epée 45-50 sur un pnj ayant 2000 HP ? Là j'ai rien pané.

RE: Intégration de l'aléatoire - niahoo - 01-07-2017

Heu ou sinon tu fais -5 +5 et pas des pourcentages et ça marche niquel. Ou alors autour de 5% du total de points de vie et pas de la vie courante par exemple. Faux problème.

RE: Intégration de l'aléatoire - Xenos - 01-07-2017

Heu, je te demanderai quand même de lire, niahoo, si tu veux réagir...

Citation :Modèle arithmétique [...] la variation aléatoire porte sur un "+" et non sur un "*": Valeur(T+1) = Valeur(T)+RAND(-5.0, +5.0)

Citation : le modèle arithmétique ne présente effectivement pas de variation de la moyenne ni de la médiane. [...] la probabilité d'être resté aux environs de la valeur initiale 100 est toujours très faible.

Là, sérieux, t'abuses, je trouve :/

Pour l'exemple du HP, tu prends un joueur a 100HP, et à chaque attaque contre un autre, il peut perdre jusqu'à -5% de vie (ou -5PV si tu prends le 2nd modèle) ou faire perdre 5% de vie à l'ennemi (ou lui cause 5 pts de dégat), qu'on peut modéliser par "l'attaquant gagne de la vie" au lieu de "le défenseur en perds".

Dans ce modèle, si tu te base sur des %, alors la moitié des joueurs auront moins de 85HP au terme de 1000 attaques aléatoires, même si la moyenne de la santé de tous les joueurs n'aura pas changée. Si tu veux éviter cela, et avoir la moitié des joueurs avec au moins 100HP au terme de leurs 1000 assauts, alors il te faudra biaiser l'intervalle (-5%..+5% devient -5%..+5.26%) et dans ce cas, la moitié des joueurs aura 100HP ou moins au terme de ces assauts... mais la moyenne de tous les joueurs sera de 125HP !

Si tu te bases sur des +/-5PV, tu n'auras pas cet effet, mais tu n'auras quasiment pas de joueur aux alentours de 100HP: tous seront soient morts, soient "hyper-boostés" en vie (c'est à dire qu'ils auront massacrés tous les ennemis). Le skill n'est pas du tout intervenu pour rappel, juste le pif.