doc/wiz/regionsleitfaden

Hallo, willkommen in den unendlichen Weiten der Regionsverzeichnisse!

Du moechtest in einer Region mitprogrammieren? Prima, neue kreative 
Mitarbeiter sind jederzeit willkommen! Du bist herzlich eingeladen, mit 
Deinen Ideen zur Entwicklung beizutragen.

Um die Programmierung und anschliessende Abnahme fuer alle Beteiligten
moeglichst reibungslos zu gestalten, seien Dir die in dieser Hilfeseite
genannten Dinge ans Herz gelegt. Diese lassen sich in folgende Kategorien
einteilen:

1) Formales zum Codestil
2) Inhaltliche Anforderungen
3) Was nicht akzeptiert wird
4) Was ist vor dem Anschluss zu beachten?


1) Formales zum Codestil

o  #pragma strong_types,save_types soll in allen Files verwendet werden,
   ab Driver-Version LD_3.5.x wird auch rrtt_checks dringend empfohlen.

o  Der Code soll keine Zeilen mit mehr als 78 Zeichen enthalten.

o  Der Code soll sauber eingerueckt und sorgfaeltig formatiert sein, aber
   bitte ohne Tabulatoren.

o  Verwende keine Lambda-Closures! Was auch immer Du vorhast: Es geht
   ohne. Es sei ausdruecklich auf die Moeglichkeit von inline-Closures
   verwiesen, wenn Du unbedingt vermeiden willst, eine separate Funktion
   zu schreiben.

o  Kommentiere Deinen Code! Insbesondere dort, wo komplexere Objekt-
   Interaktionen stattfinden, oder wo implizit besondere Eigenschaften
   (z.B. der Mudlib, oder mathematische "Features") genutzt werden, die im
   Code nicht auf den ersten Blick ersichtlich oder durchschaubar sind.
   Daumenregel: "Wenn Du laenger als eine Minute ueber eine Zeile nachdenken
   musstest, kommentiere sie." ;-) Rechne immer damit, dass jemand, der
   Deinen Code liest, keine Ahnung hat, was Du da eigentlich tust. :-)

o  Wirf bitte nach Abschluss der Arbeiten Platzhalter-Code raus (z.B. leere
   AddDetail()-Anweisungen) und entferne nicht fuer das Gebiet benoetigte
   Dateien aus den Verzeichnissen.

o  Speicherung von Daten in secure-Verzeichnissen soll bitte nur sehr
   sparsam erfolgen und nur in Abstimmung mit dem RM.

o  save_object() bitte sehr sparsam verwenden (nicht bei jeder Daten-
   aenderung, bei Bedarf in reset/remove).

o  Wenn Defines zum Einsatz kommen, verwende sie bitte moeglichst sparsam
   und sorge dafuer, dass Defines klar als solche erkennbar sind. Ausser in
   Faellen, wo es gar nicht anders geht, solltest Du keine Code-Defines
   verwenden, die mehr umfassen als einfache Funktionsaufrufe wie z.B.
      #define TP this_player()
   Fuer uebliche Standardfaelle existiert bereits eine Headerdatei in der 
   Mudlib unter /sys/defines.h. 

