Premier MUSH francophone !

Re-bienvenue ! :smiley:

Moi aussi j’ai pensé que faire quelque chose avec un truc moderne, mais en même temps, y en a-t-il besoin ? Les romans sont toujours aussi bien aujourd’hui, même si ce n’est que du texte linéaire ! Après, tout dépend de ce que tu veux faire.

Récemment, une personne du MultiMUD est venue sur le forum, tu pourrais les contacter pour voir comment ils ont fait du point de vue technique.
Pour un wiki, je ne sais pas trop : c’est un peu forcer un système à faire quelque chose pour lequel il n’était pas prévu. C’est vrai que ça peut être cool, mais comment faire pour sauvegarder ce que les joueurs ont fait ? Par exemple leur inventaire, ou s’ils ont réussi telle ou telle quête ? Ou alors ça devient totalement RP, un peu comme les jeux par forum, et on fait confiance au joueur.

Tu connais Fallen London ? Ça ressemble vachement à ça : tu peux jouer tout seul en cliquant sur des cartes et en faisant des choix, et il y a des actions qui nécessite de collaborer avec (ou nuire à) un autre joueur. Pour ton troisième point il faudrait faire ça séparément par contre.

Il ont rendu leur système de création disponible, donc tu peux aussi joueur à d’autres jeux dans le même genre si tu n’aimes pas le style victorien-gothique de Fallen London. (sur leur forum, il y a quelqu’un qui cherche des testeurs pour un gros monde cyberpunk, ça semble plus de ton genre).

Les seuls défauts, c’est qu’ils ne maintiennent plus leur outil (le public en tout cas, ils maintiennent toujours celui de Fallen London) et que l’interface sera en anglais. Pour le premier point, ça veut dire qu’ils ne corrigeront pas les éventuels bugs du moteur (mais il n’y en a pas vraiment à ma connaissance). Pour le second, ce n’est pas trop grave car le contenu du jeu est dans ce que tu écris, et il y a peu de textes dans l’interface.

Si jamais ton monde a beaucoup (genre beaucoup), de succès, je pense qu’ils essayeront de corriger ces défauts.

Je pense que c’est intéressant un wiki pour une aventure interactive, mais on perd tout le côté temps réel d’un Mush (même avec un chat) puisque les objets ne seront pas manipulé directement par le moteur de jeu. Mais c’est à creuser quand même, pour une nouvelle forme de jeu.

Par « moderne », j’entendais surtout techniquement moderne, en termes d’outils utilisés. Les romans sont toujours aussi bien, et je continue de penser que le texte est un super vecteur pour les jeux. En 3 mots, on peut créer un volcan en éruption. Avec Unity3D, ça prend un peu plus de temps !

Pour sauvegarder les informations des personnages, 2 options :

  • Soit le moteur utilise un SGBD accessible par SQL, auquel cas faut créer des tables, des requêtes, …etc.
  • Soit le moteur est en « flat file », auquel cas on garde les infos dans un fichier structuré, XML ou autre.

C’est vrai que ce n’est pas exactement un simple wiki qu’il faut. Un wiki utilise un marquage, généralement Markdown&fils, pour exprimer la mise en forme du texte. Pour un jeu textuel, la mise en forme importe moins : c’est juste du texte (pas souligné-gras-italique-taille-couleur-etc). Par contre, un marquage spécifique devrait permettre de réaliser certaines actions : aller vers un autre lieu évidemment, insérer un objet dans l’inventaire, modifier une caractéristique du joueur, réagir à l’utilisation d’un objet, parler à un personnage…

Les 3 couches utiliseraient les mêmes lieux, sous forme d’articles modifiables.
La couche 1 permet de se déplacer de lieu en lieu, d’interagir, acheter du matériel, entrainer le personnage, l’éduquer, travailler, …etc.
La couche 2 fonctionne par QCM, avec des objets réactifs (objets ou PNJ), en utilisant le marquage susmentionné.
La couche 3 est le JdR temps-réel, donc là de toute façon il y a un MJ qui peut guider les joueurs et modifier les lieux, s’ils mettent le feu par exemple.

C’est encore plus compliqué que ça : il faudrait au minimum que l’on puisse tester une condition avant d’effectuer l’action. Sinon, un joueur pourrait spammer un lien pour récolter le même objet à l’infini…

En fait, je viens de me rendre compte qu’on en avait déjà parlé un peu sur le forum !

