Einfuehrung, oder: Dieses Handbuch, und wie es zu lesen ist.

Dieses Handbuch war der Versuch von Descartes, ein LPC-Handbuch zu schreiben,
da es zwar viele gute Hilfsseiten zu den einzelnen Punkten gab, jedoch kein
Programmierhandbuch. Da die Zielgruppe eines LPC-Manual jedoch
Freizeitprogrammierer sind, die keine anderen Programmiersprachen kennen,
muss dieses auch immer beachtet werden. (Wenn ich das uebersehe, schlagt mich
einfach)

LPC ist eine sehr einfache Programmiersprache zum Lernen und ist eine wirkliche
Bereicherung fuer das wahre Leben. (Die Lebensgeschichte von Descartes lass
ich mal aussen vor, in welcher er eben erwaehntes intensiv begruendet)

Als Voraussetzung zum Verstaendnis dieses Manuals (ich werde haeufiger bei dem
englischen Begriff bleiben, da der kuerzer und praegnanter ist) ist, dass Du
die grundlegenden UNIX-Kommandos wie ls, cd, mkdir, mv, rm etc beherrschst.
Ausserdem solltest Du wissen, wie man ein File im MUD bearbeitet (ob ueber FTP
von aussen oder direkt mit dem ed ist Dein Bier). Alle anderen Grundlagen wird
dieses Manual vermitteln.

Solltest Du bereits Erfahrungen in C oder C++ haben, ist das zwar nicht
schlecht, jedoch kannst Du hin und wieder ein Problem damit haben, da LPC zwar
aussieht wie C, jedoch kein C ist. Die Erfahrungen in modularer Programmierung
werden eventuell hinderlich sein und muessen ueberwunden werden.
Solltest Du noch nie ueber C gestolpert sein, wirst Du anfangs Probleme haben,
wieso bestimmte Dinge, wie logische Operatoren oder Programmablaeufe, zu
verstehen, bzw wieso sie so funktionieren, wie sie funktionieren.
Ein C-Guru hat keinerlei Vorteile, da das, was er ueber C weiss, und dieses
Wissen macht ihn ja zum Guru, bei LPC nicht hat.

Die Kapitel dieses Handbuches sollten nacheinander durchgearbeitet werden.
Zuerst sollte man diese Einfuehrung (was Du ja gerade tust) lesen, und dann
durch die einzelnen Kapitel gehen.
Zuerst wird in einem oder zwei Absaetzen erklaert, was man an diesem Punkt
bereits wissen sollte. Danach wird das Thema des Kapitels bis ins Detail
(oder besser, soweit, wie es fuer das Verstaendnis noetig ist) diskutiert.
Am Ende kommt eine kurze Zusammenfassung, was aus diesem Kapitel an
Wissenswertem mitgenommen worden sein sollte. Danach koennen Hinweise und
Ideen kommen, die interessant sind und sich auf das Thema beziehen, jedoch
nicht fuer das Verstaendnis dieses Kapitels notwendig sind.

Falls irgendetwas unklar sein sollte, so sei so frei und schreib eine Email.
Wahrscheinlich habe ich dort etwas missverstaendlich erklaert.
Nur Feedback kann helfen, diese Punkte auszubessern und zu ueberarbeiten.
Falls das MUD im Intermud-System verbunden sein sollte, reicht eine Mail
an gralkor@tamedhon, ansonsten gralkor@fantasywelt.net

Kommen wir zu einigen grundlegenden Begriffen:
driver
Das C-Programm, welches die Grundlage fuer das eigentliche Spiel darstellt.
Der Driver akzeptiert Socketanfragen von anderen Rechnern, interpretiert den
LPC-Code, verwaltet die Objekte im Speicher etc.
Der Driver muss gestartet sein, damit das MUD laufen kann.
Als Socketanfragen werden Verbindungsanfragen von fremden Rechnern bezeichnet.
Diese dienen dazu, dass Nutzer sich mit dem MUD verbinden koennen.
Kurz gesagt: Der driver ist die Umgebung, in der das Spiel
läuft. Es verwaltet alle Dateien und regelt die Kommunikation zwischen
den Spielern und dem Rechner.