o  Solltest Du bestimmte Ereignisse in Deinem Gebiet loggen wollen (z.B.
   (Mini-)Questabschluesse oder besondere Kills), dann benutze bitte 
   log_file(), so dass die Logfiles nach /log/ geschrieben werden. Zusaetzlich
   werden so erstellte Logfiles automatisch bei Erreichen einer bestimmten
   Dateigroesse rotiert, so dass sich der Platzverbrauch in Grenzen haelt.
   Das Protokollieren mittels write_file() in Regionsverzeichnissen unter 
   /d/ ist grundsaetzlich NICHT erwuenscht. 
   Nach Absprache KANN es fuer SELTENE und WICHTIGE Meldungen erlaubt werden,
   mittels write_file(() nach /log/ zu schreiben.

o  Wenn Du in Deinem Gebiet Daten oder Code ablegst, der nicht fuer 
   jedermanns Augen bestimmt ist (Questloesungen, Gebietskarten, Savefiles
   von questrelevanten (Master-)Objekten), solltest Du in Abstimmung mit
   Deinem Regionsmagier ueberlegen, diese in ein ./secure/-Verzeichnis
   zu verschieben, damit sichergestellt ist, dass auch tatsaechlich nur
   berechtigte Magier darauf Zugriff erhalten. Denn bedenke, dass Lese-
   und Schreibrechte nur fuer Codedateien geprueft werden, jedoch nicht
   fuer beliebige sonstige Textdateien.

o  Es sei ausdruecklich auf die Manpages "goodstyle", "effizienz", etc.
   verwiesen.


Das soll jetzt nicht heissen, dass der Anschluss von Code kategorisch
abgelehnt werden wird, der diese Formalien nicht erfuellt. (Ausnahme: Lambda-
Closures werden in den Regionen nicht mehr akzeptiert.) Ich moechte aber
wirklich nachdruecklich darum bitten, sie aus einem einfachen Grund
einzubauen: Du wirst nicht immer der einzige sein, der Deinen Code lesen und
warten muss, auch in Deiner Abwesenheit koennen Bugs auftreten. Und dann ist
es wesentlich einfacher, einen Minimalstandard zu haben, der es allen
ermoeglicht, den Code auch im MG zu lesen und dort zu fixen. Denn nicht immer
wird es moeglich sein, sich Dateien herunterzuladen und lokal zu bearbeiten.

Zum Bugfixing an dieser Stelle aus aktuellem Anlass eine Anmerkung: Es wird
von jedem aktiven Regionsmitarbeiter erwartet, dass er einen Fehlerteufel
(/obj/tools/fehlerteufel) besitzt und dessen Fehlerliste regelmaessig
durchsieht und aufgetretene Fehler und Warnungen behebt. (Okt. 2007)


2) Inhaltliche Anforderungen:

o  Wenn Du ein komplett neues Gebiet schreiben moechtest, das in einer Region 
   seinen Platz finden soll, sprich bitte die thematische Ausrichtung mit
   dem RM ab, bevor Du anfaengst, Code zu schreiben. Falls von Deinen Ideen
   irgendetwas nicht hierher passen sollte, laesst sich das mit wesentlich
   weniger Frust im Vorfeld klaeren, als wenn hinterher das halbe Gebiet
   umgebaut werden muesste. Sollte sich die konzeptionelle Ausrichtung 
   oder der Umfang waehrend der Programmierung grundlegend aendern, besprich
   dies bitte kurz mit dem RM.

o  Ob neue oder alte Rechtschreibung, ist im wesentlichen Dir selbst ueber-
   lassen, jedoch waere es schoen, wenn Du die Spieler-Anreden wie "frueher"
   ueblich gross schreiben wuerdest ("Du", "Dich", "Dein").

o  Es muessen in jedem Raum gewisse Standarddetails vorhanden sein, z.B.
   Boden, Decke, Waende, Himmel (Sonne, Wolken), etc. Dies kann man sehr
   bequem mit dem "Otester" pruefen.
   Es sei aber ausdruecklich darauf hingewiesen, dass der Otester keinesfalls
   benutzt werden sollte, um saemtliche vorhandenen Substantive bis ins
   kleinste zu beschreiben. Es ist schoen, wenn Objekte moeglichst voll-
   staendig beschrieben werden, aber man sollte es auch nicht uebertreiben.

o  Was bitte nur in Ausnahmefaellen gemacht werden sollte, ist, Details, 
   Infos oder Lang-/Kurzbeschreibungen aus Standardraeumen zu inheriten.

o  Falls Du Beschreibungen/Ausgaben in ASCII-Grafik einbinden moechtest, achte
   bitte darauf, dass Du auf jeden Fall einen kurzen Alternativtext mit-
   lieferst und diesen ausgibst, wenn der Spieler P_NO_ASCII_ART gesetzt hat.
   Es besteht immer die Moeglichkeit, dass Spieler mit Sehschwaeche oder
   Blinde Deine Objekte anschauen, und diese kommen mit Objekten in reiner
   ASCII-Grafik nicht zurecht.
   (Siehe auch die Manpage zu P_NO_ASCII_ART und "hilfe grafik".)

