Protocolo y comunicación en juegos MUD de texto con Telnet

Si llevas un tiempo trasteando con juegos MUD de texto y clientes Telnet en el móvil, seguramente te habrás topado con la misma piedra: todo el mundo habla de historia, nostalgia y anécdotas sobre Telnet… pero casi nadie explica con claridad cómo demonios se comunican realmente el cliente y el servidor. Este artículo quiere justamente rellenar ese hueco: bajar a la arena del protocolo, de los mensajes, de las secuencias de control y de cómo hacer que tu propio servidor MUD se lleve bien con los clientes existentes.

Vamos a repasar de forma exhaustiva y aterrizada cómo funciona el protocolo típico de un MUD basado en Telnet, qué extensiones se usan en el mundillo (GMCP, MSSP, compresión, etc.), cómo se formatean los mensajes, qué espera ver el cliente móvil y qué debes enviar tú desde tu servidor para que todo fluya sin inventarte un protocolo desde cero. Todo ello explicado en castellano de España, con ejemplos claros y sin rodeos innecesarios.

1. Telnet como base: lo que realmente usa la mayoría de MUD

La mayoría de MUD clásicos no inventan un transporte nuevo: se apoyan en Telnet como capa de comunicación entre el cliente y el servidor. Eso significa que, al final del día, lo que se manda son flujos de bytes sobre TCP, donde el texto normal se mezcla con comandos Telnet especiales precedidos por el byte 255 (0xFF).

El servidor MUD se comporta, de cara a la red, como un servidor Telnet básico con un montón de extensiones opcionales. El cliente (ya sea móvil, de escritorio o un simple Telnet del sistema) establece una conexión TCP hacia el puerto del MUD (a menudo 23, 4000, 5000, etc.) y a partir de ahí empieza un pequeño baile de negociación de opciones.

En esa negociación inicial, ambas partes se van enviando secuencias de control Telnet del tipo “WILL”, “WONT”, “DO” y “DONT” para activar o desactivar capacidades: eco, tamaño de ventana, protocolos adicionales como GMCP, compresión, etc. Todo esto viaja mezclado con el texto de juego, pero el cliente sabe diferenciarlo porque los comandos de control van marcados con el famoso 0xFF.

2. Esqueleto del protocolo Telnet usado por los MUD

En Telnet, cualquier comando de control comienza con el byte IAC (Interpret As Command, valor 255). Después llegan uno o varios bytes que indican el tipo de comando y, en muchos casos, un código de opción. A nivel de protocolo MUD estándar, te vas a encontrar sobre todo con:

• IAC DO <opción>: “Quiero que tú (cliente) actives esta opción”.
• IAC DONT <opción>: “No quiero que uses esta opción”.
• IAC WILL <opción>: “Yo (servidor) puedo y quiero usar esta opción”.
• IAC WONT <opción>: “Yo no voy a usar esta opción”.

Las opciones se identifican por un número; algunos son estándares Telnet antiguos, otros son extensiones acordadas en la comunidad MUD (por ejemplo GMCP, MSSP, COMPRESS2), que no aparecen en los RFC clásicos de Telnet, pero que se han convertido en “pseudoestándar” de facto porque los principales clientes los soportan.

Como MUD, normalmente vas a iniciar el diálogo enviando secuencias IAC DO / IAC WILL para tantear qué soporta el cliente: si acepta GMCP, si quiere compresión, si ofrece información de terminal, etc. El cliente responderá con WILL/WONT o DO/DONT según corresponda. Tu servidor tiene que respetar esas respuestas y no usar una opción si el cliente no la acepta.

3. Separación entre texto de juego y control Telnet

Una de las dudas típicas es cómo diferenciar el texto normal del juego de los comandos de control. La regla es sencilla: cualquier cosa que no vaya precedida de 0xFF se considera texto. Los comandos Telnet siempre arrancan con ese byte especial, precisamente para evitar confusiones.

Ejemplo conceptual (no hace falta que lo copies literal, es solo para visualizar): el servidor puede enviar líneas de descripción del entorno seguidas de una secuencia IAC para negociar una opción. El cliente lee byte a byte: cuando ve 0xFF, entra en “modo comando”; el resto del tiempo lo trata como texto, aplica color ANSI si procede y lo muestra.

Si en algún momento necesitas enviar un byte 0xFF como parte del texto (algo bastante raro, pero posible), debes “escaparlo” duplicándolo. Es decir, para enviar un 0xFF literal en el flujo de datos userland, se mandan dos 0xFF seguidos, y el cliente los interpreta correctamente como “un solo 0xFF de texto, no un comando”.

