Portale

[Gnomi@Uni]

Hallihallo,

wie ich letztens schon auf dem D-Code erzaehlte, habe ich mich in letzter
Zeit damit beschaeftigt, InterMUD-Portale zu bauen, mit denen es moeglich
ist, von einem MUD in das naechste zu wandern. Ich suche jetzt 1 oder 2
echte MUDs, um das ganze zur Serienreife auszubauen.

Das Prinzip hinter den Portalen ist einfach, im Ursprungs-MUD wird der
Charakter in irgendeiner finsteren Ecke geparkt und alle seine Eingaben
an das Gast-MUD geschickt. Im Gast-MUD laeuft dann ein ferngesteuerter
Charakter herum, erhaelt die Befehle aus dem Ursprungs-MUD, fuehrt sie aus
und liefert alle empfangenen Meldungen zurueck an das Ursprungs-MUD.
Die Herausforderungen liegen darin, im Ursprungs-MUD den geparkten Charakter
vom MUD abzuschirmen (man sollte ihm keine Bomben zustecken koennen, nicht
an Krankheiten sterben lassen, etc.) und im Ziel-MUD den ferngesteuerten
Charakter echt aussehen zu lassen (d.h. wie ein interaktives Objekt), damit
alle anderen Objekte ihn als Player erkennen.


Kommunikation zwischen den MUDs
-------------------------------
Ich hatte zuerst eine Variante entwickelt, welcher den Datenaustausch via
InterMUD2 durchfuehrte. Hat auch prima funktioniert, allerdings wollte ich
die Kommunikation sicher gestalten, so dass ich auf TLS-Verbindungen setze.
(Fuer LDMud mit OpenSSL funktioniert das sehr gut, bei GnuTLS braucht man
die allerneueste LDMud-Version.) Ich habe dazu eine eigene CA eingerichtet,
welche die Zertifikate eigens fuer diese Portalsverbindungen ausstellt,
damit man sich als 'Morgengrauen' statt 'mg.mud.de' ausweisen kann.
(Ich habe eine Erweiterung fuer LDMud programmiert, welche mit mehreren
Zertifikaten umgehen kann, so dass man sich bei Telnet mit dem DNS-Namen
und bei den Portalen mit dem MUD-Namen identifiziert. Ich denke, dass dies
demnaechst in den Hauptentwicklungszweig einfliessen wird.)

Die MUDs schicken sich gegenseitig Anforderungen, welche nicht bestaetigt
werden. (Denn das sendende MUD kann ja eh nicht auf die Antwort warten,
sondern muss weitermachen.) Im Fehlerfalle sendet das MUD einfach eine
QUIT- oder LEAVE-Anforderung zurueck. Gesendet wird ein Mapping mit
Anforderungstyp und Parametern, welches via save_value() serialisiert wird.
(Hier kann man sich spaeter auch z.B. JSON vorstellen, fuer LDMud gibt's ja
bereits eine entsprechende Erweiterung.) Folgende Anforderungen habe ich mir
da bisher ausgedacht:

Vom Ursprungs- und Gast-MUD:
- P_TYPE_HELLO: Begruessung, dient derzeit nur zur Kontrolle der
Identitaet. Kann auch zum Aushandeln von
Verbindungsparametern dienen.

Vom Ursprungs-MUD:
- P_TYPE_ENTER: Ein Spieler wuerde gern im Gast-MUD wandeln. Gesendet
werden Name, Geschlecht, Save-Daten von frueheren
Besuchen.
- P_TYPE_LEAVE: Der Gast soll die Welt verlassen (er hat das
Ursprungs-MUD verlassen). Dient auch als Fehlermeldung,
dass der Spieler gar nicht mehr im Ursprungs-MUD ist.
- P_TYPE_COMMAND: Der Spieler hat einen Befehl eingegeben.