J’avais mentionné Seltani là-bas, et ça correspond assez à ce que tu veux : MUD à hyperliens façon wiki. Ça n’a plus l’air d’être très maintenu non plus…

Seltani avait l’air super, par contre j’avais voulu créer une instance chez moi, et ça me semblait un peu usine à gaz, je n’avais jamais réussi à le faire fonctionner, du coup ça ne m’a pas trop donné envie de m’investir dedans si c’était pour aboutir à un système non pérenne.

Oui c’est vrai, il y a effectivement des cas de figure où il serait bon de pouvoir faire des tests. En fait il faudrait presque un mini-langage embarqué. La question que je me pose, c’est : server-side ou client-side ? Client-side c’est très facile, je suis à l’aise en javascript, ce serait fait en deux coups de cuillère à clic, par contre le joueur pourrait tricher facilement. Server-side, le joueur pourrait difficilement tricher, mais je suis nettement moins à l’aise avec PHP (il n’y a pas d’hébergement nodejs gratuit de qualité, donc pas de javascript server-side).

Seltani est pas mal. Twine aussi, faut reconnaitre.

J’imagine un hybride avec Inform. Ce qui est bien dans Inform, c’est que le moteur connait les types d’objets, comment ils réagissent et ce qu’on peut faire avec. Mais il va peut-être un peu trop loin dans le low-level à mon goût. Il faut trouver un juste milieu.

Donc pendant le jeu, imaginons : on a du texte, contenant des mots ou expressions cliquables, identifiables parce qu’ils sont en italique par exemple. Si on clique sur un élément cliquable, au lieu de se retrouver directement vers une autre zone de jeu, ou d’effectuer directement une action, un menu pop-up apparaît, qui montre ce qu’il est possible de faire avec cet élément.

Exemple :

Quand on clique « le champignon », un menu contextuel apparaît, proposant :

  • Le jeter
  • En croquer un morceau
  • Le ranger dans votre sac à dos
  • Sentir son odeur

Je vois deux avantages :
=> le texte narratif est plus fluide que s’il devait énumérer toutes les options possibles (tous les « cliquables »),
=> et le menu contextuel peut dépendre du type d’objet, ce qui (1) évite à l’auteur d’avoir à ressasir les options à chaque fois qu’il place ce type d’objet et (2) permet à l’auteur de modifier les options pour tous les objets de ce type depuis un seul et même endroit du code source.

Un autre élément important il me semble, c’est les dialogues avec les PNJs. Je pense qu’utiliser un moteur chatbot simple et efficace, comme Rivescript par exemple, serait tout indiqué. Par un système de classes et d’héritage, on peut facilement créer différents personnages plus ou moins profonds.

Connais-tu texture ? Apparemment, avec cet outil, tu peux facilement réaliser quelque chose qui se rapproche de ce que tu cherches. À la différence près que les actions/verbes/autres sont listées à la fin de chaque page, et qu’en cliquant sur l’une tu peux voir sur quel(s) mot(s) du texte l’appliquer.

L’approche inverse, mots puis verbes/actions/autre, est peut-être possible aussi, je n’ai pas trop creusé encore.
Voici un article qui présente Texture: rockpapershotgun.com/2016/0 … h-texture/
Et voici le site officiel du projet : texturewriter.com/

Personnellement, je trouve ça agréable de pouvoir lire une page de texte, sans aucun à priori, et ensuite de pouvoir m’intéresser à l’intéraction avec des mots de ce texte. (Ce que fait texture. Une option pour cacher les actions/verbes/autre en bas de page pourrait être intéressante aussi, afin de ne les afficher qu’une fois qu’on le veut bien)

Les systèmes qui affichent directement les mots soulignés (comme Twine) gâchent un peu l’effet « découverte du texte » je trouve. En voyant les mots soulignés on a tendance à vouloir anticiper ce qui va se passer par rapport à ça, à focaliser son attention sur ces parties-là du texte. Mais là pareil, pourquoi pas un bouton en bas de page pour « afficher les liens » une fois qu’on a fini de lire.

Ce projet devrait-il être abandonné ? Un service comme No IP permet d’associer un nom de sous-domaine à une adresse IP, même changeante. Donc un MUSH serait hébergeable à la maison, chez l’un d’entre nous.

