doc/wiz/leitfaden

ACHTUNG: DIESER LEITFADEN IST FURCHTBAR VERALTET! :-(


DER LEITFADEN 'WIE SCHLIESSE ICH ERFOLGREICH MEIN GEBIET AN'.
(in sieben Schritten zum Erfolg, von Tsunami und Feuerwehr)
-------------------------------------------------------------

Dieser Leitfaden ist absolut unverbindlich und kein Reglement. Die 
Reihenfolge muss nicht eingehalten werden, und auch die Anmerkungen 
zu den einzelnen Punkten sind nicht zwingend zu befolgen.

Fuer Schnellleser:

1) Raeume/Objekte/NPCs proggen
2) Alles Testen und Mail an die Regionsmagier (RM) schicken.
3) RMs pruefen Code und weisen auf moegliche Probleme hin.
4) Antrag Balance verfassen ('goto /players/paracelsus/office').
5) Forscherpunkte beantragen (hilfe erzmagier).
6) Mail an RMs, dass nun alles i.O. ist.
7) RMs schliessen Gebiet an.

Nun etwas ausfuehrlicher.

-------------------------------------------------------------
P H A S E 1
-------------------------------------------------------------
Du bist nun also Magier, voller Ideen und Tatendrang. Bevor Du wild drauflos
programmierst, ein paar Tips, um Dir und den zustaendigen RMs das Leben zu 
erleichtern:

Fertige Dir eine ASCII-Karte an, und schreibe einen kurzen Text, der Dein 
neues Gebiet beschreibt. Frage schon mal Deinen RM, wo ungefaehr dieses
neue Gebiet angeschlossen werden koennte. So kannst Du Dir ein paar Gedanken
machen, wie die Anschlussraeume ausschauen koennten.

Erstelle sinnvolle Unterverzeichnise: es hat sich folgendes bewaehrt:
Ein Hauptverzeichnis mit dem Namen des Gebietes (kurz, wenns geht). Dort
kommen dann die Unterverzeichnise rein: z.B. '+/doc +/mon +/obj +/rooms'. 
In das '+/doc' kommen dann Deine Karten und Texte. Falls Du mit 
'NotifyPlayerDeath()' Deine Kerben loggen willst, oder andere wichtige 
Sachen loggen moechtest, dann schreibe diese Files in das '/log/<deinname>/' 
Verzeichnis. 
In das '+/mon' Verzeichnis kommen alle NPCs usw.

Wenn Du ein Textfile aufrufen willst, dass den Inhalt der Unterverzeichnise
beschreibt, so lege einfach eine '.readme' Datei im entsprechenden 
Verzeichnis an. Dieses File wird bei jedem 'cd' aufgerufen.

Bevor Du jetzt losschlaegst, ueberlege Dir ein Define-File, worin Du die
ganzen Pfade definierst. Denn wenn Du zuerst alles in Deinem Player-
Verzeichnis proggst, und vor Anschluss wird das Gebiet in das Regions-
verzeichnis gemoved, will niemand die ganzen Pfadnamen abaendern.
Ein Beispiel: in Dein 'gebiet.h' (gib ihm einen praktischen Namen der zu 
Deinem Gebiet passt: eismine.h, hoehle.h oder keller.h usw) kaeme sowas 
in der Art:

#define EISMINE(x) ("/d/polar/tsunami/eismine/"+x)
#define ROOM(x) (EISMINE("rooms/"+x))
#define MON(x) (EISMINE("mon/"+x))
#define OBJ(x) (EISMINE("obj/"+x))

Dein Raum included dann das File: #include "../gebiet.h"
Dein Ausgang in einen anderen Raum machst Du dann folgendermassen:
AddExit("norden", ROOM("raum02"));

Ein NPC wuerde somit folgendermassen in den Raum gestellt:
AddItem(MON("eiself"), REFRESH_DESTRUCT);

Wenn spaeter aus irgend einem Grund Dein Gebiet verschoben werden muss, dann
kann der RM einfach die erste Zeile in 'gebiet.h' abaendern. Das spart Zeit
und Nerven.