Vom Gast-MUD:
- P_TYPE_MOVE: Der Gast ist durch ein weiteres Portal gewandelt.
Gesendet werden Ziel-MUD und -Portal. Das Ursprungs-MUD
darf dann selbst eine Verbindung dahin aufbauen.
Wenn das Ziel-MUD das Ursprungs-MUD ist, kommt er
einfach nur wieder zurueck.
- P_TYPE_QUIT: Der Gast hat das Gast-MUD abrupt verlassen (ohne
Betreten eines Portals). Dient auch als Fehlermeldung,
dass der Spieler dort gar nicht mehr ist oder sein kann.
- P_TYPE_MESSAGE: Der Gast hat eine Meldung erhalten.
- P_TYPE_SAVE_DATA: Das Ursprungs-MUD moege bitte diese Daten fuer den
naechsten Besuch sichern (statt eines Savefiles im
Gast-MUD).

Das Interface ist also bewusst spartanisch gehalten. Ein Spieler bekommt im
Gast-MUD einen neuen eigentlich unabhaengigen Charakter, er kann keine
Gegenstaende oder Stats mitnehmen, er behaelt nur seinen Namen. (Dies ist
natuerlich ausbaufaehig. Ich habe z.B. unser Test-MUD Orbit so angebunden,
dass der Gast eines UNItopia-Gottes auch dort Gott ist, die Information
zum Level wird also uebertragen und von unserem Test-MUD honoriert.)


Mudlib im Ursprungs-MUD
-----------------------
Wer sich's anschauen will, die Dateien, auf die ich mich beziehe, sind alle
in unserer oeffentlichen Mudlib vorhanden:
http://www.unitopia.de/pub/UNItopia/mudlib.tar.gz

Beide MUDs brauchen statt des Player-Ob ein eigenes Objekt fuer die
InterMUD-Verbindung (/secure/portal/obj/connection.c), welche vom Master
dezu befugt ist, via net_connect() eine Verbindung ins Internet aufzubauen
(es muss auch Telnet via set_telnet() abschalten koennen und das passende
Zertifikat via configure_driver() auswaehlen duerfen, wenn es mehrere
Zertifikate gibt). Dazu gibt es den Portal-Master (/secure/portal/portal.c),
welcher alle Verbindungen und Reisende verwaltet. Alle Anforderungen der
eigenen Seite und der Gegenseite schlagen hier auf, werden geprueft und
weitergeleitet.

Der Abstellraum fuer Reisende (/room/portal.c) ist entsprechend abgesichert,
dass man da nicht aus Versehen reinkommt, denn der Raum faengt alle Eingaben
ab (doppelt, einmal via input_to und einmal via add_action("cmd", "",
AA_NOSPACE)) und sendet sie ueber den Master zur Gegenseite. Spieler in
diesem Raum muessen nun vom MUD abgekoppelt werden. Das beginnt allein da
schon, wenn ein zweiter Spieler in den Portal-Raum bewegt wird und eine
Ankommensmeldung bewirkt. In UNItopia haben wir ein Message-System, welches
bewirkt, dass alle Meldungen in einer Lfun des Spielers aufschlagen. Dort
habe ich einen Filter eingebaut, wenn der Spieler in diesem Raum steht.
Zudem muss man auch mudlib-spezifisch zeitliche Effekte (z.B. Krankheiten)
ausschliessen, dies geht nur von Fall zu Fall und wird man wohl erst im
Dauertest eliminieren koennen. Wobei ich ueberlege, ob diese Player-Objekte
nicht einen net-dead simulieren sollten, damit duerfte man einiges
erschlagen.

Ansonsten benoetigt der Player noch eine Ablage fuer die Sicherungsdaten aus
den MUDs und eine Funktion zur Wiedergabe der Meldungen (/i/player/intermud.c,
ganz unten). Die Meldungen habe ich uebrigens um UNIlib-spezifische
Attribute ergaenzt, so dass die Meldungsart (Kommunikation, Emote, Kampf,
Debug) mit uebertragen wird.

In UNItopia haben wir zudem die Moeglichkeit, dass man eine getrennte
Eingabezeile einstellen kann (/i/player/vt100client.c), diese arbeitet
aehnlich wie der Abstellraum, indem sie alle Eingaben des Spielers abfaengt
und verarbeitet. Auch wenn das prinzipiell kein Problem ist (diese
Eingabezeile hat Vorrang), so bietet sich hier ein kurzer Dienstweg an,
dass die Eingabezeile die entgegengenommene Eingabe direkt ans Portal
weiterreicht.

Zur Infrastruktur gehoeren noch die Portale selbst (/i/object/portal.c)
und eine Liste aller verfuegbaren (erlaubten) Portale (/static/adm/PORTALS,
in der mudlib.tar.gz unter /static/adm/examples/PORTALS).


