|
Légende
|
Alors que je cherchais à mettre au point le système de craft ultime, j'ai eu une idée. D'abord, je vais expliquer les propriétés que je recherche ; ensuite, je vous proposerai un système qui vérifie ces propriétés.
Propriétés voulues D'abord, le mécanisme doit être suffisamment simple pour être implémenté facilement, compris rapidement par les joueurs, équilibrable sans prise de tête, mais avec de nombreuses implications. Un mécanisme de jeu qui ne vérifie pas ces propriétés n'est pas intéressant. Ensuite, les joueurs doivent pouvoir apprendre par eux-même comment crafter. Dans les MMO actuels, on va voir un PNJ, on donne des PO et voilà, on sait crafter une lance (par exemple). Ou alors on trouve un papier par terre avec une recette dessus. Tout ça est bien joli mais c'est un peu frustrant : le craft c'est la création d'objets nouveaux, et là on ne nous propose que de créer des objets bien définis. C'est un peu l'oeuf et la poule : à l'origine du monde, il y avait des PNJ ? Il y avait des recettes qui traînaient par terre ? Non ! Alors il doit bien y avoir eu des gens qui ont inventé des recettes. Et pourquoi le joueur n'aurait pas lui aussi cette possibilité ? Donc, je cherche un système de craft permettant au joueur de découvrir de nouvelles recettes par lui-même, ou de démonter un objet existant pour voir comment il est fait et en déduire la recette. Cependant, je souhaite aussi qu'il ne soit pas possible pour le joueur de simplement aller sur internet et voir une liste de recettes. Le but du jeu est de découvrir les recettes. Leur application est secondaire. Il est donc nécessaire que pour un objet et un joueur donné, la recette permettant de créer cet objet soit unique pour ce joueur. D'un point de vue roleplay, chaque personnage est unique et ne construit pas les objets de la même façon. Donc pour résumer : - un joueur doit pouvoir démonter une lance pour voir qu'elle est construite à partir d'un bâton et d'un silex disposés d'une certaine façon ; - un joueur doit pouvoir prendre un bout de bâton et un silex, les assembler d'une certaine façon et obtenir une lance ; - la disposition du silex et du bâton doit être différente pour chaque joueur. Des recettes uniques pour chaque joueur Le problème c'est qu'il ne faut pas non plus que le serveur doive, pour chaque nouveau joueur, créer autant de recettes uniques pour ce joueur qu'il y a d'objet en jeu. De même, pour chaque nouvel objet implémenté, il ne faut pas que le serveur stocke une nouvelle recette unique pour chaque joueur. Sinon, avec 10000 joueurs et 100 objets craftables, il faudrait stocker 1000000 recettes. Or, un serveur de MMO doit être le plus léger possible pour accueillir le plus de joueurs possibles. Et donc je propose d'utiliser un outil que nous apporte la cryptographie, en l'occurence : les fonctions de hash. http://en.wikipedia.org/wiki/Cryptog..._hash_function On choisit donc une fonction de hash cryptographique (celle que vous voulez) que l'on va appeler HASH. On a besoin d'une fonction F qui, étant donné un joueur J et un objet O, nous donne une recette F(J, O). Et il faut que cette fonction ne soit pas facilement inversible : étant donné F(J, O) et O, il ne faut pas pouvoir calculer J. Ca tombe bien, c'est exactement ce que font les fonctions de hash. Donc étant donné un numéro unique J pour le joueur, et un numéro unique O pour l'objet, on peut définir : F(J, O) = HASH(J xor O) On obtient un numéro H qui détermine la façon d'assembler les composants permettant d'obtenir O. Ces composants sont fixes (pour faire une lance, il faut un bâton et un silex, quelque soit le joueur) mais pas leur permutation. Si on imagine par exemple que le joueur doive placer le bâton et le silex sur une grille 3*3 (ou 3*4 pour un cube horadrim  ), ça nous fait 9*8 = 72 permutations. Le hash H permet de décider laquelle de ces permutations est la bonne. Pour savoir comment obtenir la permutation à partir de H, demandez à Wikipedia :http://en.wikipedia.org/wiki/Permuta...g_permutations Concrètement, qu'est-ce que ça veut dire ? Pour le serveur c'est simple : il doit simplement stocker un numéro unique J pour chaque joueur et un numéro unique O pour chaque objet craftable. Le client doit être capable de calculer le numéro associé à la permutation choisie par le joueur, et le serveur doit déterminer si cette permutation est la bonne étant donné les composants utilisés. Le serveur doit aussi, quand le joueur démonte un objet, être capable de calculer la permutation associée à ce joueur pour lui en montrer une partie. Pour le joueur, c'est très intéressant. Imaginons que vous trouviez une lance. Vous aimeriez bien pouvoir en fabriquer d'autres. Alors vous démontez la lance. Le jeu vous montre alors un quadrillage 3*3 représentant la recette. Pour vous, le silex se trouve sur la case du milieu (mais pour un autre joueur, il pourrait être ailleur). Par contre, le bâton a été cassé dans l'opération, et vous ne savez pas où il est placé. Vous pouvez démonter une autre lance pour essayer de savoir, mais vous pouvez aussi essayer toutes les combinaisons. Après tout, une fois qu'on sait où est le silex, il n'y a plus que 8 placements possibles pour le bâton. Donc vous essayez un par un jusqu'à trouver la bonne combinaison, et ça y est : vous savez construire des lances. Améliorations On peut améliorer ce système de plusieurs façons. D'abord, tel que je l'ai présenté, les composants sont fixes ; mais on peut très bien imaginer un composant spécial (poudre magique...) pour certaines recettes. Je ne pense pas que ça soit très utile mais pourquoi pas. Ensuite, l'objet obtenu peut être plus ou moins aléatoire. La construction de l'objet peut rater de temps en temps, avec destruction de certains composants en cas d'échec (surtout si le joueur n'a pas utilisé la bonne combinaison). Le démontage des objets peut être plus ou moins difficile, et le joueur peut apprendre plus ou moins d'informations, et obtenir plus ou moins de composants. Le démontage peut nécessiter des outils. La construction aussi peut utiliser des outils : ça reviendrait à rajouter un composant (l'outil) qui ne serait pas consommé par la construction. Et bien sûr, tous ces mécanismes peuvent éventuellement être paramétrés par les compétences du personnage. Une autre amélioration possible concerne la difficulté des recettes. Dans une grille 3*3, un objet demandant un composant a une difficulté 9 (une chance sur 9 de le réussir si on place le composant au pif), un objet à 2 composants a une difficulté 8*9 = 72, etc. Bref, on n'a pas beaucoup de difficultés disponibles : seulement 9, 72, 504, 3024, 151205, 604820, 1814460 et 3628920. Mais on peut raffiner un peu ! Pour obtenir une difficulté D(O) pour un objet O, il suffit de ne pas simplement tester si le nombre C associé à la combinaison est égale à H (le hash), mais plutôt si : C = H mod D(O) Ainsi, on a une chance sur D(O) de trouver la bonne combinaison. Et c'est le développeur qui choisit D(O). Par exemple, pour une lance on peut décider qu'on a une chance sur D(LANCE) = 3 de faire une lance du premier coup en mélangeant un silex et un bâton. Mais pour une orbe de résurrection, on peut donner une difficulté plus élevée, par exemple 30. Précisions techniques Il reste un petit soucis, cependant : le démontage. Comment le serveur calcule-t-il une permutation C valide (c'est-à-dire vérifiant C = H mod D) ? Les fonctions de hashs n'étant pas inversibles (c'est le but) ce n'est pas possible instantanément. Cependant, le serveur connaît les numéros du joueur (J) et de l'objet (O), donc il peut tester toutes les combinaisons jusqu'à en trouver une qui marche. Ce qui veut dire qu'il doit tester en moyenne environ D combinaisons. Si on ne choisit pas des difficultés trop élevée, c'est raisonnable. A noter aussi qu'il y a une chance (très très faible) pour qu'il n'y ait aucune combinaison valide pour un J et un O donné. Cette chance diminue très largement si on diminue D. Raison de plus pour conserver D assez bas. Conclusion On a donc un système qui permet au joueur de découvrir des recettes par lui-même, en démontant les objets pour voir comment ils sont faits et/ou en essayant de les construire directement. Ca permet de renforcer le sentiment d'immersion, puisque le joueur a l'impression de pouvoir être à l'origine de nouvelles découvertes. Et pour éviter qu'un joueur puisse simplement trouver une liste de recettes sur internet, on utilise une fonction de hash cryptographique pour que chaque recette soit unique pour chaque joueur. |
13/09/2009, 15h34
|
Craft et cryptographie
| Suivre |
|
|
Partager | Rechercher |
|
Héros / Héroïne
|
le but des hash cryptographiques est d'être difficile a inverser, mais après, tu peu être bien écrire tes hash perso de façon a ce qu'ils puissent être inversible, hein ^^
genre, tout simplement, ln(x) dans un sens et e(x) dans l'autre ^^ sinon, j'aime bien l'idée, mais ca risque d'être très difficile de trouver des objet qui utilisent des base chères.. autant pour un objet, on peu prendre son temps pour tester toutes les combinaison (ce qui, a la base, c'est déja douteux) , mais si un composant est perdu a chaque test... évidement, c'est plus simple si tu a déja des exemplaire existant pour faire ton reverse.. mais il faut bien que quelqun ai déja inventé la version originale.. |
|
13/09/2009, 22h38
|
|
Légende
|
Pour ta remarque sur les fonctions de hash, il est nécessaire que la fonction ne soit pas inversible puisque le but c'est justement que le joueur ne puisse pas calculer son numéro unique J. En effet, s'il peut le calculer, alors il peut en déduire la liste des combinaisons de ses recettes, et c'est exactement ce qu'on veut éviter
 Ensuite tes autres remarques sont juste un problème d'équilibrage de la difficulté selon ce qu'on veut obtenir. Ca revient à équilibrer le prix de l'objet  Le problème des "versions originales" aussi est juste un problème d'équilibrage. A toi de savoir dans quelle mesure les joueurs ont déjà des objets à disposition dans le jeu. A toi de choisir si les joueurs arrivent dans un monde entièrement vierge, et qui va évoluer beaucoup, ou dans un monde déjà un peu stabilisé, avec la plupart des inventions déjà réalisées. A toi aussi d'équilibrer tout ça en fonction du nombre de recettes totales et du nombre de recettes qu'un joueur doit pouvoir découvrir en un temps donné. A toi de choisir le nombre de composants qui disparaissent (avec quelle probabilité) lors d'une construction ou d'un démontage.Par exemple, s'il faut en moyenne 3 essais pour obtenir une lance (difficulté 3, disons) et que tu décides qu'à chaque essai raté, le bâton se casse avec une probabilité 1/2, alors il faut environ 1.5 bâton et 1 silex pour découvrir comment faire une lance, puis 1 bâton et 1 silex pour faire une lance une fois que tu sais les faire. Alors qu'avec une difficulté 10 et si le bâton casse à chaque essai raté, il faut environ 10 bâtons (et 1 silex). Si le démontage te révèle la position du bâton et du silex en 2 essais en moyenne, alors tu as le choix : démonter 2 lances, ou trouver 10 bâtons et 1 silex (tout ça étant en moyenne). Ou les deux, vu que démonter les lances peut te donner des bâtons. Bref peut-être qu'en démontant une lance et avec une réserve de 5 bâtons tu y arriveras. Comme tu vois, il faut doser : - la quantité de composants (bâton et silex dans notre exemple) disponibles ; - la quantité d'objets finis (lance dans notre exemple) disponibles ; - l'apport du démontage en terme de quantité d'information et de composants ; - l'apport des composants en terme de quantité d'information pour chaque tentative de construction (sachant que si on a déjà des informations partielles ça change cette quantité d'information donc c'est un peu compliqué) ; - le prix recherché pour découvrir la recette ; - le prix recherché une fois la recette connue. Le partage de recette avec les amis Je réalise que j'ai oublié de parler d'un truc rigolo qu'on peut implémenter : le partage de recettes. Vu qu'on ne peut pas partager directement la combinaison, pour qu'un joueur A explique à un autre joueur B comment réaliser une lance, la seule possibilité qu'il a pour l'instant c'est de fournir des lances à B pour que B les démonte et voit comment elles sont faites. Mais on peut très bien imaginer aussi faire un truc du genre : si le joueur A réalise une lance devant B, alors B obtient quelques informations sur la recette des lances. Ensuite il peut démonter et remonter les lances obtenues pour achever sa formation. Pour que ça marche bien et qu'on ne puisse pas partager ses recettes à l'infini il faut que le démontage détruise les composants avec une probabilité non nulle. |
|
13/09/2009, 23h38
|
|
[Mael]
Alpha & Oméga
|
Citation :
Quand à l'apprentissage, une grande grille (genre 10*10 voir 20*20), peut être plus sympa, en mettant un apprentissage petit à petit (et incluant des coups de chance : "réussi de crafter l'item sans totalement comprendre comment !"), en dévoilant les cases où il n'y a pas l'item, ou la zone ("dans le carré de 3*3 ici") où se trouve un item, ... |
|
14/09/2009, 00h14
|
|
Légende
|
Pour ta remarque sur "possible" et "très dur", c'est tout à fait pertinent, et en fait les fonctions de hash cryptographiques ne sont pas 100% safe mais il faudrait des années ou même bien plus (des millions d'années ?) pour les "casser" (trouver des collisions). Enfin en théorie. Et clairement pour notre jeu ça nous suffit. L'article de Wikipedia doit donner plus d'info je pense.
Sinon pour la taille de la grille c'est bien sûr un paramètre du système et tu peux mettre ce que tu veux. Mais déjà en 3*3, si tu mets 5 composants il y a 15120 combinaisons et je doute qu'il soit intéressant d'avoir des objets de difficulté supérieure à 1000 de toute façon. Mais rien n'empêche d'avoir du 42*69 ou autre, de toute façon la difficulté est réglable (paramètre D). D'ailleurs, rien ne nous force à utiliser une grille voire même des combinaisons. On peut sans doute trouver plus roleplay. Il faut juste qu'il y ait la possibilité d'associer un chiffre à la façon d'assembler les composants
|
|
14/09/2009, 00h37
|
|
Empereur
|
Bonjour,
Je ne suis pas sûr d'avoir tout à fait saisi le concept, mais si j'ai bien compris c'est en gros un « code secret » (graphique ou non, ça n'a aucune influence) propre à chaque joueur qui permet de combiner des ressources pour obtenir des objets ? Cela voudrait dire que, sauf a essayer effectivement toutes les combinaisons, chaque joueur doit *au préalable* avoir a disposition un objet (qui plus est doit le démonter) pour en fabriquer un nouveau et donc que ça ne fonctionne que dans un gameplay où ces objets existent effectivement ? Si c'est le cas, c'est un peu dommage pour un "système de craft ultime" de ne pas avoir des possibilités comme échanger des secrets de fabrication dans le jeu, la possibilité d'inventer soi-même des objets sans copie d'un objet existant, etc, non ? Pour ma part je résous le problème des « transmissions sauvages de recettes par Internet » par des méthodes de fabrications uniquement IG pour les objets complexes : un personnage est obligé d'apprendre ou d'être entré en contact (oralement, par écrit ou par tout autre moyen IG, communication qui implique utilisation de temps, d'énergie, de technologie, etc...) et d'avoir échangé sur ce sujet pour que l'autre personne ait pu apprendre (Ce n'est d'ailleurs pas propre aux recettes de fabrication, cela concerne toutes informations, qui sont en somme des objets virtuels du jeu lui-même) Je veux dire il peut par par exemple "inventer la roue" en poussant un morceau de tronc (en gros un objet a un seul composant mais nécessite d'avoir l'idée du principe) puis découvrir la "projection d'objet" en observant une balsamine mure, etc, et au final construire une catapulte, alors qu'un autre joueur qui n'a pas fait ces découvertes ne le pourra pas. Mais le premier pourra donner (ou vendre ) ces techniques au second. Comme le second peut effectivement espionner (je rend possible la simple observation d'un objet, avec une perte d'information selon la complexité donc pas besoin forcément de démontage pour « apprendre ») la machine pour tenter d'en apprendre plus.Bref, est-ce qu'un échange d'information exclusivement IG ne répond pas aux propriétés demandées ? Et est-ce que la condition « la disposition du silex et du bâton doit être différente pour chaque joueur. » est réellement importante ? Si oui, il est possible de créer plusieurs « informations échangeables » pour obtenir un même objet, certaines étant par exemple plus couteuses que d'autre en temps/énergie pour le personnage... (il est même possible de créer de fausses recettes à vendre ) (mais si j'ai mal compris le principe et ses conséquences, je m'en excuse, oubliez mon message !) |
|
14/09/2009, 14h31
|
|
Légende
|
L'image du code secret est la bonne
Ton idée d'informations à partager est intéressante, mais je pense que l'expressivité est similaire. Je m'explique. D'abord, dans mon système la notion d'idée n'est pas inexistante : avant d'essayer toutes les combinaisons bâton / silex pour trouver comment faire une lance, le joueur doit d'abord avoir l'idée de combiner les deux. Il peut avoir l'idée soit en démontant une lance, soit avec du bon sens, soit parce qu'un autre joueur lui en a parlé, éventuellement sur internet. En ce sens, effectivement je ne bloque pas le transfert des idées elles-mêmes, ce que tu proposes en obligeant le joueur à réaliser une action pour avoir une idée (observer tel phénomène pour imaginer tel mécanisme). Ensuite, tu remarques à raison que ton système permet de proposer plusieurs façon d'obtenir le même objet, à partir d'informations plus ou moins "chères". Cependant j'ai l'impression que ça reviendrait, dans mon système, à proposer plusieurs recettes pour le même objet, avec des composants différents et plus ou moins chers, ce qui n'est pas inenvisageable. Mais j'ai néanmoins des objections au mécanisme d'observation que tu proposes. D'abord, ça nécessite un gros travail au niveau du design puisqu'il faut imaginer un phénomène par idée au minimum. De plus il est nécessaire de coder les phénomènes un par un (déplacement de tronc d'arbre etc). En ce sens on peut se demander si ça satisfait la condition de simplicité que je recherche. Dans mon système, j'ai juste à coder une liste de recettes de la forme A + B + C = D, avec des poids pour équilibrer les diverses pertes de composant. Ensuite, c'est peut-être un peu frustrant pour le joueur de connaître le principe de la roue ou de la projection mais de ne pas pouvoir les appliquer sans avoir fait une action précise avant (l'observation du tronc d'arbre qui roule). Ca dépend de ce que tu veux obtenir. Ton système met l'accent sur le personnage, le mien met l'accent sur le joueur. C'est une question de goût. C'est vraiment un point de vue très personnel mais je cherche à mettre au point un jeu où le joueur peut se dire : je suis mon avatar. Je trouve ça d'autant plus immersif, paradoxalement. Mais c'est un peu hors sujet (et sujet à troll  ).Par contre il y a une idée intéressante dans ton système, qui est l'observation sans démonter. Note qu'on peut rajouter ça facilement dans mon système, avec une opération d'observation équivalente au démontage mais sans aucune perte et avec moins d'informations produites. Il faut juste s'assurer qu'on ne puisse pas répéter l'opération plusieurs fois et obtenir toute l'information, vu que ça reviendrait à pouvoir apprendre à construire un objet sans rien payer (pourquoi pas pour des objets triviaux, mais ça s'arrête là). Pour conclure, je dirais que ton système est intéressant et permet au moins la même chose que le mien, avec en plus la partie observation qui est effectivement intéressante. Mais mon avis est mitigé sur cette partie, pour les raisons que j'ai évoquées plus haut. |
|
14/09/2009, 15h37
|
|
Empereur
|
Citation :
 (hormis l'échange de l'information "j'ai une lance, viens la démonter") Si le joueur n'a pas cette information préalable venant d'un autre objet, il *doit* poser ses ingrédients au petit bonheur la chance, non ? Citation :
)Ensuite je n'ai pas "des objets" mais des "attributs d'objets" => une compétence peut servir par combinaison dans plusieurs objets ayant le même "attribut". Citation :
Pour moi l'avatar ne doit pas hériter des connaissances réelles du joueur, c'est uniquement l'expérience de jeu qui doit définir ses connaissances, et que celle-ci soit cohérente et réaliste, d'où le point de vue "compétences du personnage/attributs des objets". Pas de mélange réalité/jeu en somme. Mais comme dit ça n'est pas le sujet, et chacun ses goûts donc oublie ma proposition.
|
|
14/09/2009, 18h16
|
|
[Mael]
Alpha & Oméga
|
Citation :
Tu prends un silex et un baton pour faire une lance, pas une fleur et une épée ... :-° |
|
14/09/2009, 20h40
|
|
Empereur
|
Au temps pour moi, j'avais compris qu'il était question du système d'assemblage proprement dit, merci de m'avoir éclairé !
|
|
14/09/2009, 21h47
|
| Suivre |
Connectés sur ce fil1 connecté (0 membre et 1 invité)
Afficher la liste détaillée des connectés
|