Oui Balrog, j’ai regardé Texture, c’est vraiment pas con leur système, et effectivement assez proche d’un système où on commencerait par cliquer sur un groupe nominal pour voir un menu contextuel proposant les actions possibles. A creuser !

Par contre, je suis vraiment désolé d’avoir à te dire ça mais : Vous… Ne Passerez… PAAAS !!!
Ok je sors :smiley:

J’ai longtemps voulu héberger un MUD (non, sans baston ça ne m’intéresse pas =)), et j’avais regardé du côté de CircleMUD notamment, mais au final j’avais rien trouvé de très pratique et traduisible en FR facilement, et j’ai pas envie de coder mon propre moteur.

Mais c’était il y a… pfiou, plus de 10 ans :smiley: peut-être que depuis il existe des trucs qui pourraient le faire !

Coucou, j’suis reviendou.

Je passe juste faire un petit bonjour, prendre des nouvelles. J’espère que tout va bien par chez vous, et que la communauté prospère !? :slight_smile:

Ces temps-ci, je me désintéresse un peu de l’IA, et retourne plutôt vers l’IF. Depuis tout ce temps j’ai continué, de temps en temps, à travailler un univers dont j’avais esquissé les contours, si vous vous souvenez : cybermédieval, avec une religion omniprésente et oppressante, « Unité », en l’an de grâce 2484. Je ne sais plus où est le thread. J’ai notamment écrit une scène de guerre non interactive, dont le héros est Jean de Castres, qui reste à polir. Je reste dans l’ambiance Doom 1er du nom, c’est à dire Baron de l’enfer versus fusil à pompe.

Je suis content parce que depuis quelques jours, je fais tourner sur mon mini-ordi un serveur MUD « Smaug ». On peut assez facilement créer du contenu, donc c’est plutôt sympa. Par contre pour le traduire, c’est compliqué pour deux raisons : d’abord la quantité de texte déjà en place est juste énorme, et plus grave, une bonne partie du contenu est hard-codée dans les sources en C, qu’il faudrait recompiler avec Cygwin. Je suis pas chaud pour recompiler, l’intérêt étant justement d’avoir un serveur qui tourne out of the box. Et de toute façon, la traduction par 1 personne prendrait 10 ans.

Mais j’ai eu une idée ce matin. Je fais tourner le serveur Smaug tel quel. A côté de ça, un serveur Nodejs se connecte au serveur Smaug, se charge de la traduction de l’anglais vers n’importe quel langue, grâce à un module npm fort sympatique qui utilise l’API de Google Translate. Et le serveur Nodejs sert l’interface en HTML aux joueurs, avec une belle interface façon Undum.

Bref ça cogite dur. :unamused:

Voilà, au plaisir de vous lire !

Rererebievenue !

Tout va pas mal, et oui, la communauté prospère (même si elle a toujours du mal à décoller).

Je ne crois pas connaître Smaug. As-tu un lien ? Dans le principe, l’idée d’avoir un intermédiaire entre le MUD et l’interface n’est pas forcément mauvaise, mais ce n’est pas hyper idéal non plus. Surtout si ça utilise Google Translate, parce que d’une part c’est Google, et d’autre part ça risque de donner des résultats pas exactes.

Puisqu’on en retourne à la question de savoir quelle technologie utiliser, et qu’apparemment rien de ce qui avait été mentionné plus tôt ne convenait (PennMUSH, Evennia…), la seule solution qui resterait serait de créer un moteur soi-même (mais c’est plus de boulot, et c’est pas facile). J’espère qu’on finira par trouver une solution et que ça se concrétise !

Tiens, je profite de ton retour parmi nous pour te parler d’un projet de FI multijoueur que j’ai, semblable à Fallen London (que j’avais déjà mentionné dans ce fil). Je n’en suis qu’à la phase de design initial, il n’est pas sûr du tout que ça se concrétisera, mais je pense que ton avis pourrait être intéressant (si jamais tu as envie de le donner). J’en avais parlé dans ce sujet.

C’est simple : tu as le fil sous les yeux ! Il suffit simplement de retourner à la première page. :wink:

Content que la communauté aille bien.

Smaug c’est un moteur MUD. Il y a version SMAUGFUSS sur github, c’est vivant, et c’est à ma connaissance le seul MUD qu’on peut télécharger et mettre en route en 2 minutes chrono. Il suffit de télécharger les pré-compilés Win32 ici, de télécharger les données du jeu d’origine. On copie/colle les « areas » là où se trouve l’exécutable, et boum, un MUD tout nouveau tout beau, avec plein de contenus et tout et tout. Mais en anglais.