Mudlib im Gast-MUD
------------------
Der Gast-Char ist bei uns ein regulaeres Player-Ob, welches aber gesondert
initialisiert wird (/i/player/intermud.c, setup_intermud_player()). Es liest
seine Daten nicht aus dem Savefile, sondern vom Portal, setzt die Variablen
dementsprechend und beginnt dann die normale Setup-Routine. Ich hatte zuerst
'Gnomi@UNItopia' als Namen gesetzt, aber fand dies in den dadurch
generierten Meldungen stoerend und bin daher erstmal bei 'Gnomi' als Namen
mit 'Gnomi aus UNItopia' als Titel geblieben. Dadurch kann es zu
Verwechslungen kommen, wenn zwei Gnomis unterwegs sind, inwiefern das zu
Problemem fuehrt oder ob man sich daran gewoehnt, werden wir sehen. Dies
kann natuerlich jedes MUD handhaben, wie es beliebt.

Nicht nur die Laderoutine, sondern auch die Saveroutine muss angepasst
werden, dass die Daten nicht abgespeichert, sondern via Portal
zurueckgesandt werden. Wobei ein MUD sich auch entscheiden kann, die Daten
nicht zu senden, sondern lokal zu speichern. Dann hat man weiterhin die
volle Kontrolle ueber Savefiles, bekommt aber ggf. Charloeschungen nicht
mit.

Die groesste Herausforderung fuer die Mudlib des Gast-MUDs ist aber, einen
interaktiven Player zu simulieren. Bei uns sind daher folgende Efuns in die
Simul-Efun gewandert:

- input_to, query_input_pending:
(/secure/simul_efun/input_to.inc, /i/player/input_to.c)
Wir hatten schon frueher eine input_to-Sefun zur Umlautkonvertierung,
welche um die Callback-Funktion eine Closure herumpackt. Daher werden
bei uns find_input_to, remove_input_to und input_to_info nicht
unterstuetzt und muessen auch nicht simuliert werden. input_to und
query_input_pending werden gleichermassen fuer unsere getrennte
Eingabezeile (die ja ein eigenes staendiges input_to unterhaelt und
daher andere input_tos simulieren muss) wie fuer InterMUD-Gaeste
simuliert. Der Player verwaltet hier also selbst eine Liste aller
input_tos mit ihren Prompts.

- caller_stack, caller_stack_depth, this_interactive:
(/secure/simul_efun/interactive.inc)
Diese Funktionen simulieren, dass der Aufruf eines Befehls nicht vom
Connection-Objekt ueber den Portal-Master bis zum Player-Ob und dann
zur Action gelaufen ist, sondern direkt vom Player-Ob kam.

- interactive, query_once_interactive, remove_interactive, query_idle,
set_prompt, users:
(/secure/simul_efun/interactive.inc)
Diese Funktionen behaupten, dass es bei dem Player-Ob tatsaechlich um
einen interaktiven Spieler handelt.

Bei uns sind zudem tell_object, tell_room, say, write, printf noch sefuns,
(/secure/simul_efun/comm.inc), die alle Meldungen zur Lfun receive_message()
schicken, von wo sie dann zum Ursprungs-MUD geschickt werden koennen.
Stattdessen kann man aber genauso gut catch_tell() implementieren.

Ansonsten wird noch benoetigt, dass der Master Verbindungen ueber einen
speziellen Port als Portalverbindungen erkennt und annimmt
(/secure/master/connections.inc).


Schlusswort
-----------
Ich hoffe natuerlich langfristig moeglichst viele MUDs derart anbinden zu
koennen, denn ich denke, dass dies ein riesiger Gewinn fuer alle Seiten
darstellt. Aber am Anfang moechte ich erst mit einem oder zwei anderen MUDs
(abgesehen von HomeMUDs) beginnen und wuerde mich freuen, wenn sich da
jemand meldet. Der von mir fuer die Portale programmierte Code (Alles unter
/secure/portal, /i/player/input_to.c und intermud.c, /i/object/portal.c,
/room/portal.c und /secure/simul_efun/interactive.inc) steht unabhaengig
vom UNItopia-Copyright zur freien Verfuegung, sofern die Autoren genannt
bleiben (entsprechend dem LDLib-Copyright). Und ich stehe natuerlich bei
der Implementierung mit Rat und Tat zur Verfuegung.