Weiter bietet das Define-File die Moeglichkeit, laengere Befehle zu
verkuerzen. Ein Beispiel: Du moechtest Namen des Spielers (gross geschrieben)
ausgeben. Der Befehl dazu waere: this_player()->Name(WER)
Das ist ziemlich lang. Definiere in Deinem Define-File doch einfach:
#define TPN this_player()->Name(WER)
und schon wird Dein Code etwas uebersichtlicher. Die Anwendung waere z.B.
say(TPN+" popelt in der Nase.\n");

Wenn Du automatische Zeilenumbrueche moechtest, dann schreibe folgendes
in Dein Define File:
#define BS(x) break_string(x, 78 , "", BS_LEAVE_MY_LFS)
BS_LEAVE_MY_LFS bewirkt, dass Du immer noch selbst Zeilenumbrueche einbauen
kannst mit \n. Und so wird BS dann benutzt:
AddDetail( ({"wand","waende"}),BS(
  "Die Waende bestehen wie alles hier aus purem Saphir. In die noerdliche "+
  "Wand wurde ein schrecklich gezacktes und scharfkantiges Loch gesprengt."));

Um dies zu benutzen musst Du allerdings noch #include <break_string.h> in das 
Headerfile setzen (vor die #define BS(x)...)-Zeile), sonst kennt der 
Precompiler den Ausdruck BS_LEAVE_MY_LFS nicht.

Du wirst Dein Gebiet evtl. in Deinem Home-Verzeichnis (/players/...)
schreiben, da Du noch nicht den Sprung zu Level 21 geschafft hast. Du
solltest aber wissen, dass Deine RegionsmagierInnen nur Gebiete annehmen
werden, welche im Regionsverzeichnis /d/.../dein_name/ gespeichert sind. Das
ist wichtig, denn in Deinem Heim-Verzeichnis koennen sie nicht schreiben und
so keine Fehler korrigieren. Denke daran! Benutze unbedingt die Defines,
denn vor dem Anschluss wirst Du das Gebiet in das Regionsverzeichnis
schieben muessen.

Viele Spieler 'loggen', also speichern gerne Tode oder Aktionen von Spielern
in ihren Heim-Verzeichnissen. Dieses Schreiben funktioniert nicht von
Regionsverzeichnissen in Heim-Verzeichnisse. Benutze auch hier ein define!

Nun kommen wir zum proggen. Falls Du noch nie programmiert hast, ist es
sinnvoll, sich Beispielfiles anzuschauen. Wuehl Dich durch das '/doc'
Verzeichnis oder noch besser: frag Deinen Papimagier/Deine Mamimagierin oder
den RM, ob er Dir ein paar seiner Files zuschickt. Hast Du diese Huerde
ueberwunden, kann es losgehen. Wenn Du anfaengst zu proggen und nicht weisst, 
wie man einen bestimmten Befehl benutzt, kannst Du die 'man page' konsultieren 
(das Manual = Online Hilfe). Tipp einfach 'man <befehl>' und schon kommt die 
entsprechende Hilfeseite, falls vorhanden.

Ein paar Worte zu den Raeumen: Details sind hier sehr wichtig.
Mach viele Details und beschreibe sie nett. 'unt boden' -> 'Der ist unter Dir.'
ist nicht sehr interessant. Ein Raum mit weniger als 20 Details wird
mittlerweile als ungenuegend angesehen, auch wenn es noch ein paar Gebiete
im MG gibt, wo die Raeume fast keine Details haben (diese Zahl schwankt
natuerlich von Region zu Region -- trotzdem: je mehr Details, desto besser). 
AddSmells und AddSounds solltest Du ebenfalls nicht vergessen. Der Spieler 
von Welt will auch riechen und hoeren koennen. Wenn Du einen Raum erstellst, 
ueberlege Dir auch witzige und/oder sinnvolle Befehle, die man in dem Raum 
ausfuehren kann. Bei laengeren Prozeduren ist es fuer den RM hilfreich, wenn 
Du im jeweiligen Raum einen kurzen Kommentar absetzt.

Schau, dass Du ein atmosphaerisch schoenes Gebiet programmierst. Schau,
dass es sich mit seiner Umgebung vertraegt. Bevor Du ein abgestuerztes
Raumschiff von der Vega programmierst, frage lieber Deinen RM, denn
wahrscheinlich passt es thematisch nicht in seine Region (welche Region auch
immer es ist :-)).

