+- 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)
RE: Intégration de l'aléatoire - Ter Rowan - 28-06-2017
y a un truc que je ne comprends pas avec ta notion de fonction déterministe
donne moi un pseudo algo pour mon histoire de gland et d'écureuil (pas besoin de multiplier les variables mais s'il en faut trois quatre pas de soucis)
perso quand je dis aléatoire, je dis résultat = f( rand(100) ) avec f une gaussienne dont les paramètres seraient deux trois variables du jeu (aka : l'espérance moyenne en fonction de la compétence du joueur, la saison et la richesse de la forêt en gland)
RE: Intégration de l'aléatoire - Xenos - 28-06-2017
Sur Isometry, par exemple, j'ai
Citation :UPDATE map AS m
LEFT JOIN map_building AS mb ON mb.id_case = m.id
SET m.`type` = IF(
mb.id_building IS NULL AND (SIN(0.3*m.x+0.1*m.y) + SIN(0.6*m.x-0.4*m.y) + 0.6*SIN(0.2+0.1*m.y*m.x) - 0.25*SIN(0.4-2*m.y+1.5*m.x)) < -0.3, 'MER', 'PLAINE')
;
Pour l'initialisation du type de case (tu remplaces ça par des glands, c'est pareil). Bon, comme dit, à l'initialisation, l'aléatoire peut passer (de même que forger manuellement la carte). L'avantage de ne pas en user, c'est que:
• Je peux exécuter ce script en local et en prod, j'aurai forcément le même résultat (plutôt pratique pour éviter les surprises au déploiement), ce qui est franchement top
• Je peux rendre périodique la carte (intéressant pour éviter le "premier arrivé, premier bien placé"), ou apériodique (plus riche en choix, mais donc, favorisant potentiellement certains joueurs), suivant ma volonté de game designer
• Concevoir les choses aléatoirement pousse parfois à se reposer sur les statistiques pour avoir un jeu équilibré; le déterministe a l'avantage de permettre de forger manuellement/par l'aléatoire/par une fonction bien choisie sa carte (ie: les probas n'interviennent pas pour équilibrer le jeu)
• SQL peut faire d'énormes optimisations en considérant une fonction déterministe (après, on peut "bluffer" et dire qu'une fonction stockée ayant un RAND() est en fait déterministe, cela revient à dire "pour cette requête, RAND() sera toujours identique si les entrées de la fonction sont les mêmes"; c'est un peu tordu, mais envisageable; une fonction purement et classiquement déterministe n'a alors pas cet aspect tordu)
Au fond, on pourrait me rétorquer "il suffit de générer un seed aléatoire (initialisation) et de l'utiliser après dans toute la partie". C'est un peu l'idée: les choses sont alors rejouables (déterministes), et ça, ce sera très souvent utile à un moment donné (ie: rejouer un scénario où le joueur s'est fait défoncer, pour comprendre pourquoi et ré-équilibrer le gameplay). C'est un peu pareil pour le Doodle Challenge, qu'on peut alors rejouer. Et ça m'a été demandé aussi pour le Thunderbolt generator et pour le planet generator.
On peut me rétorquer que "ouais, c'est pas pareil, c'est pas des jeux", mais à mon sens, la même chose devrait se faire sans problème dans un jeu, à une échelle simplement différente.
En revanche, pendant la partie, c'est là où je doute... Sur Flux, j'ai justement un aléatoire pour placer les villes, les faire apparaitre ou non, ajouter des voitures entre deux villes, etc. Au final, cela crée des parties très chiantes pour certaines, d'autres très difficiles, d'autres trop faciles... Rendre les choses prédictibles pour le serveur, cela simplifie quand même vachement le boulot de création (ce que je ferait dans Flux en créant des scénarios, éventuellement construits à partir de seed puis sélectionnés pour ne retenir que ceux qui sont intéressants/faciles/etc), sans forcément flinguer l'expérience du joueur (ce n'est peut-être pas prédictible du joueur car il n'a pas toutes les informations requises).
Mais bon, après, chacun son jeu.
RE: Intégration de l'aléatoire - Ter Rowan - 28-06-2017
pour générer une carte ça me parait pertinent de faire sans aleas du moment que la formule donne quelque chose de cohérent (je te fais confiance la dessus)
mais si tu reprends le sujet "événement" je cherche / je tombe sur / je rencontre
comment tu fais là ? pareil ?
RE: Intégration de l'aléatoire - Xenos - 28-06-2017
Supposons que je veuille intégrer des accidents industriels dans Isometry, je pense que je procéderai alors sous la forme suivante:
• Calcul d'un niveau dangerosité de l'usine, à partir de l'état du jeu comme D = (1 - PointsDeVieActuels / PointsDeVieTotal) * FacteurSpecifiqueUsine * (1 - exp(AgeUsineAnnees)). Les pts de vie représentent l'état de délabrement de l'usine, l'âge permet de pousser les joueur à restaurer les vieilles usines et le facteur dépend du type d'usine construite (statique, dans la BDD, éventuellement inconnu du joueur)
• Calcul de différents seuils pour qu'un évènement se déclenche. Eventuellement, une constante de jeu, ou une valeur statique par type d'usine, ou une valeur calculée dépendant du type de case, du type de bâtiment, voire du classement du joueur (pour que les meilleurs aient plus d'accidents que les autres, donc OK plus de difficultés, mais aussi plus d'opportunités de briller en gérant bien la crise). Les seuils pourraient éventuellement se chevaucher (si c'est logique).
• Suivant les seuils actifs, les évènements se passent.
A mon sens, cela reste:
• jouable pour l'utilisateur: aucun risque qu'une usine toute neuve explose, sauf choix du créateur de jeu
• simple à coder et implémenter (et probablement performant): tout est déterministe, je n'ai pas de prise de tête avec des tours, des CRONS ou des trucs du genre
• simple à expliquer aux joueurs: je peux afficher les seuils, dire dans lequel se trouve l'usine, et le joueur verra que, par exemple, son usine va péter dans 3h s'il ne fait rien, ce qui peut accessoirement pousser à l'urgence, de sorte que le joueur reste pour empêcher l'accident à venir, plutôt que d'abandonner le jeu après que l'accident ait eu lieu et l'ait dégoûté
• fiable dans le temps: je peux virer des paramètres ou en rajouter, sans risquer que l'équilibre de jeu ne parte en vrille car je ne manipule pas des "intervalles de probabilité"
• extensible: il me semble que c'est aisé d'imaginer de nouveau scénarios et seuils
• "surveillable" (pilotable?): certaines infos ne sont pas affichées aux joueurs, mais je peux les afficher aux admins (bon, perso, ce serait juste une vue SQL et bast)
Mais surtout, cela permet de comprendre pourquoi un pays est parti en vrille: cela ne peut être *que* à cause d'un joueur nul, ou à cause d'un gameplay mal équilibré. Dans le cas de l'aléatoire, cela pourrait aussi être "parce que t'as pas eu de bol :/" et là, je trouve que c'est très compliqué à corriger et à faire accepter aux joueurs.
Je sais bien que "le risque zéro n'existe pas gnagna", mais quand je joue, ça me gonfle de me faire péter la rondelle sur un coup de malchance :/ Ou de voir que l'autre gagne et prend de l'avance sur un coup de pot.
Tiens un autre exemple amusant, ce serait le genre "Mario kart" et les caisses de bonus. Pour moi, je préfère une implémentation déterministe, basée par exemple sur la durée écoulée depuis le début de la course (plutôt qu'un aléatoire brutal). Genre F = sinus( (T - T0)/K) avec T0 le départ de la course et T le moment de fracassage de la caisse. Il n'y a plus qu'à donner, à chaque item, un intervalle de valeurs (ie: carapace rouge si F > 0.95 et F <= 0.97) que l'on peut éventuellement moduler à partir de la position du personnage dans le classement, et du fait que c'est ou non un joueur. Aucun risque de ne tirer que des grosses armes même si on est en tête, ni de tirer que des brêle si on est à la traîne. On peut remplacer le sin par une fonction triangle hein (FloatPart((T - T0)/K)), ce sera d'ailleurs plus simple à maîtriser.
RE: Intégration de l'aléatoire - Ter Rowan - 28-06-2017
mouais ok... mais je crois que je m’ennuierai dans ce type de jeu (je parle pour les incidents d'usine)
tout est prédictible, donc
soit je fais ce qu'il faut et ca marche, super
soit je sais ce qu'il faut faire mais je n'ai pas ce qu'il faut pour le faire donc je sais que ça va planter, frustré
soit je ne fais pas et ça pête forcément, bof (pour moi)
j'aime pouvoir décider si je prends des risques ou pas, si je parie sur l'avenir ou non. Là y a pas de risque, y a que des certitudes, c'est un livre dont vous êtes le héros, mais sans héros, car justement le héros c'est celui qui confronté à un danger trop fort pour lui s'en sort quand même (alors que d'un point de vue déterministe, échouera) . Personne ne tue un dragon en armure ... sauf un héros, ou un rusé (mais le rusé ne fait pas d ans l'épique, et l'épique, je trouve ça beau ^^)
mais effectivement ca peut le faire dans certains cas, ou pour certains publics
RE: Intégration de l'aléatoire - Xenos - 28-06-2017
Non, car justement, *rien* n'oblige à ce que le jeu déterministe soit à information complète (ou parfaite? j'ai un doute :/ ) pour le joueur
C'est là toute l'astuce du truc: le maître du jeu (le serveur) connaît tout, et gère un jeu déterministe à information complète (ce qui est assez "simple" comparativement à un jeu non-déterministe), mais les joueurs peuvent ne pas avoir toutes les informations. Cette notion relative est hyper-importante, puisqu'elle permet à un créateur de jeu de maîtriser son jeu et l'équilibrage, sans que les joueurs ne fassent de même (en fait, c'est comme distinguer le développeur et les joueurs, ou distinguer les logs d'erreur, complets et destinés aux développeurs [MdJ qui connaît tout] et les erreurs utilisateurs affichées au joueur car il a mal renseigné un champ).Si, par exemple, le MdJ dit seuil d'accident: D>0.9 et D = Etat[%] * AgeAns pour mon usine, alors en tant que joueur, j'ai accès à l'état de mon usine (% de points de vie restant) et à son âge, donc je sais si mon usine va péter ou non, et quand elle va péter (sous réserve que l'état ne change pas durant cette période, ce qui introduit le paramètre hasardeux des autres joueurs plutôt que du random serveur). De plus, il me faut connaître cette formule, ce qui n'est pas forcément simple (si la formule introduit plusieurs paramètres, qui évoluent dans le temps, ce sera chaud à deviner!).
Maintenant, si le Mdj dit D = Etat[%] * AgeAns * KarmaUsine et que le MdJ garde l'information KarmaUsine secrète, alors je n'ai plus toutes les informations en tant que joueur, et mon usine peut péter à tout instant pour moi. Pour le MdJ, cela n'a rien changé (c'est toujours simple pour lui de savoir quand l'usine pètera), mais pour le joueur, cela change tout son plan et cela introduit un paramètre qu'il ne contrôle pas, qu'il ne connaît pas (similaire à l'effet de l'aléatoire), mais que le MdJ maîtrise parfaitement. D'ailleurs, si le jeu n'est pas équilibré, le MdJ pourra sans soucis changer le KarmaUsine pour favoriser ou non le joueur. Piper des dés, ce serait plus dur :/
La différence avec un LDVELH, c'est que le MdJ n'est pas forcément le joueur (c'est l'énorme atout des jeux vidéo d'ailleurs, contrairement aux jeux de société qui n'ont pas de MdJ). Le joueur aura donc une connaissance imparfaite du jeu dans son entièreté, et devra donc relever les défis qui en découlent, alors que le MdJ en aura une connaissance parfaite: s'il jouait, il se ferait chier, mais on s'en fiche, puisqu'il ne joue pas. En revanche, son boulot de MdJ est facilité par l'absence d'aléatoire qui lui échappe (c'est le soucis du random: ni le MdJ ni les joueurs ne le contrôlent; à mon sens, mieux faut un faux-aléatoire que le MdJ contrôle et pas les joueurs).
PS: en plus, côté MdJ, je trouve ça sympa de voir les décisions que prennent les joueurs à partir des informations qu'ils ont, et se rendre compte qu'ils "vont dans le mur", sans trop le savoir
Bon, après, si on observe ce genre de truc, c'est qu'il est probablement temps d'ajuster le gameplay pour éviter que les joueurs se crashent sans comprendre pourquoi.PPS: (oui, je n'ai pas une pensée très structurée...) Tu t'ennuies quand tu joues aux échecs, au jeu de Go, voire aux cartes? Pourtant, c'est tout prédictible... Le paquet de cartes aléatoirement mélangé en début de partie est simplement connu du MdJ (le serveur, ou la réalité pour un jeu de société) et pas des joueurs
RE: Intégration de l'aléatoire - Ter Rowan - 28-06-2017
ne crois pas qu'il n'y aura pas des joueurs pour trouver tes formules. Et du coup celui (comme moi) qui n'aura pas la patience de chercher ces formules à partir des éléments qu'il a ira les chercher sur les forum pour ne pas être pénalisé. Du coup ce principe de "je cache des trucs pour amuser les joueurs" (principe auquel je croyais il y a encore 3 ans) devient vite "je cache des trucs et ça fait chier une majorité de joueurs"
exemple typique therian saga, regarde le forum sur les métiers, etc...
les formules d'effets des composants sur un craft étaient cachées
des joueurs ont cherché (pendant 1 an ?) et sont arrivés après différentes approximations, à l'algo exacte.
du coup, comme c'est d'abord un jeu de craft et de planification, on a tous les feuilles de calcul / macros qui permettent de savoir combien il faut de quel composant pour obtenir ce qu on veut
juste un outil en plus, pas immersif, mais efficace et a l'opposé du gp prévu initialement
(je dis pas que dans ce cas il fallait de l'aléatoire je dis juste que caché, a mon sens, c'est maleuh)
pps : non je ne m'ennuie pas enfin ca dépend
si je joue face à un joueur qui joue je ne m'ennuie pas car je ne peux prévoir sa réaction, je peux la provoquer (psychologie, etc...) mais pas la prévoir
si je joue face à une ia déterministe oui, je m'en rend compte assez vite et soit je gagne parce que j'ai "cracké" l'algo soit au bout de x parties ça me fait chier et j'arrête de jouer (parce que dans un jeu me battre moi même ne m'intéresse pas, comprendre toute les subtilités ne m'intéresse pas, ce qui m'intéresse c'est le feeling, la poésie, le style)
et typiquement, au poker, si je joue contre un joueur qui joue trop serré et insensible à mes manoeuvres psy, oui je me fais chier (le poker étant a peu près prédictible bien qu'aléatoire sur une partie)
RE: Intégration de l'aléatoire - Xenos - 28-06-2017
Justement: il y aura des joueurs pour tenter de "casser" les formules. C'est d'ailleurs un autre manière de les attirer. Mais cela n'entache en rien l'intérêt du déterministe car même si la formule est connue, tous les paramètres le sont-ils? Pas sûr. Dans l'exemple précédent, même si la formule est connue, KarmaUsine ne l'est peut-être pas. D'ailleurs, cet aspect rétro-engineering (que j'ai même mis dans un article il y a quelques temps) se poserai aussi sur un jeu aléatoire.
Le truc, c'est que soit le MdJ peut prévoir la direction du jeu (simple et faisable dans le cas du déterministe, bien plus chiant pour de l'aléatoire), soit il ne le peut pas. S'il ne le peut pas, à mon sens, cela va dériver vers des gameplay foirés. S'il le peut, cela donne un gameplay maîtrisé, pour la meilleure expérience de jeu. La question est alors de savoir si les joueurs peuvent devenir des MdJ. Dans le cas de l'aléatoire *et* du déterministe, oui: il suffit qu'ils accèdent aux mêmes informations que le MdJ. Au fond, la seule différence à mon sens, c'est que le gameplay sera maîtrisé dans un cas, et pas dans l'autre. Dans le premier cas, on laisse la qualité du jeu à la maîtrise de ses créateurs, dans l'autre, on le laisse juste au pif et à la chance du joueur.
P2S: Si tu t'emmerdes parce que tu as "cassé" l'algo de l'IA, c'est que l'IA n'est pas complète. Tu as cassé l'algo, admettons, mais l'IA "bien faite" apprendra de sa partie précédente, et quand un seuil sera atteint, elle jouera autre chose pour éviter de perdre (ou rejouera pareil si elle avait gagné la partie précédente: ne tiens qu'à toi de jouer un truc différent). Sans compter que jouer deux fois *exactement* la même partie, humainement, c'est souvent chaud :/ Sur un jeu "numérique" façon les échecs ou le poker, cela peut éventuellement se faire (et encore: on n'a aucune garantie en tant que joueur [vu qu'on n'est pas le Dieu-MdJ omniscient] que le paquet de cartes soit exactement dans la même configuration que la partie précédente). Sur un jeu plus analogique, genre un RPG où on se déplace dans un monde 2D avec les flèches du clavier ou un FPS en 3D, c'est à peu près impossible de rejouer l'exact même partie.
P3S: on pourrait faire l'expérience d'ailleurs: je peux envisager de virer tout l'aléatoire d'ECLERD, et on regarde si t'arrives à crafter les formules et à péter le jeu
A mon avis, tu seras parti bien avant que le point "j'ai résolu le jeu" ne soit atteint.Sans compter que même si tu arrivais à résoudre le jeu (au sens de https://en.wikipedia.org/wiki/Solving_chess désolé, c'est en anglais), alors tout serait relancé si on changeait la taille du plateau, ou la configuration de départ. Il y a une telle quantité de moyens de renouveler un jeu! Juste balancer de l'aléatoire, je trouve cela triste :/
P4S: Si je comprends bien, tu considères que si la communauté de joueurs "résout" le jeu (elle connait tous les algos, toutes les composantes, bref, elle est Dieu/le MdJ) alors elle va s'emmerder et les joueurs aussi. Je ne pense pas. Car d'une part, la composante même des joueurs entre en jeu (ie: le paramètre humain est ton aléatoire) et d'autre part, même si on connait toutes les formules d'un jeu, celui-ci peut être encore intéressant *s'il est équilibré*: le choix entre deux stratégie ne se basera pas sur "laquelle est la meilleure dans l'absolue?", qui sous-tendrait que le jeu est déséquilibré, mais sur "qu'est ce qui me plaît le plus à moi?" ce qui est totalement subjectif. Sans compter que connaître tout d'un jeu n'implique pas d'être capable de le calculer véritablement (bon, si on ne peut pas le "calculer", le MdJ n'aura sûrement pas la maîtrise du jeu donc on perd l'un des atout du déterminisme). Genre le jeu de Go ou les échecs, on connait toutes les règles, toutes les informations, mais on est infoutu de savoir ce qu'il faut jouer pour toujours gagner.
TL;DR
Tiens, d'ailleurs, je peux te proposer un petit jeu que j'avais fait (parti d'un jeu de mot pourri): on incarne un Yack et on doit écraser des lapins avant qu'ils n'atteignent leur terrier (cherchez pas...) https://xenos.reinom.com/deviantart/cynderheart-game/game.html
Actuellement, c'est le gameplay du pauvre: les lapins et leur vitesse sont aléatoires. Du coup, y'a des parties pourries avec un score moisi, et des parties avec un score de ouf, sans qu'on n'ait réellement "progressé" entre les jeux. L'aléatoire, même sur un jeu aussi simple, rend la maîtrise du gameplay impossible pour moi.
Je tâcherai d'en faire une nouvelle version (peut-être dans un "game2.html") où je scénariserai les choses, pour avoir une courbe de progression et tout. Tu me diras lequel te semble le plus sympatique à jouer
RE: Intégration de l'aléatoire - Ter Rowan - 28-06-2017
ps3
non, vu comment tu es et comment je suis, un jeu comme eclerd me lassera bcp trop vite pour le gameplay (de ce que j'en ai compris, c'est trop de complexité pour moi) et pour l'imaginaire (l'univers ne m'attire pas) alors je ne le casserai pas
ps4 non je considère que psychologiquement (à tord ou à raison, hein) un concepteur qui se concentre sur la modélisation, n'a pas le temps de raisonner sur des plaisirs autres que celui de comprendre la modélisation. C 'est comme la plupart des films 3d on fait de plus en plus de "belle" 3D mais les scenarios, on n'a pas le temps d'y penser.
tl ; dr ton argumentaire est faible : tu n'as pas réussi a gérer l'aléatoire, donc l'aléatoire est mauvais
RE: Intégration de l'aléatoire - Xenos - 29-06-2017
Ce n'est justement pas la question de "bien" ou "mal" gérer l'aléatoire, c'est la question de sa présence.
C'est le concept même d'aléatoire (pas sa quantification) que je remets ici en cause, à savoir "le MdJ ne sais pas quel effet produira telle action dans telles conditions; à fortiori, le joueur ne le sais pas non plus". Toi, tu sembles vouloir "le joueur ne sais pas quelles conséquences exactes auront ses actions" (pourquoi pas, et c'est sympa aussi comme gameplay). Mais c'est atteignable sans que le MdJ soit dans cette même condition. Le déterminisme "bien géré", pour moi, c'est avoir un joueur qui ne sait pas forcément ce qu'amèneront ses actions, mais le MdJ le sait et peu donc orienter son jeu comme il le veut.
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), en se disant, par exemple, "là, en fin de jeu, je vais mettre des trucs dur, et au début, je vais corriger le tirage pour donner des bonus". Il n'y a plus d'indéterminisme dans la partie pour le MdJ (qui, s'il jouait, ferait alors du "délit d'initié"), et c'est ce que je trouve classe et bien pensé.
C'est quoi, pour toi, "bien gérer l'aléatoire"?