o  Eine Anmerkung zu den Schadensarten DT_HOLY und DT_UNHOLY soll nicht
   unerwaehnt bleiben: Es wird von vielen Spielern und Magiern als logisch
   und atmosphaerisch nicht begruendbar empfunden, wenn Gegenstaende oder
   NPCs diese beiden Schadensarten gleichermassen einsetzen bzw. verursachen
   koennen. Vergleichbares gilt fuer die gleichzeitige Abwehr beider 
   Schadensarten. Wenngleich bisher diesbezueglich keine klare Einigung
   erzielt werden konnte, soll an dieser Stelle dennoch empfohlen werden,
   von einer gleichzeitigen Nutzung von DT_HOLY und DT_UNHOLY abzusehen.
   Der zustaendige Regionsmagier muss aber auf jeden Fall in Kenntnis
   gesetzt werden und entsprechende Objekte zur Pruefung vorgelegt bekommen,
   falls diese Nutzung dennoch fuer unumgaenglich gehalten wird.


3) Was keinesfalls akzeptiert wird

o  Files, die in /players liegen, incl. Headerfiles. Dies erschwert das
   Reparieren von Bugs ungemein und bringt eine gewisse Unuebersichtlichkeit
   mit sich. Bitte auch nichts aus /players inheriten (Ausnahmen hiervon sind 
   aufgrund eines neuen Driver-Features nur noch mit Hilfe eines Erzmagiers 
   moeglich. Kurz gesagt: es gibt eine Whitelist von Objekten, die das 
   duerfen. Alle anderen duerfen das per Default nicht.).


4) Was ist vor dem Anschluss zu beachten?

o  Code muss vollstaendig fertig sein. Das heisst insbesondere, dass 
   Debug- und nicht mehr benoetigter Code entfernt wurde und dass alle 
   erforderlichen Kommentare vorhanden sind.

o  Abnahme durch den RM und ggf. den fuer Gesellenstuecke zustaendigen EM
   muss erledigt sein. Regionsmagier sind angehalten, eigene Gebiete, die zum
   Anschluss in der eigenen Region geplant sind, von anderen Magiern abnehmen
   lassen.

o  Der Magier ist angehalten, das Gebiet durch Testspieler testen zu lassen
   (siehe hierzu die Testspieler-Regeln). Ob ein Spieltest als Voraussetzung
   fuer die Abnahme gefordert wird, entscheidet der zustaendige RM. Er kann
   den Test auch selbst durchfuehren oder ganz darauf verzichten.

o  Quests und Miniquests muessen vom zustaendigen Quest-EM getestet,
   eingetragen und aktiviert worden sein.

o  Feedback der Testspieler und testenden Magier sollte umgesetzt sein.

o  Forscherpunkte muessen vom zustaendigen EM eingetragen worden sein.

o  Balance-Genehmigungen (Objekte, Heilung, ggf. Gildenbalance) muessen 
   vorliegen; die genehmigten Eckparameter sollen nachvollziehbar im 
   Gebietsverzeichnis dokumentiert sein: entweder im jeweiligen File, oder
   als Textfile z.B. in einem Doku-Verzeichnis.

o  Kraeuter fuer den Kraeuterskill muessen genehmigt und eingetragen worden 
   sein (dies kann jeder EM mit dem Kraeutertool erledigen).

o  Hinweis: Erstkills muessen NICHT ZWINGEND vom zustaendigen EM eingetragen
   worden sein. Die Erstkill-NPCs werden automatisch in einer vorlaeufigen
   Liste gesammelt und vom EM entweder freigegeben oder abgelehnt. Auch
   Sonder-Stufenpunkte fuer EKs muessen nicht vor dem Anschluss beantragt
   oder genehmigt worden sein, auch diese Eintragung laesst sich erledigen,
   wenn der betreffende NPC das erste Mal getoetet wurde.

o  Auch die fuer den Ruestungsskill so beliebten Ruestungen muessen nicht
   vor dem Anschluss eingetragen werden. Neue Ruestungen werden automatisch
   beim zustaendigen Masterobjekt angemeldet, sobald sie das erste Mal
   repariert werden.

Und nun viel Spass bei der Programmierung!