Una lista seleccionada de recursos, herramientas y aplicaciones de desarrollo de MUD.
Inspirado en la increíble lista.
Si desea agregar algo a esta lista, abra una incidencia o una solicitud de extracción.
Lista de clientes que puedes utilizar para conectarte a diferentes MUD, agrupados por sistema operativo. Incluye una lista de protocolos MUD con los que el cliente es compatible ( aunque puede ser una lista incompleta, ¡la ayuda es bienvenida! )
Enlaces a antiguos proyectos abandonados de clientes de barro de código abierto, tal vez haya algo útil allí:
Aplicaciones de servidor que permiten que un cliente web se conecte a un servidor mud/telnet:
Los MUD evolucionaron a partir del juego original (creado en 1978 en la Universidad de Essex por Roy Trubshaw y Richard Bartle), en familias de juegos relacionados, basándose principalmente en las tecnologías utilizadas para implementarlos.
Creado en 1987 en la Universidad de Aberystwyth, fue el primer MUD popular de código abierto. Portado a C en 1988 en AberMUD2 y publicado como GPL en AberMUD V. Inspiró las siguientes tres bases de código principales: TinyMUD, LPMud y DikuMUD.
Publicado por Jim Aspnes en 1989, ejecutándose en Unix y escrito en C.
MU* , a veces llamada familia Tiny , es una abreviatura que se refiere colectivamente a una familia que comprende: TinyMUD, MUSH, MOO, TinyMUCK. Tiene su propia wiki.
Variaciones principales: PennMUSH, TinyMUSH, TinyMUX y RhostMUSH.
Escrito por Stephen White en 1990. Ese mismo año, lanzó MOO.
Escrito por Stephen White en 1990, derivado de TinyMUCK, con diseño orientado a objetos. Pavel Curtis realizó modificaciones sustanciales al código MOO y creó LambdaMOO, que estaba alojado en Xerox PARC.
Publicado por Lars Pensjö en 1989, intentando combinar la extensibilidad de TinyMUD con las aventuras de AberMUD. Diseñó el lenguaje LPC (de Lars Pensjö C) y el driver/intérprete , intentando hacer más fácil el proceso de extensión del juego, separando el Mud en dos partes diferenciadas: el driver que actúa como máquina virtual/intérprete/runtime (programado en C), y el mudlib que implementa el código del juego (programado en LPC y ejecutado por el controlador ). Algunos juegos antiguos que todavía se juegan hoy en día comenzaron aquí: Genesis, BatMUD, NannyMUD, Discworld, etc.
Alguna documentación de idioma:
Después de que Lars Pensjö se retirara del desarrollo de LPMud, Joern Rennecke (Amylaar) se hizo cargo del desarrollo del controlador LPMud y produjo la serie 3.2 de LPMud. Esto a veces se conoce como el conductor Amylaar.
Otro grupo de personas empezó a trabajar desde LPMud v3.0 en 1992, y le cambió el nombre a MudOS, que tendrá varias versiones hasta 2003. ( mudos.org , su página web original ya no existe, pero se pueden encontrar algunas de las últimas versiones en el repositorio de maldorne y usarlos con Docker). Podría utilizar sockets a nivel mudlib (con código LPC), lo que permitió crear una red TCP intermud. Este protocolo evolucionó hasta Intermud 3.
Paralelamente a las últimas versiones de Mudos (la última fue v22.2b14, 2003), los desarrolladores de Discworld lo bifurcaron y lo rebautizaron como FluffOS. Aún mantenido. Tenía las versiones 1.0 a 1.36, 2.0 a 2.27, y desde 3.0 el mantenedor es Yucong Sun, y se lanzaron versiones principales con los nombres FluffOS 2017 y 2019.
Lars Düning continuó el desarrollo del controlador LPMud y le cambió el nombre a LDMud (pero manteniendo los números de versión de Amylaar, comenzando con 3.2.2). LDMud todavía se mantiene.
Felix 'Dworkin' Croes desarrolló en 1993 DGD (Dworkin Game/Generic Driver), no derivado de LPMud (por lo que no usa la misma licencia) pero es compatible con el lenguaje LPC. Aún mantenido y de código abierto desde la versión 1.4 (2010).
Inspirado en AberMUD y LPMud, creado en 1990/91 en DIKU ( Datalogisk Institut Københavns Universitet —el departamento de informática de la Universidad de Copenhague—) en Copenhague, Dinamarca.
Algunos derivados conocidos de DikuMUD: CircleMUD (web, fuente), MERC, Envy, ROM, SMAUG, GodWars, AwakeMUD (web, fuente).
Alguna información sobre algunos controladores/motores de juegos/bases de código modernos creados mucho tiempo después de los juegos MU* originales.
Creado por Greg Taylor en 2006, Samuel "Griatch" Regandell se hizo cargo del proyecto en 2011. Biblioteca moderna para crear juegos de texto multijugador en línea en Python puro. La codificación se realiza utilizando módulos Python normales importados al servidor en tiempo de ejecución. Licencia BSD.
Creado por Bo Zimmerman en el año 2000, creado 100% en Java. Admite cualquier base de datos JDBC/ODBC, incluye servidor web integrado. Licencia Apache.
Transmita directamente la entrada del cliente de lodo, necesaria para BBS, servidores *NIX, Roguelike MUD e interacción con otro software de consola.
Conéctese a servidores *NIX y BBS mediante negociaciones TELOPT.
Muestra interfaces de texto del lado del cliente y del servidor.
Negociar sobre el tamaño de la ventana . Envía el tamaño de la ventana del cliente mud al servidor. RFC 1073.
Hay dos RFC sobre la negociación de telnet: 854 y 855. Algunos de los siguientes protocolos se implementan como opciones de telnet, ampliando estos dos.
Protocolo genérico de comunicación con lodo . GMCP se implementa como una opción Telnet. Utiliza la sintaxis JSON para definir datos estructurados y escritos.
Protocolo de cliente de barro . Un intento de proporcionar un formato de mensaje estándar sobre el cual construir aplicaciones cliente-servidor basadas en MUD.
Protocolo de compresión de cliente de barro versión 2 y 3. MCCP2 se implementa como una opción Telnet. Permite que un servidor MUD comprima la salida al cliente receptor utilizando la biblioteca de compresión zlib. Creada en 1998, la versión 2 de MCCP se creó en 2000. En 2019, se creó la versión 3 de MCCP como un protocolo independiente.
Protocolo de datos del servidor de barro . MSDP se implementa como una opción Telnet. Desarrollado en 2009, proporciona una forma estandarizada de definir variables, matrices, tablas y comandos sin tipo. MSDP sobre GMCP ofrece manejo de eventos genéricos estandarizados además del envío de datos estructurados.
Protocolo de enlace del servidor de barro . Permite la creación de enlaces en los que se puede hacer clic en el lado del cliente. MSLP se negocia utilizando el estándar MTTS.
Protocolo de estado del servidor de barro . MSSP se implementa como una opción Telnet. Protocolo para que los rastreadores de MUD recopilen información detallada sobre un MUD, incluida información dinámica como el tiempo de inicio y la cantidad actual de jugadores en línea. Véase también GSGP.
Tipo de terminal de lodo estándar . Estándar transparente y sencillo para que los clientes de Mud comuniquen las capacidades de sus terminales. Véase también EMN.
Protocolo de chat Mud Master para mensajería instantánea y transferencias de archivos a través de conexiones P2P privadas. Es un protocolo de chat descentralizado que permite a los clientes de MUD comunicarse entre sí a través de una conexión TCP/IP.
Protocolo de extensión MUD .
Protocolo de sonido MUD .
Protocolo de medios del cliente MUD . Un estándar para cargar, reproducir y detener archivos multimedia con clientes MUD a través de GMCP que pretende modernizar MSP.
Formato de chat. Similar a MMCP pero no compatible.
Protocolo del juego Game Scry . GSGP es una estructura JSON estandarizada que puede poner a disposición de GameScry u otros sitios para realizar ping en busca de datos en tiempo real sobre un juego, sus jugadores activos, tablas de clasificación, etc. Consulte también MSSP.
Protocolo de cliente Achaea Telnet . cMUD implementó el uso del código TELNET 200 en 2008. En 2010 evolucionó a ATCP2 usando el código TELNET 201. Posteriormente pasó a llamarse GMCP. Achaea, Aardwolf, MUME, Avatar, Gensis y MUSHclient proporcionan definiciones de paquetes modeladas según el borrador de ATCP2.
Al igual que ATCP, Aardwolf incluye un canal oculto de información al que puedes acceder.
Nuevo estándar ambiental de barro . Implementado como una opción Telnet. Busca complementar MTTS proporcionando una forma sencilla de utilizar la opción telnet NEW-ENVIRON para intercambiar y actualizar varias configuraciones de clientes y servidores.
Protocolo de mapeo de lodo . Protocolo IronRealms como una forma de exportar nuestros datos de mapas del juego para que los clientes (o jugadores) puedan acceder y descargar fácilmente estos datos.
Protocolo de comunicación. HACER.