MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | |
| 2 | Hallo, willkommen in den unendlichen Weiten der Regionsverzeichnisse! |
| 3 | |
| 4 | Du moechtest in einer Region mitprogrammieren? Prima, neue kreative |
| 5 | Mitarbeiter sind jederzeit willkommen! Du bist herzlich eingeladen, mit |
| 6 | Deinen Ideen zur Entwicklung beizutragen. |
| 7 | |
| 8 | Um die Programmierung und anschliessende Abnahme fuer alle Beteiligten |
| 9 | moeglichst reibungslos zu gestalten, seien Dir die in dieser Hilfeseite |
| 10 | genannten Dinge ans Herz gelegt. Diese lassen sich in folgende Kategorien |
| 11 | einteilen: |
| 12 | |
| 13 | 1) Formales zum Codestil |
| 14 | 2) Inhaltliche Anforderungen |
| 15 | 3) Was nicht akzeptiert wird |
| 16 | 4) Was ist vor dem Anschluss zu beachten? |
| 17 | |
| 18 | |
| 19 | 1) Formales zum Codestil |
| 20 | |
| 21 | o #pragma strong_types,save_types soll in allen Files verwendet werden, |
| 22 | ab Driver-Version LD_3.5.x wird auch rrtt_checks dringend empfohlen. |
| 23 | |
| 24 | o Der Code soll keine Zeilen mit mehr als 78 Zeichen enthalten. |
| 25 | |
| 26 | o Der Code soll sauber eingerueckt und sorgfaeltig formatiert sein, aber |
| 27 | bitte ohne Tabulatoren. |
| 28 | |
| 29 | o Verwende keine Lambda-Closures! Was auch immer Du vorhast: Es geht |
| 30 | ohne. Es sei ausdruecklich auf die Moeglichkeit von inline-Closures |
| 31 | verwiesen, wenn Du unbedingt vermeiden willst, eine separate Funktion |
| 32 | zu schreiben. |
| 33 | |
| 34 | o Kommentiere Deinen Code! Insbesondere dort, wo komplexere Objekt- |
| 35 | Interaktionen stattfinden, oder wo implizit besondere Eigenschaften |
| 36 | (z.B. der Mudlib, oder mathematische "Features") genutzt werden, die im |
| 37 | Code nicht auf den ersten Blick ersichtlich oder durchschaubar sind. |
| 38 | Daumenregel: "Wenn Du laenger als eine Minute ueber eine Zeile nachdenken |
| 39 | musstest, kommentiere sie." ;-) Rechne immer damit, dass jemand, der |
| 40 | Deinen Code liest, keine Ahnung hat, was Du da eigentlich tust. :-) |
| 41 | |
| 42 | o Wirf bitte nach Abschluss der Arbeiten Platzhalter-Code raus (z.B. leere |
| 43 | AddDetail()-Anweisungen) und entferne nicht fuer das Gebiet benoetigte |
| 44 | Dateien aus den Verzeichnissen. |
| 45 | |
| 46 | o Speicherung von Daten in secure-Verzeichnissen soll bitte nur sehr |
| 47 | sparsam erfolgen und nur in Abstimmung mit dem RM. |
| 48 | |
| 49 | o save_object() bitte sehr sparsam verwenden (nicht bei jeder Daten- |
| 50 | aenderung, bei Bedarf in reset/remove). |
| 51 | |
| 52 | o Wenn Defines zum Einsatz kommen, verwende sie bitte moeglichst sparsam |
| 53 | und sorge dafuer, dass Defines klar als solche erkennbar sind. Ausser in |
| 54 | Faellen, wo es gar nicht anders geht, solltest Du keine Code-Defines |
| 55 | verwenden, die mehr umfassen als einfache Funktionsaufrufe wie z.B. |
| 56 | #define TP this_player() |
| 57 | Fuer uebliche Standardfaelle existiert bereits eine Headerdatei in der |
| 58 | Mudlib unter /sys/defines.h. |
| 59 | |
| 60 | o Solltest Du bestimmte Ereignisse in Deinem Gebiet loggen wollen (z.B. |
| 61 | (Mini-)Questabschluesse oder besondere Kills), dann benutze bitte |
| 62 | log_file(), so dass die Logfiles nach /log/ geschrieben werden. Zusaetzlich |
| 63 | werden so erstellte Logfiles automatisch bei Erreichen einer bestimmten |
| 64 | Dateigroesse rotiert, so dass sich der Platzverbrauch in Grenzen haelt. |
| 65 | Das Protokollieren mittels write_file() in Regionsverzeichnissen unter |
| 66 | /d/ ist grundsaetzlich NICHT erwuenscht. |
| 67 | Nach Absprache KANN es fuer SELTENE und WICHTIGE Meldungen erlaubt werden, |
| 68 | mittels write_file(() nach /log/ zu schreiben. |
| 69 | |
| 70 | o Wenn Du in Deinem Gebiet Daten oder Code ablegst, der nicht fuer |
| 71 | jedermanns Augen bestimmt ist (Questloesungen, Gebietskarten, Savefiles |
| 72 | von questrelevanten (Master-)Objekten), solltest Du in Abstimmung mit |
| 73 | Deinem Regionsmagier ueberlegen, diese in ein ./secure/-Verzeichnis |
| 74 | zu verschieben, damit sichergestellt ist, dass auch tatsaechlich nur |
| 75 | berechtigte Magier darauf Zugriff erhalten. Denn bedenke, dass Lese- |
| 76 | und Schreibrechte nur fuer Codedateien geprueft werden, jedoch nicht |
| 77 | fuer beliebige sonstige Textdateien. |
| 78 | |
| 79 | o Es sei ausdruecklich auf die Manpages "goodstyle", "effizienz", etc. |
| 80 | verwiesen. |
| 81 | |
| 82 | |
| 83 | Das soll jetzt nicht heissen, dass der Anschluss von Code kategorisch |
| 84 | abgelehnt werden wird, der diese Formalien nicht erfuellt. (Ausnahme: Lambda- |
| 85 | Closures werden in den Regionen nicht mehr akzeptiert.) Ich moechte aber |
| 86 | wirklich nachdruecklich darum bitten, sie aus einem einfachen Grund |
| 87 | einzubauen: Du wirst nicht immer der einzige sein, der Deinen Code lesen und |
| 88 | warten muss, auch in Deiner Abwesenheit koennen Bugs auftreten. Und dann ist |
| 89 | es wesentlich einfacher, einen Minimalstandard zu haben, der es allen |
| 90 | ermoeglicht, den Code auch im MG zu lesen und dort zu fixen. Denn nicht immer |
| 91 | wird es moeglich sein, sich Dateien herunterzuladen und lokal zu bearbeiten. |
| 92 | |
| 93 | Zum Bugfixing an dieser Stelle aus aktuellem Anlass eine Anmerkung: Es wird |
| 94 | von jedem aktiven Regionsmitarbeiter erwartet, dass er einen Fehlerteufel |
| 95 | (/obj/tools/fehlerteufel) besitzt und dessen Fehlerliste regelmaessig |
| 96 | durchsieht und aufgetretene Fehler und Warnungen behebt. (Okt. 2007) |
| 97 | |
| 98 | |
| 99 | 2) Inhaltliche Anforderungen: |
| 100 | |
| 101 | o Wenn Du ein komplett neues Gebiet schreiben moechtest, das in einer Region |
| 102 | seinen Platz finden soll, sprich bitte die thematische Ausrichtung mit |
| 103 | dem RM ab, bevor Du anfaengst, Code zu schreiben. Falls von Deinen Ideen |
| 104 | irgendetwas nicht hierher passen sollte, laesst sich das mit wesentlich |
| 105 | weniger Frust im Vorfeld klaeren, als wenn hinterher das halbe Gebiet |
| 106 | umgebaut werden muesste. Sollte sich die konzeptionelle Ausrichtung |
| 107 | oder der Umfang waehrend der Programmierung grundlegend aendern, besprich |
| 108 | dies bitte kurz mit dem RM. |
| 109 | |
| 110 | o Ob neue oder alte Rechtschreibung, ist im wesentlichen Dir selbst ueber- |
| 111 | lassen, jedoch waere es schoen, wenn Du die Spieler-Anreden wie "frueher" |
| 112 | ueblich gross schreiben wuerdest ("Du", "Dich", "Dein"). |
| 113 | |
| 114 | o Es muessen in jedem Raum gewisse Standarddetails vorhanden sein, z.B. |
| 115 | Boden, Decke, Waende, Himmel (Sonne, Wolken), etc. Dies kann man sehr |
| 116 | bequem mit dem "Otester" pruefen. |
| 117 | Es sei aber ausdruecklich darauf hingewiesen, dass der Otester keinesfalls |
| 118 | benutzt werden sollte, um saemtliche vorhandenen Substantive bis ins |
| 119 | kleinste zu beschreiben. Es ist schoen, wenn Objekte moeglichst voll- |
| 120 | staendig beschrieben werden, aber man sollte es auch nicht uebertreiben. |
| 121 | |
| 122 | o Was bitte nur in Ausnahmefaellen gemacht werden sollte, ist, Details, |
| 123 | Infos oder Lang-/Kurzbeschreibungen aus Standardraeumen zu inheriten. |
| 124 | |
| 125 | o Falls Du Beschreibungen/Ausgaben in ASCII-Grafik einbinden moechtest, achte |
| 126 | bitte darauf, dass Du auf jeden Fall einen kurzen Alternativtext mit- |
| 127 | lieferst und diesen ausgibst, wenn der Spieler P_NO_ASCII_ART gesetzt hat. |
| 128 | Es besteht immer die Moeglichkeit, dass Spieler mit Sehschwaeche oder |
| 129 | Blinde Deine Objekte anschauen, und diese kommen mit Objekten in reiner |
| 130 | ASCII-Grafik nicht zurecht. |
| 131 | (Siehe auch die Manpage zu P_NO_ASCII_ART und "hilfe grafik".) |
| 132 | |
| 133 | o Eine Anmerkung zu den Schadensarten DT_HOLY und DT_UNHOLY soll nicht |
| 134 | unerwaehnt bleiben: Es wird von vielen Spielern und Magiern als logisch |
| 135 | und atmosphaerisch nicht begruendbar empfunden, wenn Gegenstaende oder |
| 136 | NPCs diese beiden Schadensarten gleichermassen einsetzen bzw. verursachen |
| 137 | koennen. Vergleichbares gilt fuer die gleichzeitige Abwehr beider |
| 138 | Schadensarten. Wenngleich bisher diesbezueglich keine klare Einigung |
| 139 | erzielt werden konnte, soll an dieser Stelle dennoch empfohlen werden, |
| 140 | von einer gleichzeitigen Nutzung von DT_HOLY und DT_UNHOLY abzusehen. |
| 141 | Der zustaendige Regionsmagier muss aber auf jeden Fall in Kenntnis |
| 142 | gesetzt werden und entsprechende Objekte zur Pruefung vorgelegt bekommen, |
| 143 | falls diese Nutzung dennoch fuer unumgaenglich gehalten wird. |
| 144 | |
| 145 | |
| 146 | 3) Was keinesfalls akzeptiert wird |
| 147 | |
| 148 | o Files, die in /players liegen, incl. Headerfiles. Dies erschwert das |
| 149 | Reparieren von Bugs ungemein und bringt eine gewisse Unuebersichtlichkeit |
| 150 | mit sich. Bitte auch nichts aus /players inheriten (Ausnahmen hiervon sind |
| 151 | aufgrund eines neuen Driver-Features nur noch mit Hilfe eines Erzmagiers |
| 152 | moeglich. Kurz gesagt: es gibt eine Whitelist von Objekten, die das |
| 153 | duerfen. Alle anderen duerfen das per Default nicht.). |
| 154 | |
| 155 | |
| 156 | 4) Was ist vor dem Anschluss zu beachten? |
| 157 | |
| 158 | o Code muss vollstaendig fertig sein. Das heisst insbesondere, dass |
| 159 | Debug- und nicht mehr benoetigter Code entfernt wurde und dass alle |
| 160 | erforderlichen Kommentare vorhanden sind. |
| 161 | |
| 162 | o Abnahme durch den RM und ggf. den fuer Gesellenstuecke zustaendigen EM |
| 163 | muss erledigt sein. Regionsmagier sind angehalten, eigene Gebiete, die zum |
| 164 | Anschluss in der eigenen Region geplant sind, von anderen Magiern abnehmen |
| 165 | lassen. |
| 166 | |
| 167 | o Der Magier ist angehalten, das Gebiet durch Testspieler testen zu lassen |
| 168 | (siehe hierzu die Testspieler-Regeln). Ob ein Spieltest als Voraussetzung |
| 169 | fuer die Abnahme gefordert wird, entscheidet der zustaendige RM. Er kann |
| 170 | den Test auch selbst durchfuehren oder ganz darauf verzichten. |
| 171 | |
| 172 | o Quests und Miniquests muessen vom zustaendigen Quest-EM getestet, |
| 173 | eingetragen und aktiviert worden sein. |
| 174 | |
| 175 | o Feedback der Testspieler und testenden Magier sollte umgesetzt sein. |
| 176 | |
| 177 | o Forscherpunkte muessen vom zustaendigen EM eingetragen worden sein. |
| 178 | |
| 179 | o Balance-Genehmigungen (Objekte, Heilung, ggf. Gildenbalance) muessen |
| 180 | vorliegen; die genehmigten Eckparameter sollen nachvollziehbar im |
| 181 | Gebietsverzeichnis dokumentiert sein: entweder im jeweiligen File, oder |
| 182 | als Textfile z.B. in einem Doku-Verzeichnis. |
| 183 | |
| 184 | o Kraeuter fuer den Kraeuterskill muessen genehmigt und eingetragen worden |
| 185 | sein (dies kann jeder EM mit dem Kraeutertool erledigen). |
| 186 | |
| 187 | o Hinweis: Erstkills muessen NICHT ZWINGEND vom zustaendigen EM eingetragen |
| 188 | worden sein. Die Erstkill-NPCs werden automatisch in einer vorlaeufigen |
| 189 | Liste gesammelt und vom EM entweder freigegeben oder abgelehnt. Auch |
| 190 | Sonder-Stufenpunkte fuer EKs muessen nicht vor dem Anschluss beantragt |
| 191 | oder genehmigt worden sein, auch diese Eintragung laesst sich erledigen, |
| 192 | wenn der betreffende NPC das erste Mal getoetet wurde. |
| 193 | |
| 194 | o Auch die fuer den Ruestungsskill so beliebten Ruestungen muessen nicht |
| 195 | vor dem Anschluss eingetragen werden. Neue Ruestungen werden automatisch |
| 196 | beim zustaendigen Masterobjekt angemeldet, sobald sie das erste Mal |
| 197 | repariert werden. |
| 198 | |
| 199 | Und nun viel Spass bei der Programmierung! |
| 200 | |