Achte darauf, dass die Toedlichkeit Deines Gebiets sich mit Deiner Umgebung
vertraegt. Ueber-Schwere-Mega-Monster sollten von kleinen Spielern nicht
problemlos erreicht werden koennen. Benutze nicht ganz so toedliche
'Block-Monster', welche den Zugang versperren. So muss ein Spieler erst
seine Wuerdigkeit beweisen, bevor er an die harten Monster kommt. Tigonen im
Glockenwald sind KEINE gute Idee.

Viele Magier finden es lustig, Spieler in ihren Gebieten durch Fallen
sterben zu lassen. Das sind z.B. Knoepfe, die man drueckt, und die dann sofort
this_player()->die() aufrufen. Nachdem vor einiger Zeit die Todesfolgen
verschaerft wurden, sind derartige Fallen nicht mehr gern gesehen. Vermeide
sie wenn moeglich. Spieler machen jeden Muell, aber lass sie nicht dafuer
sterben, wenn Du es anders regeln kannst. Jede Todesfalle ist dem RM
aufzuzueigen.

Die Objekte: dazu gehoeren auch Waffen und Ruestungen, sowie alle anderen
schraengen Dinge, die Dir noch so einfallen werden. Bevor Du Dir Deine
erste Mega-Super-Alles-Kaputtschlag-Axt oder den Alle-Schaeden-Abwehr-Panzer
zusammenbastelst, setz Dich hin, atme ruhig durch und tipp dann 'man balance'.
Dort stehen alle wichtigen Eckdaten, die Du befolgen solltest. Und denk daran,
nicht zuviele exklusiven Waffen und/oder Ruestungen in einem einigen Gebiet.
Wenn Du grosse Objekte schreibst, ist hier auch wieder ein kleiner Kommentar
im File sehr hilfreich fuer den RM. Denk daran, Du bist vielleicht irgendwann
einmal nicht mehr erreichbar und dann ist es gut, wenn im File geschrieben
steht, was das Programm ungefaehr macht.

Jetzt kommen wir zu ein paar haeufigen Problemen:
Erzeugst Du ein Objekt, das in einen Spieler geschoben wird, musst Du 
unbedingt den Return-Wert abfragen, ob der Spieler das noch tragen kann:
Ein Beispiel: Eine eigene Funktion 'nehmen'.
In das create() vom Raum kommt:
AddCmd(({"nimm","nehm","nehme"}),"nehmen");

Die Funktion 'nehmen' erzeugt eine Zigarre. Sie prueft, ob einen Zigarre
schon im Raum liegt, dann nimmt der Spieler diese. Falls keine Zigarre
rumliegt, wird eine neue erzeugt und in den Spieler geschoben. 
Damit ein Spieler nicht hunderte Zigarren erzeugen kann, wurde eine
globale Variable 'int zaehler; zaehler=5; oben im create() vom Raum erstellt. 
Nach einem Raumreset steht der Zaehler wieder auf 5, wenn man das in der
reset() Funktion (siehe unten) definiert.

nehmen(string str)
{
  object ob;

   notify_fail("Was moechtest Du nehmen?\n");
   if(!str) return 0;
   if(str=="zigarre") {
   if(present("zigarre",this_object())) return 0; 
   // so wird die Zigarre IM Raum genommen

     if (zaehler) {   
       write(BS("Du nimmst eine Zigarre aus dem Fach."));
       say(TPN+" nimmt eine Zigarre aus einem Fach.\n",this_player());
       // TPN: siehe oben, Abschnitt 'Defines'
       ob=clone_object(OBJ("zigarre"));
       if (ob->move(this_player(),M_GET) !=1) {
       // dieses '!=1' faengt ME_TOO_HEAVY, ME_TOO_MANY_OBJECTS, 
       // und ME_CANT_BE_INSERTED ab

           write("Du kannst die Zigarre nicht mehr tragen. Sie faellt zu "+
           "Boden.\n");
           ob->move(environment(TP),M_PUT);
           }
         zaehler--;
         return 1;
         }
     write(BS("So ein Pech. Jemand hat die besten Stuecke bereits genommen."));
     return 1;
     }
  // und damit man auch andere Sachen als Zigarren im Raum nehmen kann:
  return 0;
  
}

