mu*index
Lesen
Textfassung
Design

Referenz

Was die Codebases sind, was die Clients tun und was die Protokolle bedeuten. Von Hand geschrieben und im Repository neben dem Crawler abgelegt — kein Wiki, und auf dieser Seite gibt es nichts zu bearbeiten. Jede Zahl hier ist etwas anderes: Sie stammt aus dem Katalog und wird bei jedem Aufruf der Seite neu berechnet.

Hier anfangen

Codebases

  • AresMUSH Ein moderner Rollenspiel-Server in Ruby, mit Web-Oberfläche und eingebauten Szenen-Werkzeugen statt Softcode.
  • CircleMUD Die DikuMUD-Ableitung, die gut genug dokumentiert war, um damit zu unterrichten. Ungeheuer oft geforkt; läuft immer noch.
  • CobraMUSH Ein PennMUSH-Fork mit eigenem Divisions- und Befugnismodell. Geringe Verbreitung, antwortet weiterhin.
  • CoffeeMUD Ein MUD-Server in Java, mit dem größten MSSP-Bericht von allem, was wir abgefragt haben, und einer ungewöhnlich breiten Protokollfläche.
  • DikuMUD Die Wurzel der Kampf-MUD-Familie. Level, Klassen, Ausrüstung und Area-Dateien — und eine Lizenz, die eine ganze Generation von Ableitungen geprägt hat.
  • Evennia Eher ein Python-Framework als ein fertiges Spiel. Zwei Evennia-Spiele können außer dem Unterbau nichts gemeinsam haben.
  • FluffOS Der gepflegte MudOS-Nachfolger und der Driver, auf dem die meisten überlebenden LPMud-Spiele laufen. Das Spiel ist in LPC geschrieben, nicht in C.
  • MOO Objektorientiert, vollständig von innen heraus bearbeitet und ebenso sehr Forschungs- und Lehrplattform wie Spiel-Engine.
  • MUCK Ein TinyMUD-Nachfahre mit einer eigenen Forth-artigen Sprache im Spiel und einer sozialen Kultur, die sich von der MUSH-Seite unterscheidet.
  • PennMUSH Der am weitesten verbreitete MUSH-Server. Softcode, eine lange Veröffentlichungsgeschichte und eine von nur zwei Codebases in unserer Erhebung, die sowohl MSSP als auch ein WHO vor der Anmeldung beantworten.
  • RhostMUSH Ein MUSH-Server, bekannt für ein tiefes Rechtemodell und einen großen Satz eingebauter Funktionen. Kein MSSP; beantwortet ein WHO vor der Anmeldung.
  • ROM Der bekannteste Nachfahre von Merc und die Kampf-Engine, auf der ein großer Teil der Neunziger-MUDs aufgebaut wurde.
  • SMAUG Eine Merc-Ableitung für große thematische Welten, mit Gottheiten, Ebenen und einem Area-Bestand um ein Mehrfaches größer als der ihres Elternprojekts.
  • tbaMUD Die gepflegte Fortsetzung von CircleMUD und die übliche Antwort auf „Ich will heute einen MUD im Diku-Stil aufmachen“.
  • TinyMUSH Der Vorfahr der MUSH-Linie, auf dem noch Spiele laufen. Er hat diesem Crawler beigebracht, dass dessen eigene Aushandlungsbytes den nächsten Befehl kaputtmachen können, den er sendet.
  • TinyMUX Der andere große MUSH-Server. Softcode nah genug an dem von PennMUSH, um darüber zu streiten, gar kein MSSP und ein funktionierendes WHO vor der Anmeldung.