Gruss
Gnomi@UNItopia

[Skeeter@Uni]

Eine tolle Idee! Sagst du mir Bescheid, wenn sich ein Tuerchen fuer Spieler
auftut?

Skeeter

[Alloy@FF]

Hallo,

zunaechst mal bin ich grundsaetzlich sehr angetan von der Idee, solche
Fremdwandler im MUD zu sehen, das macht sich sicher ganz lustig in einem
ScienceFiction-MUD.
Ich weiss auch, dass viele Leute bei uns schon vor Jahren mehr im Scherz
darueber sprachen, wie wuenschenswert ein solches Portal doch waere (bei uns
sollte es dann uebrigens eher ein Wurmloch oder eine Singularitaet sein).
Wir muessten bei uns im MUD erstmal ne Weile nachdenken und diskutieren, ehe
man ja oder nein sagen koennte.

> Das Interface ist also bewusst spartanisch gehalten. Ein Spieler bekommt im
> Gast-MUD einen neuen eigentlich unabhaengigen Charakter, er kann keine
> Gegenstaende oder Stats mitnehmen, er behaelt nur seinen Namen. (Dies ist
> natuerlich ausbaufaehig.

Der Fremdwandler waere also eine Art Gast. Man muesste auf jeden Fall testen,
wie aehm kreativ unsere eigenen Spieler mit dem neuen Feature umgehen wuerden.

Einige Punkte, die aus FF-Perspektive zu bedenken waeren (keine vollstaendige
Liste):
- FF hat 5 Rassen(=Voelker), die auf 4 unserer Sternensysteme verteilt
starten; eine der Rassen hat 3 Geschlechter. Unsere normalen Gaeste koennen
auf Wunsch die Rasse bestimmen, sonst werden sie ausgewuerfelt.
- Fremdwandler muessten ganz normal Schaden nehmen koennen, damit sie nicht
benutzt werden, betont gefaehrlich gestaltete Gegenden risikolos zu erkunden.
- Bei uns ist es absolut verpoent, Spieler zu ermorden, und das kommt auch nur
sehr selten vor, meist aus Versehen. Andererseits wird bei uns leider alles
ziemlich schnell umgehauen, was nicht auf Anhieb wie ein regulaerer Spieler
aussieht - ein Wandler muesste da vom Design her eingefuegt werden.
- Insgesamt sollte es moeglichst so sein, dass das Gast-MUD ueber die Jahre
auf simple Weise nachschrauben koennte.

Die Test-Version von FF haben wir leider derzeit nicht im Angebot; wenn sich
etwas ergibt, melden wir uns spontan :)

Viele Gruesse durchs Wurmloch sendet

Alloy

[Gnomi@Uni]

Huhu,

> - Fremdwandler muessten ganz normal Schaden nehmen koennen, damit sie
> nicht benutzt werden, betont gefaehrlich gestaltete Gegenden risikolos
> zu erkunden.

Also bei uns sind diese InterMUD-Gaeste ganz normale Spieler, sie koennen
raetseln, kaempfen, Mitglied in einer Gilde werden, ihre Stats verbessern
und eben auch sterben. Alle Daten werden fuer den naechsten Besuch
abgespeichert, so dass man auch wirklich was zu verlieren hat.

Gruss
Gnomi

[Gynite@FF]

Das klingt alles ganz nett und *huestel* vertraut. ;) Gute Idee auf jeden
Fall.

Ich finde, neben den normalen Eigenschaften der Gastspieler, also dass sie
praktisch echte chars und keine fluechtigen Gaeste sein sollten, waere die
Rasse und individuelle Erscheinung so ein Punkt, der das ganze reizvoll macht.
Also dass man zumindest rein aesthetisch seinen Char behalten kann, nur eben
mit eingeschraenkten Faehigkeiten.

Nur wenn das gegeben ist, lohnt sich der Aufwand ueberhaupt. Anderenfalls
besteht ja kaum ein Unterschied dazu, nebenbei noch in einer zweiten und
dritten Welt einzuloggen und dort einen Char hochzuspielen.