4. Formato de los mensajes de texto: líneas, saltos y colores

La mayor parte del contenido que tu MUD va a mandar son mensajes de texto legibles: descripciones, diálogos, listados de objetos y comandos. Aunque parece trivial, conviene cuidar algunos detalles para que los clientes Telnet (especialmente en móvil) lo muestren bien.

En general, los MUD siguen usando el estilo clásico de líneas terminadas en CRLF (\r\n). Algunos clientes aguantan solo LF (\n), pero si quieres máxima compatibilidad, envía siempre retorno de carro seguido de salto de línea.

Para colores y formato, lo habitual es que los MUD utilicen códigos de escape ANSI insertados en el texto. Por ejemplo, secuencias que empiezan con ESC (0x1B) y siguen con “[31m” para texto rojo, “[1m” para negrita, etc. Estos no forman parte del protocolo Telnet en sí, pero son entendidos por la mayoría de terminales y clientes MUD avanzados, incluidos muchos clientes móviles.

5. Extensiones MUD sobre Telnet: GMCP, MSSP y compañía

Además del texto puro, hoy en día muchos MUD combinan Telnet con protocolos extra para intercambiar datos estructurados con los clientes. Eso permite que los clientes móviles muestren interfaces más ricos que un simple flujo de texto.

Entre las extensiones más frecuentes destacan:

• GMCP (Generic MUD Communication Protocol): envía información en formato tipo JSON (aunque no siempre estándar al 100%) sobre personaje, mapa, canales, etc.
• MSSP (Mud Server Status Protocol): pensada para dar datos del servidor (nombre del MUD, número de jugadores, género, etc.) a servicios de listado y a clientes curiosos.
• COMPRESS / COMPRESS2: compresión de datos para reducir ancho de banda, muy apreciada en conexiones lentas.

Estas extensiones se negocian igual que cualquier otra opción Telnet: el servidor suele enviar IAC WILL GMCP o IAC DO GMCP y espera la respuesta. Una vez acordado, la propia extensión define cómo encapsular los datos (por ejemplo, GMCP va dentro de subnegociaciones Telnet: IAC SB <opción> … IAC SE).

6. Subnegociación (SB y SE): encapsulando datos especiales

Cuando una opción Telnet requiere mandar más datos que un simple sí/no, se utiliza la subnegociación. El patrón es:

• IAC SB <opción> <datos…> IAC SE

Dentro de ese bloque, puedes mandar cadenas, números o estructuras específicas definidas por la extensión. Por ejemplo, GMCP suele mandar algo que se parece mucho a un objeto JSON, con comillas, llaves y valores.

El cliente, al recibir IAC SB GMCP, sabe que todo lo que viene hasta el IAC SE forma parte del paquete GMCP, y no del stream de texto normal del juego. Así, puede separar muy bien lo que va a la IU gráfica de lo que va al “buffer” de texto clásico.

7. Lo que manda el servidor MUD: flujo típico de comunicación

Imagina la secuencia desde que el jugador se conecta desde un cliente Telnet móvil a tu servidor MUD:

1. El cliente abre una conexión TCP al puerto del MUD.
2. El servidor le envía un banner de bienvenida (texto) y, probablemente, algunas secuencias IAC para negociar opciones (eco, GMCP, compresión…).
3. El cliente responde aceptando o rechazando esas opciones con WILL/WONT y DO/DONT.
4. A partir de ahí, el servidor manda la pantalla de login (texto) y va procesando comandos que el jugador teclea.

En todo momento, el servidor debe ser capaz de leer la entrada del cliente como una mezcla de texto y comandos Telnet, igual que el cliente hace con tu salida. Cuando el jugador escribe, por ejemplo, “north” y pulsa Enter, el cliente suele mandar esa cadena seguida de un retorno de carro y salto de línea. Tu servidor lee hasta el fin de línea y lo interpreta como un comando del jugador.

Si el cliente decide iniciar alguna opción (por ejemplo, activar una negociación de tamaño de ventana), tú también debes estar preparado para recibir secuencias IAC desde el lado del cliente y responder correctamente, no solo al revés.

8. Lo que envía el cliente Telnet (incluidos clientes móviles)

Desde el punto de vista de tu servidor, un cliente Telnet estándar (de móvil o de escritorio) te va a mandar básicamente dos tipos de cosas: texto de usuario y comandos Telnet. El texto suele ser ASCII o UTF-8 según el cliente; conviene asumir al menos UTF-8 a día de hoy.

Los comandos Telnet que te llegarán son, sobre todo, respuestas a tus peticiones de negociación. Si tú envías IAC DO GMCP, el cliente responderá con IAC WILL GMCP si lo soporta, o IAC WONT GMCP si no. También puede iniciar alguna negociación él mismo (por ejemplo, sobre el tipo de terminal).

Un detalle importante para compatibilidad con móvil es que muchos clientes modernos interpretan el envío carácter a carácter o línea a línea según configuración. Lo más habitual es línea a línea, así que estructura tu parser de entrada de comandos pensando en líneas completas separadas por \r\n o \n, no tanto en caracteres individuales.

9. Uso de proxies y problemas de red con MUD en redes restringidas

En algunos entornos (por ejemplo, redes corporativas, campus o ciertos operadores móviles) los puertos altos típicos de MUD pueden estar bloqueados por firewall. En esos casos, los jugadores se encuentran con que no pueden conectar directamente al puerto del MUD, aunque Telnet como tal sí esté permitido en puertos estándar.

Una solución clásica consiste en utilizar un proxy intermedio que escuche en un puerto permitido (como el 23 de Telnet o el 21 de FTP) y reenvíe la conexión hacia el puerto real del MUD. El proxy actúa de puente: el cliente se conecta al proxy y este, por debajo, abre la conexión al servidor del juego.

También es común que un colega con conexión permanente a Internet instale un proxy en su máquina y deje a otros jugadores entrar al MUD a través de su dirección IP. Eso sí, hay que vigilar el tema de las IP compartidas: si varias cuentas conectan desde la misma IP, algunos MUD pueden interpretarlo como multiplay ilegal y sancionar. Lo ideal es avisar a los administradores del juego si se va a compartir IP de forma continuada.

10. Limitaciones y riesgos de los proxies para MUD

Aunque un proxy puede salvarte la papeleta en redes muy cerradas, hoy en día no abundan los proxies anónimos públicos fiables y los pocos que quedan suelen estar saturados, caídos o vetados por motivos de seguridad.

Además, las mismas redes que bloquean puertos altos también pueden tener capado el puerto 8080, muy habitual para proxies HTTP. Por eso, si alguien monta un proxy privado para acceder a un MUD, conviene que lo sitúe en un puerto que casi nunca esté filtrado (el 23, el 21 o alguno muy típico y permitido en la red en cuestión).

No olvides que estos montajes tienen implicaciones de seguridad: el tráfico pasa por una máquina intermedia, se pueden registrar sesiones, contraseñas, etc. Desde el punto de vista del diseño del servidor MUD, el protocolo no cambia, pero sí tendrás que asumir que muchas conexiones entran “envueltas” por un proxy, con posibles latencias extra o desconexiones más frecuentes.

11. Ejemplo de interacción narrativa dentro de un MUD de texto

Más allá de lo técnico, un MUD de texto se sostiene sobre descripciones ricas y ambientación. En muchos juegos se incluyen trozos de texto icónicos, citas literarias o fragmentos casi poéticos que el servidor envía tal cual al cliente para reforzar la inmersión del jugador.

Por ejemplo, puede aparecer en pantalla una especie de “letanía contra el miedo” que se muestra cuando el personaje afronta un momento decisivo. Técnicamente, esto no es más que una secuencia de líneas de texto con sus saltos adecuados y, si quieres, algo de color o formato. Pero a nivel de experiencia, tiene un gran impacto.

Ese tipo de texto, aunque no altere el protocolo Telnet, condiciona cómo quieres gestionar el interlineado, el paginado y el refresco. Si sueltas de golpe varios párrafos largos en una sola ráfaga, en pantallas pequeñas (como las de móviles) se puede volver ilegible. Por eso muchos servidores implementan sistemas de “paginación” que detienen la salida tras cierto número de líneas y esperan a que el jugador pulse una tecla para seguir.

12. Recursos externos y documentación técnica adicional

A diferencia de otros protocolos muy bien estandarizados, el ecosistema MUD se ha alimentado mucho de documentos dispersos, PDFs académicos y artículos sueltos donde se describen variantes, propuestas de extensión y estudios sobre interacción en entornos MUD.

Existen trabajos disponibles en repositorios universitarios y bibliotecas digitales que analizan la arquitectura cliente-servidor de los MUD, la evolución desde Telnet desnudo hasta protocolos enriquecidos, e incluso cuestiones de experiencia de usuario en interfaces de texto. Aunque muchos de esos documentos no enseñan línea a línea cómo formatear el mensaje, sí ofrecen contexto útil para entender por qué se adoptaron ciertos protocolos y cómo se combinan.

Para complementar la implementación, conviene revisar también documentación de clientes populares de MUD (tanto de escritorio como móviles), donde suelen detallar qué extensiones soportan (GMCP, MXP, MSDP, etc.), qué juegos de caracteres manejan, cómo tratan los colores ANSI y qué limitaciones tienen en pantallas pequeñas.

13. Dominio masivo y nombres de host: el caos visible de la infraestructura

Si alguna vez has mirado los registros DNS de grandes proveedores de hosting, habrás visto listados inmensos de nombres como www, mail, ftp, webmail, smtp, pop3, imap, panel, cpanel, admin, dev, test y variantes sin fin. Aunque parezca ruido, esto refleja cómo se organiza de verdad la infraestructura donde se alojan muchos MUD y servicios relacionados.

Detrás de un único dominio se pueden colgar centenares de subdominios: servidores de bases de datos, máquinas de pruebas, proxies, balanceadores de carga, servicios de estadísticas, plataformas de correo, almacenamiento, VPN… y, con frecuencia, también el propio puerto donde escucha un MUD. En algunos casos, el juego está en un subdominio discreto; en otros, comparte IP con una maraña de servicios que van desde foros hasta wikis y paneles de administración.

Esa proliferación de nombres es relevante si estás pensando en publicar tu MUD en un servidor compartido o en montar proxies específicos para los jugadores: tendrás que coordinar bien qué subdominios apuntan a qué máquina, qué puertos se abren y cómo se gestiona la seguridad para que el tráfico Telnet no se mezcle de forma peligrosa con otros servicios críticos.

14. Consideraciones prácticas para clientes Telnet en el móvil

Jugar o desarrollar con un cliente Telnet en el móvil añade una capa de complicación: pantalla pequeña, teclado táctil, posibles desconexiones de red frecuentes y, a veces, limitaciones de los propios clientes en cuanto a soporte de extensiones.

Al diseñar tu servidor MUD, ten en mente algunos puntos:

• Evita líneas desmesuradamente largas: mejor párrafos cortos que el usuario no tenga que estar desplazando de lado a lado.
• Modera el uso de códigos ANSI y asegúrate de que no rompen el layout en clientes que no los interpretan bien.
• Maneja con cuidado la paginación para que la experiencia no sea un muro de texto imposible de seguir.
• Implementa reconexiones suaves: en móvil es fácil perder la señal y volver a entrar; tu servidor debería tolerarlo sin romper la sesión del jugador al primer corte breve.

Algunos clientes móviles especializados en MUD ya incorporan soporte para GMCP y otras extensiones, así que si las implementas en el servidor podrás ofrecer información estructurada que el cliente muestre como paneles, barras de vida, mapas rápidos y otras ayudas visuales por encima del texto clásico.

15. Crear tu propio servidor MUD compatible con clientes existentes

Si has decidido escribir tu propio servidor MUD desde cero, la clave para no quedarte aislado es respetar Telnet como capa base y negociar correctamente sus opciones. No necesitas reinventar el protocolo, sino seguir las convenciones que ya están probadas.

De forma muy resumida, para ser compatible con los clientes más comunes deberías:

• Implementar parsing de comandos Telnet (IAC, DO, DONT, WILL, WONT, SB, SE).
• Soportar al menos algunas opciones habituales: eco, supresión de eco local, GMCP si quieres datos enriquecidos, y quizá compresión.
• Enviar texto en formato amigable: CRLF, ANSI opcional, sin abusar de líneas enormes.
• Aceptar entrada en modo línea y tratar correctamente los saltos de línea que mandan los clientes móviles.

A partir de ahí puedes extender tu servidor con protocolos adicionales o incluso con un cliente propio, pero haber partido de esta base te permite probar tu juego con clientes Telnet ya existentes y aprovechar todo el ecosistema que se ha ido creando alrededor de los MUD a lo largo de los años.

Todo este entramado de Telnet, extensiones, proxys, nombres de host y peculiaridades de los clientes móviles puede parecer un lío al principio, pero si lo desgranas paso a paso verás que el núcleo es bastante sencillo: un flujo de texto con algunas secuencias de control bien definidas. Entendiendo cómo se forman esos mensajes, cómo se negocian las opciones y qué espera ver un cliente típico, tendrás en tus manos las herramientas necesarias para construir un servidor MUD robusto, compatible y disfrutable desde cualquier cliente Telnet, ya sea en el móvil o en el sobremesa.