reset()
{
    ::reset();
    // nach 30-45 min kann man wieder 5 neue Zigarren nehmen
    zaehler=5;
}

Die NPCs. Es gibt (noch) keine Vorschrift, wie stark maximal NPCs sein duerfen,
aber schau Dir trotzdem 'man balance' zu diesem Thema an.
NPCs werden oft schmerzlich von ihren Magiern vernachlaessigt. Oft
steht der grosse Drache auf dem Speicher, kann Dich in einem Schlag umhaun,
weiss aber nicht einmal seinen Namen und besitzt nicht ein Detail. Kuemmer
Dich um Deine NPCs. Gib ihnen eine schoene Beschreibung, lass sie etwas
ueber sich erzaehlen, gib ihnen Details, gib ihnen Kleidung.

Oft will man NPCs durch Gebiete laufen lassen, so dass sie mal Land und
Leute kennenlernen. Das ist etwas rechnerlastig, und auch wenn wir jetzt
jede Menge Power unter der Haube haben, sollte man einige Dinge beachten:
* Es gibt einige sehr schoene Standard-Lauf-NPCs. Es bietet sich an, diese
  zu benutzen. Sie haben alle noetigen Eigenschaften, unter anderem, dass sie 
  stehen bleiben, wenn sie keine Spieler mehr antreffen. Das spart 
  Performance. Ausserdem werden sie oft von einem Master gesteuert, und das 
  spart call_outs.
* Aufwendig ist besonders das Bewegen von NPCs. Rennende NPCs sind doch
  oede. Lass sie sich langsam bewegen. Jedes schoene Gespraech mit einem NPC 
  geht in die Hose, wenn der NPC staendig vor einem weglaeuft.

Denke generell daran, uebersichtlich zu programmieren. Benutze nicht
mehr als 78 Zeichen pro Zeile, fuege ruhig Leerzeilen ein, um die Struktur
zu unterstreichen. Ruecke in Schleifen den Code ein paar (z.B. 3) Zeichen
ein. Kommentare machen Deinen RM gluecklich! Wenn Du einst vielleicht nicht
mehr da bist, wird irgend jemand Deinen Code warten muessen. Denk an den
armen Kerl! Fuege bei Deinen Objekten einen Hinweis darauf ein, wovon und
wofuer sie benutzt werden! Wenn Du die Wahl hast, Code in einer
fuerchterlich effizienten, aber unuebersichtlichen Weise zu schreiben, oder
etwas weniger effizient, aber intuitiv und einleuchtend, nimm die
einleuchtende Weise. 

Zaubertraenke, Gildenobjekte, Gildenquests

Zaubertraenke

Zaubertraenke sind wichtig, und obwohl es sie schon an vielen Stellen im MG
gibt, sind sie immer noch gefragt. Man sollte beim Einbauen von ZTs daran
denken, sie nicht tief in Quest-Gebieten zu verstecken, so dass ein Spieler
keine Quest nochmal spielen muss, nur um den ZT zu bekommen. Ausserdem
sollten sie nicht zu schwer versteckt werden. Ein Zaubertrank in einem Buch
bekommt man z.B. durch:

create() {
...
AddReadDetail("buch","@@det_buch@@");
}

string det_buch() 
{
 if (this_player()->FindPotion("Du findest Macht in diesem Buch...\n")) 
   return "";
 else
   return "Du findest keine Macht in diesem Buch. Wie schade...\n";
}

Denke daran, auch einen Vers zu schreiben, welcher im Orakel den Tip fuer
diesen ZT darstellt. Du kennst diese Verse sicher schon zur Genuege :-).
Du musst den Zaubertrank spaeter zusammen mit den Forscherpunkten anmelden.

Gilden- und Miniquests.

Gildenquests sind kleine Aufgaben, nicht gross genug fuer richtige Quests,
welche von den Mitgliedern einer Gilde geloest werden muessen, bevor sie
aufsteigen koennen. Die Dinger sind voll im Kommen. Zauberer-, Kaempfer-
oder Chaos-Gildenmagier sind immer hinter denen her. Quests wie 'Finde das
verschollene Buch' oder 'Befreie den Verurteilten' lassen sich oft ohne
grossen Aufwand in Gebiete einbauen. Sie garantieren auch eine gewisse
permanente Besucherzahl im Gebiet :-)). Bevor man diese Quests einbaut,
sollte man das prinzipielle OK der Gildenmagier holen, nachher muss man
ihnen die Quest vorstellen, damit sie sie bewerten und freigeben.