Es braeuchte also eine neutrale Rasse und eine initiale Moeglichkeit beim
Wechsel, die entsprechenden settings (race, gender, long, title etc) vom
Hauptchar mit rueberzunehmen (man koennte es auch voellig frei beschreibbar
machen, aber dann werden nur die komischsten Fantasiegeschoepfe kreiert ;-) ).

Also generell eine klasse Idee, die ich vor etlichen Jahren auch schonmal
mental durchgekaut habe. Allerdings wegen zu vieler inkompatibler
lib-charakteristika wieder verworfen.

Faende es spannend, wenn sich so eine Moeglichkeit tatsaechlich mal eroeffnen
wuerde.

Gynite@FF

[Gnomi@Uni]

Dies laesst sich innerhalb des beschriebenen Frameworks alles machen, man
muss sich eben nur auf einen gewissen Standard einigen. Beim Betreten des
Portals sendet das Ursprungs-MUD einige Merkmale des Original-Chars an
das Gast-MUD (derzeit Name, Geschlecht und eben als Besonderheit fuer
unser TestMUD den Level), dies laesst sich erweitern (ist ein Mapping,
kann man alles moegliche eintragen), und das Gast-MUD kann entscheiden,
was es davon honoriert.

In der Umkehrung treten dann natuerlich eigene Merkmale des Gast-MUDs
zurueck. Bei uns darf man seine eigene Beschreibung als zusaetzliche
Raetselbelohnung erweitern oder den Titel als Gildenfaehigkeit aendern.
Da gilt es eine gute Balance zu finden zwischen der Vorgabe aus dem
Ursprungs-MUD und den Moeglichkeiten im Gast-MUD. So kann ich mir
durchaus vorstellen, dass MUDs gegenseitig ihre Erfahrungen (zu einem
gewissen Anteil) anerkennen. Aber das sind Feinheiten, die ich nicht
von vornherein festlegen wollte.

Nichtsdestotrotz seh ich das nicht als Hindernis an. Auch ohne dies
bieten die Portale einen grossen Mehrwert. Auch wenn es theoretisch
einfach ist, sich mal eben weitere Charaktere in anderen Welten
zuzulegen, so machen dies doch nur eine Minderheit. Und noch weniger
bleiben auch mit allen diesen Charakteren aktiv. Ich hoffe, dass die
Portale da eine groessere Breitenwirkung entfalten und damit unseren
Spielern die tollen Welten anderer MUDs und anderen MUDs das schoene
Magyra nahebringen.

Gruss
Gnomi

[Andreas Schwarz]

On Thu, 13 Dec 2012 16:36:50 +0100, "Gnomi@Uni" wrote:

> Dies laesst sich innerhalb des beschriebenen Frameworks alles machen, man
> muss sich eben nur auf einen gewissen Standard einigen. Beim Betreten des
> Portals sendet das Ursprungs-MUD einige Merkmale des Original-Chars an
> das Gast-MUD (derzeit Name, Geschlecht und eben als Besonderheit fuer
> unser TestMUD den Level), dies laesst sich erweitern (ist ein Mapping,
> kann man alles moegliche eintragen), und das Gast-MUD kann entscheiden,
> was es davon honoriert.

Wie macht ihr das mit dem Namen, der ist doch nicht uniq und es gibt zig
Ueberschneidungen? Ganze allgemein kann da ohne einen vereinheitlichten
Standard (was Wertung und Wichtung angeht) nicht mehr als ein "proxy"
rauskommen.



--

PGP: 0x661AB571

[Gnomi@Uni]

Andreas Schwarz schrieb:

> Wie macht ihr das mit dem Namen, der ist doch nicht uniq und es gibt zig
> Ueberschneidungen?

Also in unserer Mudlib gibt es den Namen eines Spielers und den echten
Namen eines Spielers. Letzteres wird verwendet, damit Programme den
Spieler eindeutig identifizieren koennen. Und als echten Namen setze
ich eben z.B. "Gnomi@UNItopia", damit bleibt das eindeutig und es gibt
keine Ueberschneidungen auf der technischen Seite

