MIDGARD · Multi User Dungeon Alpha 0.1

Kapitel 9: Objektkommunikation – Funktionen aufrufen, Nachrichten senden

In diesem Kapitel lernst du, wie Objekte im LPC miteinander sprechen. Bisher weißt du, was Objekte sind und wie sie aufgebaut sind – jetzt geht es darum, wie sie Informationen austauschen, Aktionen auslösen und gemeinsam Spielmechaniken bilden. Ohne Objektkommunikation gäbe es keine Kämpfe, keine Quests, keine Magie und keine Interaktion.

Weiter zu Kapitel 10

Hooks, Events und fortgeschrittene Interaktionsmuster

9.1 Warum Objektkommunikation so wichtig ist

In einem MUD passiert nichts isoliert. Wenn ein Spieler einen Befehl eingibt, reagieren mehrere Objekte gleichzeitig:

  • Das Spielerobjekt interpretiert den Befehl
  • Der Raum prüft, ob Aktionen erlaubt sind
  • Ein Gegenstand reagiert (z.B. „öffnen“, „nehmen“)
  • Andere Spieler im Raum bekommen Nachrichten

All das geschieht durch Funktionsaufrufe zwischen Objekten. Objekt A ruft eine Funktion in Objekt B auf – manchmal direkt, manchmal indirekt über die Mudlib.

Wichtiges Mindset: Objekte senden keine „Signale“, sie rufen Funktionen auf. Alles andere – Textausgaben, Effekte, Statusänderungen – sind nur Folgen davon.

9.2 Funktionsaufrufe – das Grundprinzip

Eine Funktion in LPC ist immer Teil eines Objekts. Um sie aufzurufen, brauchst du also:

  • ein Zielobjekt
  • den Namen der Funktion
  • optionale Argumente

object ob = this_player();
ob->QueryProp(P_LEVEL);
      

Hier ruft das aktuelle Objekt die Funktion QueryProp() im Spielerobjekt auf. Der Rückgabewert ist das Ergebnis der Funktion – in diesem Fall z.B. ein Integer.

Merksatz: objekt->funktion() ist die Standardsprache der Mudlib.

9.3 Rückgabewerte – Antworten von Objekten verstehen

Fast jede Funktion gibt einen Wert zurück. Dieser Rückgabewert ist extrem wichtig, weil er dir sagt, ob etwas funktioniert hat oder welche Information geliefert wurde.


int lvl = this_player()->QueryProp(P_LEVEL);
if (lvl < 10) {
  write("Du bist noch zu unerfahren.\n");
}
      

Häufige Rückgabetypen:

  • int – Erfolg/Misserfolg, Zähler, Status
  • string – Texte, Beschreibungen
  • object – Referenz auf ein anderes Objekt
  • 0 – „nichts“, „fehlgeschlagen“, „nicht vorhanden“

Anfängerfehler: Rückgabewerte ignorieren. Viele Bugs entstehen, weil man einfach davon ausgeht, dass etwas funktioniert hat.

9.4 call_other() – der klassische Funktionsaufruf

Intern läuft fast jeder Funktionsaufruf über call_other(). Die Kurzschreibweise obj->funktion() ist nur syntaktischer Zucker.


call_other(this_player(), "QueryProp", P_HP);
      

Das ist funktional identisch zu:


this_player()->QueryProp(P_HP);
      

Du wirst call_other() selten selbst schreiben, aber du solltest wissen, dass es existiert – vor allem beim Debuggen oder beim Lesen alter Codes.

9.5 Nachrichten an Spieler – write(), tell_object()

Kommunikation heißt nicht nur „Code spricht mit Code“, sondern auch „Spiel informiert Spieler“. Dafür gibt es spezielle Funktionen.


write("Du fühlst dich beobachtet.\n");
      

write() sendet Text an den aktuellen Spieler (this_player()).


tell_object(pl, "Ein kalter Schauer läuft dir über den Rücken.\n");
      