Will man eine kleine Aufgabe nicht gildenabhaengig, sondern fuer alle
Spieler einbauen und dafuer Stufenpunkte vergeben, dann kann man die Aufgabe
auch als Miniquest eintragen lassen, und zwar beim gleichen EM, der auch die
FPs eintraegt. Es folgen Code-Beispiele fuer die Vergabe der Quests...

int befreie(string wen) 
{
  notify_fail("Wen moechtest Du befreien?\n");
  if (wer != "gefangener") 
    return 0;
  
  // Hier werden die Stufenpunkte fuer die Miniquest vergeben...
  // Falls man keine Miniquest angemeldet hat, laesst man das natuerlich weg
  SCOREMASTER->GiveMiniQuest(this_player());

  // Hier sind die Kaempfer. Der Code kann variieren...
  call_other("/p/kaempfer/std/k_master","SetzeAufgabe",getuid(this_player()),
    "Befreie den Gefangenen");

  // Letztes Beispiel: Hier sind die Zauberer:
  call_other("/p/zauberer/npc/test","GiveQuest",this_player(),
    "Befreie den Gefangenen");
  ...
}

Gildenobjekte

Gildenobjekte wirken noch besser als Gildenquesten, um Spieler in Gebiete zu
locken :-). Dies sollte jedoch kein Anlass sein, ein Gebiet mit derartigen
Dingen zu ueberladen aber dafuer die Details und die Atmosphaere zu
vergessen. Ganz generell gilt: Maessige Dich! Weniger ist mehr!

Ganz generell sind Gildenobjekte z.B. Utensilien der Zauberer, Waffen mit
Kaempfer-Boni fuer Kaempfer oder Kreiden etc. fuer Chaoten. Diese Objekte
muessen natuerlich von den Gildenmagiern genehmigt werden, bevor das Gebiet
angeschlossen wird. Sprecht frueh genug mit den Gildenmagiern. Sie werden
euch sicher genug Beispiele fuer derartige Objekte geben, weshalb hier auf
derartiges verzichtet wird.

-------------------------------------------------------------
P H A S E 2
-------------------------------------------------------------
Du hast nun alle Raeume/Objekte/NPCs erstellt. Nun geht es in die Testphase.
Erzeuge Dir einen Testspieler, damit Du Deine Raummeldungen wie z.B. mittels
tell_room() auf ihre Richtigkeit ueberpruefen kannst. Schau Dir in Ruhe
Deine Sachen an und versuche, die unsinnigsten Sachen darin zu tun. Das werden
die Spieler naemlich nachher auch machen. Ist Deiner Meinung nach alles OK,
schreib eine Email an Deine zustaendigen RMs. Sehr hilfreich (fuer die RMs)
waere eine zusaetzliche Liste (siehe auch Phase 4) mit:

1) allen NPCs (welche Objekte tragen sie) und allfaellige Sonderfunktionen
   ganz kurz erlaeutert.
2) Eine Liste aller Objekte. Bei komplizierten Objekten eine kurze Beschreibung
3) Eine Liste, in welchem Raum liegt welches Objekt/ZT/Heilstelle/NPC

Diese Liste kannst Du natuerlich in Dein /doc Verzeichnis legen, was dann auch
spaeter sehr hilfreich sein kann.

Falls sich Deine RMs nicht melden, sprich sie an, mail ihnen nochmal.
Vielleicht haben sie Deine Mail vergessen. RMs sind prinzipiell vergesslich.
Sie unterhalten sich jedoch sicherlich gern mit Dir. Keine falsche
Bescheidenheit, ran an den Feind.

- Testspieler -   oder   - Zwischen Legalitaet und Wahnsinn -

Kaum ein Magier kann die merkwuerdigen, oft widersinnigen und kranken
Gedankengaenge eines Spielers nachvollziehen. Deshalb ist es eine gute
Sache, sein Gebiet von Spielern testen zu lassen. Sie koennen die Staerke
der NPCs gut einschaetzen und korrigieren, kennen die geheimen Kniffe der
Gilden und machen generell das, woran man nie gedacht hat.