Anders sieht es fuer Spieler aus. Hier koennen durchaus zwei Gnomis
dann herumlaufen. Genauso wie ein Spieler auch mal einem NPC ueber den
Weg laufen kann, der zufaellig genauso heisst. Ich denke, dies ist eine
Frage der Gewoehnung. Wie ich bereits schrieb, hatte ich vorher ja auch
'Gnomi@UNItopia' als normalen Namen gesetzt, dies aber aus aesthetischen
Gesichtspunkten verworfen. Andere MUDs koennen dies aber so umsetzen oder
irgendeine andere Art der Kennzeichnungen waehlen, ich schreib es derzeit
in den Titel.

> Ganze allgemein kann da ohne einen vereinheitlichten Standard (was Wertung
> und Wichtung angeht) nicht mehr als ein "proxy" rauskommen.

Welche Wertung und Wichtung meinst Du?

Aber unabhaengig davon, ich faende "nur einen Proxy" eine gewaltige
Errungenschaft fuer uns. Und das moechte ich erstmal erreichen und dann
beobachten, wie es funktioniert, und _anschliessend_ wuerde ich dann gemeinsam
mit den teilnehmenden MUDs ueberlegen, ob und wie man das ergaenzen und
nahtloser gestalten sollte.

Gruss
Gnomi

[David Seppi]

Alloy@FF schrieb:

> Fremdwandler muessten ganz normal Schaden nehmen
> koennen, damit sie nicht benutzt werden, betont gefaehrlich gestaltete
> Gegenden risikolos zu erkunden.

Willst Du, dasz der Fremdchar innerhalb der Gastwelt Schaden erleidet,
damit er nicht muehelos am Ziel ankommt? Oder soll er das Risiko haben,
in seiner eigenen Welt zu sterben, damit er was aufs Spiel setzen musz?

--
David Seppi
1220 Wien

[Theokrates@Uni]

Ihr bringt dem "Tourismus" noch den Todesstoss! Man kann ja inzwischen nicht
mal als Geist mehr ueberall einfach mal gucken gehen und das Werk der
arbeitenden Goetter mal in aller Ruhe bewundern.

[Alloy@FF]

Tut mir Leid, dass du als Geist soviele Muehen hast, Theokrates ;)

Zu dem vorigen Posting: Ich tendiere dazu, dass ein Gastwandler nur ein
kraftloser Besucher sein sollte. Wenn er richtig spielen will, kann er sich ja
normal anmelden. Es ist ja nicht so, dass wir da jemanden dran hindern wuerden
:) Mir gefaellt aber die Idee, ohne grosse Muehe eine ganz andere Welt zu
besuchen, ein bisschen Sightseeing zu machen und vielleicht mit Bekannten ein
Schwaetzchen zu halten.
Was letzten Endes alles gemacht werden *kann*, was welchem MUD sinnvoll
erscheint, das muessen wir gelegentlich erstmal erforschen, und dazu haben wir
vorerst die Ressourcen nicht.
LLAP, Alloy

[Havelock@FF]

Alloy@FF schrieb:

> :) Mir gefaellt aber die Idee, ohne grosse Muehe eine ganz andere Welt
> :zu besuchen, ein bisschen Sightseeing zu machen und vielleicht mit
> Bekannten ein Schwaetzchen zu halten.

Mir auch. Ein paar andere Welten auskundschaften ohne sich anmelden zu
muessen und dabei seine vertraute Bedienumgebung zu haben hat schon was.
Wuerde mich sehr freuen wenn ihr das einmal angehen solltet. :-)

[Squall@FF]

Fremdwandler duerften zumindest bei uns im FF nicht gefahrlos herumlaufen,
sonst koennte man (wie Alloy bereits sagte) dieses Feature ausnutzen, um
Gegenden auszuforschen, in die man sich mit seinem echten Charakter nicht
traut. Insofern muessten Fremdwandler auch Schaden nehmen und sterben koennen.

Gruesse,

Squall

[David Seppi]

Squall@FF schrieb:

> sonst koennte man (wie Alloy bereits sagte) dieses
> Feature ausnutzen, um Gegenden auszuforschen, in die man sich mit
> seinem echten Charakter nicht traut.

Wie schaut das mit Zweities aus? Wenn das verboten wäre, dann dürfte man
ja mit Zweities de facto gar nichts mehr machen — oder nur Orte
betreten, die der andere Charakter nie betreten wird.