tell_object() ist expliziter: Du bestimmst, welches Objekt die Nachricht erhält.

Anfänger-Tipp: Verwende tell_object(), wenn du sicher sein willst, wer die Nachricht bekommt – besonders in komplexeren Abläufen.

9.6 say(), tell_room() – Kommunikation im Raum

Oft sollen mehrere Spieler gleichzeitig informiert werden. Dafür gibt es Raum-Nachrichten.


say("Ein Windhauch weht durch den Raum.\n");
      

say() informiert alle im Raum – außer dem aktuellen Spieler.


tell_room(environment(this_player()),
  "Die Fackeln flackern unruhig.\n");
      

tell_room() ist noch kontrollierter und funktioniert auch, wenn kein aktiver Spieler beteiligt ist.

Merksatz: write = ich, say = alle anderen, tell_room = ganzer Raum.

9.7 Aktionen auslösen – andere Objekte „bitten“

Kommunikation heißt oft: „Tu etwas für mich.“ Ein Objekt bittet ein anderes, eine Aktion auszuführen.


object door = present("tuer", environment(this_player()));
if (door)
  door->open_door();
      

Hier ruft dein Objekt gezielt eine Funktion im Tür-Objekt auf. Ob die Tür das erlaubt, entscheidet die Tür selbst.

Guter Stil: Das Zielobjekt entscheidet immer selbst. Du solltest niemals einfach Variablen fremder Objekte manipulieren.

9.8 Sicherheitsaspekte – nicht jedes Objekt darf alles

In großen MUDs ist Sicherheit extrem wichtig. Nicht jedes Objekt darf jede Funktion aufrufen.

Deshalb prüfen viele Funktionen:

  • Wer ruft mich auf? (previous_object())
  • Ist der Spieler berechtigt?
  • Ist der Aufruf logisch sinnvoll?

Als Anfänger musst du das nicht sofort implementieren, aber du solltest wissen: Viele Funktionen können stillschweigend 0 zurückgeben, wenn der Aufruf nicht erlaubt ist.

9.9 Typisches Beispiel: Interaktion zwischen Spieler, Objekt und Raum


int cmd_ziehen(string str) {
  if (!id(str))
    return 0;

  write("Du ziehst am Hebel.\n");
  say(this_player()->Name(WER) + " zieht an einem Hebel.\n");

  environment(this_player())->on_lever_pulled();
  return 1;
}
      

Was passiert hier?

  • Spieler ruft Befehl aus
  • Objekt reagiert
  • Raum wird informiert
  • Raum entscheidet, was weiter passiert

Dieses Muster ist extrem häufig: Objekte lösen Ereignisse im Raum aus, der Raum reagiert mit Veränderungen.

9.10 Häufige Anfängerfehler

  • Rückgabewerte ignorieren
  • Direkt Variablen fremder Objekte ändern
  • this_player() blind verwenden
  • Nachrichten an falsche Empfänger senden
  • Logik in falsche Objekte packen

Wenn etwas „komisch“ wirkt, liegt es fast immer an falscher Kommunikation zwischen Objekten.

9.11 Zusammenfassung

Du hast gelernt:

  • Wie Objekte Funktionen in anderen Objekten aufrufen
  • Warum Rückgabewerte entscheidend sind
  • Wie Nachrichten an Spieler und Räume funktionieren
  • Warum klare Zuständigkeiten wichtig sind

Objektkommunikation ist die Sprache des MUDs. Wenn du sie beherrschst, kannst du komplexe Spielmechaniken sauber und verständlich umsetzen.

Ausblick

Im nächsten Kapitel gehen wir noch einen Schritt weiter: Hooks, Events und systematische Reaktionen auf Ereignisse. Damit kannst du dein Objektverhalten elegant erweitern, ohne alles neu zu schreiben.

Weiter zu Kapitel 10

Hooks, Events und saubere Erweiterungen