Clients

  • Atlantis Ein Client nur für macOS, langlebig und lange in der Beta. Sein Skripting ist als nicht mehr funktionierend dokumentiert, und das ist das eine ehrliche „Nein“ in diesem Abschnitt.
  • BeipMU Ein Windows-Client für die MUSH-Seite des Hobbys, mit Screenreader-Unterstützung im Ausgabefenster und Pueblo statt MXP.
  • Blightmud Ein moderner Terminal-Client in Rust, mit Lua-Skripting, eingebauter Sprachausgabe und einem Screenreader-Modus, der sich beim Server selbst ankündigt.
  • Mudlet Plattformübergreifend, mit Lua skriptbar und der Client mit der am gründlichsten dokumentierten Screenreader-Unterstützung in diesem Abschnitt.
  • MUSHclient Der seit Langem etablierte Windows-Client. Fünf Skriptsprachen, eine Plugin-Architektur, in der der Großteil seiner Protokollunterstützung lebt, und eine Veröffentlichungsgeschichte, die sich verlangsamt hat.
  • Potato MUSHclient Ein plattformübergreifender Tcl/Tk-Client, geschrieben für MUSH-Spieler. Gute Unterstützung für Kodierungen und eine Dokumentation, die zu den meisten Protokollen überhaupt nichts sagt.
  • TinTin++ Ein Terminal-Client mit eigener Skriptsprache, auf jeder Plattform einschließlich Telefonen, und mit einem dokumentierten Screenreader-Modus.
  • TinyFugue Der klassische UNIX-Terminal-Client. Upstream hat seit 2007 nichts mehr veröffentlicht; ein gepflegter Fork führt ihn weiter.
  • VIP Mud Ein kommerzieller Windows-Client, von Grund auf für blinde Spieler gebaut. Er nennt sieben Screenreader — und veröffentlicht fast nichts über seine Protokollunterstützung.

Protokolle

  • ATCP Der Vorgänger von GMCP. Out-of-Band-Daten mit lockererer Nutzlast, weitgehend abgelöst und immer noch von Servern ausgehandelt, die es nie entfernt haben.
  • CHARSET Die Telnet-Option aus RFC 2066, mit der eine Kodierung vereinbart wird. Der Grund, warum die Namen eines Spiels ihre Akzente über die Strecke retten, und die Ursache einiger subtiler Fehler, wenn sie fehlt.
  • GMCP Das Generic Mud Communication Protocol — strukturierte JSON-Nachrichten neben dem Text und der Out-of-Band-Kanal, gegen den die meisten modernen Clients entwickeln.
  • MCCP Kompression des Datenstroms. Billig, weit verbreitet und das Protokoll, das den lehrreichsten Fehler in der Geschichte dieses Projekts hervorgebracht hat.
  • MSDP Das Mud Server Data Protocol — dieselbe Aufgabe wie GMCP, erledigt mit einer kompakten binären Kodierung und einem Mechanismus zur Erkundung, den GMCP nicht hat.
  • MSP Das MUD Sound Protocol — der Server nennt eine Klangdatei, und der Client spielt sie ab. Alt, einfach und leicht mit zwei anderen Dingen zu verwechseln.
  • MSSP Das Mud Server Status Protocol — wie ein Spiel einem Crawler von sich erzählt. Alles, was es meldet, ist angegeben und nicht gemessen, und diese Website hält beides auseinander.
  • MXP Das MUD eXtension Protocol — HTML-ähnliche Auszeichnung im Textstrom, die anklickbare Links, Bilder und Formulare möglich macht. Umfassend spezifiziert, ungleichmäßig implementiert.
  • Pueblo Das ältere Verfahren, HTML in ein MUD zu bringen, aus dem gleichnamigen Client. Von Clients der MUSH-Seite weiterhin unterstützt und regelmäßig mit MXP verwechselt.
  • TLS Verschlüsselte Verbindungen. Meist ein eigener Port statt einer ausgehandelten Umstellung, und die eine Fähigkeit auf dieser Website, die wir durch Verbinden prüfen und nicht durch Fragen.
  • TTYPE und MTTS Wie ein Client einem Server sagt, was er ist und was er kann — auch, sofern der Client sich dafür entscheidet, dass ein Screenreader im Einsatz ist.