InterMUD-Portale

Einführung

MUD-Portale sind Verbindungen zwischen zwei MUDs. Sie sollen es erlauben, daß man Spieler aus den verbundenen MUDs in das jeweils andere MUD laufen können, ohne sich extra einen Charakter im zu besuchenden MUD anlegen zu müssen oder eine Loginprozedur durchlaufen zu müssen.

Technisch baut dazu ein MUD direkt mit dem anderen MUD eine Verbindung auf. Beide MUDs authentifizieren sich gegenseitig (durch ein TLS-Zertifikat). Wenn ein Spieler durch ein Portal geht, leitet das Ursprungs-MUD alle Eingaben des Spielers an das Ziel-MUD weiter, welches daraufhin eine Spielerfigur entsprechend agieren läßt. Das Ziel-MUD sendet wiederum alle für den Spieler gedachten Ausgaben an das Ursprungs-MUD.

Technische Voraussetzungen

Ein MUD sollte folgende Fähigkeiten haben, um Portale zu implementieren:

• Serialisierung im LDMud-Format (save/restore_value).
• Aufbau von ausgehende Verbindungen zu anderen MUDs.
• Unterstützung für mehrere TLS-Zertifikate, CAs und die Auswertung von Zertifikaten.
• Dedizierter Port für Portalverbindungen
• Simulation (Fernsteuerung) von Spieler-Objekten

Am besten lassen sich die Portale mit einem aktuellen LDMud umsetzen. Zur Simulation von Interactives steht ein Python-Paket bereit.

Um am Portalnetzwerk teilzunehmen, benötigt ein MUD ein TLS-Zertifikat, welches von Gnomi@UNItopia ausgestellt wird. Außerdem sollte sich das MUD dann mit mindestens einem Portal mit einem anderen MUD verbinden. Dazu tauscht man sich folgende Daten aus:

• Name des Portals
• Name des MUDs
• IP-Adresse des MUDs
• Port für Portalverbindungen

Integration

Bei der Integration der Portale in das MUD gibt es drei Hauptaufgaben:

Abschirmung des geparkten Charakters

Das Player-Ob eines Reisenden muß im Ursprungs-MUD sicher zwischengeparkt werden. Er sollte dort für die Reisezeit keinen Schaden erleiden und für andere Spieler nicht zugreifbar sein. Dies ist sehr mudlib-spezifisch, so daß es keine generelle Lösung dafür gibt.

Ferngesteuerte Simulation eines Spielers

Das Ziel-MUD sollte ein Player-Ob bereitstellen, welches anders als normale Spieler nicht durch einen Login-Vorgang erstellt wird, sondern über das Portalsystem initialisiert wird. Neben dieser technischen Herausforderung (Initialisierung eines virtuellen Spielers) muß man hier auch überlegen, wie die Startattribute aussehen sollen (welchen Namen, Geschlecht, Titel, Aussehen, Rasse etc. der Spieler haben soll). Die Daten aus dem Ursprungs-MUD können hier eine Orientierung sein.

Zudem muß dieser Spieler dann im weiteren Verlauf ferngesteuert werden. Dies kann theoretisch wie ein NPC erfolgen, aber viele Optionen im MUD stehen oftmals nur echten Spielern zu. Daher muß man vermutlich einen echten interaktiven Spieler simulieren. Dies geht (recht kompliziert) über Simul-Efuns, einfacher ist die Nutzung eines Python-Pakets für LDMud, welches eine Efun make_interactive() dafür bereitstellt.

Kommunikation zwischen den MUDs

Zur Kommunikation sollte man einen eigenen Port abstellen, über den TLS-verschlüsselt kommuniziert wird. Über diesen Port sollten keine Telnet-Codes ausgetauscht werden, sondern reiner ASCII-Text. Ein Beispiel dafür haben wir für die LP 2.4.5-Mudlib entwickelt (siehe portal_connection.c und portal_server.c).

Weiterentwicklungen

Die erste Version ist bewußt spartanisch gehalten. Es werden relativ wenig Daten zum Charakter übertragen, man kann keine Stats oder Gegenstände mitnehmen. Dies ist in bi- oder multilateraler Abstimmung ausbaufähig, d.h. MUDs könnten sich gegenseitig Fähigkeiten anerkennen oder Gegenstände übertragen, wenn es einen gemeinsamen Standard gibt. Im Moment gibt es aber noch keine Pläne dazu.