Protocole et communication dans les jeux MUD textuels avec Telnet

Si vous jouez depuis quelque temps à des jeux MUD textuels et utilisez des clients Telnet sur votre appareil mobile , vous avez probablement rencontré le même problème : tout le monde parle de l’histoire de Telnet, de la nostalgie qu’il évoque et des anecdotes… mais presque personne n’explique clairement comment le client et le serveur communiquent. Cet article vise à combler cette lacune : explorer le protocole, les messages, les séquences de contrôle et comment faire fonctionner votre propre serveur MUD de manière fluide avec les clients existants.

Nous allons examiner en détail et de manière simple le fonctionnement d'un protocole MUD typique basé sur Telnet , les extensions utilisées (GMCP, MSSP, compression, etc.), le formatage des messages, les attentes du client mobile et les éléments à envoyer depuis votre serveur pour un fonctionnement optimal, sans avoir à créer un protocole de toutes pièces. Ces explications seront données en espagnol standard (d'Espagne), avec des exemples clairs et sans jargon inutile.

1. Telnet comme base : ce que la plupart des MUD utilisent réellement

La plupart des MUD classiques n'inventent pas de nouveau protocole de transport : ils utilisent Telnet comme couche de communication entre le client et le serveur . Cela signifie qu'en fin de compte, ce sont des flux d'octets qui sont envoyés via TCP, où le texte normal est mêlé à des commandes Telnet spéciales précédées de l'octet 255 (0xFF).