mudlib
LPC-Code, der die eigentliche Welt definiert.
Der Driver als Solcher ist der LPC-Compiler, waehrend die Mudlib die
Library darstellt (eine sehr weit hergeholte, aber irgendwo passende
Analogie). Die Mudlib definiert Basis-Objekte, die von den MUD-Programmierern
genutzt werden, um die MUD-Welt zu erstellen.
Die einzelnen Verzeichnisse, die relevant sind:
/std 	 - Hier liegen die Standardobjekte, die durch Vererbungsbaeume in die
	   MUD-Welt einfliessen.
/sys 	 - Hier liegen die Definitionsdateien fuer die /std-Objekte.
/obj 	 - Hier liegen in der Welt sofort nutzbare Objekte wie Tools oae.
/p   	 - Hier liegen MUDspezifische Objekte.
       	   Beispielsweise liegen im Tamedhon hier die Waffen-/und Ruestungslib.
/players - Das sind die Arbeitsverzeichnisse der Programmierer
/doc     - Hier liegen die Dokumentationen und Manpages
/log	 - Hier liegen Logfiles des Drivers und der Mudlib
/secure  - Hier werden sicherheitsrelevante Dateien abgelegt
           Dazu gehoeren Spielerfiles und so weiter

Andere Verzeichnisse wie /etc enthalten driverspezifische Dateien, die bei
der Installation und Veroeffentlichung des MUDs relevant sind.

region, subregion, spielgebiet
Speziell fuer das MUD entwickelte Objekte und Raeume, die die betretbare
Spielwelt darstellen.
Durch Vererbung bekommen diese Raeume und Objekte Faehigkeiten aus
MUDLIB-Objekten.
Diese Objekte werden direkt von Spielern benutzt.

objekt
Jedes Stueck Code mit der Endung .c ist ein Objekt.
Jeder Raum, jede Waffe, jedes Monster, die Spieler etc sind Objekte.
Es gibt Objekte der Mudlib, die durch Vererbung in Objekte eingehen, und
es gibt geclonede Objekte, deren Code mehrfach im Speicher steht.
Soweit zur Theorie:
Es gibt noch Blueprint-Objekte, also Objekte die nur einmal vorkommen.
Die Blueprint ist quasi die Vorlage. (die Blaupause, oder Durchschlag
um das deutsche Wort zu benutzen)
Bei Raeumen macht das Sinn, da es einen Raum nur einmal geben darf.
NPC oder Waffen kann es mehrfach geben, jedoch sollten sie nicht mehrfach
im Speicher sein.
Das wird durch einen kleinen Kniff erreicht:
In der Create-Funktion (kleiner Vorgriff auf Kapitel 4) wird einfach geprueft,
ob dieses Objekt im Speicher vorhanden ist. Falls ja, wird es nicht erneut
compiliert sondern eine Kopie dem aufrufenden Objekt virtuell erstellt.
(referenziert)
Vererbung ist (wie in der Biologie) das Eingehen von Eigenschaften in neue
Objekte.
Somit wird dem Programmierer die Programmierung erleichtert.
Es wurde zB. ein Standard-Raum geschrieben, der alle relevanten Sachen enthaelt,
so dass sich der Programmierer nur noch hinsetzen muss, um den Raum schoen
auszuschmuecken. Wie der Spieler mitbekommt, dass in dem Raum eine
Temperatur von 25 Grad herrscht, wird im Standardraum geklaert.
Der Programmierer muss in dem Raum, den er schreibt, nur noch festlegen,
dass in diesem Raum 25 Grad herrschen.

compiler, compilieren, interpreter, interpretieren
Da der Rechner eine voellig andere Sprache spricht als die Menschen, und
es fuer beide Seiten schwer ist, die andere Sprache zu lernen, wurden
Interpreter und Compiler entwickelt, die spezielle Sprachen, die der
menschlichen Sprache sehr aehnlich sind, uebersetzen.
Der driver ist eine Mischung aus einem Compiler und Interpreter, da er
bei Bedarf zwar die benoetigten Programme in Maschinencode umwandelt, jedoch
den Maschinencode (also das entsprechende Programm in der Sprache, die der
Rechner versteht) nicht abspeichert sondern nur im Speicher behaelt.
Das spart auf Dauer Speicher und ist auch aus Sicht der Prozessoren
nicht der falsche Weg.
Ein Interpreter liest Programmcode ein und uebersetzt ihn bei Bedarf und
fuehrt ihn automatisch aus. Nach der Ausfuehrung wird der Maschinencode,
der dadurch erzeugt wurde, automatisch wieder aus dem Speicher entfernt.