[Squall@FF]

Zweities koennen Schaden nehmen und forschen dementsprechend nicht gefahrlos,
sondern nur so weit, wie die Staerke des Charakters es nunmal zulaesst. Stirbt
der Char, ist halt an der Stelle erstmal Schluss.

Squall

[David Seppi]

Squall@FF schrieb:

> Stirbt der Char, ist halt an der Stelle erstmal
> Schluss.

Das schon, man muß seinen Erstie aber nicht in Gefahr bringen und
riskiert somit nichts. Es geht also doch mehr um "Spieler sollen nur so
weit gehen können wie es ihren Kräften entspricht" und nicht um "Spieler
sollen nur dort hin können, wenn sie bereit sind ihren Avatar aufs Spiel
zu setzen".

[Patrick Borer]

David Seppi <dse...@a1.net> schrieb:

Wollte ich auch gerade schreiben. Also, in FF ist Interaktion mit
Zweities ja verboten. Dass Spieler mit einem Zweitie Gegenden, die
ihnen verdaechtig vorkommen, ausforschen, ist hingegen meines Wissens
nicht ausdruecklich verboten und wird auf jeden Fall gemacht.
Allerdings sind Zweities ja haeufig nur kleine, schwache Chars, d.h.
ein starker "Fremdwandler", der gefahrlos herumlaufen kann, koennte
unter Umstaenden die attraktivere Wahl darstellen.

Patrick Borer

[Squall@FF]

Genau darum geht es.

Squall

[David Seppi]

Patrick Borer schrieb:

> Allerdings sind Zweities ja haeufig nur kleine, schwache Chars, d.h.
> ein starker "Fremdwandler", der gefahrlos herumlaufen kann, koennte
> unter Umstaenden die attraktivere Wahl darstellen.

Das stimmt natürlich. Löst man am besten dadurch, daß der Gast
Level 1 hat.

[Patrick Borer]

David Seppi <dse...@gmx.at> schrieb:

... und damit waeren wir wieder bei Alloys Beitrag, "Ich tendiere
dazu, dass ein Gastwandler nur ein kraftloser Besucher sein sollte" -
genau.

Patrick Borer

[David Seppi]

Patrick Borer schrieb:

> ... und damit waeren wir wieder bei Alloys Beitrag, "Ich tendiere
> dazu, dass ein Gastwandler nur ein kraftloser Besucher sein sollte" -
> genau.

Stimmt. ;)

[Theokrates@Uni]

Was uns zu "Fremdwandler koennten eigentlich auch als Geister oder Phantome
auftreten" bringt.

[David Seppi]

Theokrates@Uni schrieb:

> Was uns zu "Fremdwandler koennten eigentlich auch als Geister oder
> Phantome auftreten" bringt.

Dann können sie allerdings wieder überall hin.
Oder die Phantome sind durch die groß Entfernung zur Mutterwelt so
geschwächt, daß sie *deswegen* Level 1 haben. Das fände ich eine nette
Erklärung und kennzeichnet die Gäste ausreichend als Entitäten, die
nicht zu dieser Welt gehören.

[Skeeter@Uni]

Es gibt in Unitopia auch Stellen wo man als Geist nicht vorbei kommt,
z. B. bei einigen Waechtern in der Unterwelt.

[David Seppi]

Das wäre natürlich auch eine Idee:
Geister können sich nur in allgemein zugänglichen,
ungefährlichen Gebiete bewegen.

[Ignatios Souvatzis]

Gnomi@Uni wrote:

> wie ich letztens schon auf dem D-Code erzaehlte, habe ich mich in letzter
> Zeit damit beschaeftigt, InterMUD-Portale zu bauen, mit denen es moeglich

> ist, von einem MUD in das naechste zu wandern. (...)

Kennst du Stross' "Halting State"?

-is

[Robert Doerfler]

Hm, hm ... den Nicknamen kenn ich doch aus #netbsd! Wie kommts eigentlich
das soviele BSD Nutzer irgendwie mit MUDs zu tun haben. Liegts am Betriebs-
system? :-D

[David Seppi]

Ignatios Souvatzis schrieb:

> Kennst du Stross' "Halting State"?

Danke für den Tip, das gibts sogar in der lokalen Bücherei!
*auf die Leseliste setz*