Du point de vue du réseau, le serveur MUD se comporte comme un serveur Telnet basique doté de nombreuses extensions optionnelles . Le client (qu'il s'agisse d'un appareil mobile, d'un ordinateur ou d'un simple client Telnet système) établit une connexion TCP avec le port du serveur MUD (souvent 23, 4000, 5000, etc.), et un bref échange d'options s'ensuit.

Lors de cette négociation initiale, les deux parties s'envoient des séquences de contrôle Telnet de type « WILL », « WONT », « DO » et « DONT » pour activer ou désactiver des fonctionnalités : écho, taille de la fenêtre, protocoles supplémentaires comme GMCP, compression, etc. Tout cela est transmis mêlé au texte du jeu, mais le client peut le distinguer car les commandes de contrôle sont marquées par le code 0xFF bien connu.

2. Schéma du protocole Telnet utilisé par les MUD

En Telnet, toute commande de contrôle commence par l' octet IAC (Interpret As Command, valeur 255) . Il est suivi d'un ou plusieurs octets indiquant le type de commande et, dans de nombreux cas, un code d'option. Au niveau du protocole MUD standard, vous rencontrerez principalement :

IAC DO« Je veux que vous (le client) activiez cette option. »
IAC NE LE FAIT PAS«Je ne veux pas que vous utilisiez cette option.»
IAC« Je (le serveur) peux et veux utiliser cette option. »
IAC NE LE FERA PAS«Je ne vais pas utiliser cette option.»

Les options sont identifiées par un numéro ; certaines sont d'anciennes normes Telnet, d'autres sont des extensions convenues dans la communauté MUD (par exemple, GMCP, MSSP, COMPRESS2 ), qui n'apparaissent pas dans les RFC Telnet classiques, mais sont devenues une « pseudo-norme » de facto parce que les principaux clients les prennent en charge.

En tant que MUD, vous initiez généralement le dialogue en envoyant des séquences IAC DO/IAC WILL afin de tester les fonctionnalités prises en charge par le client : compatibilité GMCP, compression requise, affichage des informations du terminal, etc. Le client répond par WILL/WONT ou DO/DONT selon le cas. Votre serveur doit respecter ces réponses et ne pas utiliser d'option non prise en charge par le client.

3. Séparation entre le texte du jeu et la commande Telnet

Une question fréquente est de savoir comment distinguer le texte normal du jeu des commandes de contrôle . La règle est simple : tout ce qui n’est pas précédé de 0xFF est considéré comme du texte. Les commandes Telnet commencent toujours par cet octet spécial, précisément pour éviter toute confusion.

Exemple conceptuel (inutile de le copier à l'identique, il sert uniquement à la visualisation) : le serveur peut envoyer des lignes de description de l'environnement suivies d'une séquence IAC pour négocier une option. Le client lit les données octet par octet : lorsqu'il rencontre 0xFF, il passe en « mode commande » ; sinon, il traite les données comme du texte, applique la couleur ANSI si nécessaire et les affiche.

Si vous devez envoyer un octet 0xFF dans le cadre d'un texte (ce qui est rare, mais possible), vous devez l'« échapper » en le dupliquant . Autrement dit, pour envoyer littéralement 0xFF dans le flux de données utilisateur, vous envoyez deux octets 0xFF successivement, et le client les interprète correctement comme « un seul octet 0xFF de texte, et non comme une commande ».

4. Format des SMS : lignes, sauts de ligne et couleurs

La majeure partie du contenu envoyé par votre MUD se compose de messages texte lisibles : descriptions, dialogues, listes d’objets et commandes . Bien que cela puisse paraître anodin, il est important de prêter attention à quelques détails pour garantir un affichage correct par les clients Telnet (notamment sur mobile).

En général, les MUD utilisent encore le style classique de lignes se terminant par CRLF (\r\n) . Certains clients ne prennent en charge que LF (\n), mais pour une compatibilité maximale, envoyez toujours un retour chariot suivi d'un saut de ligne.

Pour la couleur et la mise en forme, les MUD utilisent généralement des codes d'échappement ANSI intégrés au texte. Par exemple, des séquences commençant par ESC (0x1B) suivies de « [31m » pour le texte rouge, « [1m » pour le gras, etc. Ces codes ne font pas partie du protocole Telnet, mais sont compris par la plupart des terminaux et des clients MUD avancés, y compris de nombreux clients mobiles.

5. Extensions MUD via Telnet : GMCP, MSSP et autres entreprises

Outre le texte brut, de nombreux MUD combinent aujourd'hui Telnet avec des protocoles supplémentaires pour échanger des données structurées avec les clients . Cela permet aux clients mobiles d'afficher des interfaces plus riches qu'un simple flux de texte.

Parmi les extensions les plus fréquentes, on trouve :

GMCP (Protocole de communication MUD générique): envoie des informations au format JSON (bien que pas toujours 100% standard) concernant les personnages, les cartes, les canaux, etc.
MSSP (Protocole d'état du serveur Mud): conçu pour fournir des données serveur (nom du MUD, nombre de joueurs, sexe, etc.) aux services d'annuaire et aux clients curieux.
COMPRESSER / COMPRESSER2La compression des données permet de réduire la bande passante, une fonctionnalité très appréciée pour les connexions lentes.

Ces extensions sont négociées comme n'importe quelle autre option Telnet : le serveur envoie généralement IAC WILL GMCP ou IAC DO GMCP et attend la réponse. Une fois l'accord conclu, l'extension définit la manière d'encapsuler les données (par exemple, GMCP s'inscrit dans les sous-négociations Telnet : IAC SB <option> … IAC SE).

6. Sous-négociation (SB et SE) : encapsulation des données spéciales

Lorsqu'une option Telnet nécessite l'envoi de plus de données qu'une simple réponse par oui ou par non, on utilise la sous-négociation . Le modèle est le suivant :

IAC SB IAC SE

Dans ce bloc, vous pouvez envoyer des chaînes de caractères, des nombres ou des structures spécifiques définies par l'extension . Par exemple, GMCP envoie généralement un objet très similaire à un objet JSON, avec des guillemets, des accolades et des valeurs.

Lorsque le client reçoit le paquet GMCP d'IAC SB, il sait que tout ce qui précède IAC SE fait partie du paquet GMCP et non du flux de texte normal du jeu. Cela lui permet de distinguer clairement ce qui est destiné à l'interface graphique de ce qui est destiné à la mémoire tampon de texte classique.

7. Ce que le serveur MUD envoie : flux de communication typique

Imaginez la séquence à partir du moment où le joueur se connecte à votre serveur MUD via un client Telnet mobile :

Le client ouvre une connexion TCP vers le port MUD.
Le serveur vous envoie une bannière de bienvenue (texte) et probablement quelques autres informations. Séquences IAC pour le trading d'options (écho, GMCP, compression…).
Le client répond en acceptant ou en rejetant ces options avec WILL/WONT et DO/DONT.
À partir de là, le serveur envoie l'écran de connexion (texte) et traite les commandes saisies par le joueur.

Le serveur doit pouvoir en permanence lire les entrées du client, qui combinent texte et commandes Telnet , tout comme le client lit vos sorties. Lorsque le joueur saisit, par exemple, « nord » et appuie sur Entrée, le client envoie généralement cette chaîne de caractères, suivie d'un retour chariot et d'un saut de ligne. Votre serveur lit jusqu'à la fin de la ligne et l'interprète comme une commande du joueur.

Si le client décide d'initier une option quelconque (par exemple, en déclenchant une négociation de la taille de la fenêtre), vous devez également être prêt à recevoir des séquences IAC du côté client et à y répondre de manière appropriée, et non pas seulement l'inverse.

8. Ce que le client Telnet envoie (y compris les clients mobiles)

Du point de vue de votre serveur, un client Telnet standard (mobile ou de bureau) vous enverra deux types d'informations : du texte utilisateur et des commandes Telnet . Le texte est généralement encodé en ASCII ou UTF-8 selon le client ; il est préférable de supposer qu'il est au moins encodé en UTF-8 de nos jours.

Les commandes Telnet que vous recevez sont principalement des réponses à vos requêtes de négociation . Si vous envoyez `IAC DO GMCP`, le client répondra par `IAC WILL GMCP` s'il le prend en charge, ou par `IAC WONT GMCP` dans le cas contraire. Il peut également initier lui-même une négociation (par exemple, concernant le type de terminal).

Un détail important pour la compatibilité mobile : de nombreux clients modernes interprètent les commandes caractère par caractère ou ligne par ligne, selon leur configuration . L’interprétation ligne par ligne étant la plus courante, structurez votre analyseur de commandes en pensant à des lignes complètes séparées par \r\n, et non à des caractères individuels.

9. Utilisation de proxys et problèmes de réseau avec les MUD dans les réseaux restreints

Dans certains environnements (réseaux d'entreprise, campus ou chez certains opérateurs mobiles, par exemple), les ports élevés généralement utilisés par les MUD peuvent être bloqués par les pare-feu . Dans ce cas, les joueurs ne peuvent pas se connecter directement au port du MUD, même si Telnet est autorisé sur les ports standards.

Une solution classique consiste à utiliser un proxy intermédiaire qui écoute sur un port autorisé (comme le port 23 de Telnet ou le port 21 de FTP) et redirige la connexion vers le port du serveur de jeu. Le proxy fait office de pont : le client se connecte au proxy, et celui-ci, en arrière-plan, ouvre la connexion avec le serveur de jeu.

Il est également fréquent qu'un collègue disposant d'une connexion internet permanente installe un proxy sur son ordinateur et permette à d'autres joueurs d'accéder au MUD via son adresse IP . Cependant, il faut être prudent avec les adresses IP partagées : si plusieurs comptes se connectent depuis la même adresse IP, certains MUD peuvent interpréter cela comme du multijoueur illégal et infliger des sanctions. Idéalement, vous devriez informer les administrateurs du jeu si vous prévoyez de partager régulièrement votre adresse IP.

10. Limites et risques liés aux substituts pour les troubles de l'humeur.

Bien qu'un proxy puisse vous sauver la mise dans des réseaux très fermés, les proxys publics anonymes fiables sont aujourd'hui rares et ceux qui subsistent sont généralement surchargés, hors service ou bloqués pour des raisons de sécurité.

De plus, les mêmes réseaux qui bloquent les ports élevés peuvent également bloquer le port 8080 , ce qui est très fréquent pour les proxys HTTP. Par conséquent, si quelqu'un configure un proxy privé pour accéder à un MUD, il est conseillé de le placer sur un port rarement filtré (23, 21 ou tout autre port courant et autorisé sur le réseau en question).

Utilisez votre téléphone portable comme serveur FTP pour des transferts rapides.

11. Exemple d'interaction narrative au sein d'un MUD textuel

Au-delà des aspects techniques, un MUD textuel repose sur des descriptions riches et une ambiance immersive . De nombreux jeux intègrent des extraits de texte emblématiques, des citations littéraires ou des fragments quasi poétiques que le serveur transmet tels quels au client afin de renforcer l'immersion du joueur.

Par exemple, une sorte de « litanie contre la peur » pourrait apparaître à l'écran lorsque le personnage se trouve face à un moment crucial. Techniquement, il ne s'agit que d'une suite de lignes de texte avec des sauts de ligne appropriés et, si souhaité, une mise en couleur ou une mise en forme. Mais en termes d'expérience utilisateur, l'impact est considérable.

Ce type de texte, sans modifier le protocole Telnet, influe sur la gestion de l'interligne, de la pagination et de la fréquence de rafraîchissement . L'affichage de plusieurs longs paragraphes à la suite peut rendre le texte illisible sur les petits écrans (comme les téléphones portables). C'est pourquoi de nombreux serveurs implémentent des systèmes de pagination qui interrompent l'affichage après un certain nombre de lignes et attendent que l'utilisateur appuie sur une touche pour continuer.

12. Ressources externes et documentation technique supplémentaire

Contrairement à d'autres protocoles hautement standardisés, l'écosystème MUD a été alimenté par des documents épars, des PDF universitaires et des articles épars décrivant des variantes, des propositions d'extension et des études sur l'interaction dans les environnements MUD.

Des ouvrages disponibles dans les archives universitaires et les bibliothèques numériques analysent l'architecture client-serveur des MUD, l'évolution du Telnet rudimentaire vers des protocoles plus complexes , et même les problématiques d'expérience utilisateur liées aux interfaces textuelles. Bien que nombre de ces documents n'expliquent pas en détail la mise en forme des messages, ils offrent un contexte utile pour comprendre le choix de certains protocoles et leur combinaison.

Pour compléter la mise en œuvre, il est également conseillé de consulter la documentation des clients MUD populaires (de bureau et mobiles), qui détaille généralement les extensions qu'ils prennent en charge (GMCP, MXP, MSDP, etc.), les jeux de caractères qu'ils gèrent, la manière dont ils gèrent les couleurs ANSI et les limitations qu'ils présentent sur les petits écrans.

13. Domaines et noms d'hôtes massifs : le chaos visible de l'infrastructure

Si vous avez déjà consulté les enregistrements DNS des principaux hébergeurs, vous avez probablement remarqué de longues listes de noms comme www, mail, ftp, webmail, smtp, pop3, imap, panel, cpanel, admin, dev, test, et d'innombrables variantes . Bien que cela puisse paraître du bruit, ces enregistrements reflètent en réalité l'organisation de l'infrastructure hébergeant de nombreux MUD et services associés.

Derrière un seul nom de domaine se cachent des centaines de sous-domaines : serveurs de bases de données, machines de test, proxys, équilibreurs de charge, services de statistiques, plateformes de messagerie, stockage, VPN … et souvent même le port sur lequel un MUD est à l’écoute. Dans certains cas, le jeu se déroule sur un sous-domaine dédié ; dans d’autres, il partage une adresse IP avec un enchevêtrement de services, des forums aux wikis en passant par les panneaux de contrôle.

Cette prolifération de noms est importante si vous envisagez de publier votre MUD sur un serveur partagé ou de configurer des proxys spécifiques pour les joueurs : vous devrez coordonner soigneusement quels sous-domaines pointent vers quelle machine, quels ports sont ouverts et comment la sécurité est gérée afin que le trafic Telnet n’interfère pas dangereusement avec d’autres services critiques.

14. Considérations pratiques pour les clients Telnet sur mobile

Jouer à des jeux ou développer avec un client Telnet sur un appareil mobile ajoute une couche de complication : petit écran, clavier tactile, déconnexions réseau fréquentes possibles et parfois limitations des clients eux-mêmes en termes de prise en charge des extensions.

Lors de la conception de votre serveur MUD, gardez quelques points à l'esprit :

Évitez les files d'attente trop longues.: des paragraphes plus courts pour que l'utilisateur n'ait pas à faire défiler horizontalement.
Modérer l'utilisation des codes ANSI Et veillez à ce qu'ils ne perturbent pas la mise en page pour les clients qui ont du mal à les interpréter.
Gérez la pagination avec soin. pour que l'expérience ne se résume pas à un mur de texte impossible à suivre.
Mettre en œuvre des reconnexions doucesSur mobile, il est facile de perdre le signal et de se reconnecter ; votre serveur doit tolérer cela sans interrompre la session du joueur à la première brève interruption.

Certains clients mobiles spécialisés dans les MUD intègrent déjà la prise en charge de GMCP et d'autres extensions. Ainsi, si vous les implémentez sur le serveur, vous pouvez proposer des informations structurées que le client affiche sous forme de panneaux, de barres de santé, de cartes rapides et d'autres aides visuelles en plus du texte classique.

15. Créez votre propre serveur MUD compatible avec les clients existants

Si vous avez décidé de créer votre propre serveur MUD, la clé pour éviter l'isolement est de respecter Telnet comme couche de base et de configurer correctement ses options . Inutile de réinventer le protocole : suivez plutôt les conventions éprouvées.

En résumé, pour être compatible avec la plupart des clients, vous devriez :

Mettre en œuvre Analyse des commandes Telnet (IAC, DO, DONT, WILL, WONT, SB, SE).
Prendre en charge au moins certaines options courantes : écho, suppression locale de l'écho, GMCP Si vous souhaitez des données enrichies, et éventuellement une compression.
Envoyer texte dans un format convivialCRLF, ANSI optionnel, sans utiliser de lignes trop longues.
Accepter les entrées en mode en ligne et gérer correctement les sauts de ligne envoyés par les clients mobiles.

À partir de là, vous pouvez étendre votre serveur avec des protocoles supplémentaires ou même avec votre propre client, mais partir de cette base vous permet de tester votre jeu avec les clients Telnet existants et de profiter de tout l'écosystème qui s'est créé autour des MUD au fil des ans.