Spielertesties sind so eine Sache. Als erstes muss man kompetente Spieler
finden, welche bereit sind, das Gebiet zu testen. Dies ist nicht einfach,
denn die wirklich guten Tester sind oft hoffnungslos ueberbelegt. Hat man
einen willigen Spieler gefunden, kreiert man sich einen Testspieler, indem
man einen neuen Spieler einloggt und im P_TESTPLAYER auf den eigenen Namen
setzt. Das kannst Du z.B. so machen: 
xcall testi->SetProp(P_TESTPLAYER,"<Magier>") wobei <Magier> Dein Name ist.

Danach darf man ihn wild in Gilden eintreten lassen, ihm seine 
Werte setzen und ihm Ausruestung clonen. Es gibt einige schoene
Testspieler-Tools, mit denen sich Testies Ruestungen setzen und sich heilen
koennen.

Hat man Spieler und Testspieler, so kommt man an die legalen Probleme. Alles
wichtige erfaehrt man durch 'hilfe testspieler'. Dort steht, dass
Testspieler bei Erzmagiern angemeldet werden muessen, welche sie dann in ein
Ueberwachungstool eintragen, so dass seine Handlungen geloggt werden. 
Tatsache ist, dass sich aber kaum einer seine Testspieler bei einem
Erzmagier anmeldet und die meisten EMs das selbst nicht tun. (Testies neuer
Gilden moegen hier eine Ausnahme bilden).

Generell beachte folgendes: Mach keine Spieler zu Testspielern, denen Du nicht
traust oder die Du nicht kennst. Wenn ein Spieler mit seinen Tools durchs MG
laeuft und Unsinn anstellt, bist Du mit Schuld, egal ob der Testie
angemeldet ist oder nicht. Wenn Du einen Spieler durch ein Gebiet laufen
laesst, bevor die FPs eingetragen wurden, dann ist das nicht legal, aber es
wird keiner meckern, wenn Du ihn ueberwachst und somit aufpasst, dass er
keinen Unsinn ausserhalb des Gebiets anstellt. Wenn Du einen Spieler durch
ein Gebiet mit FPs laufen laesst und der Spieler die von ihm gefundenen FPs
bekommen will, so musst Du ihn bei einem Erzmagier anmelden, denn FPs kann
nur ein Erzmagier setzen.

Oh, und schreibe Dir die Namen und Passwoerter Deiner Testspieler auf. Falls
man mehrere hat, vergisst man verflucht schnell die Namen :-).

-------------------------------------------------------------
P H A S E 3
-------------------------------------------------------------
Die RMs schauen alle Files an, die Du erzeugt hast. Danach werden sie Dir
eine Liste zurueckschicken mit allen Problemfaellen, die sie gefunden haben.
Je nach Umfang Deines Gebietes kann das natuerlich etwas dauern.
Hast Du die Informationen zurueckbekommen, kannst Du Dich an den Feinschliff
machen. In der Zwischenzeit solltest Du Phase 4 und Phase 5 erledigen.

-------------------------------------------------------------
P H A S E 4
-------------------------------------------------------------
Falls Du Objekte hast, die genehmigungspflichtig sind (man balance), so musst
Du einen Antrag an das Balanceteam stellen. In der Zwischenzeit sollte Dein
Magierlevel so hoch sein, dass Du den Befehl 'goto' benutzen kannst. Es
gibt einen Extra Raum fuer die Balanceantraege: 
goto /players/paracelsus/office
Dort gibt es dann eine gute Hilfeseite.
Wichtiges zum Antrag: mach bitte nicht fuer jedes Objekt einen eigenen
Antrag, sondern schreibe Dir einen grossen Antrag, in den alle Deine
Objekte reinkommen, die der Balance vorgelegt werden muessen (siehe Phase 2:
aus der Liste, die Du erstellt hast). Dazu solltest Du jedes Objekt kurz 
beschreiben. Dazu kommen die wichtigsten Werte, bei Waffen z.B. Waffenart, 
P_WC, P_NR_HANDS, P_DAM_TYPE, P_WEIGHT, und eine kurze Beschreibung der 
Sonderfunktionen.
Das Bewilligen Deiner Objekte kann eine ziemlich lange Zeit in Anspruch
nehmen (Wochen). Hier nicht ungeduldig sein. Das dauert seine Zeit.
Wenn Du Objekte proggst, die bestimmt durch die Balance muessen, gib doch
Deinem RM fruehzeitig Bescheid, dass er sich das anguckt. Dann kannst Du 
die Sachen bereits beantragen, und in der Zeit, bis die Antraege 
bewilligt wurden, die anderen Dinge proggen. Dieser Ansatz gilt aber eher
fuer Magier, die bereits etwas angeschlossen haben und neue Gebiete 
erstellen. Fuer den Neuling ist es empfehlenswerter, alles fertigzumachen
und dann zu beantragen. Grund: siehe oben: So kannst Du vorweisen, dass Du
Dir Muehe gegeben hast, tolle Sachen auf die Beine zu stellen, und nicht
einfach einen NPC in die Welt stellen willst, mit hunderten toller Objekte.