Alors je me suis amusé à coller du contenu Smaug dans Google Translate, pour voir la qualité. Bon ben non, ça le fait pas. La traduction est vraiment trop charabiesque pour jouer en immersion.

Mais j’ai une autre piste. Je suis parti sur Simplemud, une codebase Nodejs ultra-simple que j’ai traduit en français. Cela fonctionne, même si la complexité est très limitée : on peut se déplacer Nord/Sud/Est/Ouest, prendre/poser un objet, le vendre l’acheter, l’utiliser, et il y a des ennemis qui apparaissent aléatoirement (dont un écureuil de l’enfer particulièrement redoutable).

Le code de Simplemud tient sur trois cartes postales et demi. Donc ça fait une bonne base pour faire un hack’n slash, et on peut lui ajouter des fonctionnalités facilement. Je pense que je vais partir de là. Tel qu’il est pour l’instant, on peut s’en servir pour faire une sorte de FPS textuel ; on se déplace, on choppe du loot, et on s’entretue dans la bonne humeur.

Après j’ai trouvé un bon tuto pour héberger un serveur chez soi en passant par la box. J’ai un ordi qui ne sert à rien. J’ai déjà réservé mon DNS. Yapukaaaa !!!

Edit : https://github.com/lnguyenfx/simplemud

Adaptation du cyoa à plusieurs utilisateurs.

Certains lieux du MUD sont en fait des situations de sections à choix multiples.

Pour chaque section à choix multiple, il peut y avoir plusieurs situations de départ (différents lieux du MUD), et de nombreuses autres situations, toutes reliées entre elles par des choix menant des unes aux autres.

Chaque situation consiste en

  • Une description pour ceux qui se sont déjà retrouvés dans cette situation,
  • Une description pour ceux qui se retrouvent dans cette situation pour la 1ère fois,
  • Une description de comment un utilisateur se retrouve dans la même situation,
  • Une description de comment plusieurs utilisateurs se retrouvent dans la même situation,
  • Un renvoi éventuel vers une autre situation lors de l’arrivée d’autres utilisateurs,
  • Des listes de choix, leurs conditions de disponibilité, et les conséquences associées à chaque choix,
  • Un groupe d’utilisateurs actuellement dans cette situation.

Pour chaque situation, il peut y avoir plusieurs listes de choix qui s’ajoutent. La disponibilité d’une liste de choix peut être soumise à des conditions. Les conditions possibles sont :

  • Uniquement si l’utilisateur n’a pas encore utilisé cette liste de choix,
  • Uniquement si l’utilisateur se trouve dans cette situation pour la 1ère fois,
  • Uniquement si l’utilisateur s’est déjà retrouvé dans cette situation,
  • Uniquement si l’utilisateur est seul dans cette situation,
  • Uniquement s’il y a d’autres utilisateurs dans cette situation,
  • Uniquement si l’utilisateur possède tel objet,
  • Uniquement si l’utilisateur ne possède pas tel objet,
  • Uniquement si l’utilisateur a tel achèvement,
  • Uniquement si l’utilisateur n’a pas tel achèvement.

Un achèvement est une action que l’utilisateur a accompli précédemment : visiter un endroit, parler à quelqu’un, …etc.

Lorsque l’un des utilisateurs se trouvant dans une situation fait un choix, plusieurs choses se passent :

  • Celui qui fait le choix se retrouve dans une autre situation,
  • Les autres reçoivent un message décrivant le choix fait (et qui l’a fait), et ses conséquences,
  • Les autres se retrouvent éventuellement dans une autre situation (éventuellement la même que celui qui a fait le choix).

Quand un utilisateur se retrouve dans une situation dans laquelle d’autres utilisateurs se trouvent déjà, deux possibilités :

  • Soit ceux qui étaient déjà dans cette situation reçoivent un message décrivant comment cet utilisateur se retrouve dans la même situation qu’eux,
  • Soit tout le monde se retrouve dans une nouvelle situation.

Dans certaines situations, les caractéristiques des utilisateurs peuvent être modifiées, ainsi que leur inventaire, …etc.

Dans certaines situations, certains choix mènent à un retour vers un lieu du MUD.

… difficile de tout couvrir !