Richtlinien und Tips zur Raetselprogrammierung: 1. Bevor man ueberhaupt anfaengt mit Programmieren MUSS ein Konzept erstellt werden. Ein Konzept sollte einen ungefaehren Lageplan, moegliche Loesungs- wege, Ideen, EP-Vorstellungen usw. enthalten. Das Konzept ist mit einem der Raetselgoetter und einem passenden DL zu bereden. Konzepte zu Raetseln sollten (aus gegebenen Anlass) unter /w/.../priv aufbewahrt werden, dort darf nur der Besitzer lesen. (Da dort auch die Raetsel- und Domainlords nicht lesen koennen, muss man ihnen das Konzept per Mail schicken.) Erst, wenn das Konzept von Raetselgott und DL befuerwortet wurde, sollte man anfangen! Die Raetselgoetter sind uebrigens in /room/rathaus/filed (zgehzu gouv) mit 'liste auth' zu erfragen. Eine Mail an die Raetselgoetter (inkl. die Admins) kann man mit 'schreibe raetsel' abschicken. 2. VOR dem Programmieren sollte man unbedingt den zu erwartenden Aufwand abschaetzen! Ist das Projekt in einer absehbaren Zeit zu bewaeltigen? Fuer mehr als 500kB Code sollte man sich dringend einen Helfer suchen, denn sonst kann aus der schoensten Idee schnell eine traurige Sammlung trostloser Raeume und Objekte werden. 3. Lest Euch in der Enzy unter 'Richtlinien/Konzepte' mal alles durch, was beim Programmieren so zu beachten ist. 4. Ein modernes Raetsel DARF kein Lab der Form 'Du kennst Dich nicht mehr aus.' haben! Nein, Nein, Nein. Jeder Raum muss detailliert beschrieben sein und es darf keine unlogischen Raumausgaenge geben. (Wenn es gut be- gruendet wird, darf auch mal ein krumm verpointerter Ausgang dabei sein.) 5. Von Raetsel die zu einem Grossteil aus Rennerei bestehen, sollte auch abgesehen werden, d.h. wenn die Hauptzeit eines Raetsels dabei drauf geht von Ort zu Ort zu rennen, ist es sicherlich nicht das schoenste Raetsel. 6. Ein Raetsel sollte mehrere Loesungswege besitzen. Fuer jeden Weg muss es Hinweise in irgendeiner Form geben. 'Metzelloesungen' gehen auch ohne. 7. Raetsel muessen nicht gefaehrlich sein, aber sie sollten es sein. Schliesslich soll ein Spieler beim Loesen ja auch Herzklopfen bekommen, oder? 8. Ein Raetsel muss nicht das schwierigste oder das gefaehrlichste sein. Das ist gar nicht noetig:). Aber es darf gerne das schoenste sein! 9. Raetsel, die zum Teil oder insgesamt nur in einer Gruppe geloest werden koennen, erhoehen das Spielvergnuegen ungemein - sie sind natuerlich auch schwieriger zu gestalten ;-) Lasst Euch mal was einfallen! 10. Es muss ein detailliertes Loesungsfile geben, mit allen Loesungen. Es ist allerdings unter Verschluss zu halten (siehe 1). 11. Rechnet damit, dass die Spieler die verruecktesten Sachen machen. Sie werden jeden Trick versuchen, z.B. wenn man einem NPC etwas geben soll, muss man das unbedingt mit accept_object() abarbeiten. Ich-Befehle oder Illusionen sind mittlerweile sehr beliebt. 12. Die Syntax von add_actions sollte flexibel sein und ggf. irgendwo angge- deutet werden. Der Befehl 'parse_com' bietet dazu viele Moeglichkeiten. Auch von me() und here() sollte man des oefteren Gebrauch machen. Bitte keine 'festen' Stringvergleiche einbauen, sondern mit strstr() oder explode() nach einzelnen Kernwoertern suchen. 13. Viele V_Items machen zwar viel Arbeit, doch sie erzeugen erst die echte Atmosphaere eines Raumes. 14. Viele gleiche Raeume, die sich nur anhand der Ausgaenge unterscheiden, sollten nicht sein! Jeder Raum sollte seine eigene Beschreibung haben. 15. Verkaufbare Gegenstaende duerfen nicht beliebig oft erzeugt werden, nur einmal pro Reset. 16. Wenn moeglich, sollte man oft inherit oder replace_programm benutzen, um den Code effizienter zu machen. Man spart damit nicht nur Speicher, sondern auch moegliche Veraenderungen muessen nicht in jedem File einzeln durchgefuehrt werden. 17. Dokumentiert auch mal zwischendurch den Code und versucht wenigstens, einigermassen uebersichtlich zu programmieren - es wird die Zeit kommen, wo ein anderer den Code bearbeiten muss und dann nur Chaos vorfindet. 18. Wenn man sein Quest schon in einem anderen deutschsprachigen MUD einge- bunden hat, dann sollte man sich fuer UNItopia schon was eigenes und neues ausdenken. Das Konzept kann ja aehnlich sein, doch der Feinschliff sollte dann UNItopia-spezifisch sein. 19. Einige Gilden haben recht maechtige Eigenschaften, die man zwar nicht alle in seiner Programmierung beachten kann, doch man sollte sich ab und zu nach Gefahrenquellen umhoeren (z.B. die Illusion der Druiden, das Heino- bwz. Liebeslied der Barden oder das Erschrecken der Vampyre). 20. Rechnet damit, dass mehrere Spieler gleichzeitig auf Euer Raetsel los- stuermen werden. Das kann oft zu Problemen fuehren: offene Tueren, entdeckte Geheimgaenge, getoetete Waechter-NPCs, nicht mehr vorhandene Raetsel-Objekte, etc. Man sollte sich dringend Wege ueberlegen, wie man so was regelt. Moeglichkeiten sind z.B. ein NPC, der fuer einen bestimmten Zeitraum den Spieler speichert, der ihm gerade hilft oder ein Filter im Eingangsraum des Raetsels, der nur jemanden durchlaesst, wenn sich sonst niemand in den uebrigen Questraeumen aufhaelt. 21. Ueberlegt gut, wie Ihr die Erneuerung der einzelnen Raeume und Objekte des Raetsels gestaltet. Oft ist es angebracht, mehrere Raeume synchron zu resetten. Das erreicht man z.B., wenn man von einem Raum-reset() aus in den gewuenschten anderen Raeumen eine eigene _reset()-Funktion aufruft (Tip: einen Raum, der noch nicht geladen ist, braucht man auch nicht resetten, also erst mit find_object() pruefen!). 22. Wichtige Raetsel-Objekte sollten nicht ewig in einem Raum rumliegen, wo sie nichts zu suchen haben, d.h. ihr reset() sollte das Objekt zerstoeren, wenn es nicht in einem Spieler oder kein Spieler sich in seiner Umgebung befindet. Ein spaeter an diesen Ort kommender Spieler hat es sonst zu leicht, wenn er solch ein Objekt einfach so findet. 23. Immer wieder helfen Engel und befreundete Spieler einem mutigen Aben- teurer bei einem Raetsel. Wenn man das verhindern will, sollte man in wichtige Objekte eine Owner-Variable einbauen, die mit dem Namen des Spielers gesetzt wird, der das Objekt zuerst findet oder an sich nimmt. Bei jeder Aktion mit diesem Objekt kann man dann this_player() mit Owner vergleichen und ggf. eine Fehlermeldung ausgeben. 24. Man sollte dran denken, dass ein unsichtbarer Spieler von einem ag- gressiven Monster nicht automatisch angegriffen wird. Auch beim Starten einer Rolle etc. sollte der Aspekt der Unsichtbarkeit beachtet werden. 25. Ein Raetsel sollte gut in die darum bestehende Landschaft integriert werden. Ausser der Ankuendigung am Newsbrett 'Spieler/Evolution' sollte es auch unbedingt irgendwo einen Hinweis auf das Raetsel geben, besonders wenn es etwas abseits der normalen Wege und Staedte liegt. Dabei muss es sich nicht unbedingt um ein langweiliges Flugblatt handeln, dass am Stassenrand liegt ;-). Stimmt das einfach mit dem zustaendigen DL ab. 26. Ist ein Raetsel sehr lang, dann ist es angebracht, eine Unterteilung in mehrere Abschnitte einzubauen. Fuer jeden Abschnitt bekommt man dann einen Skill. Wenn der Spieler mittendrin einsteigen will, fragt man einfach seinen erreichten Skill ab. Wichtig dabei ist, dass einem solchem 'Spaeteinsteiger' ggf. wichtige Objekte fehlen, die er sonst in den ersten Abschnitten ergattert haette. Mit Hilfe des Raumtyps 'kein_startraum' oder 'startraum' kann man auch einen alternativen Startraum definieren, von dem der Spieler nach dem naechsten Einloggen das Raetsel erneut beginnen kann. 27. Genauso gilt das Problem bei Spielern, die sich mitten im Raetsel aus- loggen. Zum einen warten nun vielleicht irgendwelche NPCs auf diesen nicht mehr vorhandenen Spieler und sollten das irgendwann mal merken und andere Spieler sollten baldmoeglichst wieder ein voll funktions- faehiges Raetsel vorfinden! Moeglichkeiten gibt es hierzu z.B. mit einem Masterobjekt, dass einen Spieler waehrend des ganzen Raetsels ueberwacht und/oder mit der Funktion notify_quit() oder notify_dead(). 28. Es sollte fuer abbrechwillige Spieler moeglichst einen Weg zurueck in die freie Welt geben, d.h. Einbahnstrassen sollten vermieden werden! 29. Rechnet nicht damit, dass Eure Arbeit beendet ist, sobald die Raetsel- Admins das Raetsel eroeffnet haben! Jetzt kommen die ganzen Fehler und Ideen der Spieler - und das werden noch mal eine ganze Menge sein! 30. Viel Spass!