-------------------------------------------------------------
P H A S E 5
-------------------------------------------------------------
Gleichzeitig solltest Du die Forscherpunkte beantragen. Welcher Erzmagier
dafuer zustaendig ist, findest Du mit 'man erzmagier' heraus. Die 
Faustregel lautet: etwa 1 FP pro 10 Raeume. Vermeide FP fuer Details, damit
die 'Untersuche-Skripte' keine Chance haben. Geh lieber so vor: 
Detail: 'gras' -> 'Du wuerdest Dich am liebsten ins Gras legen.'
Wenn der Spieler dann eintippt 'lieg ins gras' oder so aehnlich, gib dafuer
den FP, aber nicht fuers Untersuchen vom Gras.
Wofuer Du alles Forscherpunkte eintragen kannst, erfaehrst Du durch
'hilfe forscherpunkte'.
Mache ein paar Vorschlaege, und schick sie dann dem zustaendigen Erzmagier.
Der wird aus Deinen Vorschlaegen ein paar rauspicken und anschliessen.
Aber bevor Du das tust, muss Dein Gebiet zwingend schon im Regionsverzeichnis 
liegen, damit keine FPs aus /players eingetragen werden.

Gleichzeit mit den FPs meldest Du auch MiniQuests und Zaubertraenke
bei diesem Erzmagier an. Du musst angeben, wieviele Stufenpunkte die
Miniquest bringen soll und in welche der 3 Kategorien einfach/mittel/schwer
Deine Zaubertraenke fallen.

Denke daran, spaetestens jetzt die Gildenquests und Gildenobjekte bei den
Gildenmagiern anzumelden. Unangemeldetes darf nicht angeschlossen werden.
Wende Dich also frueh genug an diese Leute.

-------------------------------------------------------------
P H A S E 6
-------------------------------------------------------------
Ist alles von der Balance genehmigt worden, und sind die FP angeschlossen,
solltest Du Deine RMs informieren. Falls Dein Gebiet immer noch im
Heimverzeichnis liegt, wird es nun in dein Regionsverzeichnis
verschoben. Du stehst nun kurz vor dem Anschliessen. Ueberleg Dir doch
schon eine nette Botschaft, die Du dann in der MPA veroeffentlichen wirst.

-------------------------------------------------------------
P H A S E 7
-------------------------------------------------------------
GRATULATION! Du hast es geschafft! Aber jetzt nicht auf den Lohrbeeren
ausruhen. Die ersten Spieler werden sich einfinden, und viele sind
wandelnde Konversationslexikons, die auch den kleinsten Grammatikfehler 
in Deinen Beschreibungen finden. Andere Spieler werden Dir neue Vorschlaege
fuer commands zusenden, die in die entsprechenden Raeume passen wuerden.
In /log/report/<magiername>.rep wird automatisch Dein Report-File erzeugt,
in das die Spieler die gefundenen Typos, Bugs und sonstige Ideen reinschreiben.
Schau Dir Dein Repfile an, und arbeite es ab so gut es geht.
Nur so wird das Gebiet zu einem wirklich 'gepflegten' Gebiet.
Denke daran, das rep-File nach dem Abarbeiten zu loeschen, sonst wird
es zu voll.


SIEHE AUCH:
    balance, hilfe magier, /doc/wiz/

----------------------------------------------------------------------------
Last modified: 16:00 2003-02-22 by Humni